So this week a number of us worked on a collaboration roadmap. One part of the roadmap included team collaboration. The other part is what I would term enterprise social collaboration. Both have their place and both kinds should be able to work together. Anyway, the question came up as to which version of Quickr they should use.
IBM made the interesting decision almost two years ago to deliver two version on two different platforms. At the time, all those who lived in the Java world really liked it and I’m sure all the Notes and Domino people scratched their heads. Anyway, now everyone has a decision to make as to which version to use. From the documentation, some personal experimentation, and a couple blogs, I made this list:
Reasons to Use Domino:
| # | Pro | Description |
| 1 | Offline Support | Quickr Domino has supported transferring all contents of a place to your hard drive and interacting with it there. In essence, it becomes another Domino db hanging out there. |
| 2 | More Templates | Since the domino version has been around longer, the ecosystem of partners has created a number of templates and functionality within the spaces for it. SNAPPS has a number of free downloadable templates. Neo Dashboard has a set of paid templates. The J2EE version, as a newer product does not have as deep an ecosystem. |
| 3 | More full featured collaboration components | The collaboration components have a richer feature set. For example, the oob tasks have more functionality and allow you to show more information than the J2EE version |
| 4 | Support for decentralized server environment | The scaling of Quickr D follows your typical approach to scale with Domino. You replicate. This means that session sharing is more difficult but it also means that Disaster recovery is easier. |
| 5 | Uses Domino web servers | You may consider this a plus or a minus. It uses one web server but the servers comes oob and is easy to get up and running. |
| 6 | Place Management is a bit better | With more features, there are more place management options. |
| 7 | Better browser support | The browser support is more full featured although gradually shrinking. This means that if you want to support the complete range of browsers, it will take less effort to do so with Quickr D. You can do so with Quickr J. It just means additional tweaking of the Quickr J theme. |
| 8 | Better non-document functionality | All the non-document functionality like calendar, tasks, etc are more full featured. |
| 9 | Rooms | The scaling of Quickr D is via a rooms concept where you create almost a completely new space called a room. It gives you significant flexibility but does have some UI tradeoffs. |
Reasons to use Java:
| # | Pro | Description |
| 1 | JSR 168 support | By supporting portlets, you can more easily create new functionality and place on pages. This is much easier than doing so in Quickr D |
| 2 | Better user experience | The end users can add pages and components much easier using the inline ajax functionality you see in the demos. Quickr D uses a more simple html approach. |
| 3 | Better document management | The document management functionality is both easier to use, supports a folder concept, and scales better than Quickr D. |
| 4 | SPNEGO / Windows login suppport | If you need to support login to Quickr via the windows login, you can do this on Quickr J.Note: This is extra effort for current version but oob when the soon to be released next version of Quickr J is out. |
| 5 | Can run on multiple web servers | Default if IBM http server but since it’s running on WAS, you can swap out web servers fairly easily. |
| 6 | Feed reader and other component support | Note: this is a next version itemWebSphere Portal 6.1.5 released a number of blog, wiki, idea room, really nice fead reader, and other templates. All are supported by Quickr J because of the shared foundation. This is a common theme as functionality between the two products becomes identical…….even if some of the UI approaches differ. |
| 7 | ECM Integration | Quickr J has already been integrated with Filenet, IBM DB2 Content Manager, Alfresco, and Documentum. Any need for ECM integration will push you to use Quickr J |
| 8 | Better multi-lingual support | This represents a minor pro. Both version support major languages but Hebrew, Arabic, and several other languages are only supported in Quickr J |
| 9 | Better site administration | WAS as a foundation means you can manage the entire site much easier. The example given by one administrator was that it is easier to delete a space in Quickr J but extremely difficult to do in Quickr D (e.g. a couple clicks and done vs multiple screens and clicks in Quickr D) |
| 10 | Scales like WAS | Quickr J scales via the WAS cluster approach. This allows better support for sessions for example.Note: the next version of Quickr J will add significant support for a farm or a multiple install approach where you may have three separate geographic installs with on main site view of your spaces. |
| 11 | Shared search with Lotus Connections | Currently, neither version supports search across Quickr and Connections. Last week at Impact, the product manager showed support for search between the two products.Note: this will be in the next release of Quickr J |
| 12 | Next Release notes | We have noted where some functionality is expected in the next release of Quickr J. IBM has followed a release schedule of focusing on first Quickr D and then focusing on Quickr J in the next release. The next release focuses on Quickr J with some expected enhancements to Quickr D. IBM has not announced the release date but it is expected this year. |
Here’s a couple of the blogs I used as well as the documentation:
- Lotus Evangelist has an old blog post that’s somewhat dated with new releases of the product but still useful.
- The Quickr Blog had some more information.
- IBM has a Quickr Wiki that you can both consume and contribute to.
- The infocenter has both the Java 8.1 and Domino 8.2 documentation.
