UITableView の衝撃

ひとつのデザインが事実上の標準となり、その後の基本パターンを変えてしまうことがあります。変わった後ではそれが当たり前となってしまい、その標準に始まりがあったことなど誰も気にしなくなるのです。また振り返ってみたとしても、それがなかった頃の感覚に立ち戻ることはできないので、もはや何がどう新しかったのかを実感することは難しいのです。

2007年に iPhone が発売され、その一年後に日本で iPhone 3G が発売されてから今日（2018年7月11日）でちょうど10年が経ちました。この10年間でスマートフォンやそのアプリを介したオンラインサービスは瞬く間に普及し、私たちのモバイルコンピューティング、コミュニケーション、ソーシャルメディア、Eコマースなどの態様が大きく変化したのは周知のとおりです。

iPhone のデザインは多くの面で新しいものでした。そしてその大部分がその後のスマートフォンの標準的なイディオム（慣用表現）となったため、どの部分がどのように新しかったのを細かく説明するのは意外と困難です。しかし、幸いなことに私たちはUIデザインの専門家として iPhone の登場に立ち会うことができたので、振り返って、ある程度その当時の新規性や、UIデザイン史上の意義を言語化できるかもしれません。

A guided tour

MacWorld 2007 のキーノートでスティーブ・ジョブスが iPhone を発表した直後、Apple は “iPhone. A guided tour.” というビデオを公開し、iPhone の基本的な操作方法を丁寧に紹介しました。

Apple の製品はマニュアルが少ないことで知られており、わざわざ使い方の説明ビデオを発売の何ヶ月も前から公開するのは不思議な気がしました。しかし iPhone には新しい操作方法やUI表現が全面的に取り入れられていたので、その良さを正しく評価してもらうためには、ある程度の前提知識が必要だと考えたのでしょう。なぜならタッチ操作による新しいUIで Apple が目指したのは、「教わらなくてもある程度わかる」ものではなく、「一度見れば完全にわかる」ものだったからです。

このビデオには iPhone UI のエッセンスが詰まっています。iPhone が提示した新しいイディオムは、例えば次のようなものです。

全体

• 静電容量式による敏感なタッチ反応
• 指先のサイズ（約1cm四方）に合わせて操作対象がすべて大きめ
• あらゆるトランジションにアニメーションを利用
• モーダル画面は下からスライドして現れる
• 全画面表示のウィンドウ（アクティブなビュー）
• 要素のドラッグ移動は限定的（アプリアイコンの移動、行の移動、シークバーの操作程度）
• モードの許容（編集モードや編集画面への遷移、メニューにアクションを詰め込むのではなく、必要なボタンをその都度シートダイアログで出すなど）

ホーム（スプリングボード）

• アプリ選択のためのスプリングボードが初期画面
• 前面の物理ボタンはひとつだけで、それはホームへのエスケープハッチ（あらゆる状況で使える出口）
• スライドでロック解除（操作の開始点にいきなりジェスチャ）
• スプリングボードの横スライド

写真・地図

• ダブルタップによるズーム
• ピンチ操作によるズーム
• パン（ドラッグ）による移動
• スワイプを用いたピラミッド型のナビゲーション

音楽・写真・動画

• 画面のどこかをタップして操作コントロールを表示／非表示
• ローテーションで画面内容が変わる

テキスト入力

• オンスクリーンの QWERTY キーボードに完全依存
• 優先的スペルコレクション
• 虫眼鏡表現

一覧表示

• 画面端までセルが締める一次元リストをほとんどのアプリで使用
• 画面を直接なぞる／弾く操作によるスクロール
• 慣性スクロール
• スクロールのバウンス効果
• ナビゲーションバーを固定したスクロールとドリルダウン
• 水平方向に画面がスライドするドリルダウン（シェブロンで示唆）
• ナビゲーションバーのタイトルトランジション
• カラムブラウザとビューベースドテーブルの融合
• 一覧と詳細で、UI表現としての区別がない
• ラジオボタン、チェックボックス、ドロップダウンメニュー、ボタンなどをテーブルのセルで表現

とはいえ、これらが全く新しかったわけではなく、それまでのデスクトップ環境におけるマウスジェスチャや、PDAなどのUI、そして iPod の操作方法を継承している部分も多くあります。しかしそれらが「指で操作するためのUI」としてひとつひとつ検証され、最適化してあるという印象を受けたものです。

iPhone のUIにおける全体的なフォームファクター（形、大きさ、配置）は、指でのタッチ操作に最適化するという方向で一貫して設計されており、その点がそれまでのハンドヘルド機器との違いを生んでいます。それに加えて iPhone では、「直接操作（Direct Manipulation）」についてそれまでにないくらい深く追求されています。

指で直接スクリーンに触れて操作し、スクリーンはそれに迅速に反応する。このコンビネーションのスムーズさが、ハードウェアとソフトウェアの両面から追求されているのです。iPhone 以前のタッチ式携帯機器は、タッチの精度やソフトウェアの反応が悪く、またそのほとんどはスタイラスペンによる間接的な入力であったため、操作性がよいとは言えませんでした。ただそれが当たり前だったので、それまでの操作性の悪さがはっきりと認識されたのは、iPhone（あるいは iPod Touch）を触った瞬間だったのです。

You had me at scrolling

iPhone のマルチタッチは Apple が2005年に買収した FingerWorks 社の技術がベースになっていると言われています。その技術では、単なるタップのジェスチャだけでなく、指を動かす方向や速度、同時に触れている指の数やそれぞれの動きが詳しくトラッキング可能であり、投影型静電容量方式のディスプレイ技術と組み合わさって、高速／高精度に指による入力がサンプリングされます。

