[Usability] Context for Evo 2 Mockups.

[Anna Marie Dirks <anna ximian com>]

I am writing to provide you with some context for the changes to the Evolution UI that I proposed last week on this list.  The motivations for these changes can be divided into two basic categories:  those which arise from the need to simplify the backend, and those which arise from the need to simplify the gui. 

Neither of these can be considered in isolation; to make Evolution as robust, usable and sustainable an application as possible, we must address both sets of needs. Since I suspect that the average reader of this list is not acquainted with the problems associated with the current Evolution architecture, I will address these first. Any conceptual model that we develop for the Evolution GUI must, after all, help us to advance our goals for the backend, or Evolution will cease to be a maintainable app. If you don't care/don't want to know about the backend stuff, then skip to #4.

1. The current Evolution architecture is very complicated. This complexity makes it incredibly laborious to maintain, and (for lots of would-be hackers) prohibitively difficult to contribute to. It is of utmost importance to the Evolution development team to simplify the project's architecture. 

The complexity of the current architecture causes various technical disadvantages:

        * It makes the components more closely coupled than they need to be.

        * It causes code duplication because components have to pretty much special-case the local storage.

        * The interaction for folder operations is really complicated. After almost 4 years of development, this is still rather buggy, and is difficult to fix within the current architecture.

And what's worse:  we went through all this pain to emulate the behavior of Outlook's local store, but in the end, the gui representation of this store (the folder tree) is very poor from a usability perspective.  Indeed, there is no reason why my calendar folder should be embedded into my ever-growing stack of mail folders. This only makes it difficult for me to find the information I need. 

The developers at Microsoft knew about these difficulties related to the folder tree; in fact, they provided the shortcut bar which is basically a hack to make it easier for users to switch folders.  In Outlook XP they went even further; they developed a complicated setup in the left pane which categorizes folders by type, hence hiding the underlying folder structure.

However, theirs is a messy solution (the UI uses some weirdo custom widget that rolls the categories up and down) and it doesn't really fix the underlying problem since as soon as you try to create a new folder it pops up the old-style folder creation dialog, with the folder tree in it. This seems disingenuous considering that they are trying really hard to not show it anywhere else.

The sum of this is:  we should move to an approach where the local store is gone, components handle their own folders, and the UI presents the folders categorized by type. Which leads to: 

2.  If we simply sort the folder tree by type, then we would have something like this:
 
- Local Mail
      - Inbox
      - Outbox
      - Sent

  - anna chillonia org IMAP mail
      - Inbox

  - Calendars
      - Local Calendar 
      - Exchange Calendar

  - Address Books
      - Local Contacts
      - ldap.netscape.com

This still seems over- complicated from a user interface perspective:  you have to do a lot of scrolling up and down if you e.g. are reading your mail and want to check something in the calendar. To that end, it makes sense to take the simplification of the folder tree a step further: instead of simply sorting the folders by type, we can also separate them. (Ie, within the "Mail" component, all and only mail folders will be shown in the folder tree" area.) 

It is worth noting that this direction has been adopted by numerous other similar applications; both Entourage and Outlook 2003 separate folders by type, and only allow folders of one type to be shown at a given time. See their product pages for more information: http://www.microsoft.com/mac/entouragex/default.asp?navindex=s4 and http://www.microsoft.com/office/preview/editions/outlook.asp  

3. So, if we went the "separate folders by component" route, what ramifications would this have for Evolution's architecture?

        * The UI would be simpler.

        * We get rid of all the crufty LocalStorage mess, since each component would manage its own folder tree.  For example, the mailer could use Camel store trees.

        * Folder operations become much simpler to implement and (hopefully ) less buggy.

        * Components are more loosely coupled, and it becomes easier to run them by themselves without the shell (if we ever wanted to). We would have much more freedom in implementing the components and much less dependency on the shell.

        * We can, though we don't necessarily need to, get rid of the shortcut bar (which has been an infinite source of bugs). 

Whew, that is it for backend context. Congrats if you read this far. As I hope is obvious, finding a sensible way within the GUI to separate the folders in the folder tree by type would allow us to significantly simplify Evolution's architecture, as well as its UI.

4. In addition to the aforementioned desire to simplify the folder tree, we would like to address the following needs in the Evo 2 UI.

A. We want to enable people to run the various Evo components separately, such that each component appears to be its own app. Note that it would take an enormous (read: prohibitively large) amount of work for Evolution's code base to be split into separate apps at this time, but we can move incrementally in that direction by making the changes to the folder tree discussed above. To reiterate: we can make each component *look* as though it is a separate app; developing a design that makes sense regardless of how many components you choose to run is hence a priority. 

B. We want Evolution to be easily pluggable. There are currently plugins for GAIM, Gnome Meeting, and various server projects in the works. We've also begun work on a "News" component; indeed, the number of possible components is only bounded by the number of people who desire to develop them. The new design of Evolution should be easily extensible, so that an arbitrary number of components can be installed. 

C.  We have found that a great number of users have difficulty in understanding the interaction between their local folders and their mail/calendar/ldap servers. The Evolution related email lists have had no end of questions over the past few years from people who wish to know *which* Inbox they are accessing within the local folder tree,  etc. The design for Evolution 2.0 should clearly separate storages by source, and should attempt to make it more obvious to users which storage a given folder is related to. 

D.  We want to be able to present more information inline in the Tasks, Calendar and Contacts views. Currently, we use disparate models in the Mail view and the Contacts/Tasks/Calendar views: in "Mail" you can see a listing of messages, as well as view the content of a single message. In the other views, one can currently only see a summary (at best) of the items within that view. We'd like to make the way that we present data standard across components (if that's possible without straining the UI metaphors), to lower the learning curve associated with the app, and to make it easier for people to access their data without having to open new windows.

