メニューバーと向き合ったときに

macOS のメニューバーを操作しているときにふと気づいたことがありました。プルダウンメニューが展開されている間は、他のユーザーインターフェイス要素が操作不可能になるのと同時に、どうやらその時間も停止しているのではないかということです。時間が停止すると何が良いのか、動いてしまうと何が都合が悪いのか。このことは、フォーカスに合わせて時間という属性がどのように感じられるのかについて考えるきっかけとなりました。

Cocoa をかじったことがある方ならわかるかと思いますが、確かに NSMenu と NSTimer を同時に扱う際には、スレッドと実行ループを気にかける必要がありました。でないとメニューを展開している最中にはカレントスレッドのタイマーがブロックされてしまうのです。この仕組みがスレッドとモードを正しく扱うために設計されているのかどうかまでは理解が及んでいませんが、GUI のインタラクションのための仕組みだとしたら大変に興味深いものです。

macOS のメニューのインタラクションを分解する

もう少しメニューのインタラクションに目を向けてみましょう。

  • メニューを展開している間は、注意の所在はメニューそのものにある
  • メニューを展開している間は、メニューのモードにいると考えられる
  • メニュータイトルをクリックするか、長押しし続けることでメニューの展開状態を維持できる
  • メニューの外部をクリックすると、何もせずにメニューが閉じられる（モードのキャンセル）
  • メニューを展開した状態でメニューの外部をクリックしても、その下にあるボタンなどのビューをクリックしたことにはならない
  • メニューのいずれかの項目をクリックすると、特定のコマンドが実行されて、メニューが閉じられる（モードの完了）
  • メニューを閉じると、元いたモードに戻る

メニューはある一定の操作を行っている間のみ展開し、すぐに閉じることができます。このような小規模なモードを短期間のモードとして捉えることができます。短期間のモードには次のようなものがあります。

ばね仕掛けのモード
特定の操作を行っている間のみ有効なモード。スペースキーを押している間のみ有効な手のひらツール、マウスボタンを押しながら行うドラッグ操作などはこれに分類できます。
英語では “Spring-Loaded Mode”、日本語では「ばね式のモード」、あるいは「擬似モード」とも表現されることがあります。

一回完結のモード
一連の操作の間のみに有効なモード。操作が終了するとモードを抜けます。一つの操作を終えてもモードが維持されるという点が〈ばね仕掛けのモード〉とは異なります。クリップボードへのコピー操作などはこれに分類できます。
英語では “One-Off Mode”、日本語では「1回限りのモード」とも表現されることがあります。

ここで『ヒューメイン・インタフェース』を開いてモードの章を読んでみると、Macintosh のメニューは〈擬似モード〉（〈ばね仕掛けのモード〉の表現を変えた言い方）であると説明されていました。
※〈ばね仕掛けのモード〉が〈擬似モード〉に言い換えられている理由はここでは省略します。

“擬似モードの使用によって直ちに解決できた典型的な問題として、Macintosh のプルダウン・メニューで採用した選択肢の表示インタフェースを挙げることができます。この擬似モードの適用例では、メニュー項目の上でグラフィック入力機器のボタンを押すと、ボタンを押し続けている間、そのメニューの選択肢が表示され続けるのです。そしてカーソルをメニュー内の選択したい項目に動かして、そこでボタンを離せばその項目が選択されるわけです。”
引用：ヒューメイン・インタフェース – 3.2 モード


メニュータイトルをクリックしてマウスダウンを保ちながら展開している間は、〈ばね仕掛けのモード〉にいると解釈できる。

ひとつ付け加えなければならないのは、ヒューメイン・インタフェースの著者ジェフ・ラスキン氏が Macintosh 開発に関わっていた当時の Macintosh のメニューは、必ずマウスボタンを指で押し込んでマウスダウン状態を保たないとメニューの展開が維持されない仕様であった、ということです。Mac OS 8からは、そのような “ばね仕掛け式” のインタラクションが残されている一方で、クリックしてすぐに指を離してもメニューの展開が維持され続けられる “Sticky Menus” が加わっています。Windows 95のメニューがそのような仕組みであったのでそれを取り入れたのだと思われます。今時の Mac ユーザーにはこちらの方が馴染み深いかもしれません。このようなインタラクションは “ばね仕掛け式” というよりかは、〈一回完結のモード〉と解釈することができるのかもしれません。

Traditional Mac OS menu behavior demanded that users press and hold on a menu while scrolling and selecting an item. This can be frustrating for many users, so the Mac OS now features sticky menus.
引用：Mac OS 8 Human Interface Guidelines – Sticky Menus; 1997

メニュー展開時における二種類のマウス操作。マウスカーソル周囲に円が表示されている最中はマウスボタンを押下中であることを示す。

動かすべき時間とは

QuickTime Player (macOS)
macOS のメニューの例では、インタラクションの観点から時間が停止するモードについて述べました。メニューの外側にあるウインドウは一時的に操作不能になるというのは、インターフェイス上のフォーカスやモード切り替えをうまく制御するために欠かせない仕組みであるということでした。

一方で、メニューが展開された状態で停止しては困る時間というものも当然考えられます。QuickTime Player でビデオを再生しながらメニューを操作するという場面が思い浮かびますが、このときにビデオが一時停止してしまっては困ります。あるいは、何かの変換処理中にメニューに触れただけでその処理が中断してしまうようなら、それはただ単にシングルタスクのアプリケーションでしかありません。こういうときにはメニューのモードに関わらずバックグラウンドで処理が行われることが望ましいでしょう。macOS では特にデスクトップ・インターフェイスという文脈上、マルチウインドウ、マルチタスク、マルチスレッドで動作することが強く求められます。


iPhone の録画ビデオを再生している最中にメニューバーを操作している様子。メニュー操作によってビデオの再生が一時停止するようなことはない。

ポーズ画面
ネットワーク対戦型ゲームのポーズ画面にもそのような事例がみられます。

任天堂の Splatoon ではそもそもがネットワーク対戦であるという前提があることから、ポーズという概念がありません。その場に居合わせたプレイヤーは同じ時間を同期的に共有しているわけですから、一人のプレイヤーが勝手にポーズしようにもできないようになっているのです。およそ3分間の対戦期間中にポーズのつもりで一時離脱しようものなら、そのイカは敵チームにとって格好の的ととなってしまいます。だから手を抜けないのです。Splatoon は遊びではありません。

これは仕組み上の制約からくる仕様ではありますが、このことが結果としてゲームのリアリティをより高める体験にも繋がっているのではないかと解釈することもできます。

関連記事：任天堂のUI/UXデザイナーが語るデザイン思想。UI Crunch #13 娯楽のUI【書き起こし前編】

Splatoon のほか、FPS 系の本格的なゲームではポーズが効かない作品を見かけることがあります。

ネスト構造の夢

モードと時間の関係については、クリストファー・ノーラン監督の映画『Inception（邦題：インセプション）』に登場する〈夢〉に例えることができます。

インセプションでは、夢に侵入できる機械を使って他人の潜在意識に特定の「アイディア」を植え付けるという物語が展開されます。そこでは、夢に入ってさらに眠ることで夢がネスト状に階層をなし、下位夢で過ごす時間は上位夢（現実）の20倍にもなります。いずれかの層でも死亡すると（夢とはいえ）その人は虚無に堕ちて二度と目覚められなくなってしまいます。目覚め方にも順序があり、必ず眠ったのとは逆順に目覚めなければなりません。階段を降りて地下に潜ったのなら、今度は逆に登っていかなければ外に出られないのと同じです。

このことを iOS のインターフェイスに当てはめてみましょう。
iOS はシングルウインドウの構造であるため、モーダルビューの多くは全画面を覆ってからモード切り替えが起こります。モーダルビューには必ず出口となるアクションが備わっていますから、この一枚一枚のビューを〈夢〉に当てはめると、モーダルビューの出口は夢から目覚めることに例えられます。上位にあるモードもまた同様に出口から脱出する（＝夢から目覚める）必要があります。脱出する順番も重要で、モーダルビューが展開された順とは逆順に脱出しなければなりません。例外的に間のモードをすっ飛ばしてしまうこともありますが、基本的にはモードに入った順とは逆からでなければなりません。

ここまで、インセプションの夢のネスト構造と同じです。
時間についてはどうでしょうか。

ユーザーインターフェイスの設計において、時間という概念を厳密に表すことはそう多くはありませんでした。フロー図、あるいは画面遷移図と呼ばれるような設計図においても、なんとなく暗黙的に左上の方から右下の方に向かってユーザーが体感する時間が流れているのだろうと皆が認識していましたが、厳密にはそれは間違いです。末端から逆行したり、先頭まで遷移するような導線も当然考えられるわけですから、時間を一次元的な線形のフロー図として表すことはできません。

