Opera Mail

Brendan pointed me to the Opera Mail client which I promptly downloaded and played around with. It turns out that it makes for a very interesting case study in that it really highlights the challenges of designing a flexible and scalable sidebar in an attribute-centric world.

Opera is another iteration on attribute-centric organizational scheme where views of data are defined by some attribute: attribute value pair. (ie. All items From: June Bell). Gmail, Bloomba are two others examples of attribute-centric email clients. You can even count Outlook as another if you just used their Saved Search Folder functionality. Delicious and Flickr are two more examples outside of the email space.

Attribute-centric systems differ from traditional file systems and email clients in that they allow users to slice and dice data in flexible ways so that they can create different views onto the same set of data. This is as opposed to more traditional hierarchical, location-based organizational schemes where items or email messages in this case, can only live in one location in a tree of locations (or to use more common terminology: folder).

Such traditional file systems are modeled on real physical filing systems (such as the file cabinet) where a single item (ie. a document), due to the laws of physics, can only live in 1 folder, in 1 shelf, in 1 cabinet of 1 basement, of 1 building, of 1 city block....on 1 planet: earth. You could always make a xerox of that document and put it somewhere else, but it wouldn't really be the same item (ie. if you make corrections to one copy, it won't automatically correct the other copy).

In an attribute-centric system however, due to the magic of computers, which are virtual systems and therefore not always subject to the laws of physics, items (ie. a document) can have potentially an unlimited number of attributes (ie. Author:Dan, Date created: Yesterday, Last edited:Today, # of pages: 365, etc). Therefore, if you have attribute-based views, that single item could potentially show up in an unlimited number of views. (ie. Views as defined by the following attributes...Author:Dan, Date created: Yesterday, Last edited:Today, # of pages: 365, etc) What a coup.

Attribute-centric organization is essentially a-organizational. It says to give up on organizing your organization (ie. organizing folders into folders) or meta-organization, which is what hierarchies do. Instead, just "organize" the data itself with tags (labels) and leave it in a soup to be retrieved later via search.

However, the Opera client doesn't just leave you in a soup of tags and labels the way Gmail, Delicious and Flickr do. They go one step further and structure the user's sidebar views into different kinds of views:

1. Their notion of Labels: which are essentially various flavors of emails that you get that you might actually find relevant and important to keep track of (ie. todos, emails you need to reply to, meetings, fun forwards, reference materials, etc)
2. Attachments which are then sub-divided into Documents, Images, Music, Video and Archives
3. Filters

(I believe there are more: ie. Mailing lists and Newsgroups...)

So in that sense OperaMail^? has 1 level of meta-organization, 1 level of putting views into groupings.

• OperaMail^?.png:
  

Out of the box this looks great, but the question is, does it scale?

Because everything is crammed into a single dimension (I can make more views by adding another item to the vertical sidebar), there isn't a lot of room to grow.

For example, what if I wanted to have a separate view of Documents for every Project I'm working on? Say I have 10 active Projects. The sidebar would grow immediately by 10 items. Now, if I wanted a separate Project folder for every kind of Attachment I have, that's potentially 40 more items, for a grand total of 50 views in the sidebar, just because I wanted to see an intersection of Projects and Attachments.

This assumes too, that I will always want to look at my data, first by content type (ie. Documents, Images, Music) and then second by Project...which really defeats the purpose of an attribute-centric world where I can view my data in any way I want.

So then if I want to set up views that are first organized by Project and then organized by content type, that's another 50 more views in the sidebar.

A lot of work and a lot of views to trudge through, to do something very simple, which is intersect Projects and content types.

This is why in Chandler, we're aiming to use more than 1 dimension to organize views of data. We're going to use 2, since that's what the screen affords us ;o)

Arrayed across the top are the Kinds or Chandler Application areas (ie. Mail, Tasks, Calendar and eventually Resources, Media and Directories). Down the left are user-defined collections in the sidebar. The various ways you can slice and dice data in Chandler are as follows:

1. Users can either look at all items in a particular Application area (ie. All my email) OR
2. Users can look at all items in a particular user-defined Collection OR
3. Users can look at any intersection of Application area and Collection by selecting and Application area and then selecting a Collection or vice versa OR
4. Users can overlay multiple collections on top of each other to view multiple collections at a time and then if they feel like it, intersect that with an Application area. (ie. Let's look at both my Home and Work calendars)

All of a sudden, with no extra work on the user's part and a UI that looks remarkably like a traditional PIM, the user is truly slicing and dicing data in all kinds of ways, effectively building queries by simply interacting with the UI in very traditional ways. No rule builders or fancy query language skills involved.

For more on how the sidebar works in Chandler, check out SidebarSpec2, it's a little out of date, but the basic idea is there.

• 09_Dashboard_Matrix.png:
  

• 01_Chandler_Landscape.png: