Let it be noted in advance: I am an interaction / interface designer, and I'm glad that I can assist. Solving I
& UI issues is my profession.
For all devs, who design package managers, launchers, etc, I recommend to read the very holistically written guideline:
PND management workflow.
Luckily, some aspects already improved, will update these sections accordingly soon.
QML is so quick to do it's ridiculous. I could literally change the category package listing into something what MilkyTest has in 10 minutes or under
Glad to read that the technical implementation for UI/I
concepts within QML is quick and easy! As this means higher probability for realizing certain concepts.
The recently added sorting in the category view will fix "What are the newest PNDs in cat X?"
So per category (=filter) you plan to offer different sortings (alpha, moddate). Right? If, then please try to be consistent (both with UI and key assignments) throughout the different views.
I praise M for its elegancy in mixing filtering and sorting.
Also M concealed locally installed PNDs from the "remote last modified" views, whereas P lists all PNDs in "Last updated", confronting the user with information overflow.
Is the local package sorting really necessary?
Use case: You downloaded a bunch of apps from the repo at once (lets say 3-10). Want to quickly only test those new ones.
Current workaround: Note them externally, then test them in your launcher. Or: Use file browser as your launcher sorted by moddate (
PND_utils ensure that .pnds are properly assigned to and launched with pnd_run).
Reasoning: If you test only 1-2 apps at a time, then you probably remember their name, but people with not so much spare time on their hands, rather browse the repo every few weeks, and then possibly test more apps at once.
P.S.: As your app has the "remove" feature, by adding the "launch" feature, one could realize the workflow "
browse, install, test, keep (and tag) or remove".
FILTERING VIA TEXT:
P: Yes it has, in both installed and category views.
Logical error: If you only vaguely remembers an app by parts of its name, you want to search in ALL items, rather than searching (for the vaguely known!) consecutively in 10 different categories! Thus searching must be available in the remote-all and local-all views. Agreed?
FILTERING VIA CATEGORY for both local and remote PNDs. Is this necessary for local PNDs?
Having the same overview functionality for local & remote makes sense for advanced users.
Your approach: "simple by default, customizable by preference, changeable by design"
I have to give you praise, that both P and M serve both novice, advanced users, M even serving pro users (combination of filter & sort for both local & remote).
M seems very flexible already on the first screen impression, whereas P seems more "guiding".
But both always offer clear, yet unintrusive icons, and unintrusive hints for key shortcuts.
Afterword:
Commercial IT projects conduct marketing/business/user studies, then identify their target group, conduct research & interaction design, before going into technical requirements and implementation. Of course as a FLOSS and hobby project, OpenPandora does not have this approach, but I
/ UI designers could voluntarily do their research (interviews, polls) and share their guidelines.
There are yet no studies of the Pandora users (target group, identified motivation, goals, behaviors, skills).
If I had to assume I'd say: Geek, advanced or even pro with IT, able to handle complicated GUIs, even feeling at home with the CLI, readiness to read a manual before using SW, the UI must not necessarily communicate (all) of the functionality, and freedom and flexibility is important.
But maybe these assumptions (or projections) are only valid for a minority, and we have a significant large group, who is not so IT savvy, rather gaming interested.
Possibly the Pandora users are more heterogenous than we think.
Would be worth a study.
For now I respect general I
/UI guidelines, and maybe tend to serve the rather geeky user.
