We're Crowdfunding on IndieGoGo Back Us

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

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).

設定を避ける

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

"すぐに使える" 体験の構築

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

最小限のドキュメント

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

理解可能なコピーを使う

専門用語をさけ、技術的な知識がほとんど全く無いと仮定してください。これはあなたのアプリを "自己文書化" することを可能にします。

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


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

ユーザーワークフロー

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

初回起動体験

必要な設定

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をインポートしたり、その他アプリのコンテキストの中で有意義なものは何でもできるようにしてください。

アプリをリセット

ユーザーが明示的にアプリを「リセット」した場合 (例: ミュージックライブラリ内のすべての曲を削除するか、メールクライアント内のすべてのメールアカウントを削除することによって)、そのアプリは初回起動時の状態に戻るべきです。

通常の起動

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

スピード

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

自明性

ユーザーがアプリを起動したとき、ユーザーは正確に次に何をすべきかをわかっているべきです。これは、他のインターフェースガイドラインに従うこと (あなたのアプリを他のアプリと確実に一致させること) と最初から明示的なアクションを提供することで達成されます。アプリが、曲やEメールのような "項目" を表示する場合、アプリが開いたときにそれらを表示することでユーザーにそれらの項目を取得させてください。以前に開かれた項目が全くない場合、ようこそ画面を使って、開くや新しい項目の作成(ドキュメントのように)を提供する必要があります。

状態

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

常にアンドゥを提供する

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

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

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


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

常に保存

elementary を使用している場合、ユーザーは自信を感じるはず; ユーザーは、見るものすべてが保存され最新の状態であることを知っているはずです。

elementaryのアプリは常に保存された状態で動作しなければなりません。これは、ユーザーが行った変更は即時に適用されて見えるようになり、ユーザーが手動で物事を保存することはレガシーや特殊な動作であることを意味します。

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

閉じる

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

状態の保存

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

バックグラウンドタスク

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

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

ユーザーがアプリを閉じようとしたときに、ウィンドウを閉じるのではなく単に最小化することは望ましくありません。その代わりに、アプリケーションのウィンドウを "非表示" にする必要があります。バックグラウンドで処理を継続する意味がある場合(ダウンロード/転送、音楽の再生、ターミナルコマンドの実行など)、アプリのバックエンドがそのタスクを継続し、タスクが終了した時に閉じる必要があります。プロセスが完了したことがすぐに明らかではない場合(ファイルのダウンロード/転送やターミナルコマンドを使用した場合と同様)、アプリは、プロセスが完了したことをユーザーに知らせる通知を表示することがあります。ミュージックと同じように、それが明らかである場合には、通知は何も必要ではありません。

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

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


関連項目: 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. 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.

タイトル

タイトルに説明的な単語を含めるべきではありません。 たとえば、Dexterは"Dexter"であり、"Dexter Address Book"ではありません。 Midoriは "Midori Web Browser"ではなく、ただ"Midori"です。 その代わりに、アプリの.desktopファイルのGenericName属性を汎用名に使用し、Comment属性を長めの説明的な語句に使用します。

ジェネリックネーム

アプリが簡単に分類できるまたは一般名で記述できる場合は、アプリの.desktopファイルのGenericName属性に使用するべきです。 "私のアプリは(____)です"と言うことができる場合は、その空白に収まるものが一般名である可能性があります。 たとえば、Mayaはカレンダーなので、その一般名は"カレンダー"です。

アプリの一般名には、冠詞(the, a, an)や"プログラム"、 "アプリ"、 "アプリケーション"という単語を含めないでください。

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

コメント

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

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

カテゴリー

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

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

キーワード

ユーザーが検索でアプリを見つけられるように、ランチャーにキーワードを含めることもできます。これらは "X-GNOME-Keywords"(アプリケーションランチャーの場合)と "X-AppInstall-Keywords"(アプリインストーラの場合)の規約に従います。たとえば、ウェブブラウザには、アプリの名称、ジェネリックネーム、または説明に含めなくても、キーワードとして "Internet" を含めることができます。その結果、 "Internet" を検索しているユーザーはそのアプリを見つけます。ほかの例をいくつか以下に示します。

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


関連項目: 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

コンテナーウィジェット

ウィンドウ

