TidBITS#1163/04-Mar-2013 TidBITS#1163/04-Mar-2013パスワードで困っていませんか？ 私たちの最新の電子ブックに解決法がある。Joe Kissell の、"Take Control of Your Passwords" だ。（"Joe of Tech" なる漫画と、楽しい入門ビデオもある。）TidBITS 関係のその他のニュースとしては、私たちの電子メール戦略を議論したスタッフ円卓会議もあるし、前回のスタッフ円卓会議にヒントを得た New Republic 記事もあり、さらに Adam Engst が出演した KCRW ラジオの番組もある。でも私たちが出演した話はもうそれくらいでいいだろう。Jeff Carlson はバグの多い Kindle アプリの騒動の蓋を開け、Adam は再び認可を得た DataMan Pro を検討し、Glenn Fleishman は無料で App.net に加入する方法を説明する。今週の特集記事は二つあって、Josh Centers がビジュアルコミュニケーションアプリ Napkin をレビューし、Matt Neuburg は iOS の歴史を遡って概観しつつ私たちの TidBITS News の新機能を概説する。今週注目すべきソフトウェアリリースは、Scrivener 2.4、CrashPlan 3.5.2、DEVONthink と DEVONnote 2.5、PDFpen と PDFpenPro 5.9.5 だが、いずれのアプリも Take Control 電子ブックで扱われている。
記事:
----------------- 本号の TidBITS のスポンサーは: ------------------
---- 皆さんのスポンサーへのサポートが TidBITS への力となります ----
文： Adam C. Engst: [email protected], @adamengst
訳： 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>
あなたは Web サイトのユーザー名とパスワードを、何とかかんとかやり繰りしていくのにイライラしていませんか？ 私の場合は間違いなくそうである。10 年以上の間に、積もり積もって 300 を超える Web アカウントを持つことになってしまっている。その間、安全なパスワードに対する考え方も大幅に変わり、そして問題に遭遇する可能性も、そして安全を脅かされたアカウントを所持する不利益の両方が劇的に増加してきている。これは腹立たしいし、正直いって少々恐ろしくもある。とりわけ、昨年のあの注目を浴びた Wired 筆者 Mat Honan のハッキングや ("TidBITS Presents "Protecting Your Digital Life" を見よう" 22 August 2012)、Yahoo, Twitter, そして Facebook等からのパスワード盗難と続いた後では尚更である。
幸いにして、Joe Kissell がこの問題に取り組んで来ており、そして彼の最新の 88 頁の電子本 "Take Control of Your Passwords" が、あなたもなるべく手間をかけずに適用できる安全で信頼性のある戦略を冷静に提供する。ここでもっとそれについて書くよりも、我々ももう少しましな楽しみを持ちたかったので、Joy of Tech にいる我々の友人 Snaggy と Nitrozac にお願いして、特別な "Joe of Tech" 漫画を書いてもらった (クリックすれば拡大する)。
もっと良いことに (Joe of Tech 漫画よりももっと良いものなどあればの話だが)、Joe はこれを短い 紹介ビデオ に纏めてくれた - ここでは "Take Control of Your Passwords" の中で Joe が解決の手助けをしている問題をユーモアたっぷりに見せてくれる。もっとも、あなたがいまだに Commodore 64 を使っていなければの話ではあるが。
最後に、2003 年の我々の最初のタイトルであった Joe の "Take Control of Upgrading to Panther" の時にやったことの再現になるが、もしこの電子本が役に立ったと思ったら、あなたの経験を我々に知らせて欲しい：例えば、どの様にして悪いパスワード習慣を克服したか、或いは難しいパスワード問題を解決したかとかである。(もしあなた自身の写真も含めたければ、ひょっとするとこの本からの進言で助けた気難しい "叔父さん" と一緒でも良い、どうぞご自由に！) 我々は最も面白くてそして創造的なレスを Take Control Web サイトに載せたいと思う。そして月に一度 (この本の出版から最初の 3 か月間) Joe は彼のお気に入りの話を選び、そしてその幸運な読者に彼の有名なチョコレートチップクッキーを送る。このクッキーに関する写真や感想も勿論大歓迎である！
コメントリンク13591 この記事について | Tweet リンク13591
文： Adam C. Engst: [email protected], @adamengst
1 comment
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
私たちの内輪の議論をきっかけに、先週号の TidBITS に二つの記事が載った。Josh Centers の“iPhone 用 Mailbox、メールの仕分けは簡単だが重要な機能が欠落”(2013 年 2 月 22 日) と Joe Kissell の“壊れているのはメールではなく、あなたの方だ”(2013 年 2 月 23 日) だ。私は、TidBITS の同僚たちが実際どんなやり方で電子メールを処理しているのだろうか、と考え始めた。毎日のように、時には一時間ごとに、電子メールをやり取りしている相手の人たちなのだから、考えてみればちょっと変な話だ。でも、私が目にするのは彼らから届く返事だけであって、彼らが私から届いたメッセージをどのように処理しているかは見えないし、ましてや彼らが毎日大量に届く他のメッセージをどうしているかなど分かるはずもない。
そこで、今週のstaff roundtableの席で、私は Joe Kissell、Jeff Carlson、Michael Cohen、それから Tonya Engst に向かって、電子メールの扱いにストレスを感じているかどうか、基本的な電子メール戦略はどんな風にしているか、その戦略の中に iOS デバイスをどのように組み込んでいるか、と尋ねてみた。（もちろん私のやり方も話した。）いくつか興味深いことが分かった：
おそらく Tonya は例外かもしれないが、全員が電子メールにかなりストレスを感じている。Tonya は、注意深く言葉を選びながら、電子メール自体がストレスなのではなくて、あまりにもたくさんのものを読んだり、注意深く見たり、何らかのことをしなければならなかったりするのが問題なのだと言った。電子メールはますます多くの情報を運ぶものとなっているので、それらのストレスの焦点に電子メールが位置することもよくある。
私たち全員について、それぞれの受信箱に何通の電子メールメッセージがあるかを調べてみた。Joe は、別に Inbox Zero のやり方をしているわけではないけれども、受信箱にはたった 1 通しか残していなかった。Jeff は 200 通近く、Michael は 900 通以上、Tonya は彼に僅差で勝る 1,100 程度を受信箱に持っていたが、「圧勝」したのは私で、私の受信箱には何万通ものメッセージが溜まっていた。（でも、その主な理由は、私が Gmail の Inbox ラベルをメッセージから除去する理由がないと思っているからで、その代わりに私は読んだけれどもまだ処理する必要の残っているメッセージに未読のマークを入れるようにしている。）
電子メールを扱うやり方が一人一人全く違うのを見て、私はとてもおもしろいと思った。フィルタリングを駆使して受信箱をクリーンに保とうとしている人もいれば、電子メールを情報の流れと捉えてあとで見つけられるようにファイリングする必要もないと考えている人もいる。
朝一番に iPhone か iPad で電子メールを読む人もいる。まだベッドの中にいる間に、あるいは朝食を食べながら読む人さえいる。Mac に向かわず何もかもこなすのは不可能だが、簡単なことを先に素早く済ましてしまうのは良いことかもしれない。
最後に、多過ぎる電子メールの問題を解決すると約束するどんなアプリやテクニックも、すべての人の役に立つことは不可能だと私は気付かされた。なぜなら、私たちは一人一人、それぞれにニーズも違えば好みも違うからだ。それでもなお、この私たちの議論をぜひお聴き頂きたい。ひょっとしたら、あなたが電子メールを制御するために役立つヒントが見つかるかもしれない。そして、あなたのために素晴らしくうまく働いている電子メール戦略があれば、どうぞコメントに書き込んで頂きたい。
（いつもと同様、必ずしもビデオをご覧になる必要はない。この記事のページ［訳者注： 英語版サイトのみ］の上の方にある Listen リンクをクリックすればオーディオ版が聴けるし、 TidBITS ポッドキャスト を購読すれば iTunes の中に、あるいはお好きなポッドキャストアプリの中に自動的にダウンロードされる。）
コメントリンク13597 この記事について | Tweet リンク13597
文： Jeff Carlson: [email protected], @jeffcarlson
訳： 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>
企業が顧客に最新作をダウンロードしないよう言うとしたら何故であろうか？ 何故ならばそのバージョンに簡単には直せない性質の悪いバグが含まれているからである。
27 February 2013 に Amazon はその Kindle iOS アプリのバージョン 3.6.1 をリリースし、そしてすぐ後に "このアップデートには既知の問題がある" として、ユーザーにそのアップデートを適用 しない よう勧告した。
アップデートすると、あなたの Amazon アカウントにログバックするよう強制され、その機器から全てのタイトルが除去され、そしてそれらをダウンロードすると New とラベル付けしてしまう。それにもかかわらず、それらの本のあなたが読んだ最後の場所は覚えている。
次の朝には、3.6.2 アップデートが現れ、この問題は回避された。もし 3.6.1 にアップデートはしたがそのアプリを未だ開いていないのであれば、そのまま 3.6.2 にジャンプすればこれらの問題に遭遇することは無い。
そもそも何故この様な事態になり得るのか？ 企業が Apple に App Store でのリリースのためにアップデートを提出すると、その企業はそのアップデートが承認されるまで待たなければならない。今回の場合、Amazon がテストでは十分に取り切れなかったインスタレーションバグが通り抜けてしまったのであろう。
しかし、あるアップデートが Apple に一旦提出されてしまうと、開発者はその様なバグを修正する術を持たない。唯一の方法はその問題を正すもう一つのアップデートを再提出することである - これも再度 Apple の審査過程を通り過ぎなければならない。
Amazon がとれる他の唯一の行動はリリースノートを変えることであり、こちらは開発者が容易にできる。そして Apple が新しいバージョンを承認するのを待つのである。不幸なことに、ユーザーはリリースノートなどまず読まない。もっとも iOS App Store アプリでは、iPhone 上でそうするのを簡単にはしている。もっと前のバージョンでは、実にちっぽけな What's New 三角形の真上をタップしなければならず、殆ど不可能に近いことであった；今や、そのアプリの名前の上のどこかをタップすればリリースノートが見られる。
これから先、同様なバグの影響を減らすため、Apple はユーザーが前のバージョンに戻るのを容易にすることが出来る。Matt Neuburg が指摘した様に、二つの条件さえ整えば、手動で前のバージョンに戻ることは可能である：アプリのアップデートは iTunes 同期経由でしかやらないこと、そしてアップデートした後 Trash を空にしないことである。そうであれば、あなたは Trash から前のバージョンを拾い出し、そしてあなたの Mobile Applications フォルダにあるものと入れ替えるのである。
しかしもしあなたも私の様で、App Store アプリアイコン上にバッジ (入手可のアップデートの数を示す) が現れたままにしておくのは嫌いであっても、何でも直ちにアップデートするのは待った方が良い。アップデートに予期しないバグが出現したのは何もこれが初めてではないし、これが最後という訳でもないであろう。
コメントリンク13590 この記事について | Tweet リンク13590
文： Adam C. Engst: [email protected], @adamengst
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
過剰なセルラーデータ使用量の問題はまだまだ続いているが、ここ数ヵ月間は騒動もだいぶ収まっているように見える。おそらくそれは、Apple が iOS 6 の中で黙ってバグを修正したからなのかもしれない。私は個人的に、iOS 6.1 にアップグレードして以来、データ量が手に負えなくなる経験をしていない。（2012 年 10 月 24 日の記事“iOS 6 の不可思議なセルラーデータ使用量： もう一歩深く検討する”参照。）けれども、まだ問題を経験している人たちはきっといると思う。そういう人たちは、静かに苦痛に耐えているか、それとも習慣を変えることによって（例えば手動でセルラーデータをオンオフすることで）問題を回避しようとしているかのどちらかだろう。未だに懸念を拭えないでいる人たちに、嬉しいニュースがある。セルラーデータ使用量を追跡する iPhone アプリ、 DataMan Pro が、またもう一度、App Store に再登場したのだ。（2012 年 11 月 20 日の記事“DataMan Pro で iOS のアプリ別データ使用を追跡”参照。）期間限定で、$9.99 のこのアプリは半額の $4.99 で販売されている。
DataMan Pro は App Store の中で、波瀾万丈の歴史を持つ。当初は認可を受けかなりの数を売り上げたにもかかわらず、その後 Apple によって取り下げられてしまった。しかも一度ならず二度も。問題は、DataMan Pro には Apple が認可しないテクニックを使う必要があるという点だ。特に、バックグラウンドで走り続けてさまざまの内部的ログファイルを読み取らねばならない。バージョン 6.1 の DataMan Pro を Apple が App Store から取り去ったのは、これが voice-over-IP クライアント（バックグラウンドで走ることができる）を実装しながら、その一義的目的が VoIP ではないというのが理由となった。そう、まさにその点が Apple の制約を回避するための試みであって、開発者たちを制限してユーザーたちの望む有用な機能を提供しないシステムならば、必ずその種の回避策を招くものだ。
今回の新しい DataMan Pro 6.3 は別のアプローチに切り替えた。ただし残念なことに、VoIP のトリックを使えない結果として DataMan Pro の最も重要な機能のいくつかが削除されてしまった。特に、一時間ごと、日ごと、週ごとの追跡ができなくなり、全体的使用量もアプリごとの使用量も、それぞれ月ごとのレベルでしか追跡されなくなった。もっと細かい追跡はという質問に対して、DataMan の開発者 XVision の Johnny Ixe は私に次のように説明してくれた：
「私たちがそれを除外したのは、Apple が私たちに課した技術的制約を克服するためでした。VoIP モードを利用することができないことにより、信頼性をもって一時間ごとの数字を表示することができなくなりました。日ごとの追跡もまた困難なものとなったため、Apple からの異議を招かないためにも、また DataMan Pro を早く復帰させるためにも、除外せざるを得ませんでした。このように「詳細度の低い」アプリ監視ならば Apple が受け入れてくれることを私たちは願ったのです。そして予想は当たりました。Apple はもう一度、DataMan Pro を認可してくれたのです。今後は、何とか日ごとの追跡を復活させたいと願っています。」
今回の新バージョンにはもう一つ面倒なことがある。正確なデータを保つには、再起動の 前 に DataMan Pro を開いておかなければならない。再起動の後に開く必要はない。
良いこともある。DataMan Pro は従来よりもはるかに見栄えが美しくなった。メインのスクリーンが色で識別されるようになり、あなたがその月のデータ量上限に接近する危険度がどの程度かが一目で分かる。単なる緑・黄・赤の色分けだけでなく、DataMan Pro の Smart Forecast 機能は割り当てデータ量の範囲内にいられる可能性を常時予測してくれる。その際、その月の内にどれだけの量が使われたか、請求期間の終わりまであとどれだけの日数が残っているかが勘案される。だから、あなたが上限の 90 パーセントまで使っていてもその月があと残り 1 日ならば、緑色の表示で何も心配することはないと知らせてくれる。けれども、まだ 21 日も残っているのに 90 パーセントに達した場合は、表示が赤くなって上限を超える可能性が極めて高いと警告する。
メインのスクリーンから上へスワイプすると、アプリごとの使用量内訳（セルラーのみ）のリストが出る。位置情報のピンも示される。一方、メインのスクリーンから左へスワイプすると Settings 画面になる。
DataMan Pro 6.3 は従来よりもはるかに魅力的になったし、iPhone 上でセルラーデータの使用量を追跡するための最良の方法の一つではあるけれども、より細かい追跡機能が失われたことにはがっかりせざるを得ない。もしもあなたが DataMan Pro 6.1 を持っていてそれらの機能を使っているのならば、今回のアップデートはせずにおくことをお勧めしたい。もしもあなたが iPhone でまだ DataMan Pro を使ったことがないのならば、今回のバージョン 6.3 はあなたに iOS 内蔵のレポート機能より多くの手引きを提供してくれるだろうし、私たちは XVision が将来のアップデートで Apple の制約を乗り越えてこれらの機能を獲得してくれることを願いたい。
コメントリンク13593 この記事について | Tweet リンク13593
文： Glenn Fleishman: [email protected], @glennf
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
App.net が、 gone freemium。［訳者注： 基本的なサービスを無料で提供し、より高度なサービスに料金を課金するビジネスモデルのことです。］このソーシャルネットワーキングプラットフォームはサードパーティの開発者たちによって活用されるためにデザインされているので、本来は料金を支払った顧客に焦点が向けられており、そこに無料のレベルを追加するのは一見うまく合わないようにも見える。けれども、Dropbox が無料と有料の部分に分かれているのと同じように、無料版にかけられた制限はちゃんと意味を成している。無料ユーザーになるためには、既存の有料アカウントを持っている人に招待されなければならない。
App.net は、初めのうちは Twitter に似たマイクロブロギングサービスだと誤解されるかもしれない。いずれは Facebook のような本格機能のソーシャルネットワークになりたい野心を持っているのだろうと。けれどもこのビジネスは、その正反対を向いている。App.net は、広告に支えられたビジネスモデルにすることは決してないと約束していて、開発者たちが自分のソフトウェアに対して自由に料金を設定したり好きなビジネスモデルを用いたりしても（彼らが払う年額 $100 の購読料金に満たない収入しか得られなくとも）構わないとしており、制限をかける対象は悪意ある活動と、このネットワークの安定性を脅かす者たちのみだと述べている。
私が初めて App.net について書いた記事は 2012 年 8 月 28 日の“新ソーシャルネットワーク App.net、チャットと広告の上を目指す”で、その中で私は、初めのうちは Twitter に似たものに見えるけれども、App.net の持つ野心は開発者たちのために配管を提供して、彼らが煩わしい基盤構造を気にすることなくそのプラットフォームの上に自分のソフトウェアを築くことができるようにしたいということなのだと説明した。つまり、App.net をガスや電気、下水道、上水道、そしてインターネット接続を提供する市役所だと考え、開発者たちはそれらを利用して、基本的に広さに制限のない土地の上に、自由に住宅やホテル、オフィスタワーなどを建設する、と考えればよい。App.net はそうした公共設備を提供することで収入を得るのであって、緩い建築基準法を超えたルールを作ろうとはしない。
App.net は 2012 年の中頃に、クラウドファンドのプロジェクトを通じてスタートし（クラウドファンドを利用したのは資金を集めるためでもあり、人々の興味を集められるかを確かめるためでもあった）その際に通常のユーザーの年額料金を $50 と設定した。2012 年 10 月になって、料金を年額 $36 に下げるとともに、試行をしてみたい人たちのために月額 $5 の毎月払いプランも追加した。（2012 年 10 月 3 日の記事“App.net 値下げ、ソフトウェアオプションも増加”参照。）さらにその後、同社はひっそりと有料購読者たちに対して、友人たちに一ヵ月間の無料サービスをプレゼントする招待状を三通ずつ配った。
今から数週間前、App.net は "File API" を公表した。これは、すべての有料購読者にそれぞれ 10 GB ずつのストレージを割り当てて、どこででも利用可能なクラウドデータの貯蔵場所として開発者たちがそれを使うことができるようにするものだ。Tapbots の作った iOS アプリ Netbot は現在無料となっているが、これは App.net のストレージを使って写真をアップロードし、そのネットワークのマイクロブロギング部分を通じて共有するようにしている。
無料で利用できるレベルの App.net には多くの制限がある。無料ユーザーがフォローできるのは 40 人まで、保存できるデータは 500 MB まで（さらに、個々のファイルのサイズが 10 MB まで）となっている。有料ユーザーたちにはそれぞれのアカウントに招待状が配られて、他の人たちに渡せるようになっている。過去に一ヵ月間の試用に招待されたことのある人たちのアカウントも、それぞれ無料レベルに変換されている。
このようなモデルは過去にも例がないわけではない。App.net は Dropbox や github の名前を前例として挙げているし、もっと小規模なものは他にも多数ある。Dropbox の価値は数十億ドルと評価されているが、同社はその無料・有料の使い分けを、ホストされ同期されるクラウドストレージの魅力を人々に伝えるためのツールと位置付けて続けてきた。Dropbox の無料レベルには 2 GB のストレージというなかなか気前の良い量が与えられる（さらに紹介によって、また写真のアップロードによって割当量を増やすこともできる）が、その上限量に近づいた場合には、簡単な手続きで月額料金を払うだけでより多くのストレージを得ることができる。それは、あなたが既に Dropbox の便利さを実感しているということでもあるのだ。
招待状というやり方にしたのは、App.net のユーザー基盤をじっくりと増やして行こうという意図に基づくものだ。同社は、一夜のうちに何百万人もの新規ユーザーが押し寄せることは望まない。なぜならそれは、ユーザーたちにも、またサードパーティの開発者たちにも利益とならないからだ。それよりもむしろ、ゆっくりとだが着実に成長することが目標であって、今回同社はその成長をほんの少しだけ促進したいと思い、人々が手軽にそこに何かが本当にあるかどうかを理解できるための道を作ったのだ。好奇心を持った人たちがとにかく参加して、他の人の語ることを聴き、議論に加わり、自分の興味が 40 人の他の人たちをフォローするレベルを超えた場合には有料購読者となってもらおう、というわけだ。
最初のところで述べた通り、App.net は単なるマイクロブロギングのサービスではない。それは App.net で最も目につく機能であって、このサービスができることを説明する役には立つ。その面を要約すれば「App.net は Twitter に似ているけれども、開発者たちを市場から締め出すような Twitter のビジネスモデルはここにはない」と言えるだろう。
最も興味深いのは今後何が起こるかだ。より多くの、多様なアプリケーションが登場して、App.net の基盤構造のさまざまの部分に依存しつつ、もっと風変わりなやり方で働くようになるだろう。（もちろん、App.net の基盤構造にもまだ発表されていない部分が数多く加わることだろう。）例えば、数ヵ月前に App.net は多人数が参加できるプライベートメッセージングを追加したが、この機能はまだほとんど生かされていない。また、App.net を基盤として写真共有サービスを始めることもできるだろう。（表面上は、それをすることでいずれ私たちはより多くのストレージを購入するようになるだろう。）それから、いろいろの既存のプログラムの中に App.net を加えて、Twitter や Dropbox など、ストレージやコメント認証その他の機能を統合するものの代わりに利用することもあり得る。
未来を予測することなどしたくないが、現在私たちに見えているものは開発者たちが App.net のサービスを利用してできることのほんの氷山の一角に過ぎないと、私には思えてならない。無料ユーザーを加えることで、きっと私たちの目にもその氷山のより多くの部分が見えてくることだろう。
コメントリンク13589 この記事について | Tweet リンク13589
文： Josh Centers: [email protected], @jcenters
訳： 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>
最近最も話題に上っているリリースの一つは Napkin である。これは Aged and Distilled. からの新しい画像注釈と描画のアプリである。Napkin が際立っているのは視覚通信を、ナプキン上に落書きするのと同じくらい速くそして簡単にしている点である。この比喩を具現化するかのように、そのデフォルトの背景はナプキンの質感となっている。
Napkin は、視覚通信を出来るだけ簡単にすることに焦点を当てている。同種の多くのアプリケーション - そして一般的に言えば多くの Mac アプリケーション - とは違って、Napkin はジェスチャーを強調しているので Mac 上のみならず iPad 上でも相性が良いであろうと思える。iOS バージョンが準備されていないというのは考え難いが、Napkin の考え方は現在の Apple の考え方に極めて沿っており、OS X 10.8 Mountain Lion のみに限定され、そしてデフォルトでは iCloud に保存される (即ち Mac App Store のみに限定される)。
あなたのナプキン上に画像を載せるには三つのやり方がある：既存のファイルを開く、スクリーンショットを撮る、或いはウェブキャムから写真を撮るである。スクリーンショットは全ウィンドウを撮ることも、或いはウィンドウの一部をクリック＆ドラッグすることで選択して撮ることも出来る。必要ならば、一つのナプキン上に何枚でも画像を追加出来る。
希望の画像が得られた後の注釈付けは直観的で、注釈を追加するのはメニュー或いはツールバーから、或いはジェスチャーによって出来る。もしテキストを追加したければ、ただタイプし始めればよい。矢印で何かを指したければ、ただクリック、ドラッグ、そして直線を引けばよい。形を描きたければ、Command キーを押して、クリック＆ドラッグで形を作る。一つのオブジェクトをロックすることも出来、もしそのオブジェクトから矢印をドラッグして出すと、その矢印はそのオブジェクトにリンクしたままとなる。従ってそれをアンロックして動かしまわったとしても、矢印はつながったままである。もしロックされたオブジェクトの内部に線を引くと、Napkin は代わりに寸法線を作成し、その線の長さが何ピクセルであるかのラベルも付ける。
これらの Napkin 機能全てを使って線画やマインドマップまで作成出来る。一つの形の中にテキストを直接加えることも出来るので、バブルを作り、そしてその中に考えを付け加え、それからそのバブルをロックすることが出来る。更に、その考えを含んだバブルから矢印を引き出して次の考えにつなげることも出来る。
取り込んだ画像はフレームで飾ることも出来る。これは言わば境界の様にも働き、背景も付けられるが、その選択肢は限られている。Napkin は選択肢として六つのフレームを提供しているが、調整は全くできない。私自身も実際に気に入ったと言えるものにまだ行き当たっていない。まあまあと思えるものに Simple と Photo があるが、これらは趣味のよい、少々幅広の、白い縁である。Capsule フレームというのもあるが、これは選択された画像の角を丸める。残りの三つは似て非なる構造で間が抜けた感じがする：Thumbtack, Tape, そして Paperclip で、それぞれが捉えた画像の一番上に名前の通りのものの漫画バージョンを追加する。背景はより選択肢が限られて、オプションは三つしかない：Transparent, White, そしてこれまでに紹介している Napkin である。Napkin は紙ナプキンの質感を出している。
もし取り込んだ画像に秘匿情報が含まれている場合、それをダブルクリックして編集することが出来る。Napkin はあなたがクリックした場所にズームインして、二つのツールを提供する：マーカーと消しゴムで、それぞれが色々な大きさに設定出来る。これは気の利いた機能だとは思うが、私だったら単にその秘匿情報の上に黒の四角を描くだろうと思う。通常手で描いた修正部分は汚らしく見える。
Napkin の看板機能は Call-Out である。これは固定の拡大鏡の様に働き、あなたが注意を喚起したい詳細に目を向けさせる。これを作るには、Call-Out ボタンをクリックするか円を描き、それからその Call-Out をあなたが拡大したいものの上にドラッグし、そしてそれを再度クリックしてそこに固定させる。Call-Out と矢印とで、Napkin はインターフェース項目に注意を向けさせるのを簡単にしてくれる。
Napkin は本質的にソーシャルである。内蔵の Share ボタンを使って、その画像を Twitter, iCloud, Facebook, そしてメール等々に送らせてくれる。Napkin の最も賢い機能の一つは File Pip で、".png" と名付けられたボタンとして右上に配置されている。そのボタンを何処にでもドラッグすれば現在のナプキンの PNG 画像を追加できる。残念ながら、この File Pip はまだ完璧ではなく、それをどのアプリケーションにでもドラッグすることは出来ない。TidBITS では、我々の現行の管理システムに画像をアップロードするのに ShotBOT というカスタムアプリを使っているが、File Pip を ShotBOT にドラッグしても働かないし、他にも働かないアプリケーションがかなりある。しかしながら、もしあなたが DragonDrop をお持ちなら、これはファイルやコンテンツの中間保管庫として働く気の利いたユーティリティであるが、Napkin から PNG を DragonDrop へドラッグすることが出来、そこからあなたのお好みのアプリケーションへとドラッグ出来る。不幸にも、生成された PNG の名前を何にするか直接選ぶことは出来ない；それはナプキンのファイル名とタイムスタンプの合わさったものとなる。
そのプロ向けの価格設定にも拘らず、Napkin 1.0.2 は多くのプロ機能を欠いているだけでなく、幾つかの基本的なものまで欠いている。ズームイン或いはズームアウトの機能は一切ない。これは如何なる画像編集ツールにも不可欠の機能である。スクリーンショットを撮るためのシステム全体にわたるホットキーもまだない。尤もこのスクリーンショット機能は Mission Control とは十分に上手く働くが、その場合でも、あなたの Napkin ウィンドウはあなたがスクリーンショットを撮りたいウィンドウと Desktop を共有している必要がある。画像を互い同士で整列させることは出来るが、Napkin には目安となるガイドが無いので、整列具合を微調整するのは難しい。Napkin には画像切り取り (クロッピング) も無い。スクリーンショットを撮る時にはウィンドウの一部だけを選択させてはくれるが、一旦画像を取り込んでしまえば、Napkin はそこから更にトリムダウンすることは出来ない。また、メニューとかダイアログと言った特定のインターフェース項目にスクリーンショットを合わせる簡単な方法も無い。
Mac アプリケーションとしては革新的だが、Napkin のジェスチャーベースのインターフェースは時としてイライラさせられることがある。私は、既存のエレメントをドラッグしたいと思っているのに矢印を描いてしまっている自分をしばしば発見する羽目になった。更に、寸法を測るのではなく矢印をトリガーする方法を覚えるのも難しい。Napkin はあなたがやりたいと思っていることを推測しようとするが、何時も正しく推測できるわけではない。私は、Napkin の開発者がユーザーフィードバックに耳を傾け、そしてこれらの不具合を直してくれることを望みたい。
私は Napkin を好きになりたいと思う。これは革新的だし賢くもある、そして時間と共にもっと良くなると思う。しかし現時点では、このアプリを私が、とりわけ $39.99 という値段では、お勧めするのは難しい。その簡素さのお蔭で、手軽に描画したり注釈付けをしたりするのが楽しくなるが、制作業務のために必要な細かいコントロールを備えていない。私はこれを簡単なノートや遠隔でのプロジェクト共同作業に使うことは考えられるが、ユーザーに最終的なアウトプットに対する制御を殆どさせてくれないので、もしある特定のニーズを持った出版者のために画像を準備しようとしているのならば、Napkin では役に立たないであろう。私は Napkin を "Squarespace 6 ウェブホスティング： 使い易さとデザインが欠陥を凌ぐ" (8 February 2013) において、最初の画像のために使った。結果的には、画像の整列と縁取りオプションの制限にイライラさせられてしまった。
Napkin は、開発チーム対する不可欠のツールとなる可能性を秘めている。その Call-Out 機能は細かな詳細を指し示すには素晴らしい方法だし、そしてこの機能だけでもそのコストには十分見合うと感じる人もいるかもしれない。しかし現時点では、あなたの視覚通信のニーズ全てには対応出来ないであろうから、これは既存のツールに対する単なる補足でしかない。
コメントリンク13532 この記事について | Tweet リンク13532
文： Matt Neuburg: [email protected]
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
フリーウェアの TidBITS News アプリ は、最新の TidBITS 記事を読んだり聴いたりするためのものだが、その中に iOS の歴史そのものをほとんど丸ごと詰め込んだ極小の小宇宙とも言える。犬の一年 (dog year) が人間の 7 年に相当するとすれば、開発者の一年 (developer year) は、iOS のような急速に変化しつつあるものに追い付こうとし続ける 20 年のごとくに感じられる。このアプリが公開されていたのは太陽年にしてたった 3 年間に過ぎないが、私はこれを走り続けさせ最新に保ち続けようと努めるため既に一生涯を費やしたような気さえしている。
世界の歴史を手短かに -- おそらく私はこのメタファーをさらに押し広げて、開発者の一年を 2 億年くらいに考えるべきかもしれない。すると、リリース済みの TidBITS News の六つのバージョンをそれぞれ地質時代に当てはめ、気候変動による大規模な変化を追跡することができるだろう。TidBITS News が生き抜いてきた（そして何とか生きながらえてきた）歴史を、ここに概観してみよう：
TidBITS News のバージョン 1.0 がリリースされたのは 2009 年 12 月のことで、当時は iPhone 3GS と第三世代の iPod touch が最新のデバイスであった。私はそのほんの二ヵ月ほど前に第三世代の iPod touch を手に入れていて、そこには Apple のピカピカに新しい iOS 3.1 が走っていたが、速度、メモリ、スクリーン面積のいずれの意味においてもこれほど少ないもので立派に間に合わせることができることに非常な興味をそそられたものだった。私が TidBITS News を書いたのは、このちっぽけなシングルウィンドウとタッチインターフェイスという奇妙な新しい世界でどうやってプログラミングをするのかを学んでみたいという気持ちがその動機の一つであった。
アーキテクチャの観点からは、TidBITS News はメインと詳細の二つのスクリーンを単純に組み合わせたものであった。メインの表示では、TidBITS 記事のリストにそれぞれのタイトルと要約が並ぶ。その一つをタップすれば詳細表示に移り、その記事の全文が読める。それでも、舞台裏では、かなり巧みなネットワーキングが処理されていた。記事の本文は RSS フィードからダウンロードされた上でオープンソースのライブラリを使って構文解析され、またその記事のオンラインポッドキャストがある場合は詳細表示でそれを聴くことができた。さらにメイン表示には極めて革新的な機能が含まれていた。すなわち、タイトルも要約文も、またそれらを含む表の各行も、一行単位で行の高さを調節することができたのだ。当時私の知る限りそれができるアプリは他になく、これほど巧妙なことをうまくやり遂げられたことを私は誇りに思っていた。その後私はそのやり方の説明を公表し、今ではかなり広く使われるインターフェイス形式となっている。
2010 年 4 月に、Apple は iPad をリリースした。幸いにも iPhone サイズのアプリも引き続き iPad 上で、一種のエミュレーションモードで動作することができた。iPad の画面上で、iPhone のスクリーンのサイズのままで（またはかなり見苦しいダブルサイズでも）表示された。だから、TidBITS News アプリにはとりたてて iPad 用のバージョンを別途作る必要などないと私は思い、何もせずそのままやり過ごしたいと考えていた。ところが残念なことに、このエミュレーションは厳密なものではなかった。iPad は iOS 3.2 を走らせていたが、iPhone はまだ iOS 3.1 のままで、デバイスにより相違のあるこの状態を Apple が解消するまでに、法外に長い時間がかかってしまった。二つのシステムの間には同一の機能でも実装する方法に違いがあったり、同一のコードに対して異なるやり方で反応したりした。（最も言語道断であったのは、iOS 3.1 でシャドウを描いた場合、同じコードが iOS 3.2 では反対側にシャドウが描いてしまったことだ。いったいどうしたんだ、Apple は？）
システムの挙動におけるこのような違いが、TidBITS News にもさまざまな結果を及ぼした。iOS 3.2 は、メイン表示でタイトル、要約文、表の行のサイズを動的に変更するという、高く評価された私の手法を壊してしまったので、私は大急ぎで問題の修正にあたらなければならなかった。それを解決した時のことを私は今もよく覚えている。ニュージャージー州 Princeton にある両親の家の台所に座って、仮想のハンマーでガンガン叩き続けた挙句、両方のシステムと両方の種類のデバイスで働くコードを何とか思い付くことができたのだった。この修正を盛り込んだバージョン 1.1 の TidBITS News は 2010 年 6 月に公開された。
その頃までに、Apple はもう一つの革命の準備を整えていた。iPhone 4 だ。これにより、二つの極めて大きな変更がもたらされた。第一に、このデバイスは二倍解像度のスクリーンを備えていた。そのため TidBITS News のテキストは素晴らしく見えたが、残念なことにグラフィックスが酷い見栄えになってしまった。第二に、そしてこちらの方が影響が大きかったが、iOS 4 と マルチタスキング が導入された。その当時の記事で私が解説したように（2010 年 6 月 23 日の記事“高速アプリ切り替えとは何か？”参照）それはつまりユーザーが Home スクリーンあるいは他のアプリにに切り替えた際にアプリは終了させられず一時停止の状態になるということを意味した。しかも、一時停止状態のアプリはその後何の断わりもなしに勝手に終了させられてしまうかもしれないのだ。2010 年 8 月に、私たちはバージョン 1.2 の TidBITS News をリリースして、マルチタスキングと二倍解像度のグラフィックスとに対応した。（その際私たちは App Store に関する厄介な騒動にも巻き込まれた。2010 年 8 月 21 日の記事“TidBITS News アプリのバージョン混乱の背景”参照。）
iOS 4.0 は新しい iPhone 4 のみならず、一部の古い iPhone や iPod touch 機種でも動作したが、iPad では動作せず、iPad はまだ iOS 3.2 のままで、従ってマルチタスキングやその他の iOS 4 における革新の恩恵を受けることができなかった。TidBITS News は（App Store ではそのようにして配布することが許されなかったにもかかわらず）iPhone でも iPad でも動作するようデザインされていたので、さまざまの障害をくぐり抜けてそれがどのシステムで走っているかを探知しそれに相応しく反応するように、極めて複雑な追加のコードをたくさん含むことになった。私にとってこの状況はうんざりさせられるもので（それより良い方法で切り抜けることはできなかった）Apple が開発者たちに向かって（仮想の）指を突き出すような態度を続ける限り、こちらも同じ（仮想の）指を Apple に向かって突き返してやろうと決心した。その昔 Achilles がテントに立て篭ったのを見習って、私の望む条件が整うまでは外に出て戦うことはしまいと決めたのだ。まず Apple が、各デバイスでシステムを統一する義務がある。2010 年 11 月になってようやく、劇的なフライイングスタートの後、Apple は iOS 4.2.1 をリリースした。これは iPad でも、従来 iOS 4.0 を走らせていた他のすべてのデバイスでも動作し、これでやっと Achilles も外に出て戦う準備ができた。そうして私は TidBITS News を "universal" なアプリに仕上げた。つまり、iPhone サイズのスクリーンでロードされるインターフェイスと iPad でロードされるインターフェイスの両方を備えるようにした。
バージョン 1.3 の TidBITS News は 2010 年 12 月にリリースされた。障害をくぐり抜けるためのコードは 依然として 結構たくさん含まれていたが、今回は以前とは 違う 種類のくぐり抜けのためのコードだった。異なるシステムごとに異なる挙動をするのではなくて、異なるデバイスごとに異なる挙動をするように作った。それは、システムの機能が異なるのでという理由ではなくて、インターフェイスのアーキテクチャが異なるので必要なことであった。iPhone 上では、ナビゲーションのインターフェイスで最初に表示されるのはメインのスクリーンであり、詳細表示がナビゲーションインターフェイスの第二の部分としてそれに置き換わるようになった。一方 iPad 上では、双方が同時に見えるようにして、分割表示として左右に並べるようにした。（ただし、これは横長にデバイスを置いた場合の話で、縦長に置いた場合はメイン表示が「ポップオーバー」なる煩わしい存在と化した。なぜなら、それが iOS 4 が分割表示を実装した方法だったからだ。）iPad では縦方向も長いので、表の各行の高さも高くでき、スクリーン面積にも余裕があったので、記事にはより大きな画像を入れたり広いマージンをとったりできた。
バージョン 1.3 のリリース後間もなく、稀に起こるメモリのバグが発生した。いくつか実験をしてみると、それは結局のところ私のバグではないことが判明した。それはあの極めて煩わしいポップオーバーに関係しており、私はできる限りの手段を尽くしてそれを防止するようにした。また、ある読者からの助言に従って、私は新たなオーディオ管理ポリシーを組み込んだ。すなわち、もしもユーザーがバックグラウンド音楽をプレイしている最中に TidBITS News が前面に来れば、ユーザーが記事を読みながらそのまま音楽を楽しみ続けられるようにするけれども、その後でユーザーが私たちのポッドキャストを聴こうとすれば、バックグラウンドの音楽を一時停止するようにしたのだ。バージョン 1.4 の TidBITS News は 2011 年 2 月に公開された。（2011 年 2 月 18 日の記事“TidBITS News アプリ 1.4 でバックグラウンドオーディオが可能に”参照。）
そしてその状態が、TidBITS News に関する限り、その後二年間近く続いた。けれども Apple 世界の事柄は、いつも通りの速度で動き続けていた。iOS 5 (2011 年 10 月) と、とりわけ iOS 5.1 (2012 年 3 月) が、私が TidBITS News に組み込みたいと思い願っていた革新をもたらした。（2011 年 10 月 17 日の記事“iOS 5 は開発者に、そしてあなたに、どう影響するか”参照。）けれどもそれらによって何かが壊れるということはなかったので、私にはあえて新バージョンを書かなければならない動機が生じなかった。その後第三世代の iPad (2012 年 3 月) に Retina ディスプレイが装備され、私たちのテキストは以前にも増して良く見えるようになった。私たちは既に（アプリのアイコン自体を除いて）二倍解像度に対応したグラフィックスを備えていたので、何もあわてる必要はなかった。それから、iOS 6 (2012 年 9 月) がさらなる魅力的な革新をもたらした（2012 年 9 月 25 日の記事“iOS 6 は開発者に、そしてあなたに、どう影響するか”参照）上に、私が待ち望んでいた動機をもたらしてくれた。そう、iOS 6 で、テキストを描く際に表の行の高さを動的に変更するために私が使っていた手法が、ほんの微妙にだが、壊れたのだった。それからもちろん、新しい iPhone 5 の縦に長くなったスクリーンでは私のアプリの画面の上下に黒い帯が付くようになった。私はあの「二つのシステムで走る」障害をくぐり抜けるのはもう二度とご免だと思ったので、TidBITS News を完全に一から、純粋な iOS 6 アプリとして書き直すという解決法を採ることにした。記事“iOS 4.2 と iOS 5 用の TidBITS News アプリを今入手しよう”(2012 年 12 月 10 日) で然るべき警告を提供した上で、2013 年 1 月に私たちは TidBITS News 1.5 を公開した。
あなたの目に見えるものは -- だから、TidBITS News 1.5 の新機能とは、iOS 5、iOS 5.1、および iOS 6 における新機能の横断面を高度に反映したものと言える。その中には、表面的に見て明らかなものもいくつかある。例えば、メイン表示（記事のタイトルや要約文をリストする表示）を iOS 5.1 の走る私の iPod touch 上で TidBITS News 1.4 で開いたもの（左）と、iOS 6 の走る私の iPhone 上で TidBITS News 1.5 で開いたもの（右）とを比べてみよう。
まず、スクリーンの一番上、TidBITS ロゴよりも上のところをご覧頂きたい。ここに、現在の時刻やバッテリ状態などの情報が表示される。この部分は私のアプリという訳ではなく、システムのステータスバーだが、ここにも変化が見られる。iOS 6 は、iPhone 上で（ただし iPad 上ではそうはならない）このステータスバーを不可思議な、自動的なやり方で色付けしようとする。開発者たちはこれが好きでない。なぜなら、この色付けのアルゴリズムが公開されておらず（ただしもちろん私たちはそれがどうなっているかを既に見極めていて、ステータスバーを欺いて別の色付けをさせる方法も見つけている）色付けをオフにすることもできないからだ。ただし、ステータスバーの色を黒にした場合だけは別だ。とにかく、何たることか、iOS 5 やそれ以前にあった、古き良きグレイ階調のステータスバーにすることはどうしもできない。それは、もはや懐かしき思い出に過ぎない。
ほんの少し下に目をやると、TidBITS ロゴがある。ここで変わったのはロゴ自体でなく、その背景にあるものだ。もっと前、TidBITS 1.4 が書かれた時代の iOS 4 では、このような標準的インターフェイス要素は（これはナビゲーションバーだ）あらゆるアプリで基本的に同じであった。実際それはステータスバーと似ていて、グレイ階調か黒の階調かを選べた。iOS 5 になって、Apple は多くのインターフェイス要素をカスタマイズする手段を公式に提供するようになり、iOS 6 ではさらにその先まで歩を進めた。そこでこのナビゲーションバーも、従来なかったバックグラウンド画像が今では含められ、TidBITS のホームページから取って来た階調模様が示されるようになった。そうそう、このナビゲーションバーのすぐ下に、ほんの すぐ下だが、右のスクリーンショットでは「リネン」のバックグラウンド画像との際にかろうじて見える程度に、もう一つ iOS 6 の新機能がある。ナビゲーションバーとそのすぐ下に来るものとの間に、微細なシャドウを入れるオプションが出来た。
ナビゲーションバーの右の方に、バージョン 1.4 では Refresh ボタンがあるが、バージョン 1.5 にはない。これは、iOS 6 には新たに表の Refresh コントロールが内蔵して提供されるようになったからだ。もともと Twitter アプリで生まれたこの考え方は、引っ張ればリフレッシュされる というものだ。つまり、表を下の方へスクロールして行けば Refresh 記号が現われ、そのままスクロールを続ければ Refresh 記号がアニメーションを始める。これを利用することによって、私は今や iOS 6 版の Apple の Mail アプリなど標準的アプリの共通通貨となったインターフェイスをきちんと利用できるとともに、目で見たインターフェイスを Refresh ボタンが不必要に乱すことがないようにした。
この iOS 6 の Refresh コントロールでは、アクティビティのインジケータの他に、テキストを表示できるラベルも提供される。私はこれを利用して、最後にフィードからデータをアップデートした日付と時刻を表示する方法を変更することにした。TidBITS News 1.4 では、常時見えているラベルの上にこの情報が表示され、目で見て気が散るだけでなく貴重なスクリーン面積も浪費してしまう。バージョン 1.5 では、これが Refresh コントロールの一部分となり通常は表の一番上のロゴの下に隠されている。フィードのデータがリフレッシュされた直後のみそれが見えるようになって、スクリーンショットにはその状態が示されている。こうして、1.5 のインターフェイスの方がずっとクリーンなものとなった。リフレッシュボタンもなく、Updated ラベルも通常はなく、ただ TidBITS ロゴと、素敵なバックグラウンド画像、それから記事のリストが示されるだけだ。
記事のリスト自体も、もちろんバージョン 1.5 では少し違った風にフォーマットされる。セルの高さを以前より少し高くできるようにしたので、要約文の全文が表示される可能性が高くなった。（iPad 上では、常に 要約文の全文が表示される。）けれども最も大きな変化は舞台裏で起こっている。バージョン 1.4 やそれ以前では、タイトルと要約文はそれぞれ別のラベルであって、それぞれが単一のフォントとフォントスタイルと決まっていた。さきほども述べたように、当時はたくさんの創意工夫を駆使することによって行の高さを調整したり動的に位置取りしたりする必要があった。けれども iOS 6 がそれらすべてを変えてしまった。本物のスタイル付きテキストが、正式市民として受け入れられたのだ。だから、見出しと要約文とは一緒になり、二つの段落にフォーマットされた 一つの 文字列として扱われ、以前よりはるかに簡単かつ正確に、直接描いてレイアウトできるようになった。
さて、詳細表示（つまり個々の記事）の方は、二つを並べて見比べてもそれほど劇的に興味深い違いはない。ここでもやはり、TidBITS News 1.5 では標準的インターフェイス要素をカスタマイズできるようになったお陰で、ナビゲーションバーの上のボタンにも素敵な色付けが可能となり、新しいバックグラウンドの色階調と似合ったものにできるようになった。（ナビゲーションバーのすぐ下に描かれるシャドウは、こちらのスクリーンショットの方が一目で分かるだろう。）
次に、ユーザーがポッドキャストを聴く方法について見てみよう。両方並べて比べれば、バージョン 1.5 で表示が根本的に変わったことが分かる。けれどもこれは、iOS 6 による革新のお陰ではない。ただ、私がインターフェイスを根本的に作り直したというだけのことだ。左側はバージョン 1.4 やそれ以前のもので、インターネットからのリソース（ムービーまたはサウンド）を再生するための単一の内蔵ビューそのままだ。私はバージョン 1.0 の当初からこれを使っていた。なぜなら、TidBITS News を書き始めたばかりの頃、オンラインのポッドキャストが再生できること、そのためのインターフェイスはたった二行のコードを書き加えるだけで済むことを発見してすっかり安心してしまったからだ。けれどもその後、バージョン 1.3 や 1.4 を書いていた際に、このインターフェイスではサウンドに対して出来ることの範囲に限界があるという側面に気付き始めた。そこで、バージョン 1.5 では、インターフェイスを変更することにした。この変更により、現在再生中のポッドキャストのタイトルを表示できるようになったのだが、それは変更の主たる理由ではない。本当の理由は、ポッドキャストの再生中にユーザーが他のアプリへ切り替えた場合に何が起こるかに関係がある。
従来は、私がサウンドをバックグラウンドで再生し続けられるのはユーザーが TidBITS News の中に留まりスクリーンをロックした場合に限られた。けれども今は、インターフェイスを変更したお陰で、サウンドに関するアプリのポリシーに対してずっと多くのコントロールができるので、たとえユーザーが完全に TidBITS News を終了した後であってもサウンドの再生を続けることができる。その上、ロックスクリーン自体の中から、またはアプリ切替インターフェイス（右へスワイプしてサウンドコントロールを出した状態）から、ユーザーが再生を一時停止したり再開したりすることも可能となる。さらに、今述べた二つの場所の中で、現在再生中のポッドキャストのタイトルをユーザーが見ることもできる。これは iOS 5 で導入された機能のお陰だ。
もう一つ、一目で明らかに分かる TidBITS News 1.5 での変更点がある。それは、iPad 上で記事のリストが表示される方法だ。従来は、さきほども述べた通り、デバイスを縦長に置いた場合にはリストがポップオーバーの中に呼び出される必要があった。けれども iOS 5.0 で、Apple は新たなインターフェイスを導入した。これはとりわけ Mail アプリで目立つ、メッセージのリストが左側からスライドして出てくるというものだ。私はすぐに三日間を費やしてこのインターフェイスをリバースエンジニアリングし、さらにはどうすればそれが達成できるかの説明 を発表しさえした。けれども私がそんなことをする必要はなかった。iOS 5.1 で、Apple は同じインターフェイスを開発者たちが直接、何のコードも必要なく利用できるようにした。基本的に、古いポップオーバーのインターフェイスがただ魔法のように新しいスライド式のインターフェイスに変身したようなものだ。TidBITS News 1.5 は、iOS 5.1 より後のシステムバージョンのためにコンパイルされているので、自動的にその新しいインターフェイスを使うようになっている。
ボンネットの中では -- あと二つ、TidBITS News 1.5 では大きな変更点が内部に埋め込まれている。いずれも、インターフェイスには全く現われない。むしろそれらは、Apple が開発者に提供する構成要素における変更点に関係がある。けれども二つのうち一つは、このアプリの挙動を少し変えることとなった。まずはそちらの点を説明しよう。
TidBITS News は、iOS 5 で導入された storyboard を使うようになった。この storyboard というのは単一のファイルで、その中に一つのアプリのインターフェイスの大部分あるいは全部に対する図面が含まれる。従来は、多数の「スクリーン」を持つアプリは個々のスクリーンのインターフェイスをコードで構築するか、または "nib" ファイルからインターフェイスをロードするかしかなかった。多くの場合、一つのアプリには非常に多数の nib ファイルが含まれていた。これらの nib ファイルを一つのファイルにまとめる効果的な方法となるのが storyboard だ。私の目から見て iOS 5 が storyboard を実装したやり方はかなり荒削りなものだったが、iOS 6 になっていくつか改善が施され、storyboards が真の意味で役立つものとなった。そこで、私はこれを TidBITS News 1.5 に採用した。
TidBITS News は二つの storyboard を含んでいて、それぞれが一つのデバイス用のバージョンのためのインターフェイス全体を代表する。一つは iPhone または iPod touch 用、もう一つが iPad 用だ。アプリが起動する際に、現在のデバイス用の正しい storyboard が 自動的に ロードする。その上、その storyboard 自体がスクリーンからスクリーンへの標準的移行をすべて実装している。例えば、iPhone 上でメイン表示から詳細表示へナビゲートしたり、ポッドキャスト再生表示を呼び出したり片付けたりといったことだ。その結果として、私は膨大な量のコードを削除することができた。自分のインターフェイスをコードで描いたりする必要はもはやない。さらに重要なことには、もしも iPhone 上で走っているならばこちらをして、もしも iPad 上で走っているならばこのことをする、といったややこしい条件文だらけのコードでアプリを埋め尽くす必要がなくなった。もちろん今でも多少の条件文はある。主として、双方のデバイスが共有するインターフェイスの構成における些細な違いに関するものだ。例えば、さきほども触れたように、iPhone 上ではメインの表の行の高さに制限があるが、iPad 上では制限がない。（iPad 上では記事の要約文がどれだけ長くても全部を表示するようにした。）それでも、コードは全体として以前よりはるかにきちんとしてシンプルなものとなり、理解するのも維持管理するのもはるかに易しくなった。
もう一つの大きな内部的な変更点は、起動と起動の間でどのように状態が保持されるかということに関係がある。これは、iOS 4 でマルチタスキングが猛威をふるうようになって以来ずっと厄介な問題であったし、まだこの問題を解決できていないアプリも (Apple 自身の iBooks も含めて) 存在している。問題は、アプリが目覚めるには二つの非常に違った道があるという事実から生じる。もしもそのアプリが一時停止の状態にされたならば（つまりユーザーがホームスクリーンあるいは別のアプリに切り替えたならば）即座にそのアプリは現在の状態のまま凍結乾燥される。そしてユーザーがそのアプリに戻れば、そのアプリは解凍され、そのまま、前回していたのと同じことをし続ける。他方、もしもそのアプリが一時停止の状態の最中に 終了させられた ならば（つまりデバイスがいくらかのリソースを解放する必要に迫られたならば）そのアプリは一から起動し直されることになる。両者の違いは厄介なもので、ユーザーにとっては不可解なものとなり、とりわけ、ユーザーの観点からは、これら二つの状況を区別できる手段がないことが大きな障害となる。ユーザーが明示的に一つのアプリを終了させることは決してないし、現在何が走っていて何が走っていないのかをユーザーが知ることのできる簡単な方法もない。アプリ切替のインターフェイスさえ、走っているアプリと終了したアプリの区別をしない。
開発者にとって、これはそう簡単に解決できる問題ではない。TidBITS News も、マルチタスキングが出現するより前の時代から、コールドスタートの際に何が起こるべきかという疑問に取り組む努力をしてきた。もしもユーザーが個別の記事を読んでいたならば、TidBITS News はその事実を覚えていて、再起動された際にはその記事へナビゲートした。マルチタスキングの登場によって、問題は実際さらに困難なものとなった。なぜなら、アプリが前面に来る方法が二通りになったことで、開発者はそれらを区別しなければならなくなったからだ。もしもアプリが単に一時停止の状態から復帰するだけならば、何もしなくてよい。けれどももしもアプリが一から起動しようとしているのならば、前回読まれていた記事がある場合にはその記事へナビゲートするようにしなければならない。これを理に適った、維持可能なやり方で実装するのは、途方もなく困難であることに私は気付いた。たとえ、主たる表示がたった二つしかないアプリにおいてであっても！
iOS 6 になって、Apple は状態を保存し復帰するためのメカニズムを新たに内蔵した。私は TidBITS News 1.5 を一から書き直しながら、待ち望んでいたという思いでこれを採用した。その結果として、ユーザーたるあなたは TidBITS News が再開する際に、それが一時停止の状態からの復帰であるかそれともいったん終了させられた TidBITS News を起動し直しているのかをほとんど区別できないようになっているはずだ。いずれにしても、アプリはあなたが前回いた場所に戻って、メイン表示ならば記事のリストを前回と同じ位置までスクロールして同じものを選択し、詳細表示ならば前回開いていた記事を開いてやはり前回と同じ位置までスクロールする。
残念なことに、Apple が内蔵した状態保存と復帰のメカニズムには大きなバグが一つある。これはあまりにも大きなバグなので、たとえあなたが超豪華キャンピングカー Winnebago を目を閉じたまま時速 120 km で運転してその中を通り抜けても車内にゆったり座ってマティーニなんか飲んでいる Apple 重役たちの髪の毛一筋さえ傷付かないほどだ。保存された状態は、デバイスを再起動すると忘れ去られてしまうのだ。
このバグに気付いた私は、深刻な板挟みに追い込まれた。素晴らしいはずの新機能を利用してせっかく TidBITS News を書き直したのに、その結果として以前よりも動作が 悪く なってしまったのだ！ TidBITS News 1.4 やそれ以前では、不格好な、単細胞な形で状態復帰が実行されていた。一時停止の際に、もしもユーザーが記事を読んでいたならば、その事実を保存し、その記事の識別子とスクロール位置も保存し、復帰の際に、もしも一から起動し直す場合には保存したものを復元しようと努めていた。確かに不格好かつ単細胞だったが、それでも 常に動作した。ところが今や、私は素晴らしい場所に行くつもりで間違った場所に連れて来られたようだ。この新しい内蔵の状態保存と復帰は、時々 にしか動作しない。いったい私はどうすればいいのだろうか？
私の決断は、Apple にいる人たちは当然このバグの存在に気付いているだろうという考えに影響され、いずれこのバグは修正されるだろうという期待に後押しされた。私には次のような選択肢があった：
内蔵の保存と復帰のメカニズムを利用することを止め、以前使っていた不格好な方法にすっかり戻す。この道に戻ろうという気は起きなかった。なぜなら、私のコードはとても醜悪で、ほとんど解読不能のものだったからだ。
二股に分かれたやり方にする。つまり、動作する場合には内蔵の保存と復帰のメカニズムを利用し、アプリが一から起動して保存と復帰のメカニズムが動作していないことが明らかな場合には以前の不格好なやり方に戻る、ということもできる。けれども、こには二つ問題があった。まず第一に、私の古い醜悪なコードが生き続けなければならないことを意味するけれども、私はそうしたくなかった。さらにそれより重要な問題は、もしも Apple が突然バグを修正したらどうなるのかという点だった。デバイスが再起動した後でも内蔵の保存と復帰のメカニズムが正しく働き出すことは容易に想像でき、そうなった場合に私の古い醜悪なコードが何かコンフリクトを起こさないとも限らない。
内蔵の保存と復帰のメカニズムのみを使い、いつか Apple がバグを修正してくれると期待することもできる。
私はその第三の選択肢を選んだ。そしてもちろん... もちろん！ Apple は今も、iOS 6.1 になっても、まだこのバグを修正していない。
そういう訳で、現状では、もしもあなたがデバイスを再起動すれば（あるいは、あなたが愚かにも何か標準外の方法で、例えばアプリ切替インターフェイスの「ブルブル揺れるモード」を使って TidBITS News を手動で止めてしまえば）すべての状態保存が失われる。アプリは まるでそれまで一度も起動されたことがなかったかのように 起動する。結果として、保存されたフィードは何もなく、もしもその時点でインターネット接続がなければインターフェイスは空白のままでエラー警告が出るようになる。当然ながら、もしもインターネット接続が あれば、まあ、たいていの場合はそうだと思うが、大して深刻な問題は起こらない。つまり、TidBITS News は改めてフィードのダウンロードをやり直し、記事のリストをリフレッシュするようにあなたが命じた場合と同じ動作をするだけだ。
結果として完璧ではないが、問題となる状況は十分に稀なものであって、たいていの人にとって悪影響を受けることはないはずだ。デバイスの再起動を頻繁にするユーザーはそれほど多くないと思うし、たとえデバイスを再起動したとしても、アプリが一から起動し直すのを見てもユーザーが腰を抜かすことはないだろう。実際、それこそがデバイスを再起動する 目的 の一つだとも言える。また、人々は普通アプリ切替でアプリを強制的に止めたりしないものだし、もしもそれをするのならば、その結果に責任を持つのは自分以外にないだろう。その次にそのアプリが一から起動し直したとしても、文句は言えないのではないか。（ただし、率直に言えば、文句を言う資格があると考える一人の読者から私は既に電子メールを受け取っているが。）忘れないで頂きたいが、再起動する際にインターネット接続がありさえすれば、結果は決して重大なものではない。
他方、一時停止の最中にシステム自体がアプリを止めた場合には、内蔵の保存と復帰のメカニズムが何の問題もなく働く。その次に TidBITS News を起動すれば、それがバックグラウンドで止められたのかそれとも単に一時停止されたままだったのか、あなたが見分けることは事実上不可能なはずで、あなたが前回見ていた時点で保存されたフィードとインターフェイスが、きちんとその通りに再現される。
コメントリンク13552 この記事について | Tweet リンク13552
文： TidBITS Staff: [email protected]
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
Scrivener 2.4 -- Literature & Latte が Scrivener 2.4 をリリースし、長文執筆プロジェクトに特化したこのワードプロセッサにたくさんの改良や修正を加えた。（Scrivener を使って脚本や小説、学術論文、その他を書く方法について詳しくは、Kirk McElhearn の "Take Control of Scrivener 2" をお読み頂きたい。）今回のアップデートでは、Retina ディスプレイ対応、グローバルとプロジェクトベースで別々のコンパイルプリセット、コンパイルの際に標準の Adobe Digital Editions ページを含めるオプション (iTunes Producer に持ち込むファイルに含めた場合のエラーに備えてこのオプションのチェックを外すこともできる)、前付け部分の後で (あるいはチェックを外した場合は一番初めのページで) Kindle ブックを開始するオプション、脚本用シンタックス Fountain のサポート、Scapple のメモを Scrivener のフリーフォームコルク板モードへドラッグできる機能を追加し、Find and Project Replace パネルではテキストフィールドを大きくするとともに不可視文字を表示することもできるようになった。修正されたバグとしては、プロジェクトが二日間以上開いていた場合に scrivenings モードに施した変更が保存されないことがあるという重大なデータ喪失問題、新規プロジェクトを作成した直後にレイアウトを適用した場合に起こったクラッシュ、サンドボックス化された Mac App Store 版がプロジェクトをテンプレートとして保存できなかった問題、などがある。
Scrivener 2.4 は Literature & Latte ウェブサイトのダウンロードページから二つのバージョンで入手できる。一つは Mac OS X 10.6 Snow Leopard またはそれ以降用 (これは Mac App Store からも入手できる)、もう一つは 10.5 Leopard および 10.4 Tiger 用だ。この記事を書いている時点で、 Mac App Store にある Scrivener はまだバージョン 2.3.1 のままだ。しかしながら、デモ版を Literature & Latte サイトからダウンロードしてそれであなたのシステム上の Mac App Store 版を置き換えれば、デモ版が通常通りに登録されたバージョンとして動作する。(Literature & Latte からも Mac App Store からも新規購入 $45、無料アップデート、35.7 MB (10.4/10.5 版は 31.4 MB)、リリースノート)
CrashPlan 3.5.2 -- Code 42 Software が CrashPlan 3.5.2 をリリースした。人気あるこのインターネットバックアップソフトウェアに対する小さなメンテナンスリリースだが、一つだけ大きな変更がある。Mac OS X 10.4 Tiger がサポート対象から外れた。（CrashPlan について詳しくは、Joe Kissell の "Take Control of CrashPlan Backups" をお読み頂きたい。）CrashPlan サポートページによればバックアップもリストアも引き続き動作するはずだが、今後のバージョンの機能を利用できるためにもより新しいバージョンの Mac OS X にアップグレードすることを勧めている。CrashPlan 3.5.2 では、Retina ディスプレイ対応、Java 7 への対応、それから日本語、ポルトガル語、中国語 (簡体字)、中国語 (繁体字) のローカライズ版が追加された。また、一部のユーザーに起こっていたウェブリストアの際の問題を修正し、クロスプラットフォームのコンピュータ採択を改善し、システムがスリープから目覚めた際にメニューバーが消えてしまわないようにした。10.5 Leopard またはそれ以降の走る Mac ではアプリが自動的に自分でアップグレードする（ただしそれには数日かかることもある）ので、必ずしも手動で CrashPlan 3.5.2 をダウンロードする必要はない。(30 日間の CrashPlan+ オンラインバックアップサービス付きで無料、21.2 MB、リリースノート)
DEVONthink と DEVONnote 2.5 -- その情報管理アプリのシリーズに大幅な同期機能の強化を施して、DEVONtechnologies が DEVONthink の三つの版すべて (Pro Office、Pro、Personal) と DEVONnoteをいずれもバージョン 2.5 にアップデートした。今回の新リリースでは、Dropbox、WebDAV サーバ、あるいは自分でマウント可能なドライブなどを使って複数のコンピュータや保存場所との間で、または同じローカルネットワークあるいは VPN 上で動いている他の DEVONthink との間で、データベースの同期ができるようになった。同じ "sync store" に同僚たちがそれぞれアクセスでき、オフラインで作業をした後ですべての変更を（ローカルまたはリモートで）手動ででも自動ででも同期させることができる。（詳しいことは、Joe Kissell の "Take Control of Getting Started with DEVONthink 2, Second Edition" をお読み頂きたい。）
三つの版の DEVONthink も DEVONnote もすべて、タグ付け機能が改善され、書類リストに Tags カラムが付いて複数の項目を手軽にタグ付けできるようになった。DEVONthink Pro Office ではウェブ共有機能が改善され、書類をアップロード・作成・改名・移動・消去する機能とテキストを編集する機能が提供されたほか、画像を変換したり、スキャンして作った PDF を検索可能 PDF に変換したりすることもできる。Mac ベースのウェブブラウザに加えて、フルのウェブインターフェイスは iPad 上の Safari でも走る。
DEVONthink 2.5 の公開ベータ版を使っていた人は、最終版を使うより前にあらかじめ既存の sync store フォルダを（ファイルサーバ、WebDAV ドライブ、あるいは Dropbox から）削除しておく必要がある。(いずれもアップデートは無料。DEVONthink Pro Office 新規購入 $149.95、 リリースノート。DEVONthink Professional 新規購入 $79.95、リリースノート;。DEVONthink Personal 新規購入 $49.95、リリースノート。DEVONnote 新規購入 $24.95、 リリースノート。 TidBITS 会員には DEVONnote もいずれの版の DEVONthink もそれぞれ 25 パーセント割引)
DEVONthink と DEVONnote 2.5 へのコメントリンク:
PDFpen と PDFpenPro 5.9.5 -- Smile が PDFpenと PDFpenProをバージョン 5.9.5 にアップデートした。これら PDF 処理プログラムで、いくつかの誤作動を解消するための、小さなメンテナンスリリースだ。今回のリリースでは、Full Screen モードに入った際に現在のズームレベルを処理する方法を改善し、内部的通知をする際にクラッシュが起こる可能性があったのを避け、ページリンクを辿る際に稀に起こった問題を修正し、起動時にウィンドウを元に戻す際のサイドバーの初期化を修正している。詳しい説明書としては Michael Cohen の "Take Control of PDFpen 5" がある。(新規購入 $59.95/$99.95、TidBITS 会員には 20 パーセント割引、無料アップデート、47.5/48.5 MB)
PDFpen と PDFpenPro 5.9.5 へのコメントリンク:
文： TidBITS Staff: [email protected]
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
今週は外部の記事で素晴らしいものがたくさんある。南カリフォルニアの KCRW ラジオ局で Adam Engst が 4 分間のインタビューを受け、最近の TidBITS スタッフ円卓会議にヒントを得た New Republic 記事が出た。Rob Griffiths は Siri と Google 音声入力テクノロジーを比較し、Dan Moren と Lex Friedman は iCloud が黙って一部の電子メールを床に落としてしまう様を検討する。また、Panic 社の人たちが（弓のこを使って）Apple の Lightning Digital AV Adapter 内部に極小型のコンピュータを発見する。さらに Apple が iTunes U での 10 億ダウンロードを発表し、元 Apple エバンジェリスト Guy Kawasaki が将来のスマートフォンのアドバイザーとして Google の Motorola グループに参加する。
KCRW ラジオで Apple を分析 -- Adam Engst が KCRW ラジオ (南カリフォルニアで一番の NPR 系列局) で Steve Chiotakis のインタビューを受け、素敵な説明を展開した。話題となったのは、Apple にはもともとどんな魅力があったか、iPhone と iPad はどんな意味で驚くべきものであったか、現在 Apple が以前より多くの競合相手に直面しているのはなぜか、同社は今後どのような課題に直面することになるか、といった点だ。
New Republic でブランドにがっかりする -- 今になっても私たちが Apple を支持し続けるのはなぜかを検討したスタッフ円卓会議が New Republic の注目を得た。Lydia DePillis が記事 "Apple Agonistes: What happens to Mac fanatics when the brand bums them out?" (Apple 闘士： ブランドにがっかりした時、Mac の熱狂的ファンに何が起こるか) の中で、私たちの円卓会議を引用したのだ。彼女は適切な人選をして多くの人たちにインタビューし、その結果この記事には現在 Apple コミュニティーの中で皆が感じている不安のいくつかが捉えられている。
Macworld、iCloud が黙ってする電子メールフィルタリングを追跡 -- 別に新しいニュースでも何でもない。Apple はずっと以前から一部の電子メールを黙って削除しているし、時には TidBITS のメールを削除したことさえある。今回 Dan Moren と Lex Friedman は、iCloud が特定の語句を含んだメッセージをユーザーに何の断わりもなく削除しているやり方を説明する。これはその語句が zip 圧縮された PDF 添付書類の中にある場合にさえ起こる。だから、もしもあなたに届くはずのものが届かなかったならば（あなたが気付けばの話だが）送信相手に頼んで別の電子メールアドレスに送り直してもらうのがよいかもしれない。
Rob Griffiths が Siri と Google Search を比較 -- 私たちは Siri が大好きだが、はたしてこの Apple の音声認識テクノロジーは現在最高のものなのだろうか？ Macworld 記事で、Rob Griffiths が Siri と iOS 用 Google Search アプリの音声入力機能とを比較し、Google のシステムの方が「より良く、高速で、より直観的だ」という結果を得た。Apple が Google の音声入力を iOS の中で Google 自身のアプリの外へ出ることを許すことなどあり得ないが、それでも Apple は Siri を Android や Chrome OS の音声入力と競い合えるレベルに保つ必要がある。
Panic、Lightning AV アダプタの中に極小コンピュータを発見 -- iPad から HDTV へのビデオ出力の際の奇妙な挙動に困惑した Panic 社の人たちは、弓のこを手にして Apple の Lightning Digital AV Adapter の中を調べてみた。驚いたことに、彼らがその中に発見したものは極小型のコンピュータのように見え、プロセッサ一基と 2 ギガビットの RAM (参考のために言えば、初代の iPad に内蔵された 256 MB の RAM と同等のもの) が組み込まれていた。Panic が当初推測したのは、このプロセッサが AirPlay 信号を出力しているのではないかというものだった。（それならば圧縮の副作用がスクリーン上に現われるのが説明できる。）しかしながら、a匿名であるがどうやら知識豊富な人物（Apple で働いているのではないかと推測される）からのコメントによれば、アダプタをこのようにするやり方によって「地球上にあるどのデバイスにも出力することが基本的に可能となる、エンドポイントのバスがどんなものであっても (HDMI も、DisplayPort も、また将来発明されるどんなものでも) ただそれに対応するアダプタを作ってそれを Lightning ポートに差し込むだけでそこへ出力できるようになる」とのことだ。ぜひ試してみよう！
iTunes U で 10 億のダウンロード -- Apple が、iTunes U コンテンツのダウンロード数が 10 億本に達したと発表した。iTunes U がマスコミの注目を集めることはあまりないけれども、これは Apple にとって最も重要なプロジェクトの一つかもしれない。1,200 以上の大学に加え、1,200 以上の K-12 (幼稚園から高校) に属する学校や教育学区が、2,500 以上の一般に公開されているコースや何千もの非公開コースを提供しており、iTunes U のコースの中には 25 万人以上の学生が受講しているものもあって、iTunes U アプリのダウンロードの 60 パーセント以上がアメリカ合衆国以外からのものとなっている。要するに、iTunes U は驚くべき教育資源であるということだ。
Guy Kawasaki が Google の Motorola Group に参加 -- 元 Apple エバンジェリストであった Guy Kawasaki が、携帯電話メーカー Motorola (現在 Google の所有) でアドバイザーの職を得た。彼は製品設計、ユーザーインターフェイス、マーケティング、ソーシャルメディアに注力する予定で、Apple 社内や Macintosh 世界で働いた彼の経験が将来の Google フォンにどのような変化をもたらすことになるのか興味深い。
TidBITS は、タイムリーなニュース、洞察溢れる解説、奥の深いレビューを Macintosh とインターネット共同体にお届けする無料の週刊ニュースレターです。ご友人には自由にご転送ください。できれば購読をお薦めください。
非営利、非商用の出版物、Web サイトは、フルクレジットを明記すれば記事を転載または記事へのリンクができます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありません。
告示：書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。
TidBITS ISSN 1090-7017©Copyright 2013 TidBITS: 再使用はCreative Commons ライセンスによります。
, 
日本語版最終更新：2013年 3月 8日 金曜日, S. HOSOKAWA