Re: Musings on the contacts user experience

[Allan Day <allanpday gmail com>]

Hey Alex!

This is great. I've been doing some work on this recently, and we seem
to be thinking about the same problems (good thing!)

Alexander Larsson wrote:
> I've been looking at the contact feature for Gnome 3.2  [1], trying to
> understand what we want from this and how it would look. The initial
> page talks about a standalone contacts application, and while I think
> that is needed its not really the full extent of what we
> want. Contacts are a large part of social interaction, and social
> interaction is a huge part of what computers are used for these days.
> So we want to make these an integrated part of the desktop
> environment, rather than some external app. This means we want (in
> addition to any separate app) integration into the shell and the other
> apps in the desktop.
> 
> Historically contacts have been just the data in the address book,
> something you type in once to make sure you don't forget it and then
> rarely look up. But things have changed. With the advent of social
> websites, etc we get to skip much of the "type in info" part, and we
> should be able to use the available information in many new ways.
> 
> So, what kind of things do we now want to do with our contacts
> information? Here is a pretty comprehensive list of things that you
> might need contact information for.
> 
> * Initiate direct conversation over the internet.
>   This is typically email or chat, but can also be voip/skype, or
>   e.g. facebook messages.
> * Initiate communication via external means: snail mail, phone nr
>   You'd look up the data in the contact and write it on a postcard or
>   dial it into your phone (or initiate the call via bluetooth)
> * Open up personal web pages (facebook page, blog, etc)
> * Look up information about the person
>   This can be things like birth date, pin code for house, map to house,
>   etc
> * View recent conversations
> * Send files to a contact
> * Export/Import contacts, and easily send them to someone else
> * Allow DND of contacts to apps, like the evolution composer
> * Get last known (geographical) location
> * Get availability status for im
> * Get last update (facebook, twitter, etc)
> * Edit contact data
> * Merge/link contacts from different sources
> * Extend presentation of contacts in the UI
>   For instance, hovering over an email address shown in an app might
>   show more contact information, including current online status.
> 
> Obviously an important part of this is a common platform that supports
> all these features, and we have a bunch of good technologies for this,
> but I want to start with the user visible side instead. So, how would
> this look to the user?
> 
> I'd like to start with email (i.e. evolution). This is where our
> current address book is, and one obvious step is to remove this in
> favor of a shared address book dialog. Additionally we need to make
> sure all the places thats currently using the address book in
> integrated places, like the email address typeahed, etc, also support
> all the new data. 
> 
> Overall this is not a large change, the main difference is the address
> book dialog. I don't think the traditional address book is much used
> in real life though. Email addresses are almost always looked up
> directly from the composer (via typeahead or the add addresses
> dialog), so its unlikely that the changes made here affect how users
> work with email contacts. 
> 
> This is bad, because we'd like to introduce a workflow that starts
> from the idea that you're gonna communicate with a person, so you look
> up the person and then see the available communication routes and
> chose one. This seems more efficient than starting with selecting a
> communications method and only then looking up the contact, because
> you'll be missing a lot of potential information to chose the right
> method (for instance, when looking up the person you might
> immediately see that his status is "on vacation").
> 
> In order to introduce this workflow for email we need to get the users
> used to it for other reasons. Just adding it as a possible way to
> initiate communications doesn't seem enough. The natural way to do
> this is via IM. When sending an IM message you always start by finding
> the person, and then initiate the communications. In a traditional
> system this is done via the IM main window, and if you think about it
> that window is really just a contact list. 
> 
> So, lets merge the traditional IM ui with the address book. Resulting
> in an integrated IM system that is also an entry into other forms of
> communication (and the other usecases above). This is especially
> fitting given the partial IM integration we already have in the shell
> (ability to get notified and reply to IMs, but you have to manually
> start a not-quite-integrated IM app to send IMs). 
> 
> How would such a ui look? I'm not sure, but to be usable it has to be
> easy to reach, i.e. it can't be a two-step thing (first find the
> contacts app, then find the person) it has to be directly available in
> the shell. The possibilities that I see are:
> 
> * An icon in the system tray area which gives dropdown with online
>   and recent contact shortcuts, as well as an item to open the
>   contacts.
> * A people tab in the overview
> * Return contacts when searching in the overview
> 
> None of these are imho ideal. The search one is very efficient, but
> not very discoverable, so it must be combined with something else. The
> icon in the system tray is not really matching the purpose of the
> system area (to show the state of the system). The people tab while
> good for fast lookups, will not be able to give the full set of
> features outlined above (being pretty low in UI complexity), and will
> make it hard to interact with other apps (via e.g. dnd). So it can't
> replace a full address book dialog, and doesn't make it natural to
> reach it quickly.
> 
> Here is a start idea of a possible UI that builds on a combination of
> the above:
> 
> * The address book is multi-window. The main window lists contacts in
>   very short form, and allows searching grouping, sorting, filtering,
>   selection, adding, removing, etc. It also has a few shortcuts on
>   each contact to quickly start a conversation, but the main operation
>   on each contact is bringing up a separate window with
>   the contact information, status and possible operations. It probably
>   looks something like the two-pane design on 
>   http://live.gnome.org/Design/Apps/Contacts
> * The overview gets a new tab "people" which contains a subset of the
>   contacts information (online, favorites, recently contacted, etc)
>   with a small preview of the contact (picture, name, nick, im status, 
>   last tweet, last IM, etc). Clicking on it will bring up the contact
>   in a window, just like in the address book.
> * Search in the overview includes search hits from the full set of
>   contacts, looking and working similarly to the people tab entries.
> * Make it possible to go online on IM from the user menu
> * Add a shortcut to the address book on the dash by default. 
> 
> The weakest part of this is imho the dash shortcut, as it makes the
> contacts dialog seem like an external app rather than a core thing, but
> I can't find a better place for it.
> 
> We may also want to allow adding contacts to the dash, just to make the
> contacts a first class citizen of the overview, but i'm not sure how
> useful this is in practice.
> 
> [1] http://live.gnome.org/ThreePointOne/Features/Contacts

