I have a window which shows a table on the left half. On the right half I display properties of the item which is selected in the table. The user can now change these properties.
The properties are represented by different kinds of controls: textFields, sliders, numberSteppers and popUpButtons.
The user can - besides using the mouse - use the tab key to navigate through the UI Elements. When the table has the focus tab will select the first editable item on the right side, then tab walks through the items and after the last item will go to the table again.
When the table has focus and I change the value of a popUpButton or move a sliderthe default behaviour of the API (Apple's Cocoa) is to change the value but keep the focus on the table.
My intuition would tell me that after changing a control element it should have the focus (i.e. become firstResponder). But I checked some of macOS' preference panes and they behave similarly.
In Apple's Human Interface Guidelines I do not find mention of that specific topic.
So my question is:
Is there a guideline or at least best practice an app should follow regarding if a control element like a popUpButton or slidershould get the focus when clicked or edited?
Related
I am using SWT tables in my project and there are few columns which are having longer strings which are not completely visible by default (for ex. path to a file location). Though I have tooltip to show the content and using mouse we can increase the column width to see the complete value.
Is there a way to do it with only keyboard usage?
Note: This question is more related to accessibility.
The following answer is based on my experience under windows. It can be different for other OS.
I'm afraid that there's no keyboard-only default way to adjust the size or reorder the column in a table, tree view or list view.
This is true not only with SWT but also with all other frameworks based on native win32 such as wxWidgets.
You must provide a keyboard-only way to resize and reorder columns yourself. here are a few ideas implemented by some applications:
Provide an option somewhere in the application that opens a dialog box with a checkbox list of the different columns. Ctrl+Up/Down to swap two items. Check/uncheck an item with spacebar to make the column visible or invisible.
Make the headers focusable. Use Shift+Left/Right to resize, Ctrl+Left/Right to swap two columns. Application key / Shift+10 opens a context menu where you can check/uncheck columns to show/hide and an option to open the column selection dialog box.
Some screen readers allow to do it by simulating mouse operation in some way. For example, use Jaws cursor, click lock on a header, release lock on the header to swap with.
But it's quite complicated, not always reliable, and thus very rarely actually used.
This is a very good question. I would be happy to give 100 rep to someone giving an answer being for windows and:
generic, working by default, everywhere or in most cases
Independant from screen readers (Jaws, NVDA, etc.) and techniques that simulates the mouse with keyboard (mouse keys)
Unfortunately, I don't think it exists.
I have implemented a slickgrid and activated keyboard navigation.
When the users is scrolling down using the down-arrow key and reaches the last of the currently visible rows, the grid loads a whole new section of rows and places the selection at the top.
My user tests have all included a complaint about this behaviour as they all find the jump jarring.
I would like to implement behaviour, so the grid scrolls just one line at a time, when I press the down arrow while the last visible row is selected.
I was wondering if there might be some setting, I have overlooked, or if anyone has some suggestions for how to approach the task of adding this behaviour.
(the "problem" is the same, when you scroll upwards - only reversed of course)
This is controlled by the doPaging argument in scrollRowIntoView(row, doPaging) (https://github.com/mleibman/SlickGrid/blob/master/slick.grid.js#L2662). There's no setting to control that behavior, but you could easily add one.
It was initially written this way to make keyboard navigation faster since continuously navigating down doesn't have to do as much work as it would have if we were updating the grid on every 'row down'.
I'm trying to have a feature to allow users choose two different methods of cost calculation: either they can enter a yearly cost breakdown on a datasheet (2010: $10,000, 2011: $12,000, etc) or they can enter a flat yearly cost multiplied by the number of years they select.
If I were developing another kind of web application, I'd have radio buttons to select two different options. One option would display the datasheet, and the other option would display two text fields to enter values into. However, I understand that you can't have radio buttons in Access 2010 web databases. Also, is it possible to make elements appear and disappear based on a combo box selection?
If not, perhaps I could have two different combo box options: "enter yearly cost breakdown"
or "enter flat yearly cost," which open the correct respective forms as pop-ups.
So, 1) can I have Ajax-like appearing and disappearing elements as triggered by a combo box (or ideally, radio buttons), and 2) if not, can anyone think of another clever way of doing it?
Sure, you get a nice effect by using a tab control. You can place controls and even a sub form on that tab control.
So, you build a screen like this:
Then, simple set the visible property of the second tab = No. This will hide the tab (don't change this until you built the page since it will hide it! (use property sheet to hide/un-hide during development).
Now, add some code to the after update event of the list box. Like this:
In the above, I have named the tabs PYear and PFlat.
The result is this (this is a animated gif I inserted):
Of course, you really probably could just dump the whole "list box" selection, and use a screen like this with the tabs (tabs are good UI, and users tend to grasp them quick):
So, you can hide a "set" of controls, and it really far less work and hassle then writing a bunch of JaveScript anyway. As noted, the "set" of controls you drop into each of the tabs can be sub forms, and also that of continues forms. So, the "hiding" as a set does work well in this case. I did have some format issues and found that I had to "start out" with the 2nd tab dispaled first (the first one being hidden). As noted, the listbox selecting is nice, but one could likly just go with using tabs in the first place.
Simple version
Is there any way to maintain focus on menu after clicking a menu command?
Detailed version
Specifically, I've made a menu with some menu item with checked property. The problem is that each time I click checked menu item the menu lose its focus. It can be pretty annoying when there is a number of menu item with checked property and I want to manipulate them at once.
The most elegant solution for the problem would be maintaining focus on menu, but I can't find a way to apply it. Is it possible? And if so, what's the way to do that?
Even if there would a solution for it, sooner or later you will enter a situation in which a numerical or string property is changed via the menu, and then it becomes even impossible to keep the focus on the menu (while the dialog requesting the number or string is on the screen).
The first, simple alternative would be to put the checkable menu items on a toolbar or ribbon (just like Word does with Bold, Italic, Underline, ...). Numerical/string properties can then also be added on the toolbar or ribbon.
A second alternative could be to have a more complete configuration dialog in which the user can change all the configuration items. The configuration dialog can co-exist with the current checkable items, so users simply changing one check and users changing many properties all get a quick way of doing what they want.
You might also pose this question on https://ux.stackexchange.com/ (this sibling site is more oriented towards good user interface practices).
When using icon images without text captions, should the icon represent the current state or the next state? For example I have a block of text that I want to minimize / maximize or I want to toggle showing All User Records or just My Records. I'm sure there are compelling arguments for either side and know that consistency is key, but what are the arguments related to good intuitive user design?
There is neither standardization nor general human tendency on this. For example, MS Windows UX Interaction Guidelines specifies four basic kinds of toggling progressive disclosure control. Three out of four show the state-when-activated, while one shows the current state.
I believe if you test a particular approach on your users, you'll get different results depending on what you ask. If you show them a control and ask them what state the app is in, they'll tend to read the icon as if it were indicating the state. If you show them a control and ask them to change the state (where in some cases the state is already changed), they'll read the icon as if it were the state to achieve. It's precisely because of this they invented toggling buttons.
If you're lucky, users use the icon primarily for either reading the state or setting the state, and not both. Then let the icon indicate whatever the users use it for.
If they indeed use it for both reading the state and setting the state, you're basically hosed, but there are a few things you can try to minimize hosehood:
Use text in addition to or instead of an icon. When labeled with a verb (e.g., "Connect"), the control indicates the state the user gets. When labeled with an adjective or noun (e.g., "On Line"), it implies the current state.
If your lib doesn't support toggling icons, then consider using a checkbox control, if that's allowed.
If your lib doesn't support checkboxes, then consider two controls, one to set each state, where the current state is disabled. Not too good for reading the current state, but there's some precedence for this in pulldown menus.
Fiddle with graphic design or placement to make it consistent with the meaning you've chosen. For example:
Command buttons are always labeled with the action they commit, so if your icon indicates the state the user gets, then give the icon a raised appearance like a command button. If the icon indicates the current state, then give it a flat appearance.
Toolbar controls usually show the state they bring about, so put the icon at the top of the window if indicates the state the user gets. In contrast, icons in the "work area" of the window indicate objects or attributes, so icons there should show the current state. Icons at the bottom of the window (in the status bar) should also show the current state.
This has not been truly standardized. Folder icons, for example, show open folders when they are open and closed folders when they are closed. Same for disclosure triangles, etc.
However, in other contexts, this is not always true. In a movie player, the "Play" arrow shows when the movie is not playing, and it shows the pause icon when it is playing. Probably the thing to do is use your best judgment, then poll your users. If a preponderance of the people you test are confused by your icon choices, switch them around. Then test them again and see if your initial test holds up. :)
If you are just going to have one button to toggle between two states, then the button should represent the next state, because that is the action that the button will take when clicked.
You gave the example of text that is minimized/maximized. Think of any expandable tree interface you ever see in Windows. A minimized tree has a [+] next to it, because clicking the button will expand the tree. And a maximized tree has a [-] next to it for the same reason.
You could also try to make a toggle that is highlighted or "pressed down" like mihi says, but that might be more confusing.
I prefer the "next state" approach (click plus to expand, click minus to collapse).
One reason is that this is the most widely used approach, so doing anything else would confuse users (and me as well).
Another reason is that the "next state" approach looks more inviting for the user to click.
May I present Zoom's mute button:
It shows the current state, as an icon, and the action that will occur when you push the button, as text. In other words, the icon on the button is the current state and the label on the button is the new state. The current state and the new state are opposites, so the button appears to contradict itself unless you read it very carefully.
(I hate that button.)