カテゴリー : 2012年 1月

論理と直感とiBooks Author


論理と直感といえばよく語られる二項対立。あらゆる場面で登場するが、ここでは文書フォーマットとレイアウトの議論をしたい。

テクニカルな文脈で言えば、あらゆる文書は論理的な構造を持つべきだ。だって、そうすればコンピュータにとって嬉しいもん。文書を書くときに、まずタイトルがあるでしょ、次にチャプターがあって、チャプターにはチャプタータイトルがあって、それぞれのチャプターはセクションが含まれていて、セクションにはセクションタイトルがあって、そして本文があって、、、と、木構造的な論理構造を積み上げていく。こうすると、文書のアウトライン表示ができたり、目次を簡単に作れたり、検索のターゲットが明確だったり、といいことだらけだ。コンピュータにとって。

さて、じゃこの文書を表示しようか、となると直感的なレイアウトの出番となる。題字をここに配置して、柱があって、4段組みにして、ここは強調したいから図を乗っけて、、、と読みやすく要素を配置していく。人間にとって。そのうち、論理構成が破綻していく。あーっ、その構造を崩すな!と論理が言えば、だってこっちの方が読みやすいじゃん、と直感が言う。対立が起きる。

論理と直感のせめぎ合いでグダグタになっている良い例は、現在のWebだ。HTMLという論理構造を記述するためのフォーマットが、複雑なレイアウトを実現するために極限までトリッキーに扱われている。セマンティックのかけらも持ち合わせていない断片の情報の集合、それが現在のWebだ。

で、iBooks Author。iBooks Authorの魅力は、直感的なレイアウトによる使いやすさだ。ドラッグアンドドロップで図やグラフを貼付けて、誰でも簡単に使える。そして、表現力はすさまじい。普通この手の機能を入れると、論理構造はぐちゃぐちゃうになっちゃう。このデモを見たときは、あーあ教科書なのに論理構造はまったくスポイルされちゃうのかよ、と思ってた。

実際に触ってみると、論理構造は生かされていることが分かった。大きな構造は、ブック>チャプター>セクションだ。さらに、セクションの内部では、段落スタイルを指定することで、サブの構造を付け加えることができる。図やグラフは、自由に配置できるが、実は段落にひも付けられている。ある段落に含まれている図、という体裁を取っているのだ。

そして、iBooks Authorでの読みやすいレイアウトは、iPadを縦にすることで一変する。縦画面にすると、図やグラフは左端にサムネイル表示され、本文と区別されるのだ。つまり、横画面は直感的なレイアウトモード、縦画面は論理的な俯瞰モードということだ。こういう共存があるとは思わなかった。やられた。

「論理と直感の狭間(Between Logic and Intution)」。そこに感情を揺さぶる本質がある。この電子教科書を使う学生には、そこに気がついて欲しいと思う。

iBooksで使える/使えないWidget


iBooks Authorを使って、どんなDashboard Widgetを動作させる事ができるのか実験中。久しぶりにProgramming Dashboardを引っ張りだしてきた。

まずは既存のWidgetをいろいろとと貼付けてみる。Dashboardでは、どんな動作を許可するのかを表す値が、Info.plistに記述されている。たとえば、ローカルのファイルにアクセスできるようにするとか、コマンドラインを使えるようにするとか、インターネットプラグインを使えるようにするとか、ネットワークにアクセスできるようにするとか、といったもの。

ざっと試したところ、Info.plistに許可事項が書かれていると、iBooks Authorで貼付けようとしたときに警告が出て拒否されるようだ。一つだけ例外があって、ネットワークアクセスはいけるようだ。

もしネットにつながるならば、いろんなことができるな。Twitterと連携できるだろうし。書評サイトとも連携できるし。実証すべく実験中。

iBooksとDashboard Widget


iBooks Authorで、iBooksテキストブックに計算機をつけてみた。

DashboardのWidgetである、計算機.wdgtを選択するだけ。フルスクリーンの実行環境が表示されて、その中で動作する。

Appleのデモビデオの中で、複雑なインタラクティブを行うウィジェットがあるでしょ。スライダーをドラッグして中の画像が変わるようなやつ。あれは、これだな。Dashboard Widgetだ。

瀕死と思われていたDashboardがiBooksでよみがえった。よし、Dashcodeやるぞ、Dashcode!久しぶりだなー。

iBooks Atuhor登場


iBooks Author登場。来た。現在、徹底的に調査中。HMDTは、当面iBooks Authorに注力します、おそらく。

いま、2008年にApp Storeが開始したときと同じくらい興奮している。出版というものが大きく変わるのは間違いない。

詳細は調査中だけど、電子書籍作成のツールが出ること、EPUBベースであること、インタラクティブにできること、FairPlayで保護されること、Dashcodeのテクノロジーが利用できること、など推測は当たったみたい。

