gnome contacts our ideas december 15th, 2010

To read the first part, please follow this link.

This is the second part about how we think our favourite addressbook application could look like, what is needed to get to it and the reasoning behind it. It introduces the visual ideas of our favourite addressbook application. Comments, ideas, suggestions and small ponies are always welcome. Please add them to the first part, to have them stored in one place.

A very interesting feature for many people is the integration of our applications with social networks and other services. Information should be therefore pulled out from social networks, services like jabber or other.

We started with the idea of having already a complete database aggregated from various sources, such as your normal addressbook, Jabber contacts, mail addresses and social networks. We then tried to see how we can improve the workflow of finding and interacting with your contacts.

Think of a person. What is it that came first to your mind? Certainly it was her name and a picture of her. We found that those two properties were amongst the most important elements. So we started right there, how could we display a contact in order to help people finding it quickly? We quickly discovered that some people may find a contact easier visually, some prefer to read through text. Both need to be empowered.

Another very important fact is that you often create groups of people in your memory to easily find and group them together. For example your family, your friends in one city, fellow GNOME hackers, work buddies and so on. Additionally to that we thought it might be a good idea to have some additional automated groups. Except "Favourites", they are all set up automatically. The Favourite Group could be then either created automatically by filling in contacts you are much in contact with, but can be also done by letting the user mark specific contacts as favourite.

Editing and creating new groups has to be damn easy of course. This is how we thought it might work out quite nicely:

Often you remember a piece of information but not the rest of it. For example you want to see whose phone number this is, you forgot the last name of a contact or forgot the postal code of the contact. The search must be extremely powerful to be helpful. So we simply allow to search in each contact information, starting on the name, over any phone number, mail addresses, but also anniversaries or notes on that contact.

If you don't want to edit or look up a contacts information, you mostly want to interact with him. That is why we are allowing to let other programs hook into the addressbook. For example Empathy could be interested to open a conversation window if the contact has a jabber address. On the mockup you can see four ideas. A user could quickly contact a person by hovering on the contact tile and pressing one of the buttons which appear. This will launch the chosen gateway with the primary address detail. If he however wants to use a specific detail, he can use the full contact preview. You might notice that there are buttons on the bottom toolbar too. Here we want to have actions such as merging contacts, sharing them or sending mass e-mails when selecting multiple contacts.

We would like to realize this solid integration with other applications via "service handlers", which provide extra functionality for attributes of a person. For example Empathy could be interested in Jabber addresses, while a libchamplain gui would like to display the addresses of a contact on a map. We therefore want to allow applications easily to hook into GNOME Contacts by providing a handler file stating the fields the application is interested, an icon, a name and an executable or dbus function. It will be then automatically shown on contacts, which provide such information.

On the full contact view pane, you can simply edit a contact by pressing the "Edit" button. It is very important, that each field you edited manually will not be overwritten by automatic aggregation processes, except the user wishes that. Edit will happen inline, and we boroughed a lot of ideas from mobile phone addressbooks.

Last but not least we thought that using drag'n'drop could even improve the user experience, so this is an example of what we came up with.

This is the end of our design document. Thanks a lot for reading. We really hope that we got it right and hopefully are able to accomplish this great idea. If you have any suggestion to make or want to help us, we would be more than happy to hear from you. Please add them to the first part, to have them stored in one place.

To read the first part, please follow this link.