[maemo-developers] Beyond Application Manager Categories

[From: Andrew Flegg]

On Fri, Nov 7, 2008 at 2:37 PM, Simon Pickering
<S.G.Pickering at bath.ac.uk> wrote:
>
>> As a thought experiment, could we remove the "Browse installable
>> applications" button from the AM and get by with just
>> downloads.maemo.org?  Should we work on better integration?
>
> Definitely not until the browser works faster and it's easier to click
> links. For me, AM is far quicker and less frustrating than having to browse
> that site (slowly) and click the little links.

Absolutely agreed. I've no problem with the AM providing a more
compelling and rich UI (almost like an App Store or
downloads.maemo.org), but the browser itself is such a long way from
that (as is downloads.maemo.org, if we're honest) that the two
interfaces are required.

>> There is another angle: many applications are extensible with plugins
>> and add-ons, etc.  There is a lot of potential there to simplify
>> juggling with these packages.  For example, there is no point to even
>> show the pidgin-l10n-klingon package if you don't have Pidgin
>> installed.
>> This add-on management is probably a bit hard to do for a portal site
>> like downloads.maemo.org.  But the current AM is not much better.
>
> We spoke about this before (not sure whether it was on the list or not, does
> anyone have a link - Jaffa?)

I *think* it was on IRC, when I was suggesting somehow only showing
sub-packages when the parent was installed. You responded...


> I would like to be able to see what plugins an app has before installing
> it. I might want to see if Pidgin has current support for Gadu (or any
> other protocol, etc.)

...which makes perfect sense as a requirement.

So, I'm convinced that all plugins should be viewable without
installing the app. And I don't want `n' different apps with `n'
different UIs for installing plugins[1].

My current idea here, from a UI point of view is:

  * Category list changes from large buttons to a list, *exactly* like
    the package list; with icons, descriptions and the "size" being the
    count of packages contained.

  * The package list supporting sub-categories which should match on a
    package name (this can then show the fuller name, if available).
    Sub-categories should not be used to create an expandible tree: only
    for grouping packages related to a single overall package.

  * The sub-categories in a package list would look the same, and
    use the same code, as the top-level view; tidying up the AM source
    a little and giving a more consistent UI.

How we then encode that sub-categorisation is unclear. One suggestion
I had was to continue along the existing `Section' approach, as this
then allows for *developer* consistency:

    https://wiki.maemo.org/Task:Package_categories#Application-specific_subcategories

Cheers,

Andrew

[1] Although, I can imagine it would be useful for an item on an app's
    menu to open AM at a particular subset of packages (i.e. the plugins
    for that app).

-- 
Andrew Flegg -- mailto:andrew at bleb.org  |  http://www.bleb.org/
maemo.org Community Council member