In GTK+'s official reference, the GtkMessageDialog page, it says,
Note Please note that GTK_BUTTONS_OK, GTK_BUTTONS_YES_NO and
GTK_BUTTONS_OK_CANCEL are discouraged by the GNOME HIG.
I read the latest version of GNOME HIG and found this page.
Place the affirmative button in the lower right
corner of the alert.
If the alert was produced in response to a user's
action, place a Cancel button immediately to the left of the
affirmative button.
I can figure out why GTK_BUTTONS_YES_NO and GTK_BUTTONS_OK_CANCEL are discouraged(because the negitive button is to the right of the affirmative one). But this has nothing to do with just one OK button on the dialog window. So, why GTK_BUTTONS_OK is discouraged?
And sorry about the title. I didn't actually see GNOME HIG discourages it.
On the very same page you linked to:
Button Phrasing
Write button labels as imperative verbs, for example Save, Print. This
allows users to select an action with less hesitation. An active
phrase also fits best with the button's role in initiating actions, as
contrasted with a more passive phrase. For example Find and Log In are
better buttons than Yes and OK.
This is for your Yes/No and OK/Cancel point.
Related
I term of usability, I'm wondering what's the best solution to display my confirm message.
I have a long form, and in small screen I can't see the top of the form.
When I'm submitting my form, where is the best position for my message "Your information has been saved"?
In the top of the form, and I add an automatic scroll up ?
In the bottom close to the save button?
In a dialog box?
Other solutions?
I tried to find that on Internet but nothing really interesting. Please quote your source if you have an answer for me.
Thanks!
If this is the only place in your application that has this functionality, it doesn't matter so much; if you already have it working one way or the other somewhere else, consistency is the most important.
Where will the user need to navigate to next? If navigation is at the top, auto-scrolling them to the top and showing a message there might be appropriate.
If the navigation is on the left side, auto-scrolling will lose the user's place in the page, which will make navigation harder. In this case, tell them right next to the submit button.
If there's only one place they can navigate to next, skip the AJAX and do an interstitial "success!" screen that also takes them to the next place they'll want to navigate.
But most of all? Consistency with the rest of your app.
(Duplicate of this question, but I figured I could try again, since that one wasn't answered...)
The UISearchBar on the iPhone has an option showsSearchResultsButton. When you turn it on, it shows a button with horizontal lines inside the search bar, and you can implement a callback that will be called when the user presses it.
The thing is, I can't find a single place on the Internet where it says what the intended purpose of this button is. I know I could make it do anything, but I'd like to know what it's actually for. Should it show a history of searches, or all items without filtering, or what?
It's simply to show search results when tapped.
Where Apple uses this is in their iPad App Store application. If you go to the Categories tab you'll see various app categories. Search for an item, you'll get a list of results, and when you press "Done" you are shown the categories screen again. Your previous search term is still listed in the search field, but now the Search Results Button appears in the field. After tapping this, a UIPopOver is displayed, showing a text list of the results from your last search.
I am trying to find the most usable/accessible way to implement a simple form dropdown list which will sort a list of products by pice and alphabetical order.
In your opinion is the dropdown more usable when there is a button that governs its submission or when it automatically submits onchange of the dropdown?
The research I have read is both for and against such methods and there is a variery of implementations on the web so interest to hear the thoughts of the community.
Thanks in advance
As a blind computer user either method works fine. I find that having a button to click is slightly easier for me then the onchange event firing. I wouldn't say it's a big enough difference to take into account though assuming the majority of your users will not be disabled. If your targeting specifically blind users I would not use the onchange event.
So long as you do not change focus or navigate to another page when the selection changes, either approach should work. The classic example of a problem dropdown is where it contains a list of other pages on the site, and navigates as soon as the selection changes. This prevents a keyboard user from using the list; they can't browse it, and can't navigate to any pages beyond the first selection, since it's impossible to navigate past those. So in cases where focus changes or the page navigates as a consequence, having a separate action (eg. Go button, or handling enter) to cause the navigation to take place is essential. This is likely where the advice you've read is coming from.
In this case, however, it sounds as though you are just updating content elsewhere on the page, and not changing focus or doing navigation. Simply resorting existing content should be fine.
Depends on your users and their respective expectations and the context in which it's presented.
As a blanket, general statement, you should have the drop down accompanied by very obvious submission button. That is the safer approach.
If you are refreshing page data or if the focus moves away after the dropdown option is selected, you should use a button to be accessible. If you fire the event on change, blind or keyboard-only users will not be able to use the dropdown menu at all if they are on windows with ie and chrome (so added together, a majority of the people on windows). As soon as they use the arrows to scroll down and make a selection, the first option they hit will be selected and the page data will refresh or the focus will move, making it impossible for them to navigate or select the second option, third option, etc. Below is a thorough explanation with examples so you can see what I mean.
Designers definitely don't like the buttons, but if you are blind and on chrome/ie, it is impossible to use a lot of dropdowns without it. I'm guessing Jared uses firefox or a mac.
http://pauljadam.com/blog/javascript/onchange-event-on-a-select-inputjump-menu-accessibility-problems/
After the right '+' button is pressed the item in that view is added to favorites and an UIAlertView is shown on screen saying "Added to Favorites". After it is added to favorites I make the '+' button disappear so the same item doesn't get added again to favorites. I am not sure if this ok with Apple's Human Interface Guidelines instead should the '+' remain there and if pressed again say "This item is already in favorites"?
Any help will be appreciated! Thanks
I wouldn't use the AlertView for this. By showing the alert, you force the user to confirm reading some confirmation message and taking action (by pressing the OK button). It is a good idea to provide feedback that the favorite was successfully added, but this should not be an intrusive alert. Perhaps you can use other design patterns for favorites, such as a star that lights up when pressed to indicate that the item is listed as a favorite, or perhaps an animation effect that 'moves' the selected item to a visible 'favorites' category.
The Human Interface Guidelines have this to say about the Alert view (in relation to your question):
Avoid creating unnecessary alerts.
These alerts are usually unnecessary
if they:
Merely increase the visibility of some
information, especially information
that is related to the standard
functioning of your application.
Instead, you should design an
eye-catching way to display the
information that harmonizes with your
app’s style.
Why not have two states for the button ? A "selected" state (for example negative contrast) showing the item is in favorites, and a "normal" state indicating it can be taped.
This way you can add/remove from favorite using the same button, and in a less obstructive way than with a UIAlertView.
I also suggest you use a ★ instead of a +
I am compulsive and like visually clean designs.
Theres a pop up in my app that tells the user that there's an error.
I made a clear button over the entire pop up (about 200x100 px) so the user can just touch the notification to dismiss it.
But i'm afraid the user might not know that you can just touch the pop up to dissmiss and would go crazy looking for the "OKAY" button.
Do you guys think the OKAY button is necessary or is a giant clear button overlaying the notification good enough?
note: the whole notification actually looks like a button because of rounded corners and some button like borders.
Whatever users can misinterpret, they will (just look at some of the low ranked App store reviews for examples).
So, unless it clutters your UI and/or makes things even more confusing, a clear indication of how get rid of or move beyond your popup will certainly reduce the chances for any user confusion.
I like the idea of your design, but I would go for an OK button. There might be people in the world who don't understand it and blame your app.
Or you leave out the button and make the notification disappear by itself after, say 5 secs.
Or you could go the Microsoft way:
- add the "Okay" button
- add a smaller checkbox with the caption "don't ask me again"
- when the okay button is clicked and the checkbox is marked, open an additional dialog notifying the user that the Okay button will no longer be displayed, but that they can clear that setting in the preferences menu
- create the preferences menu as described
Now who says Microsoft suck at UI ?
You should use the OK button. Not only will it be more familiar for users, but you won't have any problem with Apple's approval process. Depending on the reviewer they might reject the app for not conforming to the Human Interface Guidelines.