About Me...

NotesRunningLogoRSmall.png

I'm Kathy Brown and I've been an application developer in Lotus Notes/Domino since 2005.

Prior to working in IT, I've had numerous careers including an Investment Analyst and even an Actress (long ago and far away).

And I (try to) love running!

me.jpg

kathy (at) runningnotes (dot) net

On Twitter, kjbrown13

Upcoming Races

Looking 4 Something?

Disclaimer

This is my personal blog. None of the opinions shown here represent those of my employer. In fact, forget I even have an employer. Any examples given here are strictly fictional and hypothetical and it is pure coincidence if they in any way seem like anything in real life.

« Daily Running | Main| 28 days! »

Quickr Best Practices?

Category Quickr Lotus Notes
Anyone have input for some Quickr Best Practices?

My situation: my customer is looking to implement Quickr as a document management system (among other things, but this is first priority). The current system consists of a server drive with folder and subfolders. I’m looking for input on the best Quickr implementation.

Let’s call the server “Fruit”. There are two main folders, “Apples” and “Oranges”. Within both Apples and Oranges, there are subfolders. Apples contains “McIntosh”, “Granny Smith”, “Fuji”, “Rome”, etc. There are various folders and documents within each of those. Same goes for Oranges, there are subfolders, “Navel”, “Valencia”, etc.

So my question is whether Apples and Oranges should be Quickr places, and McIntosh and Navel should be rooms within those places, or if McIntosh and Navel should be places of their own? What are considerations for either way of setting it up?

With over 300 types of apples, we’d rather get this right on the first try. I’ve done a bit of searching around (admittedly, not a lot) and not found anything regarding a Best Practice for the architecture of a Quickr server.

I realize we can use tagging and such to categorize documents, so that will eliminate some of the need for “folders”, particularly, I am thinking the subfolders within each variety (Navel) will be unnecessary.

My first instinct is to create a place for each variety. Creating more places with fewer documents, rather than a few places with loads of documents. However, I am not a Quickr expert, and so turn to the “Yellow-verse” for your opinions.

We will need to search across all Apples. I’m not entirely sure if that makes a big difference.

Don’t be too hard on me, remember I’m a dev, not a Quickr Implementation Specialist! My admins don’t have blogs, so I’m asking the question on their behalf. Anyway, I’d love to hear your thoughts/experiences. Or feel free to tell me I am a moron, and show me a link.

Comments

Gravatar Image1 - You're not alone in failing to find best practice info for Quickr.

One thing that would help answer the question is to know how much data there is in total.

Two things to be careful of are overly large places (although using DAOS in quickr 8.2 will help with this) and very deep room structures - which can cause issues with the path length when working via the connectors.

Is there an average number of docs / volume per apple variety you can share with us?


Gravatar Image2 - The folder structure isn't very deep, one level or two at most below the "variety" level. However, anywhere between 25-100 docs in each variety folder. Problem will be as we continue, I could see a lot more "stuff" getting put in these rooms, email, attachments, etc.

So if we go with the many places configuration, how does that affect searching? Can you search across all places? THANKS!!

Gravatar Image3 - Quickr can search across all places using Domain search, so that's not an issue (although the indexing can be resource intensive, so you have to schedule it carefully).

According to this technote: { Link } you can have masses of rooms or folders in a quickr, if you search the quickr forum (www.notes.net) there are some conversations around this as well.

It seems like you could have a few top level places, and then create rooms beneath for varieties with folder structures in the rooms.

Just think about how you want/need to manage security - rooms can inherit security from the parent place when created, but after that each room has it's own ACL. A user in a room must have access all the way down the chain to the room itself. You can use groups to ease the management of users, but read up on the implications of being a member via a group rather than as a named user.

Gravatar Image4 - Yes, you can search across all places. There is a section called "Configuring cross-place searching" in the Infocenter which explains how to configure it.
And yes again, deep room structures can be a pain so try to keep them short.

Gravatar Image5 - forgetting if this should even be in Quickr for the moment vs a doc library for instance or filenet if you need deeper info, you want simple library/folder names.
You can cretae each piece as its own site which would help limit the mutiple directory url structure.

Gravatar Image6 - be careful that you are using Quickr for what it's intended for. It isn't (although some people try to use it as such) primarily designed to be a static repository for all of an organisations documents or an online filing system. Sharepoint is probably a better choice for that kind of application as that's what it is good for, but it isn't able to do much anything else.

The Quickr library components are designed to be a repository for documents that are associated with a particular business activity. Ideally this activity is the reason that the place came into existance.

That said, if you want to organise the documents coherently the best way to do that it within a single library component as you will have the tree component available for navigation which you would not if you used rooms. For scalability use rooms where there is no need to maintain coherence with the documents in the levels above or as mentioned earlier you need to manage access levels differently for a subset of documents.

If you are able to use 8.2 (I am assuming from your blog title that we are talking Quickr for Domino) and enable DAOS as this will greatly increase your scalability.

Gravatar Image7 - @1: The folder depth should no longer be a real show stopper as it is improved with the newest connector HF14 and Quickr 8.2. I have already tested 17 folder in depth with no problems (and stopped testing then...)

Gravatar Image8 - The documents should be organized in a way that is meaningful for users who need to access them. The taxonomy of the system is important and there are multiple ways of filing. The various access methods should be clearly defined prior to the design. Having designed the Quickr Migrator, we have seen the effects of having rooms and folders; some of system differences will not be obvious unless there is extensive customization. Please feel free to contact me directly for more specific advice. --Daniel Lieber, IIUI

Gravatar Image9 - Thanks everyone for your feedback! We will likely take a small portion of our documents (like just the kiwi fruit) and utilize more places with fewer docs rather than one big place with loads of docs. I'll let you know how that works for us!

Gravatar Image10 - Hi, I am part of a team maintaining a quickr 8.1 (j2ee) server that has 1000+ places (with 1 library per place on avg). The primary usage of quickr is for document management. There are more than 100,000 docs (nearly of 160 GB). However there is no correlation of the actual document size and the DB2 database size (360GB). Can anyone help any possible reasons for this inordinate disparity between actual document size and size of DB. Could it be bcos there are too many places? (Note: we are not using the wikis, blogs and other content features of quickr)

Thx
Santosh.

Post A Comment

:-D:-o:-p:-x:-(:-):-\:angry::cool::cry::emb::grin::huh::laugh::lips::rolleyes:;-)