[META] List of Issues and Inconsistencies with RetroArch

[im4potato]

Description

I've been compiling a list of issues that I've discovered with RetroArch as I've been cleaning up the US translation. Some of these are very minor and should be fixed by the work I'm doing with the translation, but there are many other "nitpicks" that I've noticed that are outside of that scope, some of these probably deserve their own issues. I expect this list to grow as I continue working my way through the UI.

I welcome any discussion or suggestions on this list.

General Issues/Suggestions

• Duplicate settings are found in different menus
• Only menu items that open a sub-menu should have an icon, regular settings should just be text, this would cut down on the number of assets needed, as well as be a visual indicator to the user that a menu item contains more settings
• Menu items that open a sub-menu should be placed at the top of their respective settings page
• The existence of Show Advanced Settings seems like an admission of there being a problem with how things are organized and explained, if the UI was improved then this setting would no longer be needed
• Most menu items lack a detailed description (the pop-up opened when pressing SHIFT) or simply contain the exact same text as the sub-label
• Many menu items have sub-labels that essentially restate what the label already says, not only is this unhelpful, but it makes less menu items visible on the screen at once
• Selecting Parent Directory when there is no parent directory will cause RetroArch to require going back as many times as you tried it in order to return to the previous menu
• The wrong data type is used for many settings, such as Settings > Audio > Volume Gain (dB), it uses a float even though only integer values are possible
• Remove all "technical" wording from settings, for example, instead of "null" being an option, it should say "Disabled" or something similar

Incorrect Data Types/Formatting:

• Settings > Video > Windowed Mode
  • [x] Windowed Scale should be an integer
  • Window Opacity should be a percentage
• Settings > Audio
  • Volume Gain (dB) should be an integer
  • Mixer Volume Gain (dB) should be an integer
• Settings > Input
  • Input Button Threshold should only go to 2 decimal places

Specific Issues

• (Ozone) The header and footer are different sizes
• (Ozone) Font sizes vary in the header and footer (the clock font is larger than the button hints)

• [x] There is no Show/Hide setting for Accessibility
• [x] There is no Show/Hide setting for File Browser
• [x] Settings > User Interface > Views is a confusing word choice, a more accurate/descriptive title should be chosen

• The Start Screen is useless, it should be removed, along with Settings > User Interface > Display Start Screen, an alternative solution is discussed here: #10513
• Main Menu > Online Updater
  • Content section should use the same icon as Load Content
• Main Menu > Information > System Information
  • Controller port doesn't match input settings (-1) and uses a "#" symbol
• Main Menu > Help
  • Only contains one item, which is not very helpful, this either needs removed or greatly expanded upon
• Netplay > Host > Stop Netplay Host
  • Unable to stop netplay host if content isn't loaded, the setting gets stuck in this state
• Settings > Video > CRT SwitchRes
  • Use Custom Refresh Rate allows the use of a custom setting in the configuration file, why is this not configurable from within RetroArch?
• Settings > Video > Output
  • Screen Orientation forces a display mode change just by selecting it, without making any changes
• Settings > Video > Scaling
  • Integer Scale refers to 'Force Aspect Ratio', a setting that doesn't exist
• Settings > Video > Windowed Mode
  • Window Opacity doesn't just affect Windowed Mode
  • Remember Window Position and Size only works on Windows, at least the "remember position" aspect of it
  • Window Width has no indication that it relies on Remember Window Position and Size to function
  • Window Height has no indication that it relies on Remember Window Position and Size to function
• Settings > Input > Hotkeys
  • There is an option to move to the next overlay, but not the previous
• Settings > Input > Port # Controls
  • [x] All entries after Mouse Index are slightly further to the right (probably by a single SPACE)
• Settings > On-Screen Display > On-Screen Notifications
  • Display Statistics doesn't do anything
  • None of the notification settings have any effect when Graphics Widgets is enabled
• Settings > User Interface
  • UI Companion and UI Companion Start On Boot don't seem to do anything
