CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)

CHI-WEB@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Singletary, Mark" <[log in to unmask]>
Reply To:
Singletary, Mark
Date:
Tue, 11 Oct 2005 10:28:01 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (142 lines)
Tania, et al

My point is, a reset button does not "blank" the fields, it restores the
fields
to their as-loaded condition. It's not used for abandoning the screen, but
as a
restart of screen entry.  This client-side feature is built into the
browsers, and
is in fact part of the mozilla standard (http://www.mozilla.org).
As a basic feature of forms driven UI, it has been around since the very
early green screen days.

It's the reset function that is needed however, and not the button!  When
possible
I do not include a button and instead make the reset function available on
a menu. I agree that the button makes little sense, particularly if it's
labled
"reset" rather than "restore form" or some other more user-action label.

By non-trivial I mean applications that support more than the create-record
function.
I mostly build enterprise scale intranet, and extranet applications for
large corporations.
These are generally replacements for old main frame or client server based
applications
and the average user expects to use these screens hundreds of times a day
rather than
once or twice a month. These screens support the creation of new records and
more importantly
the update of previously entered records, so reset doen't blank the screen,
it restores the screen.
The form-reset function is a necessary element in this environment.
It's primarily used when the user has been interrupted in mid-entry and
wishes to be
certain of all the inputs prior to submission.  It is much faster and safer
for these users to
reset the screen and retype than to review the screen for changes.

As to the topic of screen abandonment, I am afraid a must strongly disagree.
While it is theoretically true that in a stateless protocol like http we
should
be able to just abandon a screen, most modern web applications do in fact
keep
a session state associated with the user(hence the log-in) and as a result
are quite statefull.  In statefull systems a load is imposed on the server
when users abandon a screen. Session maintenance and cleanup require
significant
machine cycles and memory, and UIs that encourage screen abandonment can
create
significant issues for server sizing and concurrent user loadings.

Mark Singletary

-----Original Message-----
From: Tania Lang [mailto:[log in to unmask]]
Sent: Monday, October 10, 2005 7:23 PM
To: Singletary, Mark
Subject: Re: DISCUSSION: reset button - aagghhh


Mark
I encourage you to post this to the whole list and not just me as the 
purpose of these forums is to share and discuss alternate views on a topic.

I disagree with most of your comments.  I can't think of many instances 
where users would want to reset a whole page and reset all values.  
Surely if most users were wanting to update their details they would 
only change one or a few fields.   I doubt most users would click on 
reset even if they wanted to change all the details on a form. Why can't 
they just type over the field entries they want to change and click on a 
button "Update details" or "Submit changes".

If they wanted to reset their whole page because they wanted to delete 
all their details and clear all fields, surely it would be better to 
offer users the ability to delete their account/details.

I am interested in your comment about blank forms being a condition only 
rarely found in "non-trivial applications".  I am not sure exactly what 
you mean by "non-trivial applications".   I have worked on many web 
applications where users have to enter data from a blank form (usually 
the first time they interact with the application). 

I disagree that the reset button is a standard and that users have 
adapted to the way you use forms.  I conducted some usability testing 
last month and asked users to abort a form they had completed without 
submitting.   Most of the users just left the page and went home without 
bothering to hit the reset button.  They said they would not be pertubed 
if the reset button was not there.

cheers
Tania

Singletary, Mark wrote:

>Tania,
>
>The reset button comes from the real world of application design.
>The purpose of RESET, and the only legitimate function is to
>reset the page to pre-edit values.
>
>This is very useful and in fact required in most in applications that
>allow the user to update information from a persisted record.
>
>>From the discussions so far I think that most of the respondents
>are conceiving of all forms as starting out a blanks, a condition,
>in actuality, only rarely found in non-trivial applications.
>
>The reset button is not just a piece of development foppery,
>it's a long-standing and expected element of a forms oriented interface.
>The "WEB" is not really a new and different environment, it's merely
>a new delivery protocol.  We have been putting out formware for over 40
>years,
>and standards have evolved and adapted to the ways people use forms.
>
>Classically, if the form comes up blank the reset button is optional,
>otherwise it's required.  The reset button is NEVER set as default,
>so it fires on an entry key or CR.
>
>Mark Singletary
>


**************************************************************************************
This message has been sent via the Internet. Internet communications are not secure 
against interception or modification. Worksuite therefore cannot guarantee that this 
message has not been modified in transit, and this message should not be viewed as 
contractually binding.

This message and any files transmitted with it are confidential and intended solely 
for the use of the addressee. If you have received this message in error please 
notify the sender and destroy your copies of the message and any attached files.
**************************************************************************************
Worksuite is the trading name of Worksuite, LLC and Worksuite Ltd., members of the Severn Trent Group.
For more information visit our website at www.worksuite.com

    --------------------------------------------------------------
    Tip of the Day: Quote only what you need from earlier postings
     CHI-WEB: www.sigchi.org/web POSTINGS: mailto:[log in to unmask]
              MODERATORS: mailto:[log in to unmask]
       SUBSCRIPTION CHANGES & FAQ:  www.sigchi.org/web/faq.html
    --------------------------------------------------------------

ATOM RSS1 RSS2