A little philosophy on Quickr development
Category NoneAs you might imagine, I am often asked for advice out of the blue by people I don't know, especially about QuickPlace or Quickr. This tells me two things - one, that I've done a decent job over the past eight years of associating with the product, and two, that I need to write more newsletters. Especially now that there are several thousand interested Quickr folks out there!
Back to my story. You see, I don't subscribe to the mid-90s IT heydey "no free consulting" mantra that I occasionally hear some of my contemporaries hanging onto. I believe that you have to provide value from the first interaction - whether that is through a blog, newsletter, website, free code, or sales call. So, while I can't respond to every request (meaning, please don't send me your nsd files and don't ask me to architect a global solution via email), occasionally I receive a request that's so polite, innocent and unobtrusive that I feel compelled to help out even though I know nothing will come of it for the company.
Yesterday was one of those days. I received a request from a Notes developer in the Czech Republic. He had been struggling with how to create a fairly complex system in Quickr, and was new to it. While I couldn't design the entire system on the fly for him, I did give his approach some thought and constructed a reply - that I thought I'd post here.
Well the basic approach looks right although there are - like Notes or Domino - always options to make it easier to use. Some things to keep in mind:
1. You can create your own back-end views for Quickr just like Domino, then use them for Ajax calls and categorization and "restrict to category" operations. Useful for associating documents that are not in a true response hierarchy.
2. Your approval process can be different than the basic workflow options available in Quickr. Placebots and controlling documents/forms can be used to build your own. See the templates for examples of a custom workflow engine.
3. You can set a field to place your documents onto the calendar - it is not necessary to use the calendar view to get things on it.
4. Remember that Quickr is not a true scheduling system - you have to do the work yourself if you are going to check availability of resources as part of the application.
5. Design for the greatest ease of use for the approving managers. Consider the possibility of creating a management console where they can approve multiple requests at once instead of sending them only to single requests via email, that gets frustrating.
6. Have fun. Quickr development is like Notes/Domino, just similar at a higher level. Meaning - design for intuitive use, don't forget that there are Domino elements you can use, and don't feel constrained by the simplicity of the initial development shell (HTML & Javascript forms, folders, etc.). The best Domino applications use Notes databases as containers for innovative uses of the data store and don't stick to the core design elements.
Hope this helps!
What the exercise made me realize is that getting beyond the basics with Quickr is still hard for pure Notes or Domino heritage developers, and understanding the Domino-ness of it all is hard for great web developers. Some would say too hard for either. But by using the constructs available to us under the covers - like good Domino developers often do - we can build really excellent Quickr applications that leverage the core Quickr services like member management and security...stuff we don't have to worry about too much.
Have a look at the source files for the SNAPPS Quickr Templates. It's HTML, Javascript, and hooks into every kind of core Domino construct - views, folders, documents, the DOM, databases, field values and types, and agents. Stuff you know, stuff you use to create great Domino applications. It just takes a little leap to get from there to a great Quickr application.
Comments
This is a very Domino-centric view of Quickr development (and given your Quickplace experience I can understand why) - do you have any light to shed on the differences between the development requirements on Quickr/Domino and Quickr/J2EE?
Is SNAPPs doing any serious Quickr/J2EE development at this stage?
Cheers, Stuart
Posted by Stuart McIntyre At 03:49:16 PM On 01/03/2008 | - Website - |
That's an interesting proposition. Can you provide an example?
Posted by Nathan T. Freeman At 07:41:52 AM On 01/04/2008 | - Website - |
Posted by Rob Novak At 09:20:58 AM On 01/04/2008 | - Website - |
Posted by Rob Novak At 09:40:18 AM On 01/04/2008 | - Website - |
I have a requirement to make some customisations for Quickr for WPS and was wondering if you could point me in the direction of any resources for quickr development e.g. Red Books etc.
Regards,
Michael
Posted by Michael Wall At 10:23:24 AM On 02/19/2008 | - Website - |