mcpField
A
app-shell

app-shell

github.com/dembrandtデザイン・UI174348 回インストール1 週間前に更新
リポジトリ

app-shell について

複数アプリに共通するシェルの設計ガイドです。デザイナーやプロダクトチーム向けに、組織レベルの操作を担うバーやサイドバーと、入口や画面幅に応じた設計を説明します。

主な機能

  1. 01シェルとアプリ内ナビの分離
  2. 02ランチャーとテナント表示の定義
  3. 03環境とステータスバーの指定
  4. 04サイドバーと折りたたみレールの規則
  5. 05モバイルドロワーの動作指針

活用シーン

  1. 01複数アプリを横断するナビ設計
  2. 02マルチテナント画面の範囲表示
  3. 03業務ツールの状態情報の配置
  4. 04デスクトップのサイドバーをスマホに適応

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/dembrandt/dembrandt-skills --skill app-shell

インストール後、Claude Code で/app-shellを入力して読み込まれたか確認します。

詳細

アプリシェル

シェルとは、ユーザーが画面を移動しても変わらない部分です。画面上部のバーとそこに配置されるもの、そして大規模なツールでは画面下部の帯が該当します。その間にあるものはすべてアプリケーションに属します。シェルは小さなものですが、その見た目以上に重要な役割を担います。すべてのツールのすべての画面で、ユーザーが目にする唯一の部分だからです。

シェルはアプリではなく、サービス群に属します

1社が持つアプリケーションは、1つとは限りません。公開サイト、ショップ、顧客ポータル、社内管理ツール、そして誰も触りたがらないけれど多くの人が頼りにしている古いシステムがあることもあります。ユーザーは勤務中にそれらを行き来します。そのたびに、1つの会社としてのまとまりが保たれるか、崩れるかが決まります。

ルール:トップバーはサービス群全体で共有する備品です。アプリが所有するのはその下のすべてです。 共有バーを自分の見た目に合わせて変更するアプリは、自分に変更する権利のないものに手を加えています。バーの役割は、変わらない唯一の基準点であることです。

ただし、変わらないことと、すべてを備えることは同じではありません。シェルに含まれるものは、この画面でまだ対応されていない役割に応じて減らせます。残すものは同一でなければなりません。位置も、動作も、文言も同じです。数は柔軟に変えられますが、扱い方は変えません。

これにより、チームごとに議論になりがちな階層の問題も解決できます。アプリケーションの上位にあたるものはシェルに、アプリケーションの内部にあたるものはアプリ独自のナビゲーションに配置します。

シェルに配置するもの(アプリの上位)アプリ独自のナビゲーションに配置するもの(アプリ内)
テナント/顧客/組織セクション、モジュール、ページ
地域または市場フィルターとビュー
言語とロケールエンティティレベルのアクション
アイデンティティ、ロール、サインアウト機能の設定
アプリランチャーこのツール内の検索

操作によってサービス群全体の表示内容が変わるなら、それはシェルの操作です。このツールの表示内容が変わるなら、シェルの操作ではありません。

シェルはどこまで小さくできるか

親からのみ移動できるサブアプリに残るサービス群全体の役割は、戻る手段だけです。そのため、シェルを1行にまとめられます。コンテンツと同じ背景に、ラベルとアイコンを1つずつ置くだけで、バーも装飾も必要ありません。シェルが担うその他の情報はすでに上位で提示されているため、繰り返すとノイズになります。

条件となるのは入口の経路であり、ルールはこれだけです。

  • 常に親から入る — 戻る手段があれば十分です。
  • 直接または別の経路から入ることもある — チャットのディープリンク、ブックマーク、メールボタン、別のツールなどから入る場合、戻る手段は参照先がありません。ブラウザーの履歴は階層ではないからです。その場合はホームに戻る手段を用意します。アイコン1つだけでも構いません。

アクションではなく、移動先の名前を使います。 ← Dashboard は履歴と階層が食い違っても正確なままですが、← Back はそうではありません。「戻る」は履歴の概念で、「上へ」は階層の概念です。この2つを混同するシェルは、ユーザーが最も迷っているときにこそ、誤解を招きます。

アプリランチャー

ユーザーが3つを超えるツールにアクセスできる場合、シェルにはランチャーが必要です。トップバーに置かれたアイコン1つで、すべてのツールを開けるようにします。これは、ブックマークフォルダーや2年前に誰かがチャットに貼ったリンクの代わりとなるものです。

  • ユーザーがアクセスできるものをすべて表示し、アクセスできないものは表示しない — 403を返すツールが並ぶランチャーでは、ユーザーはランチャーを信用しなくなります
  • 社内のプロジェクトコード名ではなく、人々が普段使う名前でツールを表示する
  • 新しいコンテキストで開くものには印を付ける — シェルの見た目に合わせられない2006年製のシステムは、ユーザーを驚かせるのではなく、控えめにそのことを示すべきです
  • ユーザーの利用頻度順に並べ、その後はアルファベット順にする — 誰が何を作ったかという組織図順にはしません

