Interlaced views (interlacing roms, pnds, platform, genres, folders)

[porg]

In all game lists (All Games, Favorites, Most played, Most recent): Sort by: Name, Genres, Year.

By "Genre" I mean this: For a PND: FreeDesktop subcategory (such as: ActionGame, BlocksGame, ...) or your own defined subcategory (i.e. I use LogicActionGame to differ from LogicGame, and Shooter, ShooterFlight, ShooterScroller for my own differentiation) in the .OVR override file. For a ROM: Its parent folder. Pandafe calls this "Subfolder". For optimal melting, use the same genre naming convention among PNDs and ROMs. Within your rom folders, sort your roms by genres: PSX-roms/genre1/rom1…rom3 PSX-rom/Genre2/rom1…rom5 NES-roms/genre2/rom1…rom3 and so on… Then you can play a "LogicGame", regardless wether it is a PND, NES-ROM, PSX-ROM, ..., SMD-ROM.

By "Year" I mean this: For PNDs: Their creation date (at best identical with "added to repo" date), if not available (on FAT volumes possibly), then modification date. For ROMs: If the ROM can be identified via checksum/hash, and there is a database with dates for roms, consider this. Else, does the ROM or parent folder contain a 4-digit number? If so, consider this as the year. Else, creation date. Else, modification date.

We need one key to change the sort order. See chapter: Controls.

How to display this information to have enough orientation but at the same time not too much visual noise, is a challenge. I have my ideas, and already made some drafts. But first I wait wether, you even like the idea, and if so, maybe you have your own ideas for it.

[porg]

Nuhrin replied:

"Melting" eh? I pondered these sorts of things in my initial design work, but eventually just dropped the whole area of concern, apart from treating rom subfolders vaguely like categories, as you observed.

Its something of a can of worms, partially due to the display/interface questions, as you also observed. Having sort implies having multiple columns, which I quickly abandoned for simplicity of design and initial effort.

What if, instead of sort options, we have filter options? Filter menu pops up, you choose your filter from a tree, list is filtered, repeat. You don't get the context for all the different genres, etc, together in the list at a glance, but the filter menu itself could be written to only display what is appropriate for the game list, thus providing that context. So, its drill in and out, rather than page up and down. At a gut level, this feels more pleasant to me personally, and certainly it integrates better into the existing design and architecture.

Curious though, yes, to hear what you came up with for how this might work. And yes, we need a key to trigger this (sort or filter). Tab?

On Genre: For a PND: I hate the redundant "Game" suffix on the categories in this context, especially if trying to match rom folder names to them to facilitate "melting." Any objection to stripping that suffix, at display time? While I'm at it, what about splitting up the PascalCase (LogicAction -> Logic Action)? Any other display transformations? Does Pandafe already respect and display your own category names from OVR files? I dunno if libpnd does this transparently as part of app discovery, I never got around to testing this. For a ROM: What you describe is also my preference for structuring my rom folders, and really the whole reason there is support for subfolders. A have in my local repo a partial implementation of rom file/folder management via the context menu. Will let you move roms into existing (or new) folders within the root folder for the platform, rename rom files and folders, and delete rom files. Also lets you open terminal/thunar in the context of the selected folder, for more complex management. Still needs work, but should help with an iterative "melting" process. On Year: Interesting, hadn't considered this. Not sure I would use it, but then that's true of most other metadata that some folks like -- publisher, region, etc. This will presumably require/call-for a new subsystem for keeping track of rom metadata. Performance/memory optimization can be a challenge, so simplicity is preferred. I kind of like the idea of extracting metadata from rom filenames. That solves the problem of how to store and associate it roms very nicely. It complicates any interface for managing metadata in program, but makes it possible to have the feature before such an interface is build (or skip the interface entirely). I'm not so sure about extracting it from folder name though, as that would complicate other aspects of the program (including this one). Also not so sure about doing md5 on roms on the Pandora. Seems to expensive. Could be cached, but rom scanning would get way more expensive.