ウィンドウはその上にアプリを構築する基礎です。アプリを閉じる、リサイズなどの内蔵された基本的なアクションを持つキャンバスのようなものを提供します。ユーザーには全てのウィンドウは同じもののようにみえるかもしれませんが、elementary OS にはいくつかの明確なウィンドウの種類があります。利用可能なウィンドウのタイプ、一般的な動作、特定の種類のウィンドウに固有の動作を理解することが重要です。このセクションでは、elementary OS で利用できる、さまざまな種類のウィンドウを取り扱います。ウィンドウは種類ごとに少しずつ異なりますが、それら全てはウィンドウのサブクラスとして考えてください。特に明記しない限り、それらはすべて一般的なウィンドウとして動作します。

ウィンドウタイトル

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

ダイアログ

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

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

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

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

アラートテキスト

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

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

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

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

ボタンの順番

"OK" は "はい" ではない

ダイアログをユーザーに表示するときは、常に"保存..."、"シャットダウン"のように明示的なアクション名を使用してください。"OK"を使用することは、ユーザーが許可しているアクションを理解せずに処理を進めることにつながります。 すべてのユーザーがダイアログに表示されている質問や情報を読んでいるわけではありません。明確なアクション名を使用すると、ユーザーが意図しないアクションを選択しにくくなり、選択する前に表示された情報を読むように促すことにもつながります。

設定ダイアログ

設定ダイアログは、モーダルではなく、一時的にする必要があります。ユーザーが設定ダイアログで変更を加えたときには、その変更は 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 で利用可能なすべてのウィジェットに進む前に、全てのウィジェットに適用されるいくつかの基本なコンセプトをカバーする必要があります。これらのコンセプトを正しく採用することはユーザーによりシームレスな体験を提供します。また、あなたがバグレポートをふるいにかけることを防ぐことを手伝います。

何もしないコントロール

開発者にとって非常によくある間違いは、一見すると何もしないコントロールを作成することです。ユーザーが快適に探索できる環境を提供したいということを忘れないでください。好奇心を持つユーザーは、コントロールがすぐに反応することを期待してコントロールとやり取りします。コントロールが一見何もしないとき、これは混乱を招き、恐怖を覚えさせます("あれ、何が起こったのかわからない!")。場合によっては、何もしないコントロールは単に散らかっているものであり、不必要な複雑さをUIに追加します。

検索フィールドにある"クリア"ボタンを考えてみましょう。このボタンは、関連性があって必要な場合にのみ表示されます。 フィールドが既にクリアされているときにこのボタンをクリックすることは、本質的には何もしません。

感度

いくつかの前提条件が満たされるまで、ユーザーがウィジェットを操作することに意味がないことがあります。例えば、利用可能な進む履歴が無ければ、ブラウザの"進む"ボタンをユーザーがクリックできるようにすることには意味がありません。この場合、"進む"ボタンを反応しないようにするべきです。そうでなければ、ユーザーが結果を期待してクリックして何も起こらなかったときに混乱するでしょう。

通常は、ウィジェットを完全に隠すよりも、ウィジェットを反応しないようにする方が良いです。ウィジェットを反応しないようにすることは、特定の条件が満たされた後にのみ、その機能が使用可能であることをユーザーに教えます。ウィジェット隠すと、その機能がまったく利用できないという印象を与えたり、ユーザーがなぜ機能が突然"消えた"のか不思議に思うことがあります。

隠しウィジェット

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

スペース

整列


関連項目: 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"、"Import 20 Songs" は良いラベルです。

"OK"、"Get more storage!"、"Low Battery"は適切なボタンラベルではありません。 "Get more storage!" ラベルには間違ったキャピタライゼーションと不必要な句読点があります。 他の2つのラベルは、ボタンをクリックした結果として何が起こるかを示していません。

ツールチップ

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

リンクされたボタン

使い方

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

ラベリング

リンクされたボタンは、色付きアイコンを含んではなりません。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

アプリメニュー

アプリメニューはアプリのツールバーの右端に歯車状のアイコンを使用して開かれる、オプションメニューです。伝統的な "ファイル、編集、表示..."メニューバーの代わりに、関連するメニュー項目を提供します。

使い方

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

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

検索フィールド

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

Search と Find の区別

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

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

振る舞い

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

ラベリング

検索フィールドには、何を検索するのかを説明するヒントテキストを含めるべきです。これは、"placeholder_text" プロパティを使って設定できます。

ほとんどの検索フィールドでは、「〇〇の検索」という書式を使うべきです。〇〇には、連絡先、アカウントなどのように検索するものが入ります。

検索フィールドが検索サービスと連携する場合、ヒントテキストは "Google" や "Yahoo" のようなサービス名称とするべきです。