また、OS X から受け継いだ Core Animation フレームワークの働きによって、iPhone のUIはスムーズにアニメートし、ほとんどあらゆる画面転換においてその空間的な遷移が視覚的に示されます。Core Animation のコンセプトは、アニメーション表示のために優先的かつ効率的にリソースを費やすというものです。専用のスレッドを用いてアニメーションがスムーズに動き続けるよう、OSレベルで処理を最適化しているのです。

iPhone においてウィンドウは全画面表示され、ウィンドウの存在自体がユーザーに意識されないようになっています。また iPhone ではグローバルな表示要素を極限まで減らしており、現在前面にあるアプリの名称も表示されません。そのためユーザーは今見えている画面の内容だけではシステム全体のコンテクストを見失う恐れがありますが、アプリの切り替えや画面のナビゲーションが空間的遷移のアニメーションを伴って表現されることで、ユーザーは仮想的なワークスペースの中で今どこにいるのか、直前の操作の結果として何が起こったのかを、理解しやすくなっているのです。

それまでのPDAやフィーチャーフォンのUIでは、個別の独立した画面がばらばらに存在していて、それらをひとつずつ呼び出すだけという単発的なインタラクションでした。しかし iPhone ではもっと階層的かつ文脈的なインタラクションが、ユーザーに適切に把握できるレベルで追加可能になったのです。

トランジションにアニメーション効果をつけることは従来のデスクトップOSでも行われていましたが（例えば OS X におけるジニーイフェクト）、それらは付属的な演出としての位置づけであることが多かったのです。しかしスクリーンサイズが小さいモバイル機器では、同時にいくつもの要素を並べて表示してシステムの状態を表現することができないので、操作に対するフィードバックとしてアニメーションが本質的な意味を持つのです。スムーズなアニメーション表示にOSレベルで取り組んできた Apple だからこそ、iPhone でその圧倒的な効果を顕在化できたのだと言えます。

これらを踏まえた上で iPhone のUIを見る時、その新しいイディオムの中心は、スクロールとナビゲーションにあると感じられてきます。それは、MacWorld 2007 のキーノートでスティーブ・ジョブスがはじめて iPhone のデモを行ったその冒頭で、はっきりと示されていました。

最初のデモでジョブスは、iPhone を起動すると、まず iPod アプリ（現在のミュージックアプリ）を操作しはじめました。アプリを開いて最初に表示されたアーティスト一覧を見せながら、ジョブスは「これをどうやってスクロールすると思う？」と聴衆に問いかけました。そこにはスタイラスペンはおろか、スクロールバーやスクロールボタンもありませんでした。そしてジョブスは「こうやって指を使うんだ」と言いながら、人差し指で画面の真ん中を上に弾いてスクロールしてみせたのです。その瞬間、すべての観客の頭が変化しました。新しいタッチUIがどういうものかを、一瞬にして全員が理解したのです。それまでもGUIの原則として「直接操作」は謳われていましたが、これほど直接的にスクリーンの内容が（しかもごく自然に）操作されたことはなかったのです。そしてその慣性スクロールが擬似的な摩擦によって停止する前に、キーノートの会場は拍手喝采となったのです。

続いてジョブスは、アーティストのリストからビートルズを選びます。するとアルバムのリストがスクリーンの右からスライドして入ってきて表示されました。そのリストで「サージェントペパーズ」を選ぶと、またスクリーンの右から曲のリストがスライドして表示されました。このドリルダウン（階層を下に掘っていく）の動きは、iPod ですでに見慣れたものでした。しかし大きな違いは、今やそのリストを指で直接操作してることでした。

ひととおり iPod アプリのデモが終わるとジョブスは、同じデモを少し前に内部関係者に見せた時に言われたという言葉を披露しました。

You had me at scrolling.
（最初のスクロールのところでもう虜になったよ）

またこの iPod アプリのデモにあたってジョブスは “You can touch your music” と言いました。その表現が、iPhone の本質をよく表していたと思います。パソコンのGUIが、ひとつのデスクトップを基盤として複数のウィンドウが開かれるという箱庭式のイディオムで構成されていたのに対し、iPhone のGUIは、（スプリングボードを操作の開始点としながらも）一度にひとつだけビューを全画面表示し、それを直接触って指先でずらしたり弾き飛ばしたりしながら表示を切り替えていく、ブラウザー式のイディオムで構成されていたのです。それは、過去のPDAやフィーチャーフォンが抱えていたスクリーンの狭さゆえの窮屈さを払拭する勢いを持っていました。

それまでのPDAやフィーチャーフォンは、小さなスクリーンにできるだけ多くの情報を表示し、それをスタイラスやハードウェアボタンを使って「ちまちまと」操作するものでした。

しかし iPhone は指で操作するという前提に立ち、表示要素をデスクトップGUIよりもむしろ大きくしたのです（参考: iPhone の当たり判定を検証した）。その結果、一度に表示される情報量は減り、ナビゲーションのための階層移動が増えましたが、その結果としてユーザーははじめてハンドヘルド機器のGUIを思い通りに直接操作できるようになったのです。それが正当化されるのは、素早い反応とスムーズなアニメーションがあったからです。この新しい操作性によってユーザーは iPhone を、これまでなかった利用価値を持つデバイスとして認識したのです。そしてそのフォームファクターは、様々なオンラインサービスの隆盛と相まって、パーソナルコンピューティングの概念をおそらく根本的に変えてしまったのです。

