Release PND management suite


I thought a bit about it and came to the conclusion, that an indicator for wifi would be nice to have, as it is fullscreen and you don't always see, if you are connected or not.
I think it would make more sense to put this into the pandora overlay menu -- it's a generally important information, and a PND management software is located on a different level of abstraction.
 
Last edited by a moderator:
^ Agreed. The overlay menu will play a key role as a "device control center", available from all contexts (in game, multi tasking, etc). The question is: When will it be ready and well integrated? Until then a WiFi info within PNDManager may serve its purpose.

Christoph.Krn: I like your feedback concerning filtering. Have you tried Panorama with UI mode MilkyTest? Which one do you see as superior?
 
We've discussed with B-ZaR, and I think he is going to include version locking and partial upgrading, and other ideas gathered from this thread and past. The info element from repository is planned to be added into the package view as well. As for libpndman, I'm planning to do the backup option on the library level that some people requested, so you can try new versions and fall back if it's not good.
Very nice. :)


Another question: can the PND Manager update itself? ^^"
 
really enjoying using PNDManager. is it possible to specify download path such as /Menu/Games , /Menu/Apps, /Menu/Emulators?


ta
 
really enjoying using PNDManager. is it possible to specify download path such as /Menu/Games , /Menu/Apps, /Menu/Emulators?

Nope, that's currently limited by libpndman. I forgot that you can have sub directories inside the target ones.


This will be allowed in future, however it's up to clients/front-ends if they want to implent custom paths.
 
Uploading new release, since ED gave it an OK :) . It contains bugfixes, tunings and sorting by date of modification in the category view.

Comparison of Panorama in UI mode MilkyTest ("M") and PNDManager ("P")


SUMMARY: PNDManager is clearly superior with multi tasking and downloading, general stability, and a consistency in the drill-down/up navigation metaphor.


But besides this, Panorama Milky has a far higher usability, is far more sophisticated and original!


I'd personally prefer you'd fix Panorama's stability and add the multitasking & parallel download feature + the launch-app feature, then it's perfect!
First a word about MilkyTest, Panorama and PNDManager. Both PNDManager and MilkyTest are Panorama UIs. They use different panorama plugins for package management- pndmanagement-plugin and milky-plugin, respectively -with entirely different APIs and philosophies. The work on milky-plugin is pretty much over, since it's a mess and pndmanagement-plugin is better at everything. I've actually also learned quite a bit about making efficient and clean QML after doing MilkyTest, which has made PNDManager a LOT easier to maintain than MilkyTest.


When talking about Panorama UIs, anything you see is very easily changed or fixed. 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. It's the design, structure and the underlying stuff in the plugins that takes a lot of effort. Also adding new UI functionality takes some time to test and make efficient, but even that is fast.


Now, with this in mind...

OVERVIEW:


M: Icon + Title + Start of description text. Grouped by days.


P: Icon + Title + Date. No description! Very worthy for quick orientation. A lot of unused screen space. Date for each item is redundant if multiple entries share the same, M's grouping feature avoids that redundancy!


M has a FAR superior overview, as all its sorting, filtering and grouping methods are both available to local (=installed) and remote (=repository) PNDs, allowing super awareness about the package conditions on one's Pandora.


To prove M's superiority, just try to solve these user-centric questions/tasks in the different programs M and P, and you'll realize it:

  • What are the newest PNDs in the repo?
  • What are my newest installed PNDs?
  • What are the newest PNDs in cat X?
  • I want to install a PND which starts with "Super", but I don't remember the rest of the name...

The actually newest PNDs in the repo cannot be shown because the repo spec doesn't give the time a PND was first added, but a last modified time stamp. Last modified PNDs are visible in the home screen. Is the second one really a relevant use-case, or just a feature MilkyTest has and PNDManager doesn't? The recently added sorting in the category view will fix the third one. For the fourth: type "super".

SORTING:


M: By date, type, name in both local and remote PNDs.


P: User has no influence on sorting.
Sorting by date/title coming in the next version for category view. Is the local package sorting really necessary?

FILTERING VIA TEXT:


M: Start typing, reduces to items whose title matches the string.


P: No string filtering.
Yes it has, in both installed and category views.

FILTERING VIA CATEGORY:


M: Both for local and remote PNDs.


P: Only for remote PNDs.
Again, is this necessary for local PNDs? The installed view is pretty much modeled after the ones you find in Android and Meego devices to leverage the usability work on them (with some added bonuses).

