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/
Related
I am developing an application for the desktop with Flutter. I had to implement the form with multiple input fields. I really need to make the whole focus flow and I have used the FocusNode class to move from one input field to another. Everything is based on the submit event, so when I hit the Enter button on the keyboard it moves to the next field. It is pretty ok, but I have to change it from Enter key to Tab key which is more natural for the desktop users. Have you got any idea what can I do here to achieve such a result? Is there a way to trigger the submit event by different key (than Enter)?
This bug is for making it easy to bind keys to actions. Once that's complete, one of the intended use cases is to add tab support for form field navigation. There's been a lot of work in that area recently, so I wouldn't recommend putting time into working around this yourself.
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 want to know if there is any way to navigate Dialog components by pressing the Enter Key in the same manner natively implemented by the TAB key?
Though I haven't tried it by handling the keyDown and keyUp events certainly it seems doable. Though you may not be able to intercept the browser produced dialog boxes this way and other dialogs created using Window.alert(). How are you creating the dialogs ?
The tab key is the browser doing the work of changing focus - nothing special needs to be added, you'll find that tab works on any form on the internet (except where explicitly disabled for some reason...).
To move focus with the enter key, you must listen for the onkeydown event (focus change via tab also occurs onkeydown, so selecting this for consistency), check if it was the enter key, and if so, move focus to the next element in the list.
Typical tab focus behavior involves the browser checking the tabIndex of the elements on the page, and finding the next element on the page with a higher tabIndex, or the nearest subsequent sibling/cousin element. I don't have a method to implement this easily, so instead I'm going to focus on just going to the next widget.
GXT 3's FormPanelHelper has some handy methods to look for all Fields - this code could be used as a basis for non-GXT fields as well. Track all FocusEvent and BlurEvent from the fields found in the dialog, and use that to always track the currently focused field. Add a key handler to the dialog itself, to capture all key events, and check if one is the enter key. If so, figure out what the next field is from the currently focused field, and invoke .focus() on it - this will trigger the focus handler described above, so your bookkeeping will be updated correctly.
And as #eliran-m noted, consider leaving the tab key alone - don't get in the way of users navigating the way they are used to. Adding new functionality might be a good thing, but taking away expected behavior probably isn't.
When to use HyperLink and when to use Anchor?
When using HyperLink how to handle clicks?
com.google.gwt.user.client.ui.Hyperlink.addClickHandler(ClickHandler) is deprecated
com.google.gwt.user.client.ui.Hyperlink.addClickListener(ClickListener) is deprecated as well.
Doc suggests to use Anchor#addClickHandler, but how to use Anchor#addClickHandler when using HyperLink
Does it mean that if I need to handle click I should always use Anchor and never use HyperLink?
Great question, because it is so simple, and yet opens up what might be a whole new area for a lot of GWT programmers. I've up-voted the question just because it can be a great lead-in for people exploring what GWT can do.
Anchor is a widget for storing and displaying a hyperlink -- essentially the <a> tag. Really not much more exciting than that. If you want your page to link to some external site, use anchor.
Links are also used for internal navigation. Let's say I have a GWT app that requires the user to login, so on my first panel I put a login button. When the user clicks it, I would display a new panel with widgets to collect the user's information, code to validate it, and then if validated successfully, reconstruct that first panel the user was on.
Buttons are nice, but this is a browser, and I want my user's experience to be more like a web page, not a desktop app, so I want to use links instead of buttons. Hyperlink does that. The documentation for hyperlink describes it well:
A widget that serves as an "internal" hyperlink. That is, it is a link
to another state of the running application. When clicked, it will
create a new history frame using History.newItem(java.lang.String),
but without reloading the page.
Being a true hyperlink, it is also possible for the user to
"right-click, open link in new window", which will cause the
application to be loaded in a new window at the state specified by the
hyperlink.
That second sentence should help clear it up. The hyperlink is not changing the page in a URL sense (the way anchor does), though the URL will reflect the state of the program by displaying the "token" associated with the hyperlink appended to the base URL after a slash. You define the token. It would be something descriptive like "login" or "help" or "about". But this isn't a new page. There is no additional HTML file you've had to construct to display a help page, for example. It is the state of the current GWT app that is changing. Even if you "open in a new window" you are just running the same app in a particular state.
It looks like a link, but it is really a widget that manipulates the history frame, which in turn allows you to move the state of your GWT application. You don't write a click handler for the hyperlink widget, but a value change handler for the history stack. When you see that the "help" token has been put on the history stack, your handler will execute GWT code to attach to the RootPanel a FlowPanel with embedded HTML text with your help information. This is perceived by the user as a "new page", which is what he expects when he clicks on a hyperlink. The URL will be something.html/help. Now pretend he returns to this URL via the back button, not your hyperlink. No problem. You don't care about the hyperlink click. You only care that, somehow, the history stack changes. Your value change handler fires again, and does the same thing as before to display the help panel. The user still enjoys the experience of navigating through web pages, even though you and I know that there is only one web page and that you are attaching and detaching panels to the RootPanel (or whatever scheme you are using to display your GWT panels).
And this leads to a bonus topic.
This bonus is a bit more complicated, but ironically, it could help better understand hyperlinks. I say more complicated, but really, it helps solidify this notion that a GWT application is made up of a series of states, and that the web page on the screen is just the user's perception of those state changes. And that is Activities and Places. Activities and Places abstracts away this history frame manipulation, handling it in the background once you've set up a mapper with a GWT-provided class designed for this purpose, allowing you to break down your app into a series of activities, and as the user interacts through these activities he is put into different places, and each place has a view. Moreover, the user can move from place to place using browser controls like the address bar, bookmarks, history, and the backward/forward buttons, giving the user a real web-like experience. If you really want to get a grip on the conceptual difference between hyperlinks and anchors, you should try to learn this GWT topic. It can really make you change the way you see your apps, and for the better.
Hyperlink (or InlineHyperlink) is basically no more than a kind of Anchor with a ClickHandler that calls History.newItem and preventDefault() the event (so that the link is not actually followed).
Actually, Hyperlink won't do that if it thinks (and yes, it's only a guess) you right-clicked or middle-clicked (or ctrl-clicked) on the link (depending on the browser), to open the link in a new window or tab.
If you need any other behavior, then don't use Hyperlink and use Anchor instead. And if you want to add some behavior to an Hyperlink, then use an Anchor and mimic what the Hyperlink does. And you can reuse the HyperlinkImpl to have the right-click/ctrl-click handling (see links below).
But actually, if you need something that looks like a link and do something on click, but does not have a "target URL" (i.e. it shouldn't be right-clicked/ctrl-clicked to open in a new window/tab, or it wouldn't mean anything to do so), then do not use either an ANchor or Hyperlink, use a Label of whatever instead, and make it look like a link (but well, maybe you should use a Button and have it look like a button then; Google used to have link-alike buttons –such as the "refresh" link/button in GMail– and changed them to look like buttons when they really aren't links).
See also https://groups.google.com/d/msg/google-web-toolkit/P7vwRztO6bA/wTshqYs6NM0J and https://groups.google.com/d/msg/google-web-toolkit/CzOvgVsOfTo/IBNaG631-2QJ
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.