そして、iPhone のその独特のスクロールとナビゲーションのイディオムを構成する中心的なUI部品が、UITableView なのです。

UITableView

UITableView はiOSのUIフレームワークに含まれる代表的なクラスのひとつで、iOSアプリの開発者にとってはおなじみのものでしょう。これは画面上に一次元のリストを表示するための汎用的なUI部品です。

デスクトップのGUIや過去のPDA／フィーチャーフォンにも、もちろんリスト表示のためのUIはありました。しかしそれらは目的のコンテンツに到達する過程で課税的に表示せざるを得ないつまらない中間階層だったのです。ところが iPhone においては、テーブルビューはもっと大きな意味を持っていました。例えば、最初の iPhone にインストールされていた純正アプリのイメージをみると、これらはどれも UITableView で表現されているのです。

iPhone では指での操作が十分に行えるよう、全てのUI要素が大きくデザインされます。そのため（iPhone は当時のほとんどのスマートフォンよりも大きなスクリーンを持っていましたが）情報を段組みで二次元的にレイアウトするよりも、全てを単純な一次元リストにして画面をシンプルに保つことを選択したのです。これは二次元空間を自由に使って情報を提示してきたデスクトップGUIからすれば一種の低次元化ですが、片手で使える情報端末のマテリアルオネスティ（その物の本来的な性質に率直に従うこと）として肯定できるでしょう。iPhone の中でテーブルビューが多用されるのには、そのような正当性があるのです。

テーブルビューの視覚的な特徴としては、画面の端まで伸びたセルの罫線が挙げられます。これによってスクリーンが一次元のリストで占められていることが明示されます。またテーブルビューにはセクションをつくることができ、これは半透明の見出し行として表示されます。秀逸なのは、この見出し行は通常は他のセルとともにスクロールしますが、画面上端まで来るとそこに固定され、次のセクションの見出し行にぶつかるまで表示され続けることです。また画面の右端にはセクションを頭出しするためのインデックスを配置することもできます。このような細かな工夫が、スクロール時の視認性や操作性を向上させています。

多くの情報を一次元のリストで表現すると、その分画面は縦長になります。そのため、スクロールのしやすさは重要なデザイン要件となります。

UITableView のスムーズなスクロール機能を提供しているのは、UITableView のスーパークラスである UIScrollView です。

UIScrollView

指による直接操作では、それまでスクロールバーへのマウス操作やキーボードショートカットなどで行ってきた操作のアクセラレーションをどのようにするかが課題になります。

iPod は最初「1000曲をポケットに」というコンセプトで開発されました。このコンセプトを具現化するために必要だったのが、データの高速転送、大容量ストレージ、そして1000曲のリストから簡単に1曲を選べるインタラクションデザインです。これらの課題に対する回答として、高速転送には FireWire、ストレージには小型HDD、そして曲選択には1ストロークで無限にスクロールできるクリックホイールが採用されました。

iPhone のスクロールは、スクロールバーに対する間接的な操作ではなく、直接画面を指でなぞる方式です。その時、指を素早く弾くようにすると加速がつき、指を離してもしばらくスクロールし、そして徐々に止まります。この動きは慣性と摩擦という現実世界の物理法則を非常によく模しており、一度でもそのスクロール操作を行ってみれば誰もがすぐに学習し、自然すぎてそれが高度なテクノロジーの産物であることに気づかないほどです。

またスクロール終点のバウンス効果（少し行きすぎてから戻る視覚効果）も、単なる遊びの演出ではなく、現実世界のどこかで見たような動きによって仮想的物理にリアリティを与えながら、スクロールの終点を効果的に伝えるという意味があります。慣性スクロールでは指を離しても少しの間スクロールし続けて止まるので、その停止が仮想的な摩擦のためのものか、ビューが終点に来たためのものかを、バウンス効果によって自然に把握できるようになっているのです。ジョブスはデモの時にこれを「輪ゴムのような動き」と言いました。

Apple はインプットデバイスの操作性について古くから熱心に研究しており、例えばマウスの動きについてもよくチューニングしていることで知られています。マウスはユーザーがそれを動かす方向や速度を検知するものですが、Macのマウスではアクセラレーションがよく計算されており、ユーザーが動かす速度に応じて加速度が変化します。実際のマウスの移動距離をそのままポインターの動きに反映するのではなく、ポインターを遠くの場所に移動させようと速く動かせば大きく加速し、細かな要素に合わせようとゆっくり動かせば動きが小さくなるようにできています。このようなアクセラレーションには普段気づきませんが、急に Windows でマウスを使うと、遠くのものには届かず、近くのものは通り過ぎてしまうという不自由さを感じるのです（ただしユーザーはこのような道具の癖に適応していくので、普段 Windows を使っているユーザーはMacのマウスを使いにくいと感じる場合もあります）。

このように、GUIのインプットに関して Apple が追求するのは、「動かしたままに動く」ことではなく、「動かしたいように動く」ということです。

UIを「動かしたいように動く」ように実装するには、単にタッチ動作をイベントとしてプログラムで扱えるようにするだけでは不十分です。無数にデジタル化される入力値の中から、有効な閾値を持ってある部分を切り取り、ユーザーが意図した動作をジェスチャーとして正規化してオブジェクト化する必要があるのです。その閾値を決定するためには、膨大な試行錯誤が必要になります。

