}}
{{FeatureTeam
|Feature product manager=Jb Piacentino
|Feature feature manager=Mike Conley
|Feature lead engineer=Mike Conley
}}
{{FeaturePageBody
|Feature open issues and risks=* Syncing across a variety of contact providers presents a challenge when those contact providers don't necessarily share support for the same fields.
** As an example, consider the Google Contacts interface via GMail. This interface allows us to add an arbitrary number of phone numbers to a contact, and to give those numbers labels. Those labels are either predefined (Home, Work, Fax, etc) or can be set to a custom value. Microsoft Outlook 2010, conversely, does not give us an affordance for creating a contact with more than 14 phone numbers, and the labels cannot be customized. So what happens when a contact with phone numbers with custom labels gets sync'd? While this might be an edge case, since this involves a user's data, we should really think through what we would do.
* How will these changes affect the inline contact editor?
* What should happen to Collected Addresses? Should we keep the current behaviour, or should they expire based on some heuristic?
* How do we deal with syncing conflicts?
|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 might need to be broken down into several sub-projects - but this single page will do for now.is comprised of the following 6 components:
As <b>1) Move the Address Book into a start, we believe the new address book should allow users totab ([https://TODO:FEATUREPAGE feature page]):</b>
# Add an arbitrary * Our UX trajectory for Thunderbird seems to be that we reduce the number of labelled fields per contact - a far greater flexibility than the current address book offers.# Use Thunderbird as a contact management and synchronization front-end for contact providers, such as Facebook, Twitter, LinkedIn, Funambol (SyncML), LDAP and any desktop contact providers (such as the OSX address book)open windows.# Quickly and easily manage / merge duplicate contacts, which would likely be a consequence of (2)# Allow users to recover from contact editing mistakes by allowing undo and redo capabilities# Group contacts in a more flexible manner (ie, tags instead of folders)
This new address book should also meet <b>2) Update the following requirementscontact editor to allow N typed/labelled email addresses and instant message accounts. ([https://TODO:FEATUREPAGE feature page]):</b>
# It should allow users to seamlessly use their existing Thunderbird address books and contacts# It should not require configuration in order to be useful# It should not change the experience for users who do not use the address book, or use a different method for managing their contacts.# It should react instantly to user interaction, or display loading / progress widgets when processing * This is a slower job# It should have extensibility baked in - we should assume that add-ons might add new contact providers, or new functionality to the address book# It should provide auto-complete data for names major complaint and e-mail addresses, at the very least# Strict user control over what data contact providers have access to# Allow for easy importing and exporting of contacts to common formats (vCard, LDIF, CSV, etc)|Feature users and use cases=Our target is current users drawback of the Thunderbird address book, as well as users who are inconvenienced or frustrated by having their contacts scattered all over the web.
Use cases<b>3) Migrate the address book storage backend from Mork to something a little more sane - with asynchronous operations being the overriding goal. ([https://TODO:FEATUREPAGE feature page]):</b>
Contacts and contact providers: * While Mork may be fast, it also can be a nightmare to work with. It's time to move on.* Interactions with the new database should be asynchronous* In the schema design for the new database, each field should be typed so that Thunderbird can make intelligent decisions on what actions (if any) to take if a user selects that field. For example, Thunderbird should understand that when a user clicks on an e-mail address, we should open up a compose window. If we click on a Twitter username, the users Twitter client opens up. If we click on a Skype username, a Skype client should open, etc. This should be extendible mechanism.
# A user adds a contact provider to their address book. Among the various settings for this contact provider are options for setting whether or not this contact provider should be able to push changes to other contact providers. <b>4) The user can also choose which fields can be pushed to this contact provider, and pushed to other contact providers Move from this provider.# A user adds a contact provider to their empty address book. Contacts are copied locally. Changes made locally are automatically pushed Mailing Lists / Address Books to the contact provider.# A user adds a contact provider to an address book that already has some contacts in it. Contacts are merged where applicable. Changes made locally are automatically pushed to the contact provider. The local contacts not already existing in the contact provider are pushed, assuming that we have write capabilities to that provider, and the user has specified that this is a provider that we want to push new data to.# A user adds a contact provider to an address book that already communicates with one or more other contact providers. Contacts are merged where applicable. The user can view the contacts that were merged, and make any corrections or resolve any ambiguities that may have arisen from the merge.# A user is offline and opens their address book. They are able to view, search, and edit their contacts, but changes are not pushed until they come back online. Once back online, any ambiguities or conflicts from pushing will be brought to the users attention for resolution.# A user adds a contact provider that provides some sensitive or private information about each contact. During the setup process, the user makes sure to set the provider so that this information is not pushed to any other contact providers.# A user with several contact providers in their address book decides to compose an email. While filling out the generic "To:groups" field, potential of contacts are displayed for auto-completion.# A user adds a new contact to their address book. Contact providers that Thunderbird has permission ([https:// ability to write to are automatically updated with this new contact.# A user deletes a contact in their address book. Contact providers that Thunderbird has permissions to push to have this contact removed. For providers that do not allow us to delete contacts, Thunderbird instead hides that contact from view.# A user wants to remove a contact from one contact provider, but not from others. The user disconnects that contact from the contact provider, and the contact is deleted from that provider (if possible - if not, it's simply made hiddenTODO:FEATUREPAGE feature page]). Changes to that contact are no long pushed to or pulled from that provider.# A user wants to add a contact with a large number of e-mail addresses and phone numbers. Unfortunately, one or more of their contact providers do not support more than 5 e-mail address and phone fields. While creating this contact, these limitations are shown to the user, who can then choose a subset of e-mail addresses and phone numbers to push to those providers.# A user has added some contact providers whose supported fields do not map 1-to-1. When editing their contacts, they can easily see and manipulate which fields are being written to each provider.# A user is removing a contact provider. If there exist fields that are only supported by that provider, the user is notified for resolution. The user has the option of deleting contacts that are only connected with that provider.:</b>
Contact groups:# Contact groups from a provider (in some cases referred to as "* The current implementation of mailing lists") are synchronized in a similar fashion to contacts themselvesThunderbird is unacceptable.# Contact groups behave like tags, as opposed to * Moving from folders: a contact belongs to one or more tags/groupsmeans greater flexibility in contact organization for our users.# Contacts can be organized into arbitrary groups. <b>5) When possibleBuild an API for address book "contact providers", which allow read and if allowed by the user, these groups are pushed write to various online contact providersservices.([https://TODO:FEATUREPAGE feature page]):</b># Contact groups can be nested arbitrarily deep. When nested groups are not possible for * Design a contact editor that is flexible enough to deal with the variety of fields that a contact provider, approximations are madecould require / support.# A default contact group called "All Contacts" allows * Provide a user way to display all contacts existing within their contact groups / mailing lists from contact providers as an address bookgroup.# Each contact provider gets * Provide a group created mechanism for dealing with "mid-air collisions", or write conflicts for itcontact providers. Contacts in these groups have some or all fields synchronized with that * Store contacts from a contact providerlocally for offline searching / editing. Moving a contact into this group Offline edits will attempt need to write that be queued until connectivity is restored, at which time the operations will commence.* Build some default contact to that providerproviders - LDAP, OSX address book, Outlook, Google Contacts, Facebook, LinkedIn, SyncML connector, CardDAV connector, etc. <b>6) Duplicate resolution and link its current fields to fields merging ([https://TODO:FEATUREPAGE feature page]):</b>* It is likely that a user will have the provider supportssame person represented across different contact providers. The We should allow the user is notified if this imperfectly performedto merge these duplications into an integrated view, either manually, or via an automated process.
}}
{{FeatureInfo
