話題の「デザイン思考家が知っておくべき39のメソッド」をkindle3で読んでみた

数日前から、タイムラインで幾度となく話題に上がってきた、d.schoolによる「デザイン思考家が知っておくべき39のメソッド」ですが、せっかくなのでkindle3に入れて読んでみることにしました。

kindleで読むには、まずpdfをMacにダウンロードしてから、kindleをUSBで接続して、そのままMacのファインダーでkindleのドキュメントフォルダにpdfをぶち込みます。これだけで１秒も掛からずにkindleに取り込まれます。
USBで繋がなくても、自分のkindle用freeメールアドレスに転送すれば暫く経ってからkindleにファイルが送られてきます。いやー、簡単ですね。このへん話題のkoboの使い勝手はどうなんでしょうか？

早速見てみると、そのままでは文字が小ちゃくて読み難いです。
pdfの原寸を確認してみたら、215.9mm X 279.4mmでした。アメリカのレターサイズですね。
アメリカからきた原稿をそのままテキストだけ翻訳した感じなのかもしれませんが、今後翻訳するときは用紙サイズも変更した方がいいのかもしれませんね、なんてことをちょっと思いました。
閑話休題。だいたいA4サイズの原稿を、日本の文庫本より小さいkindle3の画面に縮小して表示しているので、どうしても小さくなります。読み辛い訳です。

そのままだと文字がかすれてしまうので、コントラストを普段より１段階濃いめにして、なんとか視認に問題ないレベルにはなりました。
でも老眼なんで、やっぱ辛いわあ。長く読み続けるのはしんどそうです。

もちろん拡大すればもっと読みやすくはなりますが、pdfの場合はあくまでも１枚ペラの画像を表示しているだけになるので専用フォーマットのような表示部分に合わせて改行なんて事はしてくれる筈もなく、いちいちスクロールしなくてならずに面倒なことこの上ないので、非現実的です。（自炊も基本これと同じことになるので、私はやらないのですよ。はー、早くkindleジャパン開店してほしい・・・）

と、この辺まできて、わたくし重要なことを思い出しました！
kindleには、一般的なテキストファイルを送るとkindle formatに変換してくれる無料サービスがあるのですよ！確かpdfも実験的に対応していたはず。

ということで、送ってみます。
やりかたは、ファイル転送と同じ宛先、自分のkindleアカウント@free.kindle.comにファイルを送るだけ。ただしこのとき、メールの件名を「 convert 」にします。

…待つこと数十分。まだきません。まあコンバートに時間が掛かるはずなので、気長に待つことにします。
…１時間後、Mac側にメールがきました。

"A problem with your document(s)"・・・＿|￣|○

コンバート失敗したようです。

日本語の場合はそもそも失敗する確率が高い様なので、それほど気にはしてませんでしたが、一応原因を探るべくpdf版で中を読み進めてみました。

そうしたら、本文が始まってすぐに原因が分かりました。

本文のテキストが、すべて画像の枠内に書かれています。

おそらくこのために、コンバート用のサーバーは本文をすべて画像と判断し、テキストの抽出をしなかったのだと思われます（想像です）。

うーん、残念。

スタンフォードなだけに、kindleのこと良くわかってて、わざとコンバートできないようにした、なんてことは考えたくはありませんが、ちょっともったいない感じです。

結論としては、日本のkindleストアの開店が待ち遠しい、早くしろ！ってことですね。

※ちなみにiPadのkindleではもうちょっと大きく表示されるので、だいぶ読みやすいです。

JSONViewが便利すぎる

InstagramのAPIを使って、OAuth認証を通してブラウザ経由でJSON形式のデータを取得するところまでまでは、とりあえずできました。

取り急ぎJSON形式のまま開いて見てみると

・・・かなり長いです。

ざーっと見ましたが、何がなんだかわかりません・・・

中にあるurlを適当に見繕ってブラウザにぶっ込んでも、当然のようにエラーになります。

うーん、中身を確認するにはPHPかJaveScript書かなきゃいけないんかなあ、大変だなあ、、と思いながら、いろいろ調べてみたところ、なんかすごい便利そうなChrome拡張を見つけました。

それが、JSONViewです。

もとはFireFox用だったみたいですが、Chrome版もばっちり動いてます。

