Difference between revisions of "PND management workflow"

From Pandora Wiki
Jump to: navigation, search
(Follow up)
(Follow up: suggestion... (also: see talk page))
Line 32: Line 32:
If your addition is large, please create only a short inline summary, and link the full content to a new page!
If your addition is large, please create only a short inline summary, and link the full content to a new page! (or: use <code><nowiki>{{HideableNotes|your text here}}</nowiki></code> to {{HideableNotes|hide your text}})
The content of the wiki describes aspects, which sometimes implicit bug reports, feature suggestions, etc, but not explicitly written and some of them yet not reported to the issue tracker.  
The content of the wiki describes aspects, which sometimes implicit bug reports, feature suggestions, etc, but not explicitly written and some of them yet not reported to the issue tracker.  

Revision as of 08:29, 27 October 2011

Whom it concerns

  • Thinkers who oversee the Pandora software platform as a whole and on the long run (core team & others)
  • Plus in particular the developers of:
    • Launchers like: MiniMenu, XFCE Menu, quick text based launchers
    • Package managers like: PNDStore, PanoramaMilky (I use "PanoramaMilky" to refer to "Panorama in UI mode milky test")
    • Package metadata/override editors/tools (PND and OVR)

Topic of this work group

Software packages are at the center of the Pandora, hence the overall way how to manage them are key to success of the platform's usability and popularity.

Currently the different aspects of managing and using PNDs are spread over a patchwork of different tools and workflows, and some aspects are yet not covered at all.

I now try to describe what is important from a user's point of view, what already exists (to my knowledge), what should be realized, and point towards possible gap-closing and synergies between existing solutions.

Disclaimer: Generally speaking, the patchwork per se is nothing bad. Openness is the principle of the Pandora, and it should by principle be always possible for a tool to cover/handle just a very small and specific task. Nevertheless from the user's perspective it is appreciated to have as little steps as necessary for common tasks in (at best) one uniform environment.

Follow up

The issue was first brought to attention within the developer forum.

It is discussed over there, and resulting actions, outcomes and developments are noted here in a structural form within the wiki-page into the SPECIFIC sections!

If necessary mark your addition with author and date in this markup format:

: A comment. If Daytime is given, state as UTC. -- Author YYYY-MM-DD HH:MM UTC
:: Further nested comment without a date only and no daytime. -- Author YYYY-MM-DD

Note: The double dash helps to quickly skip through the wiki page for authors and their comments.

If your addition is large, please create only a short inline summary, and link the full content to a new page! (or: use {{HideableNotes|your text here}} to hide your text)

The content of the wiki describes aspects, which sometimes implicit bug reports, feature suggestions, etc, but not explicitly written and some of them yet not reported to the issue tracker.

Please be autonomous enough, to realize your responsibility for your own. I spent hours brainstorming and writing this memo, even further dividing the tasks would overburden me. See it as a whole, co-ordinate your efforts (in the thread as this is "meta"), and only then slice it up on single issues. Thanks!

Main needs around handling of software packages (PNDs):

  • Discover
  • Install ( + Update + Remove)
  • Test
  • Tag
  • Launch
  • Overview

What is meant by this? How are they related?


The possibility of overview (filtering / sorting) can aid in all other tasks. The data source for "overview" is the metadata included in the PNDs plus the overrides included from OVRs (or other yet not developed over-ride/lay methods).


Currently, after installing new apps which you want to test, you have to find them as "the needles in the haystack" among the already installed apps, instead of a convenient mode, in which you can only run "new apps".

One might say: Just remember an app's name and find it from the "All" category. But what if you installed 3-5 new apps or even more … already a bit more complicated then!

If the PND framework would keep track of how often apps have been launched (or just a simple "ran-once" flag), this would provide a data basis for certain display modes like "Show new apps" or "Sort by usage frequency" in "overview" or "launch" applications.


Works quite good through:

  • Various information media related to OpenPandora like forum announcements, PandoraPress, various feeds.
  • Informal ways like chats, forums.
  • Formal catalogues / databases like the open handheld archives, appstore, repo), the latter being well suited for integration into software (machine readable). This medias especially increase the chances for newcomers, which are yet un-featured in the information and informal medias! If a user finds a well sorted catalogue, his/her readiness for trying new applications rises!

Application name, description, icon, screenshots, categories deliver a good enough idea. Filter options like categories, or sorting actions like "most recent" help to narrow down the selection even more.

This aspect is already very mature on the Pandora!

What could be slightly improved: If "discover" and "install"/"test"/"remove" are integrated into one application, your system could systematically keep track of already tested and deliberately removed applications as "uninteresting", and hide them in your further "disover" process! Sparing you a lot of time/attention seeing items again and again, which you already once found as uninteresting!

Right now, if you manually scan catalogues, you likely stumble across candidates, you already deliberately rejected, which steals you your time /attention. The only display mode which spares you this: Sort catalogues by "recently published", and thereby all new stuff is really new to you. But of course, all the display modes like, categories, tags, remain crowded with already seen stuff.


These 3 tasks must be hand-able within one environment!

At the Pandora beginnings, no tool existed, meanwhile tools came to the rescue!

I do not expect from the "launch" application (MiniMenu) to have "install/update" abilities, but at least have the "remove" ability, to facilitate "test" process. "Launch app, test wether you like it, quit app" and then "remove" right away if you don't like it!

MiniMenu: Shall be able to delete a PND application (if on remove-able media).

PNDstore and PanoramaMilky handle Install/update/remove quite ok already.

PNDstore: Shall remember default installation locations better, as PanoramaMilky already does.

After running a "scan for updates" the manager shall have the possibility to update all or only certain selected apps. (equivalent to iOS Appstore app).


