I would like to generate some feedback on why more partners are not working with Lotus Quickr with their customers. This is an open-ended thread - post whatever you want. Just be constructive. No pure complaints please - you need to suggest ideas on how to fix it.
I will reserve my thoughts on this until Monday. This feedback is not just for me or the Lotus bubble, but will be used for the DomDoc Redbook and the feedback will go directly to the Lotus Quickr team. No promises they do anything about it, but I have an opportunity to deliver the message directly.
John D. HeadCONSULTANT | RAINMAKER | COLLABORATION & INTEGRATION EXPERT
John,
First my comments are for Domino version of Quickr and from the point of view as an ISV. I would like to do more with Quickr, but for us there is still a few missing pieces. Unless it came out recently, it would be great if there is a set of APIs that we can access and program from a Domino application and from other applications. This would allow me to drive the customer towards Quickr.
Also I am still waiting for Quickr connectors for the Linux client and Quickr (Domino) on Linux. This would help in terms of licenses. Linux with Quickr I have discussed many times with other Business Partners and IBM so I will not expand on it.
Related to the API request, we need more documentation on the internals of Quickr so that we can customize its functionality. A Quickr Connector API would be nice.
The Quickr interface still needs significant improvement. It is still the old Quickplace interface with some Web 2.0 stuff. It is not intuitive. I bring this up because I just got a company on it and they did not like it because of the interface.
I hope this helped John.
I would love to do more with Quickr as an ISV. It just hasn't happened, and the principal reason is that our sales/marketing people haven't run into enough situations where not having Quickr support in our product is a deal-breaker. I'd love to be able to approach it from the other direction and be in a position to have Quickr support as competitive advantage that helps us close more business with customers who may not have it as an immediate requirement but want to be sure that their vendor will be read when they are. Unfortunately, it's not easy to get something like that to happen in my organization.
John, I tried Quickr - Installer completely destroyed client's Domino server. had to get IBM to rescue me. For SMBs would be great to have Quickr svcs on same box as Domino. (I hope that IBM has now fixed the documentation and installer to warn/prevent user from installing on an existing Domino Box.)
Otherwise, I like the idea and will not hesitate to recommend Quickr to clients, but with the caveat above.
In response to Eric, we build servers with Quickr built-in preconfigured. Drop me a note. See mycubus.com. We could even OEM them for you with your solution. Quickr installation could definitely use some enhancements but then why would anyone need us :-).
As you can tell, and many know, I not only support and work with Quickr/Quickplace but Domino.Doc/Document Manager as well and have been since they were in BETA over 10 years ago.
We can cover any project on these topics in the US, Europe, Austrailia, South America and are happy to help other BPs who can't or don't want to get involved in it.
Check out the blog post "The Lotus Community is Lazy" { Link } there are a few comments there which might be of interest. All the best, Chris.
We did a Quickr test installation at one of our healthcare client's sites. One focus of the test was the Notes plugin. When sending mails users chose to have the attachments put in a Quickr place and send a link instead they "discovered" that everybody with access to that Quickr place was able to see the attachment. This was unacceptable to them because the attachments are confidential in most cases (patient data). This is in my POV the biggest shortcoming of Quickr and it makes it hard to sell at least here in Germany.
To address this, I would like to see the Quickr plugin send a link to all recipients who are registered in Quickr and have access to the place the attachment(s) is being stored in. All other users should get the attachment. In addition to that, the attachment(s) in Quickr should only be visible to the recipients.
Last time I looked at Quickr, and it was a about 6-8 months ago, there were not enough ways to access customisation points. Specifically something like the Dom.Doc Doc events that would fire irrespective of interface, ability to create/manipulate custom document profiles/meta data collection etc.
Some of these may now be in the product but they made it difficult to port the many customisations I have already done for customers onto the Quickr platform.
I also think that Quickr like Quickplace before it is an unpleasant mix of an "pure" web/html solution squeezed into an .nsf container, and it does not leverage enough of the Domino design functionality.
Maybe re-engineering on X-pages will fix this....
Neil - they are not reengineering on XPages. They are not rebuilding Quickr on XPages. At Lotusphere they talked about Quickr consuming XPages applications you build in a future release. Now that can mean many things, but it does not mean a complete rewrite of the product.
We do a lot of Quickr Domino implementations. A whole lot. The real issue Quickr has is that it is really 3 products in one and as such is hard to describe. Yes, "team collaboration", but come on.
When installed as a pure file sharing application (that is very, very firewall friendly) it is very successful. For anything else it is a bit too hard to customize as is. I'd also like to see it use xPages too.
Also the lack of connectors is an issue. OpenOffice would help, as would other applications (CAD for exmaple would be great).
The other obvious oversight is that sending links to an external email address is nothing short of a nightmare. There really should be a setting to allow "send links to internal domains and attachments to external addresess" or similar. That would help an awful lot.
Lastly (hopefully) is searching. When I'm using the connector then I really don't want to open a browser to search the quickr content. There really has to be a better way.
The use of ActiveX is a problem as it restricts which browsers you can use Quickr on.