We’ve heard from many corners that starting up Chandler is an intimidating experience, the app feels heavy, over-bloated with features. It’s taken me a long time to ‘get’ what that means. Here’s one explanation: (As usual, it has to do with context and history.)

When Chandler began, it was going to be the alpha and the omega of information management. It was going to swallow traditional PIM functionality wholesale (Email, Notes, Tasks, Calendar, Contacts) and extend to manage non-PIM data as well: Documents, Media, URLs, etc.

The theory was: The reason why information management sucks is due to a lack of integration. Integration in terms of data types and integrations in terms of workflow.

In the meantime, the world around us changed. Instead of a trend towards more ‘integrated’ solutions, people are adopting a wider range of tools and workflows are knit together via a wide variety of interoperation techniques.

What does this mean for Chandler? Do we still have a place in this new world?

I think so. I think we’ve actually been evolving with the rest of the world. We have not been working in a vacuum for the last 2 years. Instead, we’ve dramatically re-framed the way in which Chandler integrates. Chandler is no longer about replacing your email client, enterprise email, calendaring and content management systems, wiki, project manager, IM, news reader…

Instead, Chandler is meant to live in the middle of all these tools as a way to pull all the disparate bits and pieces of information we receive out-of-context, into a contextualized, personal and shared ’source of truth’.

That being said, the user interface we have today is misleading. It contains vestiges of the ‘old’ way of thinking about integration which has the potential to scare new users away, both because there is provokes a gut-level sense that the app is big and complicated and that you can’t get started without moving your entire world into Chandler.

For example, there is an out-sized emphasis on email functionality, left over from the days when we were adamant about being a complete PIM solution. In reality, email in Chandler today plays an important, but supporting role. We talk about it as a means of:

1. Outreach: A way to get information out of the ‘Chandler’ eco-system into other people’s Inboxes; and as a

2. Bridge: A way for Chandler users to get information from their email clients into Chandler.

So, how do we proceed to lighten-up the app so that it’s a more accurate reflection of what Chandler is meant to do? Here are some ideas:

1. Remove the Reply, Reply All, Forward buttons from the Toolbar; and
   

2. Add a Reply/Forward menu item to the Item menu

3. Remove the the ‘New’ button from the Toolbar and really focus on the quick item entry bar as the way to create new items in Chandler.

4. Rename the Mail application area Messages so that it’s more of a ‘Message Center’, a place where you can see the messages you sent/received from Chandler (not un-like Inboxes for social networking sites like Facebook or Linked In), and less of a “Mail Application”.

I will be thinking about this in the coming weeks and am interested in other perspectives. See discussion on the list: http://lists.osafoundation.org/pipermail/design/2007-December/008035.html

Robert Scoble interviewed us for 51 minutes. Still, I realized that there were significant things I had left out while caught in the headlights of the camera.

Here’s a brief description of some of the neat features in the Mini-Calendar and Preview Pane on Chandler Desktop.

More egregiously however, when showing the Triage Table, I failed to showcase the considerable ‘Brain’ that decides what metadata to show when for each item of information.

The idea of having a heterogeneous view of data is not new. In the ‘real’ world, our ‘collections’ are more often heterogeneous than not. Just open up your desk drawer and take a look.

It’s a simple, accessible idea until you try to normalize that data by cramming it into a table where every row of information needs to conform to the same 5 columns of attributes.

How do you fit

• Notes that have creators and editors and created on and last edited dates; in the same table as
• Messages that have a sender, recipients, and date sent;
• Tasks that have owners, reminder dates and due dates; with
• Events that have organizers, invitees and start dates and end dates.

The few places I’ve seen this done, normalization was achieved by whittling down what’s displayed to the lowest common denominator: Titles and Date Last Edited. This approach generally yields an information-poor display of data that is not very useful.

We achieved normalization without losing data by adding a layer of abstraction.

We grouped all of the ‘Who’ attributes into a singled column

• Created / Edited by
• To / From / Updated by

