Features/Thunderbird/Modern Address Book

Please use "Edit with form" above to edit this page.

Status

Modern Address Book
Stage	Feature Inbox
Status	In progress
Release target	`
Health	`
Status note	`

{{#set:Feature name=Modern Address Book

|Feature stage=Feature Inbox |Feature status=In progress |Feature version=` |Feature health=` |Feature status note=` }}

Team

Product manager	`
Directly Responsible Individual	Mike Conley
Lead engineer	Mike Conley
Security lead	`
Privacy lead	`
Localization lead	`
Accessibility lead	`
QA lead	`
UX lead	`
Product marketing lead	`
Operations lead	`
Additional members	`

{{#set:Feature product manager=`

|Feature feature manager=Mike Conley |Feature lead engineer=Mike Conley |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}

Open issues/risks

`

Stage 1: Definition

1. Feature overview

From a surface perspective, Thunderbird's address book has not changed much since it's very beginnings. Even today, by default, it is impossible to create a contact with more than 2 e-mail addresses in Thunderbird. It has also failed to adapt to the social web as it exists today, where the identity of contacts can be spread across multiple services (Facebook, Google Contacts, LinkedIn, Twitter, LDAP, desktop address books, etc). It also has no notion that contacts may belong to one or more groups.

Thus, we believe an address book refresh is in order.

This is, obviously, a relatively large undertaking. This project is comprised of the following 6 components:

1) Move the Address Book into a tab (feature page):

• Our UX trajectory for Thunderbird seems to be that we reduce the number of open windows.

2) Update the contact editor to allow N typed/labelled email addresses and instant message accounts (and maybe more fields...) (feature page):

• Thunderbird only allows a fixed number of e-mail addresses (2), phone numbers (5) and instant messaging accounts (0) per contact. This is a major inflexibility that is the source of many complaints and frustrations with the address book. We should allow users to add an arbitrary number of these fields to their contacts.

3) Migrate the address book storage backend from Mork to something a little more sane - with asynchronous operations being a primary subgoal. (feature page):

• While Mork may be fast, it can also be a nightmare to work with. It's time to move on.
• Interactions with the new database should be asynchronous

4) Move from Mailing Lists / Address Books to more generic "groups" of contacts. (feature page):

• The current implementation of mailing lists in Thunderbird is unacceptable.
• Moving from folders to tags/groups means greater flexibility in contact organization for our users.

5) Build an API for address book "contact providers", which allow read and write to various online contact services. (feature page):

• Design a contact editor that is flexible enough to deal with the variety of fields that a contact provider could require / support.
• Provide a way to display contact groups / mailing lists from contact providers as an address book group.
• Provide a mechanism for dealing with "mid-air collisions", or write conflicts for contact providers.
• Store contacts from a contact provider locally for offline searching / editing. Offline edits will need to be queued until connectivity is restored, at which time the operations will commence.
• Build some default contact providers - LDAP, OSX address book, Outlook, Google Contacts, Facebook, LinkedIn, SyncML connector, CardDAV connector, etc.

6) Allow users to undo and redo changes to their contacts (feature page):

• The current address book does not allow users to recover from mistakes with undo / redo. This is a source of frustration, and potential data loss if the user accidentally deletes a contact.

7) Duplicate resolution and merging (feature page):

• It is likely that a user will have the same person represented across different contact providers. We should allow the user to merge these duplications into an integrated view, either manually, or via an automated process.

2. Users & use cases

`

3. Dependencies

`

4. Requirements

`

Non-goals

`

Stage 2: Design

5. Functional specification

`

6. User experience design

`

Stage 3: Planning

7. Implementation plan

`

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=` |Feature overview=From a surface perspective, Thunderbird's address book has not changed much since it's very beginnings. Even today, by default, it is impossible to create a contact with more than 2 e-mail addresses in Thunderbird. It has also failed to adapt to the social web as it exists today, where the identity of contacts can be spread across multiple services (Facebook, Google Contacts, LinkedIn, Twitter, LDAP, desktop address books, etc). It also has no notion that contacts may belong to one or more groups.

Thus, we believe an address book refresh is in order.

This is, obviously, a relatively large undertaking. This project is comprised of the following 6 components:

1) Move the Address Book into a tab (feature page):

• Our UX trajectory for Thunderbird seems to be that we reduce the number of open windows.

2) Update the contact editor to allow N typed/labelled email addresses and instant message accounts (and maybe more fields...) (feature page):

• Thunderbird only allows a fixed number of e-mail addresses (2), phone numbers (5) and instant messaging accounts (0) per contact. This is a major inflexibility that is the source of many complaints and frustrations with the address book. We should allow users to add an arbitrary number of these fields to their contacts.

3) Migrate the address book storage backend from Mork to something a little more sane - with asynchronous operations being a primary subgoal. (feature page):

• While Mork may be fast, it can also be a nightmare to work with. It's time to move on.
• Interactions with the new database should be asynchronous

4) Move from Mailing Lists / Address Books to more generic "groups" of contacts. (feature page):

• The current implementation of mailing lists in Thunderbird is unacceptable.
• Moving from folders to tags/groups means greater flexibility in contact organization for our users.

5) Build an API for address book "contact providers", which allow read and write to various online contact services. (feature page):

• Design a contact editor that is flexible enough to deal with the variety of fields that a contact provider could require / support.
• Provide a way to display contact groups / mailing lists from contact providers as an address book group.
• Provide a mechanism for dealing with "mid-air collisions", or write conflicts for contact providers.
• Store contacts from a contact provider locally for offline searching / editing. Offline edits will need to be queued until connectivity is restored, at which time the operations will commence.
• Build some default contact providers - LDAP, OSX address book, Outlook, Google Contacts, Facebook, LinkedIn, SyncML connector, CardDAV connector, etc.

6) Allow users to undo and redo changes to their contacts (feature page):

• The current address book does not allow users to recover from mistakes with undo / redo. This is a source of frustration, and potential data loss if the user accidentally deletes a contact.

7) Duplicate resolution and merging (feature page):

• It is likely that a user will have the same person represented across different contact providers. We should allow the user to merge these duplications into an integrated view, either manually, or via an automated process.

|Feature users and use cases=` |Feature dependencies=` |Feature requirements=` |Feature non-goals=` |Feature functional spec=` |Feature ux design=` |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

Priority	Unprioritized
Rank	999
Theme / Goal	`
Roadmap	`
Secondary roadmap	`
Feature list	Thunderbird
Project	`
Engineering team	Thunderbird

{{#set:Feature priority=Unprioritized

|Feature rank=999 |Feature theme=` |Feature roadmap=` |Feature secondary roadmap=` |Feature list=Thunderbird |Feature project=` |Feature engineering team=Thunderbird }}

Team status notes

	status	notes
Products	`	`
Engineering	`	`
Security	`	`
Privacy	`	`
Localization	`	`
Accessibility	`	`
Quality assurance	`	`
User experience	`	`
Product marketing	`	`
Operations	`	`

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}

Here's a contact manager UI round-up by the GNOME team