The main question I have found myself facing in relation to contacts
concerns whether we want a dedicated contacts 'app' or not. (I have
developed some mockups for a contacts app [1], and Lapo has been working
on a design for an integrated IM/contacts app [2].) In what follows,
I'll try and elaborate my thinking on this issue.

My view is that, most of the time, people engage in messaging through
dedicated apps which are typically tied to protocols. We go to our email
app to email and our chat app to do IM or video messaging. Though the
idea of a contact-centric messaging model is an attractive one - I go to
Lapo's contact to initiate messaging with lapo, for instance - I don't
think people often work like that. Instead, we tend to engage in
particular kinds of conversations using different protocols. I don't
think 'I want to contact Lapo about the contacts design': I think 'I
want to send an email to Lapo so that I can make certain kinds of points
about the contacts design' [3]. If someone is offline, I rarely send the
IM message I had in mind through email.

A contacts app will go unused for many messaging activities, therefore:
people will go to their email app or their chat app, and so on. This is
particularly the case because, often, people are continuing existing
conversations which are embedded in these particular applications.

But there are still cases where contacts become the focus of our
activities, rather than specific messages to those contacts:

 * You want to contact someone who you rarely message, and you're not
sure what kinds of contact information you have for them. (It might be
that you just have someone's Twitter or Facebook account, for example.)

 * You want to lookup someone's birthday or address.

 * You want to store information about a particular contact, such as
notes or their postal address.

 * The merge case - you have two competing sets of contact data for the
same individual, one of which might be out of date.

 * You want to find a conversation you had with a particular contact,
but you don't remember whether it took place over IM or email.

 * You want to call someone from your mobile phone, and the contacts app
is an easy way to look up their number.

Each of these cases is relatively rare compared to the cases that I
described earlier, but they are still cases that we should cater for, I
believe. So again, we have to ask whether we need a dedicated contacts
app for these cases. But since a dedicated contacts application might
not get used very often, would an integrated IM/contacts app would be
able to do the job? This largely depends on the design of that
contacts/IM app, and there are a few sticky issues here:

 * What happens if and when someone just wants to use the contacts part
and not the IM part (this may apply to quite a lot of users)? Can this
be made to work?

 * Naming: if we call it 'Chat', how will people know that this is where
they can do contact related activities? Likewise, if we call it
'Contacts', will they know that this where they can access IM? One
possibility might be to call it 'People' (a slight softening and
widening of 'Contacts'), but the same problem might remain. There is a
distinct usability advantage in having separate apps with clear
functions...

 * Conversation-based messaging. Orientating our messaging facilities
around conversations as well as contacts would be really nice. This is
something I've been experimenting with in a design for an IM app here
[4], and it is something you'd lose by centering the IM part around
contacts.

In general, then, my current position is that, despite it not being the
primary way in which people will access messaging, we do still need a
dedicated contacts app. I am open to being convinced that an integrated
IM/contacts app would work, but I would want to see the 3 issues I've
identified above resolved.

Until I'm convinced otherwise, this is my vision for how the different
GUI parts of our contacts framework, then:

 * An add contacts dialog that can be used by different applications.
This would, for instance, provide a graphical means to easily add recent
or favourite contacts to an email. This GUI would probably be similar to
the contacts app, and would probably share the same code base.

 * A dedicated contacts app for when you need it.

 * Contacts search (but no contacts tab) in the shell overview, which
will provide a quick way to initiate conversations.

 * In the future - a conversation focused IM app, and possibly even a
conversation focused email app too.

So that's one way we could do it. But perhaps the combined IM/contacts
approach would be better. Let's try and resolve this question though;
then we can concentrate on nailing down a more concrete set of designs.

Best wishes,

Allan

[1] http://live.gnome.org/Design/Apps/Contacts
[2]
http://gitorious.org/gnome-design/gnome-design/blobs/master/mockups/contacts/contacts-chat-reboot/contacts-mockup-samples.png
[3] I think this kind of behaviour occurs for a host of reasons,
including the technologies concerned (eg. longer messages which are sent
relatively asynchronously in email), but also social convention. There
are particular stylistic conventions associated with different messaging
protocols. Email is a genre.
[4] http://live.gnome.org/Design/Apps/Chat
-- 
Blog: http://afaikblog.wordpress.com/
IRC: aday on irc.gnome.org