and all of the ‘When’ (Date) attributes into a single column:

• Created /Edited on
• Sent / Received on
• Starts on
• Remind on

The problem is, most Chandler items have all of these attributes so we needed a way to decide which attribute to show under what circumstances. This is a tricky path to negotiate and we’re continually refining our heuristics.

What is ‘most important’ is subjective, but there are a few rules that we believe hit a fair majority of use cases:

• Message items always display From/To in the Who column depending on whether the message is Inbound or Outbound.
• The Who column always displays ‘Edited by’ when an item has been modified by a fellow subscriber.
• Depending on ‘the current time’ we figure out the ‘Next Important Date’ is to display in the Date column. For example, event dates usually trump all other dates, but if an event has past but there’s still an alarm set for next Tuesday, we display the alarm date.

Either way, the bet we’re making is that it’s better to display something even if it’s the wrong thing some of the time than to display nothing at all.

(My Space + Facebook are heretofore referred to as My Face.)

Maybe not if My Face means the following to you:

1. Here’s me gone wild at happy hour after I got laid off.

2. Here’s a picture of my boss gone wild at Mardi Gras I found on the internet.

3. Gold text on silver background.

4. Blink tag.

5. Repeating zebra background that makes it impossible to read anything that isn’t blinking gold text on silver background.

6. Altar to Slash from Guns N’ Roses. So hhhot!

But if you step away from My Face and take a look at it in the abstract, the difference between My Face and ‘adult’ modes of communication (email, mailing lists, IM, SMS, blogs, feeds) essentially boils down to layout. My Face is full-on, full-boar, multi-channel communication with pictures, video, music all coming at you *at the same time, NOT a long scrolling page of text occasionally wrapped around embedded images and video.

Gen Y communication is concomitant. Even as your reading this long blog post, some of you are probably skimming up, down and around the page, reading in figure eights, trying to take in linear text all at once, as a picture.

How overwhelming, not to mention tacky. But the multi-channeled hodgepodge experience My Face provides is more true to life. Life in the ‘real’, physical world is a multi-media affair (an oftentimes tacky multi-media affair). But hanging out with friends on My Face is in some ways better (or at least more scalable) than hanging out with them in real-time / real-life because like email, IM and blogs, My Face is virtual and not bound by the limitations of time and space.

1. Location is not an issue.

2. Like email and IM, hanging out on My Face is an asynchronous activity. Unlike face-to-face interactions, leaving a friend hanging for a few seconds, minutes or even hours as you switch focus to engage with othes isn’t rude, it’s routine.

Nevertheless, like IM, the irreducible unit is still the friend, contact, person…so My Face isn’t as granular / flexible as email which comes in discrete units (messages) organized by topic (threads) addressed to an ever-changing cast of contacts.

But what we gain with the loss of granularity! My Face gives you a wholistic(ish) view into your friend’s comings and goings. The gestalt of your My Face companions are offered up on their pages. They’re open as a book, but unlike a book, they’re consumed with a 3 second glancing shot down the page (assuming it loads quickly enough).

It turns out that the very granularity that makes email an unparalleled productivity tool is also the very thing that is its undoing.

Instead of managing people we’re managing individual messages. Topic areas span dozens of emails and email threads. As we vigilantly stand over our Inboxes devouring every morsel that comes in, we lose sight of the big picture.

The fluidity with which individuals can be added and dropped from threads means that through the filter of our individual Inboxes, we are each touching a different part of the proverbial elephant.

So we’ve come full circle, can My Face be applied to the workplace, if so how? Even more interesting, could modeling My Face around the small work-group collaboration scenarios we’ve been focusing on make for a better My Face experience overall?

Courtesy of Philippe, this appeared on the Chandler Design mailing list a couple of weeks ago

Kids say e-mail is, like, soooo dead

Choice quotes:

“To hear the teen panelists tell it, that means e-mail will be strictly the domain of business dealings.”

“All of the panelists said that they’re constantly looking for the next, new thing to stay current with friends; and they often use different social networks and tools to keep up with different sets of people.”

