Post

Experimental Firefox and Chrome extensions to copy and paste contacts

The extensions below allow you to copy, store and then later paste contacts into forms. They are proof of concept prototypes taken from a larger project. I have released the extensions now to help inform the discussion at the upcoming mircoformats meetup.

You need either Firefox 4.0+ or the latest Chrome browser.

/>Download Firefox extension (0.1.2 updated 16 Apr 2011)

/>Download Chrome extension (0.1.2 updated 16 Apr 2011)

2 minute video overview

How the extensions work

Copying contact details

Navigate to a page which contains a contact marked-up in hCard and right click on it. The context menu should then contain an item “Copy [Name] contact details”. Selecting this menu item will store the data in the browser.

Pasting the contact details

Navigate to a page which contains a form for contact details and right click on it. The context menu should then contain an item “Paste contacts…”. Choose a contact from the submenu and the extension will paste the data into the form for you.

Design considerations for the future

Issues of discoverability

The largest problem for the copy and paste of semantic data embedded in web pages is discoverability. It is difficult to indicate where and what data is available without over complicating the browser interface. I think the solution lays within joining the copy and paste functionality with other forms of interaction and/or visual flagging that will provide discovery.

Forms need to be marked-up semantically

At the moment most applications that auto fill web forms do not work very well. The common approach of “guessing” what data goes in which field is error-prone. Often the browsers/extensions use regular expressions to match the form field name.

Matching rule for a job title looks like this (?:occupation)|(?:job)|(?:title)

There are more sophisticated approaches which record matching rules from users, but even these are not perfect. What we really need is a way to semantically mark-up forms so there is little or no ambiguity. I have done some conceptual work on how microformats could be used to mark-up forms.

Labelling UX

Although the extensions currently work by parsing hCards I have used the terminology ‘Contacts’. This is for two reasons the first is that users do care about underlying schemas. The second is that a future interface design may abstract the data and display it differently to how it’s parsed from the page. For example, how do we deal with hResumes, do we just extract one contact or several based on work or educational history. If an hCard contains both a work and home address is it displayed as two contacts. Re-displaying the data in its raw form may not give the most intuitive interface.

Data source has to be comprehensive

Contacts found on the web are often just constructed of a few elements and not comprehensive enough to auto-fill a range of forms. The data may need to come from another more fully structured source than a web page for auto-fill to work relatively well. I also believe the user would need to be able to view what was to be copied, what is in the data store before making copy and paste choices.

  • Data Portability
  • Microformats
  • Projects

Data formats:

API