Dashcodeのウィジェットを貼付けることができるらしい。つまり、JavaScript実行環境な訳だ。ならば、何でもできる可能性がある。

正しいバグレポートの書き方:詳細編


先日の記事では、正しいバグレポートを書くには3つの情報を含めてほしい、ってことを書いた。実はこれって、バグレポートに限らず、すべてのコミュニケーションで気をつける事だよね。コミュニケーションは、自分が言いたい事を言うだけではだめで、相手が何を知らないかを推測しながらでないと成り立たない。メールみたいな、顔を突き合わせるわけではないコミュニケーションではなおさら。

これとは別に、バグレポートならではの情報ってのもある。詳細なバグレポートを書くには、この情報も必要だ。これもまとめてみた。ただ、一般ユーザにここまで求めるのは酷なので、無理にやらなくてもいいですよ。開発プロセスでテストを行うときは、テスターの人にはこういった情報を要求しているので参考までに。

デバイスの名前、iOSとアプリのバージョン
問題が発生したデバイスはの、正確な名前は?「iPhone!」それは正確じゃない。iPhoneたくさんの機種が出ているんで。iPhoneのどの機種?「白いiPhone!」それもあんまり正確じゃない。でも実は、この情報でiPhone 4以降ということは絞り込めたりする。ちゃんと、iPhone 3GSとか、iPhone 4とか、iPad 2とか、iPod touch 3rd generationとかって教えて。ただデバイスに名前書いてないから、分からない人は分からないよね。こういうときAppleの美意識は不便だ。

あと、iOSのバージョン、およびアプリのバージョンも教えて。できれば、アプリの名前も。意外に多いのが、アプリの名前が書かれていないバグレポート。アプリ毎にアドレスを用意できるような大きい会社ならいいけど、サポートのメールアドレスが1つしかない場合、何のアプリの問題なのか分からない。頭をフルスロットルで回転させて、文脈から想像する事になる。リアル推理小説だ。

正しい用語を使う
iPhoneの部品やiOSのユーザインタフェースは、名前がきちんと決められている。この定義された名前をきちんと使ってほしい。たとえば、よくアプリケーションの上部にあって、戻るボタンなんかが配置されていて、タイトルが書いてあるバーの名前は?答えは、ナビゲーションバー。よくある間違えは、ツールバー。

中途半端に間違った名前を使うよりは、「上の方にあるバー」とか、「右上にある三角のボタン」とか言ってもらった方が、実は問題が少ない。ベタだけど誤解が発生しないものの方がいい。重要なのは意図を正確に伝える事で、スマートに見せかける事ではない。

再現手順の確立
これが、いちばん重要な情報。問題が発生したとき、その問題をどうやればもう一度起こす事ができるのか、その手順が知りたい。これはもう、のどから手がでるほど知りたい。

もし再現手順が確立できれば、その問題はかなりの確率で修正する事ができる。逆にどうやって発生したのか分からない問題は、非常にてこずることになる。バグ修正作業の大きな時間を取られるのは、再現手順を調べる事だったりする。

再現率
再現手順と並んで重要なのが、再現率。どの程度の頻度でその問題が発生した?毎回?たまに?それとも、1回だけ?もちろん、再現率が高い問題の方が、修正しやすい。テスターの人にお願いするときは、100回の試行中に何回発生したか、という風に報告してもらう。

クラッシュレポート
アプリはクラッシュしたときに、どこでクラッシュしたのかを吐き出してくれる。これがクラッシュレポート。実はクラッシュレポートは、アプリの中に蓄積されている。これがあるタイミングでAppleに送信されて、開発者が参照する事ができる。クラッシュレポートが集まってくれば、問題は修正しやすい。

いつ送信されるかというと、iPhoneをiTunesと同期するときに、「お使いのiPhoneには、アップルが製品を改善するうえで役立つ診断情報が保存されています」とかいうアラートが出るときがあるでしょ。あのとき。あそこで「アップルに送信」を押すと、クラッシュレポートが送られるはず。これが役に立つので、送ってくれれば嬉しいです。

正しいバクレポートの書き方


HMDTでは、主にコンシューマ向けのアプリを多く作ってます。いろんな人に使ってもらえるんで、これは純粋に楽しいです。でも開発作業って楽しい事だけじゃなくて、バグ対応っていう辛い事にも向き合わなくちゃいけないんですよ。

大前提として、一般向けにリリースしたアプリにバグがあってはいけません。バグ込みでリリースする気持ちはないです。でも、これまた避ける事のできない真理として、完全にバグのないソフトウェアを作るのはほぼ不可能です。