“It’s a problem for teens–you’re like losing out on some of your friends if you choose just one,” he said.”

It’s fuddy-duddy email versus hip and cool Facebook / MySpace, or MyFace to be fair and brief.

The most common response to the latest pronouncements of email’s demise is that well, sure, IM and MyFace are great for hanging out, but teenagers don’t “actually need to do anything”, do they? Wait until the brutal multi-tasking reality of adulthood hits them, then they’ll be doing crazy things like emailing themselves to keep it together. Oh and by the way, My Space sure is ugly.

I’d like to take a moment and back away from the epic battle that is brewing between social networking and email and try to understand what we mean when we say email.

If you clicked on the link above, you’ll have noticed that the definitions are pretty generic. They essentially boil down to: Communicating text messages between people using computers.

But really when we talk about email we mean much more than that. Email is an experience, more specifically, email an experience mediated by the software we use Outlook, Apple Mail, Thunderbird. Gmail. Yahoo Mail. Hotmail…Pine.

What is unique about the email experience?

1. Email can be both point to point or broadcast and everything in between.
2. Email is asynchronous
3. Email is discrete, though we often wish it were more discreet.
4. However, individual email granules can link together and grow into discussion threads.
5. Most important, email comes to you, you don’t go to it. In other words, email is centralizing mechanism, a way to build a communication hub around yourself.

These 5 simple qualities of email combine and re-combine to explain our relatively recent explosion in productivity and the birth of the information worker.

In inexperienced or careless hands, email can be easily misused and abused to the point of becoming an impediment to productivity, a facilitator of misunderstanding resulting in all-around bad feeling and flame wars.

In malicious hands, email is a downright nuisance.

In skillful hands, email can be worked and manipulated to achieve symphonic heights of well-moderated discussion, informed decision-making, seamless collaboration and and parallel processing.

1. The ease with which you can move between point to point and broadcast communications means for any given conversation thread, private side conversations can be had, announcements can be made, new people can be looped in, existing participants can drop out.

2. Asynchronous communication de-couples dependencies between individuals, freeing us all to move forward on multiple fronts, on our own time.

3. Discrete messages means that email can be managed and processed as individual tasks, messages, appointments, etc. Discrete messages also means that email is easily archived and categorized for retrieval.

4. At the same time, email threads, organized around topics pave a natural pathway for follow-up, discussion and progression forward.

5. Centralization means that the Inbox has become the ’source of truth’ for people as far as what they need to know, what they need to keep on top of, what they need to follow up on, what they need to do.

Try that with IM or MyFace. For extra spellcheck fun, SMS it all the way.

If this is what we all understand as email, email is never going to die. Email has become a way of work and life for people. Email may die as a means of social interaction, please send all jokes, obscene pictures, youtube links and spontaneous outbursts via SMS or MyFace. I’m not so attached to existing email protocols or existing email information models. But the essential character of email as expressed above, as a way to “actually get things done…together” has only begun it’s trajectory towards predominance as the paradigm for how we make progress through work and life.

To spell it out, this is the vision of email we’ve been banking on for Chandler.

As enamored as I am with email, I am not making a Luddite’s case for rejecting newfangled modes of communication. My belief is that the text message and MyFace phenomenon serve different functions than email and are addenda to the ever-growing spectrum of internet-enabled social interactions. And I don’t believe that the divide between MyFace and email is teen / hangout, aka fun versus adult / business, aka boring.

There is a place for MyFace in the ‘business’ context, whatever that may mean and there is also a clear path for the web-facing side of Chandler Project to grow into an instantiation of MyFace in the ‘actually getting things done, together’ context. Follow-up blog post to come on that topic…

Mitchell Baker started a conversation about the future of email at Mozilla, looking for people to participate in “a new vision of mail”. OSAF should be engaging in this conversation, looking for ways to collaborate with Mozilla.

