Re: reset-button + "validate by direct input" (was: Validator and/or correct markup for empty table row)

On Wed, 28 Sep 2005, Frank Ellermann wrote:

>> Please don't. Destruction buttons ("reset buttons")
>> considered harmful,
>> see e.g.
> That article says "almost never helps users, but often hurts
> them."  Every user learns that lesson, once, and then "reset"
> is a feature and no bug.

Would you like to have them learn the lesson on _your_ page, though utmost 
frustration when they have spent half an hour typing something very 

Besides, it still does not help them, and it still hurts them. People 
forget things, and people misclick. The common design of putting a submit 
button on the left or (!) on the right of a destruction button greatly 
promotes misclicking.

>> on a typical browser, you can wipe out the contents of the
>> text input field by pressing the Esc key there. No questions
>> asked.
> Not with my browser.

Get another browser, then, if this bothers you and the matter is relevant 
to you.

>> This is bad software design
> Each piece of software or hardware has a "soft reset", that's
> standard design everywhere, because the "remove batteries and
> wait five minutes" approach turned out to be too clumsy.

This isn't about soft reset but about destructing user input.
Besides, if each software _has_ a "soft reset", then you won't need a 
"reset button", do you?

>> there is no need to create duplicate functionality by adding
>> a button.
> But it does not duplicate functionality for me - that's why I
> proposed class="hideme" (= don't show it for modern browsers).

As I wrote, if you want a wipeout functionality, get a browser that has 
it. Using a class attribute is guaranteed to not guarantee anything; 
remember that CSS is just optional presentational suggestions.

> My use of "validate by direct input" directly reflected the
> section "Exception: Use Reset for Repeated Form-Filling" i

It is far more common to want to type in something and have it validated, 
then do other things, than to use the feature repeatedly. Hence the 
argument does not apply. Even if it did, the destruction button should not 
be close to the submit button.

> Besides, that's not the only exception, for a complex form
> with numerous choices and defaults "reset" is a nice feature -
> at least with my old browser "reload" won't do what I want.

Again, if your browser does not do things that you regard as essential, 
consider getting another browser.

The more complex a form is, the more damage a destruction button will do.
If "reset" is important for a particular form, then _make_ it a decent 
reset. This means, with the present technology, a button created with 
JavaScript and working via JavaScript, resetting all the fields or 
selected fields, _after_ prompting for confirmation.

> The simple "direct input" is huge and ugly on the main page,
> only a few geeks need this.

Regarding the main page of the validator, I tend to agree with the idea. 
It does not need the direct input field but links to pages with such a 

On the page for validation by direct input, it's hardly extraneous.
Admittedly, the input field should be _larger_ (e.g. with width: 100%), 
and the page  could contain some JavaScript-generated buttons for 
inserting some "standard" document skeletons. You know, documents with 
suitable DOCTYPEs and some obligatory or common markup, so that you can 
just type in a little markup to check it. A bit like in the WDG validator 
but using a different technology. Perhaps, actually, best with links to 
versions of the page with such stuff prefilled in the textarea elements, 
so that we don't need client-side scripting at all.

> Those geeks would also want the
> extended features, always.

Hardly. There's not much "extended" or "advanced" about them, useful as 
they may be at times.

> Without a simple form on the main
> page the "recent updates" are immediately visible, and that's
> IMHO more important than this huge form.

Only geeks are interested in "recent updates".

Updates are useful to normal people, if they involve real improvements.
Knowing that something has been updated is much less relevant. If you can 
see (from the appearance or functionality) that things have improved, 
fine. If you can't, what's the point of telling that something has been 
updated. If there's a new feature that people might not know about and 
need to know in order to utilize it, well, you could tell about it, but 
that's something completely different from a chronology of events.

Jukka "Yucca" Korpela,

Received on Wednesday, 28 September 2005 20:09:38 UTC