[uf-discuss] Microformats in Form Fields

[Lachlan Hunt]

Ben Ward wrote:
> What if I was to mark up the form (and fields) with hCard classes?  

What a coincidence!  Just last night, I spoke to a couple of people 
about this exact concept at the WD06 after-party.  Then I got home and 
looked here and found this thread had just recently started! :-)

Generally, I think it would be a very good idea to do something like 
this, there are many benefits to it, especially for usability and 
accessibility.

Brian Suda wrote:
> By giving more structure to Forms you are accomplishing several
> things... the posibility to do some sort of introspection on data
> inputs. This would be a boon to spammers, you are using hForm, now
> they can easily paste their structured spam data into your comments
> fields. (i know using obscure fields names is not security - but it is
> a hurdle to automation).

I really don't think that's an issue.  Spammers already have many 
methods at their disposal for such automation.  For example, spammers 
already automate their comment spam processes because their tools are 
already aware of the markup structure used in many of the common CMSs. 
So, your argument is negligible because such automation is already a 
problem without this and the benefits for users (see below) far outweigh 
the negatives.

Ryan Cannon wrote:
> Alternately, you could use @name to supply your semantics instead of  
> @class.
> The server-side parser would need its internal data names  
> standardized on hCard
> (not a bad idea, IMHO).

I think that's a bad idea because you're tying the back end processes to 
the front end markup too closely.  A site should be able to use the 
microformat *without* needing to modify their back end to cope with new 
name=value pairs.  Besides, many server side systems don't allow such 
nice control over the the name attributes because they're automatically 
generated by the system when the HTML is generated.

> I don't know enough about the MIME type specs, but I wonder if we could
> reuse form @accepts to indicate that a form will take a particular
> microformat. e.g. something along the lines of:
> 
> <form method="post" action="/user/create"
> accepts="text/html+vcard"> ... </form>

That would be:

<input type="file" accept="text/directory;profile=vcard">

See RFC 2425.  It might also be useful to include text/html, 
application/xml and application/xhtml+xml in the attribute so that 
someone could upload either a vCard or an (X)HTML file containing an hCard.

Some of the things I discussed with others recently include the 
accessibility and usability benefits.

*Usability Benefits*

Auto-fill features may become more successful.  Auto-complete (which 
remembers previously used values) has been successful, particularly for 
password managers; but auto-fill (where the UA fills it in by 
heuristically guessing the field type) generally hasn't been.  I think 
this idea has the potential to do a lot for the auto-fill case.  It 
would reduce the amount of time it takes a user to fill out a form, 
particularly when they're continually asked for the same kind of 
information, such as contact info.

*Accessibility Benefits*

For a disabled user, filling out a form can be a long and tedious job. 
Depending on their input device, whether it be a keyboard, 
voice-recognition, on-screen keyboard or whatever else, entering the 
data manually can be quite time consuming.  Also, their ability to spot 
and correct errors may not be as fast as a non-disabled person, so the 
less manual data entry required each time, the better.

Additionally, someone with a cognitive disability may have difficulty 
understanding what some fields are asking for (especially if you've used 
some obscure label text they're not used to) and thus make it hard to 
complete.  If the UA could understand the field, it could help explain 
it or fill it out for them.

It would be so much quicker easier for them if their UA could either 
pre-fill most of the form for them or just submit a vCard/hCard.  For 
the latter option, a user wouldn't even have to know what a vCard or 
hCard was, their UA could recognise the accepted MIME type 
(text/directory) and ask them to select a name from their address book, 
which would then implicitly select (or generate) the right vCard.

*Types of Data*

There a many types of data often requested on forms, some more than 
others, but the tend to fall into several categories.  Some of these 
include the following:

* Personal/Contact information: name, DOB, phone, e-mail, URI, address, 
etc. (vCard/hCard)
* User signup forms: username/e-mail, password, confirmation password, 
forgotten-password questions and answers, etc.
* Comment/feedback forms.
* Event information: dates, descriptions, etc. (iCal, hCalander)
* Payment information: credit card number, card type (visa, mastercard, 
etc.) and expiry date; or BSB, account name and number.

For some of these types, there's work going on at the WHATWG to give 
them native controls in the browser (e.g. calandar widgets for dates, 
e-mail controls to allow selection from an address book and URI controls 
to allow selection from your bookmarks/history).

But even with native controls, it doesn't identify the purpose of the 
control.  e.g. a date control could be a date of birth, 
departure/arrival date, booking date, or whatever.  If we had a 
microformat that, for example, identified a particular date control as a 
DOB, it would be easy to auto-fill.

-- 
Lachlan Hunt
http://lachy.id.au/