初期の iPhone の開発に携わったソフトウェアエンジニアによれば、様々なプロトタイプを作る中で、指で操作できるというだけでは直観的とは言えないと気づいたそうです。考えられるタッチ操作の中で、どのようなものが実世界の中の経験を反映できるかを、ソフトウェアチームは慎重に検討していきました。ジェスチャーと言っても、身体動作をアナログに反映して直接操作感を生むためのものと、単にコマンドとして抽象的な命令を入力するためのものがあります（参考: ジェスチャ操作の意義と課題）。

ジェスチャの中のいくつかは、ある種の直観的な明快さを持っていることがわかってきました。例えばピンチによるズームなどです。そこで、直観的な操作と説明に従う操作との境界線がどこにあるかを探ったのです。

例えばロック画面におけるロック解除の操作では、その目的とジェスチャに直接の関連がないので、いかにもスライドできそうなボタンと溝を用意し、”slide to unlock” という文言と、左から右へ流れるハイライトまで用意しています。このような説明的な表現は場面によっては必要とされましたが、すべてのジェスチャ可能な箇所に説明を加えることは当然ながら適切ではないでしょう。

iPhone のスムーズなスクロールを特徴づける慣性スクロールやバウンス効果は、UITableView のスーパークラスである UIScrollView の働きによってもたらされます。このスクロールビューが実現する「ビューを指でなぞってスクロールする」という操作イディオムは、その後のあらゆるタッチデバイスに求められる標準的な振る舞いになったのです。

Visual Basic のデザインや「ペルソナ手法」の考案者として知られるアラン・クーパーは、90年代に次のように言っていました。

すべてのイディオムは学習する必要があるが、良いイディオムは1回だけ学習すればよい。

iPhone のタッチUIにおけるスクロールやズームの操作イディオムは、まさにこれに当てはまるでしょう。

また、テーブルビューではスクロールをスムーズにするために、セルの再利用機構が備わっています。これはテーブル表示時にリストの全行分のセルをすべて生成するのではなく、最初に画面に表示される行数分だけを生成し、スクロールによって画面から出ていったセルを次に画面に入ってくるセルに再利用するというものです。表示部品としてのセルは再利用し、文字や画像といった内容物だけを差し替えるのです。たくさんのビューを一度に生成してメモリーに保持することは大きなコストを伴うので、長大なリストを表示する際にセルが再利用されることは、メモリーの節約と表示の高速化に寄与します。この機構によって、特に各行の高さやレイアウトが統一されている場合、テーブルが何千行あってもほとんど重たくならずにスクロールできるのです。普段テーブルをスクロールしている時には意識できませんが、実は画面の上端に出ていったセルが裏で下端に回ってまた画面に現れているのです（逆方向の場合も同様）。

このように有益な機構をAPIを通じてサードパーティアプリが簡単に使えるのは、ネイティブアプリの大きなアドバンテージです。例えばウェブブラウザーやウェブビュー（ウェブブラウザー機能を提供するUI部品）の中で数千行ものリストを表示しようとすると、普通の実装では表示やスクロールがかなり重くなるでしょう。テーブルビューの軽快さは、ブラウザベースアプリに対してネイティブアプリがもつ利点の大きな部分を占めていると思います。

Apple もスムーズなスクロールこそがiOSの強みであると知っているので、この再利用機構については近年になっても改良され続けています。例えば WWDC 2016 の “What’s New in UICollectionView in iOS 10” というセッションでは、iOS 10 でコレクションビューおよびテーブルビューにおけるセルの再利用や先読み機構がどのように新しくなり、それによりスクロールがどれだけスムーズになったかを説明しています。また WWDC 2018 の “What’s New in Cocoa Touch” というセッションでは、iOS 12 においてテーブルビューのスクロールがさらに改善されたことを説明しており、バックグラウンドでの先読み処理がインテリジェントにスケジューリングされる仕様や、システムアーキテクチャの上層にあるUIコンポーネントの状況を低層のCPUパフォーマンスコントローラーに伝達して負荷のかかるタイミングを予測しながらランプアップさせる工夫などが紹介されています。

これらはいずれも100分の1秒程度の描画フレームレートにどうやって処理を間に合わせるかという話であり、スムーズなスクロールを実現するために Apple の開発者が多大な努力をして極めて細かなチューニングをかけていることがわかります。そしてそのロジックをサードパーティ開発者にわざわざ説明し、新しい仕組みへの理解とコミットを促しているのです。

初期 iPhone のソフトウェア開発を率いていたスコット・フォーストールはこう言っていたといいます。

開発者が正しいことをすれば、ユーザーはそれを意識すらしなくてすむ。

余談ですが、WWDC のいくつものセッションで、Apple のエンジニアがプログラムの実装方法を指南する際によく「〜このようにすればUIがロックされずにすみます」という言い方をします。それはこのような意味です。iOSや macOS のプログラムではマルチスレッドによって同時に複数の処理を実行できますが、UIの更新は常にメインスレッドで行われます。そのため重たい処理をメインスレッドで行うと、それが終わるまでUIが操作を受け付けなくなってしまうのです。操作性を向上させるためには、プログラマーは多少面倒であっても、画面への即時反映が必要ない処理をバックグラウンドスレッドに回すなど、UIがロックされないように気をつけるべきなのです。しかし Apple のエンジニアは「UIがロックされずにすみます」と言うだけで、それにどのような意味があるのかをわざわざ説明したりしません。UIはユーザーが常にコントロールできる状態であるべきだというデザイン原則を、サードパーティ開発者の全員が当たり前のように認識していることを前提に話をしているのです。この、すべてのテクノロジーは最終的にユーザーエクスペリエンスのためにあり、開発者はそこへ積極的にコミットすべきだという価値観が、コミュニティの基盤にあるのです。そのことがとても素晴らしく、また独特なものであるようにいつも感じます。

