IBM Project Vulcan is a concept for the future of collaboration, including the future of Lotus Notes. IBM Project Vulcan is not a brand-new effort. It builds on the existing capabilities, and represents the future versions of, the IBM Lotus product portfolio — including Notes. One of its key themes is social analytics and business analytics combined and applied to industry-specific scenarios — making collaboration more focused and relevant. The vision of Project Vulcan intends to deliver collaboration across company boundaries; make it easy to deploy the technology; and include developer-friendly services and APIs.
Joe Russo over on Synchronous just posted a writ-up about how email is supported in Lotus Connections for communicating with members of a community …
Today in Connections Communities, there’s this button “Mail Community” that let’s someone send a direct email to people in the community and it has a few aspects to it, that you may or may not be aware of … and why they are there. … There is a different UI experience in connections for things like notifications … where we’ve adopted a UI that presents a list of people, by display name, with checkboxes alongside
So now the question is, should we drop the community mail design in favor of the more standard connections notification pattern? Also, as part of this question, I’d love to hear from you all about what, if any features from the community email form you make use of…like mailto link or expanding the To field, etc.
Read the entire post and add your requests in the comments section !
The debate rages on and on – is it better to have the best individual products or the best integrated capabilities ? These are rarely the same thing.
When it comes to collaboration, you typically don’t collaborate for collaboration sake. You need to get something done. I’s more important to focus on how seamless collaboration is to the tasks and processes you need to accomplish. It’s a waste of cycles to kept bouncing between your work and your collaboration tools.
Imagine you just received a document (email, proposal, white paper, etc) and there is an acronym you don’t recognize. There are two possibilities – you use a separate tool to look up the acronym or you click on the acronym and immediately see the expanded form. Assume you don’t find it. Now assume you right click on the document and see the recent edits and can directly ask the question of the person who inserted the acronym – use a text chat, click-to-call, etc. That’s much faster than getting the author’s name, looking them up in the directory and placing a call from your desk phone.
In this example, “click-to-call” may not has all the functions of your desk phone but it sure was quick and easy and you stayed within the context of your work.
There is another dimension to consider – different people work differently and have different tools. Do you mandate a narrow set of tools and force everyone to use those and only those tools. What if you don’t command everyone and you want to allow people the flexibility to be as productive as they possibly can be ? This requires that tools integrate with flexibility. The best plan to avoid getting painted into a corner is to look for “open, simple interfaces”. “Open interfaces” mean you get to decide where, when, and how you integrate capabilities. “Simple interfaces” mean you dedicate less resource to performing integration and more resource getting work done.
So, how do you proceed ? Ask these questions …
What are the task and processes your staff must do often ?
What are some examples where they need to reach out to systems, people, and support tools while performing their duties ?
What collaboration capabilities would help people reach out ?
Do those tools provide open, simple interfaces so they integrate with *your* processes and tasks ?
Networked collaboration capabilities continue to expand and the end is nowhere near. Whether is is email, instant messaging, video, VoIP, or full 3D virtual worlds, there is something for any situation and budget. However, just because it exists, does not mean it’s right for you or "right for you now". Your adoption plan should look at your needs and your ability to deploy capabilities, train end users, and provide support. This is a good case study for "craw first, then walk, then run".
Collaboration capabilities and needs tend to evolve. The difference is that, unlike Darwin’s model where evolution implies a refinement and superiority over the prior generation, the evolution of collaboration capabilities tend to address different needs and thus the prior generation of capabilities remains valid. Here are some examples:
email – send and receive messages
instant messaging – better than email when the messages are not so long and the need for replies is more "now"
chat rooms – better than instant messaging when there are multiple people and they may not all be active at the same time
forums – better than email and chat rooms for large communities of interest in an on-going Q&A and where interactive "now" is not as important as retaining the group knowledge and support search
peer-2-peer file sharing – better than email when the content is big
file repositories – better than peer-2-peer file sharing when the content is needed by multiple people at different times
application sharing – better than file repositories when the need if for multiple people to see a file at the same time
voice – better than instant messaging when high speed interactivity is important
…
The list can go on and on. More important, is that the different methods of collaboration have different value – and to some extent different priorities of their characteristics – to different communities.
The best method of acquiring collaboration technology is to start small. While it may be possible to get everything at once, the results may over burden one or all of your resources to "deploy capabilities, train end users, and provide support". The better approach is to plan for integration.
email should be extensible to allow presence and awareness letting you switch to instant messaging
instant messaging should allow you to switch to peer-2-peer and small group VoIP
chat rooms should integrate with file repositories
forums should support search and content migration to wikis
user "business cards" (aka rich directory information) should be flexible enough to link to blogs, find users’ shared files folders, provide presence and awareness, launch text messaging, VoIP, and email
collaboration artifacts should be easy to find – search, tagging, link, etc.
…
Here again, different priorities will prevail for different communities of consumers.
If you are considering adding new collaboration capabilities, then a good place to start is with "a small group of willing participants" and "a pilot of the capability". This will give you the opportunity to learn if you are ready to "deploy capabilities, train end users, and provide support".
