前回に引き続き、ユーザーインターフェイス・デザインについて、私たちの「文化」がどのように関わっているのかということを考察してみるというシリーズです。

UI考：ユーザーインターフェイスと左右の文化 – 前編

前編では、私たちが使う言語がどのように書かれて、どのように使われているのかを考察しました。同じ日本語でも、縦書きと横書きで左右が変化することがわかりました。また、外国語、特に東アジアの諸外国での縦書き事情を簡単にではありますが探ってみました。

今回は言語以外の文化事例を見つつ、アプリでの一般例と利き手のユーザビリティを考えるべき場面というものを考察してみたいと思います。

書字方向以外の習慣がユーザーインターフェイスの方向を決めている例

横から見たイラストはどっち向き？

現在Unicodeが検討中のEmoji 11.0では、一部の横向き絵文字に右向きのものを追加しようとしています。思えば、世の中の横向きのイラストは左向きに描かれていることが多いです。実際に新しい絵文字の画像を眺めてみると、左向きの方がなんだか安心する気がします。右向きの水鉄砲は違和感がありませんか？

世の中に右利き人口が多いためか、手に持つものは右手で持って眺めたときの様子で描かれることが多いようです。私は右利きなので左向きの水鉄砲が安心するのですが、左利きの人には右向きの方が安心するのかもしれません。

人の姿も左向きの方が多い気がします。例えば信号機や非常口の人のシンボルは左向きに描かれています。（非常口が向かって右側にある場合にはあえて右向きに描かれることもあります。）

自動車や乗り物に関しては車線の通行が左右どちらにあるかでまた印象が異なるかもしれません。左側通行の日本では、歩行者目線でいうと圧倒的に左向きの車を目にする機会が多いはずです。バスは左側通行前提にインターフェイスが設計されています。右ハンドルは当然のこと、客が乗り降りするための扉が歩道に近い左側にしかついていません。一方で右側通行の外国では車は右向きである方が自然に見えるのかもしれません。（ちょっとここは自信がないです。）

武士の関東巻き・公家の関西巻き

和服の帯の巻き方にも文化の違いが現れるようです。時計回りを「関東巻き」、反時計回りを「関西巻き」と言うそうです。近畿では公家が多く、付き人に帯を巻いてもらうことが多いので、右利きの付き人が巻きやすい方向が定着したという説があるようです。

こんなに違う！関東と関西の着物好み

時計回りの古代ギリシャと仏教・反時計回りのローマ

巻き方の違いを探ってみると、古代ギリシャは時計回りの文化だったようです。第一回目の近代オリンピックの競技場は現在のような反時計回りではなく、時計回りだったのだとか。ただ、反時計回りの方が走りやすいことが発見され、今では反時計回りで走ることになっています。これには諸説ありますが、利き脚が右で軸脚が左になる人が多いことが理由として挙げられるのだとか。

一方で、ローマは反時計回りの文化だったようです。貨幣の刻印、神殿への巡礼の道筋、ローマ市の区分の順序など。

日本では四国八十八箇所のお遍路が時計回りだったりするわけで。参道の階段も左側通行（時計回り）とされています。お寺を表す「卍」も時計回りに見えます。インドでは左手は不浄、右手は浄の手だと言われます。仏教では時計回りがよしとされるのですね。

そういえば、回すだけで超お手軽にお経を唱えて徳を積めるマニ車は、仏教を庶民向けにわかりやすくしたUIと言えるのかもしれません。

なるほど、面白いですねこれは。

『SPAZIO』 no.63 「時計回りの文化、反時計回りの文化（1）」

この読み物はとても面白かったです。

時計回りの衆議院・反時計回りの参議院

衆参いずれの議院でも、投票の際には議員は東から西に向かって回る（太陽の動きに合わせて回る）そうで、国会の構造上両院が両端に向かい合うように設置されていることから、それぞれの議員は互いに反対向きに回ることになります。第一回帝国議会からの慣例なのだとか。

政治勢力を表す右翼・左翼という言葉は、元々はフランス革命期の国民議会において、議長席から向かって右手に保守派、左手に革新派が陣取ったことに由来します。これも議院の構造に由来する左右の話ですね。

衆議院と参議院では投票が逆回りになる裏事情 : 世間の常識を覆す「裏事情」

情報展開の原則

そろそろアプリの世界のことを考えてみましょう。

左横書きの言語環境においては、情報は左上から右下へ展開すると考えられます。よく、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の画面は小さいので、目に映るのは現在のカラムのみです。親カラム（過去）は画面左方にプッシュされてしまっているので、その内容を詳しく再確認するには戻る必要があります。ただし、親カラムを示す「戻る」ボタンが常に左上にいるおかげで、その存在を意識し続けることができています。多くの場合、戻るボタンは前の画面のタイトルが採用されますから、ユーザーは短期記憶に頼りながらでも前の画面がどのようなものであったのかを忘れないまま先に進むことができます。

現在の画面に親の手掛かりである戻るボタンさえ見えていれば、カスケーディングリストの中で迷うことはそうないのだろうと思います。そして、次の画面に続く手掛かりをきちんと現在の画面に用意してあげれば、未来にどのような子が待っているのかも容易に想像することが可能となります。

ユーザーは空間的に記憶する

例えば、次のような多段タブバーは最悪です。ユーザーがいずれかのタブをクリックすると、アクティブになったタブが必ず一番下の段に来るように再配置が行われます。これは、タブのメタファーに寄りすぎたがためにビューとタブを隣接させることを優先したのが原因で、タブの位置が一貫することはほぼ無視されています。

これはユーザーの混乱を招くだけでよろしくありません。タブがビューとくっついていることよりも、タブ自体の並び順とその配置からなる相対的な位置関係こそが最も重要なのです。ユーザーは個々のタブの具体的な名前よりも、ざっくりとした位置関係でそのタブの場所を覚えます。名前なんてどうせすぐに忘れてしまうのであまり意味はありませんが、位置ならなんとなくでも覚えられます。タブが一貫して常に同じ位置にいることが保証されなければなりません。

さらにいうと、タブバーを多段にしなければならないほどにタブを増やすものでもありません。そこまで膨れるようでしたら、タブバーではない別の表現を用いるか、せめて一段にまとめてスクローラルブルにした方がまだ良いというものです。

利き手を考慮する必然性がない限りは、情報展開の原則に従う

情報展開の原則を大前提とするのであれば、前編のはじめに挙げたような思考判断はやはり短絡的だと言えます。

『世の中には右利きの人が多いから、右手の親指が届く範囲にボタンを配置しよう。その方がみんな操作しやすいはずだ。』

大多数が押しやすい押しづらいとか、そういう類の話ではないのです。もちろんその観点は蔑ろにはできませんが、考えるべきレイヤーが異なるというか、操作性を考えるのはその次で良いんじゃないかなあと思うわけです。それに、スマホの場合は右利きの人でも左手で操作するという人もいますから、普通のアプリでは利き手云々議論はあまり意味はないのかもしれません。

情報展開の原則に従えば、否定的な削除ボタンは左側に配置されるべきですが、右利き人口が多いという理由だけでこれを右側に置かれてしまうと、削除の意味が変わってしまうことになるのです。

ダイアログデザインにおけるボタン配置の左右については、以前こちらの記事で解説しました。