上記のリンクから拡張を追加して、その後JSONをChromeに読ませると勝手にパースしてインデントまでしてくれちゃいます。
日本語が化けるというエントリもありましたが、自分の環境では、ちゃんと表示できてますね。無問題。

これで各APIで取れるデータがどんなもんなのか、事前にお試しで取得してみてさくっと確認できるようになりました。
簡単なプログラムでさえ自分ではほとんど書けない状態の私には、作業効率化のために非常に心強い拡張機能です。

作者さん、ありがとう！

Instagram API Access Token 取得にエラーがでたら

InstagramのAPIを使ってアプリをつくるために、Access Tokenを取得しました。
途中ちょっと手間取ったので、備忘録としてエントリしておきます。

さて、単に写真だけをひっぱってくるくらいであればAccess Tokenは必要ないみたいですが、どうせならフォローしている人の写真をソートしたり、いいねしたりもできるようにしたいので、後でバタバタするより先に取ってしまうことにしました。

※以下は、Developer登録とClient登録が済んでいて各ID取得済みである前提で記載しています。まだの方はこちらのエントリの真ん中辺りを参考にしてください。

Access Token取得方法はAPIのドキュメントに詳しく書いてありますが、手っ取り早く日本語訳のほうを参考にさせていただきましょう。

ステップ１．ユーザに認証用URLを表示する

https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=code

この時点で、ログインページを表示し、アプリケーションにデータへのアクセス許可を求める確認ページが表示されます。

ステップ２．Instagramサーバからリダイレクトされる

ユーザがログインに成功し、アプリケーションにアクセス許可を与えると、Instagramサーバがredirect_uriにcodeパラメータを付加して呼び出します。codeパラメータで渡された値は、ステップ３で用います。

http://your-redirect-uri?code=CODE

ステップ３．access_tokenを要求する

ステップ２でcodeパラメータを受け取ることができました。この値を使い、指定したユーザ用のaccess_tokenを受け取るためのデータ交換をおこないます。データ交換は、access_token用URLにcodeの値と併せて、いくつかのアプリケーション認証情報をPOSTで送信するだけのことです。必要なパラメータを以下に示します。

• client_id クライアントID
• client_secret クライアントシークレット
• grant_type 現在、"authorization_code"のみ指定することができます。
• redirect_uri 認証リクエストを送信した際にredirect_uriで指定した値です。注意: この値は、認証リクエストで指定した値と完全に一致していなければなりません。
• code 認証ステップで受け取ったcodeパラメータの値

access_token要求は、たとえば次のようになります。

curl \
    -F 'client_id=CLIENT-ID' \
    -F 'client_secret=CLIENT-SECRET' \
    -F 'grant_type=authorization_code' \
    -F 'redirect_uri=YOUR-REDIRECT-URI' \
    -F 'code=CODE' \
    https://api.instagram.com/oauth/access_token

呼び出しが成功すると、OAuthトークンを整形したデータが返されます。

ということで、ユーティリティからターミナルを起動して、上記のコマンドを実行します。最後の一行を入れてreturnキーを押して、２秒程待つと・・・

あれ？エラーです・・・orz

念の為、Instagramから一度ログアウトして、再度ステップ１から再開しCODEを再取得して試してみましたがまたエラーです＿|￣|○

返ってくるメッセージを見ると400エラーのようですが、後ろに"No matching code found"とかも書いてます。うーん、CODEはコピペだから間違う筈ないんだけどなあ。

悩んだときはドキュメントに立ち戻ってみます。

すると上記の下にこんな記述がぁっ！

“サーバ機能を持たないアプリケーション（たとえば、完全に独立したJavaScriptアプリケーションなど）を作成する場合は、上記のステップ３を実行することはできません。つまり、access_tokenを受け取ることも、クライアントシークレットを渡すこともできません。クライアントシークレットは、アプリケーションの管理下にないデバイスに保存することは絶対に避けなければなりません。では、access_tokenを受け取るにはどうしたらいいのでしょう？OAuth 2.0仕様を策定した賢い人たちは、この問題をちゃんと予期しており、暗黙の認証フローを用意したのです。”

あらら、なんか怒られたみたいです。

え、でもcurlってFTPサーバーみたいに動くコマンドなんじゃないの？なんで？？

という疑問は素人が考えても仕方がないんで取りあえず横に置いておいて、その「暗黙の認証フロー」を試してみることにします。

クライアントサイド（暗黙の）フロー

