hcard-user-interface: Difference between revisions
m (wrong link to qr_code) |
DelroCmonc (talk | contribs) (oubocr) |
||
Line 1: | Line 1: | ||
letobo | |||
<h1> hCard User Interface </h1> | <h1> hCard User Interface </h1> | ||
{{TOC-right}} | {{TOC-right}} | ||
Line 5: | Line 6: | ||
== Authors == | == Authors == | ||
* [http://allinthehead.com/ Drew McLellan] | * [http://allinthehead.com/ Drew McLellan] | ||
* [http://tantek.com/ Tantek | * [http://tantek.com/ Tantek Ãelik], [http://technorati.com Technorati, Inc] | ||
== Single Input Field for Names == | == Single Input Field for Names == |
Revision as of 16:51, 3 January 2009
letobo
hCard User Interface
This page is for techniques and issues surrounding user-interfaces to author, publish, and display hCards.
Authors
Single Input Field for Names
When capturing name data that is later to be presented as a hCard, it's important that the data is collected at the highest fidelity possible. As not all names are suitable for hCard's implied-n optimisation (and therefore can't be output as fn
, with n
omitted), capturing component parts of the name individually enables the proper construction on n
when generating the hCard.
Sometimes, however, constraints require a name be collected with a single field. Once such example is common blog CMSs (WordPress, TextPattern) that use a single database field to store the name against each post comment. In such cases it is always desirable to find a way to collect the name with higher fidelity. However, if this simply cannot be done, the implementer could chose to attempt to best-guess the component parts of the name to form a valid n
.
One suggested 'best-guess' algorithm might be:
- If the name is one word, attempt implied nickname optimization
- If the name is two words, attempt implied n optimization
- For three or more words
- Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
- Apply the grammar "(honorific-prefix) given-name additional-name(s) family-name (honorific-suffix)"
The principal behind this suggestion is that it's better to make a good guess and potentially miscategorise an ambiguous name component than to generate an invalid hCard.
Additional user interface
Some examples of additional user interface for hCard. Note that most of these actions should be applicable to all instances of the microformat on the page at once (e.g. export all contacts), of for a selection of instances (e.g. export selected contacts), or one just one specific instance (e.g. export contact XYZ).
address book integration
- "Add to Address Book" (convert the hCard to a vCard (.vcf) and pass it onto the OS to automatically open/incorporate into the user's preferred local address book application)
- add to Gmail, Yahoo Mail, Hotmail address book (etc.)
desktop to phone transfer
- send to Bluetooth, for quick transfer of contact info from the web to a cell phone.
- display contact details in an on-screen or downloadable semacode, qr_code or other 2d_barcodes (to allow them to be read by mobile devices)
telephony integration
- If a
tel
(phone number) having typehome
,work
orcell
is present, provide options to dial it (NB applies to one number at a time only; except for possible conference-call uses) directly, or via- built-in modem
- bluetooth command to a paired device (e.g. cell phone)
- default telephony app (e.g. skype-out)
- If a
tel
(phone number) having typehome
,work
orcell
is present, provide options to send MMS:- directly
- using on-line service
- bluetooth command to a paired device (e.g. cell phone)
fax integration
- If a
tel
of typefax
is present, provide options to send a fax to it via:- efax online service
- built-in fax modem
birthday planning
- If a birth-date is present, treat it as a recurring hCalendar event.
address canonicalization
- Given a postal code (or other partial address) fetch the full, canonical postal address for the relevant authority's website (e.g. [1]). If no country is defined, used the user's locality as the default.
data export
- export as text/ comma-separated-variables (CSV) to allow editing, sorting and/ or import into spreadsheets/ databases, etc. (or concatenate to existing file)
see also
- hCard
- hCard cheatsheet - hCard properties
- hCard creator (feedback) - create your own hCard.
- hCard authoring - learn how to add hCard markup to your existing contact info.
- hCard examples - example usage of various classes within hCard.
- hCard examples in the wild - an on-going list of websites which use hCards.
- hcard-supporting-user-profiles - sites with user profiles marked up with hCard - a very common example.
- hCard FAQ - if you have any questions about hCard, check here.
- hCard implementations - websites or tools which either generate or parse hCards.
- hCard parsing - normative details of how to parse hCards.
- hCards and pages - semantic distinctions between different hCards on a page, and how to identify each
- hcard-user-interface - techniques and issues surrounding user-interfaces to author, publish, and display hCards.
- hCard profile - the XMDP profile for hCard
- hCard singular properties - an explanation of the list of singular properties in hCard.
- hCard tests - a wiki page with actual embedded hCards to try parsing.
- hCard advocacy - encourage others to use hCard
- hCard "to do" - jobs to do
The hCard specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. These thoughts, issues, and questions are kept in separate pages.
- hCard brainstorming - brainstorms and other explorations relating to hCard.
- hcard-parsing-brainstorming - brainstorming specific to parsing of hCard
- geo brainstorming
- hCard feedback - general feedback (as opposed to specific issues).
- hCard issues - specific issues with the specification.
- vCard errata - corrections to the vCard specification, which underlies hCard.
- vCard suggestions - suggested improvements to the vCard specification.