iPhone のスクロール操作がそれまでのデスクトップやPDAなどのGUIと違っていたもうひとつの点として、スクロールの方向に関するものが挙げられます。それまでの一般的なスクロール操作では、（縦方向スクロールの場合）スクロールバーにある矢印ボタンやハードウェア上の十字キーにおいて「下向き矢印」を押すと、表示コンテンツは上方向にずれていきます。同様に、マウスポインターやスタイラスペンでスクロールバー上のつまみ（スクロールボックス、スクロールサム、スクローラーなどと呼ばれる）を下に向かってドラッグすると、表示コンテンツは上方向にずれていきます。1980年代初頭に Apple Lisa のグラフィック描画エンジンを開発したビル・アトキンソンは、スクロールボタンの矢印の向きと配置位置、そしてそれを押した時にコンテンツが移動する方向の対応について様々な組み合わせをテストしたといいます。その結果、ユーザーはスクリーンの下部に隠れている残りのコンテンツを見たい場合（つまりドキュメントを読み進める場合）にはスクリーン下部にアプローチすることがわかり、上記のような実装に落ち着いたそうです（Oral History of Andy Hertzfeld and Bill Atkinson）。しかし iPhone では、一般的なスクロールバーの方向性とは逆に、コンテンツを上に向かってずらすためには指も上に向かって動かすようになっているのです。

それまでのスクロール操作が、スクロールバーという部品に対する働きかけ、もしくは見たいコンテンツがある方向の間接的な指示であったのに対し、iPhone のスクロールは、コンテンツ自体を自分の指で直接ずらす行為として再定義されたのです。これはスクロールというものに対する我々のメンタルモデルを大きく変えるものでしたが、iPhone を触って一度でもその操作をしてみれば、それがとても自然な振る舞いであることがわかるのです。

コンテンツを直接ずらすという操作は、Google Maps のように面積の大きなグラフィックコンテンツを閲覧するための方法としては用いられていましたし、MacPaint や Photoshop などのグラフィック作成ソフトにおいても古くから「手のひらツール」として存在していました。また FM TOWNS の MopTerm などではマウスのフリック操作でコンテンツを慣性スクロールさせる、通称「猫の手スクロール」が実装されていました。この種の直接スクロール操作が、タッチUIとの親和性をもって、iPhone では全面的に採用されたのです。

Apple はその後 Mac OS X 10.7 Lion で、トラックパッドやマウスでのスクロールジェスチャの方向性を「ナチュラル」スクロールとしてそれまでのものから反転しました。同時にスクロールバーの表示はオプション扱いとなり、慣性スクロールも取り入れられ、デスクトップにおいてもコンテンツを直接ずらすというタッチUIのアナロジーが採用されはじめました。これには批判も多くあったようですが、Apple は自社のトラックパッドやマウスをマルチタッチUIの一環と位置付け、ユーザーにメンタルモデルの変更を促したのです。

UINavigationController

iPhone における典型的なテーブルビューの用いられ方は、iPod アプリのデモで示されたとおり、それがドリルダウンナビゲーションの中で連続的に用いられることです。ひとつひとつの表示要素が大きく、一画面における情報量が少ない iPhone では、ナビゲーションの階層は深くなる傾向にあります。2008年に公開された iPhone のネイティブアプリ用ガイドラインには、モバイルデバイスにおいてはデスクトップアプリのように複数の階層を同時に見せるのではなく、情報の階層ごとに画面を分割してナビゲーションさせるように書かれています。

情報システムにおける選択操作では、一度に見せる選択肢を増やして階層を減らすか、選択肢を減らして階層を増やすか、UIデザイナーは常に考えて判断しなければいけません。iPhone では、階層を増やしてでも一画面をシンプルにするようにガイドラインが指示しているのです。階層が増えたとしても、ナビゲーションがスムーズに動けば、ユーザーの認知的な負荷が軽減され、操作が増えること以上のメリットがあるという考え方です。

ナビゲーションの過程でテーブルビューを連続的に表示するのは、UINavigationController クラスの役割です。ナビゲーションコントローラーは、ナビゲーションバーとツールバー以外に目に見える部品を持ちませんが、選択操作に応じて次々と画面をスライドさせながら遷移する振る舞いを提供します。新しく表示された画面は内部のスタックに追加されます。ナビゲーションバーの左端にある「戻るボタン」を押すと、現在の画面が内部スタックから取り除かれ、ひとつ前の画面に戻ります。このヒストリー式の機構は一般的なウェブブラウザーと似ています。一度表示されてスタックに追加された画面はメモリーに保持されているので、ユーザーがそこへ戻った時には高速に表示されます（その際に表示内容を更新するかどうかはプログラムで制御できます）。

ドリルダウンに伴って次の画面がスクリーン右からスライドして現れる表現は iPod からの流用ですが、さらにその元になっているのはデスクトップアプリの iTunes のカラム表示です。iTunes のカラム表示では、ジャンル、アーティスト、アルバムなどを順番に選択しながら曲のリストをフィルタリングできます。これはユーザーにとっては情報を階層的にドリルダウンしているように感じられますが、内部ではファセット検索（各項目に複数の属性タグがつけられており、任意の組み合わせに合致する項目を抽出していく検索方法）が実行されています。

