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.
Related
I'm looking for half modal that I can operate the back page.
(It's like when I tap a pin on Google Maps.)
I used showModalBottomSheet, but I can't operate the back page.
I searched for an option that would meet my request, but it didn't exist.
Is there any way?
I self-solved.
I use showBottomSheet, not showModalBottomSheet.
The problem is that my like button is quite at the bottom at the page,
And when someone clicks the like button, the dialog just gets cropped,
and I just can't do anything with it.
Did anyone have a similar problem?
The only way to fix this is by using some CSS to your page to move the dialog box. This is kind of a hack, but its the only way to really do what you want. The only downside is that the tiny triangle in the top left corner of the dialog will seem out of place.
One other option that does not involve moving the dialog is to make your page slightly longer.
I have an activity with a mayStop() method. I am having two issues with it that pertain to a hyperlink on the page.
The first issue is that if I hit refresh or the window's X I get a dialog box that wraps my mayStop() text with "Are you sure you want to navigate away from this page?" and "Press OK to continue, or Cancel to stay on the current page." That is fine.
When I hit the hyperlink, I only see my mayStop() text without the wrapping text. Why is that?
The second issue is that if I hit Cancel in response to the hyperlink click, hitting the link again results in not getting the mayStop() challenge at all. It is as if I am not hitting the hyperlink.
Has anyone run into these issues?
Any thoughts?
Thanks,
Doug
The difference in "behavior" is that the first dialog box is the one from the browser when you try to prevent the user from navigating away, while the other is PlaceController calling Window.confirm(). Each browser uses a different dialog box for the first case, so there's no way to mimic it for everyone, and it's probably not a good thing either (navigating away from the app vs. navigating within the app).
As for your second issue, the events are generated by the browser "history" changing; if you prevent navigating away (from the Place), the URL stays the same (there's noway to know what to do to "rollback" the change: History.back(), History.next(), History.newItem() but then you destroy the existing "next" history ?), so when you click again on the link, you don't make the URL change, and no event is fired.
It's expected that you use PlaceController.goTo to navigate when you use places, not Hyperlink or History.
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/
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.