GNOME Contacts is a new feature that is planned for GNOME 3.2. It includes both a GNOME-wide contacts framework that can be used by different applications as well as a dedicated contacts application. I’ve been working hard on the design of the application part for a while now and thought it was about time I showed the work off.
GNOME Contacts will pull together your contacts from your different online accounts and integrate them into a single address book. This means that looking up someone in GNOME Contacts will give you access to a summary of all your online relationships with that person (or as many as we are legally allowed to), including the various ways you can communicate with that person and links to the different places where they exist on the web.
One of the things that makes all this awesome online contacts integration possible is another new feature that is planned for GNOME 3.2: GNOME Online Accounts. I won’t talk too much about this because I’m not all that involved, but I will say that this is a huge win for GNOME in general. Web integration is the kind of thing that has been talked about for a long time but has never really materialised. Well, it’s happening. It’s a new departure for us, and it is a major modernising step. GNOME Contacts will be the first GNOME application to be built from the ground up with online accounts in mind but I’m sure it won’t be the last.
But anyway, you want to see mockups!
As you can see, GNOME Contacts has a simple two pane design. Search is going to be the primary way in which contacts are found, so the search box is put in a prominent place (the first place in terms of how the UI will be read). Next to that is the add contact button.
We’ve tried really hard to make GNOME Contacts about people rather than data. This is one reason why the right hand pane has such a prominent and rich representation of the contact, which makes it feel personal. I’m hoping that we’ll be able to pull in a range of different data to display there so that the most recent status update, Tweet or even IM message is included below the contact name.
The right hand pane also demonstrates the desire for GNOME Contacts to be what I’d call a minimal impact UI. Different tasks associated with the contact, such as editing contact details or adding a note, don’t involve radical UI transitions. The header stays where it is to provide continuity and context and UI changes occur inline rather than within new windows. There are no jarring context changes which results is a UI that is both more efficient (since the user does not have to continually reorientate themselves) and more comfortable to use.
One thing I’m especially happy with is the low number of disclosure points in the design. There are exactly two places where someone can reveal further options in the main UI: the application menu (which is present for all applications) and the user menu which is hosted in a button within the contact pane itself. This means there should be little searching around for menu entries.
Both editing and linking show how GNOME Contacts will pull together the your contacts from across the web. Editing is done per online account so that you can see which details are held in which online address book. Contact linking will be done automatically as much as possible, but there is also a facility to manually link contacts from different online accounts.
These designs are currently being implemented by the mighty Alex Larsson (who has also been contributing to the design process). I’m sure he’ll give a report on his progress at some point in the future. We haven’t been the only ones involved in the design, of course: Lapo Calamandrei was a major contributor and there are lots of Jon McCann‘s ideas in there as well as some nuggets of wisdom from Jimmac.
Questions? Comments? Opinions?
Great work Allan, like every time. 😉
Can I use your image for a french post in my own blog?
Hey, thanks! Of course you can use the images.
But I have two questions:
– What about kexboard only use?
– For the right side, you plan to use WebkitGTK?
Cool stuff Allan!
Do you think it would be good to have an in-built “when have I talked to this person” bit there too, like the old Beagle Dashboard? So you see somewhere in the contact that you exchanged emails in September, chatted in May, and they’re waiting for an answer to a question, maybe even you mentioned them in a document you were writing? I might be on crack, but this kind of thing would be wildly useful to me at least, as someone with thousands of contacts and difficulty in keeping track of previous conversations.
Screenshots & info: http://nat.org/dashboard/
With Tracker & Zeitgeist, we should have the data already, I think… it’d “just” be a question of pulling it all together.
In a word: definitely. We’re concentrating on the basics for 3.2 but things like that are definitely on the cards for subsequent releases.
Nice work! But why did you choose to make this a separate window instead of completely integrating it with the shell? For example: Hit Activities, start typing the name of your contact and get results or click on ‘Contacts’ next to Windows and Applications to browse.
Thanks! Contact searching will be integrated into the shell too. This is just the application design.
Is this related to Folks at all, the stuff Travis Reitter has been working on?
That’s right; our friends at Collabora and Intel have provided us with some great tools.
I like it a lot. However, I’m missing contact groups on your mockups. A lot of applications like messengers and email clients are using them for their contact frameworks. Might be worth to support them in our gnome-wide contact repository as well.
I’m agrea with you, a “Groups” system is needed. Or a “Tags” system.
You could add one, or more, tags for each contact like other field. And, in Application Menu, you could choose a third option for “List Contact By” nammed “Tags”. And we can have some auto tags like “Empathy Contacts” for quickly find some kind of contact.
PS: And it would be cool if we can see the number of tweet posted by a contact that we have don’t read and if this information is highlighted like his IM status (In the list of contact _and_ in his dedicated page).
What do you think Allan?
Groups were definitely considered as a part of the design process, and some concepts for groups were considered at various points. In the end I figured that grouping is probably out of scope for this kind of tool. The main goal is to provide something that is light weight, quick and easy to use. We didn’t want it to have too many bells and whistles and more to concentrate on integration.
I’m sure grouping is important to some situations, particularly work-focused or enterprise contexts. That’s not what we’re aiming for with this design just now though. It might be that if you want to do contacts management for those contexts you need a different tool.
It is extremely early days for GNOME Contacts, of course. We’ll definitely be reassessing these kinds of issues in the future.
why not just add an input field for comma seperated tags with autocompletion for existing tags, as we have it in Epiphany Browser’s “add bookmark” dialog already? As an option under “add detail”..
once two or more contacts share a tag, they are de facto already a group.
search based apps or the shell could make great use of that sort of stuff!
is is that already implemented on Travis’ “individual” level?
Hi, very interesting desing, I’m looking forward to using it. 🙂 Is synchronisation with Google Contacts feature planned?
Good to hear! Yes – Google integration is planned.
Pingback: GNOME 3′s new Contacts app gets shown off, is pretty in design & vision
Very nice Work indeed – clean design, I like it … now if we could have mail client and a calendar in the same vein … that would be brilliant (-:
For the email client, have you tried https://launchpad.net/postler ?
Postler is a very alpha version, e.g. at the moment there is no POP support.
In addition I would like to have a calendar application which is only a calender application with such a nice layout as this contact selector.
Nice work ! I’d like to see this into GNOME 3.2 🙂
Awesome! Great ideas, hope it’ll turn out very usable as well. Keep up the good work
Great work, congratulations!
What’s keeps me wondering if Evolution and Empathy will also share its data, so that if I either edit a contact on Empathy or Evolution, GNOME Contacts will also display those changes.
Both Gnome Contacts and Empathy are based on top of Folks (which aggregates contacts from multiple sources, such as IM and the local address book). One of my main goals (as the maintainer of Folks) is for all desktop applications to use the same set of contacts.
We’re fairly far along with a new evolution-data-server backend now. Once that’s ready, we’ll also be including the same contacts that Evolution currently uses. And, maybe in time for Gnome 3.4, I’d like to get Evolution rebased on top of Folks, so it will have the exact same set of contacts. As it will likely be for Gnome 3.2, editing contacts in Evolution will automatically affect the contacts through Folks, but, eg, IM contacts won’t automatically show up in Evolution.
Thanks for providing more of the technical details, Travis, and thanks for all your work on Folks too!
Looks really nice. Whenever I hear about addressbooks, I immediately think of synchronization. I really like that there is supposed to be _one_ addressbook which harvests from different sources, but unfortunately, synchronization is still a topic – to other devices like cellphones or netbooks. And not just to Google, as mentioned above. Would be cool if that topic was kept in mind from an early stage on.
I also agree to Flo that groups for contacts are handy. Or maybe “tags” is a better word, for “broadcast this message to all IT 101 course members”-kind of usecases.
Keep up the great work!
Online accounts and web integration is cool and all, but as a spy I just need something to securely place contact data about people (positioning systems datum tokens as well).
This looks cool, but I’m feeling a bit trepidatious…
What will this use as a backing store? I have a pretty big Evolution contact list (about 850 contacts), and while my contact list isn’t super long, it is “wide” (lots of info besides name, address, phone). I really only need something nice to manage it, in situ (I’ve been getting frustrated with Evo’s maintenance).
Will Gnome Contacts be able to work with the Evo contacts in their own database? And more importantly, without needing to store things in yet another database? I really depend on my contacts having their “home” in the Evo store, because it’s useful for making my own scripts. I’d hate to have to deal with yet another backing store (Evo and Thunderbird already are two) – no matter how unified it might appear in the interface.
Gnome Contacts uses Folks for its storage. We’re fairly far along on our new e-d-s backend and that will be the default store for addressbook-type contacts in Folks. This setup (with the in-development e-d-s backend) is what Gnome Contacts is being developed against.
So your Evolution contacts will automatically show up in Gnome Contacts. New contacts added via Gnome Contacts will automatically show up in Evolution, etc. We don’t want to reinvent the wheel and use a new database either 🙂
Travis, many thanks (though a bit belatedly) for explaining this in more detail in your various comments here. I’m cautiously optimistic (cautious as with any new tech), but mostly looking forward to this. I’m rooting for everyone involved with this!
The only thing I am not sure I like is the application menu entries. Isn’t Application menu suposed to deal with Application-related commands (namely “Help”, “About Contacts”, and “Quit” and maybe “Import”), while window, document or context-related commands (“List contacts by:…” and may “Import”) would be available in the window? Also, “Online Accounts” (which I presume would launch GOA) relates to another application, and would fit better in the user status menu than in the Contacts application menu.
I also agree with Flo: I miss contacts groups. I commonly send e-mail messanges to a whole group, invite the whole group for an IM conversation, etc. Being able to filter by group (for example “show Family contacts only”) would also be interesting.
It’s a good visual design heuristic that when a window contains multiple vertical scrollbars besides each other, either their tops should line up, or their bottoms should line up, or (if possible) both. Here, neither end lines up, which is a good sign the layout could be made more elegant. For example, you could add a status bar across the bottom of the window. Or you could add a splitter for the panes below the contact list scrollbar, in the same place as the resize grip goes for the card scrollbar.
I think application menus are a silly idea, but that aside, the capitalization and ellipses need a little cleanup: “Link to Another Contact…”, “Delete Contact”, and “Import…”.
Another reliable heuristic, this time for interface design, is that excessive repetition is a sign that you’re using the wrong kind of control. Here, your contact linking dialog repeats nearly every contact from the main contact list. This is a sign that you should be using the contact list itself for the task instead. For example, someone could select two contacts and then choose “Edit” > “Link Contacts”. Or if only one contact is selected, “Edit” > “Link Contacts…” could temporarily reveal a checkbox next to each contact in the contact list, and a “Link” button at bottom. (It’s not clear why you have “linking” rather than merging.)
Finally, it looks as though Notes and the standard contact details are not visible simultaneously. If so, that could be awkward. If notes are often used to add details that didn’t fit in the standard fields, you would have to keep the contents of all the standard fields in your short-term memory before switching to Notes to fill in everything else.
Keep up the good work!
“Linking” is from the Folks vocabulary. Because we’re actually linking contacts together (which can be undone!) vs. merging them, like contacts on Maemo 5 (which can’t be undone). In most cases, it’s minor, but when you accidentally merge people, it’s a pain to undo the damage. Unlinking people, however, is trivial.
Hey Matthew! Thanks for all the constructive feedback! I won’t respond to each individual point here, but there are definitely some actionable items amongst this.
Just a cuestion about the “add” button contact in left panel . What do you think about the add/remove buttons way in some System Settings left panels? Like that: http://gitorious.org/gnome-design/gnome-design/blobs/raw/master/mockups/control%20center/privacy-and-sharing/sharing.png
Álvaro: the reason I didn’t do that was to preserve vertical screen space which is valuable in these days of widescreen displays and which is particularly valuable in the context of a long list which really needs the height. Also, we don’t really need a prominent remove contact button – it’s not something that is used very often.
Is Akonadi integration being, at least, planned?
That’s great news! I’ve been waiting for ages for a clean design like this one. If it’s supposed to be a central component, is integration with Evolution, Empathy and others planned?
looks like I’m curly now, if this nickname sticks I’ll make you responsible for that 😛
but anyways: nice mockups! I’m glad there is some momentum towards gnome contacts.
Any chance the contacts information will be simple to access outside of the app?
I don’t use GNOME Shell directly, instead I use xmonad + gnome — any chance a CLI of sorts could be built? At least a simple SQLite or whatever file, so then I could build one. 🙂
Absolutely. Gnome Contacts is built on Folks, which other programs (eg, Empathy) already use. Morten Mjelva (a Google Summer of Code student for Gnome) is working on Gnome Shell integration for Folks.
Folks includes an interactive debugging command-line tool called folks-inspect. If you want to build a fully-featured CLI program, you might want to have a look at that.
Just a small suggestion: I think the Notes panel could just be another information field, just like the address, so that you go to the Edit panel to add notes (via an always present multiline text field, at the end of the page). I don’t think you need to write pages of text about people: it doesn’t need a full panel for itself.
Great Work, Thank You 🙂
I dont’t know how have do this, but I like this work too: http://gitorious.org/gnome-design/gnome-design/blobs/master/mockups/contacts/contacts-chat-reboot/contacts-mockup-samples.png
is there a KDE equivalent for this without any GNOME dependencies, I heard there is QTFolks but is anything great planned for that in terms of nepomuck/akonadi integration?
I know KDE-telepathy is working on a person based contact list, but I feel this is going to be pretty matured by the time KDE-Telepathy person contact is ready
I’m the maintainer of QtFolks (and lead maintainer of Folks). QtFolks depends upon Folks (and thus GLib, telepathy-glib, etc.), but it doesn’t pull in too many Gnome dependencies. Eg, it doesn’t pull in GTK (since Folks doesn’t include any UI bits).
We have no immediate plans to support Nepomuk or Akonadi in Folks, though I’d be happy to provide some guidance on a Nepomuk backend, if someone wants to do the bulk of the work. I’m not sure an Akonadi backend would make too much sense (since it seems to do similar work as Folks itself).
Architecturally, a KDE program using QtContacts through QtFolks -> Folks -> Folks-nepomuk -> Nepomuk would be a little odd though. I’d instead recommend QtContacts -> QtFolks -> Folks -> Folks-eds -> EDS, since that will be actively developed and supported in MeeGo (and from Folks all the way down in Gnome).
Hooray, This is the biggest change for contacts in years!! Please have a look at this user’s wish list and a couple of questions about linking/editing below;
I would like to see personal and work contact fields (telephone, mobile, address, chat, presence) grouped separately because our people relationships are either personal or professional – fields shouldn’t be grouped based on devices (home telephone, work telephone). For each contact, I would also like to see a personal and professional presence which would be the same, except when I knock off work when all my professional contacts see that I am offline. Similarily, I would like online accounts to be grouped based on at least personal and professional relationships. Ideally online accounts (people networks) should be based on people’s relationships like fans, friends, dating, family, household. I would also like to see a personal photo for ‘friends’ and a personal avatar for the public and possibly the same for my professional network.
Just like Flo, I would like to group contacts to prevent a personal photo from been ‘leaked’ accidently to a professional contact. Groups/Buddy lists are used for chat clients but I would also like to be able to set my presence at a group/person level. For example, I would like to set my Professional presence to offline but set my Work Team presence to available, which would give me a presence of offline to everybody in the office except my team – I would prefer this opton than using the hacky invisible status.
If the same contact has different details in two online accounts I see the need to link the accounts. However, why do you not merge accounts when the details are the same? If the details in one account changes, by all means create a new linked contact.
If you have a contact that does not have an online account I should be allowed to edit the contact. However, why should I be allowed to edit the details of a contact that is linked to an online account? Surely my contact will know their details better than I?
It may not seem so, but I do appreciate the work you are doing and I do like your ideas. I just thought that as you are creating contacts from scratch, now is the time to make my wishes. My pet peeve is the invisible status and I guess it has never been fixed because it’s to hard with what has been created already.
Keep up the good work!!
Very nice – good work so far. Looks very easy to use, however feature set is pretty much what empathy roster does offer already – uses folks as well so some design decision are influenced by the framework – which is not a criticism just a observation.
Linking contacts is a good idea, however how does a contact look after linking?
Is there an easy way to see which information came from where? For example I prefer to contact people over their personal xmpp accounts rather than on for example the facebook chat account. In empathy roster I use right click and choose the specific account or uid.
It would be nice to see if a pgp key is stored for each of the available email addresses
There definitely needs to be Groups of people either as groups or tags doesn’t matter – tags might be more flexible – but one needs to be able to use it as a filter criteria in search and for criteria in setting the status. In my opinion there should be at least a tag for the account provider (i.e. facebook, twitter, whatever.org Jabber server, aim, …) which should be already available and an additional tag which marks the account private or corporate.
Speaking of corporate: There is a need to think about LDAP directories which can offer contacts and contact groups for a company. Also think of freelancers which might have more than one directory. The user may be able to edit contacts on the server or not – or partially (i.e. department or just own user) – but the information on an ldap server (and on some accounts like jabber) might be writeable and manageable. One more think on LDAP – there might be OUs (Groups) that also might have contact information stored like an email address for the Group or OU (Organizational Unit).
We have an about me setting in Gnome which could be replaced by a Me contact that links all my accounts and my personal data I enter of me and that information can be different based on which account it is stored in. So at least for the me account I need to be able to unfold the view and see my different accounts and the information in that account in different cards or side-by-side – I’m not sure what would be best.
And finally thinking of multiple machine, it would be awesome if most of the information could be stored on the respective servers and what needs to be stored locally including the accounts I set up would be really awesome if I could export it and import it on another machine. Thinking a bit ahead and maybe too specific to how I use xmpp with multiple machines – as all my machines are logged in with an unique resource on the same account – they could sync over xmpp that would be a real killer feature (for me) 🙂 Could also work on link-local xmpp, however a token would need to be exchanged to authenticate the machines to each other instead of just trusting all machines (resources) that are logged in on the same account.
So keep on going – I’m really looking forward to gnome contacts. And I hope I wasn’t going way too far for what you want to accomplish – i just feel strongly about those things. Or should I have created wishlist bugs somewhere instead? would be happy to do so if I’m in the wrong place
Pingback: Stopped Clock Blog
I have been thinking about Links. Rather than just Linking contacts, why not state the relationships, if any, between the contacts. For example your use case is to link to an “Alias” of a contact, but you could also link spouses, sweethearts, siblings and parent-child (bit more difficult) too.
I also liked @Mikes comments in regards to about me. Gnome Contacts are being created to serve all Gnome applications because Evolution contacts silo philosophy only served the Evolution application. Evolution also silos about me information, e.g. email address, and Empathy seems to be doing the same with the Gnome Online Accounts. Would it not be better to have Empathy’s Accounts in an about me application which is available to all applicatiions than locked into Empathy?
Several contacts systems over the years have included inter-personal relationships, including QtContacts, Evolution Data Server, and Facebook. But it tends to be one of those “feature checklist” points. Among my friends in Facebook, only a few have correctly labeled their relatives as such (even if they have friended them). It’s one of those things that takes a bit of effort on the user’s part (especially if they’re describing relationships between people other than themselves). Having about 10-20% of relationships accurately labeled wouldn’t be terribly useful in an application.
The only relationships I see anyone carefully maintain (on Facebook) is girlfriend/boyfriend/spouse. I can’t imagine anyone taking the time to record relationships in a local address book. It’s similar to asking people to maintain the metadata in their music files. Track title, album, artist, track number are all reasonable (and usually set), but few of my music files have a genre set.
As far as avoiding silos, that’s why we’ve got Folks. If everything uses Folks (as we’re planning), we will have the same view of contacts in all applications.
Synchronization with google contacts?
will we have Skype messages ?