このカラムナビゲーションを、一度に1カラムだけ見せるようにしたのが iPod のUIです。また、iTunes や iPod の後に発表された Mac OS X では、Finder のオプションとしてカラム表示が用意されており、横スクロールを伴いながらフォルダをドリルダウンして目的のファイルを探せるようになっています。このカラム式ファイルブラウザーは Mac OS X の前身である NeXTSTEP の Workspace Manager から継承されたものですが、この形式のブラウザーはミラーカラムとも呼ばれ、1980年にエール大学の Mark S. Miller によって作られたと言われています。そしてさらにその源流にあると思われるのが、1970年代にアラン・ケイなどを中心に Xerox PARC で開発された最初期のGUI／オブジェクト指向開発環境である Smalltalk のシステムブラウザーです。

NeXTSTEP に採用された開発言語の Objective-C は、Smalltalk に強く影響を受けていると言われます。その Objective-C は Mac OS X と iOS にも使われています。そう考えると、iPhone は Smalltalk から多くのコンセプトを受け継いでいるのです。

この水平方向にドリルダウンしていくというイディオム（テーブル行の右端にはシェブロンが表示される）は、階層移動を視覚的に表現する上で非常に効果的ですが、遷移の方向に応じて画面がスライドすることに加えて秀逸なのは、ヘッダーのタイトル表示部分の変化です。ドリルダウン時には、画面上部のナビゲーションバーは移動せず、その下のビュー（テーブルビューなど）の部分が右から左にスライドします。ナビゲーションバーは移動したり明滅したりしないので、同じ入れ物の中で場面が転換しているという感じが出ます。ナビゲーションバーは移動しませんが、その中央にあるタイトルのラベルは新しく表示された画面のタイトルに切り替わります。同時に、直前に見ていた画面のタイトルが、左端の戻るボタンのラベルになります。画面がスライドしながら遷移し、古いタイトルが戻るボタンのラベルになり、新しい画面のタイトルが中央に表示される。戻るボタンを押した場合は、逆のトランジションによって前の画面に戻る。この一連のシークエンスがスムーズなアニメーションで示されるのです。これによりユーザーは小さな画面の中で仮想的な空間を一貫してイメージでき、ナビゲーションのメンタルモデルをはっきりと持つことができるのです。

ナビゲーションコントローラーは必ずしも情報の階層構造を表現するだけのものではありません。ウェブブラウザーのように、どのようなナビゲーション構造であっても画面の変遷として司ることができます。ですから例えば Twitter や Facebook アプリのように、ハイパーリンクを延々と辿りながら次々とコンテンツリストを読み込んでいくような使い方もできます。

この初期の Facebook アプリの画面はテーブルビューでできています（おそらく）。ここで特徴的なのは、このリストが必ずしもコンテンツに到達するまでの中間階層ではないということです。Facebook においてはこのリスト自体が主要なコンテンツになっています。このような表現を取れることが、実はテーブルビューにおけるもうひとつの、そして最大の特徴なのです。

View-Based

リスト表示のためのコントロールは、ほとんどのGUIフレームワークに備わっているでしょう。しかしそれらのほとんどは、一項目を一行で表し、複数カラムを持ったいわゆるグリッドテーブルを表示するものです。例えば Mac のUIフレームワークに含まれるリスト表示用の NSTableView クラスは、このようなUIに用いられます。

グリッドテーブルは縦横軸でデータを表示するもので、コンピュータ画面でDBから取り出した情報を一覧表示する時の基本的な表現方法です。しかし小さなスクリーンではどうしても横幅が制限されるので、列を減らしたり、文字を小さくせざるを得ません。しかしそうするとデータの一覧という意義がスポイルされてしまいます。例えば過去のPDAでは、リスト表示は次のような狭苦しい表現になっていました。

ブラウザーベースのウェブアプリケーションにおいても、（ウィンドウ幅が可変なので）多くの情報を一度に表示させたい業務システムなどではテーブルの横幅が常に課題となります。列を減らすべきか、それとも横スクロールさせるか、あるいは文字を小さくしたりトランケート（末尾を省略）させるか。この問題に対する、シンプルかつ決定的な回答がテーブルビューにはあったのです。それは、テーブルを単一カラムにして、そのかわりにセルの中を複数行で自由にレイアウトできるようにすることでした。

テーブルをシングルカラムにしてセルの中に複数行の項目を表示するという表現は、限られた幅のスペースにデータの一覧を表示するために有効なので、 Newton OS など90年代のPDAでも一部では採用されていました。Windows Mobile や Symbian OS にもそのような表現はありましたし、デスクトップでも MS Outlook などで2000年代前半には見かけるようになっていました。おそらくウルトラブックなど小型のPCではスクリーンの縦幅が非常に狭いワイドスクリーンが多くなり、アプリケーションのペインを横方向に並べる上でテーブル幅を限定する必要があったためでしょう。ただしそれらは一覧の列を縦に並べてみた程度の使われ方にとどまっていたように思います。iPhone ではこのシングルカラムの考え方をすべてのリスト表示に対して全面的に取り込み、コンテンツ表示方法のひとつとして、セルにもっと自由な表現を持たせるようになったのです。

