MailNews Talk:Address Book
This page is for discussion of new ideas for new features for Address Book.
If you want to help develop for the address book please see the developers page for more information.
Please also enter your sig when commenting against other entries - that way it should make it easier for keeping track of who's commenting where.
Ideas so far:
- PCSync - we need PCSync-Support to manage contacts with Palm and PDAs
- Manage Contacts in Trees and SubTrees per Address-Book to categorical the Address-Book-Entries
- Birthday interlink with optional Calendar (e.g. Sunbird-Project)
- Opportunity to create new forms (see MS-Outlook 2003 ;-)
- Certificate GnuPG interlink with optional GnuPG-Plugin (e.g. Enigmail-Project)
- Quick-Filter for Address-Entries as a ToolBar with Entries A, B, ..., Z (see MS-Outlook 2003 ;-)
- Prevent Double Entries
- Define "Double Entries"... just the email address the same? or the whole card? Some people want two cards with the same email address. --Standard8 14:11, 7 Oct 2005 (PDT)
- Double Enrtrie = The same email address. Two cards for the same email address isn't favorable. In Future I hope we have List of email address with the affiliated Display Name. What should one need 2 cards for an electronic mail address still then for? --Griffin 00:12, 8 Oct 2005 (GMT+01:00)
- 2 different people using the same email address. Though if we do it right, then perhaps it won't be entirely necessary. --Standard8 03:21, 8 Oct 2005 (PDT)
- Ok, this is an argument. I probably don't have one could carry out this problem about a query taken into account this case because such a fall from my circle of friends isn't known to me; -). The Address book simply likes to ask the user like him it liked... --Griffin 13:53, 9 Oct 2005 (GMT+01:00)
- Define "Double Entries"... just the email address the same? or the whole card? Some people want two cards with the same email address. --Standard8 14:11, 7 Oct 2005 (PDT)
Does a time schedule already exist when the new address book will be completed or when you shall start with the innovations? Within 76 days is Christmas and the ideal Christmas present would be a new address book ;) --Griffin 16:33, 9 Oct 2005 (GMT+01:00)
Sorry, no time schedule. At the moment there are only a couple of people actively working on address book & they don't have a lot of time to spare (including me).
We're not planning on rewrite all the current code/redesigning the whole thing either. Certain things also really should happen before/alongside others e.g. clean-ups to the back end, fixing drag & drop - getting the basics working a bit better. We're always willing to accept patches from others. So if you want to try and help please do. --Standard8 12:15, 11 Oct 2005 (PDT)
globally working addressbook maps
The map feature in addressbook is localizable, but it doesn't allow for mapping functionality in other countries. For example, I can't get a good map of a polish address in an en-US build, or get a good map of Brasilia in a German build.
In my head, maps are like fonts, wherever you are, which build you use, you should get a good display of whichever address. Thus, we should include good maplinks for all countries where we have one. As addresses are often saved in the format that some person likes, and not in the one the map provider does (country names, spelling etc), we should probably have a few words with fuzzy matches (e.g. Polska, Poland, Polen...), and the corresponding provider query string, likely with the country already filled in in the preferred format. Maybe we can add a special set of localized country names to each locale, so that the main build would cover the native language plus english, french, spanish and a few others, and each localization could add a bunch of further mappings in their language. That should likely cover most use cases, I guess. --AxelHecht 05:12, 14 Oct 2005 (PDT)
Ultimate AddressBook - Relational/Associative
My ultimate wish for an addressbook make it relational(ish). Not heavyweight relational; maybe relational is not even the right term, maybe associative is better.
What I want is the ability to "normalize" my contacts, in database kind of way. Each entry is a location or a person or whatever, and each entry has attributed like phone number or address. And then there's the relationships between them (familial [relative, spouse/SO, friend, ...], location<->person, ...).
Use case
Several people live at the same location (that's the relationship between each person and the location). A location has an address, and can have a phone number. A person can have a phone number (mobile, since land line is associated with the location). Stuff like that. If I have 4 entries for different people at the same location (office, home, whatever) and that location changes its number, I only want to have to change it once, not 4 times.
Similarly for individual vs. company (i.e. location) email addresses.
File Formats and Export/Import
I'd like to see the import/export formats expanded. I believe the current PDA/Cell/iPod standard is VCARD, so this would be first. The future of the internet seems to heavily use XML, so I'd suggest developing towards that eventuality. There are already google-able pages up on RDF-VCARD formats in XML.
I see the double-email and associative/relational issues as issues of Object Definition.
What are the individual objects? [object ratio, ie- #Entry:#Objects] As I understand it, the VCARD 3.0 is: (correct me if i'm wrong, and these are only the fields I think important)
- AddressBook Entry
- Name [1:1]
- Display Name / Formatted Name [1:1]
- Family Name / Last Name [1:1]
- Given Name / First Name [1:1]
- Suffixes and Prefixes
- Address [1:*]
- Type: Home, Work, etc.
- Phone [1:*]
- Type: Voice, Fax, Pager, Modem, Home, Work, Mobile [1:1] (string of all that apply)
- Value: The actual phone number, in x.500
- Email [1:*]
- Type: Home, Work, etc.
- Value: actual email address
- URL [1:*]
- Type: Home, Work, Personal
- Value: http://sub.domain.url
- Name [1:1]
Contact merging isn't straightforward, reliably doing so would require a GUID for each contact, and that's not going to happen until Big Brother fully exists. However, during a "merge" or "compact", suspected duplicates could pop up a dialog box with both sets of info like:
( ) Name: John Public | (*) Name: John Q. Public [x] Phone: +1-800-555-5555 | [x] Phone: +1-555-800-5555
and so on...
and you'd click the checkboxes you want in the merged contact. In the case of addresses and phone numbers, multiples can be checked, whereas for Name, only 1 can be chosen (radiobutton).
Contact Input Dialog
This needs to incorporate the possibility of many more address, phone, URL, and email objects, including the ability to have many of the same type (ie. more than 1 HOME email, more than 1 WORK phone) Outlook had these capabilities, and so should this project.
This is already under consideration - see MailNews:Address_Book_Card_Fields --Standard8 09:44, 17 Jan 2006 (PST)
"Show all mail from this contact"
Quite simple really, but a nice feature would be to show all mails from a certain contact. It is quite simple, since you already can do that with a search, but it would be more intuitive to do it directly from the adress book. For instance as a context menu item (right click). --Audunmb 07:11, 28 May 2006 (PDT)