Address Book Cards [ postal address ]

[Bryan W Clark]

Moving into this one as Leni points out it's very similar to the name field so we might as well keep our thought process going before looking at the other fields.  Some general ideas that came out of the previous thread and I believe we're interested in were: Speed, Extensibility, Offline, and Syncing.

http://wiki.mozilla.org/MailNews:Address_Book_Card_Fields
http://wiki.mozilla.org/MailNews_Talk:Address_Book_Card_Fields
http://wiki.mozilla.org/MailNews_Talk:Address_Book

This message, as the subject indicates, is about the Postal Address field; dissecting what others are doing along with what we are doing.

Current Thunderbird
2 default types of address, Home and Work

Home

• Address (1)
• Address (2)
• City
• State / Province
• ZIP / Postal Code
• Country
• Web Page

Work

• Title
• Department
• Organization
• Address (1)
• Address (2)
• City
• State / Province
• ZIP / Postal Code
• Country
• Web Page

Other Address Books
(again, this could be an en-us only view of all these systems, help is appreciated)

Mac Addressbook [1]

• Address
  

Google Contacts [2]

• postalAddress

Yahoo Address Book [3]

Home

• Street (multi-line)
• City
• State
• Zip
• Country
• Personal Web Site
  

Work

• Company Name
• Job Title
• Street (multi-line)
• City
• State
• Zip
• Country
• Company Web Site
  

Windows Live Mail [4]

Personal Information

• Home Address
• City
• State / Province
• ZIP / Postal Code
• Country
  

Work Information

• Company
• Work Address
• City
• State / Province
• ZIP / Postal Code
• Country
  

vCard [5], hCard [6]

Types: intl||dom,home||work,postal,parcel,pref

• adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, type, value), label
• geo (latitude, longitude), tz

JavaPhone [7]

Types: intl||dom,home||work,postal,parcel,pref

• adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, type, value), label

Address Conventions

Similarly to naming conventions the more complex postal address systems above are based on the X.520 system of attributes, most LDAP systems behave this way as well.  Google and Apple offer a single entry for addresses while most others tend to break down the system into pieces of addresses.  Wikipedia has some excellent resources on postal address conventions and formats.

http://en.wikipedia.org/wiki/Address_(geography)
http://en.wikipedia.org/wiki/Mailing_address_format_by_country

Where do we get Postal Addresses?

LDAP and Remote Systems

Many enterprise LDAP systems will often have the address fields entered for address cards in the company system.  Other remotes systems like Plaxo where postal addresses were entered in a different interface and now sync to the local address book.

Manual Entry

Currently a person could open the local address book to find a contact and open the contact editor to the Postal Address tab.  With the contact editor open one can begin to enter in the information in the desired fields.

A typical use case is one where an address was sent by a contact and the user would like to save it with that contact.  With the current system for either a remote or local address book we have a really poor set of steps for a person to complete.  Copy & paste individual pieces of an address from an email into the different address fields. (about 5 copy & paste maneuvers for a typical US address on whole and parts of whole lines) - this is a very difficult set of steps, especially for people who do not use keyboard shortcuts for copy and paste.

Postal Addresses used

In the Address Book window with the Card Pane Summary (View -> Card Pane Summary) open the postal address for either work or home is shown with a button for [Get Map] which will open the address on Google Maps.

Address book cards can also be printed for labeling and use in mailing.

Use Cases to consider

Here are some use cases I think we'd like to support, but it would be great to see some thinking beyond just harvesting address information and more along the lines of what do we do with addresses when we have them.  Why should we encourage people to collect postal addresses in their address book?

Some general changes that could help any use case.
* It would be nice if we could recognize postal addresses [1] and offer options to add or update an existing address for the card of the person.
* We should offer opening the contact editor directly from the email on any address
* Copying an address should be slimmed down into a single copy & paste action.

Update a contacts information.with a postal address received in an email.

A person you know and have an existing contact entry for sends an email with their new postal address.  How do we update (replace) the existing address?

