Update to my address book mock-up

Update: I also added “instant” style searching a few minutes ago. I thought it was cool enough that I’d update my mock-up right away.

Thanks so much for the great feedback this past week for my initial mock-up!

Today, I’ve decided to zoom in a little bit, and try to make some adjustments to the contact list, the category selector, and the search input.

The contact search, category selector, and list have been updated.

 

Here’s a list of the things I’ve changed, in no particular order:

  • “Instant” style searching.
  • Names in the contact list are not bold unless selected
  • The contact list is wider
  • Names in the contact list are sorted alphabetically – regardless of accents. Accents are ignored.
  • I’m using pinyin.js to help me sort the Japanese names. Hopefully the order they’re in makes some sense.
  • The category selector toggle now exists outside (but adjacent to) the search input. It’s the grey button with the “tag” icon.
  • Choosing a category puts the search query for that category into the search input, and then focuses the search input.
  • Searching within a category is now possible, with searches like: “tag:clients guertin”
  • The “Add X” items from the contact details view have been removed. I’ve got something less noisy in mind now – I’ll focus on that soon.

I got a lot of feedback about sorting during my last iteration. It sounds like sorting contacts is something people want to be able to do.

I’m curious if that’s true, and why sorting is so important. So I’ve updated my feedback form to hopefully give me some insight.

Note: If you used the old mock-up, you might need to flush your cache to view the changes. Press and hold SHIFT while reloading to flush your cache.

Another note: The same disclaimer about code quality and browser compatibility still applies.

Enough already, here’s the link to the updated mock-up.

And here’s a direct link to the feedback form.

 

I hear you.

It’s been about 24 hours since my blog post about my address book mock-up, and the feedback has been rolling in like crazy.

The Mozilla community is really awesome. 🙂

I’ve organized the feedback into a few different sections – hopefully that all makes sense. I’ll respond to the feedback soon. Until then, this feedback is for pondering.

 

Feedback

The search input / tag selector:

Constructive criticism

“The mockup lets you limit the scope of the search by clicking the drop-down arrow. However the current scope is not visible without clicking on the drop-down arrow.”

“It’s a step in the right direction, but the Contacts group selector should definitely NOT be part of the search box.”

“…the drop-down to select groups in the search box is confusing, give it a separate place, possibly before the searchbox, to indicate that first one selects a group (or just use all contacts) and then search within that group.”

“I don’t like the way contact categories work: it is for instance never clear if I’m looking at the full list of contacts or only my sports team. It would be better if this were separate from the search bar.”

“It also might be nice to see a list of contact groups somewhere, but maybe they’re ok staying in the search drop-down menu.  They just seem kind of hidden there…”

“If you filter by tag / category, filtering contacts works fine. However, one does not see that a filter is applied.”

“Merging the search field and the “”tag filter”” could lead to confusion. The user is not aware that he could select to see only one group until he presses the field.”

“I expected the Contacts list to filter as I typed, not wait for me to press enter.”

“I really want to be able to filter as I type and not have to press enter”

“I’d rather have each category be separate tabs that I can switch back and forth between.”

“I don’t like that I have to search in every address book separately.”

“You could be consistent with Thunderbird global search (it defaults to global but lets you limit scope after the fact).
You could use a Google-style commands where selecting a scope from the drop-down menu actually adds a special command to the search box. Think of labels in Gmail or site-specific searches for the web. For Thunderbird contacts maybe something like:
group:toronto-office
You could list the groups on the side, similar to Thunderbird’s current address book.”

“If I have entered a search term, I expect there to be an ‘x’ button that cancels the search with one click (like TB’s Quick filter search bar).”

“When searching one contact, it’s better to give a dropdown list of suggested results.”

“Some shortcuts to categories of contact would be better.”

“The concept of to combine the search capacity with the grouping by address book is… weird, here. Other parts of Thunderbird doesn’t play in that idea.”

Enhancement requests

“Would be nice to have features like search folders, tag navigation, classic folder hierarchy on a side panel”

“Is there a way to search on when the contact has been added: in a professional environment, in searching contact situation, you don’t remember the name spelling, or much details but that it was in “sept 2009″ that you have been in touch with the contact.”

Praise

“Looking good overall. I like the quick responsiveness of the search and selecting groups from the drop down”

 

The contact list

Constructive criticism

“Accent of characters should be neglected for sorting. The “Á” is at the end of sorting rather than within “A”.”