チェックボックスとスイッチ

チェックボックス

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

使い方

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

ラベリング

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

スイッチ

スイッチはユーザーに機能や振る舞いを"オン"または"オフ"で切り替える手段を提供します。

使い方

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

"マイクから録音"オプションは、スイッチのための良い候補であることに注意してください。あなたはこの録音サービスを有効にしたり無効にしたりしています。

しかしながら、2つのオプション"システムサウンドの録音"、"マイクからの録音"がある場合、今度は今度はより大きな録音サービスの一部として含めるための、関連する項目のリストを扱っています(誰がオンなのかオフなのかは、それがどんなサービスを含むかとは無関係です)。この場合、この包含を表現するためにはチェックボックスがより適切です。

ラベリング

可能な場合、あなたが決定しているサービスを直接はっきりと言ってください。ウィジェットが説明している、"マルチタッチを有効にする"や"マルチタッチを無効にする"というような、状態を記述する単語を使わないでください。これは論理的な混乱を招くことがありまます。代わりに、シンプルにその単語を使って"マルチタッチ"と書いてください。


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

ノートブック

ノートブックは、アプリが複数のページの1つを表示できるようにするタイプのウィジェットです(口語では"タブバー"とも呼ばれます)。

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

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

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

ダイナミックノートブックは、一般的にWebブラウザで見られるユーザーが管理できるタブ機能を提供するための方法です。タブは、関連するコンテンツの上側にある独自のタブバー上に、ツールバーに貼り付けられて表示されます。タブは並べ替えたり閉じたりできます。"新しいタブ"ボタンがノートブックウィジェットの左側にあります。

図像

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

形状

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

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

メタファー

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

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

アクションアイコン

アクションアイコンは、"削除"、"再生"、または"保存"といった、一般的なユーザアクションを表すために使用されます。これらのアイコンはたいていはアプリのツールバーで見られますが、OS 全体を通して見ることができます。

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

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

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

アイコンサイズ

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

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

それが見られるであろうサイズで各アイコンをデザインしてください。つまり、1つのアイコンをデザインして残りのサイズはそれをリサイズすることはしないでください。各アイコンがそれぞれデザインされたときに、ベストな結果となります。この考え方("pixel-fitting"と呼ばれます)とその重要性について詳しく知るために、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 ブラウザアイコンフォトアイコンネットワークアイコンカレンダーアイコン

色は意味合いを持っているので、色を選ぶときはこのことを認識してください。例えば、赤は通常エラーや"危険"、オレンジは警告と関連付けられます。しかし、 "行く" のための緑のように、色の意味合いをあなたのアイコンの意味を伝えるために使うことができます。

記号的なアイコン

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

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

記号的 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

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

輪郭とコントラスト

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 設定アイコンにおけるコントラストの例

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

影とハイライト

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%不透明に設定されています。

次に、大きい方を"ブックエンド"するために、2つの小さい長方形を作成します。 最初のものと同じ勾配でそれぞれを塗りつぶしますが、代わりにそれを放射状にします。 放射状の勾配を短辺の中央に配置します。各勾配は最も近い辺に直接出ます(下の例を参照)。 これらの長方形も60%不透明に設定されています。

ピクトグラムの影

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

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

アイコンのマテリアル

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

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

以下は、あなたのアプリのアイコンを作成する際に考慮すべきいくつかの"すること、してはいけないこと"の例です。

テキスト

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) を大文字にします。 タイトル、ボタン、メニュー、および他のほとんどのウィジェットに使用されます。

注意/例外

固有名詞は常に適切に大文字にする必要があります。これは例えば、 Google は常に "Google"、 elementary は常に "elementary"、 MPEG は常に "MPEG" として示されるべきである、ということを意味します。どのように特定の代名詞が公式に大文字で書かれるべきであるかについて確信がないならば、その代名詞のドキュメンテーションを参照してください。

句読点

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

よくある間違いを防ぐ

ハイフンとダッシュ

ハイフン (-)

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

en ダッシュ (–)

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

em ダッシュ (—)

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


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

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

省略記号の使用

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

追加情報

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

短縮されたテキスト

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

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

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


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

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

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

"ページの中を検索..." は、その項目がクリックされたときに実行されるアクションを明確に記述しているため好ましいです。"ソフトウェア・アップデート" は好ましくありません。この項目をクリックするとどうなりますか?どこに連れて行くのでしょう?それは何をしますか?結果がはっきりしません。