Add an additional postal address to a contact's information.

A person you know and have an existing contact entry for includes the postal address for their work in the footer of the message.  How do we add the additional address?  Should we give it a type (work, home) during the addition, and how?

Ideas

Google Maps offers geocoding services [2] which could be used in a number of ways, inline maps, update partial addresses, inserting latitutude and longitude.

Others?

~ Bryan

[1] http://search.cpan.org/~pauamma/Geo-PostalAddress-0.04/PostalAddress.pm
[2] http://code.google.com/apis/maps/documentation/services.html#Geocoding
     http://code.google.com/apis/maps/documentation/staticmaps/

[Philip Reames]

I'll add a few use cases to your list:
- Allow multiple addresses and multiple business roles. I have several
friends who work part time for different organizations. Trying to keep
track of them with Thunderbird's current setup, I end up dropping most
of that information in free form notes.
- Keep track of different addresses over time. (This also applies for
email address & phone numbers.) I want to be able to mark an address as
"old", but still have it available in the database. My reasoning is
that I may want to remember where a friend used to live. Say they had a
good restaurant nearby or something. Being able to locate that again is
useful. "Old" information would probably not be visible by default, but
would remain in some kind of history view. (I realize this one is
reaching a bit and might be appropriate for an extension, but please at
least make it *possible*.)

Yours,
Philip

[Philip Reames]

My apologies for replying to myself; I know it is often considered bad
form. I remembered two additional use case I wanted to include.
- Partial addresses - Often I do not have complete information for a
contact, but I may have their city or state of residence. (Say for
someone I met at a conference.) Having robust support for entering,
parsing, storing, and search based on partial location information would
be quite useful.
- Search by location - When visiting a city, it is often useful to be
able to find everyone I know who might live in that city. (Due to
auto-syncing from remote data stores, I might not even be aware they
live there.) Currently, there is no way to do a search for everyone I
know in say Washington, DC. I could also see this being quite useful in
business, for sales people in particular.

Yours,
Philip

[Bryan W Clark]

Philip Reames wrote:
> I'll add a few use cases to your list:
> - Allow multiple addresses and multiple business roles. I have
> several friends who work part time for different organizations.
> Trying to keep track of them with Thunderbird's current setup, I end
> up dropping most of that information in free form notes.

Yes, we definitely need this. Work and Home are good labels to provide
intiially for addresses, but we should be allowing any kind of label for
any number of addresses.

> - Keep track of different addresses over time. (This also applies for
> email address & phone numbers.) I want to be able to mark an address
> as "old", but still have it available in the database. My reasoning
> is that I may want to remember where a friend used to live. Say they
> had a good restaurant nearby or something. Being able to locate that
> again is useful. "Old" information would probably not be visible by
> default, but would remain in some kind of history view. (I realize
> this one is reaching a bit and might be appropriate for an extension,
> but please at least make it *possible*.)

I think that's a perfectly valid use case, we should be keeping more
information than we're losing. Tagging an address or any other
attribute as "old" or "archive" could remove it from the daily view in
Thunderbird or the Compose window but would still be available in the
Address Book.

(adding in the others)

- Partial addresses - Often I do not have complete information for a
contact, but I may have their city or state of residence. (Say for
someone I met at a conference.) Having robust support for entering,
parsing, storing, and search based on partial location information
would be quite useful.

I agree, I'm hopeful we might get some help from things like the Google
geocoding system to make the addresses better.

- Search by location - When visiting a city, it is often useful to be
able to find everyone I know who might live in that city. (Due to
auto-syncing from remote data stores, I might not even be aware they
live there.) Currently, there is no way to do a search for everyone I
know in say Washington, DC. I could also see this being quite useful in
business, for sales people in particular.

I wonder what kind of search you're expecting for the postal address.
Is this from the Address Book search or some other search facility?

Cheers,
~ Bryan

[Clint Talbert]

