ヒューマンインターフェースガイドライン

These guidelines are designed to help developers and designers create a beautifully consistent experience on the elementary OS desktop. They were written for interface designers, graphic artists and software developers who will be working on elementary OS. They will not only define specific design elements and principles, but will also instill a philosophy that will help you decide when it is appropriate to deviate from the Guidelines. Adhering to the suggestions contained here will provide many benefits:

これらの目標を達成するのを助けるために、ここにあるガイドラインでは、基本的なインターフェース要素とそれらの使い方や効果的なまとめ方、アプリケーションをデスクトップへうまく統合する方法を扱います。覚えておくべき最も重要なことは、ガイドラインに従うことはアプリケーションのデザインを、難しくするのではなく、簡単にするということです。

しかしながら、これは、ルールブックではなく、ガイドラインであるということに留意してください。新しい、驚くべきインタラクションのパラダイムが日々登場し、また、発見されるのを待っています。これは、変更することができる、変更される、生きた文書です。

まだ書かれていないセクションについては、リンクを参照してください。 GNOME ヒューマンインターフェースガイド

デザイン思想

The elementary OS HIG isn't just about a set of concrete rules; it's meant to be flexible and extensible. As such, this very first portion of the guideline is all about the guiding philosophy we employ. For a quick crash course, we like "The User is Drunk":

悪いデザインの例

Before we get into all the things that make up elementary OS apps, there is a clarification that needs to be made. We need to understand what exactly design is about, but more importantly we want to smash two major myths:

  1. デザインとは製品が完成したあとで付け足す何かではありません。 あなたがそれに気づいているかどうかに関わらず、あなたは常にあなたが構築するものをデザインしています。それは何かを作成するための本質的な部分です。デザインは、何かの見えるものだけではありません。ただの色とフォントではありません。デザインとはどのように動作するかです。あなたが何かをするボタンを追加することを決めたとき、それはデザインです。あなたはボタンの追加、そのボタンのアイコンやラベル、そのボタンの場所とサイズや色を決めました。決定はデザインです。

  2. デザインは単なる好みであったり、あなたの意見であったりしません。デザインはテスト可能です。あるデザインは、別のデザインよりも特定の目標をより良く達成します。自転車の種類を考えてみましょう。折りたたみ自転車はマウンテンバイクとは異なる設計目標を持っています。重量、サイズ、タイヤトレッドのようなものは意図したユーザーが目標を達成するうえで重要な要素です。我々はデザインが特定の問題を解決することであること理解しているので、我々が客観的にこれらの問題を解決するために2つのデザインの有効性を比較することができることも理解する必要があります。

  1. Design Is Not Veneer, Aral Balkan
  2. Design is Not Subjective, Jeff Law

簡潔さ

常にあなたのアプリがすぐに理解できるものにするように努めてください。アプリの主な機能は即座にとらえられるようにすべきです。あなたはいくつかの方法でこれを行うことができますが、最善の方法の一つは、簡潔さの原則を守ることです。

機能の肥大化を避ける

たいていの場合、アプリケーションにより多くの機能を追加し続けることは非常に魅力的です。しかし、すべての新しい機能が価値を持っていることを認識することが重要です。具体的には、新しい機能を追加するたびに:

モジュールで考える