• Settings > Power Management
  • Should only appear if the device is battery powered
• Settings > Achievements > Hardcore Mode
  • Spams duplicate notifications
• Settings > Playlists > Playlist Management > History
  • [x] There is an option to Delete Playlist even though it is not possible to do so

Feature Requests

• (Ozone) The selection rectangle should follow the mouse cursor on the sidebar (but not enter that menu until it is selected)
• (Ozone) Settings that depend on another setting to be visible should be indented
• Setting to show the number of items in a playlist
• Label Display Mode should have an option to keep revision and version information to avoid multiple playlist entries having identical names
• The Core Updater menu should move each system/core type into its own sub-menu, as libretro adds more cores the list just gets longer and more difficult to navigate
• Cores should provide information about when they were last updated or synced with upstream
• Cores should provide a link to the upstream website or source code
• Cores should state their purpose, for example, the average user will not understand why there are so many versions of Snes9X

[hizzlekizzle]

I can field a few of these.

Duplicate settings are found in different menus

This is done for convenience. I'm not a huge fan of it, but it makes sense in some cases, such as the 'latency' menu, which brings a lot of redundant options together. The obvious retort here is "well, if they belong together, remove them from their other home". /shrug

Only menu items that open a sub-menu should have an icon, regular settings should just be text, this would cut down on the number of assets needed, as well as be a visual indicator to the user that a menu item contains more settings

This is a fine suggestion. I don't care either way, but perhaps @natinusala or @jdgleaver has an opinion.

The existence of Show Advanced Settings seems like an admission of there being a problem with how things are organized and explained, if the UI was improved then this setting would no longer be needed

'show advanced settings' exists because there are a lot of settings that people simply don't want to see and it was requested ad nauseum until we put it in. The first thing I do with an installation is turn it on, but apparently many people never do. However, there's no real overarching ethos behind what gets dubbed "advanced", so I think if anything we should come up with a consistent concept and apply it to way more stuff.

Most menu items lack a detailed description (the pop-up opened when pressing "shift") or simply contain the exact same text as the sub-label

This requires a ton of copywriting that almost no one will ever read, followed by a ton of translation with similarly little payoff. With that said, perhaps it's outlived its usefulness vs the sublabels (which were added later), but I suspect it is still useful in some cases.

Many menu items have sub-labels that essentially restate what the label already says, not only is this unhelpful, but it makes less menu items visible on the screen at once

These relatively useless descriptions were added in for consistency. They could be expanded, I guess, but there are relatively few of them, so I think removing them would be jarring.

The wrong data type is used for many settings, such as Settings > Audio > Volume Gain (dB), it uses a float even though only integer values are possible

Is this really a problem? That is, what's the real benefit of changing 4.0 to 4?

Remove all "technical" wording from settings, for example, instead of "null" being an option, it should say "Disabled" or something similar

Most of the "null" options should be removed entirely from the GUI, as they do nothing but break the program for the people who unknowingly pick them.

There is no Show/Hide setting for Accessibility There is no Show/Hide setting for File Browser

This is just an oversight, AFAIK, not a design choice.

Settings > User Interface > Views is a confusing word choice, a more accurate/descriptive title should be chosen

I think that's fair. Something like "menu item visibility"?

The Start Screen is useless, it should be removed, along with Settings > User Interface > Display Start Screen, an alternative solution is discussed here: #10513

I think the Start Screen is more useful in Android, maybe? Being able to choose language and potentially a few other things directly from it would be nice, though.

Main Menu > Help -- Only contains one item, which is not very helpful, this either needs removed or greatly expanded upon

I think the information in there is extremely important but I would wager almost no one ever sees it. Perhaps it would make sense to replace the underutilized help text (retropad-select) with the content from this item and add a note at the footer that says "select - Help" or something.

Settings > Video > CRT SwitchRes -- Use Custom Refresh Rate allows the use of a custom setting in the configuration file, why is this not configurable from within RetroArch?

