What is defined as a user-friendly menu?

[Apothem]

In the context of doom, what would you consider to be a user friendly menu? When presented with these things in game, what are your expectations? Do you prefer something like strife's menu set up or something more advanced? Is mouse support a must? Or would you rather cycle through options with arrow keys?

How would you consider a menu to be easy to use in the context of doom?

[Matt]

Just some thoughts...


If I mash Enter a few times, I will start the game.

If I hold the up or down arrows I can move rapidly, and when I get to the end of something I will wrap around to the top (and vice versa).

The meaning of the side arrows is consistent and unitary - I don't want them to open a submenu in one context, move a slider in another, select a subvalue in yet another, etc.!

Shortcut keys should be obviously indicated if any exist.

Mouse should always be optional if supported. (cf. shortcut keys)

Tooltips or captions that explain what an option does are always helpful. Exceptions: 1) they're badly written or unclear; 2) they pop up in a way that prevents you from accessing something else (but if mouse is never mandatory this should be a virtual nonissue)

Never, ever, ever have the options be "OK/Cancel" but "Yes/No" or the actual descriptions of the options. Relatedly, never, ever, ever frame a yes/no question as a negative ("Are you sure you don't want to make a backup of this savegame?").

In fact, if you ever have a button that says "OK" then you've fucked up. The message should be able to be presented without interrupting the flow of your interaction in the slightest.

[Nash]