We’ve been looking at email as an important part of the Chandler project. Our approach has been to design applications around user problems and goals, in particular for informal groups working together. Our starting point was the observation that people use their Inbox as their task list. Another observation: calendaring is fundamental to task management; integration of messaging with calendaring makes a lot of sense with user workflows. We think that people will benefit from integrating email, tasks, calendar, contacts and other related information in one application, instead of having to do the work of patching together information across software tools, protocols and data formats. We’ve observed people collaborating on shared problems with email; we think there are huge gains to be made by converging personal communication and group collaboration. Email protocols are not the only route for communication; social networking and other messaging paradigms are other important areas to explore.

The Chandler team is currently working on a Preview release expected by the end of August: a usable version of the desktop application, rich web application, and server. We’ll also launch our free hosted service, Chandler Hub (an instance of Chandler Server).

Chandler Desktop will not be a full email client in the Preview release, but great email support is important to our full vision. Our research shows that many people sit in their email client all day as they try and manage their personal information and work on projects with others. Chandler uses email protocols for “sharing” items (calendar events, notes, tasks). It also has enough basic email functionality to allow users to get email into Chandler to manage a task list and calendar, but as a complement to an email client. Filling out Chandler to be a full email client is one of our options for a 1.0 release.

If you want more information about Chandler ideas, you can read the latest draft of our vision document or explore our wiki. A user guide and screencasts will be showing up as well. You can also experience Chandler in action by downloading the desktop, server, and/or creating a free account on Chandler Hub. Even though we haven’t released Preview yet, the recent desktop checkpoints are usable (modulo a few bugs) as is the previous release of the server (it doesn’t have the full Preview feature set). We use it internally to share group task lists and manage an office calendar.

The Chandler team is focused on getting our Preview release out, so we’re pretty busy through August. We anticipate getting interesting feedback from Preview and we’re going to let that guide our next steps.

I’m not yet sure where a collaboration with Mozilla would lead or what it would mean, but I think we’re looking at a similar problem space and it makes sense to see if we can forge a common path and combine resources. We offer a perspective on the problem, a server and a desktop application, and a team of people who are excited about doing creative things with personal information management (including email). Once we have Preview out, I intend for OSAF to participate actively in the conversation about email futures.

Mimi Yin is the interaction designer for OSAF where she designs the visual interface for Chandler. In March she will be participating in three different forums talking about issues that drive user interface design for Chandler.

9 March 2006, O’Reilly Emerging Technology Conference, San Diego., Personal Information Architecture and Chandler.

14 March 2006, The San Francisco Bay Area Chapter of ACM SIGCHI 7:30-9:30 pm. Getting Things Done: Technology and Practice.

27 March 2006, 7th Information Architecture Summit, Vancouver, BC., Tagging and Beyond: Personal, Social and Collaborative Information Architecture

A few weeks ago, we had some sprints for the OSAF staff. These were kind of blue sky sprints and people worked on pretty much whatever they felt like (if you are looking for cool project ideas related to Chandler, there are a bunch of those there as well).

Morgen had worked up a simple XML-RPC server which allowed him to build an OS X Dashboard widget that could get information out of Chandler. That, discussions we’ve had about building a simple command line interface into Chandler, and the KGTD Quicksilver Action were the inspiration for a quick hack.

The KGTD Quicksilver action allows you to use Quicksilver’s text entry facilities to dump ideas or reminders or whatever into KGTD right from Quicksilver. It provides a quick, unobtrusive mechanism for collecting stuff that you need to get out of your head and into your Getting Things Done (GTD) system.

What I did was to do a similar thing, but instead of sending the text to KGTD, I send the text to Chandler via XML-RPC. And instead of sending just a piece of text, I implemented a very stupid command line interface to Chandler. The XML-RPC servlet and the command line processor are now checked into Chandler’s subversion repository, and the QuickSilver AppleScript is checked into my OSAF sandbox: http://svn.osafoundation.org/sandbox/twl/applescripts/ToChandler.scpt. The script ended up being very simple, because AppleScript has built in support for XML-RPC handling. In fact, the code is so short, that I’ll just include it here, too.