キャンセルのキャンセル問題から考えるダイアログデザイン | Goodpatch Blog

利き手に依存してしまったユーザーインターフェイス

世の中の道具で利き手依存性が強いものをいくつか挙げてみましょう。

ネジとネジ回し

ネジは右手に合わせて作られています。右手にネジ回しを握ったとき、時計回りの方が力が入りやすいのでネジを締めやすくなります。

左利きの人にはネジを締めづらいかもしれません。逆にネジを緩めるには左利きの人の方が有利でしょうね。実際に私も右利きでありながら、ネジを緩める際には左手に持ち替えて回します。ペットボトルの蓋もそうですね。

腕時計

腕時計の多くは右利きの人が左腕につけるようにデザインされています。そのため、竜頭は右手で操作しやすいよう右側に付いていることが多いです。左利き向けの腕時計では竜頭が逆向きについています。

Apple Watchは装着する腕や竜頭（Digital Crown）の向きを設定できるので、利き手に最適化することができます。

はさみ

はさみは右利きの人が切りやすいようにデザインされていることが多いです。右利き用のはさみを左手に持つと途端に切りづらくなるのは、二つの刃が離合する方向に力が入ってしまうので、うまく刃が噛み合わないためです。

マウス

ゲーミングマウスの多くは右利き用に作られています。FPSなどで操作性が良くなるように、右手で握りやすい形になっているのです。このようなデバイスは、左利きの人にはとても不便かもしれません。

Macのマウスカーソルが左向きに傾いているのは、マウスを右手で握っていることが前提になっているからです。人間がものを右手に持つと自然と左に向きます。マウスカーソルは手で握ったデバイスの延長にあるものとして、その身体的な現象をわざわざ絵で表現しています。「手のひら」カーソルは一目瞭然ですね。それ故に、左手でのマウス操作時には違和感のあるものとなってしまっています。

利き手属性が重要になるユーザーインターフェイスとは

ゲーム

ビデオゲームのコントローラーやVRでは利き手を考慮した方が良さそうです。バーチャルな腕と武器を操作して戦う類のコンテンツであれば利き手属性が重要になります。操作性を特に重視するFPS系のゲームにはサウスポーモードが用意されていることがあります。

任天堂の「ゼルダの伝説 スカイウォードソード」では、プレイヤーがWiiリモコンを実際の剣のように振って、主人公リンクの腕の動きと同期させながら遊ぶことができました。元々リンクというキャラクターは左利きの設定ではあったのですが、プレイヤーの大多数が右利きであるということで、本作ではあえて右利きに改められたということです。

（ただ個人的には、左利きモードも個別で用意しても良かったのではないかと思います。サウスポーモードとして、あるいは忠実に左利きリンクになりきって遊びたいゼルダファン向けに……。）

利き手に適合するUI

Appleはユーザーの持ち手によってUIが適合する仕組みの特許を取得したらしいです。これはとても面白い仕組みだと思いますが、そのままiPhoneに実装しても情報展開の原則を破るだけになってしまうので、やるとしてもキーボードを自動的に持ち手に寄せるとか、縦スクロールの判定を持ち手に合わせて斜めに傾けるとか、そういった形での調整に利用するのではないでしょうか。

操作する手に応じて右手用UIと左手用UIを切り替え--AppleのスマホUI特許が公開

そこで思い出すのが、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を利き手に合わせることも検討しましょう。

この記事は、ユーザーインターフェイス・デザインについて、私たちの「文化」がどのように関わっているのかということを考察してみるというものです。具体的な“アプリケーションのUIデザイン”に踏み込む前にまずは日本語の使われ方を観察し、そして海外の文化との比較を簡単に行ってみたいと思います。

はじめに

今までにも私はユーザーインターフェイスにおける左右について考察したことがありました。Mac OSのウインドウについているクローズボタンはなぜ左配置であるのか。デスクトップアイコンはなぜ右配置であるのか。デスクトップの方については若干疑問が残る形となってしまいましたが、メニューバーが左寄せであることと狭い画面サイズが関係していそうであるというところまでは辿り着けたかなと思います。

• Mac OS のクローズボタンはなぜ左配置なのか
• Mac OS のデスクトップアイコンはなぜ右配置なのか

今回は、私たちが使う言語や文化がユーザーインターフェイスにどのような影響を与えているのかという考察をしてみたいと思います。

例えば、次のような思考判断はユーザーインターフェイスのレイアウトを考える上では短絡的だと私は考えます。

『世の中には右利きの人が多いから、右手の親指が届く範囲にボタンを配置しよう。その方がみんな操作しやすいはずだ。』

右利き人口が多いのは事実だし、大多数を取るのであればその判断でも通用するのかもしれません。しかしこのような判断だけで設計を進めてしまうと、ユーザーインターフェイスの本質を見誤ります。左利きを見捨てるべきではないとかそういう話ではありません。

ユーザーインターフェイスの設計では、そこで扱う要素を上下左右のいずれに配置するべきなのかということを検討する必要があります。これにはまず、私たちの文化背景から考えなければなりません。

書字方向

私たちが日常最もよく使う道具の一つが言語です。言語のルールがユーザーインターフェイスにどのような影響を与えているのかを考えてみます。

言語には書字方向という大原則があります。文を記述する方向のことで、これは言語ごとに定まっています。英語をはじめとした西洋の言語は横書きで、文字を左から右に向かって連ねます。改行が起これば一段下げて左端に戻るので、全体としては左上から右下に向かうことになります。このような、左を頭とする横書きの言語を左横書きと呼びます。

縦横が混在する日本語

現代の日本語も英語と同じ左横書きが主流ですが、一方で、伝統的に右を頭とする右縦書き（右上から左下に向かって文字を連ねる）の文化があります。左横書きは近代にかけて日本人が西洋文明と触れて以来徐々に浸透していったものですが、初めのうちは横書きの左右は統一されておらず混乱が見られました。それまで横書きにする習慣がなかったためで、戦中にようやく左横書きに統一されたそうです。

戦後日本で右書きの横文字が左書きに変わった瞬間をさぐってみた

実は日本語の横書き文章は左から右方向で始まっていたのです。

一方で、それに立ちふさがるのは、明治時代以前から看板などで使われていた右書き文字です。店の看板の他、新聞の見出し文字、雑誌の題字なども主にこの形式が取られていました。また、紙幣や硬貨、郵便切手など国が発行する券面の表記も右書きでした。

書籍「日本語大博物館 悪魔の文字と闘った人々」によると、その他にも「鉄道の場合は切符が左横書き、出札口の表示が右、食堂車や寝台車は左、大阪行急行は右という具合で（後略）」、つまり横書き表示の書き順は統一されていなかったのです。

（中略）

横書きが増大していく中、国もこのよろしくない状況に懸念していました。太平洋戦争開戦翌年である1942年（昭和17年）に、文部省（現・文部科学省）主導で左書きへの統一の動きが打ち出されます。

ついこの前の出来事ですね。

なぜ日本語は伝統的に右縦書きなのかというところでは、漢字のルーツである古代中国において、人々は木簡に文字を書いていたことがその理由であるとの説があります。人類の多数は右利きであり右手で筆を持つ、木簡は縦長であり左手に持つ、その結果として書字方向は右縦書きになる。人類の右利き有利と、文字を記述する媒体が縦長であったことの影響だそう。

