Build Service/Navigation
aus openSUSE, der freien Wissensdatenbank
Inhaltsverzeichnis |
Seiten
Alle Seiten
- Alle Seiten werden in der oberen, linken Ecke das Logo tragen. Wenn das Logo angeklickt wird, gelangt der Nutzer zurück zur Frontseite.
- Auf jeder Seite wird sich ein Eintrag zur Suche befinden, welcher schnellen Zugriff auf die Suche nach verschiedenen Projekten bietet.
- Jede Seite wird über eine konsistente Kopf- und Fußzeile verfügen (mit Ausnahme der ersten Seite, welche auch eine angepasste Kopfzeile haben kann).
- Wenn man nicht angemeldet ist wird sich oben rechts eine Box zur Anmeldung befinden.
- Wenn man angemeldet ist, sollten an Stelle der Anmeldebox oben rechts Verknüpfungen zu interessanten Orten (bspw. zur Seite zur Einrichtung des Benutzerkontos) stehen.
Vergessen Sie nicht:
- Nutzer suchen nach Software, nicht nach Paketen
- Pakete sind ein technischer Vorgang, Software auszuliefern
- Wir sollten für die Nutzer alles so einfach wie möglich machen -- angepasst an die Nichttechniker und die Gurus (und alle dazwischen)
- Wo immer möglich, sollten der Aufwand an Klicks, um etwas zu erreichen, minimiert werden
Frontseite
Abgemeldet
- Anmelde/'Sign in'-Box
- Beschreibungstext
- Ideen zu Information die auf der Frontseite herausgestellt werden sollen:
- Beliebte Projekte (beste Bewertungen der letzten Tage? Wochen? Monate?)
- Kürzlich aktualisierte Projekte (neu gebaute Pakete)
- Beliebte Markierungen/Tags (Tag / Woche / Monat)
- Nach Kategorien sortiert durchstöbern
- Sucheinrag
Angemeldet
Gleich wie abgemeldet, allerdings ohne Anmeldung und Beschreibung. Außerdem wird die Anmeldung folgendes hinzufügen:
- Verknüpfungen zu Projekten auf die der Nutzer Schreibzugriff hat ("Meine Projekte/My Projects")
- Kontoinformationen
- Benachrichtigungen vom System und anderen Nutzern
Außerdem könnten wir uns noch folgende Verknüpfungen vorstellen:
- kürzlich besuchte Projekte
- Projekte die vom Nutzer hoch bewertet wurden
- Projekte die vom Nutzer kürzlich kommentiert wurden
Projektseite
Unterhalb der Kopfzeile (und oberhalb des Titels der Projektseite) wird sich eine verzweigte Navigation befinden.
Ein Beispiel: Build Service > Projekte > Spiele > SuperTux
Texteingabfelder (Titel, Beschreibungen, usw.) sollten der Titel- und Beschreibungsbearbeitung von flickr ähneln.
Paketseiten
Paketseiten sollten als Unterseiten der jeweiligen Projektseite behandelt werden. Beim Nutzer sollte nicht der Eindruck entstehen, dass er sich auf einmal in einem anderen Teil des Build Systems befindet. Auf der Paketseite sollte sich der Nutzer immer noch fühlen, als sei er auf der dazugehörigen Projektseite, wobei er nur etwas bearbeitet was Teil des Projekts ist.
Stöbern
Für das Durchstöbern werden wir eine Mischung aus Kategorien und Tags (Schlüsselwörtern) verwenden, um es einem Nutzer zu ermöglichen, so direkt wie möglich zu dem Projekt (oder den Projekten) zu gelangen, nach dem er unter tausenden geschaut hat.
Kategorie
Es sollte fünf bis zehn Kategorien geben (optimalerweise so um die sechs, aber wie man an der Beispielliste unten sehen kann, brauchen wir wahrscheinlich mehr) in die jedes Projekt eingeordnet werden kann, wobei eine Projekt nur zu einer Kategorie gehören wird.
- Audio & Video
- Browsing
- Kommunikation/Communication
- Entwicklung/Development
- Spiele/Games
- Grafik/Graphics
- Büro/Office
- System
- Werkzeuge/Tools
- (Alle/All)
Um die Kategorien zu platzieren, könnten wir uns wünschen, die Kategorien eine Projektpakets auf unsere Projektkategorien abzubilden. Dies sollte zu einer größtenteils akkuraten und schnellen Methode führen, die meisten Projekte in unsere Kategorien einzuordnen.
Tags/Markierungen/Schlüsselwörter
Jedes Projekt kann durch mehrere Schlüsselwörter gekennzeichnet werden, deren theoretische Anzahl zwischen Null und Unendlich liegen kann, wobei wir die Anzahl aber wahrscheinlich auf ein Maximum von 20 bis 30 begrenzen wollen.
Wir sollten dabei eine feste Regelung haben, dass nur verwendbare Schlüsselwörter einem Projekt zugewiesen werden sollten und versuchen, nur Schlüsselwörter zu verwenden, die (wenn möglich) bereits benutzt werden. Das Hinzufügen von guten, allgemeinen Schlüsselwörtern ist natürlich auch schön.
Die anfänglichen Tags können von den RPM-Kategorien übernommen werden (deren Hierarchie in mehrer Schlüsselwörter aufgeteilt würde), wobei man auch die Kategorien innerhalb der .desktop-Dateien eines Projektpakets einbeziehen kann.
Die Tags sollten für jedes Projekt von jedermann geändert werden können, der angemeldet ist.
Die Schlüsselwörter sollten außerdem gewichtet werden, so dass Tags wie X, KDE, GNOME usw. schwerer (wichtiger) sind und weiter oben im Schlüsselwortbereich eines Projekts angezeigt werden.
Wir sollten das Zuweisen von Schlüsselwörtern für angemeldete Benutzer so handhaben, wie es auf del.icio.us angewandt wird.