Navigating in/out of depth (B/X) is a bit more consistent in P throughout all areas of the program (i.e.: "drill down": list > app summary > app screenshots), but M's has a very quick navigation scheme.
The scheme in MilkyTest is quick, but not very flexible. It's harder to add new features the more tightly a UI is designed. By applying common patterns in the design, making changes becomes so much easier.


I could concievably make another UI based on MilkyTest's paradigm (no use whatsoever using it as a starting point), but that would be another time sink for my limited development time :) . PNDManager will be maintained irregularly, but if I start another UI I can only spend half the time on both.


This is actually why way back I started the thread for the community to design a Panorama UI they want. I know there are talented people (like you and Cristoph.Krn here) in the community that could collaborate and come up with that perfect UI for me to implement. There was some ideas thrown around, but I actually wanted something more like the conversation here: analytic and professional. Also some talented artist making other graphics than stock icons and gradients would not probably hurt either :)

For touch screen I could think of all kinds of drawers and stuff, but for game controls it became a bit more difficult. I thought about making a "context menu" to stuff this kind of things into, but it would kinda break the simple UI scheme I have. Thus I just made a list of previously updated packages to the home view.
This kind of simplicity is what makes the PND manager easy to use, and yet simplicity is not the answer to complexity, at least not the way it is understood by most people.


Did you know that Windows 7's taskbar "Jump Lists" initially used arrows to indicate their existence? in order to /increase/ usability, Microsoft eventually decided to dismiss the Jump List arrows and instead trusted that advanced users would find the feature themselves (what now opens up "Jump Lists" on taskbar entries is right-clicking, which is quite well-known actually, even by not-too-advanced-yet users). Similarly, you could put a "Filter" screen behind a physical key (combination), such as F2 or Ctrl-F, but not indicate this from the main interface, and instead put the information into the documentation (or, at most, put something like a single guihint with a gear next to it into an appropriate place in the main interface).


Maybe you remember the "filter buttons"[1] I once wrote about (buttons that represent a regular expression, each of which can be altered and enabled/disabled from within the user interface). If you allow the user to create such buttons from within the F2-filter-screen, you can then display activated filter buttons on top of the category list in the main UI (or wherever else the filter is currently active), allowing the user to both see at a glance that a filter(s) is active and quickly disable it. For keyboard use, give each filter button a dedicated keyboard button combination (such as "Right shoulder" + "R" for the "Recent" filter button), so as to not interfere with the "instant search" function (this also allows powerusers to quickly toggle filters). Also, you can give each filter button an option to "display filter button in category list even if it's inactive".


Now, the interesting part is that the same mechanic can be used to add various other "buttons" which alter the display of the PND list in some way or another, without compromising the simplicity of the first level user interface.
I did not know that, and I remember the talk about filter buttons. I actually meant simple from two perspectives: observed simplicity and structural simplicity.


For observed simplicity you make a good point, one which nicely echoes in my signature: "simple by default, customizable by preference, changeable by design". For example, the filter buttons present a simple interface for novices, allow customization for advanced users and would actually be reimplementable/redesignable by the end user because QML is awesome.


From a structural standpoint, a context menu creates a tangled mess of state and signals between UI components. Consider this with the limited time I had (have) and you'll see I would never had made the deadline if I implemented it :) . I can do it later, perhaps.


I actually really like the button combo idea. I'll have to think about it some more before I can give a good answer to that.


For now, chalk design decisions that would require more UI functionality up to "did not have time". I love getting this feedback and will try to act on it.


Thanks for all the feedback and comments!


(the new version is up, go get it while it's hot!)
 
Last edited by a moderator:
Okay, I just downloaded this lovely package and gave PNDManager a spin. I basically found two problems:


1) The Wesnoth package has a multiline description. If you have *not* installed the package the description works lovely and the additional info is shown correctly. If you have the package installed only the first line will be displayed and no "additional info" from the repo is displayed. This is easily testable this days by just downloading wesnoth-1.10.x and comparing how 1.10.x and 1.9.x differ in the display.


2) The additional info section is not automatically updated unless the package itself is updated. This is a little sad since I just altered the additional info for the old wesnoth-1.8.x and wesnoth-1.9.x packages to point out that an update to 1.10.x makes sense.


EDIT: And a small FR: please allow to (additionally) quit using fn+q (aka 'Esc').
 
Last edited by a moderator:
The additional info section is not automatically updated unless the package itself is updated. This is a little sad since I just altered the additional info for the old wesnoth-1.8.x and wesnoth-1.9.x packages to point out that an update to 1.10.x makes sense.

