CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)

CHI-WEB@LISTSERV.ACM.ORG

Options: Use Classic View

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

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

Print Reply
Ash Donaldson <[log in to unmask]>
Wed, 14 Apr 2004 11:48:08 +1000
text/plain (77 lines)
Quoting Cindy Lu <[log in to unmask]>:
> Currently, Tab key is used to tab through the fields.  The Enter key is used
> to submit the form or activate a specified action button.  Enter key is also
> used for line returns in text areas.
>
> The request is from a client.  They think when a form contains a lot of
> fields for numeric data, it is more efficient to use the numeric key pad on
> the keyboard and use the Enter key to advance fields.

A Key Level GOMS analysis would show that, yes, using enter would be more
efficient if all the fields were numeric data and the data entry operator were
using a number pad for input.

How would users handle line returns in text areas though?  I think you would
find that having mixed fields such as these (with obviously mixed behaviours)
would cause an increase in errors and anxiety levels.  Unfortunately, increased
anxiety levels result in a narrowed focus of operations (ever seen someone
repeatedly hitting a button in frustration when it's obviously not doing
anything?), leading to even more errors if an inconsistent behaviour such as
this is present - a rather vicious circle.

Therefore, if this application requires the ability to enter line breaks in text
fields, I'd avoid using the enter key for anything but its default behaviour.

Quoting Elizabeth Buie <[log in to unmask]>:
> When should a web app act more like a web site, and when should it act
> more like a desktop app?
>
> Much as I hate to spout platitudes, some of these things have become
> platitudes because they work -- and this case cries out for ours.  "It
> depends."

Ahhh... Someone after my own heart.  Yes, "It depends".

Even though I hate the very notion of web apps for internal applications
(browsers are still so poorly suited to application development - why do people
insist on using them when there are much better options available?), I have to
constantly work on these types of projects.

One thing I have found in user testing is that if it looks like a browser and
the users are used to web browsers, they will generally treat it like a browser.

Of course the error rate is usually greater for whichever use (default browser
or web app modified browser behaviour) is less dominant for people i.e. if they
use a web app all day, then just do a little surfing after work, they will make
their errors surfing; if they use the web app less frequently, but research on
the net for most of the day, they will make their errors in the web app if
inconsistent behaviours are present.  Either way, it's a frustrating experience.

That said, I'm actually writing this e-mail in an e-mail web app I designed a
while back.  It acts nothing like a browser.  It has drag-and-drop, right-click
contextual menus, I can delete messages by scrolling through and hitting the
delete key... In fact, it acts almost exactly like a GUI email client (including
a 'perceived' instant response to every action).

So why don't people make errors with it if it is a web app that doesn't act like
a browser?  It looks nothing like a browser - it looks and acts exactly like a
GUI app.  In this case, perception is everything - regardless of the technology
being used.

This should be another consideration when developing web apps that have
behaviours inconsistent with browsers.

I hope this helps.

Best regards,

Ash Donaldson
User Experience Designer

    --------------------------------------------------------------
    Tip of the Day: Use the archives to research common questions
     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