“You ought to sort Chinese characters according to pinyin.”

“Having a grouping by the first letter of the name might be good”

“I would like to be able to decide whether the first or last name is displayed first”

“On the left side bar, make the pictures and font slightly larger without using bold.”

“Some preferences for sorting (first name, family name, stored name, …) would be great.”

“The simultaneous selection of many contacts don’t work, it’s ok, but at least I expected that it will available… for to let to get the similar capacity of the current Tb address book: see at one glance the main fields of information of many contacts.”

“Consider to let use the displayed name *or* the full name in the contacts’ list.”

“I tried to page through the list of All Contacts, the Page Up and Page Down buttons did not work. One needs to be able to do it from the keyboard as well as by using the slider.”

“I should be able to sort by first name OR last name”

“Sorting by any field is important.”

“Sorting by Client/ Contact is important.”

“It’s better to sort the Chinese characters in pinyin order.(though they are Japanese names)”

Praise

“Nice to have the photo thumbnails in the contact list!”

 

The contact detail viewer

 Constructive criticism

“I would put the “Add Contact” not above the person details panel, but somewhere above the contact list.”

“I think you have to come up with a multi column details view”

“The contact details should have some headings (e.g. Internet: Mail, IM, Website)”

“You have several “Add email” items in the list. You only need one. (Of course there should still be an “Add email” item regardless of the number of “completed” emails listed)”

“In your sample data the email is always listed as “Home”. Home should be a drop-down menu with choices for home, work, custom (and “custom” should let you type in anything).”

“The gap under the name (the big blue bar) due to the height of the photo seems like wasted space.  The big photo is good, I wonder if the other data could be moved up under the name in one consistent column?  And maybe getting rid of the blue stripe?  Or you could align the photo with the right side of the screen, or put it above the name? (if there is a photo?)”

“I don’t agree with the Cobooks way of showing the fields (the data items). They’re listed with no grouping at all, there’s a lot of horizontal rulers. Google Contacts’ way of using white spaces and grouping data: I think that is a better approaching.”

“I wouldn’t use “Contact is a company” for the cases of collective entities. I would rather say something like “Contact is an organization” (think about NGOs, political parties, etc.).”

“Two columns of phones and etc is better – no need to scroll!”

“The blue bar in my mind, takes too much space. I understand the need for a picture, but why not putting a few basic fields on the right hand side of the picture?”

“The actual Address Card (with all the contact info) is too large, that size isn’t necessary. But I think you’re on the right track.”

“You don’t have to repeat “”Add”” before every item. Just say “”Name,”” “”Email,”” etc.”

“Don’t print the names of each field in grey. They should be black for maximum visibility.”

“You have a space for a picture at the top but no field for adding a picture.”

“I don’t understand what the “”Home”” line at the top is about, because it’s obviously not a home address.”

“What happened to the Eudora convention of having one page for home information and one for work information?”

“You can use an icon to replace the “”add contact””.”

“In the contact detail view, maybe we can display the short descriptions of the contact right below the name of the contact. Currently  it is just blank below the name.”

Enhancement requests

“An interesting feature I’d like to see is a ‘share’ button that opens a windows with options: share files (music, photos, text, etc), contacts or anything. It’ll be another step in system integration.”

“Please add the possibility to attach a file to a contact. This would for example allow to attach a scan of a business card as pdf.”

“It would be nice to have an option to launch an external application for calling the contacts phone numbers.”

“I’d love to be able to attach arbitrary metadata to my contacts (or any other TB item, for what matters)”

“It would be perfect, something dreamed, if we could link persons’ contacts with organization’s contacts. Something like: “Carlos” (contact) works in “Mozilla” (link to its contact tab).”

 

The Cobook-style “Awesome Field”

Constructive criticism