This might be a limitation or design decision in repo. As far I know, it doesn't update last_modified timestamp when one changes additional information.


It would be possible to workaround this by allowing user manually do full synchorization against repo. But as far I kno (again), pndmanger doesn't do full synchorizations at all, only merges. However it's encouraged to clients do full pull either manually or per week at least (and especially first time). I suggested this to B-ZaR and maybe he adds it.






In milkyhelper you can do full pull with milky -Sy --nomerge (or uncomment the "nomerge" option in configuration file), and this information will be carried over pndmanager as they use same library and database files.


EDIT: And a small FR: please allow to (additionally) quit using fn+q (aka 'Esc').
F12 quits in panorama.


@porq


I noticed that you opened some issues to the old libmilky/milkyhelper project. I've renamed the milkyhelper repository in my github to libmilky, so that I can avoid such confusion in future.





I've fixed the other issue you opened, but I suggest you reopening
both issues inside libpndman repository so I can keep track of them.


(And I can remove the issues from the old project)


@B-ZaR


I'll start tagging the libpndman releases and do 'stable' branch whenever voting is over.
 
Last edited by a moderator:
I'll add esc as a quit key too. No harm there since it's currently unused. I could do a quick fix for the full sync and make a coutner that does a full sync every 5 syncs or so? Or based on date? Or manual full syncs with a modifier key?
 
cloudef is correct it only changes the date modified when an app is uploaded or updated otherwise it returns the header "HTTP/1.1 304 Not Modified" based on what data the client supplies the repo json page :) this way it doesn't have to generate new json on every request and saves on server load. but also it depends
 