http://www.osaka-ue.ac.jp/zemi/nishiyama/gihyo/column6.pdf

横書きが主流となった現代においても、縦書きが廃れたわけではありません。読み物としての性質が強い書物、書道や御朱印帖など伝統的なもの、文字が書かれる媒体が縦長で縦書きの方が収まりが良い場合など、横書きが主流だとはいえ日本語ではまだまだ縦書きが用いられます。本の背表紙をわざわざ読みづらい横書きにはしません。街を歩けば縦書きをよく見かけます。ビルの看板や電柱の案内板なども縦書きが多いです。新聞や漫画、小説、雑誌は縦書きです。

一つの言語にこのような縦横混在が可能であるのは、日本が漢字文化圏に属しており元々縦書き文化であったこと、日本語の文字が正方形のマスに収まるようにデザインされているので縦横どちらに並べても機能すること、横書きが入ってきてからも縦組みと横組みを同時に扱うルールをきちんと制定したことなどがその理由として挙げられるのかもしれません。

歴史的な建造物などで見かける右横書きは、一行一文字の右縦書きと解釈するそうです。ただし、約物は方向に合わせて傾けたり反転したりすることもあります。右横書きだと思っていたあれは縦書きだったのですね。

その他、文字が用いられる状況次第ではあえて左右を反転する例も見られます。進行方向から後方に向かって表記する船舶名や自動車での文字表記があります。

#ターャジスあつめ hashtag on Twitter

このように、日頃見かけるさまざまなUIが日本語のルールのもと成り立っていることが改めて理解できました。

外国語の事情

アラビア語やヘブライ語などでは書字方向が右横書きで、英語とは左右が反転しています。モンゴル文字は元々は右横書きでしたが、漢字の影響を受けて左縦書きが行われるようになったそうです。

アラビア語では「？」も左右反転します。

هل تتكلم اللغة الإنجليزية /العربية؟

（あなたは 英語／アラビア語 を話しますか？）

地球ことば村 — 書字方向― 縦書き・横書き からの引用：

モンゴル文字で表記されるモンゴル語は，左から右へと行を進める左縦書きを使用する。これは，モンゴル文字がソグド文字系統のウイグル文字から派生したことに由来する。これらの文字は，もともと右横書きされていたが，漢字の書記体系に影響をうけ，反時計回りに 90 度回転した形の左縦書きとなった。

東アジアの縦書き事情

韓国では縦書きを使うことがほとんど無いそうです。朝鮮半島も伝統的に漢字文化圏で縦書きで書くはずですが、漢字を利用しなくなっていることが縦書き廃れの原因なのかもしれません。その一方で、ロゴや出版物の表紙などに左縦書きを用いることがあるそうです。左横書きの文脈で縦書きしているということなのでしょうか。

韓国語の縦書き | 韓国語のHANA

現在の日常生活で韓国語の縦書きを見る機会はほとんどありませんが、最近、少し変わった韓国語の縦書きが目に入るようになってきました。

例えばTwitterのこのツイートでは、韓国語に翻訳されて出版されたライトノベルの背表紙の写真をアップしています。手前に見えているライトノベルの日本語での原題は『境界線上のホライゾン』、韓国語のタイトルは『경계선상의 호라이즌』。

お気づきですか？
そう、縦書きの方向が左から右に進んでいるのです。

日本では小説やラノベ、漫画は縦書きしますから、フォーマットそのままで海外に持っていくとこのような現象が起こるのですね。

漢字の国・中国でも現代は横書きが主流となっているようです。新聞も小説も基本的には横書きなのだとか。どうやら文化大革命で縦書きが一掃されてしまったらしい。

中国の縦書き、横書き事情 からの引用：

「国語の教科書は縦書き？」

「横書きです」

「新聞は？」

「横書きです。見出しなどに少しだけ縦書きがあるけど、日常的に見る縦書きはこれくらい」

「小説なんかの本は？」

「もちろん横書きです」

「でも書道の時は縦書きやんなぁ」

「そう、書道の時くらいです。昔の漢詩は縦書きです」

「じゃぁ国語の教科書なんかで漢詩が紹介されたりする時は縦書き？」

「いえ横書きです」

もう一つの漢字の国である台湾は、中国本土とは異なる伝統的な繁体字を使っています。こちらでは現代も縦書きがよく使われているようです。香港は英国植民地であった歴史的な経緯から横書き主流となっているという話も聞きますが、今でも縦書きは健在なようです。

台湾の電子書籍をEPUB 3で広げる

縦書きは、いまではもう中国本土にはない、台湾独自の文化です。中国ではかつて「文化大革命」がありましたよね。それ以後、中国語簡体字の書籍は、ほぼ全部が横書きです。また香港も中国語繁体字を使っていますが、イギリスの植民地だったこともあり、やはりほとんどの書籍が横書きです。台湾は中国語圏のなかで、縦書きを維持している、最後の場所になります。

あまり詳しく調べられたわけではありませんが、日本、台湾、香港の漫画は縦書き、中国本土、韓国の漫画は横書きという違いがあるということを少し知ることができました。

長くなったので、後編に続きます。

UI考：ユーザーインターフェイスと左右の文化 – 後編

私の職場ではUIについてのマニアックな談義が行われることがあります。アプリやwebだとかのデザイン会社なので周囲にはUIやUXのプロフェッショナルが集まっていて、『UI談義』の文化が根付いています。

UIを解剖するためのUI談義

UI談義とは、UIオタクで集まってUIのことをひたすら考察し合うだけの集まりです。ここには職種問わず誰でも参加が可能で、UIデザイナーはもちろん、iOSデベロッパー、Androidデベロッパー、PM、マネージャーなどなど、あらゆるタイプの人が集まります。

UI談義のテーマは突如設定されます。普段利用しているアプリのちょっとしたインタラクションが気になったらそこでUI談義が始まります。iOSのアップデートでApple純正アプリのUIが変わったタイミングや、Twitter, Instagramなど有名アプリのアップデートでUIが変わったタイミングが多いです。

『なんかTwitterがモーメントとかいう機能を実装したらしい』

『俺のTwitterにはニュースしか無いんだけど』

『ここの動きめっちゃよくできてる』

『3D Touchちゃんと実装してるなー』

大抵はこのような具合です。Twitterはなぜモーメントを実装したのか、普段縦の動きだけだったところに横の動きで違う視点を云々……、なぜモーダルビューのクローズボタンを左から右に変更したのか、、などさまざまです。

UI談義を通して、普段ユーザーとして利用していると自然すぎて気づかないデザインが見えてきます。

UI談義の始め方

まず、UIオタクを集めます。共通言語が欲しいのでできれば同じプロダクを利用しているユーザーが多くいた方が良いです。集まり方は、実際に席を近づけるでも良いし、Slackにチャンネルを作っても良いです。私の職場のSlackには #ui-dangi チャンネルがあって、そこでUI談義がよく行われています。ただ、うるさくなるのでできれば少人数の方が良かったりもします。

観察と洞察

デザインには必ず意味があります。その意味を言語化することがUI談義の目的です。デザインを言語化できればその真理が見えます。たとえ1pxの余白であってもそれには明確な意味があるはずです。目に見えるものだけでなく、あらゆる要素に意味を見出す、それらを見つけられる洞察力が求められます。

デザインガイドラインを理解しておく