“Your textbox labeled “Type in here to quickly add some contact information” seems out of place. It is difficult to give specific suggestions since there are so many directions this could take. I discourage having two different methods for entering contact details. Either this box becomes the default way to enter any details (in which case it would make sense to have it be a separator between the completed contact details and the uncompleted “add email, add phone, add …” items. Or you remove the box and the user has to click on “add email, add phone, add…” before they can enter text.”

“I have no idea how the ‘Type in here quickly to add contact information’ thingy is supposed to work. Apparently it does not do anything yet? More importantly, it is not at all clear how I would use this to, say, add a new telephone number to a contact. Maybe something like Rememberthemilk’s ‘smart add shortcuts’ could work?”

“I also don’t understand the line that says “”Type in here to add some contact information quickly”” (split infinitive removed). Why do I need it? I can just type in information on one of the lines below, right?”

Praise

“I like your approximation, the things you want to use from Cobook. I found the “quick add” bar awesome.”

 

Misc

Constructive criticism

“One annoyance that I have with almost every address book implementation is how difficult it is to copy an address from an email and paste it into the address book. You have to switch back and forth between the email and the address book, copying first the street, then the city, then the zip code, etc. I often end up retyping manually instead of using copy paste to save time (and frequently make typos). If the address book is moved to a tab instead of a window it makes it even more difficult to manually retype the address, because you can’t see the email while you are typing in the address book.”

“The UI does not show any integration with the email functionality of Thunderbird! The ability to select several people in the address book and send them all a email is one of the main purposes for having an address book in Thunderbird.”

“Why are we taking the whole width of the screen? When using an address book, I often want to see my mail behind..”

“The left margin is too large. Everything should be moved to the left.”

“Also the white space between lines is a bit too much. They could be squeezed vertically a little.”

“The setting button icon on right top corner looks like the setting button icon of the latest version of chrome. maybe can use something else to replace it.”

Enhancement requests

“Please, make the address book a bit more independent from Thunderbird as a mail client. I mean, it should me integrated nicely but also be useful if someone prefers another mail client.”

“I’d like a working import/export with Google mail and other mail programs.”

“Thunderbird-contacts-lens for Unity, please!”

“And I would like to have the same address book in FF and in TB: same layout but also same contents. Not another address book to maintain/sync/etc please.”

“What I really want is a contacts app that runs on my PC that can be synced with Google, Yahoo, Outlook Android Phones, iPhones, etc so that you only have to enter contact info one time in one place and that will then be updated on all your platforms. It is the syncing that is important.”

“I think the address book should be card dav compliant ! This is very important for me !”

“Connection with Google Contacts would make this my main go-to for contacts.  Also, being able to open empathy call or chat directly from address book would make ubuntu users happy.”

Praise

“Keep rolling ahead.  This is going to make Thunderbird so much better to use.  If I think of suggestions, I’ll send them in later.  But for now: Onwards!
Thanks so much for your hard work.”

“By the way, I love the simplicity of the layout! congratulations!”

“Looks great!”

“It’s a step in the right direction”
“Like it, go on!”

“Overall, I like the clean and spacious feel and I think you’re heading in a good direction. There’s still lots of work but I suppose you’re already aware of that :-)”

“Overall, it looks awesome.”

“Thanks for giving this a try. Really appreciate the effort!”

“Beautiful. Vastly superior to current address-book.”

“It seems very clear because it’s a large space and the print is big.”

“I think it is awesome.”

Questions

“Are you planning to do this in HTML or XUL?”

“How would you add more tags to a contact? I feel like that’ll be the most confusing aspect (and it isn’t mocked up, as far as I could tell). Also, there’s no list of tags for each contact?”

“Of course, the big question will be interoperability (android and zimbra in my case) and the capacity to merge.”

“Lot of empty space on side of contact photo & name. Will some information come there?”

“Will the categories be realized as tags somehow, so I can flag my contacts with something?”

“Will it be possible to customize some of the labels?”

“But What About if We wanted to Keep Our Address in Folders Like : Clients, Vendors, Hotels, Resorts, Production Houses, Event Managers, Casting Directors etc. etc.”

“Is the format of the address book something that can be exported easily as a text or even Excel file? One of the failures of Eudora was that it shuffled the fields when one did an export (for reasons best known to them).”

A glimpse of a new address book for Thunderbird

I’ve been working on a new address book for Thunderbird.

And I’m making progress.

I’ve reached a point where I feel like the back-end can do something useful, and I want to start worrying about how the front-end works and feels and functions.

Now I’ve got a web-based super-early prototype for you to try.

A screenshot of the mockup in my Firefox browser.

Some caveats:

  1. Bear in mind this thing is super early, and super incomplete.
  2. The primary goal of this version of the prototype is to determine if the general layout makes sense
  3. Adding contacts, and adding new fields to existing contacts does not work
  4. Expect hacky hacky crap code if you look inside the mockup. Here there be monsters.
  5. The menu button in the right-top corner does not work
  6. I’ve only tested / developed in Firefox. Other browsers are not supported, and I don’t plan to sweat about it too much.

