AppleInsider: Apple の iPad の内側： iPhone OS vs Mac OS X
原文： Inside Apple's iPad: iPhone OS vs Mac OS X
モバイルデバイスでの解像度問題
モバイルデバイス上でデスクトップ向けオペレーティングシステムを実行する第一の問題は、マウスベースのインターフェースをサポートするためにデザインされた要素でスクリーンの資産を多く消費してしまうことだ。 iPad は初代 iMac モデルと同じ 1024x768 というディスプレイ解像度を備えているが、初代 iMac の 15"（対角 13.8"）のディスプレイと違って、9.7" 132dpi というスクリーンにこうしたピクセルを押し込めなければならない。
スクリーンピクセルをより濃密にすることで、もともとマウスのためにデザインされていたインターフェース要素としてのターゲットはより小さくなってしまう。 しかし iPad のマルチタッチスクリーンは、マウスカーソルよりも大きく正確さでもやや劣る指でナビゲーションするようにデザインされている。
つまり、使いやすくするためには、ボタンやメニューバー、ウィンドウフレームといったあらゆるインターフェース要素は、同じ解像度であっても従来型のデスクトップコンピュータで描画されるよりも、大きく表示されなければならない。 しかしそうすると、モバイルデバイス上で利用可能な解像度はけっしてそれより大きいわけでないため、ユーザーはブラウザーページといったコンテンツで利用できるエリアが少なくなってしまう。
モバイルでの制約を再考する
Apple は、iPad をコンテンツのためのエリアを狭めてより低速にしたネットブック（実質的にはこれが Tablet PC のできること）として送り込むのではなく、そのインターフェースを作成するにあたっては iPhone を起点にした。
iPhone はすでに比較的小さい画面ながら密度の高い解像度を利用しているため、Apple がそれ用に開発した指に最適化したヒューマンインターフェースガイドラインのほうが iPad でより意味をなす。 iPad をノートブックの簡易版にしてしまうのではなく、iPhone のスケールアップ版としてしまうのだ。
Apple は、利用可能な画面解像度とインターフェースでのターゲットサイズを考えることに加えて、iPhone で設定されたモデルから進化したマルチタッチインターフェースを iPad でどう扱うかについて多くの考察を加えている。
Mac OS X デスクトップ向けに開発されたアプリケーションはすべて、マウスやトラックパッドを使ってナビゲートすることを前提としている。 Microsoft が Windows 7 で成し遂げたように、また Adobe が Flash で作業を進めているように、タッチの要素をいくつか追加することはできるものの、既存のデスクトップ向けアプリケーションはこの新しい機能を利用するために書き替えが必要となる。既存のものは マウスポインターがないと うまく機能しないようにデザインされているからだ。
Cocoa Touch： マウスポインターの不在
Apple は iPad のために、iPhone でタッチ機能という薄いレイヤーでコーディングされただけでなく、指で操作できるようにゼロからデザインされてもいる新しい Cocoa Touch プラットフォームを利用した。 その違いは微妙なものだが、非常に重要だ。
マウスポインターでは、ユーザーは常にターゲットをポイントして、クリックすることでアイコンを選択・開くことができる。 しかしマルチタッチ環境においては、システムはユーザーの指が画面に触れない限りその人が何を指差しているのかが分からない。こうしたことは通常クリックで認識されるようになっているからだ。
タッチでマウスの挙動を模倣しようとすると、またたく間に複雑になってしまう（そしてますます直感的でなくなってしまう）。 Apple は、タッチやさまざまなジェスチャーの組み合わせによってマウスポインターの挙動をエミュレートしようとするのではなく、Cocoa Touch をユーザーが画面とやり取りする際に自然に感じられるようなあり方で指のタッチに反応するようにデザインした。
この結果、Cocoa Touch はポインターではなくタッチを中心に開発されたまったく新しいプラットフォームとなったのだった。 iPhone のスクリーンにはマウスポインターはなく、iPhone に向けて開発されたすべての Cocoa Touch ソフトウェアはポインティングでバイスではなく指との直接コンタクトを中心にデザインされているため、ポインターがなくとも困らないのだ。
飛躍の失敗
その他のほとんどのモバイルデバイスは、なんらかの形でトラックボールや方向ボタン、あるいはスタイラスを維持して、マウスポインターを動かそうとしている。というのも、そうしたデバイスは従来型のポインターを中心としたソフトウェアを走らせようとしているからだ。 これが Microsoft が Window CE Handheld PC や Pocket PC、そして Windows XP ベースの Tablet PC や OMPC で試みた戦略だ。 そのいずれもあまり成功しなかった。
これはまた Flash にも当てはまる。というのも、Adobe の最新ツールをつかって新しいタッチを中心としたコンテンツを開発できるにもかかわらず、Flash アプリや他のコンテンツのインストールベースの圧倒的多数は、マウスオーバーやポインターを中心とした環境に依存した他の要素をいまだに幅広く利用しているからだ。 こうした既存のコンテンツを iPad でサポートしようとしても、結果的に失望感の強いユーザー体験となってしまう。
他のベンダーらは、Apple が 2007 年に決意を持って実行したように、もっと早くにタッチインターフェースに移行するというビジョンに欠けていただけでなく、タッチへの飛躍を行うにも遅れていた。というのも、そうすることで新しいプラットフォームが必要になるからだった（ちょうど Apple が Cocoa Touch で作成したように）。
新しいプラットフォームという catch-22
新しいプラットフォームを作りだすことにまつわる問題とは、それで成功を収めるためには多大な作業（と運）が必要だということだ。 ベンダーが本当の意味で新しいプラットフォームを立ち上げるためには、カスタマーにそれを購入してもらわなければならないが、ユーザーは沢山のアプリケーションが利用できない限り大した興味を示してくれない。
同時に、開発者らにアプリケーションを作ってもらうにあたっても、そうしたアプリを販売できるような既存のインストールベースがない限り難しい。期待されていた多くの新しいプラットフォームがその勢いを増していくことができなかった悪循環がここにある。
Apple は Cocoa Touch でもって、サードパーティ開発者プログラムを始める前でさえ、自社のバンドルアプリだけで幅広い利用者に iPhone をうまく販売した。 当時、開発のゴールドラッシュに油を注げるような新しいアプリへの需要が高まっていた。
iPad は iPhone コーダーらの間にあるその既存の関心と専門知識を梃に、iPad を中心とした開発を引っ張ってくれるようなタブレットを採用する機運を高めようとしている。 iPad が既存の Mac ソフトウェアを実行できたとしたら、開発者らが目を向けられるようなソフトウェアへの新しい需要はほとんどなくなってしまう。 またデスクトップ向けのアプリケーションは満足のいく動作はしないだろうし、ユーザーにとってそれは失望でしかない。
替わりに開発者らは、彼らがすでに手にしている iPhone アプリをより洗練させるだけでなく、既存の Mac 用アプリに向けてオリジナルのマルチタッチインターフェースを生み出すという大きな動機付けを持つことになる。 Apple は、Calendar や Mail、Notes のような iPhone のバンドルアプリの拡張版に加えて iWork のマルチタッチ版を披露して、その両方をどうやったら良いのかという例をデモンストレーションしている。