現実には、ユーザからバグを報告してもらい、それに対応して新しいバージョンをリリースすることを繰り返す事になります。HMDTでもたくさんのバグ報告をもらうんですけど、それはどれもありがたいんですけど、なかなか有益なバグレポートってのは難しいんだなあ、って思うんですよ。レポートはもらうんですけど、ごめん、これだとこっちも対応できないんだよ、っていうものが多いんですよ。なので、いったいどういうバグレポートが有効なのか、どういう情報が必要とされているのか、ってのをまとめてみました。

ちなみに、バグレポートって、どうしても感情的なものが多いです。気持ちは分かります。そりゃ、私だってゲームしている最中にクラッシュされたら、怒りのメールを送りたくなりますよ。そこは思いの丈をぶつけてください。でも、バグを修正して品質を改善するために、どうしても欲しい情報があるんで、それだけ教えてください。

そんな難しい話じゃないです。バグレポートの基本は、次の3つの情報を記載する事です。

1. どんな操作をして、
2. どんな結果を期待していたのに、
3. どんな結末になった。

この3つです。この3つがあれば、バグ潰しの旅にでかけることができます。逆にこれがないと、どうにもこうにも手を出す事ができません。

例を出しましょう。

良くない例:
「クラッシュした。」

クラッシュしましたか、ごめんなさい。ほんと申し訳ないです。そのバグ直したいんですけど、これだけじゃ手も足も出ないんですよ。これは、「3. どんな結末になった」だけが書いてある例です。「1. どんな操作をして」と「2. どんな結果を期待していたのに」も書いてくれると助かります。

良くない例:
「Webブラウザで、指定したWebページが開かなかった。」

開かなかったですか、ごめんなさい。それは問題ですよね。でも、どうやってWebページを開こうと思ったのか、教えていただけませんか。テキストフィールドにURLを入力しましたか?ブックマークから開こうとしましたか?それとも、文中のリンクをタップしましたか?「1. どんな操作をした」のか教えてください。

「どんな操作をしたかなんて、自明じゃん」と、思うかもしれません。でも、そのユーザにとってWebページを開く方法は一つしかなくても、アプリ全体では複数の方法が用意されているものなんです。なので、それをあえて書いてください。

良くない例:
「ツールバーの停止ボタンを押して、ムービーの再生を止めようとした。」

停止ボタンを押しましたか、ごめんなさい。それで、えーっと、どうなりましたか。「3. どんな結末に」なりましたか。ボタンを押したら、クラッシュしましたか?ボタンを押したら、ムービーの表示が乱れましたか?ボタンを押したら、鳩が出てきて飛んでいきましたか?それとも、ボタンを押しても、何も起こりませんでしたか?「何も起きなかった」というのも、立派な結末です。ぜひ、教えてください。

こういうレポート、冗談みたいでしょう。でも、とても多いです。ほんと多いです。こういったものを受け取ると自分が能無しの犯罪人のような気分になって、山奥に隠れ住みたくなります。

ソフトウェアの品質ってのは、ユーザとプログラマの間でやり取りをしながら高めていくのが理想です。そのためには、ポイントを押さえたレポートが欲しいです。ということで、ちょっとだけ気にしてもらえると嬉しいです。しかし、バグの話になると、どうしても下手に出る気分になるね。

Yellow SubmarineとiPad電子教科書(追記あり)


HMDTでは、定期的にエンジニアの人たちで、内部で技術プレゼンをやっている。内容は、日々の仕事を通して得られた、他の人の参考になりそうなプログラミング情報を共有する事。なかなか面白いです。

で、先日の発表で出てきたネタをご紹介。去年の12月に、iBookstoreから「The Beatles Yellow Submarine」という絵本がリリースされた。もちろん、ビートルズのYellow Submarineだ。その技術的な調査と将来の展望について。

このYellow Submarineは、マルチメディアでインタラクティブな絵本になっている。以下の機能があることが確認された。

・複数のフォントおよびサイズの混在したテキスト表示
・自由なテキストレイアウト。曲線にそったものもあり
・オーディオの再生
・テキスト、図版、ムービーの重ね合わせ
・ムービーのインラインおよびフルスクリーンでの再生
・テキストの読み上げ。読み上げ中にテキストをハイライト表示
・図版のアニメーション
・図版のドラッグでの移動

などなど。いかにもiPadらしさを活用した絵本だ。ダウンロードして触ってもらうのがいちばん分かりやすい。

ただ、これだけならApp Storeにたくさん登場している絵本アプリでも実現している。というか、そっちの方がもっとリッチなものがある。Yellow Submarineが興味深いのは、これらをどうやって実現しているかだ。