Wow, so it sounds like this thing doesn’t do a whole lot. So what does it do?

  1. It loads a list of 500 fake contacts for you to browse through.
  2. It allows you to see the email addresses for each contact that has an email address
  3. Simple searching works
  4. Different contact categories can be viewed
  5. Gives you a sense of how the layout would be. Hide Firefox’s navigation bar for bonus points!

There’s also a big fat FEEDBACK button at the top of the mock. Please give me feedback. Or click here to go to the form directly. Am I heading in the right direction?

Here’s the link to the mock-up. Give it a whirl!

And here’s the Github repository if you want to cry while reading my crappy mockup code.

Expect more of these.

Rambling about a new Address Book for Thunderbird

Hey all.

I’ve been pretty bad about talking about the address book. Sorry about that. I’ve been pretty busy helping to get Instant Messaging shipped for TB 15.

But with IM polished off, I’ve (once again) started refocusing my attention to the address book.

So where am I?

The Ensemble Project

In short, I’m writing an add-on to experiment with approaches to a new address book. I’m calling it “Thunderbird Ensemble”, because every project needs a cool code name.

The add-on is in its very very early stages. Nothing is usable. Nothing is stable or guaranteed. There’s no UI yet, but there are some tests.

You can track my progress here.

Here are some highlights, implementation details and unstructured thoughts about the add-on, and where I’m going with it:

SQLite Storage Back-end

I’ve chosen to use SQLite (via mozStorage) for the contact database. I was originally toying with using indexedDB, but it’s lack of support for substring searches (which is necessary for things like auto-complete) wasn’t very appealing. I briefly toyed with throwing my own indexing layer on TOP of indexedDB, and then I realized that I was probably reinventing the wheel.

So SQLite it is!

Diffs, Diffs Everywhere

Contact records are a representation of the fields and meta data about a contact. My add-on will be able to calculate diffs between records, and those diffs can be applied on top of records to make changes.

So, for example, suppose I decide to make some changes to a contact – I add some email addresses, remove a phone number, and change a birthday. I’m effectively creating a diff.

Now we apply the diff on top of the original contact, and send the resulting contact record to the datastore for storage.

If the storage happens to be on the network, and the original record we applied the diff on to was out of date, we should get a fresh copy of the contact record, apply the diff, and try again.

Conflict Resolution

With diffs comes conflicts resolution – but conflict resolution is never a pleasant experience, and I’d like the user to not have to deal with that if possible.

My solution is to just be optimistic – if a diff is asking to remove something that isn’t there, great! Mission accomplished! If the diff is adding something that already exists, no problem! We skip!

And for things that get changed, like birthdays, we simply say that the last writer wins.

Maybe that’s naive, but that’s the approach that I’m taking.

What do I have?

I can create contact records, diff them, apply diffs, and “merge” two records together. And I have tests for all of that work.

I’ve got the start of the SQLite backend working (basically, we can set up the database…but that’s it.)

I’m currently working on importing old Thunderbird contacts into Ensemble’s notion of contact records.

After that, I’ll work on getting them written to the database.

Comments? Questions? Complaints? Ask them here. It’s still really early on in the process, but if you find bugs in my code, please file issues on GitHub.

No, that’s not “it” for Thunderbird…

(Disclaimer: I’m an employee for Mozilla Corp, who works full-time on Thunderbird development. These opinions are my own.)

Today, through various channels, it was announced that continued innovation on Thunderbird is not a top priority for Mozilla.

Now before you all go running around with your heads chopped off saying things like, “Welp, that’s it for Thunderbird!”, or “We’d better fork that mutha!”, stop for a second, and read this.

Thunderbird is not dead.

Not by a long shot.

Please don’t overreact.

We’re simply not going to pour resources into trying to “innovate” on Thunderbird. Users will still be getting an email client that answers to nobody but them. Users will still benefit from stability, performance and security updates from Mozilla. And their mail will continue to land in their inbox, just as it always has.

So please, relax. It’s all good. Let’s not make a mountain out of a mole hill.

I’d also like to ask those people talking about forking Thunderbird… why? Why would you do that, instead of contributing to the core project? You’d be cutting yourself off from us, the people with experience developing Thunderbird, who can help you with your projects. Work with us. We’d love to have you.

Now, if you’ll excuse me, I’m going to continue testing some kick-ass contributor code. This new Australis default theme is going to blow your mind…