モードについて考えてみると、やはりこれも『インセプション』と同様に、モード（＝夢）ごとに異なる時間軸が存在し、ネスト構造によって依存関係があるものと捉えるとしっくりくるような気がします。多重モードがあったとき、インターフェイスのフォーカスが子モードにあったら、子モードにおける時間は進行し、親モードにおける時間は一時停止します。子モードから脱出すると親モードにフォーカスが移行するので、同時に時間も再開するというわけです。


iOS「写真」アプリケーションで選択モードに入り、さらに共有モードに入って AirDrop を実行し終えるまでのタスクを簡略図で示したもの。

例外もいくつか見られます。例えばアラートビューやアクションシートはモーダルビューの一種ですが、その振る舞いは非同期的です。アラートビューが表示されたからといって、その裏にいるビューの世界が停止することはありません。元々これらのコンポーネントは画面全体を覆うタイプのモーダルビューとは異なった文脈で使われることを想定していますから、コンポーネントごとの特性をよく理解してそれらを適切に使い分けながらデザインすることが求められます。

タスクと時間を図式化するには

例えば、iOS のプッシュ型トランジションによる画面遷移ではタスク1を1ステップ分進行させます。モーダル型トランジションではタスクラインが分岐して新たなタスクが生まれます。タスク2はモードなので必ずタスク1に収束するように示されています。
これらのタスクをシーケンスと捉えると、シンプルに次のように表現することができます。

モード切り替えの際に元のタスクの時間が一時停止することを示す場合は、次のように表現することができます。

さらに厳密にタスク2の出口（結果）が複数ある場合を考慮すると、次のように表現することができます。

なお、マルチタスクな環境ではこのタスクラインが複数同時に走ることになります。iOS ではアプリケーションごと、macOS ではアプリケーションのほか、ウインドウや分割ビューの単位でもこのラインを設計する必要があります。

よく、iOS の戻るボタンによる状態遷移を「作業の破棄」として捉えてしまう開発者を見かけますが、戻る行為は必ずしも否定的とは言えません。ある画面でのユーザーの行動は事実として歴史に刻まれ、画面を戻ろうがその事実をなかったことにすることはできません。ここでは「戻る」と「キャンセル」を区別する必要があり、もしもデータ変更の保存行為をユーザーに意識させるのだとしたら、そこでモードを新たに用意しなければなりません。よくあるパターンは、モーダルビューの右上に「保存」もしくは「完了」、左上に「キャンセル」を設けて、変更の保存と破棄ふたつの出口を用意してあげるという流れです。ここで破棄が行われるとき、モーダルビューの中での時間は『無かったこと』とされ歴史から抹消されます。そしてユーザーは一時停止していた元のタスクに帰還することになります。

ここまで複雑になってくると、いい感じに図で表現するにはいろいろな工夫が必要に思えます。モードによって結果が異なるその条件分岐をどこまで網羅するのかが問われるところです。シンプルかつ明瞭な状態遷移を表すためのソリューションが必要です。さらに言えば、このような曼荼羅を描く行為が設計者にとって難しいようでしたら、そのシステムはユーザーにとっても複雑で難解なものになると言えるのではないでしょうか。ユーザーは短期記憶に保持した少し前の出来事を念頭に今の作業と向き合いますから、条件分岐が増えすぎると直前のことなどすぐに忘れてしまいます。できるだけシンプルに保つことが重要です。

そういったことが、具体的なビジュアル設計に入る前の段階に検出できれば良いのではないかと考えます。設計ツールとして何が最適解であるのか、もう少し探る必要がありそうです。

コブ『考えるんだ、アリアドネ。どうやってここに来た？　君はいま、どこにいる？』
Inception

Share on

usagimaru
ソフトウェアデザイナー、UIアーキテクト、Appleデベロッパー。iPhone 3GSの登場を機にiOSデベロッパーとしての活動を開始。2016年に同肩書きでグッドパッチに入社。その後ソフトウェアデザイナーに転向し、UIデザインにおける情報設計の担い手としてさまざまなクライアントワークに従事。直近はDesignOpsの一員としてデザイン組織を支える傍ら、デザイナーの社内育成やソフトウェアデザインの知識普及、外部に向けてのセミナーやワークショップの提供など、その活動の幅を広げている。