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.
Related
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.
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.
I'd like to notify my users when something like a request failure occurs. However, I don't want to interrupt the user by using a popup style alert. I'm looking for something like when you change the volume on the device and that translucent icon pops up and fades away after a second or two. During the time the icon is showing, the user can still interact with the app as if it weren't there.
I looked in the HIG, but I couldn't find any such UI control that is native to iOS. Are there any good open source controls that do this?
There's an excellent control for a HUD-style popup called SVStatusHUD. I belive it does exactly what you're looking for:
I've seen how iphone users delete from lists - its generally a swipe action and then shows some minus/remove button.
I realize that it is counterproductive to implement iphone things on android because android users don't know this stuff.
I don't want to do that, I just don't know of a better/intuitive way to delete from a listview.
I've previously opted for doing "longclicks" on listview items, which will show an alertdialog asking if you want to delete or do other things, but this is never an obvious thing to do.
I've seen delete buttons that are shown in each view, but that messes with the layout of the listview, in a way that wasnt' considered in the wireframes.
What is a good intuitive way to allow the user to remove items from listviews on android?
Here's my two cents before I pitch my answer. Any one who has an android phone is going to know or eventually find out that longclicks often lead to another menu. Yes, it's not immediately obvious but they are going to figure it out just as iphone users have figured out the swipe action is to delete.
If you really want a fool proof way for a user to know how to delete, I would implement checkBoxes. (More on check boxes here)If the user checks the item, bring up a "soft menu" at the bottom that has a bunch of options normally associated with long clicks.
If you look at the gmail application and check a box, you'll see what I mean when I say "soft menu".
Another way you could go would be to implement check box, then have "menu options." Every android user should be able to see and figure out the menu button on their device, all devices have them. Make one of the menu options delete and you're all set.
http://developer.android.com/guide/practices/ui_guidelines/menu_design.html#options_menu
I agree that long click is horrible, but it is the standard on Android; people are more likely to be able to discover using this than any alternative gesture.
Also, put in a delete menu item on the Activity you get to after selecting something from the ListView.
In my view you should add checkbox to your list view and give a separate button for deleting items from list I mean to say that add a delete button in the layout in which your list view is also present and when user checks the item which he/she wants to delete and click on the delete button,the item which is checked by the user gets remove from list.
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 +