Quickr Best Practices?
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
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?
Posted by Peter Smith At 09:06:50 On 22/06/2009 | - Website - |
So if we go with the many places configuration, how does that affect searching? Can you search across all places? THANKS!!
Posted by Kathy Brown At 09:26:27 On 22/06/2009 | - Website - |
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.
Posted by Peter Smith At 09:48:17 On 22/06/2009 | - Website - |
And yes again, deep room structures can be a pain so try to keep them short.
Posted by Andreas Ponte At 10:07:15 On 22/06/2009 | - Website - |
You can cretae each piece as its own site which would help limit the mutiple directory url structure.
Posted by keith brooks At 12:53:18 On 22/06/2009 | - Website - |
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.
Posted by garth thomas At 13:03:45 On 22/06/2009 | - Website - |
Posted by Michael Urspringer At 16:33:46 On 22/06/2009 | - Website - |
Posted by Daniel Lieber At 08:58:45 On 24/06/2009 | - Website - |
Posted by Kathy Brown At 13:41:33 On 28/06/2009 | - Website - |
Thx
Santosh.
Posted by Santosh Shanmukh At 06:38:52 On 19/03/2010 | - Website - |