ソシオメディアの上野さんの記事。
丁寧に細部まで解説、考察されている非常に良い記事なので、UIデザイン関係者は必読。
この記事を読んで、当時FlasherとしてiPhone登場時にUIに感じたFlashの影響と、その経緯について書いておこうと思います。あまり懐古的にならない、将来につながる内容にしたいと思いますが、年齢的に無理かもしれません。ご了承ください。
Flashとは
Flashってなに？という世代も増えているかもしれないので、簡単に説明・・・。
Flashは1996年に開発されたFutureSplash Animatorを起源として、Macromedia、Adobeへと引き継がれたマルチメディアオーサリングソフトとその規格。（詳しくはWikipediaを参照 > Adobe Flash – Wikipedia）2000年から2010年までWeb上を席巻し、様々な歴史的なWebコンテンツ制作に利用されていましたが、2010年のAppleによるiOSのFlashサポート終了を期に衰退し、今ではWebコンテンツ制作ツールとしてはほぼ死滅した状況です。（そしてAdobeのFlash Playerのサポートも2020年で終了）
わたしが最初にFlashに触れたのはFlash2か3からなので1997～8年ごろになるかと思いますが、当時は通信回線も56Kbpsとか貧弱な環境だったため、Web上で展開するアニメGIFの代替となる軽量のアニメーション作成ツールという感じで、ベクターで作成したアニメーションに音と簡単なインタラクションをつけたものが軽量サイズでリリースできることがメリットでした。この時代の著名なサイトはEye4You（www.eye4u.com）とか、よしのやのゴノレゴシリーズあたりかなと思います。
Flash4あたりからインタラクション、外部データ読み込みなどの機能が強化され、一気にサイトのパッケージ化、アプリケーション展開が加速していくことになりますが、この辺はやはり中村勇吾氏のサイト”MONO*crafts 2.0″の影響が大きいと思います。（もう公開されていないけれど・・・）
こうして、Flashはアニメーションツールと、サイト構築・アプリケーションツールという2つの特性を持って進化していくことになります。
FlashにおけるUI
サイト構築・アプリケーションツールとしてのFlashが活用され始めたFlash4の頃は、簡単なマウスイベントと関数しか存在せず、UIコンポーネント、ライブラリなどという概念も存在しませんでした。このため、HTMLの標準要素であるボタン、プルダウン、チェックボックス、ブラウザ機能であるスクロールバー、三角関数まで自作が必要な状況でした。
つまり、サイトをフルFlashで構築する場合は、まずOSのUI、HTMLのUIをベースとした同等のパーツをフルスクラッチで作成するプロセスが必然的に発生していた訳ですが、このプロセスはそれまでタグを記述するだけだったHTML汎用パーツに対して、ロジック解析・コンセプト理解など、深い洞察と改善策を導く良い学習プロセスとして作用しました。それにより、それまで無条件に受容せざるを得なかった既存のWeb、アプリケーション（特にVBアプリ）の表現、UIに対する疑念、不満の解消を強く期待させたように思います。
また、当時はJS、CSSでできる視覚的拡張も非常に限定的（特にForm系）だったこと、Flashがバイナリ出力されることによるソースのブラックボックス化がHTML原理主義的な評価の対象外になったこと、Playerというプラグインを介することでOS依存の挙動差が少なくなったことなどの影響も大きかったかと思います。
つまり、「気持ち良い」「面白い」「楽しい」「かっこいい」「斬新な」という感覚的指標が大きな評価ポイントになっていたこと、そして、様々な既存呪縛からの開放によりクリエイティブへ労力を集中できる状態が揃っていました。
このことが、UIに対してFlashが積極的に独自拡張、独自解釈を適用した理由だろうと思います。
UIの拡張
自由にUIを作成できる（しなくてはならない）状態、且つ、評価ポイントが感覚的なものになった状態において、Flashがアニメーションツールとしての側面も持っていたことによる相性の良さもあり、制作者の記憶の中にあった映画、アニメ、ゲームがUIのアウトプットに与えた影響は非常に大きかったかと思います。
個人によって差はありますが、2001年宇宙の旅(1968)、マクロス（1982）、攻殻機動隊（1995）、マトリックス(1999）、マイノリティ・リポート(2002)、オウガバトル(1993）、フロントミッション（1995）、カウボーイビバップ(1998）、エヴァンゲリオン（1995）などなど、制作者の脳内に記憶されていた表現とUIが、一気に実際に利用できるものとしてリリースされていきました。
黎明期はソリッドでエッジの効いたUIが多かった印象がありますが、当時の音楽シーンの流行（Prodigy、Chemical Brothers、Fatboy slim、Squarepusherなど）の影響も多分にあったのでは無いかと勝手に思っています。
斬新なボタンインタラクション、ダイアログパターン、スクロールバーなどがリリースされ、それにインスピレーションを受けたものがリリースされるという加速度的なサイクルが発生し、コンテンツと同等にUIも評価の対象になっていました。その頃はTouchデバイスは普及していなかったので、PCでのマウスIFでのスクロールボタンクリック、ホイールスクロール、D&Dへの対応でしたが、慣性スクロール、境界バウンスもかなり早い時期から実装されたインタラクションだったはずです。また、スクロールバーも様々なパターンが試され、iOSのタイプもFlashで試行されていた記憶があります。（ブラウザのスクロールバーを完全に再現するコストが高いという問題もあったとは思うけれど・・・）
また、VBアプリ代替や、WEB上のRIA展開の案件も増加したことにより情報コンテクストを失わないダイアログパターンなど、実用的な情報認知のアプローチを取り入れたUIの試行も増加していきました。（Flexリリース後にRIA系は汎用ライブラリを用いたVB的な方向に進んで行きましたが・・・）
一方、Touch UIに関してはFlash AIRでキオスク端末展開が行われていましたが、当時はディスプレイのTouch認識精度も低く、多点タッチできるものも少なかったため、FlashでTouch UIに特化した試行は多くなかった印象があります。Touch領域の最適サイズに関しても当時のTouchディスプレイ解像度が低かった（Nintendo 64やSTBも640×480だった）こともあり、意図せずサイズの大きなUIになっていた印象です・・・?。どちらかというと、Touch UIよりもカメラ入力による画像認識をトリガーとしたインタラクションの方が盛んだったかもしれません。
ちょっと話が発散しましたが、iPhoneリリース時には”UISwitch”、”UIDatePicker”あたりのUIは興味を持ちましたが、それ以外のUIの多くは比較的馴染みがあった記憶があります。どちらかというとTouch操作がもたらす操作性と直感性が想像以上で衝撃を受けた記憶があります。
トランジションによる気持ちよさの追求
少し細かい話になりますが、Flashにおけるトランジションの気持ちよさへの追求についても書いておきます。
Flashはアニメーションツールとしてタイムライン上で座標、形状、色を変化させる機能があり、Flash黎明期はボタンインタラクションなどはこのアニメーションを用いていました。しかしこの方法は固定モーションのため、インタラクションとしての柔軟性に限界がありました。そのため変形、変色などのトランジションに対して演算処理を行う方向へと進化していきました。
これはUIに対してというよりはコンテンツ内の物理シミュレーション的な追求と並行で進化していた部分があり、はじまりはコンテンツとしての数値演算的なアプローチだろうと思います。原始的な例ですが、目的のx座標に対して減速しながら移動していく動きだと以下のような式になります。
obj.x += ( toX - obj.x ) / 10
これに係数、関数などを組み合わせて色々な動きを表現しましたが、この方法は柔軟にインタラクションする半面、浮動小数点、結果が収束しないことなどで演算負荷が増加し、気持ち良いレスポンスができなくなるリスクがありました。このためイージング関数を用いたトランジションが主流になっていきます。Robert Penner's Easing Functions などがよく利用されていたライブラリになりますが、Sin、Quint、Cubic、Quart、Bounce、Elastic・・・、ベジェ指定など、様々なトランジションの中から、その場面で気持ちの良いタイプ、適用先（座標や色）、反応時間のスタディを繰り返し、気持ちよさを追求していました。
また、適用タイミングについても整合性というよりは体感的な部分に重きを置いた調整が多かったように思います。分かりやすいところだとmouseOver時のイージングとmouseOut時のイージングの気持ちよさの視点の違い、フェードインは透明度0スタートでなくとも違和感が少ない場合がある、スライドインは画面外からでなく、ある程度の移動を認識できれば相関関係を認知できるなど、明確な理論が持っていたわけではありませんが、気持ちよさに関係する様々なパラメータの最適化の試行結果により、色々なノウハウが蓄積、共有されていったように思います。
このあたりの「トランジションの気持ちよさ」は、現在のTouch UIに共通の要素、思考を強く感じますが、現在そこまで細かく設定、調整できるのかは良くわかりません。
余談ですが、UIに対してはユーザビリティ的な面も考慮されていましたが、アクセシビリティ面はFlashでは優先度がかなり低く設定されていた様に思います。（Flash自体がそのへんの機能が少なかったということもあるが・・・）
気持ちよさの追求
前述のトランジションも含めて、操作に対して気持ちよさ感じる要因は「腑に落ちる、意味がわかる」「応答・反応が早い」「スムーズである」といったところが主なところになりますが、それらを確保するために様々な試行がFlashでも行われていました。主要なところだと、
- FPS（1秒間のフレーム再生数）の調整（細やかな動きを表現するためにfpsの調整。大体60fpsぐらいが相場だが、微細な動きを表現したい場合は120fpsなど、負荷処理と最適化調整）
- ビットマップによる描画負荷軽減（大量のベクターデータを移動させると描画負荷が増大してスムーズに動かなくなるため、ベクターデータをFlash内部でビットマップ化して描画負荷を軽減させてスムーズな動きを確保。後日プロパティとして簡単に制御できるようになった、もっと後にはGPUが使えるようになった）
- インスタンス数の最適化による負荷軽減（上野さんの記事でも触れているセルの再利用機構も早い段階でFlashでは課題としてiOSの対応と同じ形で対応されていました。これはリストのスクロールだけでなく、ループ移動する画像などにも適用されましたが、画面サイズに応じた必要最小限のインスタンスだけを動的生成し、その中身を動的に入れ替えていくことで、メモリ消費と描画負荷を軽減。この対応はリストアイテムだけでなく、汎用ダイアログなど流用性の高いオブジェクトにも適用されることが多かった）
- ガベージコレクションによる負荷軽減（メモリにゴミが残りスムーズに動かなくなる場合がある場合はガベージコレクション（GC）で対応。ただしGC処理負荷が高いため、発動は気持ちよさを阻害しないタイミングになるように調整）
- 読み込み分散（コンテンツや機能の多い場合は別ファイルに分けて、個別読み込みにして初期Loading時間を短縮。また、外部ファイル読み込み時は処理負荷が上がるため、気持ちよさを阻害しないタイミングを調整）
これらの知見がiOSのUI設計に影響を与えたかは正直わかりませんが、iOS UIに関する情報や発表を見ていると、気持ちよさを追求していくと類似した課題と対応が必要になることが伺えます。この辺の課題理解と解決プロセスの追求を体験できる（できた）ことは、色々とUIのロジックを理解する上で勉強になる（なった）気がします。（老害的発言）
レスポンシブ的思考
マルチデバイス対応のロジックにもFlashが与えた知見は多くあるように思います。
現在ではHTMLでの画面フィット対応は見慣れたものになっていますが、当時は制約が多かった記憶があります。その状況においてFlashは画面フィット表示機能を提供しました。画面フィット表示が与える画面制圧力の強さは非常に重要視され、多くのFlashサイトでフィット表示が採用されました。しかしHTMLの様に縦積みレイアウトというレイアウトの基本制約がないFlashにおいて、変形領域内での要素の動的レイアウトは、それまで経験ない領域だったはずです。特に初期Flashはマウスホイールイベントが存在しなかったため、スクロールを極力避けるレイアウト、UIが選択された傾向もあり、スクロールを極力発生させない形でのレイアウトのレスポンシブ制御パターンとUIロジックが多く試行されていました。
その試行の中にUITableViewに似た、プルダウン拡張パターンのUIが存在していた記憶があります（自分でも作成した記憶がある）。これは固定表示領域内で情報の階層化による選択肢数を抑えることでスクロールの発生とメモリ浪費を抑えるという思想だと思いますが、子要素がスライド展開していく挙動はUITableViewとほぼ同じものです。利用場面としては地域選択、商品カテゴリ選択などドリルダウンUIとしての利用が多かったように思いますが、iOSと異なり全画面展開による単機能の提供だったわけでは無いので、上野さんの考察からずれる部分があるかもしれません。（フィーチャフォンアプリFlashの中にもUITableViewUI似たものがあった記憶がありますが、こちらはマルチステップダイアログ的な位置づけで親子関係は存在していなかったかもしれません）
また、フルFlashサイトにおけるページ遷移処理にも似た思考のトランジションパターンが存在していました。
現在ではAjaxで同様の対応も可能になりましたが、当時のFlashの利点の一つにページ遷移せずにコンテンツだけを切り替えができる点がありました。つまり、ヘッダやナビゲーションなどの共通要素を表示したまま、コンテンツ要素だけを入れ替えるという処理です。遷移先ページをFlash内に埋め込むか、外部読み込みにするかはさておき、コンテンツ切替時にナビゲーションのトランジションと連動したコンテンツ切替などの表現を行うことができました。その際に、コンテンツ切替を認知させる表現として、一次元的にコンテンツをスライド切替という表現は多くのサイトで採用されていたように思います。ただこれもちょっとコンテンツ間の相関関係的に上野さんの考察からズレた話かもしれません。
これ以外に、カルーセルUI、Expand表示、画像のCrop対応などもFlash起源だった気がしますが、ちょっと自信なし。
まとめ
結局、老害の戯言になってしまった感がありますが、無理やりまとめていきます。
UIデザインを行う身としては、Appleが汎用UIライブラリを探求の上で展開していること、汎用化に伴う認知メリットも理解しつつ、それが本当に最適なのか？という疑問を持つことは、UIを最適に利用するという点で大切なことだろうと考えています。今では自分で実装する機会も減り、脳内で再構築プロセスを作動させて検証を行うような状況になっていますが、Touch UIに（WebのForm UIも！）はまだ多くの改善点があるように思いますし、将来の汎用UIとなる予想を越えた斬新なUIがインディーズから出てきたら楽しだろうなと思ったりもします。（自分も含めて）
そのためには、自分で同等のUIを作成することを前提にUIのロジック解析・コンセプト理解を行うことが非常に効果的だと考えますが、Flashが衰退した現在にそれを代替する簡便なUI検証ツールが無いこと、またコスト的に担保されないリスクが高いところに懸念を感じていたりします。（JS＋CSSである程度はできますが、それ以上の自由度が欲しい・・。良いツールがあれば教えてください）
ということで、そういう助けになるかもしれない、また自分の中での整理ということで、Flashを使っていた頃のUI設計経緯や試行プロセスをまとめてみました。
以上、新しいUIを考える時の参考になりましたら僥倖です。
PS
iOSのUIDatePickerにはiPhoneリリース時から強いストレスを感じていますが、それ以上にAndroidの描画ストレスの方が強いです・・・。