AppleやGoogleなどのプラットフォーマーが定義するデザインガイドラインは、そのプラットフォームのUIの基本的な設計を言語化したものです。ガイドラインとはすなわち設計書です。数値など細かいルールは読み飛ばすとしても、最低限には把握しておくべきでしょう。

よく、『HIGに従うことは必須ではない、自分のデザインで独自性を出すべきだ』と言った声が聞かれますが、設計の通りに動かせないデザインはそもそも実装できません。プラットフォームに適合したデザインでUIを設計するにはどうすれば良いのか、UIを解剖することで学ぶことができます。デザインの本質がわかれば、ときにはプラットフォームの設計に矛盾せずにガイドラインをあえて無視して独自のデザインを構築することもできるはずです。

iOS ヒューマンインターフェースの原則

テーマを決める

テーマは重要です。UIといっても幅が広く、MacユーザーばかりのところにWindowsのUIについての話題をぶっこんでも談義には発展しづらいでしょう。モバイルアプリとwebでも性質は異なりますから、「モバイルwebサイトにける最適なナビゲーションとは」といった記事を投げたところで、アプリデベロッパーは喰いつきにくいかもしれません。

一番良いのは、共通言語になりやすい、普段使っているアプリやwebサービスを題材することです。やはりAppleやGoogleのプロダクト、TwitterやPinterest, そしてこのMediumなど、みんなが使っている有名なwebサービスをまずは選ぶことです。

そこから発展して家電や自動販売機に手を広げてみるのも良いかもしれません。

観察しよう

UI談義は何も答えが出ずに自然散会してしまうこともありますが、時には真理に近づくこともあります。ここで、我らが ui-dangi チャンネル一番の成功例（？）とも言える、メールアプリの事例を挙げてみます。これについては私が以前Mediumで記事にしてアウトプットしました。元々はUI談義の有志によって導き出されたメールアプリの解剖結果です。

ちなみにここでいう『ヤバイ』は肯定的な意味で捉えてください。

iOS 純正メールアプリのUIがヤバイ件

事の発端は、メールアプリのモーダルがiOS標準の形になっていない、なぜだ。というちょっとした疑問からでした。

普通のユーザーはこれに何の疑問も持たずに自然に使いこなすだろうと思います。ちょいと洞察力がある人であっても、奥行き感でカッコつけてるんだろうくらいにしか思わないでしょう。しかしUI談義ではここに『なぜ』を突きつけます。

まだこの画像だけではよくわからないので、他の動きも観察してみましょう。

新規メッセージ画面がスクリーン下部にスタックされる機能があることを発見しました。メールアプリを使っていなければそもそもこの動きを見つけることすらもできなかったでしょう。普段からいろいろなアプリに触れておくべきだと思いました。この画像のような、ビューコントローラーの外側にスタックされる部品はUIKitでは提供されていません（これが標準のものではないことは、UIKitに精通しているデベロッパーか、あるいはデザインガイドラインを読めばわかる）。Appleのメールアプリ開発チームはわざわざ自社のUIKitのルールを自ら逸脱してこのような独自UIを設計しました。なぜでしょうか。「見た目がカッコいいから」だけではそんなことはしないでしょう。観察からUIを解剖して、この標準のものではないデザインの真理を探り出します。

さらに観察を続けると、スタック部分をタップすることでSafariのタブ一覧と同じような見た目に変化することがわかりました。もちろんSafariのタブ一覧含めこれはUIKit標準のものではありませんが、この部分にSafariと同じUIを採用したことには明確な理由がありそうですね。

メールアプリのメッセージ画面はタブとして扱われる…このことがわかったら、次にタブとは何かという考察をします。詳細は省きますが、タブとはすなわちウインドウの別表現であって、タブ化した物体はウインドウで表現されるドキュメントである、ということがわかってきます。そもそもタブと言って良いのかという議論もありますが、このSafariのタブ一覧はどうみてもスタックされたウインドウの一覧です。

当時のUI談義では『ひょっとしてMacのメールアプリと同じなんじゃね』という発想から一気に真理に近づきました。要は、デスクトップアプリのマルチウインドウをモバイル化しようとしたらこのメールアプリの形にせざるを得なかった、ということなのでしょう。

観察のコツ

観察には多角的な視点が必要です。

• アプリの目的を探る（アプリの目的は大抵ひとつである）
• 目的（ゴール）までに至る過程で、ユーザーは何をすべきかを探る
• ランドスケープ表示にしてみる
• スプリットビューにしてみる
• タブレット版を見てみる
• デスクトップ版アプリがあればそちらから掘り下げてみる（特にApple純正アプリ）
• タッチしてみる、ダブルタップしてみる、ドラッグしてみる、フォースタッチしてみる
• 長押ししてみる（長押しは大抵ショートカット機能である）
• 言語環境を英語もしくはアメリカ合衆国にしてみる
• カレンダーを和暦にしてみる
• アップデート前後の違いを比べる
• 気になったらすかさずスクリーンショットを保存する
• できれば動画やgifアニメで記録する

悪いUIのリデザインをしてみる

UIがダメなアプリをリデザインしてみましょう。ファストフード系アプリ、メディア系アプリ、交通系アプリはそういったネタの宝庫です。『なんでそのUIにしたの？』『何をさせたいの？』と言いたくなるような絶妙なものだらけなので、もしリデザインするならどうすれば良いのかを考えてみると面白いかもしれません。

むすび

UI談義とはデザインを解剖して真理を探るための手段です。よくできたUIはとても自然で、ユーザーの意識の中に融け込んでいます。それでいて気持ちの良い主張をします。このデザインの真理を探るためにも普段から様々な優れたアプリに触れることが重要で、そのためにも有志で集まってUIについて談義しましょう。私のおすすめはAppleの純正アプリを観察することです。純正のiOSアプリには大抵Mac版もありますから、それらを比較することで、デスクトップとハンドヘルドとの間で彼らがどうヒューマンインターフェースをデザインしているのかがよく分かることでしょう。

今回はメールアプリを一例にUI談義をご紹介しました。また何か成果がありましたらMediumで随時言語化していこうと思います。

UI Design Advent Calendar 2016 - Adventar

私が考えるエロいUIの条件：

• AppKitを利用したCocoa App
• デスクトップアプリ
• WebView, Electron, Flash, Javaなどの技術で構築しない
• HIGを守る／Apple純正アプリをリスペクトする
• WindowsのUIを基準にしない
• ドラッグアンドドロップなど機能的にもMac OSの仕組みに従う
• 独自UIで汚染しすぎない
• Mac OSらしい色使い
• Mac OSらしいアニメーション／インタラクション
• Mac OSらしい言語表現（例えば「ウインドウ」「環境設定...」など）
• Mac OSらしいフォント（San Francisco, Helvetica Neue, Lucida Grande, Hiragino Sans, Menlo, Monaco...）
• 標準的なメニューバーおよびキーボードショートカット

よって例えば次のようなアプリのUIは『エロい』とは言えない。

• Chrome
• Adobe Creative Cloud
• Microsoft Office
• Slack
• Twitter

Chrome は機能的には優れているが、Mac OSのHIGを無視してしまっているため、条件に当てはまらない。

Adobe CC はWebの技術でUIが構築されていると思われ、Mac OSらしいUIからは程遠くWindowsとの共通化が図られている。メニューバーの内容にもMac OSらしさはないため、条件に当てはまらない。