-- Invoke applescript with text
-- 1. Activate QuickSilver and select this script.

– 2. Tab to the next and select Process Text..
– 3. Tab to the final pane and enter the command line text


using terms from application “Quicksilver”
    on process text ThisClipping
        tell application “http://localhost:1888/xmlrpc”
            set returnValue to call xmlrpc {method name:”commandline”, parameters:ThisClipping}
        end tell
    end process text
end using terms from

This is mostly a cool developer hack at the moment, but it gives you a taste of things you could do to integrate better with the native platform, as well as demonstrating the power of having some server functionality built into a desktop application. Of course, in an ideal OS X world, we’d have an AppleScript dictionary for Chandler and just use AppleScript (instead of XML-RPC) to do all this. But that’s probably a topic for another post.

I attended the FLOSS Extreme Usability Spring II in San Francisco last week.

In the words of the event organizers Blue Oxen and Aspiration:

“Extreme usability is a methodology that incorporates usability in a highly iterative and agile development process and that partners usability practitioners with programmers and users as co-designers and co-developers.”

Unfortunately, we were unable to take Chandler there as a project, but I had a great time working with the folks from CivicCRM. The event lived up to it’s name and was an extremely intense 3 days of whirlwind usability.

I’ve written up a short-ish report of the what our group accomplished at the sprint and the process we “invented” along the way.

The write-up in turn generated some thoughts as to the nature of usability and design, both in general and in practice. In particular, it got me thinking about how the vague and intangible nature of designing software for human beings is better suited to Extremely Rapid and Extremely Iterative design methods than the Somewhat Rapid and Somewhat Iterative approach that I’m used to.

Personal take on What is Extreme Usability?

Broader implications on What is Usability?

I also realized that while here at OSAF, we are priveleged to have such a close and ongoing working relationship between Development and Design, there are still many lessons to be learned about how to make that relationship even better.

I’m looking forward to trying out some of the techniques we experimented with at the sprint, in-house. Perhaps to iron out some of the existing design issues we have as well as to generate new ideas for areas of the UI that are still murky at best. I’d like to gain a better understanding of where Extreme Usability works very well and where it works, not so well.

Last Tuesday, I made a Design presentation to OSAF staff about the Chandler Virtuality: What it is today, the workflows it is designed to support and how it will mature into an extensible platform in the future.

The presentation slides can be found at: wiki.osafoundation.org/bin/view/Journal/VirtualityPresentationSlides

Our working definition of virtuality is: The quality of unity and robustness of the shared imagined space.

Goals of the presentation:

1. Provide the vision and motivation for Chandler’s design.

2. Establish a concrete, multi-dimensional user-centric conception of how information is stored and organized in Chandler both to provide context for development efforts in the 0.6 timeframe as well as to provide a focal point for development efforts moving forward in 0.7 and beyond.

3. In addition, we wanted to…

Demonstrate how Chandler’s virtuality will: - Feel familiar to users - Meet their organizational needs - Scale to deal with a lot of data - Make room for Chandler as an extensible platform

By: - Presenting research and user-based studies - Explaining the conceptual model behind the design - Demonstrating how the conceptual model is realized in the UI - Comparing and contrasting our design with alternatives

We intend to turn this presentation into a more coherent write-up and a series of screencasts. Hopefully, I will post something to the blog over the next few weeks.

In the meantime, some related reading if you’re interested can be found at:

http://shirky.com/writings/ontology_overrated.html (A long, but interesting blog posting comparing fixed hierarchical taxonomies and more free-form “items in a soup” organizational systems.)
PrefaceToHierarchyPapers
Journal/HierarchyPapers
Journal/HierarchyVersusFacetsVersusTags

Mimi

The “43 Folders” guy has written an article: The inbox makeover for the Mac audience, explaining a David Allen approach to dealing with e-mail — organizing by action instead of topic — the same way Chandler intends to facilitate e-mail processing.