The "tag" process overrides the metadata fields supplied in the PND manifest with the fields the user finds better suitable (i.e. file an item under another subcategory, add a custom note, etc), which later aids "overview" and "launch" applications.

Right now there is neither a well-working workflow for "test an app, quit it, tag it" nor a mass-editor for tagging multiple apps according to your memories or notes.

The advantage of "test an app, quit it, tag it" is, that the user's memory of the tested applications is still fresh, hence the tagging is easy to make and appropriate.

There is currently no tag concept associated with PNDs. It is possible to abuse notes for this purpose, but none of the tooling will really be able to do anything useful with it as there are no semantics specified for the fields. -- Caine 2011-10-10 12:53 UTC

MiniMenu - Test an app, quit it, tag it

Problem 1: After you ran an arbitrary app and quitted it, you do not return to your last position (bug #241). You need to find that app again first. And then go into submenus. And only then tag it. Problem 2: After the override of ONE SINGLE app, MiniMenu currenty completely restarts, thus rescans **all** .PNDs and .OVRs! Only re-reading the affected PND + OVR would tremendously speed up.

If both problem 1 + 2 would get fixed the method "test an app, quit it, tag it" would practically work.

Mass OVR editor

A spreadsheet-like list with all apps, with the columns: icon, name, custom note, cat, subcat, possibly also summary/screenshot as obtained from repo-catalogue to refresh one's memory, where one can then quickly edit all the metadata of all apps to suit one's own sorting system better.

Caine already developed "OVR editor", and considers to realize such a "OVR spreadsheet editing mode". http://boards.openpandora.org/index.php?/topic/4201-ovr-editor-and-pnd-aware-application-launcher/


Your interface for launching apps. The data source for this comes from the PND files plus your OVR override files ("tag" applications).

Launch could be much more fine grained, please see the section on the possibilities of combining: Launch + overview.

Besides this some suggestions of improving existing features right here in this section.

Hotkey application launcher

Well known from many OSes, this feature would be fine within the Pandora too.

Triggered by hotkey working from everywhere or from menu/desktop entry -> text input with auto completion of installed apps -> launch.

I think that already exists. I just don't know which one's, and how to set the hotkey for it.

XFCE launch menu shall have meta trees "All apps" and "All games"

MiniMenu has an "All" category tree. The XFCE launch menu doesn't! Would be fine if it had one meta tree which "holds them all".


Many combinations of tasks are already described in one of the affected task "verb" sections. Some of these involve many others, and are therefore described below as combinations of "task verbs".

Discover + install + update + remove

Right now "discover", "install" and "test" are separate workflows.

PanoramaMilky very well unites "discover" + "install/update/remove".

I think discovery could be improved in MilkyTest by allowing ordering packages by rating and showcasing random highly rated applications. Not sure how the showcasing would work with the UI, but it's something to consider -- B-ZaR 2011-10-10 05:41Z
Discovery should be handled by browsing the apps in the repo along with their preview pictures to get an impression of the content. Sorting orders should include alphabetically, by rating, by author, and newly added (excluding recent updates). Also of note, we are essentially talking about CRUD operations on apps. Create (install), Read (run), Update (upgrade app/edit OVR) and Delete. I've always assumed these to eventually merged into a single application, though so far I omitted the OVR files in that vision. -- Caine 2011-10-10 12:33 UTC

PanoramaMilky: Would be cool if it could "launch" apps. You could "test" the app, then quit it. PanoramaMilky must then have the previously launched app selected so that you can immediately "remove" or keep it.

Already planned, though I'll probably fork MilkyTest to create a more fleshed out UI under a different name. MilkyTest was always about testing milky-plugin. I'll post more on this to panorama's beta thread. -- B-ZaR 2011-10-10 05:41Z
I propose to make "Panorama in UI mode MilkyTest" a standalone PND. -- porg 2011-10-10 17:00 UTC

Launch + overview

Currently MiniMenu allows a filesystem like browsing with metaphors like tabs as categories / subcategories as subfolders within that tabs, and some generated meta categories like "All".

These additional display modes would help:

New meta category "Fresh", "By Date Added", "By Date Published"

This is for aiding the "test" process, particularly showing yet untested or fresh apps.

Implementation could be hard: As the PND has no central registry, but rather "certain files at certain places", which are scanned to then provide a "certain basis for certain launchers", the tracking of this dates or usage amounts must happen within that scanners/launchers, which must either have the "test" and "tag" abilities themselves, or must make that data available to those applications. Does anyone know what according data is tracked within MiniMenu?

Rating and/or favorite system.

Date source for "favorite" and/or "sorting" is provided by from your "tagging" (overrides). In addition the "launch" application may have its own methods to "rate" or "favor" applications. (Again this would be good for the approach: "Run app, test app, tag it".)

MiniMenu should show a tab "Favorites", which contains all apps, which are flagged as "favorite" or which have a rating above a certain treshold (i.e. on a scale from 1-5, all which are equal or higher than 4).

MiniMenu should show one tab "By rating", which contains all apps, sorted by rating (as sort key 1, and by alphabet as sort key 2).

If you navigate within the categories and sub-categories folders/tabs, a certain hotkey or menu command, should trigger the "favorite display" or "sorted display", which filters/sorts the contained items accordingly.

Pressing favorite hotkey first: Shows only favorites.

MiniMenu: Flawed tab display of sub-categories if they have a common string beginning Pressing favorite hotkey again: Shows favorites on top of others. Pressing favorite hotkey again: Disables favorite view mode, normal view again.

Pressing sort hotkey first: Sorted from best to worst Pressing sort hotkey again: Sorted from worst to best Pressing sort hotkey again: Disables sort view mode, normal view again.

MiniMenu - Improvements of existing functionality

There are many MiniMenu related bugs to be resolved! Just search the bugtracker for MiniMenu