search

libretro / RetroArch

Cross-platform, sophisticated frontend for the libretro API. Licensed GPLv3.
http://www.libretro.com
GNU General Public License v3.0
10.25k stars 1.83k forks source link

[META] List of Issues and Inconsistencies with RetroArch #10710

Open im4potato opened 4 years ago

im4potato commented 4 years ago

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

Incorrect Data Types/Formatting:

Specific Issues

Feature Requests

hizzlekizzle commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

Any progress on any of this?

LibretroAdmin commented 2 years ago

Decided to address some things here: