Build Service/Navigation

移動先: 案内, 検索

ページ

すべてのページ

  • どのページにも左上にロゴがあります。そのロゴをクリックすれば、front page に戻ります
  • どのページにも検索ボックスがあり、他のプロジェクトに素早くアクセス出来るようになっています
  • どのページにも同じヘッダとフッタがあります(最初のページだけは例外です。そこにはカスタムヘッダがあるかもしれません)
  • ログアウトすると、右上にサインインのボックスが出ます
  • ログインすると、興味深そうな場所(アカウント編集ページのような)へのリンクが右上のサインインのボックスのところに出ます

忘れないで:

  • ユーザはソフトウェアを探すのであって、パッケージを探すわけではありません
  • パッケージとは、ソフトウェアの配布メカニズムのことです
  • ユーザに対しては、あらゆることを可能な限り簡単にすべきです -- 技術的なことを知らない人にも達人にも(その間にいるすべての人たちにも)応えて
  • できるだけどこでも、何かをするのに必要なクリック数を最小化してください

Front Page

ログアウト

  • 'Sign in' ボックス
  • 説明文
  • front page に載せる情報についての案:
    • 人気プロジェクト(過去何日/週/月で得票数の多いもの)
    • 最近更新されたプロジェクト(新しいビルド)
    • 人気のあるタグ(日間/週間/月間)
  • カテゴリ表示
  • 検索ボックス

ログイン

ログアウトのページと同じですが、サインインと説明文はありません。またログイン中は以下のものが加わります:

  • そのユーザが書き込み権限を持っているプロジェクトへのリンク("My Projects")
  • アカウント情報
  • システムや他のユーザからの通知

また、以下のものへのリンクも考えています:

  • 最近訪れたプロジェクト
  • ユーザが上位にランクさせたプロジェクト
  • ユーザが最近コメントを加えたプロジェクト

プロジェクト・ページ

ヘッダの下(プロジェクト・ページのタイトルの上)にツリースタイルのブレッドクラム・ナビゲーションがあります

例えば以下のような:: Build Service > Projects > Games > SuperTux

テキスト入力エリア(タイトル、説明等)の編集は flickr のタイトルや説明の編集と同様であるべきです

パッケージ・ページ

パッケージ・ページはプロジェクト・ページに属するサブページのように扱われるべきです。ユーザが「ビルドシステムの別な部分に移動してしまった」と感じるようではいけません。パッケージ・ページにいることは、ユーザがあたかも「自分はまだ特定のプロジェクト・ページにいて、ただそのプロジェクトの一部を編集しているだけだ」と思わせるものであるべきです。 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.


ブラウジング

ブラウジングのためには、ユーザが数千ものプロジェクトの中から自分が探しているプロジェクトを絞り込めるよう、カテゴリとタグ(キーワード)の合わさったものを使いたいと思います


カテゴリ

どのプロジェクトも含まれるような 5 - 10 のカテゴリがあるべきです(6 くらいが最適ですが、以下にサンプルを示すように、もっと必要でしょう)。プロジェクトはただ一つのカテゴリにのみ属します

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

カテゴリを生み出すためにTo seed the categories、我々はプロジェクトのパッケージ・カテゴリを我々のプロジェクト・カテゴリにマッピングしたいと思うかもしれません。これは、ほとんどのプロジェクトを我々のカテゴリに分類するかなり正確で迅速な方法を可能にします


タグ/キーワード

どのプロジェクトも複数のキーワードを持ちます。理論的には、タグの数は 0 から無限までありえますが、最大でも 20 か 30 にとどめたいと思うでしょう

「適切なキーワードのみをプロジェクトに与え、(できるだけ)すでに使われているキーワードを使うようにする」というポリシーを述べておくべきでしょう。一般的なキーワードを与えるのも勿論よいことです

第一タグは RPM カテゴリから引っ張ってくることができます(RPM カテゴリの階層は複数のキーワードに分割されるでしょう)。同様に、カテゴリ・キーワードはプロジェクトのパッケージの .desktop ファイルから引っ張ってくることができます。

プロジェクトごとのタグはログインした人が編集できるようにすべきです

また、タグは重みづけされているべきです。プロジェクト・ブラウザの上の方に表示されるよう、X、KDE、GNOME などのようなタグはより重く(より重要に)したいと思うでしょう

ログインしたユーザがタグをつける際には、del.icio.us の投稿ページのようにタグの割り当てを扱うべきです We should handle tag assignment like the del.icio.us posting page when a logged in user is attaching tags.