This can require a very specific setting that probably doesn't make sense to set in the GUI (e.g. 57.2548776). Perhaps it should be renamed to "Use config-specified Refresh Rate" or something?

UI Companion and UI Companion Start On Boot don't seem to do anything

I believe these affect the Qt/desktop menu (F5)

Settings > Playlists > Playlist Management > History -- There is an option to Delete Playlist even though it is not possible to do so

It does appear to clear the history. While that doesn't actually delete it, it seems close enough to me (and perhaps it's actually deleting it and then immediately making a new one under the hood...?)

The Core Updater menu should move each system/core type into its own sub-menu, as libretro adds more cores the list just gets longer and more difficult to navigate

I think this is a technical limitation...? like something between the downloader and the ability to parse directories or something?

Cores should provide information about when they were last updated or synced with upstream

Strongly disagree. If anything, we should provide less information, as this is something that just confuses end-users and sets up an endless treadmill of "upstream is 3 commits ahead!! libretro is trash unless they update and get those commits that don't even affect the core!" (I wish this was an exaggeration)

Cores should provide a link to the upstream website or source code

Similar to the last one, relationships with upstream are not always sunshine and rainbows, and this would complicate it even more. If someone wants that stuff they can visit github where all of it is already available.

Cores should state their purpose, for example, the average user will not understand why there are so many versions of Snes9X

jdgleaver is planning to add support for displaying a "description" field from the core info files. We can include something like this in the description, though many of them are going to be "faster than X but not as fast as Y" which doesn't really explain why we have more than 2 (i.e., the fastest and the most accurate, though that's not always a zero-sum relationship), but it's better than no explanation at all.

[im4potato]

Thanks for taking the time to read through it! I'm sure you understand the history behind some of these decisions better than I do, so your insight is great to have.

As you can probably tell based on my previous contributions and our other discussions, I'm trying to work on things that have probably been seen as low priority or that others might not have noticed or cared enough about to fix. I don't mean that as a criticism of the RetroArch team, there's just so much to work on in a massive project like this that things get left behind or go unnoticed.

In regard to your points:

Duplicate settings are found in different menus

This is done for convenience. I'm not a huge fan of it, but it makes sense in some cases, such as the 'latency' menu, which brings a lot of redundant options together. The obvious retort here is "well, if they belong together, remove them from their other home". /shrug

I can understand the logic behind this, but this seems like a problem that could be solved in a better way. Better categories and more sub-menus would make these settings easy to find and cut down on the confusion of having duplicates. Of course, having to go multiple levels deep into a menu structure is not desirable, but if done properly I think this could be improved dramatically.

The existence of Show Advanced Settings seems like an admission of there being a problem with how things are organized and explained, if the UI was improved then this setting would no longer be needed

'show advanced settings' exists because there are a lot of settings that people simply don't want to see and it was requested ad nauseum until we put it in. The first thing I do with an installation is turn it on, but apparently many people never do. However, there's no real overarching ethos behind what gets dubbed "advanced", so I think if anything we should come up with a consistent concept and apply it to way more stuff.

Like the previous point, I understand the logic, but I think that a better menu structure could solve this issue without overwhelming people. I can definitely see both sides of this argument, though.

The wrong data type is used for many settings, such as Settings > Audio > Volume Gain (dB), it uses a float even though only integer values are possible

Is this really a problem? That is, what's the real benefit of changing 4.0 to 4?

Like many things in this list, this is a small issue, but I think little things like this add up to a more negative user experience. Using 4.0 vs 4 implies that it's possible to increment a value in steps that aren't possible. It also just makes things messier than they need to be. By the same logic, there's nothing wrong with having it be 4.0000000, it means the same thing, but there's no reason for it.

To go along with this change, I'd also like to see the units moved out of the label and into the setting value itself. For example, Settings > Latency > Audio Latency (ms) defaults to 64, the label should be changed to just Audio Latency and the value should display 64 ms.

The Start Screen is useless, it should be removed, along with Settings > User Interface > Display Start Screen, an alternative solution is discussed here: #10513