Microsoft Office はMac OSらしいUIからは程遠く、条件に当てはまらない。

Slack はWebの技術でUIが構築されているので、条件に当てはまらない。

Twitter は独自のUIがHIGから逸脱しすぎているのと、インタラクションがMac OSらしくないことから、条件に当てはまらない。

Paw 3

https://paw.cloud

HTTPクライアント。一目見て、この設計者はMacのUIはどうするべきかをちゃんと分かっていると感じた。色の選び方も素敵。全体的にXcodeから影響を受けていると思われる。

Sketch

The digital design toolkit

言わずと知れたGUI設計ツール。我々もお世話になっていて頭が上がらない。そのSketch自体もMacのツールはどうあるべきかをちゃんと分かっている。

左サイドバーにレイヤー要素、中央にエディタ、右サイドバーにインスペクター、そして上ツールバーというスタイル。もちろんドキュメントベースドアプリなのでマルチウインドウにも対応している。

全体的な感じからKeynoteから影響を受けていると思われる。

Sequel Pro

Sequel Pro

MySQLデータベースを構築するためのMac App。普段使っていないので細かいところまではわからないが、このウインドウを一目見れば『分かっている』のが伝わってくる。黄色と紫色を使い分けるのはMacユーザー、特にXcodeユーザーには馴染みがあって良い。

ツールバーの感じからスタイルが3〜4年ほど古い印象はある。

Tower 2

Tower - The most powerful Git client for Mac and Windows

割と良いお値段のGitクライアント。スクショを眺めるだけでもほぼ完璧である。Data Sourceスタイルのサイドバーを備えた3ペイン構造はMail.appに近いUIかもしれない。

Cornerstone 3

https://www.zennaware.com/cornerstone/

Subversionクライアント。使ったことはないけれど、スクショを見る限りではUIは素晴らしい。Mac Appをデザインする際に参考になりそうな表現が数多くある。

Fork

Fork - a fast and friendly git client for Mac

シンプルなGitクライアント。TowerやSourceTreeほどではないけれども、必要最低限の機能は備えているしUIはとても美しいので、今後期待したいMac Appである。

ドキュメントベースドのマルチウインドウアプリではなさそうだが、Safari/Xcode風のタブバーに対応しているので実質的にはドキュメントベースドに近い。

Mac Appとしてはメニューバーから行える命令の量に若干貧弱さを感じてしまうがまだβ版ということで、今後手入れされることを期待したい。

Kaleidoscope 2

Kaleidoscope - File comparison for Mac

ファイルの差分を確認できるツール。今となってはスタイルが古いがあえてここに挙げた。その様子は2009年頃のSafariを彷彿とさせるメタルUIで、タブの角丸の具合が特にイケている。

CodeRunner 2

CodeRunner - Programming Editor for Mac

コードをサクッと実行できるエディタ。スニペットのテストなどが行える。

Xcode風のタブバーが再現されていて、コード補完機能やエディタの構成なども全体的にXcodeをリスペクトしていてとても良い。

1Password

Password Manager for Families, Businesses, Teams | 1Password

言わずと知れたパスワードマネージャー。スキューモーフィズムの時代は微妙だったが、最近の1PasswordはMac OSらしさがあって良い。横3ペイン構造はMail.appで馴染みがあるので直感的で使いやすい。環境設定ウインドウはMac OSらしさをはかる上でも注目したいところ。

CotEditor

CotEditor

Cocoaらしさが詰まったテキストエディタ。UIを余計にIDEっぽく拡張せずに昔のSimple Textのような形態を守っている。それでいてコーディング向けの痒い所に手が届く機能もサポートしている塩梅が良い。

PopClip

PopClip for Mac

PopClipのUIと言えるようなものはこのポップアップと環境設定画面くらいだが、テキストフィールドでポップアップが出る様は余計なものはなくMac OSらしさを破壊せずうまく調和できている。その上でMacに足りていないショートカット機能を提供できているので、これも挙げてみた。

Pixelmator

Pixelmator

超良くわかっているペイントアプリ。Mac OSらしさを残しつつ黒地のUIをデザインするのはなかなか難しいけれども、これはちゃんとHIGを守りつつ独自色も出せていて素晴らしい。機能豊富で複雑なツール系アプリだが、なんとなく触っていても使い方が分かるのは良くできている証拠である。

Adobe Photoshopも見習うべき。

セル（UITableViewCell）は iOS においてもっとも一般的なビューのひとつです。セルを利用することで、コンテンツの表示、選択、スイッチやボタンの配置、テキストフィールド、ナビゲーションを実装することができます。この辺りの具体的な実装例は『設定』や『Apple Store』が参考になるでしょう。セルにはさまざまな役割を与えられますが、どのような作法に従ってデザインされているのかよく理解する必要があります。

セルの一般的な利用作法は iOS Human Interface Guidelines で解説されていますが、私はこれを読んだだけでは十分に理解が及ばなかったため、iOS 標準アプリの事例からセルのデザインについて考察したものをまとめました。この記事では iOS の標準的なセルのデザインパターンを探り、自身のアプリにどう活かせるのかの土台となるよう考察してみます。

UICollectionViewCell もセルと呼称されますが、今回は UITableViewCell に限定して考えます。

内容は Qiita の記事と同様です。

セルとは何か

セルは情報の細胞です。ひとつの情報のまとまりが“セル”として表現されます。セルはそれ単体ではほとんど意味をなさず、セルの集合＝テーブルビューによってはじめて機能するようになります。このような情報の細胞が集まって構成されるのがテーブルビューであり画面であり、そしてアプリケーションです。

テーブルビューセルが細胞というメタファーで表現されることには少々違和感があるかもしれません。iPhone のテーブルビューはセルがただ上から下に一列で並ぶので、細胞が敷き詰められているようには見えません。どちらかというとリストです。ここで、iOS の親である Mac OS X を見てみましょう。UITableView に相当する NSTableView にもセルという概念が存在します。NSTableView ではセルはとても細胞らしく振る舞われます。

iPhone の画面は縦長であることと、その利用のされ方が PC とは大きく異なるため、モバイルに適したテーブルビューとしてリデザインされました。歴史を振り返って UITableView は Cocoa (Mac OS X) の NSTableView から来ているものと仮定すると、UITableView はモバイルに適した一列表示に特化した廉価版 NSTableView と解釈できます。

元来 NSTableView のセルはビューではありませんでした。Cocoa における“セル”はビューとは別の NSCell という情報で扱われ、基本的にセルはどんなビューにも入り込むことができ、実際の描画とイベント処理はビューが行うものとなっていました。セルにはボタンとしての見た目を決める「描画処理」を記述したメソッドだけを実装すれば良いものでした。この仕組みがあるおかげで、ボタンセルをそのままテーブルビューに設置すればボタンの見た目をしたセルを割と簡単に実現することができました。セル単体では意味をなさないけれども、ビューに入り込むことでボタンとしての機能と見た目が成り立つようになっていて、その設計思想はまさに細胞というのに相応しいものです。

しかしここで、NSCell を有しないビュー、例えばプログレスインジケーターをテーブルビューに並べることは非常に難しいという問題が浮上します。Safari のダウンロードパネルのようなテーブルビューは正攻法では作ることのできないビューだったので、実装にはなかなか苦労したものです。

