: Etherpad users! We are developing an extension that will allow you to create pages from etherpads quickly and easily. Please visit our sandbox and help us test it.

Features/Thunderbird/Modern Address Book

From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.

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

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 ` `


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