Summary
The current distinction between "Platform Bindings" and "Platform Versions" in the Library Management settings is unclear and not intuitive. It's difficult for a user to understand the purpose of each section, the potential overlaps, and the expected behavior when configuring them. This can lead to confusion and misconfiguration of the library. I had to read the source code to understand the intended functionality, which highlights a need for a better user experience.
Detailed Description
When a user navigates to Settings > Library Management, they are presented with two similar-looking sections for mapping folders to platforms:
- Platforms Bindings
- Platforms Versions
The tooltips provide a hint, but they don't fully clarify the functional difference or the precedence between them. This raises several questions for the user:
- What is the difference between a "binding" and a "version"?
- What happens if I map the same folder (e.g.,
atari-2600) in both sections?
- What is the expected behavior if I only use the "Versions" section for a folder that isn't a variant of another?
- Which mapping takes precedence if there's a conflict?
After reviewing the code, my understanding is:
- Platform Bindings (
PLATFORMS_BINDING): This acts as a folder alias. It tells RomM to treat a folder with a custom name (e.g., My Nintendo 64 Games) as an official platform slug (e.g., n64). This is the primary way to map a custom folder name to a known platform.
- Platform Versions (
PLATFORMS_VERSIONS): This is for metadata inheritance. It tells RomM that a specific platform folder (e.g., n64dd) is a variant of a main platform (e.g., n64). This is used during scanning to fetch metadata from the correct parent platform on sources like IGDB, as seen in the _get_main_platform_igdb_id function.
This distinction is crucial but not at all obvious from the UI.
Proposed Solutions to Improve User Experience
To make this feature more intuitive and prevent misconfigurations, I suggest the following improvements:
1. UI/UX Enhancements
-
Rename Sections for Clarity: The current names are too similar. Consider renaming them to better reflect their function:
- "Platforms Bindings" → "Folder Aliases" or "Platform Folder Mapping".
- "Platforms Versions" → "Platform Variants" or "Metadata Mapping".
-
Improve Tooltips: The tooltips should be much more explicit.
- For Bindings/Aliases: "Use this to map a folder in your library to an official RomM platform. For example, if your Nintendo 64 games are in a folder named
Nintendo-64, you can bind it to the n64 platform here. This becomes the primary identifier for that platform in RomM."
- For Versions/Variants: "Use this if you have a separate folder for a platform variant and want it to use the metadata of a main platform. For example, mapping a folder named
n64dd as a version of n64 will cause RomM to search for N64 metadata when scanning n64dd games."
-
Visual Reorganization: Instead of two separate, identical-looking sections, consider a unified view. Show a list of all detected library folders and allow the user to define its behavior: "Map to Platform" or "Set as Variant of Platform".
2. Functional & Validation Improvements
-
Prevent Overlap: A folder name (fs_slug) should not be allowed to exist in both "Bindings" and "Versions" simultaneously. The UI should prevent this. When adding an entry to one section, the folder name should become unavailable for selection in the other.
-
Filter Available Folders: When adding a "Platform Version", the dropdown for the folder name should not include folders that are already defined in "Platform Bindings". This enforces the idea that a folder is either a primary platform (or an alias to one) or a variant, but not both.
3. "Nice to Have" Features
- Automatic Detection and Listing: Instead of relying solely on manual entry, the UI could list all folders found in the
/library directory. Each folder could then have a dropdown next to it, allowing the user to either bind it to a platform or mark it as a version of another platform. This would be much more intuitive than starting from scratch.
- Default Mapping Display: For platforms that RomM correctly identifies using the default folder name (e.g., a folder named
snes), they could be displayed as "Default" or "Auto-detected" in the UI. This would make it clear that no manual configuration is needed unless the user wants to override it.
Expected Outcome
After these changes, users should be able to:
- Clearly understand the purpose of each mapping type without confusion.
- Confidently configure their library, even with non-standard folder names or platform variants.
- Be prevented from creating conflicting or ambiguous configurations.
These improvements would significantly lower the barrier to entry for users with existing, complex library structures and make RomM even more powerful and user-friendly.
Thank you for your time and consideration of these suggestions.
Summary
The current distinction between "Platform Bindings" and "Platform Versions" in the Library Management settings is unclear and not intuitive. It's difficult for a user to understand the purpose of each section, the potential overlaps, and the expected behavior when configuring them. This can lead to confusion and misconfiguration of the library. I had to read the source code to understand the intended functionality, which highlights a need for a better user experience.
Detailed Description
When a user navigates to
Settings > Library Management, they are presented with two similar-looking sections for mapping folders to platforms:The tooltips provide a hint, but they don't fully clarify the functional difference or the precedence between them. This raises several questions for the user:
atari-2600) in both sections?After reviewing the code, my understanding is:
PLATFORMS_BINDING): This acts as a folder alias. It tells RomM to treat a folder with a custom name (e.g.,My Nintendo 64 Games) as an official platform slug (e.g.,n64). This is the primary way to map a custom folder name to a known platform.PLATFORMS_VERSIONS): This is for metadata inheritance. It tells RomM that a specific platform folder (e.g.,n64dd) is a variant of a main platform (e.g.,n64). This is used during scanning to fetch metadata from the correct parent platform on sources like IGDB, as seen in the_get_main_platform_igdb_idfunction.This distinction is crucial but not at all obvious from the UI.
Proposed Solutions to Improve User Experience
To make this feature more intuitive and prevent misconfigurations, I suggest the following improvements:
1. UI/UX Enhancements
Rename Sections for Clarity: The current names are too similar. Consider renaming them to better reflect their function:
Improve Tooltips: The tooltips should be much more explicit.
Nintendo-64, you can bind it to then64platform here. This becomes the primary identifier for that platform in RomM."n64ddas a version ofn64will cause RomM to search for N64 metadata when scanningn64ddgames."Visual Reorganization: Instead of two separate, identical-looking sections, consider a unified view. Show a list of all detected library folders and allow the user to define its behavior: "Map to Platform" or "Set as Variant of Platform".
2. Functional & Validation Improvements
Prevent Overlap: A folder name (
fs_slug) should not be allowed to exist in both "Bindings" and "Versions" simultaneously. The UI should prevent this. When adding an entry to one section, the folder name should become unavailable for selection in the other.Filter Available Folders: When adding a "Platform Version", the dropdown for the folder name should not include folders that are already defined in "Platform Bindings". This enforces the idea that a folder is either a primary platform (or an alias to one) or a variant, but not both.
3. "Nice to Have" Features
/librarydirectory. Each folder could then have a dropdown next to it, allowing the user to either bind it to a platform or mark it as a version of another platform. This would be much more intuitive than starting from scratch.snes), they could be displayed as "Default" or "Auto-detected" in the UI. This would make it clear that no manual configuration is needed unless the user wants to override it.Expected Outcome
After these changes, users should be able to:
These improvements would significantly lower the barrier to entry for users with existing, complex library structures and make RomM even more powerful and user-friendly.
Thank you for your time and consideration of these suggestions.