前回に引き続き、ユーザーインターフェイス・デザインについて、私たちの「文化」がどのように関わっているのかということを考察してみるというシリーズです。
前編では、私たちが使う言語がどのように書かれて、どのように使われているのかを考察しました。同じ日本語でも、縦書きと横書きで左右が変化することがわかりました。また、外国語、特に東アジアの諸外国での縦書き事情を簡単にではありますが探ってみました。
今回は言語以外の文化事例を見つつ、アプリでの一般例と利き手のユーザビリティを考えるべき場面というものを考察してみたいと思います。
書字方向以外の習慣がユーザーインターフェイスの方向を決めている例
横から見たイラストはどっち向き？
現在Unicodeが検討中のEmoji 11.0では、一部の横向き絵文字に右向きのものを追加しようとしています。思えば、世の中の横向きのイラストは左向きに描かれていることが多いです。実際に新しい絵文字の画像を眺めてみると、左向きの方がなんだか安心する気がします。右向きの水鉄砲は違和感がありませんか？
世の中に右利き人口が多いためか、手に持つものは右手で持って眺めたときの様子で描かれることが多いようです。私は右利きなので左向きの水鉄砲が安心するのですが、左利きの人には右向きの方が安心するのかもしれません。
人の姿も左向きの方が多い気がします。例えば信号機や非常口の人のシンボルは左向きに描かれています。（非常口が向かって右側にある場合にはあえて右向きに描かれることもあります。）
自動車や乗り物に関しては車線の通行が左右どちらにあるかでまた印象が異なるかもしれません。左側通行の日本では、歩行者目線でいうと圧倒的に左向きの車を目にする機会が多いはずです。バスは左側通行前提にインターフェイスが設計されています。右ハンドルは当然のこと、客が乗り降りするための扉が歩道に近い左側にしかついていません。一方で右側通行の外国では車は右向きである方が自然に見えるのかもしれません。（ちょっとここは自信がないです。）
武士の関東巻き・公家の関西巻き
和服の帯の巻き方にも文化の違いが現れるようです。時計回りを「関東巻き」、反時計回りを「関西巻き」と言うそうです。近畿では公家が多く、付き人に帯を巻いてもらうことが多いので、右利きの付き人が巻きやすい方向が定着したという説があるようです。
時計回りの古代ギリシャと仏教・反時計回りのローマ
巻き方の違いを探ってみると、古代ギリシャは時計回りの文化だったようです。第一回目の近代オリンピックの競技場は現在のような反時計回りではなく、時計回りだったのだとか。ただ、反時計回りの方が走りやすいことが発見され、今では反時計回りで走ることになっています。これには諸説ありますが、利き脚が右で軸脚が左になる人が多いことが理由として挙げられるのだとか。
一方で、ローマは反時計回りの文化だったようです。貨幣の刻印、神殿への巡礼の道筋、ローマ市の区分の順序など。
日本では四国八十八箇所のお遍路が時計回りだったりするわけで。参道の階段も左側通行（時計回り）とされています。お寺を表す「卍」も時計回りに見えます。インドでは左手は不浄、右手は浄の手だと言われます。仏教では時計回りがよしとされるのですね。
そういえば、回すだけで超お手軽にお経を唱えて徳を積めるマニ車は、仏教を庶民向けにわかりやすくしたUIと言えるのかもしれません。
なるほど、面白いですねこれは。
この読み物はとても面白かったです。
時計回りの衆議院・反時計回りの参議院
衆参いずれの議院でも、投票の際には議員は東から西に向かって回る（太陽の動きに合わせて回る）そうで、国会の構造上両院が両端に向かい合うように設置されていることから、それぞれの議員は互いに反対向きに回ることになります。第一回帝国議会からの慣例なのだとか。
政治勢力を表す右翼・左翼という言葉は、元々はフランス革命期の国民議会において、議長席から向かって右手に保守派、左手に革新派が陣取ったことに由来します。これも議院の構造に由来する左右の話ですね。
情報展開の原則
そろそろアプリの世界のことを考えてみましょう。
左横書きの言語環境においては、情報は左上から右下へ展開すると考えられます。よく、FやZの字に視線が動くといわれるあれですね。言語の書字方向と情報の配置・展開順序が深く関係しているということです。
わかりやすい実例として、アラビア語／ヘブライ語環境のiOSがあります。アラビア語のように英語とは左右反転している言語では、それを見せる画面全体も左右反転します。ドリルダウンする方向は左だし、戻るボタンは右上についています。飛行機のように方向性のあるアイコンも反転する傾向にありますが、Bluetoothアイコンのようにシンボルとして定まっているものはそのままを保ちます。
iOSの「設定」は情報の展開する流れがUIによく表れています。
縦書きと横書きで変わる情報展開の方向
我々がアラビア語の画面を見ると違和感を覚えますが、彼らにとっては画面上の情報が言語と同じ方向に流れますから、この方がより自然に見えるのでしょう。
このような右から左の流れは日本人には馴染みある現象で、今まで見てきたように日本語には縦組みと横組み両方の文化があります。横組みの本は左開きなので情報が左から右に向かって展開しますが、新聞や漫画、雑誌などの縦組みでは右開きとなるので、情報も右から左に向かって展開します。これは、日本語の書字方向に合わせて本というインターフェイスの形が変化しているということになります。私たちは無意識のうちに、書字方向の違いに合わせて情報の流れる方向が変わることをまく理解しているのです。
空間的な配置と時間的な順序の変換といえば、文字と言語のほかにもこの関係はあてはまります。たとえば、楽譜と音楽、マンガとマンガで描かれているドラマ、絵巻物とそこで描かれるストーリー……（※右図参照）。そういうものの中で一番古いのは、文字と言語の関係。書字方向をひな形にしてそういうものが成り立っていると考えられます。
日本の絵巻物は右から左に進行しますが、西洋で絵巻物にあたるものは左から右に進みます。日本の屏風絵で四季が描かれているものは右から春夏秋冬の順序。ヨーロッパの同趣向の絵では左から。美術の展覧会でも、日本の絵を展示するときは、順路を右からにします。ヨーロッパの絵を展示するときは逆に左から。日本の双六は右から左に進行しますが、西洋の双六にあたるグースゲームでは左から右に進行します。
次の写真は、江戸時代に編纂された日本初の仏和辞典「拂郎察辞範（ふらんすじはん）」の草稿です。日本人の手によって書かれており、縦組みの中に縦書きの日本語と横書きのフランス語が対応するように書かれています。日本語を読むときは正方向、フランス語を読むときは本を左90度傾けて使います。本を傾けて使うという発想はとても面白いです。
当時の日本人には日本語をフランス語に合わせて横組みにするという考え自体が存在しなかったのだと思いますが、それでも書字方向の異なる言語を同時に記述する書き方としてこの方法は理に適っており、この書物では左90度傾けたとしても常に同じ点、右上（傾けた場合は左上）から左下（傾けた場合は右下）に向かって情報が展開し、縦横どちらでもページの進む方向は同じになるようになっています。
日本の漫画は縦組み右開きが前提のレイアウトとなっていますが、これをそのまま海外に輸出すると厄介です。日本式と称してそのまま出版してしまうこともあるようですが、横書き文化の中ではどうしてもコマ割りやページの進行方向が反転してしまうので、完全に左右反転させて綴じ直してから翻訳をかけたり、わざわざコマ割りをやり直して吹き出しの大きさも横書きに調整し直している作品もあります。前編で紹介した韓国版冴えカノの表紙の例のように、左縦書き現象も見られます。
昨今はさまざまな漫画アプリが出てきていますが、そこでは漫画のレイアウトをどうするのかをよく検討する必要がありそうです。紙のレイアウトをそのままPDFないしJPEGにしてページめくりするだけでは本当に良いとは思えません。西洋文明の左横書き文化に支配されたIT世界に、東洋の伝統的な縦組みをどう適用するのか、出版物ではない縦長のディスプレイの中にコマをどう配置するのか、文化の延長で新しいメディアを考えるのはとても面白いことだと思います。
寄生獣のミギーが「ヒダリー」だという話も面白いです。
ユーザーインターフェイスの構造
情報展開の原則に従えば、左横書きでは情報は左から右に流れます。すなわち、左が過去で右が未来、左が親で右が子。あるいは、左が否定で右が肯定です。私たちが普段見ている画面というのは、その法則に従って情報を時間的・空間的に表し、誰もがイメージしやすいようにメタファーを用いて表現しています。
仮に今の画面には映っていない情報だとしても、ユーザーは自身が辿ってきた画面遷移の道筋の記憶から、左の方にはより古い／荒い／親となる情報が並んでいるものと想像することができます。そして実際に戻るボタンに触れることでその情報のあるところまで遡ることができるわけです。この前後／親子関係があるからこそ、ユーザーは「戻るボタンを押した先には一つ上の階層の情報がある」と認識することができています。
これと同様に、右の方にはより新しい／詳細／子となる情報が並んでいるものと想像することができます。
カスケーディングリストは左から右へ流れる情報の階層構造を表しています。実際に、フォルダーをクリックすれば右側にその中身の詳細情報が展開され、その子要素が現れます。インスペクターを持つウインドウであれば右サイドバーにその情報が展開されます。インスペクターが右側にある理由もこの情報の流れに大きく関係しています。
macOS版Pocketの画面を見てみると、ウインドウは横に二分割されています。これはアプリではお馴染みの「マスター詳細パターン（Master-Detail Pattern）」と呼ばれる構造です。場合によっては上下に分割することもありますが、大抵は左サイドバーのコレクションに右コンテンツビューアーという構成になります。このレイアウトでは、情報は左から右に向かって流れます。
Xcodeの画面は基本的に横3ペイン構造で構成されるマスター詳細パターンの発展形です。左から右に向かって情報が展開します。左サイドバーにはプロジェクトファイル一覧（コレクション）、中央にはそのファイルのエディター、右サイドバーはインスペクターとして機能し、選択中オブジェクトの詳細情報を表示します。
Keynoteの画面はXcodeと似ていますがよりシンプルです。基本的には横3ペイン構造ですが、オブジェクトリストを表示するとエディター部分がさらに二分割されます。これはエディターにのみ作用するサイドバーであるので、3ペインのうちエディター内にある2ペインという入れ子構造であると解釈することができます。左サイドバーはスライド一覧、中央がWYSIWYGエディタ、右サイドバーがインスペクターです。
QuickTime Playerではドキュメント（ムービーファイル）が一つのウインドウに展開されます。サイドバーのようなコレクションでは使いません。単一のファイルと単一のウインドウが1:1で対応する、とても原始的なユーザーインターフェイスです。
この場合はインスペクターはメインウインドウからは独立して存在し、モードレスダイアログの形で最前面にあるドキュメントの情報を常に表示するように機能します。（黒いウインドウ）
このようなビューアー系アプリは、ドキュメントファイルとビューアーウインドウが1:1で対応するように設計すると良いでしょう。もしもこれをPocketのような2ペイン構造で扱ってしまうと、単一ウインドウのブラウザとしての性質の方が優先されてしまい、ドキュメント同士をデスクトップに並べて比較するといった使い方ができなくなってしまいます。
QuickTime Playerと似たUIを持つプレビュー.appは、単一ビューアーとしての性質と、2ペイン構造でのブラウザの性質とをうまく使い分けている例です。画像ファイルを同時に複数開いたり、PDFのような複数ページを含むドキュメントを開くと自動的にコレクションとしてまとめてブラウザとして扱ってくれます。
現在と過去がわかり未来が想像できれば、ユーザーは迷わない
iPhoneのドリルダウン構造（ナビゲーションコントローラー）の実態はカスケーディングリストです。macOSのFinderと同様に分割されたカラム構造の連続体をただコンパクトに見せているものになりますので、そこでの振る舞い方もFinderとさほど変わらないでしょう。
Finderのカラム表示では、現在のカラムとその親カラム、そして選択した先の子カラム、計3つのカラムを同時に俯瞰することができます。これにより、現在のカラムを起点として過去・未来の前後関係を時空的に把握することができています。では、iPhoneの場合はどうでしょう？
iPhoneの画面は小さいので、目に映るのは現在のカラムのみです。親カラム（過去）は画面左方にプッシュされてしまっているので、その内容を詳しく再確認するには戻る必要があります。ただし、親カラムを示す「戻る」ボタンが常に左上にいるおかげで、その存在を意識し続けることができています。多くの場合、戻るボタンは前の画面のタイトルが採用されますから、ユーザーは短期記憶に頼りながらでも前の画面がどのようなものであったのかを忘れないまま先に進むことができます。
現在の画面に親の手掛かりである戻るボタンさえ見えていれば、カスケーディングリストの中で迷うことはそうないのだろうと思います。そして、次の画面に続く手掛かりをきちんと現在の画面に用意してあげれば、未来にどのような子が待っているのかも容易に想像することが可能となります。
ユーザーは空間的に記憶する
例えば、次のような多段タブバーは最悪です。ユーザーがいずれかのタブをクリックすると、アクティブになったタブが必ず一番下の段に来るように再配置が行われます。これは、タブのメタファーに寄りすぎたがためにビューとタブを隣接させることを優先したのが原因で、タブの位置が一貫することはほぼ無視されています。
これはユーザーの混乱を招くだけでよろしくありません。タブがビューとくっついていることよりも、タブ自体の並び順とその配置からなる相対的な位置関係こそが最も重要なのです。ユーザーは個々のタブの具体的な名前よりも、ざっくりとした位置関係でそのタブの場所を覚えます。名前なんてどうせすぐに忘れてしまうのであまり意味はありませんが、位置ならなんとなくでも覚えられます。タブが一貫して常に同じ位置にいることが保証されなければなりません。
さらにいうと、タブバーを多段にしなければならないほどにタブを増やすものでもありません。そこまで膨れるようでしたら、タブバーではない別の表現を用いるか、せめて一段にまとめてスクローラルブルにした方がまだ良いというものです。
利き手を考慮する必然性がない限りは、情報展開の原則に従う
情報展開の原則を大前提とするのであれば、前編のはじめに挙げたような思考判断はやはり短絡的だと言えます。
『世の中には右利きの人が多いから、右手の親指が届く範囲にボタンを配置しよう。その方がみんな操作しやすいはずだ。』
大多数が押しやすい押しづらいとか、そういう類の話ではないのです。もちろんその観点は蔑ろにはできませんが、考えるべきレイヤーが異なるというか、操作性を考えるのはその次で良いんじゃないかなあと思うわけです。それに、スマホの場合は右利きの人でも左手で操作するという人もいますから、普通のアプリでは利き手云々議論はあまり意味はないのかもしれません。
情報展開の原則に従えば、否定的な削除ボタンは左側に配置されるべきですが、右利き人口が多いという理由だけでこれを右側に置かれてしまうと、削除の意味が変わってしまうことになるのです。
ダイアログデザインにおけるボタン配置の左右については、以前こちらの記事で解説しました。
利き手に依存してしまったユーザーインターフェイス
世の中の道具で利き手依存性が強いものをいくつか挙げてみましょう。
ネジとネジ回し
ネジは右手に合わせて作られています。右手にネジ回しを握ったとき、時計回りの方が力が入りやすいのでネジを締めやすくなります。
左利きの人にはネジを締めづらいかもしれません。逆にネジを緩めるには左利きの人の方が有利でしょうね。実際に私も右利きでありながら、ネジを緩める際には左手に持ち替えて回します。ペットボトルの蓋もそうですね。
腕時計
腕時計の多くは右利きの人が左腕につけるようにデザインされています。そのため、竜頭は右手で操作しやすいよう右側に付いていることが多いです。左利き向けの腕時計では竜頭が逆向きについています。
Apple Watchは装着する腕や竜頭（Digital Crown）の向きを設定できるので、利き手に最適化することができます。
はさみ
はさみは右利きの人が切りやすいようにデザインされていることが多いです。右利き用のはさみを左手に持つと途端に切りづらくなるのは、二つの刃が離合する方向に力が入ってしまうので、うまく刃が噛み合わないためです。
マウス
ゲーミングマウスの多くは右利き用に作られています。FPSなどで操作性が良くなるように、右手で握りやすい形になっているのです。このようなデバイスは、左利きの人にはとても不便かもしれません。
Macのマウスカーソルが左向きに傾いているのは、マウスを右手で握っていることが前提になっているからです。人間がものを右手に持つと自然と左に向きます。マウスカーソルは手で握ったデバイスの延長にあるものとして、その身体的な現象をわざわざ絵で表現しています。「手のひら」カーソルは一目瞭然ですね。それ故に、左手でのマウス操作時には違和感のあるものとなってしまっています。
利き手属性が重要になるユーザーインターフェイスとは
ゲーム
ビデオゲームのコントローラーやVRでは利き手を考慮した方が良さそうです。バーチャルな腕と武器を操作して戦う類のコンテンツであれば利き手属性が重要になります。操作性を特に重視するFPS系のゲームにはサウスポーモードが用意されていることがあります。
任天堂の「ゼルダの伝説 スカイウォードソード」では、プレイヤーがWiiリモコンを実際の剣のように振って、主人公リンクの腕の動きと同期させながら遊ぶことができました。元々リンクというキャラクターは左利きの設定ではあったのですが、プレイヤーの大多数が右利きであるということで、本作ではあえて右利きに改められたということです。
（ただ個人的には、左利きモードも個別で用意しても良かったのではないかと思います。サウスポーモードとして、あるいは忠実に左利きリンクになりきって遊びたいゼルダファン向けに……。）
利き手に適合するUI
Appleはユーザーの持ち手によってUIが適合する仕組みの特許を取得したらしいです。これはとても面白い仕組みだと思いますが、そのままiPhoneに実装しても情報展開の原則を破るだけになってしまうので、やるとしてもキーボードを自動的に持ち手に寄せるとか、縦スクロールの判定を持ち手に合わせて斜めに傾けるとか、そういった形での調整に利用するのではないでしょうか。
そこで思い出すのが、iOS 11のキーボードです。
iOS 11のキーボードは、地球アイコンから手動設定することで左右いずれかに寄せることができます。画面が大きくなりすぎたことに対する、片手の操作性向上への対策なのだと思いますが、このやり方が良いのかというと正直私はそうは思いません。持ち手に応じて自動的にキーボードが寄るといった動きが理想ではありますが、まだそこまでの機能はiOSには備わっていません。上記の特許が実現化した暁には、よりスマートな実装になっていることを願います。
上下の例もあります。iOSの「簡易アクセス（Reachability）」は、ホームボタンのダブルクリックやホームインジケーターの下スワイプ（iPhone X）により画面全体を下げて上部にある要素をタッチしやすくするための機能です。タッチアクションで操作を確定すると自動的に元の位置に戻るので、これは「一回完結のモード」の一種だと分かります。なので、恒久的に画面が下がって入るわけではなく、キーボードの例とは違いあくまで一時的なものです。
かなり無理やりな方法だと思いますが、なんだかんだこれは便利だったりします。一回完結ですぐにモードから抜けることも、無駄に状態や設定を気にする必要がないので安心です。
まとめ
いくつかの文化や習慣を振り返ってみて、なぜそのように成り立っているのかが少しわかるようになりました。昔の右横書きは実は縦書きであったこと、外国では言語の書字方向が違ったりすること、アラビア語のiOSは左右反転していることなど、文化や習慣によって物事の左右が決定することが改めて理解できました。
このことは、ユーザーインターフェイスにおける左右を決めるにあたって、利き手だけにとどまらず私たちのさまざまな生活習慣や文化背景を考慮することがとても重要だということです。
一般には言語が情報展開の方向を決めることになりますが、仏教や国会議事堂の例があったように、私たちの習慣に基づいた左右というものもデザインに取り入れると良いのかもしれません。また、利き手のユーザービリティがより重視される場面ではそのことに特化しても良いのでしょう。
情報展開の原則
左横書きの言語では、情報は左から右に流れます。すなわち、左側がより古く、荒く、親であり、否定的にもなり得ます。右側がより新しく、詳細で、子であり、肯定的な情報です。左右の空間の配置が時間の流れも同時に表しています。
この原則にさえ従っていれば、ユーザーはナビゲーションの迷路で迷うことはありません。逆に、前の画面に戻るはずなのになぜか右側にプッシュ遷移するような動きにしてしまうと、ユーザーが迷う原因になってしまいます。トランジションの方向と情報の展開する方向を必ず一致させましょう。
レイアウトやナビゲーション設計ではまずはこの情報展開の原則に従いましょう。
情報展開の原則に従って適切なレイアウトを採用する
マスター詳細パターン（Master-Detail Pattern）はレイアウトの最も基本的な構造です。ウインドウを左右または上下に分割し、情報の親子関係を表現します。たいていは親のペインがコレクションを扱うようになっていて、子の一覧が並んでいます。そこで選択されたオブジェクトの詳細情報がもう片方のペインに展開されるというものです。
マスター詳細パターンは複数ペインを持つこともあり、横3ペイン構造や左・上下3ペイン構造などの発展系も存在します。
単一ドキュメントをただ表示するだけの機能で十分であるなら、ドキュメントファイルとビューアーウインドウを1:1の関係性に保ち、よりシンプルな構造にとどめておく事も検討しましょう。過剰な構造化はただUIを複雑にして使い勝手を悪くするだけです。
文化をリスペクトする
まず液晶画面の外側に目を向け、私たちの普段の生活習慣や文化の成り立ちを考えましょう。
古来から続くものがあれば、それを参考にデジタル世界にも適用してみましょう。
言語や地域が変われば文化も変わります。外国人が触れるUIを設計する際にはそのことも考慮に入れましょう。
ルールに従う
左側通行の社会で右側に扉がついているバスを走らせても不便なだけです。ルールに則ったUIを検討しましょう。
例えばiOSやmacOSであればApple Human Interface Guidelines、AndroidであればMaterial Designが参考になるでしょう。
利き手属性が優先される場面を考える
利き手属性がより重要になる場面では、利き手のユーザビリティを考慮しましょう。ゲームのコントローラーや片手操作がより重要になる入力では、UIを利き手に合わせることも検討しましょう。