テーブルビューのこの仕様により、iPhone の標準的なイディオムからグリッドテーブルは無くなりました。そしてそれまで選択操作のための中間階層に過ぎなかったテーブルが、コンテンツを自由に連ねて表示するための新しいイディオムとなったのです。ひとつひとつのセルが縦に広がればその分スクロールは増えますが、テーブルビューのスクロールは高速かつ思いどおりに操作できるので、課題はカバーされます。この割り切りが iPhone を情報表示デバイスとして有効にしたと言えるでしょう。

リスト内のセルを自由にレイアウトできるということは、逆に言えば、複数のコンテンツを連ねて表示できるということです。別の言い方をすれば、レイアウトのテンプレートとして一覧と詳細を区別しないということです。この発想は、パソコンの画面では MovableType や WordPress などのブログサービスでやはり2000年代前半に見かけるようになっていました。ユーザーはコンテンツを次々と閲覧するためにわざわざドリルダウンしなくても良いというわけです。このように iPhone のテーブルビューは、デバイスの形状的制約への対応やコンテンツ閲覧の合理化といったいくつかのベクトルをうまく集約したのです。

セルのレイアウトの自由度は、UIデザイナーにとって表現の可能性を広げ、またコンテンツの性質に応じて柔軟にテンプレートの情報量を調節できるため有意義です。そしてスマートフォンのキラーアプリとなった Twitter や Facebook などのタイムライン表現ともマッチして、非常に多くのアプリがテーブルビューを中心にコンテンツ表示を演出するようになりました。

そしてこのシングルカラムの表現は、後にMacのUIフレームワークにも取り入れられました（Mac OS X 10.7 Lion）。Macの NSTableVIew クラスに加えられたシングルカラムのオプションは、View-Based テーブルと呼ばれました（従来の一行形式は Cell-based）。例えばそれ以前の Apple Mail では、グリッド式のテーブルの下に詳細ペインがレイアウトされる形式でしたが、Mac OS X Lion の Mail ではシングルカラムのリストと詳細表示ペインを横並びにした形式になりました。

Detail

もうひとつテーブルビューが特徴的だったのは、それが詳細画面にも使われたことです。情報システムの多くは一覧と詳細（Master-Detail）で構成されます。初期のデスクトップアプリケーション、クラサバシステム、PDAなどでは、一覧から項目を選ぶと、別ウィンドウで詳細画面が表示されるものがほとんどでした。一覧に戻るためにはそのウィンドウを閉じるのです。このような立体的な情報の重なりを表現することは、シングルウィンドウの全画面表示を基本としたハンドヘルドデバイスには向いていません。狭い画面の中でウィンドウが重なるとユーザーは現在の状況を見失いやすくなるからです。

そこで iPhone では、一覧から詳細への遷移も水平スライド式のナビゲーションに含めました。テーブルビューが全ての情報表示形態を請け負い、一覧から詳細への流れをナビゲーションコントローラーの単一的な遷移モデルで表現したのです。

シングルカラムを基本とした iPhone の画面では、情報は上から下へ一次元的にレイアウトされます。そうであれば、セルの内容を自由にレイアウトしながら縦に並べることで様々な情報を表現できるはずです。つまりテーブルビューをコンテンツ表示にも用いることができるというわけです（メディアプレーヤーや地図などのグラフィックコンテンツを除いて）。

例えばMacの環境設定における一覧から詳細への遷移は、このようにひとつのウィンドウ内で全く違うレイアウトの画面に切り替わるかたちになっています。

また、iPhone 以前のPDAである PalmPilot の設定画面では、メニューによって大項目を切り替えるようになっており、デスクトップGUIの作法をそのままミニチュアライズしているようです。値の選択も、ひとつひとつ小さなモーダルダイアログ（あるいはドロップダウンメニュー）を出すようになっています。

いずれも詳細画面は二次元的なレイアウトとなっていて、レイアウトの自由度は高いものの、PDAでは画面の大きさが制約となって限定的な要素しか表示できない様子が伺えます（要素を限定すること自体は良いことですが）。これらに対して iPhone の設定アプリでは、一覧と詳細が同じレイアウトスキームの中に融合され、統一的に一次元リストを使って情報と機能を提示します。

iPhone の設定アプリの中では、ナビゲーションコントローラーを用いたメニュー階層を辿ると各設定画面に到達します。そこではテーブルビューを使ってパラメーター項目が並べられています。さらに iPhone では、パラメーターの値を選択するための選択肢までもが、テーブルビューで表現されています。このように徹底してテーブルビューを使って、システム全体のイディオムをシンプルにしているのです。

これにより、詳細画面から派生する別のリストを表示したい場合（例えば、顧客一覧 → 顧客詳細 → 会社詳細 → 商品一覧 → 商品詳細…）など、一覧と詳細を連続的に遷移したい場合でも、一連のナビゲーションとして情報を自然に表現することができます。ナビゲーションは内部スタックとして線形に蓄積されますが、情報構造は必ずしも線形になっている必要はなく、テンプレートを再帰的に利用しながらどこまでも情報探索を進めていくことができます。

ここで興味深いのは、iPhone のUIフレームワークでは、それまでGUIのフォームコントロールとして標準的だったラジオボタン、チェックボックス、ドロップダウンメニューなどが排除されていることです（ウェブビュー内を除く）。ラジオボタンは、テーブルビューでの行選択（およびチェックマークの表示）による単数選択操作に置き換えられました。チェックボックスは UISwitch というコントロールに置き換えられました。ドロップダウンメニューはラジオボタンと同様の行選択、あるいは UIPickerView というコントロールに置き換えられました。また、テーブルビューの行自体をボタンのように用いる表現も許容されています。これらはいずれも、選択操作を指で十分に行えること、一つの画面で複雑な操作をするよりも画面遷移させること、そして狭い画面の中でも多くの選択肢から無理なく選択操作ができることなどが考慮されているのです。

