Yearly Archives: 2011

Fiddling with designs for a future Thunderbird address book

State of the current Thunderbird address book

While I was hacking away on my EDS Contacts Integration add-on, I got pretty familiar with the Thunderbird address book.

And as it stands, it’s adequate – but adequate like a pickle is adequate for dinner if it’s the only thing left in the fridge.

The address book interface hasn’t even really changed that much since it was part of Netscape Communicator.  Check it out:

Before:

Here's a screenshot of the address book from Netscape Communicator

After:

Here's a shot of the Thunderbird address book on Ubuntu Oneiric

Verdict: the Thunderbird address book is still stuck in the 90’s.  It still assumes that your contacts only have one or two email addresses.  It doesn’t have any notion of Twitter accounts, Facebook accounts, LinkedIn Profiles, or anything that we would associate with a modern online contact identity.  It’s not flexible in the type and quantity of fields that can be associated with a contact.

We can do better.

Some designs I’ve been fiddling with

I should start by saying that the following are just ideas that I’ve been tossing around, and it’s still very very early in the design process.  This is just a starting point. Feedback is encouraged!

Ok, enough disclaimer.  Here we go:

The first thing to notice is that the address book is now contained in a tab, as opposed to a separate pop-up window.

Next, notice that he tree of “address books” on the left is now gone.  I always found it strange to open up the Thunderbird address book, and see that there were…address books inside of the address book.  What I imagine instead is that the Thunderbird address book will know about “contact providers”, like Google Contacts, the OSX address book, the Evolution Data Server contacts database, etc.  Thunderbird will copy all of those contacts locally for fast searching and processing, and synchronize changes both ways.  It’ll also merge contacts that it realizes are the same person. (that’s a ton of work already…).

“But wait!”, I hear you cry.  “I don’t want my Google Contacts to be mixed with the contacts from my OSX address book!”.

No problem – the new address book could have a notion of contact groups.  Contacts imported from the OSX address book will belong to the OSX address book.  Contacts imported from Google Contacts will belong to the Google Contacts group.

And contacts that were common between the two contact providers, and merged, will belong to both groups.  Think of it like Google Plus’s Circles – a user can belong to one-or-several contact groups.

And if you want to view the contacts in a particular group, you could just choose that group from the contact group dropdown:

If we select a contact, we could view it like so:

 

And then we could edit it by clicking the “Edit” button towards the top right:

When we’re editing a contact, the contact list slides away, and we get the full space of the address book to edit the contact.  I haven’t exactly figured out what the various editing tools will look like on a contact (especially considering a merged contact where some elements of the contact exist in one contact provider, but cannot exist in another…ugh).

So one thing that we’re missing in that last screenshot is a “Cancel” button.  Notice that we have those back/forward navigation buttons in the top left.  I’m not sure if those are sufficient / clear enough for the job…but suppose the user could just click “back” to return to viewing the contact without having saved it.

But what about selecting multiple contacts within the contact list?  That might look like this:

So I’ve selected a few contacts here, and I can do various things with this selection – like removing the contacts from my address book, or printing them, etc.  I can also assign these contacts to contact groups en masse.

Highlighting Barry Addison, Bruce Botrill and Phil Cassidy, I can see that all three belong to my “Friends” and “Clients” groups.  Notice that the “Baseball Team” group checkbox looks a bit funny – it’s half filled in, which means that only some of my selection belongs to this group.

From here, I can just click on the various groups I want to assign these three contacts to.  If I click on “Baseball Team”, the half-filled checkbox turns into a check – meaning that all of the contacts I’ve selected will be assigned to that group.  Clicking it again would clear the check, meaning that all of the contacts I’ve selected will not be assigned to that group (and will be un-assigned if that already were assigned).  And if I were to click that checkbox one more time, then it’d go back to it’s half-filled state, meaning that I’ll just keep the contacts that are assigned to “Baseball Team” where they are, and won’t add or remove any contacts from that group.  It’s a tri-state checkbox.  Kinda funky, but it’s my current solution.

Some other ideas worth mentioning:

Asynchronous

Currently, many operations conducted by the address book are synchronous, meaning that the user interface can feel sluggish while it’s waiting for certain events to occur (like writing contact data to a database).  These events should really happen in the background so that the address book stays nice and snappy, and the user can go about their work.

Undo / Redo

This is a big one – any edit or delete events should be un-doable and re-doable.  No exceptions.

So that’s what I’ve been thinking about.

Feedback?

Fiddling with an EDS Provider for Lightning (Calendar)

While I was focusing on getting EDS contacts integration working in Thunderbird, Phillip Kewisch started working on an EDS provider for Lightning.  This would allow the Lightning calendar add-on to read and manipulate EDS calendars.

One of the reasons we want to do this is because EDS calendars are nicely tied in with the indicator-datetime applet:

