Community Application Support/Design Apps aka Downloads

Latest revision as of 19:06, 2 June 2011

IMPORTANT - this page to be updated and moved under MeeGo Apps - please move or delete the content and redirect the page.

This page is intended to be a starting point of the design for the end-user downloads Apps website. In maemo.org there is maemo.org Downloads, which is a good example of what can be expected.

I'll give a list of available data and suggestions of what we can add. Let's try to find out what a MeeGo Apps website should show.

After we have created a clear list of requirements, we can ask the community for a design or design suggestions. The work ongoing at apps-beta is currently concentrating on getting the correct data from the community OBS and making sure everything is in place for community QA. The Apps website itself will be running on top of this data, but with a clear end-user oriented view on top of this.

The Apps website will also have an OCS api interface, so App installer/clients can use the same data as the Apps website.

Feel free to add points. Make sure you end the line with --~~~~, so it is clear who posted what.

Data available

Application info

• title
• short description
• long description
• version
• icon
• category
• screenshot(s)
• rating
• comments
• download link
• timestamp of publishing
• maintainer/company
• homepage
• code development (github, gitorious, etc)
• license

Statistics

• rating
• comments
• downloads (TODO, data not available yet)

Design

We should probably come up with wireframe designs, based on the discussion.

Front page

Target selection

The Apps front page will most likely be visited from either a MeeGo or a non-MeeGo device. When browsing to the site from a MeeGo device, we can probably detect what version of MeeGo and architecture it is running by looking at the browser string. If this is not possible, we should present a screen where one can select the target UX, architecture and version.

After this selection has been made, it will be stored in the current session so that the interface will only show the correct target.

Target front page

The actual front page for the selected target should show a top list of featured, new, updated, most downloaded.

Should it can also give a list of available categories? --Xfade 11:29, 9 February 2011 (UTC)

Sample Wireframe

This is just a sample of a listing of apps. It doesn't take into account target or a few other app details, but might be helpful to kickstart the discussion.

Apps List

App details page

This should show detailed info about the application including screenshots.

Sample wireframe. This is a bit old but can start the conversation.

App Page

App categories

We have to distinguish the categories used in .rpm or .deb packages from the ones we display in the Apps web UI. At the same time it is important to make categorization as automated as possible to avoid time consuming manual work once the packages are imported into the Apps web application.

Let's use the following naming conventions from now on:

• base categories: the ones shown in the Apps web UI
• package categories: the ones defined in the .rpm or .deb packages

There are a lot more package categories than base categories we plan to display. Therefore it is important to come up with a sensible mapping between the two groups of categories. The base categories should in theory cover all the package categories. It is also possible that a package category belongs to multiple base categories.

The idea here is that Apps web application will have a default list of base categories. Base categories are managed by administrators. Admins will be able to create, update, delete base categories and will also be able to map package categories to base categories.

The Apps web application will do the initial mapping, so all currently imported packages and their categories will be linked to the base categories. During the "continuous package import" the Apps web application will map new package categories as they appear. So whenever a package is being imported the system will check whether its package category has been mapped to a base category or not. If there is no mapping yet, then the tool will analyze the package category using some patterns and map it to a certain base category.

Currently we plan to use the following base categories (in no particular order)

• Internet
• Office
• Graphics
• Games
• Audio
• Video
• Education
• Science
• System
• Development
• Accessibility
• Network
• Location & Navigation
• Utilities
• Other

Comments and rating

Comment blocks should be designed to fit in the style of the website and show the appropriate info.