[Design Request] Adding Affordance to Pagination

[stuartjmoore]

As a new user, I wanted to share some ideas I had after booting up the system for the first time. I’ve grown to really appreciate the UX/IA behind the design; these thoughts are only to enhance what’s already there.

Navigating the menu took me some time to figure out, primarily due to issues with affordance—specifically, understanding what each button does before pressing it. Though, different controller layouts and the limited hardware buttons certainly contribute to the confusion.

One of the most perplexing actions was horizontally paging between menu screens. While I appreciate this feature, tapping left and suddenly seeing all the options change is quite jarring. The only indication of this action is the arrows on the “exit” row at the very bottom, which don’t clearly convey their function.

Concepts

Blades

A simple and familiar solution, reminiscent of the Xbox’s blade UI, would be to display the adjacent menu titles on the left and right sides of the OSD. This would help users see their current position and potential navigation options. The existing left and right arrows (icons in the font) could indicate which buttons to press to navigate.

Sticky Footer

Building on @SeongGino’s concept below, a space-constrained concept would keep the arrows and titles inside the bounding box of the current OSD, as a sticky (alway visible) row at the bottom of the screen. I don’t know the minimum width required for MiSTer, but the OSD could easily swap between tighter and wider variations for the display available.

Arrows

While these would add a lot complexity to the OSD code and layout, having to define which menus are adjacent to each one, a quick implementation could repurpose and move the “exit” row arrows.

Implementation

The most straight forward implementation I could imagine would be MenuWrite:

Main_MiSTer/menu.cpp

Line 732 in 59916eb

static void MenuWrite(unsigned char n, const char *s = "", unsigned char invert = 0, unsigned char stipple = 0, int arrow = 0)

Basically, if title s is STD_EXIT and the arrow flag contains OSD_ARROW_RIGHT or OSD_ARROW_LEFT, these arrows could instead be drawn permanently on-screen in either one of the concepts above. The titles would have to be set in another method.

Alternate

An alternative and simpler design would include pagination indicator dots below the OSD, similar to the ones in iOS. The bounding box would be custom drawn, but the filled and outlined boxes are already included in the font. While it may not be as explicit as the blade UI, it would provide users with a better sense of their location within the menu.

[birdybro]

I really like this idea. New users are often confused about there being more to the menu than they are seeing and this would give them an intuitive signal on what to do or what to try. :)

[SeongGino]

Hrm... would it be possible to use the bottommost line (or otherwise extend the OSD by one line) for page indication?

Assuming that physical size of the layout is the limitation (I'm not personally aware of what the technical "limits" of current OSD are), I'm sure even this would be a good indicator.

Not sure about colors, might be limited by how long the console name is, but the idea is to either change the highlight without moving the items, or shift the items so that the current selection is always in the center.

[stuartjmoore]

@SeongGino similar to today, but sticky. I like it. I’ll spec out the pixels and add it to the list.

It’s possible that we could do both based on the amount of space available. Even if you’re using NTSC, you should have ~480 pixels to play with, but don’t quote me on that.

[SeongGino]

@SeongGino similar to today, but sticky. I like it. I’ll spec out the pixels and add it to the list.

It’s possible that we could do both based on the amount of space available. Even if you’re using NTSC, you should have ~480 pixels to play with, but don’t quote me on that.

Hey, thanks! :)

To be fair, I don't think literal resolution is the limiting factor here--IIRC I'd read something from (I think) Sorg's recounts that there's not a lot of resources to go around with the current OSD as it is, which is why it's so functionally/aesthetically simple. Not sure if it's memory or (current) layout limits or what... but don't quote me on that. c;

But I'd love to see any improvements along the lines of what's being discussed here, if it's at all possible. The hidden pagination sure caught me off guard the first time I used MiSTer, know that for sure.

[sorgelig]

OSD can output only inside existing square. Any outside element will require additional precious BRAM resource, so it's no-go option.
Adding some footer/header inside existing square is possible but it's not super helpful because MiSTer uses only 2 level menu and current sub-menu name is displayed on the left side. It's also optimized for simple navigation by 4 directional key and 2 buttons. Adding additional navigation will require more complicated key combos which is not really useful.
Besides that. i don't see scenario where you need to jump between sub-menus regularly. Usually you enter one submenu to change the option and that's all.

[stuartjmoore]

OSD can output only inside existing square. Any outside element will require additional precious BRAM resource, so it's no-go option.

That’s good to know. I haven’t gotten around to compiling and playing with the code yet, but it definitely puts a damper on another idea I was playing with.

Adding some footer/header inside existing square is possible but it's not super helpful because MiSTer uses only 2 level menu and current sub-menu name is displayed on the left side.

This isn’t for sub-menus, it’s for the lateral menus at the same level. Those aren’t indicated anywhere and it was super disorienting as a new user where in the menu I was.

Sub-menus are a good comparison, though, as each row displays where it will direct you. But, the left and right button actions aren’t indicated anywhere, other than the off-screen “exit” menu row. Even then, the exact location named aren’t displayed.

It's also optimized for simple navigation by 4 directional key and 2 buttons. Adding additional navigation will require more complicated key combos which is not really useful.

This doesn’t change any navigation or input, it only displays what existing keys will do when pressed.

[SeongGino]

Pretty much agreed with Stuart; as it is without any indicators, it's hard to even know there is a sub-menu in the first place without being explicitly told about it beforehand. And even then, just being made aware of what the other screen is adjacent to the one we're on would be helpful.

I guess my proposal as it was drawn would be slightly redundant showing the selected page name at the bottom when the sidebar does that as well, but it would be nice to have it show what page being switched to correlates to what direction is being pressed on the input device/pad.

It's understandable that kind of info might not be prudent for those already experienced with MiSTer--but for the however-many-other-thousands of people jumping in via cheaper board options as of late, it would help to smooth over the UX a little with some basic labeling.

[sorgelig]

it's hard to even know there is a sub-menu in the first place without being explicitly told about it beforehand.

Every sub-menu is marked by triangle on the right. Pretty much distinguishable.

You are welcome to propose changes through pull request. I mean not drawing the pictures but modifying existing code to the way you think will be better.

[stuartjmoore]

Every sub-menu is marked by triangle on the right. Pretty much distinguishable.

Yes, but this isn’t for the sub-menu, it’s for the menus to the left and right of the one you’re currently in. The ones that aren’t marked anywhere.

You are welcome to propose changes through pull request. I mean not drawing the pictures but modifying existing code to the way you think will be better.

This is the proposal and RFC. We work out the design and ideas for someone looking to pick up work. There’s no reason to put in the coding effort if it’ll be rejected or need heavy modification.

[sorgelig]

on the last line of menu you can see < and > marking availability either page on the left or right.

Version with sticky footer should be achievable with current menu design and its limitations. Though it will eat one line from menu.