submit button for list of items

30 Oct 2006 - 1:20pm
7 years ago
7 replies
817 reads
mtumi
2004

Hi all -

I have a list of items that are turned on/off with checkboxes.

These can work instantly, via AJAX, or with a submit button. I
prefer the former, but am wondering what if any additional feedback
is necessary.

If people know of similar interfaces, where checkboxes work without a
submit, I'd appreciate it if you could bounce them my way.

This seems to get at a larger question as well - how fast are people
re-learning these new models of interaction on the web? Should you
always include a submit button to accommodate those people who are
used to doing things the "old" way?

Michael

Comments

30 Oct 2006 - 3:19pm
Janna DeVylder
2006

I think Kayak.com <http://kayak.com/> has an interesting way of showing the
search result set has changed as dimensions of the search on the left are
checked or unchecked, especially in the flight path when there are multiple
variables and results to shift.

I think we can do without 'submit' if we can give immediate transition
feedback. The Yahoo pattern library has some good examples of that, as well.
When using AJAX-type controls, we're having to create a parallel accessible
version, so ultimately we're always needing to think of how that button
could fit in if need be.

Janna DeVylder

30 Oct 2006 - 2:40pm
Chris Jackson
2006

Hi Michael,

The results page for www.kayak.com updates automatically when search
options are changed. An "Updating Selection" message appears while the
update is made. Since the message appears right after I change the
selection, it's unlikely I'd miss the feedback. I got used to the AJAX
very quickly and like its speedy response.

Chris

Michael Tuminello wrote:
>
> If people know of similar interfaces, where checkboxes work without a
> submit, I'd appreciate it if you could bounce them my way.
>

--

Chris Jackson
Information Architect
Dynamic Diagrams, Inc.
www.dynamicdiagrams.com

30 Oct 2006 - 3:59pm
Robert Hoekman, Jr.
2005

Great question. I'm actually going to be writing an article on this soon.

I think situations like this always demand some sort of visual feedback,
because a big part of good design on the web is a matter of gaining the
user's trust. If a user is not offered any clue that something she
explicitly told the app to do has been done, then how is she to trust the
site? She'd have to double-check the page to see that the change "stuck".

In the case of things like admin pages and such, there's usually a Save
Settings button or something that saves everything and the switch to another
page is the cue that the action has been completed, but if you're having
users switch settings on and off via checkboxes and not requiring anything
be explicitly posted, then some other cue is needed.

The yellow-fade technique could be a good way to go. Click the checkbox and
a text msg is shown using the yellow fade confirming the change. Or you
could display a single message for every change made, building up a list of
them in a common area of the page (like above the form or something). You
could also simply stick with the Save Settings button idea, but use AJAX to
post the changes to the database and then show a single message beneath the
Save button that confirms the changes.

There are many ways to do this, but I think the need for quality feedback is
vital to the experience and should definitely be designed intentionally.

-r-

On 10/30/06, Michael Tuminello <mt at motiontek.com> wrote:
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Hi all -
>
> I have a list of items that are turned on/off with checkboxes.
>
> These can work instantly, via AJAX, or with a submit button. I
> prefer the former, but am wondering what if any additional feedback
> is necessary.
>
> If people know of similar interfaces, where checkboxes work without a
> submit, I'd appreciate it if you could bounce them my way.
>
> This seems to get at a larger question as well - how fast are people
> re-learning these new models of interaction on the web? Should you
> always include a submit button to accommodate those people who are
> used to doing things the "old" way?
>
> Michael
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

30 Oct 2006 - 5:24pm
Robert Hoekman, Jr.
2005

> The results page for www.kayak.com updates automatically when search
> options are changed. An "Updating Selection" message appears while the
> update is made. Since the message appears right after I change the
> selection, it's unlikely I'd miss the feedback.

Ironically, the "updating results" message IS the feedback, so it's not that
you're not missing it, it's that it's so effective you don't even consider
it feedback anymore. :)

-r-

30 Oct 2006 - 6:17pm
DrWex
2006

My feeling on the instant-checkbox vs submit question has to do with
the reversability of the action. If it's doing something simple, like
filtering a list, then it makes sense and saves effort if the checkbox
takes effect immediately. On the other hand, if the check/uncheck has
a consequence, particularly one that is difficult or costly to
reverse, then I strongly prefer a "Submit" or other confirmation
button.

Essentially, for me, the question of which route to go depends on the
answer to the question "What is the consequence of a mis-click?"

--Alan

2 Nov 2006 - 7:17pm
Christopher Fahey
2005

> I have a list of items that are turned on/off with checkboxes.
> These can work instantly, via AJAX, or with a submit button.
...
> Ironically, the "updating results" message IS the feedback,
> so it's not that you're not missing it, it's that it's so
> effective you don't even consider it feedback anymore. :)

The whole idea of a "submit" button harkens back to a time when interfaces
were locked into strict states due to the limitations of (a) memory, (b)
speed, and (c) programmer skill and creativity.

But nowadays computers are faster and programmers are better (or at least
they have libraries to leverage), so in many cases where a submit button
might be considered de rigeur, perhaps a submit button is hardly necessary
at all. I won't cite examples, I'm sure you can think of plenty.

Maybe we should decide to go with more efficient UI design even when it
defies user expectations and assumptions, simply to push the envelope and
improve the overall "base" of the quality of user interface design. Yes,
such changes may be confusing or frustrating to users at first. But unless a
critical mass of UI designers decide to break the mold and go with a new
paradigm, we'll be stuck with inefficient legacy UI design patterns.

This is the rationale, for example, for why many web designers and their
companies jumped on the 1024-width bandwagon seemingly a year or two early
-- they wanted to lead the way, even at risk of writing off some users. They
were comfortable pushing users, too, to upgrade their systems. This is a
good thing for the rest of us, I think.

-Cf

Christopher Fahey
____________________________
Behavior
http://www.behaviordesign.com
me: http://www.graphpaper.com

3 Nov 2006 - 4:54am
maglez@btintern...
2006

For a desktop application or a AJAX kind web page, we don't need the submit button any more, all
checking can be done on the fly so the user will know, beforehand, if all data that he or she has
input comply with the proper standard.

You have two kind of fields, those that must be filled up and those that are optional.

Those fields that must be filled up will have an red asterisk.

Those fields that has been filled and its content doesn't comply with the proper format will have
a reddish background. You check if a field's content comply with a given patter through RegExp,
http://en.wikipedia.org/wiki/Regular_expression. When the user moves to a different field, the
application will check against that field's pattern to see if the input data comply with that
specific pattern.

Once all must be fill up fields are filled and comply with their patterns, the submit button will
get activated.

There are more interaction to account for on this scenario, it's just an example to make my point
that we don't need to press the submit button to find out that we have to fill up some more fields
or that we mistook on a number when we input the credit card number. Credit card number can be
validated half the way beforehand, those numbers must comply we a formula, obviously we could
input a wrong credit card number that comply with the formula but this will make half the job.

For a web page I think we have to continue calling that submit button just like that, Submit. For
a desktop application could be something else like Continue, Proceed, Submit...

Maglez.

--- Christopher Fahey <chris.fahey at behaviordesign.com> wrote:

> [Please voluntarily trim replies to include only relevant quoted material.]
>
> > I have a list of items that are turned on/off with checkboxes.
> > These can work instantly, via AJAX, or with a submit button.
> ...
> > Ironically, the "updating results" message IS the feedback,
> > so it's not that you're not missing it, it's that it's so
> > effective you don't even consider it feedback anymore. :)
>
>
> The whole idea of a "submit" button harkens back to a time when interfaces
> were locked into strict states due to the limitations of (a) memory, (b)
> speed, and (c) programmer skill and creativity.
>
> But nowadays computers are faster and programmers are better (or at least
> they have libraries to leverage), so in many cases where a submit button
> might be considered de rigeur, perhaps a submit button is hardly necessary
> at all. I won't cite examples, I'm sure you can think of plenty.
>
> Maybe we should decide to go with more efficient UI design even when it
> defies user expectations and assumptions, simply to push the envelope and
> improve the overall "base" of the quality of user interface design. Yes,
> such changes may be confusing or frustrating to users at first. But unless a
> critical mass of UI designers decide to break the mold and go with a new
> paradigm, we'll be stuck with inefficient legacy UI design patterns.
>
> This is the rationale, for example, for why many web designers and their
> companies jumped on the 1024-width bandwagon seemingly a year or two early
> -- they wanted to lead the way, even at risk of writing off some users. They
> were comfortable pushing users, too, to upgrade their systems. This is a
> good thing for the rest of us, I think.
>
> -Cf
>
> Christopher Fahey
> ____________________________
> Behavior
> http://www.behaviordesign.com
> me: http://www.graphpaper.com
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

Syndicate content Get the feed