The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Automatic refresh or "get results" button?

Hi to all !

  I have been bothered by a small&silly GUI design problem for a few days now:

  In a lot of places in my web application I have a page were I present some data based on an item the user has selected from a drop down list. There are two ways I can do this: Automatically postback to the server when the user selects an item in the list, or add a "Get" button to the right of the list. Then the user selects and item and presses the button. Question is.. which do you preffer?

 Both approaches have pluses and minuses. Automatic postback means less clicks .. but then again I don't like it when the page refreshes and the user is not expecting it (after all.. a dropdown list is not a submit button).

I know it sounds trivial, but it's been bothering me for a long time now, and I can't find any definitive arguments for one solution or the other.
Radu094 Send private email
Wednesday, January 17, 2007
 
 
You should always provide the button to the right of the select control. It makes it a lot clearer.
John Topley Send private email
Wednesday, January 17, 2007
 
 
One potentially undesirable effect ot using Autopostback is that you get lots of requests sent to the web server if the user sets focus to the SELECT control then scrolls up and down using the mouse wheel.
Joe
Wednesday, January 17, 2007
 
 
If the information is relatively static, then you can simply show/hide elements with Javascript. This is especially useful when you have a simply workflow, but certain choices expose other ones.  That replaces simply throwing them all on the page, multiple page refreshes, or using multiple pages. Its a quick and dirty trick, so sometimes it can look weird when large blocks of elements pop in and out suddenly (unless you add some graceful transitioning logic).

In cases that are pretty dynamic and can't be pre-render (e.g. user's query hits the db), then you can use AJAX. Its a tad more work and you may have other quirks to resolve if you roll your own stack (e.g. back button), but there are enough free/mature frameworks with pre-built widgets that can help. Its the ideal solution, but requires the most time.

So depending on the situation and your time commitment, the you can eagerly or lazily load the information. That's usually better than a browser refresh.

On your specific question, I dislike automatic refreshes in general. They can be a bit jarring, especially on pages that are scrollable.
Manes
Wednesday, January 17, 2007
 
 
Put me in the "dislike automatic refresh" camp as well.

I suggest thinking about whether you need the select boxes at all.  I personally detest the select box and feel it should only be used when absolutely necessary.  Typically the time to use the select box is when you have so many items to choose from that you cannot feasibly list them vertically on a single page.  Otherwise you should be able to create a sidebar with all of the items as links.  And if the list is really short, you can do just about anything navigation-wise.

Clicking a link is a 1-click activity.  Clicking in a select box is at minimum a 2-click activity (3-click with the button) with a rather large maximum click count.  The user may have to scroll, which will result in clicks up and down or on the scroll bar.
Barry Hess Send private email
Wednesday, January 17, 2007
 
 
By GUI standards, parameter-type controls don’t execute commands, but by HCI guidelines you should avoid unnecessary clicks –that’s why it’s controversial. The users, well, they’re just confused by our inconsistency. I don’t know how feasible this is in your case, but the solution is to make your control look and act like a *pulldown menu* rather than a parameter-type dropdown combo box.

If space allows, an even better solution is to present your items as a plain menu with no dropdown/pulldown. If you limit the menu to showing 5 to 10 items at a time (perhaps using a vertical scrollbar), it’ll still be reasonably compact. To make a choice, the user only has to click once (versus twice or thrice), at least for the menu items at the top.
Michael Zuschlag Send private email
Wednesday, January 17, 2007
 
 
The problem with "automatic refresh" is that as soon as you add a second control to collect a second parameter for the query, you HAVE to use a separate 'Get Results' button, otherwise you will get useless results everytime they change one parameter and intend to immediately change the other. So IMO unless your app is so simple that you will only ever have one query parameter anywhere, use a separate 'Get Results' button. People will bitch, though.
Greg Send private email
Wednesday, January 17, 2007
 
 
I've found that automatic refresh works well when I'm populating selection sub-criteria fields. If I select a state, I get a list of cities in that state. The assumption in this case is that yes, I did intend to pick both a state and a city.

If I'm expected to passively read the output data, I prefer a "get results" button. For example, if I picked California, Los Angeles, instead of California, Los Altos, I wouldn't want to have to wait for a list of all services in LA to appear before I can correct my mistake.
TheDavid
Wednesday, January 17, 2007
 
 
A good rule of thumb is to ask what's the next action the user will want to make after selecting something from the drop down.  If the answer is click "Get", then just get rid of the "Get" button and auto-refresh.  At this point, this is such a common technique that users are going to expect it when it makes sense.
SomeBody Send private email
Wednesday, January 17, 2007
 
 
I'd say go with a button. Less confusion and does not depend on whether javascript is available or not. The key is avoiding _unnecessary_ clicks, not avoiding all clicks that can be avoided. Just because you can doesn't mean that you should.
anona Send private email
Sunday, January 21, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz