Remixing how we use the Open Source desktop
by Jono Bacon
To understand how to design for proper integration, you need to first explore what people actually use their computers for. Aside from recreational use, the majority of businesses users, and those who actually work on their computers all utilise them within the concept of a project. Within this context, you find users who mentally hook together different applications with the intention of satisfying criteria to achieve a project or goal. This can be demonstrated with a simple use case.
Imagine that John Smith works as a consultant. John needs to interact with a variety of software tools:
- Customer Relationship Management (CRM) system
- Email client
- Private and public shared calendar
- PDA that is synced to the calendar
- Office suite
This is the way that John will typically bring these tools together when working on a project:
- First John speaks to the client on the phone and then manually logs the client and call in the CRM and logs a meeting on his PDA. He then syncs his PDA to his calendar in Evolution. He also adds the client contact details to the PDA and syncs those with the main address database in the office.
- Next, John needs to fill in some forms for the paperwork. He gets the CRM details for the client and creates a document in OpenOffice.org. He meticulously copies the data over that he stored in the CRM and prints it out.
- To prepare for the meeting, John wants to meet with his colleagues to discuss some aspects of the job. He discusses some things with one colleague over the water dispenser, but another is working from home. He cannot see him in Gaim, so he sends him an email and they have a lengthy (in time) email conversation.
- John now cuts and pastes the discussion from the emails into the CRM to better prepare for the meeting.
- John tries to contact the client to confirm the meeting but cannot get through. The client calls up on John's office VoIP phone and the phone emails him the answermachine message. John listens to the message and copies the details into the CRM manually.
- The meeting happens and John makes notes on his PDA which are then copied manually into the CRM as well as some other emails with the client.
This use case is a typical example of a number of different systems working together on the same project but not actually integrating. The result of this lack of integration is that there is a lot of manually copying and pasting between different systems, particularly into the CRM; a system that most people find difficult to keep updated.
In reality, the above use case is not actually realistic. In our busy working lives, it is difficult and practically impossible to make use of all of these systems and keep them up to data manually. Each of these systems relies on John remembering to update them with the right information, and as anyone who works in a busy office will know, it is far too easy to get sidetracked by fellow staff members, other projects, websites, other emails, other IM conversations and lets not forget the surprise visitors who want to bend your ear for an hour or so.
There is clearly a problem here. Most of us will use a variety of software tools in one way or another to achieve a combined goal, but these tools cannot talk to each other effectively - they cannot integrate, and this wastes both time and effort. The source of the problem is that the desktop integrates together at a software level, but not a task level. Integrating these applications does not just mean sharing data between them, but it also means pro-actively adjusting the user experience of these tools in favor of a project.
The solution to many of these problems is to adjust the desktop experience so that it supports Projects at the base level. This would involve creating a simple to use Project Manager tool and including support in a range of other applications to automatically update and integrate with this tool. You can think of the Project Manager tool as a means to simply help different tools to talk to each other and to provide a central place in which the Project is managed. This Project Manager tool would also provide a clear summary of the project, who is working on what and provide access to all files relevant to the project; all of this being useful for reporting an auditing procedures.
Imagine this case study for John's situation:
- John speaks to the client on the phone about the work that he client wants doing.
- John now logs into the Project tool on his computer and creates a new project. He adds some details about the project in the Meeting box he selects the date for the first meeting. When he saves the project, the software will update Evolution with the meeting which in turns syncs with his PDA. The information about the project is also added to the CRM and the call and meeting are added as CRM activities. The software also generates an OpenOffice.org document with the relevant information added and adds the document to the project file store.
- John now decides that he is going to work on the project. In the top right hand side of his GNOME desktop he clicks on the project icon and a drop down list of his current projects are displayed. He selects the right project and now his desktop has been adjusted to reflect those projects - the right bookmarks are loaded in Firefox, the right contacts (and only the right contacts) appear in Gaim, emails from the right people appear in Evolution and Nautilus is familiar with the files involved in the project, accessible from the My Project Files icon on the desktop.
- John clicks on My Project Files and clicks on the OpenOffice.org document to update some of the details. When he saves the file, this action is stored in the CRM and the updates are possibly mailed to his colleagues automatically with a list of the changes.
- John checks his mail in Evolution and sees that he has received an email from the client. When the mail was received by Evolution, it automatically noted it in the CRM and a message pops up hovering over the project icon informing that a new project related email has been received.
- John decides to send a new email and selects on the people involved in the project from his now more limited address book (the address book is more limited when he selects to the project to find contacts quicker).
- As John is working on some parts of the project, he sees interesting web pages in Firefox that he bookmarks in the project. As he works, the client pops up in Gaim. Gaim has automatically adjusted itself to only include buddies within the current project so John does not get distracted and ignore Gaim totally. He has the conversation and then the log of the conversation is added to the CRM automatically.
- John goes to the meeting, makes notes on his PDA and get back and syncs the PDA. The notes are automatically added to the CRM and if a second meeting was arranged, Evolution would be updated with new time and the CRM would be notified of the new meeting as well as any colleagues that are required (Evolution would mail them).
- At the end of the week John is working on his timesheets and most of them have been automatically filled in by the Project Manager tool with detailed times of then he was working on all these parts of the project. He only needs to fill in the gaps.
- As John finishes the project, he is asked by his boss for report. He clicks a single button in the Project Manager and a PDF report is generated automatically for him with a detailed breakdown of what he has worked on, how much staff labor was involved, the labor costs (calculated by referencing the time spent on the project and John's average hourly wage), the goals achieved, the steps involved and more. A few other colleagues have asked to see the report so John can add them to the report mail-out or generate an online report that is automatically uploaded and then mails interested parties of the report.
With this use case, you can see how much of the leg work is automated by the systems. This case specifically improves on the old one in that the logging of each event in the CRM is automated by the software and John does not need to remember to log in and make the updates himself. In addition to this, each application within his desktop is adjusted to reflect the resources that are part of the current project. This is particularly useful when it comes to communication.
Better communication with the integrated desktop
One of the problems with communications tools is that they are notorious for sidetracking you. Possibly the largest offender is an IM client such as Gaim. When you log on to IM, it is likely that you are looking to speak to someone in particular, or you may be specifically interested in speaking to a particular group of people. As an example, I have a number of friends who work in IT and a number of friends who are in bands. When I am mentally in work mode and I am working on a project, I often log onto IM to ask a particular question to an IT buddy. Typically when I log on, one of the music buddies will pop up to chat to me and I feel guilty if I just ignore them. I have a short conversation and typically get sidetracked by the discussion. This not only wastes time, but it also affects my concentration. The result of this is that I tend to leave IM switched off unless I am specifically looking to be distracted or speak to non-work friends. It seems such a shame to waste an entire medium of communication just because of distractions from the wrong people I seek to use the tool to communicate with. Oh, and switching your status to busy does not alleviate this problem...
In an ideal world, Gaim (or any other IM client) will check the contacts in the current project and only advertise my online status to them and their online status to me. This will restrict IM to a tool that is useful for the project in hand, and my contacts are likely to talk to me on matters that are relevant. Some of you may think, well just organise your buddies into groups and select the right group. The problem with this is the same old issue affecting the current desktop - I have to make the effort to adjust it. No. The tool should make the effort to adjust it. I see no reason why I should indicate to five or six tools that I am working on the same project. I should indicate my desire to work on the project once and then the Project Manager updates everything else.
Can it happen?
Now, all of this is being discussed in a perfect world where this can all be coded and works effectively. Can it actually happen? Yes, I do believe it can.
I am specifically interested in making all of this work in GNOME. There are a few reasons for this. Firstly, the GNOME project have a fairly strong integration and control over a number of different applications. I don't mean this so much from a technical perspective, but more from a social perspective. If you read Planet GNOME or keep up with the GNOME websites, it seems that the GNOME developers seem far more in touch with each other and better integrated. This is largely due to the existence of a lot of GNOME hackers in companies such as Red Hat and Novell, but also the fact that the GNOME hackers seem to discuss and actually produce software efficiently in tight groups. Some may see this as an old-boys-club, but I think it is just good hackers working with other good hackers.
Another reason why this can happen in GNOME is because you can only make this work at an architectural level and not at an application level. If the Gaim developers buy into the idea but other tools don't, nothing will happen. To really make this work, the foundation GNOME architecture will need to incorporate a means to talk to other project-aware applications in different ways. This will require data-aware widgets becoming project-aware, the GNOME file picker including the project in the GNOME VFS, nautilus remembering file location histories for the project, recent-files menus remembering recent project files, evolution-data-server supporting sharing of contacts all over the place and more.
A final reason why I think it can happen with GNOME is that I believe the GNOME developers are real innovators. Some of the work going on in GNOME has been quite ground breaking with work such as Beagle, Project Utopia, Sabayon, Tomboy, custom widgets in F-Spot, file picker improvements and the GNOME VFS, luminosity eye-candy, support for SVG and more. In addition to this, the GNOME project have really hooked into some of the freedesktop.org technologies such as HAL, DBUS, XGL and more. Another point is that I was quite pleased to see the GNOME developers had the balls to bravely include the spatial nautilus in GNOME. A decision that caused much controversy but also spoke legions in terms of dedication to usability.
I think that that reasonably, the technology is available to make much of this happen. A lot of the challenges can be solved with DBUS, but I also think that a deep integration in GNOME of many of these project driven principles can work. Even then, the concept of the project does not need to be the only limiting factor. In addition to a Project, you may want to incorporate other modes for integrating applications together. I am not sure what they are right now, but I am sure they can be discussed extensively on mailing lists in further detail.
I should clarify that I am neither a usability engineer or a GNOME developer, but I have a strong interest in both usability and GNOME development. I am a consultant who works every day to help businesses, charities, schools and consumers get the most out of Open Source. The problems that I mention in this article about the lack of integration are real, tangible and measurable problems that I myself, my colleagues and my clients face every day. Duplication of effort typically results in no effort with some systems, and then this effort must all be reproduced in bulk when a project is tied up. With all the approximate applications in place (email, IM, productivity, CRM etc.), there is a real potential to make them work together more effectively and provide a truly innovative reason to move to the Linux desktop. There are many other factors to discuss in the design of this integrated desktop, and I am certainly not the only person to discuss this idea, but hopefully this article can contribute to the design and the discussion.
Do you think it can work? How can it be better improved? Write your views below...
"Project" isn't the root level object...
..."context" is. A context is made up of (among other things, add more...) location, time and date, capabilities/affordances, and -- wait for it -- purpose.
I Agree -- Almost
While your concept is one that we do need to look toward, I disagree with the idea that it takes a GUI such as Gnome, or even KDE (my choice) to tie this together. Would not a well developed database with database aware applications accomplish much the same objective.