We all know that the retroarch interface and user experience has been much discussed, it is very problematic for users. There is debate over whether retroarch should allow for many options or whether it should be simpler for new users, becoming a Gordian knot for the UX. I would like to comment on this topic again and propose a series of changes that without being profound at the application level would make the UX of all users much more comfortable without losing any option or customization.
The problem of retroarch, from my point of view, is not the professional, veteran, geeky public or the most mainstream public. Nor is it the amount of options it gives the user, nor the complexity of these … it’s a simple clear hierarchy problem problem in the UX / UI.
As a user, my main problem when facing retroarch is the concept of core (don’t worry, I’m not going to ask to eliminate that idea) and the importance of this concept in the UX.
When a user uses retroarch for the first time, he doesn’t see anything about games, platforms, roms … The program is not about to play games, it is about to use cores. To play games, the true intention of the user, is secondary from the point of view of the interface and the design of the application.
This is what a user expects:
- Run program
- Select platform
- Select game
- Play it
This is RetroArch:
- Run Program
- Install a Core
- Load a Core
- Set up a Core
- Search for Core content
- Select the content for the core
- Ask him again what core he wants to use.
- Play it
The problem with retroarch is that it is a program about cores, not about games!
Why this abstraction for the program? I see no reason for retroArch to be “corecentric”, nor an impediment to fix this just by changing the interface, without breaking all that libretro means.
The solution is much simpler than it seems to allow ordinary users, those players who are now between 30 and 50 years old, to easily approach retroarch
Change current retroarch hierarchy:
Core -> Options -> Game
To a more logical hierarchy:
Platform -> Game -> Options -> Core
To relegate the central role of the core in the interface currently to a parameter within the options, which has global options, or being overwritten for each particular game. As it currently happens.
Most of the general options of the cores would be relegated to a menu within options dedicated to cores, where cores could be installed, updated or configured. Remove all traces of cores in the interface main menus.
When a user wants to play a rom, it is part of a platform, which he must select, which has an associated core (the first installed of that platform, that you can change in the core tab settings), but the user can load that rom with another core and that always remains that option saved there.
This idea is very brief, but if the developers are interested I can expand it further or qualify depending on important limitations of the system.
One of the problems that I find most when using retroarch is the menu that comes out when you pause the ROM, it does not make sense, I easily get lost in this concept and I have useda lot of times. Instead of block the user in a menu while executing a ROM, what it does is send it to the general interface with a submenu, very hidden, where you can go back to the rom or close it.
It should be clearer how pausing a rom works. You should hide all options about library to load a new rom while you still have one running, and exchange with a menu dedicated to that particular ROM, its options, if you want to stop the execution, …
Another fundamental problem is that retroarch crashes, crashes a lot. This is normal and expected when dealing with emulators, more so with a suite of emulators. The problem is that as a user every time you try something if retroarch crashes you lose the settings. And since the interface is so complex, many times you end up leaving the program forcing the program to exit or close.
This makes retroarch, for the first 10-20 uses a user is always going back to the default settings even if you have configured 1000 things. And that you are constantly losing the changes.
A program with so many options cannot work like this. Every time an option is changed something must be saved and this setting should not be lost under any circumstances other than at the request of the user.
Another thing that retroarch needs is to ask, as soon as it starts up for the first time, the default path it will use. It is very problematic