Re: Beyond Application Manager Categories
(For some reason, this keeps failing to get through to the list -- trying again.) I guess I imagine something more like how Mauku functions. Tapping a Category would take you to: *One list for installed and uninstalled apps: any item that's installed becomes grayed-out (or the zebra stripe is a different color), indicating that it is installed; what was the install icon on the right becomes an uninstall icon*Simple, kinetic scrolling list (with zebra striping, as referenced above) *Thumbnail of app on left, title (bold) and info in the center, single-tap download icon on the right *Double-tapping on row opens package contents (e.g., application, plugins, other affiliated files): package contents would act the same as described for (main) installable apps *Tap/hold on any row (main or contents) gives other options (e.g., more info, ratings = real-time star selections, version, package date, keywords, category, info, whatever, etc.) Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beyond Application Manager Categories
On Fri, Nov 7, 2008 at 9:28 AM, Marius Vollmer [EMAIL PROTECTED] wrote: But the current AM is a pretty unfriendly place for browsing a long list of available applications. In the past, I kept saying that I don't want the AM to turn into a portal for applications, that should be left to the browser. We have downloads.maemo.org, which is this portal. Are people using it? 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? Downloads.maemo.org could use information from the device to give a view that is nicely tailored to each device. I really hate browsing Downloads on the device. .installs are awkward, Downloads is slow and irritating and the browser just isn't responsive enough. My personal desire is to see h-a-m become similar to the AppStore as the one-stop-shop for applications and packages. Native applications will always be faster, slicker and more usable than a web-based equivalent. Especially on a mobile device. Applications might want to do their own add-on management, or want to defer to a central application that is good at it. For example, the theme selector could list available themes in addition to the installed ones. The media player might be able to figure out that a codec add-on is missing and offer to install it. This goes into the direction of PackageKit and package management as a system service. Something to keep in mind. It'll take some non-trivial amount of work and commitment. I like this idea, but the implementation sounds rather involved. Maybe something to target for farther down the road, but not really something I see as realistic in the Fremantle timeframe. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Beyond Application Manager Categories
Hi, with the recent category discussion coming to a close, I already have something to think about that might go beyond categories. But first, many thanks to everybody involved in the recent category cleanup! I will catch up carefully and will do my best to make the necessary changes to the Application Manager. Ok. I think a central component like the Application manager is OK for the routine maintenance task of keeping your software uptodate. You want to be notified about available updates and hit a big button to install them all. Maybe you want to review a bit what you are about to install. But the current AM is a pretty unfriendly place for browsing a long list of available applications. In the past, I kept saying that I don't want the AM to turn into a portal for applications, that should be left to the browser. We have downloads.maemo.org, which is this portal. Are people using it? 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? Downloads.maemo.org could use information from the device to give a view that is nicely tailored to each device. 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. Applications might want to do their own add-on management, or want to defer to a central application that is good at it. For example, the theme selector could list available themes in addition to the installed ones. The media player might be able to figure out that a codec add-on is missing and offer to install it. This goes into the direction of PackageKit and package management as a system service. Something to keep in mind. It'll take some non-trivial amount of work and commitment. But, maybe we can get something worthwhile with only a few changes to the current Application manager. - We can let applications open a specific category in the Application manager, with the idea that useful add-ons for that application are found in that category. This would put more pressure on the categories: the Boingo category might want to come back, for example. - Or we can let applications compute their own list of packages (using debtags, say), and ask the Application manager to install them. This would essentially create a temporary category under control of an appliction. Will users understand what is going on? Opinions? Kristiina and Tero (in CC) have a need for something like this. Am I on the right track here? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beyond Application Manager Categories
Removing the option to install applications listed inside our configured repositories takes away greatly from the system. The UI is at fault, not the actions it performs and data it contains within it. Gary On Fri, Nov 7, 2008 at 2:28 PM, Marius Vollmer [EMAIL PROTECTED]wrote: Hi, with the recent category discussion coming to a close, I already have something to think about that might go beyond categories. But first, many thanks to everybody involved in the recent category cleanup! I will catch up carefully and will do my best to make the necessary changes to the Application Manager. Ok. I think a central component like the Application manager is OK for the routine maintenance task of keeping your software uptodate. You want to be notified about available updates and hit a big button to install them all. Maybe you want to review a bit what you are about to install. But the current AM is a pretty unfriendly place for browsing a long list of available applications. In the past, I kept saying that I don't want the AM to turn into a portal for applications, that should be left to the browser. We have downloads.maemo.org, which is this portal. Are people using it? 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? Downloads.maemo.org could use information from the device to give a view that is nicely tailored to each device. 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. Applications might want to do their own add-on management, or want to defer to a central application that is good at it. For example, the theme selector could list available themes in addition to the installed ones. The media player might be able to figure out that a codec add-on is missing and offer to install it. This goes into the direction of PackageKit and package management as a system service. Something to keep in mind. It'll take some non-trivial amount of work and commitment. But, maybe we can get something worthwhile with only a few changes to the current Application manager. - We can let applications open a specific category in the Application manager, with the idea that useful add-ons for that application are found in that category. This would put more pressure on the categories: the Boingo category might want to come back, for example. - Or we can let applications compute their own list of packages (using debtags, say), and ask the Application manager to install them. This would essentially create a temporary category under control of an appliction. Will users understand what is going on? Opinions? Kristiina and Tero (in CC) have a need for something like this. Am I on the right track here? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Beyond Application Manager Categories
But the current AM is a pretty unfriendly place for browsing a long list of available applications. In the past, I kept saying that I don't want the AM to turn into a portal for applications, that should be left to the browser. We have downloads.maemo.org, which is this portal. Are people using it? 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. 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?), but basically 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.), I'd prefer not having to install it to be able to see the available plugins. I do agree though that hiding them would clean up the list and would be suitable for most of the time (though it should be possible to unhide them if needed). Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beyond Application Manager Categories
Hi, Sorry to jump in a thread like this as a stranger! My name is Nicolas and I am just a N810 owner interested in development. This thread makes a lot of sense to me because as a user I am a bit frustrated with the current AM. So just my 2 cents, I totally second Simon comment about being able to see available plugins before installing an app. What about having a kind of nested view which would expand available plugins when you select an app in the AM (or with an expand icon somewhere). Near the title of the app you could even have a number indicating the number of plugins available for a particular application? Of course this would mean introducing a kind of hierarchy in the package index (do current package index already support this?). I don't have any drawing skills to illustrate this, so I hope my explanations make sense. Best regards, Nicolas. We spoke about this before (not sure whether it was on the list or not, does anyone have a link - Jaffa?), but basically 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.), I'd prefer not having to install it to be able to see the available plugins. I do agree though that hiding them would clean up the list and would be suitable for most of the time (though it should be possible to unhide them if needed). Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beyond Application Manager Categories
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 maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beyond Application Manager Categories
You could run something on maemo.org that would produce an app list in multiple forms with all the extra data n the BROWSER, then a keyed installation target for the app manager which would do the right thing. This would require a small new API to the app manager that would allow it to do an install of something it already has in the index, but then would offload the fancy formatting and parsing to a periodic task on the server and create static pages instead of having to do complex things from within app manger. Meanwhile, could someone get the following things copied from the tools or sdk into where they are directly visible, perhaps user/utilities (feel free to add to the list) bluez-utils-test (I really need l2ping and rfcomm) less (I use the added features over more and am used to typing this to view files) strace wget nano and/or nano-tiny tcpdump traceroute wget These are all released and well debugged, and I could duplicate some (but not all) of the functions by writing something for extras, but why not use what is already there. On Fri, Nov 7, 2008 at 10:01 AM, Andrew Flegg [EMAIL PROTECTED] wrote: 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 maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
