Tag Archive: Quickr

SNAPPS Quickr Bootcamp

This week I attended the SNAPPS Quickr Bootcamp, held in Overland Park, KS. It was a three-day Quickr developer training session. The next time the SNAPPS folks offer this, RUN, don’t walk, to sign up.

Obviously, these guys are smart, they’re frequent speakers at conferences, and they are experts on Quickr. They have done a terrific job at putting together material to get you up to speed and developing with Quickr. The three day bootcamp covered what you need to know, as well as what to watch out for. They discussed how to fix things when they go wrong and what you should NOT do (but how to do it anyway). They’ve really condensed their years (and years and years) of experience and delivered a lot of that knowledge in three days.

The bootcamp was very well constructed, with a basic starting level and working up to more advanced topics. The format was part lecture, part hands on exercises, with enough of each to deliver the knowledge and keep the attendees engaged.

Much like going to Lotusphere, I feel exhausted and my head is filled with stuff I can’t wait to get home and try out. Thanks SNAPPS guys!

Headed to Boot Camp

Quickr Boot Camp, that is. I am excited to say I just got approval to attend the SNAPPS Quickr Boot Camp this April. I am looking forward to learning all about Quickr from *THE* Quickr experts.

There are only 12 slots, who else is going? Let me know if you’ll be attending!

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.