I think the Start Screen is more useful in Android, maybe? Being able to choose language and potentially a few other things directly from it would be nice, though.

While I don't use RA on Android, I'm not sure what benefit having a little pop-up that says "Welcome to RetroArch" serves there. I do think what's discussed in that issue is the best solution, but obviously that will require some work.

Main Menu > Help -- Only contains one item, which is not very helpful, this either needs removed or greatly expanded upon

I think the information in there is extremely important but I would wager almost no one ever sees it. Perhaps it would make sense to replace the underutilized help text (retropad-select) with the content from this item and add a note at the footer that says "select - Help" or something.

I agree that having helpful information directly in the UI is a good idea, but like my point says, currently there's hardly anything in there. I know that it used to have additional sections in it describing what a core is, among other things, but for some reason they were removed.

Settings > Video > CRT SwitchRes -- Use Custom Refresh Rate allows the use of a custom setting in the configuration file, why is this not configurable from within RetroArch?

This can require a very specific setting that probably doesn't make sense to set in the GUI (e.g. 57.2548776). Perhaps it should be renamed to "Use config-specified Refresh Rate" or something?

I'm not sure what the solution is, but it doesn't seem like good design to have settings within the UI that you can't configure from within the UI.

Cores should provide information about when they were last updated or synced with upstream

Strongly disagree. If anything, we should provide less information, as this is something that just confuses end-users and sets up an endless treadmill of "upstream is 3 commits ahead!! libretro is trash unless they update and get those commits that don't even affect the core!" (I wish this was an exaggeration)

That's a fair point, you guys definitely get a lot of undeserved grief from entitled users that don't know what they're talking about. So, if that is a major concern then maybe this is a bad idea, but I do think that providing information like this would also help alleviate some of the "mystery" of what the state of a core is. Some cores go very long periods of time with no updates, which can lead to a poor user experience, like Dolphin for instance. Again, you guys are the ones who have to put up with the bad behavior of these people, so maybe this just isn't worth the trouble.

Cores should provide a link to the upstream website or source code

Similar to the last one, relationships with upstream are not always sunshine and rainbows, and this would complicate it even more. If someone wants that stuff they can visit github where all of it is already available.

I'm at least partially aware of some of the strained relationships that you guys have with a few of the upstream developers. I know there are multiple reasons that things aren't "sunshine and rainbows", but it seems like at least part of that is because they don't feel like they are getting credit for their work because people just use RA (along with some of them not appreciating that because of RAs popularity, their latest work often doesn't reach their users for some time). However, I can also see how linking to upstream would be problematic, because people might blame them for issues that are specific to the libretro core. I think that anything that can be done to improve those relationships would be great, not only to relieve some of the tension, but it would allow more cooperation and reduce the workload on everyone involved. I do understand that this might be unrealistic though.

Thanks again for the discussion!

[natinusala]

Only menu items that open a sub-menu should have an icon, regular settings should just be text, this would cut down on the number of assets needed, as well as be a visual indicator to the user that a menu item contains more settings

I think it was originally like that when I first wrote ozone :thinking:

The issue is that visually it looks wonky to have some entries with icons and some entries without. We couldn't find anything that we liked so we put the generic icon everywhere

[im4potato]

I think that keeping all menu items that open a sub-menu at the top of their respective settings page would be a good way to do it, put all of the individual settings below them.

[natinusala]

This is not something that we have control on at the driver scope, but that's a good idea independently of the driver

Le 26 mai 2020 11:38:00 im4potato [email protected] a écrit :

I think that keeping all menu items that open a sub-menu at the top of their respective settings page would be a good way to do it, put all of the individual settings below them. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[hizzlekizzle]

The 'advanced settings' toggle is an attempt to strike a balance between two truths in UX: 1.) people get confused by a long list of options and just tune out and 2.) people get lost in submenus once you get down more than a couple of layers. I think having breadcrumbs would help with num2, though the inability to just go and click on them to jump up X layers makes it less useful than in a regular WIMP situation. But at least you could see where you are in the grand scheme of things.