テナント、環境、そして色の落とし穴

マルチテナントまたはマルチカスタマーのツールでは、ユーザーが画面上のデータが誰のものかを常に把握できるようにする必要があります。関連する2つの制御ですが、重要な違いがあります。

環境には色を使う価値があります。 本番環境、ステージング環境、ローカルビルドは、見間違えようがないようにする必要があります。取り違えれば、実際のデータに実際の変更を加えてしまうからです。色付きのストリップや色合いを付けたバーが適切であり、シェルの落ち着いた印象を意図的に崩してよい数少ない場面のひとつです。

テナントには色を使いません。 顧客ごとにUI全体に色合いを付けるのは魅力的なアイデアですが、顧客ごとに見た目の異なる製品になり、ブランドを損ない、選んでいない色が顧客の色になった途端にコントラストをひそかに崩します。テナントはテーマではなく、シェル内にラベルとして表示します。名前と、あればアバターまたはイニシャルを表示します。テナントが独自のビジュアルアイデンティティを本当に必要としている場合は、セッションごとに色合いを変えるのではなく、製品レベルで一度決めるホワイトラベルの判断です([[brand-visual-language]])。

誰が選択されていても、シェルにはその内容を明確かつ常に表示し、破壊的な操作では確認画面にも繰り返し表示します([[ui-context-and-scope]])。

ステータスバー

ディスパッチボード、データマネージャー、ユーザーが6時間も使い続けるエディターなどの高機能ツール([[operational-expert-tool-ui]])では、周辺的な状態を表示する画面下部のストリップが役立ちます。ユーザーがわざわざ探しに行かなくても、次の情報を確認できます。

接続と同期の状態 · 環境 · 有効なフィルターと一致するレコード数 · 選択件数 · 最終保存時刻 · ここで重要なキーボード操作のヒント

常時表示するものなので、控えめに保ちます。シェルのほかの部分と同じ小さく落ち着いた文字を使い、アニメーションは付けず、本当に問題がある場合を除いて色も使いません。点滅するステータスバーは、通知の場所を間違えています([[notifications-and-recovery]])。

コンシューマー向け製品では、ほとんど必要ありません。ユーザーが画面下部を確認する習慣がつくほど長くツールを使わないのであれば、このストリップは画面の一行を無駄にするだけです。

サイドバー

単一のアプリケーションにはトップバーがなく、左端のサイドバーだけがシェル全体を担う場合があります。その場合、サイドバーは2つの役割を担います。上の表にある全体レベルの制御と、アプリ独自のセクションです。この2つは見た目で明確に区別する必要があります。セクションは中央に配置し、必要ならスクロールできるようにします。全体レベルの制御は最下部に固定するフッターに配置し、アプリのセクションが増えても、ユーザーがいつも同じ場所で見つけられるようにします。サイドバー全体はビューポートに固定します。長いページはその下でスクロールし、ナビゲーションは画面から消えません。

フッターの項目は役割の順に並べます。 まずスコープ(テナント、場所、顧客など、アプリが「何を」表示するかを決める制御)、次に設定(言語、テーマなど、「どのように」表示するか)、最後にユーザー情報とサインアウトを区切り線で分けます。スコープと設定は異なる判断なので、同じ行に混ぜると不自然です。設定は小さく、高さも必要としないため、同じ行にまとめてもかまいません。

ロゴはサイドバーの最上部に配置します。 展開時にはロックアップを、折りたたみ時にはマークのみを表示し、ブランドが求める余白を確保します。ロゴを小さくする原因はパディングなので、切りのよい数字を選ぶのではなく、クリアスペースを基準にパディングを決めます。

ロゴからホームに移動できるようにします。 サイドバーを使うアプリでは、ロゴがホームに戻る唯一の手段なので、画像ではなくリンクにします。ロゴにフィルターをかけるのではなく、テーマに合わせてアセットを切り替えます。ダークカラーのナビゲーションレール用に作られたロゴは、反転表示に耐えられないことがよくあります。

ユーザー情報は一か所にまとめます。 サイドバーのフッターかページヘッダーのどちらか一方に配置し、両方には置きません。サイドバーだけが常に表示されるクロームであればフッターに配置します。各ページにすでにヘッダーがある場合はページヘッダーに移し、フッターはスコープの表示に使います。

サインインで利用可能になる項目は表示し、ロールで利用可能になる項目は隠します。 サインインすればユーザーがアクセスできる項目は、控えめなマークを付けて表示したままにします。これは招待だからです。ロールによって制限される項目は非表示にします。403を返すリンクがあると、ユーザーはナビゲーション全体を信用しなくなります。

レールへの折りたたみ