NSCell と各種ビューでそれぞれ別のクラスとして実装しなければならないこと、そこまで細胞的な汎用性は必要ないにもかかわらず NSCell の仕組みに従う必要があること、NSCell が NSObject 直下のクラスなのにビューで表示する内容の描画処理を実装する必要があること、ビューに依存する処理は難しいこと、iOS が登場して UITableViewCell のような直感的な仕組みに慣れてしまったことなど……。とにかく NSCell はレガシーかつ扱いづらいということで、最近はビューベースドセルという iOS 風の仕組みが導入されています。要はビューとしてセルを扱えるようになった、ということですね。

iOS 側からはよく見えなくても、Mac OS 側からはセルとは何なのかがよく見えてきました。
ここからは iOS に戻ってセルのデザインパターンを考えてみます。

セルのデザインとシグニファイア

純正アプリはそのほとんどが UIKit 標準の状態で実装されているので、セルの利用作法を学ぶ良いお手本となります。それらを観察して見えてきたデザインの構造について以下にまとめました。

項目のリスト表示

セルの原則は情報を均一に配置することです。同じセクションに並べられる情報は同等になります。

『設定』アプリのように、同一テーブル内で情報を区切って表示するには『グループスタイル（Grouped）』を採用します。グループスタイルでは連絡先で見られるようなセクションヘッダーやインデックス（索引）は利用できません。『設定』アプリのような用途でテーブルを用いるにはこのグループスタイルを採用します。

主にデータやコンテンツを並べる用途でテーブルを用いるには『プレーンスタイル』を採用します。このスタイルでは『連絡先』アプリようにセクションヘッダーやインデックスを利用することができます。

ディスクロージャーを伴うセル

セルのアクセサリーにはディスクロージャーを配置できます。ディスクロージャーはその行と別の情報との連続的な関連性を示しています。セルにディスクロージャーが表示されることで、ユーザーはセルをタップすると関連する情報を扱う別のテーブルに遷移できることを認識できます。これはドリルダウン（プッシュ遷移）に限らずモーダルビューによる遷移でも同様です。

遷移先がテーブルではないセルにディスクロージャーを用いるのはあまり好ましくない気がしますが、その行と関連するテーブル以外の情報を表示する画面に遷移する程度であれば許容されるでしょう。ライセンス条文を記述した WebView へ遷移するような場合にもディスクロージャーを利用することができます。SFSafariViewController はモーダルで遷移しますがそのトランジションがあえてドリルダウンのように演出されるため、ディスクロージャーとは相性が良さそうです。

逆にディスクロージャーを利用できない場面、例えると、セルをタップしたら Safari で web ページを開くといった明らかに連続性が断ち切られるような動作です。ディスクロージャーはそのセルに関わる情報への関連性を示していますから、別のアプリに遷移するには後述する『アクションを伴うセル』を用いるか、セクションヘッダー／フッタービューに配置したボタンで対応します。

値を表示するセル

アクセサリーに詳細ラベルを伴うセルでは値を表示することができます。作法として、左側のラベルは左寄せであるのに対し、右側の詳細ラベルは右寄せであるべきです。色がグレーであると編集ができないことを意味します。ユーザーはこのようなセルを見たとき、タップできないセルだと認識します。

次の例ではディスクロージャーを併用しているので、このセルはタップすることができ、関連するテーブルで情報を編集できるということを示唆しています。関連テーブルの結果がセルの値として表示されています。ユーザーはこのようなセルを見たとき、セルをタップした先に何かしらの選択肢や編集機能があることを察します。

値を表示するセルは普通タップできないものですが、シリアル番号のように、どこかで入力が必要になるかもしれなくて手入力が困難な情報を表示する場合は、そのセルをタッチした時にコピーメニューを表示するというインタラクションを実装してあげると親切です。

スイッチ・ステッパーを伴うセル

セルのアクセサリーにはスイッチやステッパーを配置できます。このようなセルはタッチに反応しません。アクションはスイッチ・ステッパーのみに作用します。もし押下（ハイライト）できてしまったらそれは実装ミスの疑いがあります。

なお、UISwitch は UITableView のみで使用しなければならないとされています。

スイッチを用いる場合はその状態が一目瞭然であるため、スイッチに応じてラベルの表記を『オン』『オフ』と切り替えて表示するようなことは必要ありません。

コントロールを伴うセル

スイッチやステッパー以外のより大きなコントロールはアクセサリーではなくセルに直接配置します。このようなセルはタッチに反応しません。アクションはコントロールのみに作用します。

詳細ボタンを伴うセル

スイッチ・ステッパーを伴うセルに似ていますが、代わりにボタンを配置したセルです。このセルはタッチに反応できます。セルとボタンのアクションは個別に実装できます。

このようなアクションが二つ以上あるセルはユーザーを戸惑わせる可能性があるため扱いには要注意です。Wi-Fi 設定の例ではうまく対処していて、セルのタップでは選択肢としてのセルのように振る舞い、詳細ボタンは詳細設定への遷移アクションとして振る舞います。もし選択されている場合はセルのタップでも詳細設定に遷移します。

選択肢としてのセル

セルのアクセサリーにはチェックマークを配置できます。チェックマークを用いたテーブルでは、少なくともそのセクションはすべてチェックマークが表示されうる選択肢として機能しなければなりません。ユーザーはセルを選択肢として認識したとき、そのテーブルを押下可能な候補一覧と見なします。このようなテーブルではセルがタッチ可能なものでなければなりません。

もし選択肢が一つしかなくトグルのような機能をデザインするには、チェックマークの代わりにスイッチの利用を検討してください。

左チェックマーク？

『設定』アプリの Wi-Fi やサウンド設定画面ではこのような左チェックマークのセルが見られます。チェックマークはアクセサリーに配置するものとされていますが、左チェックマークは標準の機能では提供されていないので、イメージビューなどを利用して独自に実装しているのでしょう。Wi-Fi 設定画面ではアクセサリーに詳細ボタンを配置しているためチェックマークを左側に寄せているのだと思われます。サウンド設定画面に関しては、本来の右チェックマークではなく左チェックマークを用いている理由は正直言ってよくわかりませんでした。

アクションセル

アクションをセルに持たせるにはテキストを Tint Color などで着色したセルを用います。iOS では Tint Color で着色された要素はボタンと認識できるので、これはほぼボタンと言っても良いでしょう。このようなセルはタップしても関連テーブルには遷移しません。テーブルに行を追加するアクション、情報を削除するアクション、web ページを Safari で表示するアクションはこのアクションセルで実装します。アクションが破壊的であるなら文字色は Tint Color ではなく Destructive, 赤色にすると良いでしょう。

アクションセルが無効な場合は、色を disable と同じグレーにしてタップできないことを説明します。

テキストフィールド型セル

セルそのものにテキストを入力できるセルです。テキストフィールドには幾つかのパターンがありますが、コンテクストに合わせてデザインされているように見えます。一般には次のものが用いられます。

テキストフィールドにはプレースホルダーが記入されていて、ユーザーはプレースホルダーを見てこれが文字入力可能なテキストフィールドだと理解することができます。書式を記入しておけばそれが何を入力すべきフィールドなのかも理解しやすくなります。

左寄せと右寄せの違は正直に言ってよくわかりませんでした。何か明確な作法が実は隠れているのかもしれないし、特に理由なんてなく、案外担当者の気分で違いが生まれているのかもしれません。