Build small, modular apps that communicate well. elementary OS apps avoid feature overlap and make their functions available to other apps either through Contractor or over D-Bus. This both saves you time as a developer (by other apps making their functions available to you), and is a courteous gesture towards other developers (by making your app's functions available to them).

設定を避ける

可能な場合、アプリ内に任意の設定や構成を提示することを徹底的に避けてください。設定を提供することは通常アプリの動作に関するデザインを決定する簡単な方法です。しかし、機能の肥大化の問題と同じように、設定はより多くのコード、より多くのバグ、より多くのテスト、より多くの文書化、および複雑さを意味します。

Build for the "Out of The Box" Experience

Design with sane defaults in mind. elementary OS apps put strong emphasis on the out of the box experience. If your app has to be configured before a user is comfortable using it, they may not take the time to configure it at all and simply use another app instead.

オペレーティングシステムに尋ねる

できる限り自動的に多くの情報を取得してください。ユーザーに自分の名前やその場所を尋ねるかわりに、システムにこの情報を訪ねてください。これは、ユーザーがやらなければならないことの量を削減し、アプリがインテリジェントで統合されているように見せます。

あなたはそれが本当に必要ですか?

設定オプションが本当に必要なのか、ユーザーの理にかなっているか、自問してみてください。エンジニアリングやデザインの意思決定をユーザーに依頼しないでください。

絶対にしなければならない場合

物事の文脈を保ってください。設定ダイアログの中にすべての設定をしまい込むのではなく、その設定事項が影響を与えるオブジェクトの近くにオプションを表示することを考えてください (シャッフルやリピートオプションがミュージックライブラリの近くに表示されるように)。

アプリを使えるようにする前に設定が必要な場合 (メールクライアントなど) 、この設定は ようこそ画面 のようなメインウィンドウの中に出してください。もう一度、これは本当に必要なセットアップであることを確認してください。不必要な設定画面を追加すると、ユーザーがそもそもアプリを開いたときにユーザーがやりたかったことをすることを止めてしまいます。


関連項目:

  1. Checkboxes That Kill Your Product by Alex Limi
  2. Don't Give Your Users Shit Work by Zach Holman
  3. The Wizard Anti-Pattern by Stef Walter

最小限のドキュメント

ほとんどのユーザーは、アプリを使うことができるようになる前に、ヘルプドキュメントを最初から終わりまで読みたくありません。その代わりに、彼らはアプリが支援なしに理解できるよう直感的でシンプルになることを期待しています。

理解可能なコピーを使う

Avoid technical jargon and assume little-to-no technical knowledge. This lets your app be "self-documenting."

不可解なエラーメッセージの代わりに非技術的な説明を提供してください。何かがうまくいかない場合は、何が起こったのかの簡単な説明とそれを修正する方法を提示するべきです。


詳細については、ライティングスタイルを参照してください。

ユーザーワークフロー

目に見えるデザインは、ユーザーエクスペリエンスの大きなパートですが、ユーザーのワークフロー、またはアプリとどのように相互作用するのかも同様です。このセクションでは、一般的なワークフローのいくつかの重要なステップをカバーします:

初回起動体験

必要な設定

When a user first launches an app, they should be able to get down to business as quickly as possible. If configuration is not absolutely required for the first use, they should not be required to configure anything. If configuration is required, they should be presented with a clean and simple welcome screen within the app. Avoid separate configuration dialogs when launching.

起動の速さ

アプリの初回起動は、アプリに対するユーザーの最初の印象となります。それは本当に、そのデザインとスピードを披露するチャンスです。あなたのアプリが目に見えて起動する前に、バックグラウンドで何かを設定する必要がある場合、それは、ユーザーにアプリが遅いか、起動に時間がかかるという印象を与えます。その代わりに、アプリケーションウィンドウを高速に表示することと使える準備をすることに注力し、その後、任意のバックグランドタスクを舞台裏で実行してください。バックグラウンドタスクがブロックする (例. それが完了するまで、ユーザーは特定のタスクを実行することができない) 場合、バックグラウンドプロセスが起こっていることを何かしら表示し、ブロックされたユーザー・インターフェース項目が反応しないようにしてください。(参照: ウィジェットコンセプト)

ユーザーを歓迎

ユーザに表示するコンテンツが無い場合は、シンプルなようこそ画面を使用して、ユーザーが行動可能なアクションを提供してください。ユーザーが、ドキュメントを開いたり、アカウントを追加したり、CDをインポートしたり、その他アプリのコンテキストの中で有意義なものは何でもできるようにしてください。

アプリをリセット

If a user explicitly "resets" the app (ex. by deleting all songs in a music library or removing all mail accounts in a mail client), it should return to its first-launch state.

通常の起動

ユーザーがアプリを起動するとき、ユーザーは明示的なアクションを実行し、高速でしばしば即時応答を期待しています。アプリの起動について3つの主要なエリアに焦点をあてるべきです: スピード、次の何をすべきかの自明性、および状態。

スピード

前にも言ったとおり、スピードは、特にアプリを起動するとき、非常に重要です。ユーザーがアプリを起動することを決めたときからユーザーがそれを使うことを始められる瞬間までの間の遅延はできる限り小さくするべきです。アプリがスプラッシュスクリーンを要する場合、それは間違ったことをやっています。

自明性

When a user launches your app, they should know exactly what to do next. This is achieved by following the other interface guidelines (ensuring your app is consistent with other apps) and by offering up explicit actions from the get go. If the app typically displays "items," such as songs or emails, let the user get at those items by displaying them when the app opens. If there are no previously-opened items, you should offer to open or create a new item (such as a document) by using a welcome screen.

状態

ユーザーが以前にアプリを使用している場合、それを再度開くときにアプリの状態を復元することが一般的には最も良いことです。これは、ユーザーが再び自分の仕事をまた始めることができるように、アプリがユーザーが止めたところに戻ってくることを意味します。ミュージックプレーヤーの場合、これは、ユーザーが止めたところ、アプリを閉じたときに曲を一時停止したところのビューで開くことを意味します。文書エディタの場合、これは、同じドキュメントで同じ場所にスクロールし、ページ上の同じ場所にカーソルがある状態で開くことを意味します。

常にアンドゥを提供する

時々、ユーザーは破壊的または伝統的に取り消しできない可能性があるアクションを実行します。アプリはユーザーに警告を提示するよりも、適切な時間の間は元に戻すことができるようにするべきです。この動作が役に立つときのいくつかの例は:

この振る舞いは、最後の手段のようにだけするべきです。これは、アプリがユーザーに何が起こったかを示してからそのアクションを実行するまでの間のバッファ時間を提供することによって実装されます。すぐに応答するエクスペリエンスを保つため、アプリは、ユーザーがアクションを開始したらそれがすぐに実行されたかのように見える必要があります。

この動作は、ユーザーが意図しないことをしないようにしながら、ユーザーのやり方を邪魔しないように最良のバランスをとります。元に戻す操作を目立たずにシンプルで直感的に保つことが重要です。 そうする一般的な方法は情報バーを使うことですが、他の方法も適切かもしれません。


関連項目: Never Use a Warning When you Mean Undo by Aza Raskin

常に保存

Users should feel confident when using elementary OS; they should know that everything they see is saved and up to date.

Apps in elementary OS should operate around an always-saved state. This means that changes the user makes are instantly applied and visible and that making the user manually save things is a legacy or specialized behavior.

たとえば、曲情報ダイアログはユーザーが保存ボタンを押す必要が無く即時にトラック情報を更新できるようにしなければなりません。ユーザーの環境設定はユーザーが関連するウィジェットを操作したらすぐに適用しなければなりません。アプリを閉じることは再度開くときにユーザーが止めたところに戻ってくることを意味しなければなりません。

閉じる

ユーザーがアプリを閉じるとき、それは一般的にはユーザーがアプリを使い終わりそれを片づけたいからです。

状態の保存

アプリは、閉じるときに、ユーザーが止めたところで再度開くことができるように現在の状態を保存しなければなりません。理想的には、アプリを閉じて再び開くことは、伝統的なアプリの最小化と最小化の解除と区別ができない状態であるべきです。つまり、開かれた文書、スクロール位置、元に戻す履歴を含む、すべての要素が保存されるべきです。

バックグラウンドタスク

ウィンドウが閉じられた後にアプリがバックグラウンドタスクを完了することが理にかなっている場合は、ウィンドウを閉じた後すぐにタスクを完了する必要があります。 アプリがバックグラウンドタスク(メールクライアントなど)を繰り返し実行する場合、バックグラウンドタスクは、開いているアプリケーション自体に依存しない別のデーモンによって処理される必要があります。

アプリのウィンドウを閉じる

It is not desirable for an app window to simply minimize rather than close when the user attempts to close it. Instead, the app window should be "hidden". If it makes sense to continue a process in the background (such as downloading/transferring, playing music, or executing a terminal command) the app backend should continue with the task and close when the task is finished. If it's not immediately apparent that the process has completed (as with the file download/transfer or terminal command), the app may show a notification informing the user that the process has completed. If it is apparent, as with the music, no notification is necessary.

再度、アプリのウィンドウを開く

バックグラウンド・プロセスがまだ実行中にユーザーがアプリを再び開いた場合、アプリはそのウィンドウがずっと開かれていた場合の状態と正確に同じでなければなりません。例えば、ターミナルはすべてのターミナルの出力を表示するべきですし、ミュージックプレーヤーはそれを閉じたときと同じ場所であるべきです。また、ブラウザは、以前のページにに戻ってくるべきです。詳細については、通常の起動にあるアプリの状態の説明を参照してください。


関連項目: That's It, We're Quitting by Matthew Paul Thomas

デスクトップとの統合

An important advantage that developers have when choosing the elementary OS platform is the ability to seamlessly integrate their application with the default desktop. Outlined below are the several ways in which you can make your application feel beyond native in elementary OS. This section will cover things like:

アプリランチャー

あなたのアプリを発見して使う第一の方法は、Slingshot や ドックの中のアプリランチャーです。これらのランチャーを提供するためには、アプリに適切な .desktop ファイルをインストールする必要があります。これには、ランチャーに適切な名前をつける、適切なカテゴリの中におく、アイコンを割り当てるなどを含みます。

.desktop ファイルは freedesktop.org Desktop Entry Specification に従ってください。それらは、/usr/share/applications にインストールする必要があります。ユーザーは、 .desktop ファイルを ~/.local/share/applications の中に置くことで独自のランチャーを作ることがあります。

.desktop ファイルの内容は、この式に従ってください:

Title is a(n) GenericName that lets you Comment.

タイトル

You should not include descriptive words in your title. For example, Dexter is called "Dexter," not "Dexter Address Book." Midori is just "Midori," not "Midori Web Browser." Instead, use the GenericName attribute of your app's .desktop file for a generic name, and the Comment attribute for a longer descriptive phrase.

ジェネリックネーム

If your app is easily categorized or described with a generic name, you should use that for the GenericName attribute in your app's .desktop file. If you can say, "My app is a(n) ____," then whatever fits in that blank could be the generic name. For example, Maya is a calendar, so its generic name is "Calendar."

You should not include articles (the, a, an) or the words "program," "app," or "application" in your app's generic name.

一般名はタイトルケースにする必要があます。そして、システムでアプリの説明やカテゴリを分かりやすくするために使用されます。

コメント

このシステムは、アプリの Comment 属性(.desktopファイルにあります)を利用して、ユーザーにアプリで何ができるのかを簡潔に伝えます。 これは、動詞で始まり、あなたのアプリが扱う主要な名詞を含む短い文または句でなければなりません。 たとえば、適切なコメントは次のとおりです。

アプリのコメントは、句点 (ピリオド、 エクスクラメーションマーク、クエスチョンマーク)は含まない、 センテンスケースである必要があります。また、出来る限り短く、アプリの 主要なユースケースを説明する必要があります。

カテゴリー

次のカテゴリは、アプリの検索や閲覧を支援するために使用されることがあります:

詳細情報については、FreeDesktop.Org menu entry の仕様を参照してください。

キーワード

You may also include keywords in your launcher to help users find your app via search. These follow the convention of "X-GNOME-Keywords" (for in the app launcher) and "X-AppInstall-Keywords" (for in the app installer). For example, web browser might include "Internet" as a keyword even though it's not in the app's name, generic name, or description. As a result, a user searching for "Internet" will find the app. Here are some more examples:

キーワードは、セミコロンで区切られた単一の単語(タイトルケース)である必要があります。


関連項目: Desktop Entry Specification from FreeDesktop.org

Contractor

Contractorは、アプリケーション間で簡単にサービスを公開するためのサービスとプロトコルです。 これにより、アプリはハードコードされたサポートなしで他のアプリやサービスとやりとりできます。 Contractor のサポートを追加するだけで、Contractor に登録されているサービスがすべて使用できるようになります。 あなたのアプリは2種類の方法で Contractor と統合することができます。

Contractor からの結果の表示

Contractor の結果をユーザーに表示する最も一般的な方法は、メニュー形式です。Contractor の結果を表示するときは、次のことを心がけてください。

ドックとの統合

Pantheon のドックと統合することで、アプリはユーザーに一目でそのステータスを伝えることができます。

プログレスバー

プログレスバーは一義的なものにしてください。つまり、一つの、特定のタスクのみで使うということです。例えば、ファイル転送やエンコーディングなどの長さのあるプロセスの進捗を示すのにプログレスバーを使ってください。逆に、複数のアクションが混ざっている時は、プログレスバーを使わないでください。

バッジ

バッジは、あなたのアプリが管理している、アクション可能な項目の数を示します。これは、ユーザーの注意やアクションを必要とする項目があることを目立ちすぎずに知らせることが目的です。これは受動的な通知です。バッジは合計やほとんど変化しないカウンタを表示するべきではありません。ユーザーがあなたのアプリを見たときにバッジが簡単には消えない場合、これはバッジの良い使い方ではない可能性があります。

システムインジケーター

インジケーターは、トップパネルにある小さなアイコンです。さまざまな設定やイベントの迅速な表示のためにユーザに一目見る場所を与えます。アイコンをクリックすると、ユーザが利用可能な関連アクションと小さなメニューが表示されます。

アプリにはインジケーターが必要ですか?

インジケーター領域は、乱雑でデザイン思想に一貫性のない状態に陥りがちです。ユーザーは多くのサードパーティー製アプリをインストールするのですから、インジケーターの数や振る舞いには注意せねばなりません。本当にインジケーターが必要でその利益があるアプリは限られています。次のような場合はインジケーターを使うべきではありません。


関連項目: Farewell to the Notification Area by Matthew Paul Thomas

コンテナーウィジェット

ウィンドウ

Windows form the foundation of your app. They provide a canvas with basic, built-in actions such as "closing" and "resizing". Although users may see windows as being all the same, elementary OS has several distinct window types. It's important to understand the types of windows available to you, window behavior in general, and behavior that is specific to a certain window type. This section will cover the different types of windows available in elementary OS. Although each type of window is a bit different, think of them all as a subclass of a window. Unless otherwise stated, they all behave as an average window.

ウィンドウタイトル

ウィンドウタイトルを扱う場合、その主な用途は、ある1つのウィンドウを他と区別することにあることを考慮してください。良いウィンドウタイトルは、ユーザーの選択を助ける説明を提供します。以下を考慮することを心に留めておいてください:

ダイアログ

24
ダイアログ警告アイコン

基本的な情報と提案を提供するプライマリテキスト

さらに詳細な情報を提供するセカンダリテキスト。アクションのどんな明白でない結果でも説明する情報も含む。

24
キャンセル
アクションの提案

アラートテキスト

アラートは、プライマリーとセカンダリーの両方のテキストを含みます。

プライマリテキストは、状況の概要が含まれており、提案されたアクションを提供します。このテキストは CSS クラスの primary を使用する必要があります。

セカンダリテキストは、状況のより詳細な説明を提供し、利用可能なアクションの副作用の可能性について説明します。ユーザーの判断にはプライマリテキストだけが必要であり、セカンダリテキストはその明確化のために参照するだけであることに注意することが重要です。このテキストはデフォルトのフォントサイズとウェイトを使用して、プライマリテキストの下に1行の高さで配置する必要があります。

プライマリとセカンダリの両方ともテキスト選択可能としてください。これは、Eメールメッセージのような、他のウィンドウのテキストへのコピーと貼り付けをユーザーに容易にします。

ボタンの順番

"OK" is not Okay

When presenting a dialog to a user, always use explicit action names like "Save..." or "Shut Down". Consider how "OK" lets users proceed without understanding the action they are authorizing. Not all users will read the question or information presented to them in a dialog. Using specific action names will make it harder for a user to select an unintended action and may even encourage them to read the presented information before making a selection.

設定ダイアログ

設定ダイアログは、モーダルではなく、一時的にする必要があります。ユーザーが設定ダイアログで変更を加えたときには、その変更は UI にすぐに表示されるべきです。ダイアログがモーダルである場合、ユーザが変更を見るのを妨げる(また、関与するのを妨げる)可能性があります。つまり、ダイアログを閉じてから変更を評価し、ダイアログを再度開く必要があります。ダイアログを一時的にすることで、簡単にアクセスできるようにダイアログを最前面にしたまま、ユーザーは設定ダイアログを閉じたり開いたりすることなく変更を評価したり、変更を元に戻したりすることができます。


関連項目:

  1. Why 'Ok' Buttons In Dialog Boxes Work Best On The Right by UX Movement
  2. Why The Ok Button Is No Longer Okay by UX Movement
  3. Should I use Yes/No or Ok/Cancel on my message box? on UX StackExchange
  4. Where to Place Icons Next to Button Labels by UX Movement

ポップオーバー

ポップオーバーはコンテキストダイアログのようなものです。それは、メニューのように、クリックされたものに関連する一時的なコンテンツを直接表示し、外側をクリックすると閉じます。

メインの UI から抜けずにクイックアクションを実行する場合は、ポップオーバーを使用するべきです。ポップオーバーが使用できる場所の例としては、電子メールから連絡先を追加する、ブラウザにブックマークを追加する、ダウンロードやファイル転送を表示するなどがあります。

シンプルなアイテムのリストだけを表示するときは、ポップオーバーを使うべきではありません。代わりに、メニューを使用してください。同様に、ユーザーが数秒以上を費やす場合は、ポップオーバーを使用しないでください。代わりに、ダイアログを使用してください。ポップオーバーは文脈上のものであり、生成元のUI要素に直接関連する必要があることに注意してください。

ツールバー

ツールバーは、ユーザーにアプリで最もよく使われる機能にすばやくアクセスできるようにするのに便利です。ボタンに加え、ツールバーは最も頻繁に使用されるUI要素の1つです。それは単純なコンテナのように見えるかもしれませんが、使用と構成において一貫性を保つことが重要です。

ツールバーの項目の順番

ツールバーの項目は、左側が最も重要なオブジェクト、右側に重要度が低いもの、アプリメニューは常にツールバーの右端、として構成するべきです。多くのツールバーの項目がある場合、グループに分割し、各グループの間にスペースをいれることが適切です。 RTL 言語で見た場合、ツールバーのレイアウトが反転されることに注意してください。

UIツールキットエレメント

elementary OS uses consistent user interface (UI) elements to bring a unified and predictable experience to users, no matter what app they're using. When used properly, this ensures a small (or nonexistent) learning curve for your app.

ウィジェットのコンセプト

elementary OS で利用可能なすべてのウィジェットに進む前に、全てのウィジェットに適用されるいくつかの基本なコンセプトをカバーする必要があります。これらのコンセプトを正しく採用することはユーザーによりシームレスな体験を提供します。また、あなたがバグレポートをふるいにかけることを防ぐことを手伝います。

何もしないコントロール

A very common mistake for developers to make is creating controls that seemingly do nothing. Keep in mind that we want to present an environment where users feel comfortable exploring. A curious user will interact with a control expecting there to be some immediate reaction. When a control seemingly does nothing, this creates confusion and can be scary (Think,  "uh-oh I don't know what happened!"). In some cases, controls that do nothing are simply clutter and add unnecessary complexity to your UI.

Consider the "clear" button present in search fields. This button only appears when it is relevant and needed. Clicking this button when the field is already clear essentially does nothing. 

感度

Sometimes it doesn't make sense for a user to interact with a widget until some pre-requisite is fulfilled. For example, It doesn't make sense to let a user click a browser's "Forward" button unless there is forward history available. In this case, you should make the "Forward" button insensitive or a user may click it, expecting a result, and be confused when nothing happens.

It's usually better to make a widget insensitive than to hide it altogether. Making a widget insensitive informs the user that the functionality is available, but only after a certain condition is met. Hiding the widget gives the impression that the functionality is not available at all or can leave a user wondering why a feature has suddenly "disappeared".

隠しウィジェット

ウィジェットが特定のコンテキスト(実行されるべきアクションのインジケーターとしてではなく)でのみ意味を持つ場合、ときにはそれを隠すほうが意味があります。例として、ハードウェアの必要条件を取り上げます。システムに単一のディスプレイしかない場合、マルチディスプレイオプションを表示することは意味がありません。マルチディスプレイのオプションを非表示にすることは、実際にはこのシステムで役立つヒントではありません。 このルールのもう一つの例外は、上のクリアボタンの例のように、ユーザーがコンテキスト内でのみ探すウィジェットです。最後に、反応しないようにした項目はスクリーンリーダーやその他の支援技術に認識されますが、隠されたウィジェットは認識されないことに注意してください。

スペース

整列


関連項目: Form Label Proximity: Right Aligned is Easier to Scan by UX Movement

インフォメーションバー

インフォメーションバーは、さまざまな重要度のレベルでコンテキスト情報とアクションをユーザーに対して提供します。

重要度や使用するインフォメーションバーの種類を決定することが重要です。利用可能なインフォメーションバーのタイプは4つあります。

ようこそ画面

ようこそ画面は、ユーザーがアプリを使い始めるのに役立つフレンドリーな方法です。

使い方

一般的に、ようこそ画面はミュージックや Scratch のようにアプリと対話する前にライブラリへのインポートやオブジェクトの作成を必要とするところで使用されます。ユーザーがはじめるための明確な道筋をユーザーに提供し、アプリが有用になる前に彼らが取る必要がある直接的なステップを指し示します。

アプリでユーザーがライブラリを消去できる場合は、空のリストの代わりにようこそ画面に戻るようにしてください。

ラベリング

ようこそ画面は、二組のラベルで構成されています。

図像

各アクションをグループ化するのは、すぐに視覚化するのに役立つアイコンです。ほとんどの場合、これらはアクションアイコンになりますが、場所をインポートまたは設定するときはプレイスアイコンを、設定ユーティリティを開く必要がある場合はアプリアイコンを使用することができます。

ソースリスト

ソースリストは高度なナビゲーションの形式として使用できます。ソースリストは、異なる場所、ブックマーク、カテゴリをアプリ内で表示するのに便利です。

セレクション

ソースリストは、それぞれが独自の見出しを持つ、別々の折り畳み可能なセクションに分けられます。たとえば、ファイルマネージャには、ブックマークされた場所のセクション、コンピュータに接続されたストレージデバイスのセクション、ネットワークの場所のセクションがあります。これらのセクションは、ソースリストの中にある関連項目をグループ化するのに役立ち、ユーザーは自分が使用しないセクションを隠すことができます。

可能な限り、ソースリスト内に拡張可能なセクションを入れ子にしないでください。これをやりたいと思う場合は、セクションを再考する必要があるでしょう。

階層構造

階層構造は、ウィジェット自体の中とより広いアプリの範囲の中の両方で、ソースリストにとって重要です。

ソースリストの中のセクションは、一番上の最も重要なものから一番下の最も重要でないものの順にソートする必要があります。各セクションの相対的な重要性を判断するのに苦労している場合は、ユーザーがどのセクションを頻繁に使用する可能性が高いかを考えてください。このようにセクションを並べ替えると、ソースリストにすべてのアイテムに収まらない場合でも、最も重要な項目は常に表示されますが、もちろんスクロールすることで下にある項目にもアクセスができます。

A source list goes at the left side of a window (or right side for right-to-left languages). Because the user reads in this direction, the sidebar is reinforced as being before (and therefore at a higher level than) the app's contents.

ボタン

Buttons are an incredibly important widget to understand since your app will undoubtedly contain them.

ツールボタン

ラベリング

ツールボタンは、ほとんど常にアイコンだけであり、ボタンの境界線はありません。これらは、ラベルが添付されてはなりません。

ツールチップ

ツールボタンはラベルを含まないため、全てのツールボタンはツールチップが必要です。これは、障害のあるユーザーだけでなく、認識されないアイコンの翻訳を与えることを支援します。ツールチップは、センテンスケースで行う必要があります。

テキストボタンのラベルと同様に、ツールチップはボタンが押されたときに何が起こるかを明確に説明しなければなりません。

テキストボタン

ラベリング

テキストボタンのラベルは、タイトルケースで行う必要があります。

メニュー項目と同様に、テキストボタンラベルは、ステータスではなく、アクションまたは場所で構成されているべきです。ボタンのラベルには、それが押されたときに何が起きるかが明確に記述されていることを確認してください。

"Remove Account", "Transfer to Jim's Laptop", and "Import 20 Songs" are good labels.

"OK", "Get more storage!", and "Low Battery" are not good button labels. The "Get more storage!" label has incorrect capitalization and unnecessary punctuation. The other two labels do not indicate what will happen as a result of clicking the button.

ツールチップ

テキストボタンには明確で明示的なラベルが付いているので、通常はツールチップをつける必要はありません。

リンクされたボタン

使い方

リンクされたボタンは、本質的に類似または相互に排他的である、グループのアクションに使用されます。たとえば、太字、斜体、下線のようなテキストオプションをグループ化できます。または、グリッド、リスト、またはカラム表示のような相互に排他的な状態をグループ化するために使用することができます。

ラベリング

リンクされたボタンは、色付きアイコンを含んではなりません。16px の記号的アイコン、または、テキストのみです。アイコンとテキストを混在させないでください。


  1. Why The OK Button Is No Longer Okay by UX Movement
  2. Should I use Yes/No or Ok/Cancel on my message box? on UX StackExchange

アプリメニュー

The AppMenu is an optional menu which is opened using the gear-shaped icon on the far-right of an app's toolbar. It provides relevant menu items in place of the traditional "File, Edit, View..." menu bar.

使い方

あなたのアプリがこのウィジェットを必要とする場合は最初に検討するべきです。ほとんどのアプリにはあるかもしれませんが、あなたのアプリは必ずしもアプリメニューを必要としないかもしれません。

アプリメニューに項目を追加するときは、次の点を考慮してください:

検索フィールド

コンテンツの検索やフィルタリングをサポートするアプリは、アプリのツールバーの右側に検索フィールドを含めるべきです。これにより、ユーザーにはアプリが検索をサポートしているかどうかを確認するための予測可能な場所と検索をするための一貫した場所をユーザーに提供します。Gtk+ は、この目的のためにGtk.SearchEntryという便利な複合ウィジェットを提供します。

Search と Find の区別

Search は、音楽やビデオなどのライブラリのコンテンツを、一致する項目でフィルタリングするためのものです。Search は通常、ライブラリビューの任意の場所でタイピングされたときに開始されます。

Find は、文字列の一致する部分、つまりテキストエディタ、Webページ、またはターミナルで強調表示するためのものです。これは、キーボードショートカット (Ctrl + F) または 検索アイコンでトリガーされます。Find バーは、ヘッダーバーの下の表示領域の中で、次の検索、前の検索、すべての強調表示などの関連するアクションとともに表示されます。また、表示領域には、置き換えや行への移動などの関連するアクションも含まれます。

振る舞い

アプリ内で検索機能を提供できる場合、そうするのが最善です。任意のリストや複数のデータを、これらのルールに従う1つの検索フィールドを使って検索できるようにするべきです。

ラベリング

Search fields should contain hint text that describes what will be search. You can set this using the entry property "placeholder_text".

Most search fields should use the format "Search OBJECTS" where OBJECTS is something to be searched, like Contacts, Accounts, etc.

If the search field interacts with a search service, the hint text should be the name of that service such as "Google" or "Yahoo!"

Checkboxes & Switches

チェックボックス

チェックボックスはリストから項目を選択する手段を提供します。

使い方

ユーザーが項目を選択するときにチェックボックスを使ってください。 ユーザーがチェックボックスに関連付けられたラベルをクリックすることで、チェックボックスの状態を切り替えることができることを確認してください。

ラベリング

通常、チェックボックスと関連付けられているラベルの文字列は名詞または名詞句であるべきです。

スイッチ

Switches present a way for users to toggle certain features or behaviors "on" or "off".

使い方

リストの一部として関連する項目を含めるためにスイッチを使わないでください。代わりに、チェックボックスを使用します。スイッチは独立したサービスに作用するようなもの、チェックボックスはリストの中にオブジェクトを含めるようなものと考えてください。これは作るための重要な違いです。

Notice that the option "Record from microphone" is a great candidate for a switch. You are enabling and disabling this recording service.

However, if there are two options "Record system sounds" and "Record from microphone" you are now dealing with a list of related items to include as part of a larger recording service (who's on and off state is independent of what services it includes). In this case, a checkbox is more appropriate to denote this inclusion.

ラベリング

When possible, directly call out the service you are acting on. Do not use words that describe the state that the widget is describing like "Enable Multitouch", "Use Multitouch", or "Disable Multitouch". This can create a confusing situation logically. Instead, simply use the noun and write "Multitouch".


関連項目: 3 Ways to Make Checkboxes, Radio Buttons Easier to Click by UX Movement

ノートブック

Notebooks are a type of widget that lets apps show one of multiple pages (also colloquially referenced as "tab bars").

スタティックノートブック

スタティックノートブックは、一般的に環境設定や設定画面で見られる変化しないタブの小さなセットです。タブはコンテンツ領域の上部の中央にリンクボタンとして表示されます。スタティックノートブックは、通常、2から5個のタブが含まれている必要があります。

ダイナミックノートブック

A Dynamic Notebook is a way for an app to provide user-managable tabbing functionality, commonly seen in web browsers. The tabs appear attached to the toolbar on their own tab bar above the relevant content. Tabs are able to be rearranged and closed and a "new tab" button is at the left ot the notebook widget.

図像

図解は elementary OS の重要な一部です。アイコンは、ユーザーが積極的に関わることになるであろうUIの大部分を占めます。アイコンはシステムに命を吹き込み、人間の脳の強力な認知エンジンに応えるものです。

形状

アイコンは、その認識性を高めるために独特の形状/シルエットを持つべきです。この形状は複雑すぎてはいけませんが、いつも丸みを帯びた矩形であってはなりません。

警告ダイアログアイコンチャットアイコンフォトアイコンビデオアイコンオンラインアカウントアイコンターミナルアイコン

メタファー

ハードウェアデバイスまたはファイルの種類 (MIME タイプまたはデバイスアイコン用のものなど) のアイコンを作成しているのであれば、その形状は一般的にはそれと実世界で対応するものを視覚的に表現したものです。例えば、カメラアイコンはカメラを表現したものです。

カメラアイコンハードディスクアイコンマウスアイコンパッケージアイコンHTML テキストアイコンコンピューターアイコン

アクションアイコン

Action icons are used to represent common user actions, such as "delete", "play", or "save". These icons are mostly found in app toolbars, but can be found throughout the OS.

前へアイコン次へアイコンドキュメントエクスポートアイコン印刷アイコン保存アイコン削除アイコンカットアイコン元に戻すアイコン逆アイコン再生アイコン新しいタグアイコンメニューアイコン

もしあなたのアプリがこれらの共通のアクションを使うのであれば、独自のアイコンを作る代わりにそれに対応するアイコンを参照してください。これは、一貫したユーザーエクスペリエンスを保証し、ユーザーが共通機能を認識することを助けます。

もしあなたのアプリに独自のアクションがある場合、あなた独自のものを作る必要があります。その際は、既存のアクションアイコンのルック&フィールに従ってみて、あなたのアプリにそれを加えてください。

アイコンサイズ

elementary OS は 6 つのメインアイコンサイズをOS全体で使います。あなたのアプリケーションの一部として、6つすべてを含めることをお勧めします。

16 ピクセル ターミナルアイコン24 ピクセル ターミナルアイコン32 ピクセル ターミナルアイコン48 ピクセル ターミナルアイコン64 ピクセル ターミナルアイコン128 ピクセル ターミナルアイコン
16 24 32 48 64 128
128 ピクセル ターミナルアイコン
128

Design each icon for the size it's meant to be viewed at. In other words, do not design one icon and resize it to fill the remaining sizes, the best result is when each icon is designed individually. For more information about this practice (called "pixel-fitting") and its importance, we recommend reading Dustin Curtis' article, Pixel-fitting.

カラーパレット

Color, don't be afraid to use it! Many of the elementary OS icons use vibrant colors; it's best to reserve muted tones and greys for boring system icons.

メールアイコンRSSリーダーアイコンWeb ブラウザアイコンフォトアイコンネットワークアイコンカレンダーアイコン

Colors do have their connotations, so be cognisant of this when picking them. For instance: red is usually associated with error or "danger" and orange with warnings. But you can use these color connotations to help convey your icon's meaning, such as green for "go".

記号的なアイコン

記号的なアイコンは共通のシステムアイコン、記号化されたファイル、デバイスやディレクトリ、であり、そしてまた、カット、コピーやセーブのような一般的なアクションを表すために使用されます。

記号的なアイコンは対応するフルカラーのアイコンを縮小した形です。この最小限のデザインは、小さなサイズでも読みやすさと明確さを保証します。

記号的 vs. 色付きアイコン

色付き vs. 記号的なアイコン

フルカラーと記号的なアイコンの用途は交換可能ではなく、それぞれに適切な用途があります。

フルカラーアイコンの最適な用途:

記号的なアイコンの最適な用途:

構造

There are three aspects to note when designing an elementary OS icon:

Composition breakdown of elementary OS Videos icon Composition breakdown of elementary OS Terminal icon

デザイン時にこれらのラインを念頭に置いておくと、各要素をこれらにそって配置することができ、まとめたときにアイコンがより一貫して見えるようになります。たとえば、上のターミナルとビデオアイコンの中で、各要素がミーンラインに対してどのように関連しているかに注目してください。

一般的な寸法

上で見たターミナルのアイコンのような、正方形のアイコンをデザインする場合、各アイコンでこれらの一般的な寸法 (ピクセル) を使用することを検討してください。

キャンバスサイズ ベースライン エックスハイト ミーンラインハイト
16x16 1 14 8
24x24 2 20 12
32x32 2 26 16
48x48 3 40 24
64x64 4 56 32
128x128 9 104 64

例外

ただし例外があります。 多くのアイコン (特に mimetype アイコン) には、アセンダとディセンダの要素、ベースラインとエックスハイトラインを超えて拡張する要素があります。(エックスハイトラインはここでは オレンジ.)

Composition exception example in elementary OS Video icon Composition exception example in elementary OS Terminal icon

一般に、丸い構成要素はそれが長方形の構成要素よりも小さく見える錯視を補償するために、いくらかのオーバーシュートを必要とします。

Outlines & Contrast

All elementary OS icons have a thin outline (stroke) to improve their contrast. The width of this stroke is one pixel for all icons, at every size. The color of the outline is a darker variant (30% darker) of the primary color of the icon. For instance, in the calendar icon below, the green header has a stroke of a darker green.

Example of contrast in elementary OS Calendar icon elementary 設定アイコンにおけるコントラストの例

さらにコントラストを向上させるために、線もまた半透明です。これにより、さまざまな背景に対してアイコンがシャープに表示されるようになります。また、もしその要素が白に近いとき、この線が境界線として機能し、重ね合わせるのではなく、その関連する要素を含めます。この例については、上記のアイコンを参照してください。

Shadows & Highlights

If you picture an icon sitting on a shelf, facing you, with a light source above it, you may see a small fuzzy shadow near the bottom. Also, since the edges of an object tends to reflect more light due to your position relative to it and to the light source, they will have a highlight. Both these effects are something elementary OS icons emulate in their design to lend them a degree of realism.

縁のハイライト

アイコンにエッジ強調効果を適用するため、かすかな、1 ピクセルの、線をハイライトとして内側に描いてください。この輪郭は上部と下部が縁よりも少し明るくなっています。

Edge highlight example in elementary OS Music icon

影を落とす

影を描くためには、長方形を描くことから始めましょう。そして、アイコンの下余白に対して垂直である直線勾配で塗りつぶします。グラデーションは3つの点があり、最初と最後の点の不透明度は0です。この形状全体は、 60%不透明に設定されています。

Next create two smaller rectangles to "bookend" the larger. Fill each with a gradient identical to the first, but make it radial instead. Center the radial gradient in the middle of a short edge with each stop directly out to the nearest edge—see below for an example. Both these rectangles are also set to 60% opacity.

ピクトグラムの影

あなたのアイコンに、以下のアイコンの再生の三角形のようなピクトグラムがある場合は、それがアイコンの背景から目立つようにドロップシャドウを与えることができます。

これをするためには、まずピクトグラムを複製して黒一色とし、それを不透明度 15%に設定してください。次に、それを1ピクセル下に移動し、ピクトグラムの下においてください。この影のコピーを作成し、1ピクセルの線(これも黒)をつけて、この要素を不透明度 7%に調整してください。

アイコンのマテリアル

アイコンに光沢(余分なハイライト)を追加するのは自由ですが、実際の生活の中でより反射する表面(例えば、プラスチック、ガラスなど)を模倣している場合にのみお勧めします。例えば、紙には光沢がないので紙を模倣するアイコンにも光沢はありません。

すること、してはいけないこと

Below are some "do and don't" examples to consider when creating icons for your app.

テキスト

Although elementary OS primarily uses graphics as a means of interaction, text is also widely used for things like button labels, tooltips, menu items, dialog messages, and more. Using text consistently and clearly both in terminology and format is an extremely important part of designing your app and helps add to the overall cohesiveness of the elementary OS platform.

執筆スタイル

理解可能で一貫性がある文章とするために、次のルールに従ってください。

簡潔にする

たくさんの読むテキストをユーザーに与えてはいけません。長い文は手強く見えますし、メッセージを実際に読むことをやめさせてしまうかもしれません。その代わりに、短く簡潔なテキストをユーザに提供してください。

シンプルに考える

ユーザーは賢いが技術者ではないと思ってください。長い、珍しい言葉を避け、一般的な、シンプルな動詞、名詞、形容詞を使うことに力を入れてください。専門用語を使用しないでください。

結論に達する

テキストの先頭に最も重要な情報を入れてください。ユーザーが読むのを止めても、ユーザーは、気に留めておかなければならないことを持っています。

繰り返しを避ける

繰り返しは迷惑になりえますし、メッセージを不必要に長くします。

視覚の階層を使う

視覚の階層は、ユーザーが読むことやテキストを理解することを支援するだけではなく何が最も重要なのかを知ることも支援します。適切に見出しや他のテキストスタイルを使用してください。

言語

While much of elementary OS is developed in English, there are many users who do not know English or prefer their native language. While putting text into your app, keep the following in mind:

キャピタライゼーション

ラベル、ボタン、およびメニューを含むすべてのテキストのユーザーインターフェイス項目は、2つの大文字スタイルの1つを使用する必要があります: センテンスケースまたはタイトルケース。

センテンスケース

センテンスケースは通常の文やフレーズのように大文字にすることを意味します。

文の最初の1文字と固有名詞の最初の1文字を大文字にします。 ラベルや説明テキストに使用されます。

タイトルケース

タイトルケースは本や記事のタイトルのように大文字にすることを意味します。

最初と最後の単語を大文字にします。 すべての名詞、代名詞、形容詞、動詞、副詞、および従属接続詞 (as, because, although) を大文字にします。 タイトル、ボタン、メニュー、および他のほとんどのウィジェットに使用されます。

注意/例外

Proper nouns should always be capitalized properly; this means that, for example, Google should always be shown as "Google," elementary should always be shown as "elementary," and MPEG should always be shown as "MPEG." If you're unsure how a certain pronoun should be officially capitalized, refer to the documentation of the pronoun in question.

句読点

適切なタイポグラフィは、elementary OS 全体で重要です。OS 内での一貫性のためだけではなく、適切な慣例に従い、私たち自身を真面目でプロフェッショナルなプラットフォームとして見せるためです。

よくある間違いを防ぐ

Hyphens & Dashes

ハイフン (-)

コードの中では \u2010 を使ってください。以下のために使用します:

en ダッシュ (–)

コードの中では \u2013 を使ってください。以下のために使用します:

em ダッシュ (—)

コードの中では \u2014 を使ってください。以下のために使用します:


疑問がある場合、Butterwick's Practical Typographyを参照してください。

これらのルールは、英語に適用されます。他の言語は、翻訳者が従うべき独自の規則を有しているかもしれません。

省略記号の使用

省略記号文字 (…) は、主に二つの理由のためにインタフェースで使用されます: 必要な追加情報をユーザーに知らせることとテキストが短縮されたことをユーザーに知らせることです。

追加情報

省略記号は、ユーザーがアクションを実行するにはより多くの情報やさらなるアクションが必要であることを知らせるために使用されるべきです。通常、これはユーザーが意図したアクションを完了する前に、より多くの情報を入力したり選択したりするための新しいウィンドウ、ダイアログ、ツールバーなどのような新しいインターフェイス要素が表示されることを期待するべきであることを意味します。これは重要な違いです。ユーザーは一般的にボタンやメニュー項目に即時のアクションを期待するはずですが、これはそれらに別の動作の準備をするためです。具体的には、省略記号は次のアクションと関連付けられるときに使うべきです。

短縮されたテキスト

三点リーダーは、特定の場所に収まらないテキストを短縮するときに使うべきです。例えば、プレイリストの名前がサイドバーの中で利用可能なスペースより長い場合、それを切り捨てて、それが切り捨てられていることを示すために省略記号を使います。テキストを短くしたときに省略記号を使用するには、2つの方法があります。

自身が無い場合、文字列の最初と末尾はそのまま残した、中央の切り捨てを使うことがベストです。また、切り捨てられたテキストを含むアプリを出荷しないことも重要です。切り捨ては、サイドバーのリサイズやカスタムテキストの入力といったユーザーアクションの結果のみでなければなりません。

省略記号を使用しないとき


3つの連続したピリオド文字 (.) ではなく本物の短縮記号 (…) を必ず使用してください。

メニューアイテムに名前をつける

メニュー項目はアクションや場所の、決して説明ではない、名前を持っている必要があります。メニュー項目が簡潔であることを確認するだけではなく、クリックされたときに実行されるアクションが完全に記述されているかを確認してください。

"Find in Page..." is acceptable as it clearly describes the action that will be performed when the item is clicked. "Software Up to Date" is not acceptable. What happens if I click this item? Where will it take me? What will it do? The outcome is uncertain.