r2 - 25 Mar 2005 - 13:33:36 - MimiYinYou are here: OSAF >  Journal Web  >  MimiYin > InertiaOfIWontUseItIfIHaveToOpenAnotherWindow
It seems like the number one barrier to entry when it comes to new software adoption is: If I have go to another window to use, I don't need it that badly.

Case in point, many Outlook users won't use the Tasks, Journal or even Calendar portions of the application simply because it requires switching views. Some users won't even use the OOTB "For follow-up" folder to viewed flagged emails because that too would require switching away from the Inbox. The pain of clicking around is too high when it's unclear to users what benefit they will get out of the pain. What's the point if I can keep it in my head or my Inbox? This is especially true if clicking around takes you to new UIs that are completely different from where you came from: Creating both a cognitive and motor coordination burden for users.

The inertia of not wanting to switch views means that any task, calendaring or shared project management system that isn't tightly integrated inside the user's existing world will ultimately fail for the majority of users, rendering the system "untrustworthy" in David Allen terms. Why bother putting things into a system if you don't trust yourself to consistently use it? (That's largely why web services like flickr and del.icio.us will serve primarily as sources of entertainment for a while to come...because there are yet another place in the wide world for users to expend a lot of energy inputting data.)

So how do we get people to use all parts of the PIM without feeling like they're leaving their Inbox? Squeeze everything onto one screen? Simply a bad idea.

Instead, we're focusing on lowering the bar to interacting with different parts of the PIM with:

A third, largely heretofore unrecognized way in which we're hoping to beat user intertia wrt using different software is by integrating "shared" information into the user's PIM. As in, the user does not have to go access data in the sky from a web browser.

We've talked about this mostly in the context of shared calendaring where we will provide users the same easy access to shared calendars that they have to their own calendars (ie. overlays a la Apple iCal).

However, there is a huge untapped space in the world of "integrated, lighweight, collaborative project management." Most collaborative project management tools are accessed via the web (ie. wikis, basecampe, sharepoint) and therefore segregated from daily personal communications about the very projects that are supposedly being documented on the web in the shared project management tool. Most are too heavyweight. The closest thing to an integrated (into your PIM), lightweight project management tool might be public folders in Outlook or Project Center in Entourage. But public folders in Outlook don't integrate emails, tasks and calendars into a single project. And Project Center in Entourage is yet a 6th application area in the app and requires completely separate setup and effort from the other application areas.

In Chandler, the biggest benefit of our orthogonal sidebar design is that with no extra effort, users end up with tidy little project folders in their sidebar that contain all relevant email, tasks and calendar (even though users can treat sidebar collections as if they were unique to a particular application area). This is because all Chandler collections can contain items of various kinds and the same Chandler collections stretch across all areas of the app: Mail, Tasks, Calendar. This currently already works in .5. Sharing these tidy little project folders also already works in .5. So right now, any small working group can already share project-based collections of emails and notes (as a substitue for wiki documents), tasks and calendars with project milestone due dates and meetings complete with meeting agendas and meeting notes (conveniently attached to the meeting on the calendar).

So we basically already have a lightweight project manager. What's missing?

  • A baseline of visual polish, which we're focusing on for .6.
  • Get the sidebar and summary table view to be minimally comprehensible.

Shared triage. The reality is, most people don't use electronic task lists for themselves. How do we get them to use it as a group? The theory is that most people don't use electronic task lists because:

  1. They have to switch views or apps to get to their task app to enter and review tasks (simpler just to keep it all in email)
  2. It's feels like too much work and redundant work to enter items. Especially when it's simply to cut and paste text from an email they received.
  3. Even if they were to bother to enter all of their tasks, they would just end up with a huge list of hundreds of undifferentiated items, which feels: Not helpful. If they separate their lists into daily todo lists, they can't see their tasks as part of a larger project plans. If they separate these lists into different projects, then it becomes hard to look at a complete list of "current tasks".

Some task lists provide a way to assign priority and/or a variety of dates: start date, alarm date, due date as a way to differentiate between tasks. But priority is hard to assign. Whenever software asks me to prioritize something, I always think to myself, relative to what? But very few task applications allow users to prioritize tasks by explicitly ordering them relative to each other. Even if the right prioritization UI were to come along, it's unclear that users care to draw such fine distinctions. Most of the time, they simply want a way to highlight the really important or really urgent tasks, so they won't forget. Sometimes they'll do that by simply putting it on the calendar with an alarm. Also just because something is high priority doesn't necessarily mean a user wants to see at the top of the list for a variety of reasons: I can't act on it right now. It's not due for 4 months. I don't know what the next step is.

David Allen proposes maintaining a list of project plans and then moving actionable items to context based lists: @calls, @home, @computer, @hardware store, etc...However, all of this amounts to a lot of of lists, a lot of work and a lot of clicking around. Which brings us back to the inertia problem.

Therefore, what if there were a simple way for a small team to share project task lists with the following features:

  • Triage: Organize tasks by Now tasks, Later tasks and Done tasks (a tickler feature to automatically make a Later task into a new Now task would be an added bonus)
  • Put certain tasks on the calendar (ie. due dates, milestone dates) with reminders (feature already exists)
  • Assign and notify the assignee of the task by sending it them via Email. Send it to yourself if you're the assignee and CC: your manager (feature already exists).

  • This plus a project calendar that has all relevant meetings with meeting agendas and meeting notes... (feature already exists)
  • Plus a way to share general content via email and notes... (feature already exists)
  • And the whole thing is completely integrated into your PIM (just another collection in the sidebar) so that adding content to the shared project is as easy as filing an email into a folder today...

is by our estimates, a solid foundation for a lightweight shared project management tool.

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r2 < r1 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.