そこに至るコンテクストからセルの意味を理解する

VPN 構成を設定するこの画面では「ラベル付き左寄せ」が用いられていますが、プレースホルダーが無いセルはこれがテキストフィールドなのかただのセルなのか、一目では区別がつきません。ユーザーはラベルの意味とこの画面でのコンテクストを理解して初めてそれらがテキストフィールドであろうと察することができます。

セパレーターの隙間

iOS 7から、セルのセパレーター（セルの境界線）の左側に隙間が空くようになりました。

セルの左端ではなく文字列の始まりに合わせて線を引くと視覚的に開始点が揃って目線が文字列に向かうので読みやすくなります。横書き文を右から左に読む言語ではこれが反転します。また、セルを完全に区切らないことでこれらが連続的な情報であるということも比喩的に表現されているように思えます。

さらに踏み込むと、セパレーターの隙間が情報に階層構造を生み出し、同一セクション内であってもグループ分けと似たような情報の分類が行えます。

例えばiOSのUIScrollViewは自己帰属感を得られるUIの代表だ。60FPSで描画されるスクロールアニメーション、端に到達したらバウンスバックしたり、指が離れたらその瞬間を初速として滑らかに減速してゆくインタラクション、そしてパフォーマンスを上げるためのセルの再利用機構など、これらすべてがスクロール時の自己帰属感を得るために不可欠な要素となっている。驚くことにiPhoneの第一世代（OS X iPhone）からこれが実装されていたというのだから、Appleのデザインとエンジニアリングを融合した開発姿勢は圧倒的すぎて本当に頭が上がらない。そして9年近くたった今でも、WebView含めUIScrollViewはiOSのGUIの基本要素になっているし、細かいアップデートはあったにせよ基本的な部分は当時から変わった様子はない。iPhone自体のハードウェア性能が比較的低くてもとても滑らかな動作、いわゆるぬるぬる感が得られる所以はここにある。iOSのユーザー体験はUIScrollViewがあってこそのものと言っても過言ではない。

iOSアプリに携わる者としては、ただこれを賞賛してありがたがるのではなく、その設計思想と正しい使用方法を理解した上でアプリに適用していかなければならない。しかし残念ながら自己帰属感の重要性を理解せずになんとなくのUIデザインを行ったり見た目だけのアニメーションを実装してしまっているようなプロダクトが多いのも実情である。

『スワイプしたらそれに合わせて画面がスライドしてビューが切り替わる』

という要件を実装するとき、ダメな開発現場ではこうやってしまう。

まずスワイプジェスチャのイベントを判定する処理を実装する。タッチ開始時点から終了時点までの移動距離や速度やベクトルなどの数値を適当な閾値で抽出して、そのイベント終了をトリガーにしてビューがスライドするアニメーションを改めて描画する。

このアニメーションは指に吸い付くような動きをするわけでもなく、特定の指の動きをただのコマンド入力代わりにして映像を動かすだけのものになってしまっている。PCアプリで特定のマウスジェスチャを入力したらコマンドを実行するような機能があったりするが、あの感覚だ。もっとiOS的に言うとUIPanGestureRecognizerを使わない実装である。意外とこれができていないアプリは多い。そしてこれだけで自己帰属感は失われてしまう。GUIのぬるぬる感が無くなるのはスマートフォンのアプリにおいては致命的と言える。

無駄なアニメーションというのは例のような実装の不手際で無意味化しているものや（私はほぼバグだと認識している）、見た目の格好よさに惑わされて目的を見失っているものを言う。そうではなく、シグニファイアをデザインするため、自己帰属感をもたらすため、しっかりと目的を持ってアニメーションをデザインしなければならない。そしてこれはエンジニアリングが大いに関係してくるところなので、デベロッパーこそがこの概念をよく理解する必要がある。

社内のSlackでUI談義が突発的に始まることがあるのだけれども、以前そこで上がったiOS純正メールアプリのUIについてのネタがなかなか面白いのでまとめてみようと思った。結論から言うと、純正メールアプリ、ヤバイ。

まずは観察

メールの新規メッセージ画面は他の純正アプリではあまり見かけないようなトランジションを採用していて、開くと元の画面が少し後ろに下がってナビバーだけが見えつつもメッセージ画面が中途半端なモーダルビューで現れたような状態になる。このUIが使いやすいとか何となく見た目がかっこいいとか、そんな上辺だけの理由では絶対ないはずなので、AppleがメールアプリをデザインするときになぜこのUIに至ったのか、その理由を考えてみた。

普段純正メールアプリでメッセージを送信することはほとんどなかったので、まずはいろいろと動きを観察することにした。新規メッセージ画面は送信せずに下にスワイプすると、このようにスタックされていく機能があった。このスタック部分はツールバーを押し退けて下に鎮座する、ある意味でグローバルな状態になっている。ここにスタックされているのは「すべての下書き」内に溜まっているもののうち、画面として開かれているものだ。

そしてこのスタック部分をタップすると、なんとSafariで見たことがある画面一覧が現れる。元々のメールボックス画面もそれらの一つとして扱われているが、左上に×ボタンがないことからもわかるようにこの画面だけは閉じることができない。新規メッセージ画面はSafariと同様、×ボタンまたは左スワイプで閉じることができる。これらは閉じてしまっても下書きとしては残っている。

ここまでの材料で考察したのは、新規メッセージ画面はiOSで一般的なモーダルビューではなくウインドウのようなものではないか、ということだ。同じUIを採用しているSafariの画面一覧を考えてみるとこれはしっくりくる。

タブとは何か

そもそもWebブラウザのタブとは元はウインドウなのであって、何枚もドキュメントウインドウを重ねるのが使いづらいということでタブの形で一つにまとめたUIパターンだ。なのでそのタブを分解したらウインドウになるのはとても自然なことだ。iPhone版SafariではPCで一般的なタブバーをあえて採用せず、重なったウインドウの切り替えという表現で同様の仕組みを実現している。もちろん左上には×ボタンが配置されている。これはAppleのOSでは標準的なクローズボタンだ。iPhoneというモバイルデバイスは複数のウインドウを同時に扱うような用途のためには設計されていないので、このように単一の画面（アプリ）にのみ集中できることが大前提となっている。アプリは絶対にひとつしか表示できない。あるアプリの中でウインドウのメタファーを採用したとしても、ユーザーが同時に扱えるのはひとつだけだ。SafariのUIはそのことをよく反映している。

なお、iPadではスプリットビューでアプリを同時に起動できる機能があるし、SafariではPCと同様のタブバーを採用している。iPadは片手前提のiPhoneとは違う使い方を想定したデバイスなので、UIにもこのような違いが現れる。Appleは単純に画面の広さだけではなく、ユーザーがデバイスを使う場面やユーザーとデバイスの「距離」に合わせてそれぞれ適切なUIをデザインしていることが伺える。

純正メールアプリは単なるモバイルアプリではない

ここで純正メールアプリに話を戻すとあの画面がSafariと同じUIなのも察しがつく。要は新規メッセージ画面は一つ一つがウインドウなのであって、下のスタックはウインドウを開きつつも避けている状態（Macで言うExposéやDockへの最小化状態）、画面を閉じることはウインドウを閉じることと同義だ。メールボックス画面が後ろに少し下がる演出は、メールボックス画面は生きているのだけれども一旦後退しているよ、という視覚的な合図。だから新規メッセージ画面は一応モーダルビューっぽいんだけれど完全ではないみたいな、そういう特殊な状態になっている。下にスワイプしてスタックできるのは、開いたまま下に最小化しているよ、ということなのでしょう。

