maemo.org - Talk

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Brainstorm (https://talk.maemo.org/forumdisplay.php?f=47)
-   -   [sandbox] How to avoid "app store anarchy" by improving the behavior of Hildon App Manager (https://talk.maemo.org/showthread.php?t=39073)

Flandry 2010-01-02 19:16

[sandbox] How to avoid "app store anarchy" by improving the behavior of Hildon App Manager
 
Executive summary: App Manager doesn't provide a way to manage add-ons and associate their packages with apps. Instead, they appear in the listing with full apps. This leads to bloated, long listings of apps to install that contain non-apps.

Edit: Please read the explanation at the brainstorm page first, as that is the later evolution of this first post into an actual brainstorm proposal.

The reason for moving this from Development to Brainstorm is that
  • it became clear that few developers who frequent the forum had any comments. This may be in part due to the fact that it is somewhat out of "our" hands.
  • this is a general UI issue as much as it is a technical issue, thus requires input from more than just developers.
  • it will require significant community consensus, backing, and effort to get the best solution to this to happen because it requires changes to a Nokia-controlled app as well as support by app maintainers. Please show your support for a proposed solution by voting for it and be prepared to code and/or implement the needed changes in the packages you maintain and/or make a lot of noise to get this added by the Nokia devs. Squeaky wheel gets the grease and all that...
If a considered, coherent, and complete solution for this issue is not implemented soon, it will be too late to save Fremantle from app manager madness and this will become another one of those "fixed in Harmattan" blots.


The problem

I've packaged up a few different games for maemo now and almost invariably run into the same problem: there's a huge gap between a full-fledged /user app that shows up in HAM's (Hildon App Manager) listing and, well, anything else. I'd like to know what methods others are using to close this gap, and perhaps discuss a wiki/guideline/brainstorm/best practices approach if there seems to be use in it.

It seems that using debian packages and related utilities is the obvious way to deliver these parts; the interface is where the problem arises.

HAM: Museum or Library?

When i open up HAM, i want to visit the Museum of Maemoware: to be able to browse through a list of complete, independent apps for my device. I suspect that is what most users also expect. This means that making every add-on and optional part of apps visible is going to be overwhelming and unwieldy to the end user, and render the UI useless. Even the number of packages in -devel right now is approaching overload given the current granularity of package cataloging.

Someone might offer an argument that HAM is actually intended to be a library, not a museum: simply an interface to the repo. Whether that's what "maemo" had in mind for it, i don't know, but i don't think that's what most people expect from it, even if it needs to serve that role, too.

Examples

Let me give a couple examples. UQM is a classic game that has (in debian) a binary package and various data packages. One smallish data package is required for the game to function. The other two larger ones are completely optional, but add substantially to the user experience.

In this case, i made the required data package a dependency of the game package, and put the other two packages together in a massive 130 MB package that shows up under Games in HAM along with the binary package. The user can add or remove this content at any time, as it should be, but it's also hanging out there for all to see, even those who don't have uqm installed. This has the additional pathological problem of testing (10 tests for a package with a single large data archive in it?), because all packages that show up in HAM (rather than just being installed as dependencies) have to go through Extras-testing.

Case 2: Doom. Prboom is one of several doom engines that could be ported to fremantle. The variants actually have fairly different capabilities (e.g. strong multiplayer capabilities, faithfulness to the original game feel, etc.) and there could be a user who would want to install more than one. These would (possibly) use the same (independent, optional) data files. Just as with uqm there are multiple data files and each is optional, and this time optional for a number of apps.

Solutions

The process of organizing my thoughts for this has made the ideal solution seem clear to me, but it's not an immediately available solution and the exact implementation details aren't important at the moment. Add a user/optional category or hierarchy of package type. Packages of this type only show up in HAM when they Provide a virtual package that is Required, Recommended or Suggested (the latter two are debian control file directives that are AFAIK currently ignored by HAM) by currently installed apps. There is the whole meta package arrangement that could assist with organizing this.

How the user would browse to the options isn't that important for the moment, but i can think of a few possibilities including showing the original app icon/entry but with an overlay on it to indicate that it will bring up an options installation menu. The options could also be given (in a list with checkboxes) in the installation dialogue for any main app package in HAM, so the user is aware of them and can install them along with the main app.

This could handle everything from small mods such as alternative config files to data to plugins without cluttering up the HAM UI and without requiring command line installation of any files. It would also alleviate the -testing conundrum, as the requirements for user/optional packages could be reduced. (They can't be installed without one of the full-class user apps that they are listed under, and that one has to go through full testing.)

What do you think?

In the meantime, what's the best way to do this? Having some extra menus and network code in the app to download data is a waste of developer time and not a consistent UI. Actually, it seems like a bad idea in many ways: it can't use apt-get or dpkg because it's not running as root, and it can't install into the program directory without modifying the default debian installer behavior to change the owner of the directory when the main app is installed...

There are script options during installation to let a user choose optional packages, but that doesn't let them add things later, or remove them later, etc.

Jaffa 2010-01-03 00:03

Re: RFC: Closing the gap between full-fledged user apps and invisible packages
 
My own thought on this is sub-sections within the Application Manager::

http://wiki.maemo.org/Task:Package_c..._subcategories

You could also have it so the section contained the parent package name - then, if the package wasn't installed, users wouldn't see the content. However, there is an argument that the extra content may make it more enticing.

Another option is to have HAM prompt the user if "Suggests" are specified:

Quote:

This packages suggests, but does not require, the following additional packages: ...
You could also have a "Details" button available for each one, and a dialogue-based version of the existing GtkTreeView containing size, icon etc.

However, the issue with doing anything with HAM is getting the code into users' hands.

DrWilken 2010-01-03 00:10

Re: RFC: Closing the gap between full-fledged user apps and invisible packages
 
Quote:

Originally Posted by Flandry (Post 450211)
The options could also be given (in a list with checkboxes) in the installation dialogue for any main app package in HAM, so the user is aware of them and can install them along with the main app...

I second this idea... ;)

If You haven't installed the game/app yet why would You want to see which additional packages are available to it? :)

Flandry 2010-01-04 17:53

Re: RFC: Closing the gap between full-fledged user apps and invisible packages
 
Thanks for the link Jaffa. None of the proposed additions there seem to address this in a completely general fashion except the facets part, which could be used for the same purpose in a less coherent way than what i suggested, but has other advantages.

This seems to be a fairly important UI issue to avoid "the breakdown of the app store" (lcuk's words on IRC) while it's still early enough to standardize on an approach, but isn't getting much discussion. Is that because it's not really up to us with HAM being out of our control?

This would probably be better as a brainstorm, now that there's a clearly defined problem with no current solutions, and at least one proposed solution. The brainstorm page is taking forever to load but if it ever does i'll set it up as a brainstorm so that it can be opened up for input from the whole community.

Jaffa 2010-01-04 20:40

Re: RFC: Closing the gap between full-fledged user apps and invisible packages
 
Quote:

Originally Posted by Flandry (Post 452788)
This seems to be a fairly important UI issue to avoid "the breakdown of the app store" (lcuk's words on IRC) while it's still early enough to standardize on an approach, but isn't getting much discussion. Is that because it's not really up to us with HAM being out of our control?

HAM is one of the most open user-facing apps in the OS; so I suggest trying to come up with a spec (or patch!) which can be run past the HAM developers on its official mailing list:

maemo-developers@maemo.org

Of course, getting a patch accepted and getting it in users' hands are two different operations. However, since Mer more closely tracks the upstream, it will - if nothing else - benefit Mer users.

Flandry 2010-01-05 07:46

Re: RFC: Closing the gap between full-fledged user apps and invisible packages
 
Brainstorm link:
http://maemo.org/community/brainstor...n_app_manager/

I've refined the problem statement and solution there compared to the original post here.

Could a mod please move this to brainstorm?

Flandry 2010-01-05 14:27

Re: RFC: Closing the gap between full-fledged user apps and invisible packages
 
Ok great, now could a brainstorm mod please work their magic? :D

qgil 2010-01-27 20:23

Re: RFC: Closing the gap between full-fledged user apps and invisible packages
 
Quote:

Originally Posted by Flandry (Post 453973)
Ok great, now could a brainstorm mod please work their magic? :D

What needs to be done?

btw, this is a well formulated brainstorm proposal touching one problem that, if unsolved, will generate lenty of posts in this forum. I'm surprised it's not getting more votes.

Flandry 2010-01-28 06:03

Re: [sandbox] How to avoid "app store anarchy" by improving the behavior of Hildon App Manager
 
Thanks Quim. I guess nothing is to be done unless the issue draws enough support to warrant moving forward. I agree with your analysis and have been equally puzzled by the lack of interest in the issue. The problem is that not that many people have been put in a position that they've had to think about this impending problem; it's one of those things that nobody notices until it's too late. If i hadn't encountered it in trying to figure out the best packaging solution for a few games, i'd not have thought about it, either.

So, what's to be done, indeed?

qgil 2010-01-28 14:06

Re: [sandbox] How to avoid "app store anarchy" by improving the behavior of Hildon App Manager
 
The good news is that there are currently 10 votes.

Could Jaffa's proposal described above be posted as solution? Technically I could do it myself but I'm noticing that some people imagine some kind of Nokia endorsement (or my endorsement) in the proposals I cop&paste.


All times are GMT. The time now is 23:31.

vBulletin® Version 3.8.8