After thinking/"talking" this through, I'm liking the idea of adding game attribute filters (vs sort) to game lists, and extracting rom metadata from filenames. What do you (all) think?

[porg]

Concerning the whole topic of interlaced genres/views: I once wrote a guideline / vision about the PND management workflow. It is worth reading before/while conceptualising highly integrated solutions for the Pandora such as launchers!

I dislike the idea for a filter drill-down approach (aka pogo stick navigation in interaction design lingo) as it works only good if you have enough elements with common attributes and the total common attributes being only a few (i.e. 20 games in 6 genres) but bad for datasets with little commoness (i.e. 20 games in 18 years), where you navigate a lot, and forget context in the meantime. We don't want to through a full fledged table at users (overwhelming), but I am thinking of a table, where cells repeating on multiple rows are not shown, only their first instance, thus creating groupings, and the full details only in the focused selection. I have something in mind, which tries to solve that complexity. Fzero suggested thumbs/screenshots. UI-wise I probably also consider that aspect into the issue. If I get my time, I will sketch a wireframe and upload it. Tech-wise I urge you to use the PXML-icon/screenshot cache together with MiniMenu, which already caches them. In order to use SD storage space efficiently.

PND Genres: I don't like the FreeDesktop naming scheme at all. But our founding Pandora fathers chose so ;-) We have to live with it, or use our own genres in our overrides. Btw, Pandafe respected my individually defined genres from my override files. Your proposal to change PascalCase to Proper Case and to strip of that redundant "game" from the genre name at display time is very appreciated! How MiniMenu / libpnd fail or handle sub/categories can be read in this bug report to some extent.

You mention to offer file/folder renaming/moving options (for ROM genres). If this feature comes, it would be nice if in the frontend PND genres could be edited the same way, and in the backend Pandafe handles to write that info to the appropriate override files. XFCE has no interface for this. AFAIR MiniMenu has editing capabilities for sub/categories but enforces to chose from existing genres and if you set a custom genre it fails, or it fails in both cases, am not sure anymore. Anyhow, there is the utility OVR editor from Caine. Nevertheless I'd love to see an integrated solution, especially as individual action (per-file) and overall consequence (in interlaced/aggregated view(s)) are better perceivable.

Besides name, platform, genre, year… what about more attributes like: publisher, region, …? We have to put a stop somewhere. First, we have the UI challenges, but they can possible be overcome (if the sophisticated table idea works, it might scale for more attributes as well), but what cannot be overcome, is that this would require a really heavy metadata engine, whereas the year can be extracted quite cheap (parsing ROMs for .*\d{4}.* or PNDs for file-date-stamp or a PXML-date-field, should it become part of the standard one day)

The year should be extracted from the rom file name, the genre from the parental folder (as genre is very likely the way people sort roms into folders) or as a fallback from the rom filename. A standard has to be assumed/defined, i.e. this:

path/to/roms/platform(/GenreName)*/Game Name (1990) Genre Name [ID] (flag1) (f2) etc.suffix
(.*){punctationOrWhitespace}(\d{4}){punctationOrWhitespace}(.*){punctationOrWhitespace}
1 name, 2 year, 3 genre, 4 something else

• From the file name the year can be identified quite unambiguously
  • —> \b((19|20)\d{2})\b
• the genre assumed quite safely
  • —> either the parental folder name
  • —> or in the filename the fraction after the year until the next word boundary if GenreWrittenInCamelCase
  • —> or until the next punctation character .,-+|[](){}) i.e. Super Mario Kart (1992) Racing Kart - Nintendo -- User comment.zip
• region could also be identified quite easily, by checking against quite unique keywords from a wordlist such as:
  • —> EU, JP, US, etc…
• everything else really hard
  • as a they vary greatly (no wordlist to identify from safely),
  • and the field order ("What means what?") in the filename or order within the folder hierarchy cannot be guessed, but would need to be standardized (inflexible).

[porg]

Ok, some mockups:

I realized of course, that we likely need an overall redesign of the layout if we intend to use icons, screenshots, banners and thelike. Nevertheless would like to read your ideas on the principles presented in that mockup.