The indicator-datetime applet on the Ubuntu desktop, opened to show the calendar, and some events from the calendar

That’s really cool integration – at a glance, I can see what’s going on today, and I don’t need to open my full-blown desktop calendar application to do it.

In just a little over a week, Phillip had us doing basic reading of the default EDS calendar:

The Lightning add-on, displaying an event from an EDS calendar

Awesome!  But there’s still a lot of work to do.

In particular…

Indicator-datetime integration

When we click on an event in the indicator-datetime applet, we want Thunderbird to open with the Lightning tab focused, and the selected event in view.  If we click on the “Add Event” menu item, we should be brought to the dialog that allows users to add new events to their EDS calendar.  Also, when a user double-clicks on a particular day in the indicator-datetime applet, we want that day to open up in Lightning.

So there are a few challenges here.  The first one is that opening Evolution calendar is hard-coded into indicator-datetime.  That means that we’re going to have to do a bit of reorganizing so that indicator-datetime can figure out what application to open when the user starts clicking on things.

And remember that we want this to occur whether or not Thunderbird / Lightning is open.  If Thunderbird is closed, and the user starts clicking around in indicator-datetime, then Thunderbird and Lightning should open and react appropriately.  If they’re already open, they should probably focus (although Evolution calendar doesn’t seem to do this).

That means making a way for Lightning to be summoned up from a command like “thunderbird -calendar”.

Full reading and writing to EDS calendars

The provider that Phillip got working is a good start, but it’s far from complete.  For example, it will only read a single calendar from EDS.  It also seems to choke if I restart Thunderbird after loading up my EDS calendar.

Luckily, Lightning was developed with extensibility and other back-ends in mind.  No de-RDF’ing required.

So what’s the ETA on this?  Hard to say.  I’m new to Lightning development, and I’m still feeling my way around.

I’ll keep you posted!

It’s Official: Thunderbird will be the default e-mail client for Ubuntu Oneiric

Word has just come down from Canonical:  Thunderbird will be the default e-mail client in Ubuntu Oneiric!

Woo!  And there was much rejoicing!

Breakdancing Bear

Now, you might think this news is a bit late.  Thunderbird has been set as the default e-mail client on the past two Oneiric alphas.  Isn’t this old news?

Well, kinda, yeah.  But the thing is, those first alphas were just to get a sense of how Thunderbird would work as the default client, and to gather feedback.  At a moments notice, Canonical could have backed it out and switched it back to Evolution.

But they’ve given their thumbs up, and they’re fully on board.

So, at the risk of repeating myself:  come early October, Thunderbird will be shipped by default!  Woop!

UPDATE (Aug 10, 2:41PM EST)

I forgot to mention that this would not have been possible without the enormous efforts of both Chris Coulson and Andreas Nilsson!  You’re both awesome!

EDS Contacts Integration for Thunderbird – So What?

Some of you might be wondering what the advantage is of having Thunderbird share address books with Evolution.  I mean, what’s the point?  A user will most likely use Thunderbird or Evolution – but rarely both.  Why is sharing contacts between the two interesting at all?

So, the answer lies in how Evolution stores contacts.  If you’re running Evolution, you’re actually running two pieces of software – the Evolution client, and the Evolution Data Server (EDS).  The client is what most users think of as Evolution – it’s the program with the GUI that allows users to access and manipulate their mail, contacts, calendar, etc.

But the heavy lifting is really being done by the Evolution Data Server.  The EDS is the program communicating with the e-mail servers to get and store your mail.  It’s the program communicating with your various address books (local or remote, like Google Contacts).  It’s the program that’s communicating with all of your calendars and task lists.

Essentially, if your Evolution experience was a restaurant, then the Evolution Data Server is the kitchen.  The Evolution client is just your waiter.  The waiter takes your orders and passes them off to the kitchen, the kitchen does all of the cooking, and then the waiter brings you the tasty results.

The fact that GNOME has split Evolution like this is really handy.  It means that alternative clients can access Evolution’s mail, contacts and calendars.  Essentially, the user could uninstall the Evolution client, but keep EDS installed, and still have access to all of their mail, contacts and calendars.

To stretch the restaurant analogy a little bit, what I’m saying is that the GNOME developers made it possible for you to order take out from the Evolution restaurant via a third-party.

So what’s the advantage of that?

Well, for one thing, Evolution Data Server talks to some services that Thunderbird doesn’t – for example, Google Contacts (although, this extension suggests that Google Contacts integration for Thunderbird is possible without EDS).

The other big one is Ubuntu One contacts sync.  Ubuntu One contacts are stored in CouchDB address books that are accessed through EDS.  Now that Thunderbird can read your EDS address books, it means that you get your Ubuntu One contacts as well (at least, it will be able to, once Ubuntu One contacts sync starts working in Oneiric).

Not bad, eh?