Look, ma. I’m in a book!


In THIS book

I was fortunate enough to be a reviewer of Packt’s new book in the IBM’s series: Lotus Quickr 8.5 for Domino Administration.


It’s not the software, it’s how you use it

What drives collaboration?  It is not the latest collaboration software, offering eye-popping features and kick-ass integration.  It is the desire of teams to collaborate.  Like the proverbial horse, you can lead a team to collaboration, but you can’t make them collaborate.

On of my projects now I’m working with an amazing team of great software developers.  The team is small, there are 6 of us.  The velocity of the project is great with 2-week sprints delivering minimally viable product at each iteration.  The team simply must collaborate in order to survive and to keep on top of the project.

Before I joined the project, the team chose Basecamp from 37signals.  Basecamp wouldn’t have been my first choice.  Having used Quickr, Connections, SharePoint, I find Basecamp somewhat primitive, lacking features that I’m used to with other packages.  But it is not the strengths or weaknesses of Basecamp that determine my teams’ ability to collaborate.  It is the team’s desire to collaborate that drives collaboration.

All team members religiously engage in discussions, posting updates and tracking their progress on Basecamp.  Basecamp has also become a vehicle for outbound communication from the team to other stakeholders in the organization.  When the project will be done, all of the project’s history and all of its intellectual capital will be in Basecamp.

It is a dream come true for many organizations trying to foster internal collaboration, trying to harvest the wealth of knowledge locked in employees’ heads and often lost with them.  It is a problem that organizations try to solve with this or that latest software.  But if there’s no desire to share, if collaboration is not being fostered, then no amount of bells and whistles can fix it.



Quickr J2EE thoughts

The other day I had a chance to take a deeper than usual dive into the J2EE version of Quickr.  Previously, all of my advanced level experience with Quickr was in the Domino realm.  Working with the J2EE version, aside from the obvious interface differences, the difference in the feature set quickly becomes obvious.

In short, the current version of QuickrJ appears to be more powerful in core document management features: versioning, workflow, access control.  But it severely lacks in team room features.  Until the 2 versions — the Domino version and the Java version — of Quickr merge, if you’re looking for pure document management, the J2EE version is the way to go.  But if you’re looking for powerful team rooms, the Domino version is the winner.

In the J version, I liked how versioning can be enabled on standard forms.  By default, it is implicit, but you can make it explicit with a click of a button.  Same applies to workflow.  You don’t have create custom forms to handle versioning.

I loved the whole portlet concept, being able to add various portlets to your pages, much like the Connections interface allows you to add portlets to your community.  But there are odd limitations on the quantity of some portlets that are allowed in a place.  For example, you can have multiple discussion forum portlets, but only 1 library.  I was working on a place that we wanted to break up into multiple document libraries based on a specific area.  In the Domino version, I would’ve created separate rooms for each area.  The Java version didn’t give me this functionality.  I was able to get around this limitation and, after discussing the needs and the options with the business users, came up with a rather elegant solution that satisfied their requirements; but having rooms would’ve been nice.

The Java version also had more features and better interface for some of the admin features.  It’s nice to be able to manage places and delete a place with a click of a button as opposed to go through the insane steps required by the Domino version.  The administration side of QuickrJ is clearly based on that of Websphere and is much more powerful.  It feels like a real administration interface, specially when compared to the Domino version, which always felt, well, a bit childish to me.

The annoying thing about QuickrJ is how very context sensitive some of the management and customization links are: you have to follow very specific steps to get to some of the links. For example, clicking on View Members lets you do just that — VIEW members. There’s no way to add new members from that page.  You have to go through a completely different and somewhat obscure set of links to get to the page that allows you to manage members.

I know that the next release of Quickr is bringing these 2 versions closer together.  I just wish they would’ve become identical in the feature set, so that customers didn’t have to go through a decision process when selecting which version to deploy.

Ephox EditLive for Quickr is in Beta

For the past few months we at PSC have been working with Ephox on a Quickr for Domino version of their EditLive editor. It was a fascinating project that allowed our development team to take a really deep dive into the world of Quickr for Domino. Talk about JavaScript galore…

This week the final result of our implementation effort went into Beta. The EditLive editor replaces the standard out-of-the-box Quickr rich-text editor powered by Dojo and offers editing features that are not otherwise available in Quickr.

For more information on how and where EditLive works inside of Quickr see this post on John Head’s blog.

If you are a Quickr for Domino user. If you would like to give your users text-editing features beyond what Quick provides out-of-the-box. If you’re interested in being a part of the beta program, contact Ephox directly.

If you decide to join the beta program, I would love to hear your feedback on EditLive and how it works inside of Quickr.