E.  We want a design that shrinks down nicely: we want people to be able to see as much or as little of the Evo navigational widgets as they want. Currently if you are in the Mailer and you want to switch to the Calendar, you have to either have the folder bar open at a reasonable size so that you can read the folder names and switch to the folder you want, or you have to have the shortcut bar displayed at a reasonable size so that you can read the shortcuts' labels and find the one you want. If you make the shortcut bar narrow enough that only the icon for each shortcut is displayed, then the shortcut's label is truncated (on both ends, argh). This (besides not being very usable whatsoever) simply looks unprofessional. In both the case of the person using the folder bar to switch from Mail->Calendar and the case of the person using the shortcut bar, the screen real-estate consumed by Evolution is inefficiently used. 

F. We want a design that uses UI paradigms which are widely enough understood that people new to Gnome will be able to apply their knowledge of other interfaces to the Evolution interface. And a corollary to this is that we want to use UI paradigms that fit within the Gnome universe, and which can comply with the HIG and the Accessibility guidelines.

So, with those things in mind, I developed the mockups which I included in my original mail on this subject. Those mockups* were intended to serve only as a starting point, really. They provide us with enough concrete detail that they can be used in usability tests, and can be easily adapted to better suit the needs of our target audience members once we have concrete information about how people use them.

*For ease of access, here they are again: 

http://primates.ximian.com/~anna/evo2/evo2_mail.png
http://primates.ximian.com/~anna/evo2/evo2_calendar.png
http://primates.ximian.com/~anna/evo2/evo2_contacts.png
http://primates.ximian.com/~anna/evo2/evo2_tasks.png

So how does this all translate to the "conceptual model" that Calum asked for? 

The model is: 

All of Evolution's components should be able to be run as seemingly separate apps, and Evolution should be able to accommodate an arbitrary number of components. In the mockups above, these things would be accomplished by adding or removing navigational buttons.  Note that the size of the icons on the togglebuttons I used in the mockups is subject to change, as is the number of togglebuttons/row. 

The Evolution folder tree should be as simple as possible, and should clearly separate the various storages. In the mockups above, this is done by only showing folders of one type at a time, and by clearly labeling the various storages using user-familiar language. Relatedly, people who do not wish to see the folder tree at all should have an easy (and minimally consumptive of space) way to switch components. This is shown in the navbar_shrunk screenshot above.

The model used for reading mail (message list + preview pane) should be extended to other components as appropriate, to allow the user to more quickly and easily view his data without needing to open separate windows. The Tasks and Contacts views above show a possible way to do this. Still working on a proposal for the Calendar view.

Finally, our design should use widely understood UI metaphors, and should conform to the HIG/Accessibility guidelines. How well our design uses familiar metaphors is something that usability testing can tell us; we will adjust our design based on people's feedback as needed. As for the HIG and Accessibility stuff, all I can say is that we won't rest until its compatible. With the exception of the nav buttons in the shrunken toolbar view, I think that most of this design is already fairly compliant with the Accessibility guides...

So. Hopefully this is what Calum was asking for, since I just spent a heck of a long time writing up all of this. Calum, if this is NOT what you had in mind, please let me know specifically what other kind of data you want.

I would be most appreciative of any specific, concrete ideas about how we might improve the usability of this design.


Anna

--
Anna Marie Dirks <anna ximian com>