Last edited by a moderator:
Let it be noted in advance: I am an interaction / interface designer, and I'm glad that I can assist. Solving IxD & 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/IxD 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 IxD / 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 IxD/UI guidelines, and maybe tend to serve the rather geeky user.
 
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.
By default only a few filters. Such filters are IMO mostly needed when browsing and discovering new applications. In the "installed" view the user is already familiar with the content and the amount of information is smaller. MilkyTest did have a nice filter/sort system. I could do a more generic "package browser" component that would contain all the filtering and sorting options, then apply it to all package views (installed, category, search), but it feels like it would break the context-sensitivity of the current views.

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.
This can be easily changed.

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.
OK, that's a valid use case. I tend to download-test-download-test, so I don't have that problem, but someone might.

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".
Considering it. The memory overhead of PNDManager may affect how the application runs (when there's no action, PNDManager takes 0% CPU), but I can see the use case of testing a newly downloaded application.

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?
If you only vaguely remember parts of the name of an application, you use the search facility. It searches all items, downloaded and not. Filtering by part of a title in category views is more useful when you know what you want already.

Having the same overview functionality for local & remote makes sense for advanced users.
Possibly. My focus with PNDManager was the novice user. If I see a "how do I do X in PNDManager?" question on the boards, I have failed :p

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.
You like MilkyTest a lot, don't you :D ? I may have to make a MilkyTest paradigm UI :p

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 IxD / 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 IxD/UI guidelines, and maybe tend to serve the rather geeky user.
I would find this information interesting myself.


And now onto the next one...

Phew, that was close... good thing you meant Cristoph.Krn, and not me, because I really don't like when people say things they can not prove. ;) My usability knowledge does not qualify as high-end. (I'm aware you did not state that, nonetheless it's important to know that my usability-related knowledge is not comprehensive.)
Stop dodging my compliments! :D


Your level of conversation on this topic is high-end in the context of this community. It is my opinion that you are talented in both analyzing usability and conveying your findings to others. I won't even try to prove it, but that is my perception. Or you are just fishing for more compliments by playing yourself down :p , nah.


(and sorry for mistyping your name)

Be very careful with this. Decoration can easily destroy usability if done wrong, and is not essential (the other way around, it can increase usability if done right and would then be called design, but I assume you already were aware of that).
True.

Just to be sure, what is your definition of "analytic and professional"?
You can't deny both you and porg have an analytic approach to usability and interaction. Compare your posts to most feature requests, which tend to offer no reasoning or higher level constructs to support the case. I call that analytic.


I did not mean professional in the sense of "you do this for your job" (porg does, though), but this conversation is very much like the ones I've had with some of my usability researcher friends. If I wouldn't know better I'd think you were doing usability stuff for your job :p
 
OK, yesterday I updated PND Manager over PND Manager and it worked. However, at the first try, the download stopped with no error message, but I guess this is because of the old repo problem with broken downloads, still happens from time to time, especialy when using a browser. maybe PND manager could detect and report if a download just hangs or is corrupted or have to be started again? ^^

On an absolute scale though, both graphical PND managers have a significant problem, which is that they do not provide much notable benefit over using a command-line interface.
Isn't it the biggest advantage of an GUI over a command line, because it IS an GUI? :D Do you really want to torture yourself with a command line when you can have modern GUI with a great usability? Or do you prefer command line usage on devices like Pandora, Smartphones, Tabletts or whatever?


Not everyone is a Linux Geek that want to manage it's device over a text terminal.
 
On an absolute scale though, both graphical PND managers have a significant problem, which is that they do not provide much notable benefit over using a command-line interface. I've actually mentioned some time ago what I think is the biggest problem about this, which is that multimedia content, in particular videogames, is much more efficiently explained via screenshots and videos than using textual descriptions alone.


Screenshots and videos are one important factor for multimedia PNDs ("discover"), the "install, test, keep (and tag) or remove" you mentioned is the other problem both PNDManager and MilkyTest have yet to tackle (more PNDManager, since that supersedes MilkyTest). I have previously written something relevant to both problems, see this beauty-get explanation (PND list in beauty-get) and the content linked therein.
Summarizing our common ground: Package managers (PM), where "discovery" is one of the main goals, need to have a multi medial presentation form (GUI).


In addition there can be other PMs, who are rather serving the "I already know, what I want" user.


Without any conducted research, I assume that a lot of OP users like to discover new content actively, as there is no "marketing / advertisement" machinery, which creates the needs, which leads to "I need game X, now I go into the appstore and search particularly for game X". Of course the forum discussion is one point for inspiration, which could lead to "I go to the Package Manager with a certain PND in mind".


Analyzing the current available software I know of, I would categorize their main focus, as follows:


Get specific SW which you already know of: PNDStore, Milkyhelper, Download to SD on your PC


Discover (and test) SW: Panorama Milky, PNDManager, beauty-get


I want my contributions and our discussion be about the latter category ("Discover").

the limit imposed by the current repository specification, the latter allowing users to manage PNDs, but wasting a *lot* of potential in the realm of helping people find PNDs of possible interest to them.

Let's identify, what could help the "discovery" of PNDs for certain user interest fields & personal preferences?


Suggesting a collective brainstorm. I give it a start:


What's already offered concerning "discovery" (to mixed degrees at repo.openpandora.org, PanoramaMilky, PNDManager ) :

  • Maintainer provided info:
    Title
  • Category + sub category
  • Description text (aids in full text search)
  • Icon + Screenshots + (Videos linked, not embedded) (emotional impression)
[*]User provided infos:

  • Downloads + Rating (quantitative popularity)
  • Comments (qualitative popularity)




What further repo features could help "discovery":

  • Recommendations of similar apps, based upon: (Current workaround: User comments like: "Also check out X, is similar/better/...")
    Free-keyword-tagging (not categories!)
  • "PND A similar to PND B"
  • "Part of series/family/bunde X"
  • My ratings (for estimating your preferences for other similar apps, probably hard to get a good algorithm, but I through it in as an idea)
[*]Visual impression side-by-side listing (like Christophs's beauty-get mockup): You can VERY quickly and efficiently get an emotional impression of very MANY apps, with no need to navigate in out to each item's detail/screenshot view.


[*]Metadata flags:

  • Originality: Plain software port; port with OP specific adaptions; original OP creation
  • Perspective: Top-down; Platform (2D); 3rd-person (3D); Ego (3D); ...
 
Last edited by a moderator:
porg -- It's not a good idea to put this kind of discussion into a bugtracker / feature request tracker such as this thread, because it is neither a bug nor a feature request. I suggest continuing this discussion in the thread for PNDManager/milkyhelper general discussion that my text you quoted originates from.


I can not take the time to write a full reply yet. I do want to note now though that beauty-get is not based on emotional concepts, because I want a user interface to /make sense/ (yes, I do understand what you mean by "emotional impression"). Neither does beauty-get have a main focus (because the additional features only make sense when the core functions remain solid), nor are the screenshots not included for rational purposes (I'm not using the concepts behind "emotional impression", I'm making screenshots representative). Some more about this can be found in the content I linked to from my post that you have quoted.
 
Last edited by a moderator:
That thread is for feature requests and bug tracking. I'd rather keep conversation in another thread to make it easier to maintain the list in the first post. Of course the conversation here might spark feature requests, but they should be concise and presented pragmatically.
 
Last edited by a moderator:
Back
Top