このようなUIはPCのアプリを見ればとてもしっくりくる。MacのメールアプリMail.appではメッセージのウインドウをいくつも並べて開くことができる。メッセージを開いたままメールボックスの方に行くことだってできる。マルチウインドウとはそういうものだ。

このようなマルチウインドウのUIをモバイルに持ってきて更に最適化すると結果的に純正メールアプリのあの形になる。実はiOSの純正メールアプリは、マルチウインドウをモバイルで実現してしまったとてつもないアプリなのだ。おそらくこれが答えでしょう。

メールボックス画面と新規メッセージ画面は独立したウインドウ、そしてモバイルでマルチウインドウを擬似的に実現するには完全なモーダルではダメだった。ウインドウは閉じることができるし、開いているウインドウはそのままの状態で簡単に切り替えられなければならない。閉じずにメールボックスも確認できなければならないから最小化の仕組みが必要。特にiPhoneでは単なるタブバーでは到底実現できなかったので、ウインドウのスタックとSafariを模倣したUIが必要だった。（実はSafariも結構すごかった。）

自分たちがモバイルアプリのUIをデザインしようとしてもまずここにはたどり着くことができなかっただろうし、モバイルアプリとは何なのか、モバイルのUIとはどうあるべきなのかを改めて考る機会にもなった。そしてAppleのデザインが単に表面的なものではないことに衝撃を受けたのだった。「純正メールアプリ、ヤバイ」と。

Mac OS の左と右考察シリーズ。今度のお題はウインドウのクローズボタン。閉じるボタンとも言う。昔は四角かったからクローズボックスとも言われた。Windows では右配置になっているクローズボタンだが、Mac OS を前提になぜ左配置なのかを考察したい。

ウインドウは左上からはじまり、右下に終わる

情報の流れの原則に従うと、ウインドウの起点は左上、終点は右下になる。右下には（かつての Mac OS では）サイズボックスと呼ばれるウインドウを拡大縮小するための箱が設置されており、それ＝終点をドラッグすることで起点を固定したままウインドウの大きさを変えられた。ウインドウに収められるコンテンツも左上起点に描画されるので矛盾がない。

今時の Mac OS ではウインドウの端であればどこを掴んでも拡大縮小できるようになっているのでサイズボックスは省かれた。掴んだ辺の位置によっては拡大縮小処理の起点が右上や左下になることもあるが、本質的なウインドウの起点は左上と見てよい。

ウインドウは左上から右下に向かって拡張する。逆に言えば右下から左上に向かって収束するということだ。だからその収束点にクローズボタンがあるのが自然だ。一番分かりやすい例が Dashboard ウィジェットの閉じる際のアニメーション。左上のクローズボタンを押すとウィジェット自体がそこに向かって吸い込まれる。

Windows は Mac を反転させただけなんじゃないか説

ではなぜ Windows はクローズボタンを右側に配置したのかという疑問だが、実際のところはよく分からない。全く裏付けのない憶測だが、Windows が最初に Mac OS を真似たときに差別化を図るためにあえて配置を逆にしたのではないかと考えている。Windows には全体的にそのような反転した UI デザインが多く見られる。デスクトップアイコンの配置（左）、メニューバー（上）に対するタスクバー（下）、ボタン配置（肯定が左）、カーソルの色（白）、そしてウインドウのクローズボタン（右）。すべてを Mac の逆にしたはいいけれども、情報の流れる方向は変えられないので、結局矛盾が生じているように見える。その一つが右上クローズボタンだ。使えないわけではないが、テキストの正方向は右なのに次第に否定的なクローズボタンに近づいてゆくのが今ひとつ納得できない。

タブはウインドウの一種だからクローズボタンは左側にあるべきだ

Mac に話を戻してここでブラウザなどのタブを考えたとき、やはり左側にクローズボタンがあるのが自然になる。このタブというのは言い換えると複数の書類＝ウインドウをひとつのウインドウに重ねまとめた状態、であればウインドウと同じく左側にクローズボタンを配置しないと一貫性が保てない。書類を閉じるアクション＝左側 というルールは守られるべきである。Safari ではこれが正しく実装されているが、Chrome は残念ながら Mac 版であっても無視してしまっている。

Web サイトのクローズボタンはどちらにあるべきか

Web でもできれば、ユーザーの利用している OS で判断してクローズボタンの左右を最適化する実装があると良い。残念ながら大半のサイトのモーダル的画面では Windows にならって右側固定のクローズボタンが実装されている。これは Mac ユーザーや iOS ユーザーにとっては違和感のある体験だ。こういう1pxに匹敵する些細なインタラクション “little big details” に気を配ったデザインができれば、そのプロダクト全体の UX を良くすることにつながると思う。

Mac OS のデスクトップは今日に至るまで一貫して右側にアイコンを配置するデザインを採用している。普通に考えたら、左から右に文を読むのだからアイコンも左上から詰めるのが自然に思えるし、実際フォルダの中身はそうなっている。Windows も左配置だ。Mac OS のデスクトップだけなぜ右配置になっているのか、それを考察してみた。なお私は正解を知りません。

はじめにこの問題を考えたとき、当初の画面が狭い Macintosh においてウインドウやメニューが左側を塞ぎやすい画面構成であること（右側が空きやすい）、そしてマウスの移動量のバランスを考慮して右側に置いたのではないか、となんとなく思っていたのだが、多分これだけでは説明不足。

PC のデスクトップとは元来「机上」のメタファーであり、ピクセルで現実世界の姿を模倣したものだ。大多数の右利きユーザーを想定した時、文房具類は普通机の右側に置かれる。大抵ね。だからデスクトップでも道具は右側に置かれるのが自然ということになる。考えてみればとても当たり前のことだが、そんなことも忘れて PC の「デスクトップ」だけを見てしまっていた。ヒューマンインターフェースは人間と接するところで、人間のためのデザインだということを再認識したのだった。

『右利きを想定した時、机上では道具は右側に置かれる。それに倣ってデスクトップのアイコンも右側に配置される。』

やっぱり気になったので改めて昔の Macintosh Human Interface Guidelines (1995) を眺めてみたところ、気になる記述を発見した。（これはアーカイブされていて良い奴なのか不明……）

A document for a word-processing program has a well-defined most useful width (the width of a page) and most useful height (the height of the screen). Therefore the width of the standard state should be the width of a page or the width of the screen, whichever is smaller. (When determining the width of the standard state, it’s a good idea to leave room on the right side of larger monitors so that desktop icons are not obscured when the user switches to the Finder.) The height of the standard state should be the height of the screen or the length of a page, whichever is smaller. ––170

『ウインドウはまず左上起点に“標準的な大きさ”で表示されるので、右側の余地があればデスクトップアイコンが隠されずに済む。』

実際の正解はわからないし一つだけでもないとは思うが、「デスクトップ」は机上のメタファーは必ず取り入れているはずだし、同時に情報設計やユーザビリティもよく考慮している UI だと思う。次はメニューバーや Windows との違いを考察してみたい。