デスクトップアプリケーションのUIパターン - ウインドウ編
この記事は、2023年7月8日に開催されたmacOSネイティブアプリケーション開発技術を主題としたイベント macOS native Symposium #09 での同名講演が元になっています。講演時のスライドをベースにテキスト解説を書き下ろし、講演では触れなかった解説も追加しています。
Macらしいソフトウェアを形作るには、開発者によるUIパターンの理解が大切です。ひとえにUIパターンと言ってもさまざまなものがありますが、今回はUIパターンのうち“ウインドウ”に着目し、よく用いられるレイアウトや振る舞い方の解説を簡単に行いました。
今回のテーマはMacにおけるデスクトップUIのデザインに関するものですが、他のプラットフォームやiOSなどのモバイルUIにも通ずる考え方が多くあります。そもそも、モバイルUIは基本的にデスクトップUIから派生して作られているので、元来多くのコンセプトを共有しています。昨今のソフトウェアのビジネスはモバイルファーストが主流になっていますが、UIのデザインは依然としてデスクトップファーストで考えていくことで、正しい構造とインタラクションを備えたUIというものをフォームファクタ問わず構築しやすくなります。
元になった講演のスライドはSpeaker Deckで無料公開しています。講演ではvisionOSなどベータ版ソフトウェアの情報を一部扱っていたため、公開版では削除しています。
・・・
パターンが“らしさ”を形作る
ソフトウェアを設計する際には、そのプラットフォームが持つ「らしさ」を踏襲することが大切です。人間が直接扱うソフトウェア（＝アプリケーション）の場合、その人にとってのソフトウェアとはそこに備わるUIから見えるものが全てですから、UIを丁寧に作り込むことによってプラットフォームの「らしさ」を表現します。
プラットフォームの「らしさ」とは言い換えると一貫したルックアンドフィールのことです。あなたが開発しているアプリケーションと既存のアプリケーションとが同時に並んだ際に、それぞれのルックアンドフィールに違和感がないようにすることをまず目指しましょう。これらをユーザから見たときに、互いに似たような見た目をしていればきっと同じ意味や振る舞いがあるのだと予測できますし、同じ操作方法なら同じ機能結果を期待することができます。一貫性のある操作方法であるならばその使い方を一から再学習する必要もなくなり、使いやすいUIに仕立てることができます。
ここでHIGのmacOSページを開いてみると、同様のことがはっきりと簡潔に書かれています。
macOS向けのアプリやゲームをデザインするときは、まずデバイスの基本的な特徴やmacOSならではの操作パターンを理解することから始めてください。この特徴やパターンを参考にしてデザインを決定することで、Macユーザに喜ばれるアプリやゲームを提供できます。
HIGは2023年6月のWWDC23に合わせて公式に日本語版が提供されるようになったため、我々日本語話者でもガイダンスを読み解きやすくなりました。今までは英語だからと読まない言い訳もできましたが、今は日本語ネイティブでAppleプラットフォームのデザイン言語とガイダンスに直接触れられる環境があるので、macOSでもiOSでも開発に携わる方はまずはHIGを開いてみることをお勧めします。
ただし、HIGには直接書かれていないデザインのコンセプトや考え方というものもあります。今回私が紹介する事柄はHIGにはない話題を多く含みますが、実際のUIの様子から読み解いたものであるので基本的には間違っていないはずです。講演では時間枠の制約もあったため特に「ウインドウ」に着目し、Macらしさを形作るいくつかのパターンを紹介しました。この記事でも同様にウインドウのデザインパターンに触れ、追加で関連する分野の解説も試みます。
オーバーラッピングウインドウの基本
オーバーラッピングウインドウとは、複数の平面状のウインドウが重なり合いつつ、ユーザの操作によって自由に前後に入れ替えすることができる構造です。オーバーラップウインドウ方式などとも呼ぶことがあります。要するに我々が普段使っているMacやPCのマルチウインドウ表示方式のことですね。これは新しい概念ではなく、Macよりも古い時代のXerox Altoの系譜で発明されました。この開発に携わったAlan Kay氏は、オーバーラッピングウインドウについて、著書で次のように語っています。
「ウィンドウを利用するときの直観的な方法は、マウスをそのウィンドウに入れて、ウィンドウを“上”にしてウィンドウをアクティブにすることである。」
「アクティブなウィンドウはモードを構成している。しかし、何かをするときには停止せずに隣のウィンドウに移ることができる。これが私にとってモードレスたる由縁なのである。 」
仕組みをおさらいしてみましょう。
デスクトップにウインドウが3枚展開されている状態で、それぞれが一部重なって表示されているとします。そのうち一番手前のウインドウはアクティブです。
ここでマウスポインタで後ろ側にあるウインドウをクリックすると、そのウインドウが手前（Alan Kayが言うところの“上”）に移動してきます。クリックしたウインドウはアクティブ状態になります。
当たり前すぎて今更目新しさも不思議さも感じられない、ごくありふれた振る舞いですが、これこそがオーバーラッピングウインドウの真髄です。Alan Kayの言葉を再び振り返ってみましょう。
「アクティブなウィンドウはモードを構成している。しかし、何かをするときには停止せずに隣のウィンドウに移ることができる。これが私にとってモードレスたる由縁なのである。 」
アクティブなウィンドウはモードを構成しているという点は当時のシステムの動作環境をいくらか考慮する必要もありそうですが、マルチタスクで複数の処理が駆動できる現在のシステムにおいても、概ね変わらない考え方だと思います。一つだけがアクティブになれるということは、何かしらの作業モードがウインドウUIの中に生じていると考えることもできそうです。要するにモーダルとモードレスを区別することになるのですが、Alan Kayは「オーバーラップされたウインドウはモードを構成しているが、作業を停止せずにウインドウ間を移動できるため、これは私にとってモードレスだ」と言っています。どういうことでしょうか。
仮にアクティブウインドウの切り替え動作が「モーダル」だった場合の振る舞いを見てみましょう。
同様に複数のウインドウが重なった状態で、後ろ側の非アクティブウインドウをクリックして手前に移動させようとしてみます。このときに、現在アクティブである手前側のウインドウが切り替え処理に割り込んできて、ウインドウの切り替えをしても良いか問いかけるダイアログを提示してきたらどうでしょうか。ユーザはいちいちダイアログの問いかけに回答しないといけなくなります。ウインドウのアクティブ状態というものが完全にモーダルに振る舞ってしまうと、柔軟なウインドウの切り替え操作が非常に面倒になり、ユーザビリティが損なわれます。言い換えると、ユーザが常にウインドウのモードを強く意識して、モード切り替えのための操作を余儀なくされるということでもあります。
フルスクリーンなど一部の特殊な状態のウインドウであればこのようなモーダルな振る舞いもうまく機能することもあるのですが、普段使いしていて毎回このダイアログが現れるようなら、これは非常に面倒くさく、使いづらいインターフェイスになっていたと思います。
何かをするときには、作業を停止せずに他のウインドウに移ることができる。オーバーラッピングウインドウ方式には、アクティブ状態というものがあるのである意味ではモードを構成しているのだけれども、ユーザが大きく認識するほどにはモーダルに振る舞っていないので、実質的にモードレスのようにも感じられるというのがこの仕組みの核心です。
macOSはオーバーラッピングウインドウ方式を採用しており、モバイルと違って複数のウインドウをデスクトップに同時に展開でき、1クリックで簡単に行き来できるようにデザインされています。さまざまなコンテンツを複数同時に展開できて、切り替えを遮るものはありません。この仕組みのおかげでMacはモバイル環境よりも生産的に制作活動を行えるようになっているのですね。iPhoneだと、ウインドウ＝appを切り替えるために一度ホームに移動したり、スワイプ機能を使って表示を切り替える動作が必要です。同時に複数のウインドウ＝appを並べることも基本的にはできません。ここが大きな違いです。
ウインドウのレイアウトパターン - 基本
分割レイアウトの基本
レイアウトパターンに話題を移しましょう。macOSらしいインターフェイスはウインドウのレイアウトでも表現することができます。レイアウトはコンポーネント一つで実装できるものでもないため、どういったデザインの型があるのかを把握することが「らしさ」を目指す近道となります。
これから複数のパターン例を示していきますが、まずはベースとして次のようなプレーンな1枚のウインドウがあることを想定してみましょう。
基本的には、ウインドウの内側領域を区切り線で分割して、それぞれの領域に役割を与えていく方針を取ります。Split Viewと呼ばれるコンポーネントを使用します。
仮にこのウインドウを左右に分割したときに、それぞれの領域をMain / Detailと役割付けします。横分割の場合は、左側がMainで、右側がDetailです。その逆になることはほとんどありません。また、区切られた領域のことをPane（ペイン）と呼びます。
（Main / Detailというラベル付は、筆者が解説用に便宜的に行ったものです。）
Paneというのは窓の一区画に相当する部分を指す英単語です。GUIのウインドウも“窓”ですから、同じメタファ由来のPaneという言葉を引用しているわけですね。例えば三分割されたウインドウレイアウトパターンを「3-pane layout」などと呼ぶこともあります。
Main + Detail（ヨコ）パターンのPaneの役割を見ると、Main側が概要情報を扱う領域で、Detail側が詳細情報を扱う領域と考えることができます。横分割では情報が左から右に展開します。
上下分割の場合も同様に考えることができます。上下レイアウトの場合は基本的に上側がMain（概要）、下側がDetail（詳細）になります。縦分割では情報が上から下に展開します。上下逆の役割になることはほとんどありません。
レイアウトの基本原則
この考え方をレイアウトの基本原則という形にまとめてみます。これまで説明してきた左右・上下の分割と役割の配置、情報の展開方法を踏まえて、次のようなルールでレイアウト設計考えてみると、基本を守りながらも応用が効きやすくなります。
・左にある情報は粗く、右にある情報は細かい
（概要情報を左に置き、詳細情報を右に置く）
・上にある情報は粗く、下にある情報は細かい
（概要情報を上に置き、詳細情報を下に置く）
・グループと子要素の入れ子構造で表す
・グループは粗く、子要素は細かい
※左横書きレイアウトの場合
要するに、基本構造として画面に配置される情報は左上起点で、外側にあるほど解像度が粗く、右下・内側に向かうほど解像度が上がっていくということですね。そのレイアウトの中でさらにいくつかのグループが構成されて、グループ同士も入れ子になっていたりします。情報を平面と奥行き（入れ子の軸）の立体構造で捉えながら、うまく2D平面に落としていくような具合です。
このことは知っている人からすると今更当たり前のことだとは思いますが、これを意識するとUI構造の意味を読み解きやすくなりますし、自らUIを設計する場合にも原理原則を念頭においた形を作れるようになるので、覚えておいて損はないと思います。また、この後の解説もこの基本原則を意識しながら読むことでより理解しやすくなるかと思います。
なお、これは左横書きレイアウト（横書きを左から右に向かって記述する言語）の場合に適用されるもので、ヘブライ語のような「右から左（RTL）」レイアウトや、日本語の縦書きのような右縦書きレイアウトでは事情が変わります。UIでの情報の流れ方は文字の記述方向に依存するため、文字組みが入れ替わったり、複数レイアウトが入り組んだりする場合の考慮も必要になることがあります。今回は左横書きのみを前提に話を進めます。
macOSで特に頻出する、ウインドウの基本部品
まず言葉の解説を挟みます。この後の説明でも頻出するので覚えておくと良いでしょう。Paneは先ほど説明したように、ウインドウの中でSplit Viewなどで区切られた領域を指す言葉です。Paneの中でも特にウインドウの左側に縦長に確保され、リストなどの一覧が設置されるパターンがあるのですが、このPaneをSidebarと呼びます。（HIG: サイドバー）
反対側の右側に縦長に確保されるPaneをInspectorと呼ぶことがあります。右側にあるものが常にInspectorであるとは限らないのですが、多くのパターンではInspectorとして設計されることが多いようです。そのほか、Title bar, Toolbarといった部品も頻出します。
Inspectorについて
ここから先は
この記事が気に入ったらサポートをしてみませんか？