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/
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss
|