For the float/integer thing, even though the UI only moves in integer increments, I think the config allows floats, so it's probably a good idea to show when a float value is entered. Perhaps we can drop trailing zeros or something? or cast to int (though that drops the fractional value)?

Display Statistics doesn't do anything

It does stuff, but you have to have a game running. There's nothing to show otherwise--unless you want to measure frame-time etc. for the menu itself.

None of the notification settings have any effect when Graphics Widgets is enabled

Yeah, widget and notification settings should be consolidated when possible, I think. I believe the problem is that many of them are bools and to be combined, we would need to replace them with string arrays like { OFF, notifications, widgets }, not to mention that most of the customizeability of the notification text isn't implemented in the widgets.

Just as a general note, I think it's good to have these sorts of audits/discussions because it is easy to just get used to things, and it's nice to revisit them with a renewed analytical eye.

[i30817]

Could you add the fact that we have to go into the video menu to change shaders for cores or running games? That always bothered me. Especially now that the running core menu gained a bunch of shortcuts to parts of those menus that are useful to override for a particular game or core and has the buttons to save those overrides.

I'd also be nice if the file browser remembered its position at runtime. Going back one level from a 'game directory' to a 'game platform directory' if you you made a mistake is a brutal inflection point on flow, requiring a keyboard search or tedious scrolling to get back to where you were. I think this was fixed recently for the playlists (except if you move to another playlist with the horizontal direction instead of drill inside a entry, which is fair enough) and most settings submenus, but not the file browser. Passing the 'previous directory' when going 'up', and then focusing on it should be enough, I don't think there is a real usability need to remember the other direction for paths.

[soredake]

Any progress on any of this?

[LibretroAdmin]

Decided to address some things here:

• [x] Windowed Scale should be an integer (https://github.com/libretro/RetroArch/commit/84868ab21f6f0528ea80b4bf4461940c123287ea)

[Perlovka]

Retroarch UI is a horrible thing. On Steam deck you even can not search for cores to install, because there is no search field. Not something new though, RA UI sucks for ages.

[sonninnos]

Search does exist: https://docs.libretro.com/guides/input-and-controls/#default-retroarch-keyboard-bindings

[Perlovka]

Search does exist: https://docs.libretro.com/guides/input-and-controls/#default-retroarch-keyboard-bindings

I said search field does not exists.

Keybinding exist. But it does not work on steam deck by default. And you can not issue search with neither mouse nor touchscreen.

[hizzlekizzle]

it's a good thing no one's forcing you to use such a horrible program.

[Perlovka]

it's a good thing no one's forcing you to use such a horrible program.

This answer clearly explains why this program has problems with UI/UX (not only) for ages.

I've just tried to use it and tell that is has some huge problem in usability. And I'm not alone, there are plenty of related issues even here, on github. But nobody forcing you to fix it. Who cares about users, LOL.

[sonninnos]

So it is RA's fault then if some random device decides to do something else with normal controller face buttons.

[Perlovka]

So it is RA's fault then if some random device decides to do something else with normal controller face buttons.

No, RA fault is when key binding is not working for some reason you have no other way to accomplish the task. This is called bad UX design.

[sonninnos]

Yes it absolutely should be able to read minds.

And in Ozone menu driver clicking/touching the bottom toolbar buttons does work.

[Perlovka]

No need to read minds to build user friendly interfaces.

If you click Load Core, then Download Core, then Search button on bottom toolbar, it will throw you back to the screen you provided.

[sonninnos]

I'm noticing some serious focus issues if those bottom buttons are used in "load core" menu, since search there moves the pointer instead of filter the results, like it does in "core downloader" menu. It didn't throw it back to the root menu though.

Feel free to improve the code to be more consistent.

[warmenhoven]

If you click Load Core, then Download Core, then Search button on bottom toolbar, it will throw you back to the screen you provided.

This is changed in the nightly build, the bottom icons (which never were intended to be buttons) are now buttons.