あなたが今週号をお読みの頃には、Google Reader はもうビットの墓場の中だ。人気のあったこの RSS リーダーおよび同期サービスは、2013 年 7 月 1 日以降閉鎖される。けれども RSS ファンに喜んでもらおうと、Josh Centers が最良の代替製品をいくつかまとめてみた。インターネットのニュース見出しなんか見ても楽しくないという方は、Sky Gamblers: Storm Raiders で Battle of Britain の腕試しをしてみてはいかがだろうか。このゲームでは Mac、iPhone または iPad の上に第二次世界大戦の航空戦が再現される。もっと思慮に富んだ時間の過ごし方をしたいという方には、Michael Cohen が電子ブックにおける脚注の役割に踏み込み、Steve Aquino が法律上失明の身であってもフリーランスのライターとして働けるようになるために Markdown 言語がどのように役立ったかを分析する。また、iOS 7 において Apple の教育用オンラインサービスが 13 歳未満の子供たちに無料で開かれると約束されていることを紹介する。最後にもう一つ、私たちは新しい試みとして、Jeff Carlson が現在執筆中の電子ブック "Take Control of Your Digital Photos" を TidBITS 会員のために一連の記事の形にしてみた。どうぞご覧頂きたい!
記事:
----------------- 本号の TidBITS のスポンサーは: ------------------
---- 皆さんのスポンサーへのサポートが TidBITS への力となります ----
文: Josh Centers: [email protected], @jcenters
訳: 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>
Children's Online Privacy Protection Act (COPPA) がオンラインの子供たちを保護するために議会を通ったのは 1998 年であったが、その結果 13 才未満の子供たちはオンラインサービスから除外されてしまうケースが多くなってしまった。サービス提供者は彼らの個人情報を収集するためには 13 才未満の子供の親からの同意を取り付けることが義務付けられたが、それ程の手間をかける価値がない場合が多く、多くの提供者は、Facebook の様な、幼い子供たち全部をアクセス禁止にしてしまった。
Adam Engst が前に "嘘をつけと子供たちに教えるのは COPPA" (15 November 2011) で書いたように、この法律及びその意図とは異なる結果は教育におけるコンピューティングに対する巨大な障害となり、子供たち及びその親たちに有用なサービスにアクセスするために年齢データを偽装させることとなっている。不幸にして、学校はそうあからさまに法を破ることは許されないので、iTunes U や iCloud といった Apple サービスは 13 才未満の子供たちのいる小学校や中学校のクラスでは使えないものとなってきた。教育現場では iPad が広く採用されているにもかかわらずである。
幸いにして、教育専門家 Bradley Chambers が一つの解を発見 し Apple はそれを iOS 7 に盛り込むと約束している。Apple の iOS 7 と教育のページには次の様な記載がある:
Apple ID を持つ学生たちは、iTunes U, iCloud バックアップといった素晴らしいオンラインサービスへのアクセスという改善された個人経験を楽しむことが出来、そして新しい Volume Purchase Program の中でライセンスを受けることが可能になる。そして今や学校は一つのプログラムを通して Apple が 13 才未満の学生に対する個人的な Apple ID に対する検証可能な親の同意を得るのを手助け出来るようになる。
これは教育者にとっては素晴らしいニュースであり、そして学校で iTunes U コンテンツを使えるということは多くの色々なレベルでの一大改革となり得る。Chambers が言うように、"これはものすごいことである。"
コメントリンク13877 この記事について | Tweet リンク13877
文: Adam C. Engst: [email protected], @adamengst
訳: M.Sugimoto <dfbia300@kcc.zaq.ne.jp>
Apple が最初に iPhoto を登場させたとき、私たちがそれまで写真を溜め込むために使っていた靴箱の代わりとしてそれが使えるはずであったことを、皆さんは覚えているだろうか?最初はうまくできた。しかし、時が経つにつれて、私たちが撮ったディジタル写真の数が増えるにつれて、最初は迅速だったものが、その後見たところ、指数関数的に iPhoto はついていくことがどんどん不可能になっていった。多くの人にとって、iPhoto はあなたが写真を取り込み、むだに溜め込む、まさに仮想の靴箱になってしまった。
私たちは一つの解決方法をもっているが、非常に多くの問題と同じで、この問題に対するには何のツールを使うかについての解はあまりなく、どのように作業するかに関してはより多くの方策がある。間違いをしないで欲しいのだが、正しいツールを選び、構築することは重要で、それはあなたが私たちの上級編集者である Jeff Carlson から学ぶ全体的アプローチの一つである。Jeff は賞を受賞した写真家で、ここ数年にわたり "The iPad for Photographers(写真家のための iPad)" のような人気の高い写真本の作者である。しかし、重要なことは、可能な限り自動的に、かつ時間を費やさずに、写真を取り込み、選択除去し、レート付けし、体系化する、最高の方法を学習することで、Jeff の現実のアドバイスを習慣に変えることである。
おそらくあなたは私たちの解決法が Take Control 電子ブックの形式をとることを期待しているかもしれない。そしてまさにそうだが、あなたのために新しい取り組みもある。今まさに Jeff は "Take Control of Your Digital Photos" 執筆の最中で、まだ購入はできないが、すぐに読み始めることはできる。電子ブックの導入章は今すべての人が " Take Control of Your Digital Photos, Chapter 1" として読める状態で、TidBITS ウェブサイトで記事として各章を投稿し続けるつもりだ。もしあなたがそう呼ぶならば、"チャプティクル"と呼ぶ記事として、毎週記載され、次の 6 週から 8 週かけて編集される。
最後までいけば、本全体を読むことができるだろう...もしあなたが TidBITSメンバーシッププログラムに参加しているならば。私たちはいつも TidBITS メンバーに対してすべての Take Control books に関しては 30 パーセントの割り引きを、多様な種々の Mac ソフトウエアに関しても大幅な割引きを提供してきた。しかし、TidBITS メンバーシップをさらに価値あるものにするために、すべての TidBITS メンバーは本全体を各章ごとに読むことができるようにした。ちょうどどんな記事もそうであるように。(各章を見るためには、 メンバーアカウントで TidBITS ウェブサイトにログインする必要がある。)唯一の制約は本の他のパートへのリンクが生きていないことで、それらパートがまだ完成していないためだ。
ちょうど他のどんな TidBITS 記事もそうであるように、各章にコメントを残すことさえでき、実際あなたにがんばってコメントして欲しい!Jeff が直接返事をするだろうし、プロジェクトが継続するにつれて、本のテキストを適切に修正することだろう。私たちはメンバーに対して、章を発行するにつれて新章の通知をする。この本の各章も含め、あらゆる TidBITS 記事を、記事が出版され次第個別の電子メールで受け取るように設定することも可能だ。そのためには、会員専用の Your Subscriptions ページで the Receive All Articles チェックボックスを選んでおけばよい。個々の章は TidBITS サイトで何回でも無期限にアクセスできる。そして、本が完成したあかつきには、本全体を古典的な Take Control PDF、EPUB、そして Mobi フォームで読みたいなら、30 パーセントのメンバー割引きが相変わらず適用可能だ。
これらすべてが可能となったのは、私たちが使っているいくつかの新しい制作ツール、すなわち Nisus Writer Pro と Joe Kissell が書いた Markdown 変換マクロと、Markdown を EPUB に変換する Leanpub 出版エンジンとの組み合わせのおかげだ。今回個々の章をオンラインの記事にできたのは、Leanpub がうまくフォーマットされた HTML を抽出してくれるおかげだ。(TidBITS 出版システムは Markdown もネイティブで使用するが、EPUB から抽出した HTML に依存することによってさらなるフォーマットの柔軟性を得ている。)このシステムは洗練されていると同時に、装飾豊かだが、作るには楽しいことがたくさんあった。新しい電子ブック作品を楽しんでください!
コメントリンク13882 この記事について | Tweet リンク13882
文: Steven Aquino: [email protected], @steven_aquino
訳: M.Sugimoto <dfbia300@kcc.zaq.ne.jp>
数ヶ月前、私は地方学区での 11 年間の仕事を辞めるという大変辛い決断をした。そこで私は特別なニーズをもった就学前児童たちとともに働いていた。私が決断に至ったのにはいくつかの要因があったが、その主たるものは私が 真にしたいこと、文章を書くということを追求するためにもっと時間を割きたいということであった。
私は執筆するということに対して、いつも深い愛情をもっていた。そしてそれにさらに力を尽くすこと、それに関して趣味から芸術作品へ高めること、ができるときをいつも夢見てきた。少なくとも最初は私のキャリアを変えるという決断はうまくいっている。この記事を含め、執筆の仕事を得ることはうまくいったし、私の記事の多くは、例えば、The Magazine の中で掲載された "Re-Enabled" のように、賞賛を受け、そして、Apple ウェブサイトのホットニュースセクションで特集された。私の執筆が成功した理由の一つは私がユニークな視点から執筆していることだと思う。
視覚的障害者(厳密に言えば、 法的盲目者 )として、Apple おたくとしても自信があるのだが、私はアクセシビリティーテクノロジーが私のデバイスの使用方法に、とくに iOS に関するものに、どのように積極的に影響を与えるか、自信をもって話すことができる。このような確信をもってこのトピックを書けることが視覚障害者であることの大きなメリットであり、私はそれを当然とは思っていない(つまり、得難いことだと思っている)(明らかに、法的盲目であることに対抗するのは、どうがんばってもいいことではないが、この姿勢は不快な環境を最大限に活用する。)私の以前の生徒たちの行動を観察すること同様、私自身の経験が障害をもつ人たちに適用可能な、現代的で、タッチベースのインターフェースに対する興味を形成することに役立った。私は Apple のデバイスが好きだし、それとつきあう最高の方法をいつも探している。私のようなユーザーにとって幸いなことに、Apple は VoiceOver といったその種のことを実現するための理解しやすい一連の道具を提供することにおいて、大変優れた仕事をやってきた。
私の執筆する点から言えば、私が書くことの すべて はウェブのためである。フリーの立場か、あるいは個人的ブログのために書く立場かに関わらず、私は他の多くの人たちと同じように、Markdown ですべてを組み立てる。今まで数年間Markdown を使用してきたし、絶対的に大好きである。Markdown に大変馴染んでいるので、まるで第二の性格のように感じている。Markdown を見つける以前、そして自由契約を始める以前は私はブログを独自のやり方で書いていた。私のサイトは WordPress の上で走り、投稿したいときにはいつでも WordPress CMS(コンテンツマネジメントシステム)にログインし、ポストエディターを使って書き込んでいた。確かに機能的だが、そのインターフェースは不細工で使いでがよくない。さらに言うと、テキストをスタイルするために使用する小さなフォーマットツールバーをナビゲートするにも多大な時間がかかるようになっていた。私は視覚的障害なので、小さなカーソルでツールバーボタンあたりをうろうろすることはうまくない。結局 CMS を使うことに疲れて、代わりとなるものを求めた。
John Gruber の Markdown に巡り会ったのはそのときで、私はすぐに恋に落ちた。Markdown に慣れていない人のために言うと、Markdown は 2004 年に開発された単純なプレーンテキストフォーマット構文ツールで、書きやすく(まあ、HTML よりは容易な)、そして構造的に有効な HTML に変換することができる。おもしろいことに、Markdown が生まれるきっかけとなったものの一つは setext、すなわち structure-enhanced text であって、それは 1992 年の昔にTidBITS 発行者 Adam Engst からの助言も得て Ian Feldman が作ったまた別のプレーンテキストフォーマットであり、その後今に至るまで TidBITS で使用されている。
Markdown で私の生活はよりよいものに変わった。制約のある私の視覚の下でもグラフィカルインターフェースの扱いが容易になったばかりでなく、ほとんどすべてのドキュメントにおいてプレーンテキストのみを使えば済むようになった。もはや多くのツールバーであふれたワープロで作業する必要はなく、リッチテキストフォーマットで悩む必要もなくなった。Markdown を見つけたことは真にある意味で解放されることになった。
しかし意図していなかったことなのだが、Markdown の性格から考えると、それが実は素晴らしいアクセシビリティーツールであることに気がついた。なぜなら、Markdown は書いている間、目の緊張を軽減するのだ。Markdown の構文の単純さは私が単語をイタリックにしたり、リンクを挿入したりしたいときにいつでもスクリーンを見る 必要 がないようにしてくれる。私の目は大多数の人々よりも敏感で、私は目の疲れや苦痛を感じるためにそれほど長時間スクリーンを凝視できない。スクリーンを見なければいけない時間が減れば減るほど、私の目の調子はよくなる。こうして、Markdown を使ってすごいことはボタンやメニューオプションの位置を確認するためのむだな時間を費やす必要がなくなることだ。単にキーボードをちょっと見下ろして、確実に正しいキーを押すだけだ。
視覚的に障害があるという状況で、書くために何が必要か、あなたがよく考えるまで、Markdown のことをイネーブリングテクノロジーと考えることは奇妙に思えるかもしれない。大部分のソフトウエアは私自身のようなユーザーを考慮して設計されていないから、それは 難しい ことだ。それが視覚に障害のある人々のために ZoomText のような特別なツールがある理由だ。しかし、スクリーン拡大ツールやリーダーツールが一定の地位を得ているけれど、私が好む以上に複雑すぎる。
ツールバーを 200 パーセントに拡大し、スクリーンの場所を占める代わりに、私はツールバーとの関わりを完全に断ちたかった。それをまさしく Markdown がする。ツールバーとメニューの問題からユーザーを解放する。一方で、使用するワープロやテキストエディターがなんであろうとその上に重なって出るスクリーン拡大ツールやリーダーを扱わねばならない負担をも同時に取り去る。
ツールバーをナビゲートする際のトラブルは視覚障害者だけの問題ではないことは注意すべきことだ。この不快感は通常の視覚をもつ人々の間でも共通の問題であって、彼らは Keyboard Maestro のような長く使用されてきたアプリを使って、文字を判読する必要や小さな不可解なツールバーボタンをクリックする必要性から自らを解放する。さらに言えば、キーボードのみを使用することによって、Pages のようなワープロを使用することはある程度可能だ。実際、私は優秀なロンチャーアプリである Alfred と同様に、作戦として Mac OS X のたくさんのキーボードショートカットも頼りにしている。他の多くのツールと同じく、とくに私の視力の制約を考慮すれば、私はこれらツールを私のワークフローにとって欠くことのできないものと思っている。
"Markdown が私の生活を変えた!"という声明は、誇大広告のように聞こえるかもしれないが、それは少なくともある程度、真実だと信じている。私はWordPress CMS や Pages のようなアプリで仕事をやってきたが、私の執筆の生産性の相違は当時と今とでは大変大きなものになっている。
Markdown は私が愛するものをさらにもっとアクセスしやすいものにしてくれた。手助けして私にさらに 少し だけよく見せてくれる何かは大事なもので、私の目が必要以上のいかなる苦痛も受けないことに感謝しているのが分かる。そして私にとってツールバーは"拷問"を意味する。この意味で、Markdown はアクセシビリティーのよい例となっている。なぜなら、Markdown は私の視力の身体的な制約にもかかわらず、私の執筆体験の質を完全に変えるからだ。
私の執筆体験の改善は いかに 私が書くかに影響を与えるのみならず、私が 何を 書くかにも影響を与える。視覚をそれほど緊張させなくてすむから、真に問題となること、すなわちコンテンツに集中することができる。私は目の障害にもかかわらず、一人の作家としてやり抜き、成功を楽しむことができているという事実を非常に誇りに思っている。
Markdown は私の視力を改善できないが、私を手助けして、障害を有するテックおたくとして、私のユニークな視点をさらに容易に共有させてくれることに役立つ。これらの個人的な話は貴重なものだと考えている。なぜならば、そうした話は(私の思うところによれば)Apple ユーザーベースの中で過小評価されている一つのセグメントの存在に気づかせる力となるからだ。WordPress CMS を使うことはいつも苦しい戦いのように感じた。すべてのボタンとメニューを区別するために常に戦っていた。しかし、Markdown を使うと少しも苦痛ではなくなった。私がするすべてのことは 書く こと、そして、それがそうあるべき道だ。
私は Markdown の福音を説く最初の人でもなければ、おそらく最後の人でもない。ウェブ出版をする作家の間で Mardown の人気はその単純さと使い易さの証しであり、そしてその周囲に多くのツールが出現した。とは言っても、Markdownの美点を異なる視点から賞賛することはわくわくする。私自身に Markdown を教えることは、私のインターネットの声を設立することに向かって仕事をする限り、おそらく私が今までに下した最高の決断だった。
Markdown のおかげで他の人たちをアクセシビリティー共同体に触れさせる言葉を書くことに役立つ。iOS のアクセシビリティーテクノロジーが障害をもつユーザーや彼らの iPhone や iPad に与える影響を説明することで。そのために私はMarkdown の John Gruber に大きな恩義を感じている。アクセシビリティーツールだという 意図 はなかったかも知れないが、私にとって Markdown は気がつかないうちに、私のツールキットの全体部分になってしまった。毎日それを使い、その存在に絶えず感謝している。
[Steven Aquino は新進のフリーのテクノロジー作家で The Magazine、Macworld、TidBITS、Tech.pinions、そして Enhanced Vision に寄稿してきた。彼はまたパーソナルサイト、Steven's Blog に定期的に寄稿している。(支払いのある)著作の世界に飛び込む以前は、特別なニーズを持つ就業前児童へのクラス支援者として、彼の地方学区のために 11 年間働いた。]
コメントリンク13865 この記事について | Tweet リンク13865
文: Michael E. Cohen: [email protected], @lymond
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
Apple の Worldwide Developer Conference (WWDC) も終わり、Jony Ive に率いられた新しい iOS のインターフェイス改訂と、それが異素材模倣(スキューモーフィズム)のデザインを(ほぼ)完全に捨て去ったことに関する耳をつんざくような大声の議論は、今やインターネット上の金切り声のやり取りへと移行して、iOS 7 で新たにデザインし直されたアイコンがはたして猫のパジャマ(最高に素晴らしいもの)か犬の朝飯(見苦しいごちゃまぜ)かという醜い罵り合いとなりつつあるけれども、そのような大騒ぎにかき消されがちなのが、異素材模倣のデザインがどのような場合に適切でどのような場合にそうでないのかという、冷静な議論だ。
そんなオタク用語には馴染みがないという方のために、"skeuomorph" (異素材模倣) という用語のいくつかある定義のうちの一つを、Wikipedia から引用しておこう:
デザインまたは構造の要素であって、元来の品物においては必須の素材で出来ていたけれども、新たな素材を使って作り上げられた品物においてはそれがほとんどあるいは何も意味を持たないようなもの
Apple のユーザーインターフェイスデザインにおいて、異素材模倣に反対する意見を持つ側の人々からいつも槍玉に挙げられる例として、現行の Calendar アプリの革と破り取った紙、Game Center の緑色のフェルトのテーブルなどがある。つまり、アプリのインターフェイスがそのような見栄えであることが、使い方に関する手掛かりとしては実際何の役にも立たず、ただ実世界にあって似たような働きをする品物を思い起こさせるに過ぎないという実例だ。(例えば Calendar アプリで仮想のページを一枚破り取ることはできない - 私は試してみたから知っている。)一方、異素材模倣を支持する人々は、実際に役立つ異素材模倣の実例を挙げて反論する。例えば、Calculator アプリのボタン(iPhone スクリーンなどタッチして操作する場合は便利)などだ。
けれども、必ずしもすべての異素材模倣がグラフィックなインターフェイス要素とは限らない。もう一つ別の、一目で分かるとは言い難い種類の異素材模倣に、私は数ヵ月前、"Take Control of iBooks Author" の改訂版を作るため準備的な調査をしていたときに気付いた。それが、脚注 (footnote) だ。ウェブをいろいろ調べていると、Apple が新しくリリースした電子ブックオーサリングツール iBooks Author 2.0 に関する議論の中に、この全く新しいバージョンになってもまだ Apple が脚注の自動番号付け機能を装備してくれないというライターたちからの苦情(「非良心的だ」という言外の意味が汲み取れた)を何度も見かけた。
私の最初の反応は、「そうだな、そりゃ本当にひどいな」というものだった。そして実際、表面的にはそう見えた。なぜなら、ワードプロセッサと呼ぶに相応しいプログラムはほとんどすべて、脚注の自動番号付けが処理できるからだ。
けれども私は、この問題についてもう少しよく考えてみた。その際、過去にしばしば成功した技を使った。つまり、単純な質問を一つ、口に出してみた。
この場合、私が持ち出した単純な質問は「そもそも脚注とは何だろうか?」というものであった。そしてそこから、たくさんの関連する質問が生まれた。例えば「脚注は何の目的で使うのか?」とか「なぜ脚注は現在使われているような形になったのか?」とか、最後には最大の質問として「インタラクティブなデジタル本に、従来型の脚注が本当に必要なのか?」とかいったことだ。そういった質問に一つ一つ答を出しつつ、私には次第に真実が見えてきた。つまり、番号付けのされた脚注を iBooks Author が作るような種類の本の中で使用するというのは、実際一種の異素材模倣に他ならないということだ。
私がこの結論にどうやって達したかを説明するために、まずは私の最初の質問から話を始めたい。そもそも、脚注とは何だろうか?
見た目だけを言えば、脚注は印刷されたページの一番下にあるテキストで、通常は小さな文字を使ってメインのテキストと区別できるようにし、多くの場合先頭に何らかの記号または数字を上付き文字にしたものが付く。脚注のテキストの前に付いた記号または数字は、そのページのメインのテキストの文中にも同様の上付き文字の記号または数字として、対応する個所に表示される。
では、脚注は何の目的で使うのだろうか? 実際のところ、使う目的はいろいろあり得る。メインのテキストの中の一部分を説明したり発展させたりするため、引用や翻訳を提供するため、あるいは何らかの注釈を付けたりするためといったことが考えられる。個々の脚注がどんな目的のものであるにせよ、一般的な目的はと言えばそれはメインのテキストの文章の流れを妨げることなく追加の情報を提供することにある。メインのテキストの中にある脚注マーカーが追加の情報の存在を示唆するが、そこには実際に表示されないのでテキストの流れが急停止することはない。脱線した話にぶつかってテキストを途切れさせる代わりに、マーカーはただ単に脱線した話が存在することだけを示し、メインのテキストはそのまま流れ続ける。ちょうど、小川の中の小石のようなものだ。そこまで読んできた読者がメインのテキストの中にマーカーを見つければ、読み進めてきたテキストを中断してその追加の情報を探して読むか、それともそのままマーカーを無視して読み続けるかは、読者の判断に任される。
別の言葉で言えば、本文中の脚注マーカーが追加コンテンツの存在を示し、脚注自体がそのコンテンツを提供し、脚注の直前にあるマーカーがメインのテキストと脚注コンテンツとのビジュアルなリンクを提供するわけだ。
そこで私の次の質問が浮かぶ。なぜ脚注は現在使われているような形になったのだろうか?
この質問に対する答は二つの側面を持つ。制作上の側面と、使い勝手の側面だ。
制作の実務上の観点からは、本をタイプセットする際にテキストの行の中に上付き文字の記号を含めるのはごく簡単な作業だ。それに、一つのページの中に二つの種類のセクションを作って、片方にメインのテキストをページの一番上から流し入れ、もう片方に脚注のコンテンツを下に詰めて入れるというのは、確かにタイプセットの作業としては困難なところもあるが、それでもタイプセット前段階の原稿に書き込まれた注釈や、欄外や行間のあちこちに思い付くままさまざまの形式で加えられた追記を、活字を使って忠実に再現することに比べればずっと簡単な作業だ。
使い勝手の観点からの答は、既に述べてきた。読者にとって見つけやすいと同時に、過度に気を散らされることがない。また、示されたコンテンツを見つけるのも容易だ。読者がしなければならないのは本文中にあるマーカーと、脚注の先頭にあるマーカーとを対応付けることだけで、ちらっと視線を走らせるだけで十分できるだろう。
読者にとって最悪のケースでさえ(タイプセットをする者にとっては最良のケースでもあるが)注釈を脚注でなく巻末の注とすることができる。この場合、読者は本のページを繰ってそのマーカーに対応する巻末注を探さなければならないが、それでも非常に困難とまでは言えない。読みかけのページに指を入れておいて、あるいはペーパークリップや紙のしおり(ブックマーク)を挟んでおいて、素早く巻末注のページに行き、ここでもう一度ちらっと視線を走らせて、本文中のマーカーに対応する注釈を見つければよい。
けれども、今言ったことはすべて、印刷された本についてのことだ。スクリーン上では、一度に一つのページ全体が見えているとは限らないので、ちらっと視線を走らせるだけでは本文中のマーカーとページ下端にある注釈のマーカーとを見比べることができないかもしれない。さらに悪いことに、デジタルな環境においてはページという概念そのものが存在しないこともある。その代わりに、読者は注釈マーカーをクリックして注釈のコンテンツを見ることになる。これこそ、ハイパーテキストの奇跡だ。
でも、ここでもやはり、そういうマーカーをクリックするのは別に困難ではない。マウスポインタやトラックパッドは正確なデバイスなので、スクリーン上のテキストの中にある小さな脚注マーカーをクリックするのは、たいていのコンピュータユーザーの能力の範囲内にある。マウスやトラックパッドを使った他の操作に比べて少し高めの正確度が要求されるとしても。
けれども今の私たちはタブレット機の時代にいる。そこには、iBooks Author で作られたマルチタッチ本が存在する。ここでは、いろいろなことがより大きな問題となる。この世界においては、ポインティングデバイスはもはや精密な器具ではなくて、先の尖っていない、人の指先だ。それに、タブレットのスクリーンは一見ページのように感じられることがあっても、スクリーンのサイズやスクリーンの解像度による制限のため、タブレットのスクリーンに一度に表示できるテキストの量は限られている。
だから、印刷された本と同様に注釈をそのマーカーと同じページに含めるのは、タブレット上の表示領域が限られていることを考えれば無駄が多くなり、必ずしも効率的なやり方とは言えなくなる。他方、タブレット機はコンピューティングデバイスなので、マーカーから注釈へのハイパーテキストリンクを提供するのはお手のものだ。スクリーン上の限られたページの広さをメインのテキスト専用とし、注釈の内容はどこか他の場所に取り除けておく方が、ずっと良い結果となる。
それと同時に、印刷本で使われているごく小さな上付き文字の数字を本文の中に置いて注釈の存在を示すやり方をそのまま模倣し、そのごく小さな文字をハイパーテキストリンクにすれば、人間の指先で正確に押す目標としてはあまりにも困難なものとなってしまう。マウスやトラックパッドのようなポインティングデバイスではないのだから。
その結果として、印刷本で慣習となっている脚注マーカーや、同じページ上の脚注や巻末注などをそのままタブレット機の環境に持ち込めば、読者にとってみればずっと効率の悪いスクリーン面積の利用法となる(脚注の場合)か、またはいちかばちかのフラストレーションだらけの使用感となる(ハイパーリンクされた巻末注の場合)か、いずれかになってしまう。iBooks Author においてそのような印刷本の慣習を再現しようと試みるのは、結局は異素材模倣に他ならない。一つの媒体において必要であったデザイン要素を、それがあまり必要でない別の媒体に持ち込もうとするのだから。
注釈とそのマーカーが iBooks Author で作った本には必要でないと言っているのでは ない ことに、注意して頂きたい。そうではなくて、数字で番号付けられた注釈と上付き文字を使ったマーカーという 特定の実装方法 が、iBooks Author で作った本には必要でないと言っているのだ。
結局のところ、iBooks Author をよく見れば、たくさんの注釈機能が既に提供されている:
単語や語句を(小さな記号よりずっと指先でタップしやすい目標となる)選んでそれをリンクにし、別のページ上にある追加のコンテンツへと読者を導くようにでき、巻末注と同様の使い勝手がタップしやすい目標で実現される。
内蔵の Glossary ツールを使って文中の特定の単語や語句の定義や説明をポップアップで提供できる。こちらもまた、狙い易い目標をタップして呼び出すことができ、メインのテキストのみのスクリーンの上で余計な場所を取らない。
本題から逸れた話が長くなる場合には、ポップオーバーウィジェットが使える。グラフィック(小さいけれどもタップしやすいインライン画像)からのリンクでフローティングパネルが開き、その中に大量のテキストや画像を含めることができる。
結果的に、私は、iBooks Author に脚注の自動番号付け機能がないことに対して、一部の批評家たちのように腹を立てる気持ちにはなれない。それでも、将来の改訂版の iBooks Author でその機能が追加されれば、それは素晴らしいことだろうと思う。たとえ、タブレット上のインタラクティブなテキストで番号付けされた脚注にさまざまな問題があるとしても。そう思うのはなぜか?
まず第一に、ちっぽけな脚注マーカーが小川の中の小石のようなものだとすれば、下線や強調書体、あるいは色付けなどでハイライトされた単語もまた、少し大きめの石に過ぎない。それに、たとえ小さめのグラフィックのマーカーを埋め込んでも、やはり従来型の上付き文字の脚注マーカーに比べれば、ビジュアルにかさばる印象は否定できないだろう。
けれどももっと重要な点として、従来型の脚注の慣習には修辞的な意義がある。上付き文字で書かれた数字のマーカーやページ上にある注釈は、下線の付いた色付きのテキストやタップしやすい Pop-over リンクに比べて、ずっと重大なものに 見える。それは、何十年にもわたってこの慣習を用いてきた何千何万という本に受け継がれてきた重大さだ。文章が学問的に 見える ことで読者の信頼が増すとすれば、このような伝統に基づく重々しさは決して軽視すべきものではない。
Apple は、インタラクティブなテキストの中に伝統的な脚注を用いるための、言わば双方の長所を生かした解決策を見出すことができるはずだ。例えば、テキストの中に番号の付いた脚注マーカーを入れて、その後に続く単語とともに Pop-over リンクとなるようにすればどうだろうか。現行のインライン画像の代わりにするわけだ。けれども、たとえ Apple が単純にページの下部に自動番号付けされた脚注を入れるという普通のワードプロセッサと同様の機能を実装してくれただけであっても、そういうものを必要とする著者たちには大いに嬉しいことだろう。様式上の理由から、自分の執筆するインタラクティブなマルチタッチ本の中に伝統的な脚注の手法を使いたいという著者たちも多いからだ。インタラクティブな本だからといって、すべてがインタラクティブである必要はない。
他の多くの異素材模倣と同様、デジタルなテキストの中の伝統的な脚注もまた、注釈の問題に対する最良のインターフェイス手法とは言えないかもしれないが、だからといって価値が ない わけではない。スタイリッシュなメッセージはやはりメッセージだが、それはそれで何かしら価値あるものを伝達している。そのこと自体、異素材模倣に対抗して多くのデザイナーや批評家が全面戦争を挑んでいるこの時代に、じっくりと考えてみるだけの意味のあることではないだろうか。
コメントリンク13805 この記事について | Tweet リンク13805
文: Josh Centers: [email protected], @jcenters
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
訳: M.Sugimoto <dfbia300@kcc.zaq.ne.jp>
Google Reader の終了が目前に迫って、新たな RSS 同期サービスを探すべき時が来た。あるいは、探すなり諦めるなり決断すべき時が来た。2013 年 7 月 1 日以後は、ボスの Larry Page から土壇場の一声でもない限り、Google はきっぱりとスイッチを切り、打ち捨てられた Google 構想の墓場へと Reader を送り込むことになる。
Google が初めて Reader の終了を発表した際、私たちはその当時に利用可能であった候補者たちを見渡してみたが、正直言ってそこは乾いた不毛の土地と言わざるを得なかった。(2013 年 3 月 18 日の記事“Google Reader の代替を探る”参照。)自己ホスト型の手法を使う Fever は、開発者 Shaun Inman にとって 優先度の高い製品ではなかった。 Netvibes は私たちが注目したもう一つの製品であったが、アップデートを必要とすることが明らかだった。
けれども嬉しいニュースがある。その後開発者たちのコミュニティーが立ち上がり、デバイス間で RSS 購読の同期ができて欲しいと思う人たちが Google Reader に代わって使える有望な代替製品が、今はいくつか存在するようになった。ただ、そのいずれもまだ完璧と言うには程遠いのだが。また、前回私たちが気に入った Feedly も、さらに新しい能力を身に着けている。この記事では、これら競合する製品たちをそれぞれ調べて、複数のプラットフォームで動作し、サードパーティのサポートもあり、可能ならば持続可能なビジネスモデルも持つ、そのような最良の選択肢を見つけたいと思う。
まだそうしていない人は、まずはあなたの既存の Google Reader 購読を OPML に書き出し ておこう。以下に挙げるサービスはいずれも Google Reader の subscriptions.xml ファイルを読み込むことができるので、うまく働いて満足できる製品に落ち着くまでの間は、その書き出しファイルをなくさないようにしよう。
Feedly -- 前回 Feedly を調べた時点では、これが最良の Google Reader 代替製品であった。無料であり、複数のプラットフォームに対応し、既存の Google Reader アカウントから直接読み込むことができる。また、前回の記事でも触れたように、当時 Feedly は Normandy という名前の独自のサービスを構築中で、Google Reader に代わって同期のサービスを提供することを目指していた。Feedly は約束通り、6 月 19 日に Google のサービスから独自の基盤の上へと移行を果たした。その先見の明と、素早い行動に、心からの賞賛を Feedly に捧げたい。
Feedly はウェブ用と iOS 用それぞれにクライアントを提供しているが、既に RSS リーダーを持っていてそれに慣れ親しんでいる人のために嬉しいニュースがある! Feedly は、自社のクラウド API をサードパーティの開発者向けに開放したのだ。既に Reeder、 Mr. Reader, と Newsify の開発者たちがそれを採用している。いずれのアプリも、Feedly 対応を組み込んだアップデートを 7 月 1 日の Google Reader 終了以前に出す予定だ。(実際、Mr. Reader は既に 6 月 26 日に Feedly やその他のサービスに対応したアップデートを出している。)さらにもっと Feedly を魅力的なものとするため、Feedly は今回 自動化サービス IFTTT にもサポートされ、Twitter、Pocket、Facebook など他のサービスとの間で手軽に、かつ自動的にコンテンツを共有できるようになった。
サードパーティのアプリなど使いたくないという人は、Feedly のウェブアプリや iOS アプリを使って、数多く提供されるテーマや表示オプションを通じて好みに合わせた使用体験を楽しむことができる。三つのプラットフォームのいずれも、記事を雑誌風に、あるいは一連のカードとして、あるいは Google Reader 避難民のためには見出しのリストとして、表示することができる。
前回の記事で私が Feedly の難点として述べたのは、フィードの書き出しに対応していない点であった。けれども今回の閉鎖の直前になって Feedly にその機能が追加されたので、いつでも好きな時に他のサービスに移行できるようになった。
プラグインなしにブラウザ内でフィードを表示できる機能も Feedly に追加されたけれども、まだ塞がれていない欠落もある。フィードの中で検索する手段が依然として存在していないし、グループ共有機能もまだない。これらの機能は将来の Feedly でぜひとも加えて欲しいものだ。
現時点では、まだそうしていないのなら、とりあえず Feedly のアカウントを作っておくのは価値あることだろう。何より無料だし、サードパーティ同期のサポートもあるし、デスクトップ用と iPhone 用と iPad 用それぞれのクライアントもあるし、開発者たちはこの製品にしっかりと注力している。けれども私としては、Feedly がはっきりしたビジネスプランを打ち出してくるまでの間は Google Reader から書き出した私のデータを残したままにしておこうと思う。
Feedbin -- RSS 分野の新参者は有料の Feedbin で、単純なインターフェースと開発者のための API を月額 $3 で提供する。Feedbin でとくに私が好きな点は、私が選んだ RSS クライアントである Reeder が既に Feedbin をサポートしている点である。しかし、Feedbin のサポートは現在は Reeder の iPhone 版のみに限られ、iPad や Mac クライアントに関してはまだサポートがない。幸いなことに iPad の Mr. Reader の最新版もまた現在、Feedbin をサポートしている。また、Mac 用の ReadKit も、他のサービスとともに Feedbin を含めたアップデートがされている。
Google Reader から直接取りこむことはできないが、Google Reader のフィードを OPML で取りこむことができる。単に Settings を選択し、そこでImport/Export を行う。
ウェブ使用体験は Google Reader や Reeder のユーザーにとっては、なじみ深いものだ。フィードはタグ(フォルダー)として組織化され、また、個々にリスト化される。最左端のサイドバーのボタンはすべてのアイテム、あるいは未読アイテムだけを表示し、読むべきすべてのアイテムをマークさせる。新フィードはページトップのボックスに追加されるが、まだフォローするサイトのディレクトリーはない。
Google Reader 避難民は Feedbin が J と K によるナビゲーションを含むGoogle Reader のすべてのショートカットをまねていることがうれしいだろう。実はいくつかのレンダリング問題はあるのだが、Feedbin は Google Readerのデフォルトインターフェースよりも魅力的である。そして最近のサーバーアップグレードの後、同程度に速くなった。
iPad でウェブインターフェースを眺めると別の問題がある。基本的にはデスクトップウェブアプリのつめこみ版である。タッチは十分うまく機能するが、iPadがポートレートモードにあるとき、コンテンツそのものが押しつぶされたようになる。わたしは Feedbin のウェブインターフェースを使うよりは Mr. Readerに 追加の $3.99 を払うことを勧める。
全体的に言って、私は Feedbin が好きだ。ウェブアプリは満足のいくもので、すでに Feedbin はサードパーティーの堅いサポートを得るためにがんばっている。
Feed Wrangler -- Feedbin と同じく、Feed Wrangler は Google Reader に代わるまた別の有料の選択肢で、購読料が年間 $19 かかる。Feedbin と違って、iPhone と iPad 用に Feed Wrangler アプリがある。Feed Wrangler は David Smith によるもので、彼は、私のお気に入りの iOS お天気アプリの一つ Check the Weather の作家でもある。
Feed Wrangler はフィード管理に独自のアプローチをとっている。フィードを分類するフォルダーもタグももっていない。代わりに、Feed Wrangler は Smart Streams と呼ぶものを使って、フィードをすりつぶし、いっしょにする。Smart Streams は iTunes のスマートプレイリストに似ていて、用語を探したり、あるいは手操作でフィードを含むことによって定義されたフィードのグループのことである。強力ではあるが、フィードを追加するために小さなチェックボックスをクリックすることは必要以上に面倒だった。フィードをフォルダーにドラッグするほうが易しいだろう。Feed Wrangler は最初はフォルダーを Smart Streamsとして取り込まなかったが、セットアップをもっとスムーズにするために今は取り込んでいる。
ウェブアプリと iOS アプリの両方とも賢い設計がされていて、単純なレイアウトとフォントのうれしい選択ができる。一つ気が利いている点は iOS アプリが 1Password パスワード管理アプリのための組み込みサポートをもっている点だ。さらにいいことに、Instapaper や Pocketのような期待の共有オプションに加えて、Feed Wrangler はアイテムを Drafts に送ることをサポートしている。その Drafts で好きなように操作したり、コンテンツを共有したりできる。しかし、腕のいい Dr. Drang が指摘しているように Feed Wrangler は理解しがたいことであるが、一度に一つの共有サービスしかサポートしない。つまり、Instapaper、Pocket、あるいは Pinboard だ。もし提供されたアプリで満足できないならば、よいニュースがある。Feed Wrangler がサードパーティー API をもっている点だ。Reeder の開発者はすでにサポートを追加することを表明している。iPad 用の Mr. Reader の最新版は現在 Feed Wrangler をサポートしている。Mac 用の ReadKitと同様だ。
私は最初は Feed Wrangler に夢中にならなかったが、時が経つにつれて、これが私のお気に入りのサービスになるかもしれない。含まれるアプリは基本的なものだが、サードパーティー製クライアントのサポートと目に優しいウェブアプリのおかげで Feed Wrangler は将来大変有望だ。
NewsBlur -- Samuel Clay の NewsBlur は表面上は無料のサービスだが、実際に使いたいならば年間 $24 のお金を払う必要がある。無料のアカウントは長い順番待ちリストで、また、64 フィードだけに限られる。
にもかかわらず、NewsBlur には多くの好きな点がある。まず、NewsBlur はiPhone と iPad 用の無料のアプリを含んでいる。そして公式のデスクトップクライアントはないものの、Mac 用の ReadKit がサービスをサポートする。
すぐにあなたは NewsBlur が競合製品とまったく異なるウェブインターフェースをもっていることに気づくだろう。フィードはフォルダーにグループ化されるが、サブフォルダーも作成可能なので、Apple とラベルされたサブフォルダーをもつ Tech とラベルされたフォルダーをもつことが可能だ。また多くのビューモードもあり、見出しのリストとして記事を見たり、テキストそのものをブラウズしたり、あるいはオリジナルのサイトのコンテンツを見たりすることも可能だ。
NewsBlur の最大の特長の一つは NewsBlur が欠陥のある RSS フィードをレポートし、それを解決する手段を提供する点だ。もし、感嘆記号がフィードの横に出れば、それはフィードが壊れていることを意味する。それをクリックして新しいフィードを探すか、あるいはフィードを完全に削除するかのオプションを与えられる。
NewsBlur はまた Intelligence Trainer と呼ぶフィルタリングオプションもあり、RSS フィードのどのアイテムが好きなのか、嫌いなのか NewsBlur に教えることができる。それが効果的かどうかを話すほど十分に使っていないが、Macdrifter の Gabe Weatherhead はそれが気に入っている。それと並んでおもしろいソーシャル機能がある。例えば、NewsBlur コミュニティーからの記事に対する組み込みコメント機能などだ。
NewsBlur はブログコミュニティーから歓迎されているが、私は NewsBlur にあまり夢中ではない。そのオプションの塊りは能力を高めるよりも混乱を招くと思う。Feed Wrangler はセットアップするのは苦痛だが、デイリーベースで使うには単純でありながら、強力だ。NewsBlur はすべての異なったスイッチとオプションに危惧を覚える。そしてそのフィルタリングオプションはコンテンツを失うかもしれないという被害妄想を感じさせる。フィードを読みたくないなら、私なら単純に購読をやめる。
それ以外 -- 私がこの記事を書いている最中にも、次々と新しい RSS リーダーが開発され、インターネットのいたる所からリリースされつつある。 AOL や Facebook でさえ、そこに参加しつつある。以下に、あといくつか興味深いものを挙げておこう。
Diggチームも独自のリーダーを開発していて、今はウェブ用と iOS 用のリーダーが誰でも入手可能となっている。ウェブアプリも iOS アプリもよく出来ているが、いくつか問題がある。Digg Reader はあなたの Google Reader アカウントからフィードを読み込むことができるけれども、OPML 読み込みの機能はまだないようだし、書き出しの機能もない。また、私は自分の Google アカウントからウェブアプリと iOS アプリの双方にサインアップしてみたが、どうやら両者は互いに同期することはできないようだ。
そうした問題はあるけれども、最新のニュースを見たいときに私が何も考えずに開くのは今ではこの Digg アプリになっている。RSS フィードと、Digg が独自に集めたコンテンツとが組み合わせて表示されるのが素晴らしいし、いずれ Betaworks がこれらを Instapaper とどう組み合わせてくれるようになるのか、私はワクワクしながら待ち望んでいる。(Digg を所有する Betaworks は、2013 年 4 月に Instapaper を買収している。2013 年 4 月 25 日の記事“Betaworks が Instapaper を引き継ぐ”参照。)私をさらにもっとワクワクさせているのが、iOS 用の Digg アプリが部屋の明るさに応じてテーマを調整できる機能だ。以前、Instapaper の開発者である Marco Arment はその機能が Apple による制約のため実行不可能だと言っていたのに。
iOS 7 と OS X 10.9 Mavericks が登場すれば、はたして RSS の必要性が丸ごと消え去るのだろうか? Safari のリーディングリストに新装備される機能に、Shared Links というものがある。これは、あなたの Twitter タイムラインの中からリンクを含む tweet をすべて抽出してくれるものだ。もしもあなたがパワーユーザーでこのやり方を極めたいのなら、Launch Center Pro アクションを使ってカスタマイズされた Tweetbot 検索を実行し、あなたの選んだニュースソースからのニュースのみを含めることも可能だ。
Black Pixel 社のチームは Mac 用 NetNewsWire 4 のベータ版をリリースしたが、これは同期のために Google Reader を使用しないよう再構築されている。けれども残念なことに、その結果として同期機能がもはや存在しなくなり、しかも iOS 用のアプリは現在 App Store から取り下げられていて、Black Pixel はこれを iOS 7 用に書き直している最中だという。それでも、このベータ版は無料で、Google Reader から読み込むことができ、動作速度は非常に速い。リリース時にはこのアプリの価格が $20 となるが、現在 $10 での予約注文を受付中だ。現時点ではあまり良い解決法とは言えないが、将来性は十分にあるので、私は注目していたいと思う。
私たちのお薦めは -- 平均的なユーザーならば Feedly で十分満足できるだろう。無料だし、クロスプラットフォーム対応だし、将来は多数のサードパーティのリーダーにも対応するはずだからだ。Feedly はいずれ間違いなくフィードリーダーの中の巨人となるだろうが、私としてはあなたが Google Reader から書き出した購読データを万一に備えて保存しておくことをお勧めしたい。
Feedly については、一貫したビジネスモデルが見えない点を私は懸念している。その点が重要に思えるならば、Feedbin、NewsBlur、Feed Wrangler といったものに料金を払う価値はあるだろう。それらのうちどれを選ぶかは好みの問題だ。Feedbin は使用感が Google Reader に最も近く、iPhone では Reeder に、iPad では Mr. Reader に、Mac では ReadKit に、それぞれサポートされている。NewsBlur は三つのプラットフォームいずれにもネイティブなアプリがあり、パワフルなフィルタリング機能もあるが、サードパーティの iOS サポートがまだない。Feedbin と同様、Feed Wrangler も三つのプラットフォームいずれにもネイティブなアプリがあり、私は iOS アプリが特に気に入っている。
個人的に、私はフルタイムで Feedbin を使うことにしようかと思っている。セットアップが簡単で、インターフェイスは馴染み深く、三つの Apple プラットフォームのいずれにもネイティブなアプリがあり、持続可能なビジネスモデルがある。その上、開発者の Ben Ubois は信頼できて反応も早い。(彼はまた TidBITS の大ファンでもある。開発者である読者を支えることができるのは私としても嬉しい限りだ!)しかしながら、価格が最近月額 $2 から月額 $3 へと値上げされた上に、Feed Wrangler が最近フォルダの読み込みができるようになったこともあって、抜きん出て魅力的とは思えなくなった。
ここでちょっと横道に逸れて、iPad 用の Mr. Reader の開発者に敬意を表しておきたい。彼は、あっという間に Feedly、Feedbin、Fever、Feed Wrangler へのサポートを追加してくれた。これほど素晴らしいサポートがあるならば、それだけでも $3.99 の価格を出しても惜しくないと思える。同じように私は Mac 用の ReadKit の開発者にも喝采を送りたい。NewsBlur、Feedbin、Feed Wrangler、Fever、さらには Pocket や Instapaper までサポートしているので、今やこれは Mac 上で必携のリーダーアプリとなりつつある。
その一方で、Reeder にはがっかりさせられた。iPhone 版はアップデートされて Feedbin と Fever をサポートし、近日中に他のサービスもサポートするようになるらしいが、iPad 版と Mac 版のアプリの アップデートは 7 月 1 日の終了に間に合わず、App Store から取り下げられることになる。また、三つのバージョンのいずれも無料となったので、私としては開発者の Silvio Rizzi が今後開発を続ける十分な動機を持っているのかどうか疑いたい気持ちにならざるを得ない。
もちろん、他にもたくさんの、数え切れないほど多くの代替製品がある。今回は、私は複数プラットフォームへの対応が優れているもののみに絞って検討してみた。この分野にある他の製品のリストを見たければ、 ReplaceReader サイトがまさにそういうリストを出していて、Twitter で触れられた回数によってランク付けしている。
コメントリンク13858 この記事について | Tweet リンク13858
文: Josh Centers: [email protected], @jcenters
訳: 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>
Atypical Games の Sky Gamblers: Storm Raiders はあなたを World War II 戦闘機のコックピットに誘い、単一プレーヤー軍事作戦と複数プレーヤー空中戦の両方が楽しめる。私はこれが 2013 年の初期に App Store リストの上位にランクされるのをしばしば見ていたが、私の子供の頃の NES 用の Top Gun でのトラウマ的経験から手を出せずにいた。しかしながら、Storm Raiders が Apple Design Award を WWDC で得たのを知って ("Apple Announces 2013 Apple Design Award Winners" 13 June 2013 参照)、私はこれを試さずにはいられなかった。このゲームは Mac 及び iOS のどちらのバージョンも $4.99 であるが、私はセールで両方をそれぞれ $0.99 で購入出来た。(iOS バージョンは iOS 5 かそれ以降しか必要としないので、iPhone 3GS や第三世代 iPod touch の様な機器上でも走る。) 操作を除けば、ゲームはどちらのプラットフォームでも同一である。
最初にこのゲームを立ち上げた時、私はこれは App Store ゲームなので操作はレベルを下げてあるのであろうと想像した。でも、そうではなかった。オプションとしてカジュアル操作も選択出来るが、Storm Raiders はスロットル、ピッチそしてヨーに対して完全な操作をさせてくれる。ゲームは最初にあなたが基礎をマスターしていることを確認するため 6 つの訓練ミッションを与える。一旦コツを掴んでしまえば、ループをやるのも朝飯前である。iOS バージョンは飛行機の操作の多くを内蔵のジャイロスコープに依存しているので、時としてぎこちなさが感じられるが、Mac バージョンのキーボード利用よりは全般的にずっと滑らかである。しかしながら、Mac バージョンでは、ゲームパッド、ジョイスティック、そしてトラックパッドすらも使えるので、操作の選択肢は豊富である。
最初に気づくことの一つは、そのグラフィックスが素晴らしいことであろう。Storm Raiders はどの現世代のゲーム機上にもすんなりおさまるであろう。そうではあるが、このゲームは私の 2011 MacBook Pro 上でも滑らかに機能したし、27-inch のモニタにつないだ時ですら問題はなかった。ゲーム進行は私の年老いた iPad 2 上でも滑らかさは変わらない様に見えた。
しかし Storm Raiders はただ単に見かけが美しいだけではない - 内容も充実している。ゲームには 2 つの単一プレーヤー軍事作戦が含まれている:Battle of Britain と Asia-Pacific 戦線で、それぞれに 6 つの任務が用意されている。軍事作戦には、Messerschmitt と空中戦をする、Nazi 基地を爆撃する、飛行軍団を護衛する、London を爆撃機から防御する、そして Pearl Harbor を神風パイロットから守ることまである。Pearl Harbor 任務はとりわけ痛ましい。もしあなたが WWII の歴史マニアであれば、これらの任務はたまらないであろう。
軍事作戦におけるより印象的な操作面の一つは、あなたの飛行軍団をどう管理するかである。一つのボタンをクリックするかタップすることで、編隊を組んで飛行する、自分の飛行機を守る、或は敵のパイロットを個別に迎え撃つことが出来る。多くのビデオゲームでは、AI チームメートを制御するのが最もイライラの募るものの一つだが、Storm Raiders はこれを完璧にこなしている。敵方パイロットの AI も同じ様に印象的で、あなたの飛行能力の真価を問うであろう。
私の印象に残ったもう一つのインターフェース要素は、それぞれのレベルの最初に出てくる解説文の下に現れるバーである。それは現れた後縮み始め、その特定の文章があとどれぐらい長く画面上に表示されるかの表示となる。私はこの細部にまでの注意が気に入っている。勿論、これらのスクリーンを早送りしてやり過ごすことも出来る。
もしこの軍事作戦もあっという間に完了、或はただ単に飽きてしまったとしても、他にも沢山の単一プレーヤーオプションがある。例を挙げると、サバイバルモード、空中戦、そして自由飛行モードすらある。しかしながら、Mac バージョンでは、自由飛行モードのレベルのリストをスクロールするのに苦労した。これは私がこのゲームで遭遇した唯一の大きなバグである。
Storm Raiders はまた数々の追加の飛行機や武器を解き放ち、リプレー価値に追加したり、複数プレーヤーゲームでの使用に追加させてくれる。但し、この中にはアプリ内購入が必要なものもある。私はアプリ内購入のファンではないが、これがどうもゲーム業界が向っている方向のように見える。
このゲームはまた同じぐらい多様な複数プレーヤーオプションも提供している。その中には、参加自由のデスマッチ、チームデスマッチ、旗取りゲーム、そして基地防衛が含まれる。Quick Play を使えば、8 人までのプレーヤーがゲームに直ぐに飛び込め、Wi-Fi 上で近所の友人に挑戦したり、或は Game Center を通して遊ぶことすら出来る。このオンラインプレーは素晴らしいし、ゲームを一つ選ぶのにも困った経験はない。Wi-Fi オプションですごいのは、iOS と Mac プレーヤーがお互い同士戦えることで、これはパーティでの余興としても適している。
残念なのは、ゲーム進行は iOS と Mac バージョンの間では同期されていない様に見えることである。Storm Raiders は Apple 技術を良く使っており、iOS 機器間ではゲーム進行は iCloud 同期でなされ、複数プレーヤーサポートに Game Center を使い、トラックパッドもコントロールとして使え、そして AirPlay を使って巨大画面に映し出すことすら出来る。
全体として、Sky Gamblers: Storm Raiders はとても楽しい。これはゲームセンター品質のゲームを Mac と iOS にもたらし、一方では両プラットフォームの能力を十分に生かし、そして自分自身で或は友人と楽しむための数多くのゲームモードを提供している。もし次から次と出る Call of Duty クローンに飽き飽きしている、或はただ単に自分の Apple 機器のための高品質のアクションゲームが欲しいというのであれば、Sky Gamblers: Storm Raiders は入場料の価値はある。
コメントリンク13879 この記事について | Tweet リンク13879
文: TidBITS Staff: [email protected]
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
Transmit 4.4 -- 盛り沢山の変更がある訳ではないが、Panic のこのファイル転送プログラム Transmit のバージョン 4.4 へのアップデートでは編集可能な Server フィールドを通じた Amazon S3 互換なサーバへのサポート改善という歓迎すべき機能追加があり、この Server フィールドは Amazon S3 互換でないサーバ用にも書き換えることができるようになった。今回のリリースではまた、一部の SharePoint サーバに WebDAV 経由で接続できなくなっていたバグも修正された。(Panic からも Mac App Store からも新規購入 $34、無料アップデート、29.4 MB、リリースノート)
PopChar X 6.3 -- Ergonis Software が PopChar X 6.3 をリリースし、クリック可能なリンクを Font Info 表示に追加して、クリックすればそのフォントの保存場所が開くようにした。一つのフォントの複数個のバージョンがシステムに存在する場合には、どのバージョンが現在使われているかをフォント発見ユーティリティが表示するようになった。また、今回のアップデートでは一時的クリップボードの内容を PopChar X が処理する方法を変更していろいろなクリップボードユーティリティとの互換性を高め、利用可能なフォントが変わった際の反応速度と信頼性を増し、メニューバーアイコンをクリックした後に一部のメニューがブロックされていたバグを修正している。Ergonis はまた、ユーザーインターフェイスの変更もいくつか施した。Escape キーを押せば PopChar X ウィンドウが閉じるようになり、割り当てられたホットキーで正しくウィンドウを閉じるようにし、アプリが最初に開いた際にウィンドウのヘッダがスクリーン外にあればウィンドウ位置を修正するようにした。(新規購入 29.99 ユーロ、 TidBITS 会員には 25 パーセント割引、無料アップデート、3.7 MB、 リリースノート)
文: TidBITS Staff: [email protected]
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
夏の疲れが溜まってきたようなので、今週は二つだけ ExtraBITS 記事をご紹介したい。無料の iPhone 修理キットが登場し、Apple の緊密な統合の結果として iOS 7 はコピーが困難となっている。
iFixit から無料で出た修理キットであなたの iPhone に自由を -- 米国の独立記念日 (Independence Day) を祝って、iFixit は 7 月 1 日から 7 月 5 日まで "iPhone Liberation Kits" を無料で配布している。このキットは、iPhone 4 と iPhone 5 用に配布されているが、Apple 独自仕様の五角星形のネジを標準のプラスネジに交換するために必要なツールをすべて含んでいる。iFixit は先着 1,776 名には送料も無料と発表していたが、それはあっという間に売り切れてしまったので、今は注文ごとに $5 の送料がかかる。
Apple の統合により iOS 7 はコピーが困難 -- iPhone のデビュー以来、競合するスマートフォンメーカー各社も、ウェブ開発者たちも、iOS 7 のもたらすスクリーン上の美学をコピーしたいと思い続けてきた。しかし開発者 Marco Arment の論ずるところによれば、来たるべき iOS 7 は Apple のハードウェアを巧みに活用してコピーを困難にしているという。具体的には、iOS 7 のインターフェイスの多くの部分が iOS デバイスの持つパワフルなグラフィックプロセッサと高解像度のスクリーンとに依存しているので、スペックの弱い他のプラットフォーム上で真似るのは困難なのだと彼は言う。
TidBITS は、タイムリーなニュース、洞察溢れる解説、奥の深いレビューを Macintosh とインターネット共同体にお届けする無料の週刊ニュースレターです。ご友人には自由にご転送ください。できれば購読をお薦めください。
非営利、非商用の出版物、Web サイトは、フルクレジットを明記すれば記事を転載または記事へのリンクができます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありません。
告示:書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。
TidBITS ISSN 1090-7017©Copyright 2013 TidBITS: 再使用はCreative Commons ライセンスによります。