hcard-user-interface

hCard User Interface

This page is for techniques and issues surrounding interfaces to author, publish, and display hCards.

Authors

• Drew McLellan
• Tantek Çelik, Technorati, Inc

Contributors

• ...

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:

1. If the name is one word, attempt implied nickname optimization
2. If the name is two words, attempt implied n optimization
3. For three or more words
   1. Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
   2. 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.