How to avoid "app store anarchy" by improving the behavior of Hildon App Manager

Posted on 2010-01-05 07:41 UTC by David Falkayn. Status: Under consideration, Categories: User Experience.

The problem

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.

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. This is a problem because there are many things that need to be installed by GUI that are not full applications. 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 in HAM 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.

An alternative way of classifying HAM is that it is actually intended to be a library, not a museum: simply an interface to the repositories. 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. Right now there's no "in between": either a package is in HAM (meaning it's in a user/* category), or it's not.


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. Furthermore, i reduced the user's choice by combining the two packages (which i did to reduce the clutter in HAM). This has the additional pathological problem of testing (10 tests for a package with nothing but 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, but this is the more complex case: multiple optional data files that work with multiple (somewhat) optional apps.


Talk threadFragmented, obsolete wiki page on the issue

Solutions for this brainstorm


Solution #1: "user/addons" package type and full use of debian package hints

Posted on 2010-01-05 07:42 UTC by David Falkayn.

Add a user/addons category of package type. Packages of this type can show up in HAM, but only when

(1) an installed package Suggests or Recommends it or Depends on a meta package that it Provides (The capitalized words are existing qualifiers in debian packages, but only Depends is used in HAM),

(2) a package that has been selected in HAM for installation has user/addons packages that it Recommends, Suggests, or Depends on.

In case (1), the user could browse all visible addons in a separate "Addons" category in HAM, just like the existing categories (Desktop, Games, Graphics, ...). Click on to install, also like in main categories.

In case (2), a checklist of all the available addons for the selected app would appear before the app installation confirmation, letting the user know that there are addons for the app and giving him a chance to install them at the same time.

Uninstalling would work in a similary way, with a way to view all the addons and remove them directly, and a checklist to uninstall when removing the parent app. Whether or not the checkboxes are filled by default would depend on the nature of the relationship and whether any onther apps are installed that have a relationship with the addon.

Updates wouldn't need any modification besides adding support for the user/addons package type.

This modification to HAM could handle everything from small mods such as alternative config files to data to plugins without cluttering up the UI or breaking apt compatibility. Such flexibility in the hands of devs will allow for much more configurable and modular projects while giving the user only as much detail as needed. It would eliminate most possible scenarios where a user would need to use the command line.

It would also alleviate the -testing conundrum, as the testing requirements for user/addons 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. In addition they are generally going to be data or plugins, hopefully less complex and subject to errors.

Latest activities to brainstorm How to avoid "app store anarchy" by improving the behavior of Hildon App Manager