Yellow Submarineはアプリではなく、iBooksで表示するドキュメントの体裁を取っている。そのフォーマットは、EPUBだ。つまり、HTML、CSS、JavaScriptで、レイアウトやアニメーションを行っているのだ。HTMLはFixedレイアウト。テキストの読み上げタイミングの制御には、SMILが使われていた。EPUBに含まれる標準技術で、これだけの絵本を作れるという実証になっている訳だ。

ただし、HTMLやJavaScriptファイルは、暗号化されていた。おそらくFairPlayで。だから内容は確認できなかったし、他のEPUBビューワでの再生もできないだろう。

で、こっからは予測になるけど、Appleから1月19日にイベントが行われる事が告知されている。噂によると、電子教科書関連の発表になるらしい。となると、その機能やアピアランスは、このYellow Submarineで実現されているものに近くなるんじゃないだろうか。つまり、自由なテキストレイアウト、図版やムービーの重ね合わせ、インタラクティブ、テキストの読み上げとハイライト。フォーマットはEPUB。FairPlayで暗号化。配信にはiBookstoreを使う。と、いった感じで。

でも、こんなリッチな教科書をどうやって作ろうか。ここで思いをめぐらせると、Appleが作っていたHTML、CSS、JavaScriptオーサリングツールとして、Dashcodeがあったじゃないか。DashcodeはDashboardウィジェットをWYSIWYGで開発できるツール。とてもよくできていたんだけど、Dashboardがまったく流行らなかったので、表舞台に立つ事はなかった。Dashcodeの特徴は、HTMLを編集するんだけど、完全にFixedレイアウトでデザインすること。これって今回のYellow Submarine向きじゃない。

ということで、イベントではiPad教科書用のオーサリングツールも同時に発表されるだろう、と予想。これが出たら、電子書籍の起爆剤になるだろう。それに、Flashがなくなったことによるインタラクティブアニメーションツールの不在という問題も解決する事になる。

ま、これは予想というよりも願望に近いな。

 

17日15時追記:推論からこの記事を書いたんだけど、他のサイトからこんな記事も。GarageBand for e-booksって言い方はテクノロジーベースで考えると不適切だと思うけど。でも、ツールが出るかもしれないって話が噂サイトからも出てくると、それは盛り上がるね。

iPad 3が脅威なワケ


iPad 3の噂がまたいろいろ出てきた。話の焦点は、iPadでもRetinaディスプレイを搭載するとこのこと。まぁ、噂屋はその程度しか思いつかないんだろうけど。

しかし!iPadのRetinaディスプレイ搭載は、大きな脅威となる。アプリの開発者にとって。なぜか。

iOSアプリの開発ってのは、シミュレータを使って行われるんだよね。たとえば、iPhoneシミュレータを27インチiMacで動作させるとこんな感じ。

この中でアプリをテストする。かわいいね。

iPhone 4が登場したときは、シミュレータもRetina対応になった。Retinaディスプレイだと、ピクセル数が縦横それぞれ2倍になったので、シミュレータもこんな感じになった。

大きくなったぜ。アイコンもでかいし。シミュレータのウインドウの立て幅は1,048ピクセル。iMacならいいけど、15インチMacBookだとはみでる。開発機材を選ぶんだよね。

で。iPadシミュレータは、現状こうなっている。

これがRetinaディスプレイになるということは、予想図はこうなる。

イヤァァァァ!ぜんぜん入んない。こんなん、どうやって開発しろと。もちろん50%縮小モードで表示とかできるんだけど、それだとちゃんと高精度で動いているかどうか分かんないし。40インチiMacが必要だ。または、iMac with Retinaディスプレイが。

つーか、モバイル機器のディスプレイ解像度がデスクトップを上回るなんて、どんな時代よ。

ドキュメント中心のFiderのために


ドキュメント中心のFinderのために、TSADocumentManagerViewControllerというクラス名を忘れないようにここに書いておく。

[Mandal-Art Dev] iMandalArtがAppleのあちこちで登場


新年一発目のMandal-Art Dev。まずは、iMandalArtがApple関係のあちこちで登場したので、そちらの紹介から。

App Storeの「New Year, New You」では、心のケアのアプリとしてiMandalArt HDが登場。心のケアってのがにくいね。頭を活性化すれば、心もスッキリするってことですか。

Webサイトの方では、iPhoneと教育という特集ページの中で、リファレンス/仕事効率化/コラボレーションの例として取り上げてもらった。

このおかげもあってか、正月の一週間はいつもの倍の数を売り上げた。iMandalArtおよびiMandalArt HD、まだまだ売れております。

次期バージョンの開発も、いよいよ本格化。先日のミーティングでは最終的な仕様が固まった。あとはどんどん実装していくだけだね。使い勝手をよくするものから、衝撃的な新機能まで、盛りだくさんになった。乞うご期待。