0

I'm working on a Unity app:

The first menu has users choose a couple of items in an accordion list: When one parent button is clicked, then a extended list with all of the child items is shown below it. When the same button is clicked again, then this list is hidden again. Only child items can be selected for later use.

This menu supports both mouse and keyboard input/navigation: You either move the mouse and click LMB or use ↑ and ↓ to navigate from button to button, then press Enter to interact with it (=unfold/fold parent or select child).

Buttons in Unity have multiple states that you can set a color for:

  • Normal Color (button is none of the below)
  • Highlighted Color (mouse cursor is over the button)
  • Pressed Color (LMB is held down over the button)
  • Selected Color 1 (currently active item for keyboard navigation, only parent button: Becomes active when a button is clicked (=LMB released) or Enter is pressed)
  • Selected Color 2 (only child button, becomes active when a child button is clicked or Enter is pressed on it, overrides all other colors)
  • Disabled Color (button can't be interacted with - not used)

The problem I've come across:

The very first button in the list is selected at the beginning. When I now hover the mouse cursor over the third button in the list, then that one switches to the "highlighted" state, while the first button is still "selected". When I press ↓, then the second button becomes selected, while the third is still highlighted.

Here's a screenshot:

Shows how the selection changes when the "down" key is pressed while the mouse cursor hovers over another button

  • White = Normal Color
  • Light Blue = Selected Color 1
  • Orange = Highlighted Color

Disclaimer: These are only temporary colors, so it's easier to distinguish between the button states. I intend to merge the "Pressed" color with "Normal" in the finished app, as it doesn't add any information of value.

This is a special case because you usually don't select multiple list items in game menus without there also being horizontal navigation (like "on" and "off" buttons for a single option), so there aren't any examples (that I know of) that I could just copy.

What behavior would you expect here? Is there any kind of "official" guideline for vertical-only button navigation? Should the fourth button have become selected because the mouse cursor was over the third button or is all of this way too complicated and I should just narrow it down to three colors: Normal=Highlighted=Pressed, Selected 1 (navigation or parent) and Selected 2 (only child)?

Improve this question
2
  • I'm not clear on what these buttons do - sounds like they are not for navigation,or maybe even for taking action, but some kind of multi-select of items? Can the user select more than one button at a time? Do the buttons remain selected? Can you explain more a little more about the context here? Commented Jul 21 at 15:00
  • @Mattynabib Yes, it's multi-select. The parent buttons display or hide their own child buttons. The user has to select at least one child button, which act like a toggle (one click to select, second click to deselect). The information that is connected to the selected child buttons (only within a single parent, never across multiple parents) is then used in the next step, which is reached by pressing the "okay" button below this list (not shown in the screenshot). Commented Jul 22 at 8:32

1 Answer 1

Reset to default
1

Based on your reply to my question above, I guess my main curiosity is why you are using a dropdown and button paradigm - two well-understood UI patterns - to accomplish what appears to be something of a form or wizard, with options which could maybe be better understood as a series of sections with checkboxes, radio buttons, or more recognized toggles of some kind.

Even something as simple as a more obvious multi-select-list-like structure could be easier for the user to parse; hover state is clear enough (the light gray) and very distinct from the selected state, which is a well-recognized form:

image of a multi-select tree list

I still don't feel like I know quite enough about your flow or context to give you more robust input, but maybe that helps?

Improve this answer
10
  • 1
    Based on the info shared so far, I agree with Mattnabib's answer. In particular due to two issues with the orginal design, both of which affect accessibility: 1. Buttons trigger actions, not select options from a list. Using buttons for that latter purpose screws up screen reader output due to its semantic difference from actual selector controls. 2. Color changes alone are not enough to reflect status (color blindness!); status should always be reflect by additional text and/or shape changes. This answer here ↑ addresses both issues. I am curious, tho', to learn more about the problem. 😎 Commented Jul 23 at 1:20
  • 1
    Sorry, it looks like I omitted some information that is important to understand my design: This app is also going to be used in VR, so I need big buttons that can be easily selected with the VR controller rays. This is also the main menu that is centered on the screen (not a toolbar menu), you have to interact with it to progress. Furthermore, only 0-1 parents are unfolded at any time because child options can't be mixed. If you open a parent, all the other ones are closed automatically and their children are deselected. Did you create your menu in Unity? How does keyboard navigation work? Commented Jul 23 at 8:42
  • 1
    @JochenW I: No worries, there are indeed no buttons in my menu that select options: The parent UI elements are actual buttons and their only purpose is showing and hiding their children (they trigger the fold/unfold "action"). The children are toggles, which is Unity's version of a checkbox, I just made them bigger and removed the checkmark. Their checkmark is basically the "Selected color 2" (that's why there are two of these) but adding an extra checkmark on the right side is probably not a bad idea, thanks! Commented Jul 23 at 8:51
  • @JochenW II: How do you show the active element (!= selected/checked child!) of keyboard navigation to account for blindness? Would my narrowed down version work: One color for the Normal, Highlighted and Pressed state (probably white), a second for the active element of keyboard navigation and another for selected="ticked" children? Commented Jul 23 at 8:58
  • Hi @Neph, thanks for your thoughtful follow-up comments! πŸ‘ I: The issue with <button /> elements goes a bit deeper than what a seeing user experiences. It's that screenreaders (that read out what's on screen for users with impaired sight) interpret buttons differently from [navigation] links and selector widgets: buttons should always trigger actions, links should always take the user to a particular location, and selectors should allow users to make, well, a selection. 😁 Commented Jul 24 at 20:51

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.