アイコンレールに折りたためるサイドバーなら、コンテンツ領域はレール分を除いた広さを取り戻せます。キャンバスツールやテーブルツールでは、作業全体を見渡せるか、スクロールが必要かの違いになります。レールを単に狭くするのではなく、使いやすくするためのルールは4つあります。

  • アイコンだけでラベルの役割を果たせるものを選びます。 レールを折りたたむと、アイコンが唯一の操作の手がかりになるため、装飾ではなく認識しやすさを重視して選びます。汎用的な円はナビゲーション項目になりません。スクリーンリーダー用のテキストとしてラベルを DOM に残し、title ツールチップにも同じラベルを表示します。
  • グループ見出しは縮小せず、非表示にします。 カテゴリ見出しにはアイコンがなく、折りたたみ先もありません。非表示にするのが適切です。「ADM」だけが残るのは適切ではありません。また、視覚的に非表示の見出しは、レールに表示されなくなった構造を読み上げてしまいます。
  • 狭いビューポートでは折りたたんだ状態で始め、その後はユーザーの選択に従います。 タブレット幅のビューポート(約1024px未満)では、レールを既定の状態にするのが適切です。ユーザーが状態を選んだら、その選択をどこでも優先し、セッションをまたいで保持します。再読み込みのたびに勝手に開くサイドバーは、ユーザーの信頼を失います。開いているタブ間でも状態を同期し、2つのウィンドウが互いの設定を上書きしないようにします。
  • トグルは端に配置し、コンテンツ側の操作要素と重ならないようにします。 サイドバーとコンテンツの境界にまたがり、半分がサイドバー、半分がコンテンツにかかるトグルなら、探さなくても見つかります。コンテンツ領域の下端からせり上がるもの(キャンバスの操作要素やフローティングボタンなど)を測り、より高く積み重なる要素の上にトグルを配置します。2つの背景の上に配置されるため、ホバー時は不透明にします。半透明だと両方の背景に色がかぶさってしまいます。
スマートフォンの場合

スマートフォン幅のビューポート(768px未満)では、サイドバーは幅を狭めるのではなく、表示しなくなり、代わりにドロワーを使用します([[modal-and-overlay-patterns]])。ドロワーは同じサイドバーです。ロゴの行、項目、並び順、フッターはすべて同じなので、ユーザーはデバイスが変わっても同じメンタルモデルを保てます([[responsive-paradigms]])。変わるのは開き方です。ホームインジケーターに隠れないよう、セーフエリアのインセット内にある画面下隅のフローティングトリガーから開きます。ドロワーを開くとページにスクリーンを重ねて、body のスクロールをロックし、ナビゲーション時に閉じます。タップ後も開いたままのドロワーでは、ユーザー自身が閉じる操作をしなければなりません。

アクティブ状態は背景の変化と文字の太さで示し、色だけで表現しません([[status-colors-and-errors]])。明るいアプリ内に暗いレールを置くのは問題ありませんし、よくあることです。ただし、コンテンツ領域のサーフェストークンを流用するのではなく、レール独自のサーフェストークン(ベース、浮き上がり、沈み込み)が必要です([[surface-separation]])。

レビューチェックリスト

  • すべてのアプリケーションで、シェルは同じ位置にあり、動作や文言も同じですか?
  • 簡略化されている場合、その理由は特定のアプリの好みではなく、利用経路に基づいていますか?
  • 戻る操作では、「戻る」ではなく、移動先を明示していますか?
  • すべての操作要素は適切な階層にありますか?シェルには全体共通の操作要素、アプリ独自のナビゲーションにはアプリ固有の操作要素が配置されていますか?
  • ランチャーには、このユーザーが実際に開けるツールだけが表示されていますか?
  • 現在のテナントはテーマとして適用するのではなく、ラベルとして明示されていますか?
  • 環境(本番環境/ステージング環境)はひと目でわかりますか?
  • 重いツールでは、ステータスバーに常時表示する状態が示され、かつ控えめに保たれていますか?
  • サイドバーのあるアプリでは、全体共通の操作要素が固定フッターに置かれ、スコープ → 環境設定 → ユーザー情報の順に並んでいますか?
  • ロゴはホームへのリンクになっており、反転させるのではなく、テーマごとに切り替えていますか?
  • アクティブな項目は色だけでなく、背景と文字の太さで示されていますか?
  • レールに折りたたんだとき、すべての項目はアイコンから判別でき、スクリーンリーダー用にラベルも保持されていますか?
  • 折りたたみ設定は再読み込み後もタブ間でも保持され、狭いビューポートでのみ折りたたんだ状態から始まりますか?
  • スマートフォンでは、ドロワーは同じサイドバーになっており、セーフエリアを考慮したトリガーから開き、ナビゲーション時に閉じますか?
  • サインインが必要な項目には控えめな印が表示され、ロールによって制限される項目は表示されませんか?

コメント