なお、テーブルビューには2種類の表示形式があります。通常の「Plain」と、グループごとの見出しを持った「Grouped」です。機能的な違いはありませんが、Grouped スタイルのテーブルビューでは、セクションごとにセルがグループ化されて表示されます（初期のiOSでは現在の Grouped スタイルよりもグループの境界が強調されていました）。Grouped スタイルのテーブルビューを使えば、情報を視覚的にグルーピングしてレイアウトすることができます。詳細画面は通常、データベースからの検索結果としてレコード群を動的にリストするのではなく、決まった数の項目を静的にレイアウトすることになるので、これをテーブルビューで作る際には、Grouped スタイルを用いることが多いのです（上の設定アプリの画面は Grouped スタイルのテーブルビュー）。

Fluid Interfaces

ここまで説明したとおり、iPhone のUI全体の中で、テーブルビューというひとつのクラスが次のような役割を担っています。

• ドリルダウンされる階層の再帰的なテンプレート
• データベースやサーバーから取得されたデータのリスト表示
• リスト形式のコンテンツ表示
• 詳細形式のコンテンツ表示
• 選択肢の表示
• ラジオボタン、チェックボックス、ドロップダウンメニュー、ボタンなどの代替

テーブルビューはこのように多くの役割を担うので、様々な方法で実装できるようになっています。動的なデータを流し込んだり、静的なコンテンツを表示したり、ひとつひとつのセル（行）の高さやレイアウトを変えたり、インデントをつけたりなどです。

また、UISearchController による検索機能、UIRefreshControl による「引っ張り更新」の追加、セルのスワイプでアクションボタンを表示したり、3Dタッチで Peek and Pop を発動したり、ドラッグ＆ドロップでセルを移動できるようにするなど、初期の iPhone にはなかった機能がその後次々と追加されています。

多くの表現形態がある分、実装する際にはオプションの指定や条件分岐が多くなります。データの取り回しに必要なコンパニオンオブジェクト（delegate、 data source、prefetch data source など）も多く、iOSアプリ開発の初学者にはとっつきにくいクラスでもあります。しかしこのクラスこそが iPhone というUIイディオムの中心にあり、またスマートフォンにおける集合的／階層的情報提示方法のスタンダードを擁立したものであるという意識を持って、積極的にその使い方を工夫していくべきでしょう。

ところで、先月開催された Apple のデベロッパー向けカンファレンス WWDC18 において、”Designing Fluid Interfaces” というセッションがありました。WWDC では毎年いくつかのデザイン系セッションがありますが、このセッションにはこれまでで最も強く感銘を受けました。本当に、UIデザインに関わる人には必見の内容と言えます。

iPhone X を使っている方は気づいていると思いますが、iPhone X のUIはそれまでの機種とは少し違う動きをします。アプリの起動や切り替え時など、他機種と基本的には同じ操作でありながら、画面の反応のしかたが少し異なります。トランジション時のフィードバックが「決まった動きをするアニメーション」ではなく「指の動きについてくるような弾力的／有機的な反応」になっているのです。

このセッションでは、その iPhone X 向けに実装されたインタラクションを「流動的なジェスチャインターフェース」という表現で詳しく説明しています。iPhone の操作がなぜ気持ち良いのかという話題は、これまで多くのUI研究者によって繰り返されてきましたが、このセッションが重要なのは、タッチUIについて Apple がこれまで追求してきたこと、あるいは結果的にもたらされたものの総合的な意味について、Apple 自身がはじめて正面から言語化している点です。

このセッションで Apple のインターフェースデザインチームは、iPhone というデバイスの道具的存在性／手元存在性といった哲学的なパースペクティブと、それを生活の中に実装していくテクノロジーの理論を、多くの具体的な例とともにはっきりと示しています。

例えば iPhone という道具を我々の認知の拡張として適合させるために、次のようなデザインが重要だとしています。

• 即座の反応と、絶え間ない方向転換への適応
• 空間的な一貫性の保持
• ジェスチャの方向に関する暗示
• 軽い操作と、増幅された出力
• 柔らかい限界とトランジション
• スムーズでダイナミックな振る舞い

前述のとおり、現実世界の物理的な動きを真似た表現は iPhone の初期から試みられてきましたが、Apple はその考えをさらに進めて、人と道具と世界の新しい関係性をUIによって再モデリングしているように感じます。Google や Microsoft といったOSベンダーも自社のGUIシステムについて洗練されたコンセプトやテンプレートを公開していますが、このセッションを見た後では、それらが表面的なものに思えてきます。

当初 iPhone にくらべて反応がぎこちないと言われていた Android のUIもこの数年でだいぶスムーズに動くようになりましたが、タッチUIというものに対する考察の深さや試行錯誤の量は、まだ Apple が数年先を行っている印象を受けました。逆にその細部までのこだわりがマニアックすぎて、他のベンダーはそこに有益さを見出さないのではないかと思われるほどです。

今回は UITableView を中心に初期 iPhone がもたらした新しいUIイディオムの特性について書きましたが、Fluid Interface の実践がその直接的な延長線上にあることは明らかでしょう。これからも私たちは、この先の10年で起きるツールやサービスの進化をよく観察し、その意味を言語化し、そして自らもその発展に関わっていきたいと考えています。