ステップ１．ユーザに認証用URLを表示する

https://instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=token

この時点で、ログインページを表示し、アプリケーションにデータへのアクセス許可を求める確認ページが表示されます。明示的フローの場合と違い、response_typeパラメータの値が"token"であることに注意してください。

ステップ２．URLフラグメントによりaccess_tokenを受け取る

ユーザがログインに成功し、アプリケーションにアクセス許可を与えると、Instagramサーバがredirect_uriにURLフラグメントとしてaccess_tokenを付加して呼び出します。次のようになります。

http://your-redirect-uri#access_token=ACCESS-TOKEN

URLフラグメントのaccess_token部分を取り出せばおしまいです。

あっさり、上記の方法でAccess Tokenが取得できました・・・

同じ様にエラーでAccess Tokenの取得ができない方は、クライアントサイドフローを試してみて下さい。

Instagram Developer に登録してみた

ちょっと思うところあって、InstagramのAPIをいじってみようと、Developer登録してみました。

APIに関していろいろと参考になりそうなブログを探してみたのですが、あまり最近のは見当たりません。大体2011年のAPIが公開されたあたりのエントリです。
公開されてからあまり大きな変更がされていないということですかね？
FacebookのGraph APIを使う時に、しょっちゅう仕様が変わるので設計に悩んだことがあるので、あまり変更がなさそうなのはいいですね。
とはいえ、InstagramはそのFacebookに買収されたので、今後はどうなるかわかりません。ちょっと心配です…

閑話休題。
APIをいじるには、Developer登録をした後にApplicationの登録をします。
ここまでで参考になったのはこことここです。ありがとうございます。

まだぜんぜんいじっていないので、感想などはまた改めて。

ダイスキンB6とペーパープロトタイピング

ちょっと前に話題になり、当時は品切れ続出で入手困難だったダイスキン。
私もA6サイズのダイスキンを愛用しております。

用途はとしては、まずはアイデア帳として。
そしてtips的な使い方ですが、A6ダイスキンって（勿論モレスキンもですが^^;）実はiPhoneより一回り大きい位のサイズなので、iPhoneアプリを作る際のペーパープロトタイピングに重宝するのです。


デザイン要素を原寸大に落とした時、片手でもボタンが押し易い位置にあるかとか、表示は見やすいか、指で隠れないか、次のページに遷移したとき操作ミスしがちな配置じゃないか…などなどを手書きとはいえ、実際にさわれるイメージでテストするのです。

写真は当社のアプリQueuence設計時に使った実際のペーパープロトタイプです。

こんな落書きで意味あるのかと思われるかもしれませんが、なかなかどうして、こんなラフなものでも、原寸大で触ってみて初めてわかる事や気が付くことが山のようにあります。
ペーパープロトタイピングをやったことの無い方は、だまされたと思って一度試してみることをオススメします。

Kincle3との比較

さて、本題のB6モレスキンですが、今日久々に地元のダイソーの手帳売り場をチェックしたら見慣れない物を発見したのです。
そう、それがB6モレスキンだったのです！
A6モレスキンよりも2回り程大きいサイズ（あたりまえだ）。
これ、Kindle3とほぼ同じ大きさですね。
ということは、これから流行るだろうミニタブレット向けのペーパープロトタイプにピッタリということです。

