Build Service/Navigation

From openSUSE

Pages

All Pages

• All pages will have the logo in the top-left. When the logo is clicked upon, it will take the user back to the front page.
• There will be a search entry on every page, providing quick access to searching for a different project.
• Every page will have a consistent header and footer (with the exception of the first page, which may or may not have a custom header).
• When logged out, a sign in box will be at the top right.
• When logged in, links to take the user to interesting places (such as the account editing page) should be in place of the sign in box, in the top right.

Keep in mind:

• Users look for software, not packages
• Packages are a technical delivery mechanism for software
• We should make everything as easy as possible for users -- catering to the non-technical and the gurus (and everyone in between)
• Minimize the number of clicks it takes to do things whereever possible

Front Page

Logged Out

• 'Sign in' box

• Description text

• Ideas for information to be exposed on the front page:
  • Popular projects (top ratings of the past day? week? month?)
  • Recently updated projects (new builds)
  • Popular tags (day / week / month)

• Browse by category
• Search entry

Logged In

Same as logged out, except no sign in and description. Also, being logged in will add the following:

• Links to projects the user has write access to ("My Projects")
• Account information
• Notifications from the system & other users

Also, we may consider links to:

• Recently visited projects
• Projects highly ranked by the user
• Projects recently commented upon by the user

Project Page

Tree-branch-style breadcrumb navigation will be below the header (and above the project page title).

An example is: Build Service > Projects > Games > SuperTux

Editing text input areas (titles, descriptions, etc.) should be similar to flickr's title and description editing.

Package Pages

Package pages should be treated like a sub page of the project page to which they belong. It should not feel to the user that they have moved to a different part of the build system. Being in a package page should make it seem as though the user is still in the specific project page, only editing something that is a part of the project.

Browsing

For browsing, we will want to use a hybrid of categories and tags (keywords) to allow the user to narrow down to the project (or projects) which they are looking for from many thousands.

Categories

There should be 5 - 10 different categories (optimally around 6, but we may need more, as the sample list below shows) which each project can be placed into. Projects will reside in only one category.

• Audio & Video
• Browsing
• Communication
• Development
• Games
• Graphics
• Office
• System
• Tools
• (All)

To seed the categories, we may wish to map a project's package categories to our project categories. This should allow for a mostly accurate, quick method to categorize most projects into our categories.

Tags/Keywords

Each project will have multiple keywords. Theoretically, number of tags can be anywhere from 0 to infinity, but we'll probably want to limit it down to 20 or 30 at a maximum.

We should have a stated policy that says that only applicable keywords shall be added to a project, and try to use keywords that are already used (if possible). Adding good generic keywords is fine too, of course.

Initial tags can be pulled from RPM categories (the heiarchy would be split into multiple keywords) and also the category keywords from the .desktop files within a project's packages.

Tags per project should be able to be edited by anyone logged in.

Tags should also have a weight. We'll want to make tags such as X, KDE, GNOME, etc. heavier (more important) so that they'll show up higher in the keyword area of the project browser.

We should handle tag assignment like the del.icio.us posting page when a logged in user is attaching tags.