On Fri, Nov 7, 2008 at 2:37 PM, Simon Pickering
<[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] | http://www.bleb.org/
maemo.org Community Council member
_______________________________________________
maemo-developers mailing list
[email protected]
https://lists.maemo.org/mailman/listinfo/maemo-developers