ちょっとググったら春位から販売されてたらしいですが、割と小まめにダイソー見てるのに今日初めて見つけたという事は、これもA6と同じくレア商品のにおいがします。
koboやkindle fire向け開発を考えている方は、早めの在庫確保が吉かも？100円だしね
(´・ω・`)

B6ダイスキン。手前はA6ダイスキンです

無線LAN中継機を買ってみた

なんだか家の無線LANの状態がよろしくない感じになってきたので、対策として無線LAN中継機を導入してみました。

今のルーターはAterm WR8170Nというハイパワータイプで木造2階の北東隅に設置してありますが、１階のリビング南端にあるApple TVの接続状況がどうも酷い事になってきたのです。
ビデオのHD画質サンプルさえ始まるのに5分以上掛かり、しかも途中で止まり終いには強制終了したりします。特に酷いのは、MacやiPhoneから動画をApple TVにAirPlayすることがほとんどできなくなったことです。私のApple TVの目的って、撮った写真やビデオをリビングの大画面テレビでみんなで観る事なので、それができないとなるとApple TVを持っている意味がなくなってしまいます。
これはなんとかしなければなりません。

以前から多少バッファリングでもたついたりすることはまりましたが、少し前から完全にハングアップしたり接続が切れちゃったりするようになりました。
Apple製品の不具合対応の基本である再起動をしても直りません。ということはハード側じゃなくて、通信品質に問題があるんじゃないかと疑ってみました。
そこでSpeed Testなんぞしてみたら、Apple TVの設置場所付近ではなんと下りで1Mbps、上りで450Kbpsとか酷いことになっていたんですね。同じ家の中でこんなに減衰しちゃうとは驚きでした。

FLETS光はベストエフォートとはいえ、ルーターのすぐ隣では大体40~50M、良い時は80Mbps近く出るんですよウチ。それが1/50になっちゃうんですからねえ。酷い。
これではHD画質のホームビデオから加工した動画をiPhoneからルーターに一旦飛ばしてそこからまたApple TVに飛ばしてストリーミング再生するなんて、確かに辛い筈です。

最初は以前使っていた無線LANルーターや封もあけていないFONなんかを使って、なんとかアクセスポイント的に使えないかなあといろいろ調べてみたんですが、無理でした。
この辺詳しくないんですが、どうやら中継機（エクステンダーともいうらしい）を入れるしかないらしい。

ちなみに電波が弱いからと言って、TV受像のようにブースターを使う事は電波法違反になるそうです。なのでそのような商品はたとえできたとしても販売できません。

その点、中継機は電波を増幅する訳ではなく、文字通り中継するだけです。つまり中継機の時点での受信状況をさらに遠くに伝達するだけなんで、例えば中継機地点で15Mbpsの受信状況であれば中継機は最大15Mbpsの電波をそのまま伝達するだけなので、その先ではそれ以上の速度は絶対に出ないということです。

それでも１階リビングの入り口付近で15Mbpsであれば、その奥に鎮座するApple TVの　場所でも10Mbps以上余裕で出るようになりました。上りでも3Mbps以上出ますね。
その状況で試したところ、いままでバッファ中に止まってしまっていた動画もほとんどストレス無くAirPlayできるようになりました。

普通の木造2階建なら「ハイパワータイプの無線LANルーターで余裕だわ」と思っていましたが、ちゃんと計測してみると意外と心許ないことが今回わかりました。
実は半年くらい前までは不都合を感じたことはなかったのですが、思い起こせば裏に2軒新しい家が建ったころから状況が悪くなってきたような気がします。
logもないので検証したわけではありませんが、これはルーターの性能や家の構造の問題ではなく、世に言う無線LANの干渉問題なのかもしれません。

原因はともかく、もし同じように無線LANの電波が弱くて困っている方がいらっしゃれば、無線LAN中継機の導入を検討されては如何でしょうか？
あまりメジャーな機材ではありませんが、探せば数千円台前半というお手頃価格で見つかりますので、しかるべき設置場所がありそうならば、試してみる価値大です。

なお、私が購入したのは調べた中で一番安く、レビューの評判もなかなか良かったこちらPLANEX MZK-EX300N です。Amazonで最安値¥2,480でした。安っ！
設定もWPSならボタンを数個押すだけで簡単です。
万が一中継機としてあまり効果が無かったとしても、有線LANしか使えない機材（TVとか）を無線LANに繋ぐメディアコンバータとしても使えるんで無駄にはならないと思います。
在庫があればマジでオススメです。

インタフェースデザインの心理学 ―ウェブやアプリに新たな視点をもたらす100の指針

オライリー本ですが、内容的にはテクニックの解説等技術者向けっぽいところはほとんどなく、もっと根源的な人の心理にフォーカスして、こういうこと押さえて設計しろよという指南書です。
どちらかというとビジネス書に近いかも。


タイトル通り100の短い章に分かれていて、一つ一つは簡潔にまとめられています。
決してすべてが新しい話ではなく、ユーザー心理やUXを学んでいる人には既知のものも少なくないですが、そういうものでも新たな解釈があったりここでそこにつながるかという発見があったりで、飽きずに読み進められます。

UXとか小難しくいわずに、ユーザー目線を考える上で参考になる入門書として、デザイナーだけでなくディレクターやエンジニアにも読ませたい内容です。特に新人には読み易くていい本だと思います。


もっといえばすべての客商売やってる人が読んでいい本だと思います。