Don't make the user rebind keys for menus. Design your input revolving around the keys already binded. Navigation using mouse or movement direction doesn't matter (I am making this user settable in my project; there's an option called UI Navigation and user can set it to either "Console mode" (direction keys) or "PC mode" (mouse)). Lastly, SetHUDSize. So many GUIs break horribly because they don't use this. Actually in a first person shooter context (examples like STALKER, Fallout 3, Skyrim, Dying Light etc) I think mouse navigation feels the most natural. You can point the cursor where you want to click fast and then there are useful shortcut keys for context-sensitive functions for faster operation (be sure to label what key does what clearly)

[wildweasel]

Regarding what Nash said about Console and PC mode: ideally, this shouldn't even need to be an option. If the movement keys are pressed, the mouse disappears and any mouse specific prompts are changed to keyboard ones. If the mouse has moved more than a little bit since then, switch them back.

(Edit) Oh, and for the love of Pierre, figure out how to take into account the player's Invert Y Axis settings with regards to the mouse. I've seen a lot of otherwise nice menus become broken because the mouse moves backwards when the wrong Invert setting is used.

[edward850]

(Edit) Oh, and for the love of Pierre, figure out how to take into account the player's Invert Y Axis settings with regards to the mouse. I've seen a lot of otherwise nice menus become broken because the mouse moves backwards when the wrong Invert setting is used.

That's sort of impossible for what Apothem seems to want, and brings up my own point: Fake menus are the worst. If a menu cannot be navigated natively from the users system, then it's inherently not user friendly from the start. Especially with the rise of tablet PCs, the way the end user can interact with a menu can change at a moments notice, and if it cannot be adapted, then any effort put in is already squandered.

Ultimately, a user friendly menu is one that cannot be restricted to any one type of user input.

[Matt]

...I'm going to second everything that edward said, and admit that I hadn't even seriously considered that this was what was being discussed and not some fancy MENUDEF work or something!

Maybe just keep it simple, numbered list, hit the number you want to go into it, hit Esc to go back to the previous page?

[edward850]

Even that's a problem, as numbers aren't a guaranteed available input (and on that note aren't actually a readable input ). You can expect, at a minimum, analogue movement*, some kind of weapon selection, use and fire.

*Binary movement doesn't always exist, and Doom always translates that to analogue movement (which is what it actually uses). However, never the other way round. Put simply, as far as input is concerned, the player is always using a joystick.

[wildweasel]

(Edit) Oh, and for the love of Pierre, figure out how to take into account the player's Invert Y Axis settings with regards to the mouse. I've seen a lot of otherwise nice menus become broken because the mouse moves backwards when the wrong Invert setting is used.

That's sort of impossible for what Apothem seems to want, and brings up my own point: Fake menus are the worst. If a menu cannot be navigated natively from the users system, then it's inherently not user friendly from the start. Especially with the rise of tablet PCs, the way the end user can interact with a menu can change at a moments notice, and if it cannot be adapted, then any effort put in is already squandered.

Ultimately, a user friendly menu is one that cannot be restricted to any one type of user input.

With respect, I am not sure you read my whole post; specifically, I think you might have missed the part about switching automatically between movement controls and mouse controls as the player touches them. This would obviously also apply to gamepads and the like.

[edward850]

Oddly, I just covered that.
The engine, sans the interface used by the network buffer (although by that point you are sitting in SDL and DirectX libraries), doesn't know or care what input method you have, and a mod cannot distinguish between them in any ideal manner. Everything just ends up looking like a twin-stick joystick, in the end. A mouse would probably be the least identifiable input.

[GooberMan]

Just from personal/professional experience, trying to find a one-size-fits-all UI solution is difficult at best. There's three paradigms that need to be taken in to account in the future - mouse driven, touch driven, and controller/key driven. The differences between the three range from subtle to wild. Doom, and its derivatives, only reliably implement the controller/key driven system.

Honestly, unless ZDoom gets a UI layout engine, it's best to only design for the first one. The other two can be used, but trying to design for all three with limited engine capabilities just won't happen.

[Nash]

I made it a switchable option in my project because I was lazy. =P I didn't want to bother figuring out how to make the movement input and the mouse cursor not override each other's selection value (imagine if the mouse is already pointing at something, then when you press W or S, the selection will briefly move before snapping back to whatever the mouse was pointing at). This is actually easy to solve and of course one could do that if they put the effort into it. As I said, I just didn't bother because I have other things to worry about (code-wise) for now. :P

Skyrim and Dying Light actually allows you to use both - you can use the mouse to point and click at stuff, but at the same time if you can use WASD to move around the menu selections... this is ideal.

Mouse Y axis input is also easy to solve, but don't read from ZDoom's inverse mouse variable... that will just desync multiplayer. Create your own custom CVar. Clunky I know but better than nothing.

Also an interesting concept to try as far as first person shooter UIs go is the Destiny style of UI. It's actually a crosshair that you move around with your movement keys. Someone wrote an article that thoroughly studies the Destiny UI and there was a section dedicated just to this moving crosshair thing but I don't have the link right now.

[edward850]

Honestly, I don't get the point in trying to shoehorn things in that clearly aren't going to work without thrusting some sort of square peg into some kind of round hole. It seems much better to create something you can spend the effort in polishing off, then to deal with something that will come off as perpetually incomplete.

But then I'd also rather people (or hell, someone) actually make maps again.

[GooberMan]

This reminds me that I'm meant to be finishing up Prime Directive... and whipping up an example in Hexen format that ReX requested from me for the 3D moving floors.

Stupid overtime.

[Apothem]

Sadly, using number keys would be more hacky than just detecting mouse movement.

But from what I can tell with all the discussion so far, it's not so much an issue of keyboard or mouse only. It's more of just making it comfortable to use without causing any major headaches.

A need for no new controls seems to be a must. But I made assumptions for that ahead of time.


However the one thing I'm noticing here that I haven't given much thought to is adding key detection as menu shortcuts. That's an excellent idea as something to be able to additionally define to a menu button so you can access it multiple ways.

The last obstacle is the inverted mouse, the only thing I've been able to find so far is just a button that toggles it to the correct state. I know that you can detect for this via getcvar but that's a singleplayer only kind of feature.

There may be no work around currently for the inverted mouse issue.

However, setting hotkeys for menu options sounds like a great idea. This should also be easy to implement as an extra property to detect for.

Appreciate the input so far guys!

@Nash: I had a similar idea for doom menus that required some kind of cursor input.

Would controlling a cursor with movement keys like a mouse be a decent compromise for those who do not wish to use a mouse?

Perhaps using keys would be a little bit more reliable, as mouse sensitivity and the like can really effect input in doom.

[Nash]

Speaking for myself, I am alright with a Doom mod that uses movement keys (things that I would have bounded for normal gameplay anyway; WASD, Space for jump, Ctrl for crouch, Shift for speed modifier etc) for in-game UI navigation.

If there's one thing that annoys me the hell out of Doom mods, it's that I have to further bind new keys just to navigate your custom in-game UI elements. :P

A blog post on Destiny's UI

A video (good study on the crosshair controls):