Re: [css3-ui]? Proposal for ::error pseudoelement

On Tuesday 25 August 2009, Tab Atkins Jr. wrote:
> HTML5 defines a system of constraints that can be applied to form
> elements, and which prevent the form from being submitted while the
> constraints aren't satisfied.  When you try to submit a form with
> invalid elements, the UA should display a message informing the user
> of which controls are invalid, and why.

It's certainly a good idea to be as explicit as possible about what you 
expect the user to put in a form, but designing the UI to go with that 
is not something I would trust a Web author with. Usability is hard. 
Let the browser makers figure it out and let the user then configure 
his browser for his personal style of working and his level of 
experience. But let's avoid the situation where the same simple input 
box works differently from one Web page to another.

Even assuming the browser displays error messages at all, there is no 
need for the author to style them, because they are not part of the 
visual identity of the page. You normally don't even see them. But most 
of all they are part of a dialog between the user and his browser, not 
between the user and the author. (Try Tab's example in Opera, but make 
the window small: you can see that the error isn't rendered on the 
page, but in a separate window.)

What the best way to fill a form is, is not so simple to answer. There 
is a heuristic in usability that avoiding an error is often better than 
reporting it afterwards. That may result in, e.g., an input box for 
digits that doesn't let you enter letters. If the user tries typing a 
letter, depending on how experienced the user is, it may be enough to 
just issue a short beep (if the user is alone in his office, otherwise 
it might not be such a good idea). A message in a tooltip or the status 
bar might be useful if the user doesn't immediately understand what's 
wrong. And for a beginner, a modal message box might be necessary.

But avoiding errors isn't as simple as refusing them. A typical example 
is editing an entry: say the input has to be four letters. I type ABCE. 
A little later I notice that that wasn't what I meant, so I put my 
cursor before the E and type D followed by DEL. Result? One beep and an 
error box: "ABC is too short, please add another letter."

So sometimes you don't want to avoid the error, you want to postpone the 
checking and then see all the errors at once. As programmers know, a 
compiler that stops at the first error isn't very usable. Even if many 
errors are spurious, you still want to see them all.

So what's the best way? I don't know. But there are many things that 
could be part of the answer, from various sounds to changes in color, 
force-feedback mice, blinking backgrounds, changing focus, and LEDs on 
the keyboard that suggest keys to use or avoid.

Some browsers have drop-down menus with previously entered values, so 
you can use the arrow keys instead of the letter keys to enter your 
answer and thus avoid typos. (The Safari method of suggesting is 
particularly *un*helpful, but Konqueror works well; Opera's Magic Wand 
is yet another way to avoid errors.) And UIs for small devices (mobile 
phone, remote control, etc.) have a whole slew of input methods, 
adapted to the device.

I can imagine a browser that doesn't let you fill in a form, but opens a 
separate window with all the fields in a nice, clear table. (The w3m 
browser almost does that: it edits input fields in a separate part of 
the window and text areas in an external editor.) With such a browser, 
you could save your answers, edit them off-line, and the next time you 
can submit the form even quicker than Opera's Magic Wand.

Imagine that authors would be able to style all of the browser's hints 
and messages. Suddenly what looked like a hint before now looks like an 
error, and the beep that previously signalled success now means that 
something is wrong... Filling in forms would take three times as long.



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Friday, 4 September 2009 17:38:58 UTC