ES GUI improvements: Cyclic menu's and then what?

Zigurana

Hi guys!

Because I got frustrated again with the menus in ES I had another stab at making the menus cyclic. I had tried that before, but it kind of broke the controller-setup wizard. The reason for this being that it tries to continue to the next item, and upon arriving at the last item, moves the cursor to the [OK] button. If the menu is cyclic there is no 'last' item, doh!

I've fixed this by exposing the loopType and setting the loopType for that particular list to NEVER_LOOP.
Ok, so now all lists are cyclic, and the controller input wizard is still working, fine!

But upon testing I saw these situations:

So on the left: the main menu, with a help-prompt stating that the way to close the menu is by pressing [start] again.
On the right however, we see that the menu shows a button (not part of the list), labeled [back] to allow the user to exit the submenu.
In both cases, there is another way to exit, which is by pressing [B].
This makes the [A] button the go-in button, and [B] the go-out button (rather intuitive, if you ask me).

In the stock ES, this is already the functional reality. So why do I bring it up now?
Well, the main side effect of a cyclic menu (or any other list really) is that you will need to introduce an additional step to step-out of the list, in order to be able to select anything outside the list. Cyclic behaviour 'locks' the cursor to the list (vertically at least). That 'escape' mechanism is not there now, and would also need some kind of visual clue I think to work well. For most cases though, these buttons are not needed anyways.

So my proposal is to:

Remove all [Back] buttons if they are the only button to choose, and update the help-prompt to indicate the B button as the go-back function. This would make the menus look a bit different, smaller mostly.
For menus where there are also other buttons, the menu's will simply not be cyclic for now, until I can think of a better way to handle this.

What do you guys think?
Are cyclic menu's something that you would find useful, or is it just me?

lilbud

A question on the menus:

How difficult would it be to allow those menus to be themed? Like each theme could have a design for those.

jdrassa

@Zigurana I'd be ok with removing the back button where it is the only button. I almost always use the B button. The good news is that you don't have to update the help-prompt. It already shows that you can use the B button to go back.

jdrassa

@lilbud I believe @jacobfk20 did some work on allowing the menus to be themed. I am not sure how far he got with it.

FlyingTomahawk

@lilbud

This dude here was able to theme the menu.

pjft

@Zigurana What do you mean by cyclic, apologies? Does it mean that, in the picture to the left, if you press "down" it'd go to the first item? Or what are you trying to address here?

Just making sure I follow.

Zigurana

@pjft that is correct, so pressing down on the last item, will cycle through to the first.

pjft

@Zigurana Perfect.

And you're saying you fixed it now by "exposing the loopType and setting the loopType for that particular list to NEVER_LOOP."? That's a misleading name if I've ever read one - I wouldn't have found that one out :)

I'm not especially keen on removing buttons myself based on the rational that it's needed to get cyclic menus working. I believe if we want to remove the buttons for UX clarity, that's fine, and if we want to make menus cyclic that's also fine, but making one contingent on the other may make the behavior unclear and unexpected when there need to be buttons and such.

That being said, I can understand it's tricky in the current architecture.

In my view of the world, in the right-side picture, pressing UP from the "System Volume" selection should take you to the "Back" button, and pressing DOWN on the back button should take you to the "System Volume" selection.

That way it'll be fully cyclic regardless of the menu layout - there are quite a few menus with buttons where cyclic behavior would be a positive - I'm thinking of the scraping and metadata editor menus, but I'm sure there are others.

Furthermore, if we're being nitpicky, most (if not all) dialogs where there are options to be changed could/should have a "Cancel" and "Apply" button rather than a "Back" button, which would in turn disregard any changes, or apply the changes. But that would require a larger overhaul of the menus as they currently are, and I'm sure that's not a priority for anyone, and that's outside of the scope of the discussion. :)

Summarizing:
a) I don't oppose removing the button, in principle. Your point is valid: single button dialogs probably don't need it anyway.
b) I don't really support removing it because having it causes a new behavior not to work as intended. Would rather try to make the behavior work well with the buttons, instead, so that it works across the board.
c) I won't oppose if a) and b) are done together, though. :)