Features/Thunderbird/Modern Address Book
Status
| Modern Address Book - V1 | |
| Stage | Design |
| Status | In progress |
| Release target | Under revision |
| Health | OK |
| Status note | Need to review size of work/scope of v1, and amount to implement. |
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 | ` |
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.
Note that we're not planning on upgrading the old address book - this is a full reimplementation, from the ground up.
This is, obviously, a relatively large undertaking. This project is comprised of the following 6 components, in no particular order:
1) Move the Address Book into a tab (wiki page):
- Following in the footsteps of Conversations and the Compose-in-a-Tab experiments, we would like to see the address book open in a new tab as opposed to a new window.
2) Design a contact editor to allow N typed/labelled email addresses and instant message accounts (and maybe more fields...):
- 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) Have a smooth migration path from the current address book to the new address book:
- It is critically important that users are able to move their contacts over to the new address book, and have their data be fully intact.
- Interactions with the new database should be asynchronous
4) Move from Mailing Lists / Address Books to more generic groups/categories of contacts:
- Moving from folders to groups/categories 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:
- Design a contact editor that is flexible enough to deal with the variety of fields that a contact provider could require / support.
- 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:
- 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) Contact integration (wiki 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. Edits to a contact should then be propagated to the contact providers that compose that contact.
2. Users & use cases
This change will affect all Thunderbird users who make use of the address book.
Here are the current series of use cases.
3. Dependencies
`
4. Requirements
`
Non-goals
At this point, we're not going to let contact providers push changes to other contact providers through Thunderbird. So, in other words, if a contact provider X sends an updated field, Thunderbird will not update this field for other contact providers.
Instead, Thunderbird will disassociate X from the old field, and add the updated field as a new field, associated with X.
Stage 2: Design
5. Functional specification
`
6. User experience design
- A single contact selected
- Adding, editing and deleting contact names
- Adding, editing, and deleting simple fields
- Field hiding / merging logic
Stage 3: Planning
7. Implementation plan
V1
- Should have at least functional equivalence to current Thunderbird address book. Specifically, users should at the very least have the ability to:
- Add, delete, and update contact records with (at least) the same fields.
- Create and send mail to mailing lists
- Search for contacts
- Have read-access to the OSX address book
- Add and query LDAP servers
- Auto-complete to/cc/bcc fields
- The Contacts API being developed by the Web API team should be used as a mechanism for communicating with the system address book
- Note that TB has no interest at this time in exposing the Contacts API to web content.
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
`
Feature details
| Priority | P1 |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | ` |
| Secondary roadmap | ` |
| Feature list | Thunderbird |
| Project | ` |
| Engineering team | Thunderbird |
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | sec-review-needed | bug 744955 |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