Bryan W Clark wrote:
I'd like to throw another interesting twist into the mix. What about
localizing the address fields themselves?

Often other localizations do not use addresses that readily conform to
these fields and it would make sense to have a different visual
representation for them rather than stuffing their information into what
is essentially an en-US format for address data.

For example, here is a German address formatted the way that they
traditionally do it:
Herrn ["Mr." (form of address)]
Eberhard Wellhausen [name]
Wittekindshof
Schulstrasse 4 [street address]
32547 Bad Oyenhausen [postal code + city/town]
GERMANY [country]

And a link to another one for Japanese which really changes up the
expected locations of the textboxes:
http://www.japan-guide.com/e/e2224.html

We cannot create every form of address in one dialog, but if we come up
with a system that allows localizers the flexibility to re-label the
layout to a format that their users would expect while still allowing us
to garner the proper mapping of information into our database, I think
it would be an elevation of user experience.

We did a simple version of something like this for the Simdesk Organizer
Addressbook pane. I'll see if I can find the code we used for that to
give you some ideas.

Clint

Here's a very useful link on postal address formats:
http://bitboost.com/ref/international-address-formats.html

[mozil...@zindus.com]

I recently blogged about syncing Thunderbird postal addresses with Google:
http://www.zindus.com/blog/2008/04/30/release-075-and-thunderbird-google-address-sync/

There's nothing earth-shattering there to read - it just illustrates the
difficulty of syncing between apps that have made different choices
about single fields vs differentiated fields.

Single fields:
- ease of capture
- ease of localization

Differentiated fields:
- fine-grain management
- better data-exchange with apps that expect differentiated fields

Leni.

[ovidiu]

I'll state again something I just dropped in the other (names..) thread:
I support adding a combination of fields and field tags with "add more"
option.
1. the idea of "field names" as "field tags". Meaning hidden tags. So
that if I see "city", that is a field with 1 tag. In this way you create
a flexible base for later improved/changed field arrangement. And "add
more"[+] ..
2. These "areas" in the panel (home and company etc) would be again
tags. And "add more"[+] Home and company *areas*, turning out more than
1 company/location, being for more companies, but also for various
locations. [A building site is a location (or more than one..), for
example, where one contact may be tied to.] So this means where I see
"home" and "city" is a field with those 2 tags.

I plead for a flexible case like this to have a base for further issues
and compatibility to be dealt without need for deep change. And the
[+]add more is a case for emails and phones always ..

but to complicate it's beauty:
Of course, now, and address may be redundant info, for you and family
for example, or for 10 people in a company. How about having that info
in a "locations" place and tie it to various contacts? Like having
Company X location and then 10 people just tied to it instead of 10
times that info. Cause when it comes to location, there is room for all
of us under the sun, but some just insist on occupying same small
offices .. :-)

Now one can move on thinking of drag and drop a location to simply add
it, auto completions (when fill a company, present the location ..),
dealing with duplicates etc. Hmm.. well, the idea is just an intention
to look for more of a "hub" approach, to really help users. Some small
things can make a difference ..

[Leni]

A thread touching on this issue on the Google Contacts API mailing list.

http://groups.google.com/group/google-contacts-api/browse_thread/thread/65fc032082d5e374

Leni.

[Mark Banner]

Clint Talbert wrote:
> Bryan W Clark wrote:
> I'd like to throw another interesting twist into the mix. What about
> localizing the address fields themselves?
>
> Often other localizations do not use addresses that readily conform to
> these fields and it would make sense to have a different visual
> representation for them rather than stuffing their information into what
> is essentially an en-US format for address data.

I've actually just remembered I kicked off a thread about this in
md.l10n a couple of years ago:

http://groups.google.com/group/mozilla.dev.l10n/browse_thread/thread/e23bc673ed8b83f6/6c89623de7f5f5ca?lnk=gst&q=address+book+cards+ordering+of+fields#6c89623de7f5f5ca

Unfortunately it didn't really get much of a response from the
localization side...

Standard8