untitled

[manabuueno]

Instagram 投稿の詳細情報を表示するウェブアプリ "Infosta"

Instagram 投稿の詳細情報を表示するウェブアプリ “Infosta” を作りました。

Infosta

Instagram の純正アプリやウェブサイトでは、各写真の詳しい投稿日時がわからないとか、その写真ファイルの直接の URL がわかりにくいといった不便がありますね。 でもそれらの情報は API 経由であれば知ることができます。

Infosta は、Instagram の API を使って、各投稿の詳細情報を表示します。

はじめて Infosta にアクセスすると、Instagram へのログインを求められますので、ログインしてください。

Infosta の画面では、ユーザー名またはタグ名を入力してキーボードのエンターをおすと検索が実行されます。

検索結果の一覧で項目をクリックすると、その下に投稿の詳細情報が表示されます。

表示される詳細情報はほぼ API から取得した JSON そのままなので、少しみにくいですが、あしからず。

画像ファイルの URL は、images のところにある low_resolution, thumbnail, standard_resolution のサイズ違い三つです。

[manabuueno]

Textwell でツイート埋め込み用 HTML を取得するアクション “Tweet Embedder”（T.request 版）

これまで二度ほど紹介している Tweet Embedder ですが、最新の Textwell（iOS版はv1.3.4、Mac版はv1.1.1）で追加された T.request という API を使って作り直しました。機能としてはこれまでと同じですが、実行速度がだいぶ速くなっているはずです。

Tweet Embedder は、ブログなどに特定のツイートを貼り付けるために、ツイートのURLから埋め込み用HTMLを生成するアクションです。

タップしてアクションをインポート →［Tweet Embedder］

Textwell を最新にしておいてください。

＜使い方＞

まず Twitter クライアントなどで目的のツイートの URL をコピーします。

そして Textwell を開いて Tweet Embedder アクションを実行します。すると埋め込み用の HTML がカーソル位置に挿入されます。

↓ Blog Preview アクションで見てみるとこんな感じ。

挿入されるのは、Twitter のサイトで取得できる埋め込み用 HTML と同じものです。

ちなみに “HTML Preview”などを使って、ローカルでプレビューした場合、スクリプトの関係で正常に表示されません。これはこのアクションのせいではなくもともとそういう作りです。”Blog Preview” ではプレビューできます。いずれにしても、サーバー上で公開すれば正常に表示されるはずです。

＜オプション設定＞

アクションのソースを開くと、上の方に以下のようなところがあります。

var tweetURL = T.pboard; var maxwidth = 550; var hide_media = false; var hide_thread = false; var omit_script = false; var align = ‘none’; var lang = ‘ja’;

これらを編集してオプションを設定できます。

tweetURL これは取得するツイートのURLをどこからもってくるかで、T.pboard は現在ペーストボードにある文字列を意味します。ここを例えば T.current にすると、現在カーソルがある行（または選択中の文字列）がインプットになります。

maxwidth これはツイートブロックの最大幅。デフォルトは550。

hide_media これはメディアの埋め込みをしないというオプション。デフォルトは false なのでメディア埋め込み有り。無しにしたければ true にする。

hide_thread これはスレッド（会話）表示しないというオプション。デフォルトは false なのでスレッド表示有り。無しにしたければ true にする。

omit_script これはスクリプト挿入しないというオプション。ここでいうスクリプトとは、ツイートブロックのHTMLの後ろに挿入される script 要素のことで、ツイートブロックを正しく表示させるためには必要だからデフォルトは false（挿入有り）。ただ、このスクリプトはページの中で一度読み込まれていればいいから、ページ内の他のところですでに同じスクリプトが読み込んであるならば true（挿入無し）にしてもよい。普通はよく分からないだろうから false のままにしておくのがよいと思う。

align ツイートブロックをページ内で中央や右に寄せたい場合のオプション。’none’, ‘left’, ‘center’, ‘right’ のいずれかにする。デフォルトは ‘none’。’none’ は普通 left と同じ左寄せになると思う。クォーテーションが必要。

lang 表示言語指定のオプション。例えば日本語なら ‘ja’ だし英語なら ‘en’ など。

[manabuueno]

Textwell でツイート埋め込み用 HTML を取得するアクション “Tweet Embedder”（Textwell v1.3 対応版）

以前に公開した TweetEmbedder は Textwell (iOS) v1.3 で動かないので、修正版を作りました。

これは、ブログなどに特定のツイートを貼り付けるために、ツイートのURLから埋め込み用HTMLを生成するアクションです。

タップしてアクションをインポート →［Tweet Embedder］

＜使い方＞

まず Twitter クライアントなどで目的のツイートの URL をコピーします。

そして Textwell を開いて Tweet Embedder アクションを実行します。すると埋め込み用の HTML がカーソル位置に挿入されます。

↓ Blog Preview アクションで見てみるとこんな感じ。

挿入されるのは、Twitter のサイトで取得できる埋め込み用 HTML と同じものです。

ちなみに “HTML Preview”などを使って、ローカルでプレビューした場合、スクリプトの関係で正常に表示されません。これはこのアクションのせいではなくもともとそういう作りです。”Blog Preview” ではプレビューできます。いずれにしても、サーバー上で公開すれば正常に表示されるはずです。

＜オプション設定＞

アクションのソースを開くと、上の方に以下のようなところがあります。

url: T.pboard, maxwidth: 550, hide_media: false, hide_thread: false, omit_script: false, align: 'none', lang: 'ja'

これらを編集してオプションを設定できます。

url これは取得するツイートのURLをどこからもってくるかで、T.pboard は現在ペーストボードにある文字列を意味します。ここを例えば T.current にすると、現在カーソルがある行（または選択中の文字列）がインプットになります。

maxwidth これはツイートブロックの最大幅。デフォルトは550。

hide_media これはメディアの埋め込みをしないというオプション。デフォルトは false なのでメディア埋め込み有り。無しにしたければ true にする。

hide_thread これはスレッド（会話）表示しないというオプション。デフォルトは false なのでスレッド表示有り。無しにしたければ true にする。

omit_script これはスクリプト挿入しないというオプション。ここでいうスクリプトとは、ツイートブロックのHTMLの後ろに挿入される script 要素のことで、ツイートブロックを正しく表示させるためには必要だからデフォルトは false（挿入有り）。ただ、このスクリプトはページの中で一度読み込まれていればいいから、ページ内の他のところですでに同じスクリプトが読み込んであるならば true（挿入無し）にしてもよい。普通はよく分からないだろうから false のままにしておくのがよいと思う。

align ツイートブロックをページ内で中央や右に寄せたい場合のオプション。’none’, ‘left’, ‘center’, ‘right’ のいずれかにする。デフォルトは ‘none’。’none’ は普通 left と同じ左寄せになると思う。クォーテーションが必要。

lang 表示言語指定のオプション。例えば日本語なら ‘ja’ だし英語なら ‘en’ など。

[manabuueno]

iOS デバイスのシステムログをリアルタイムに見る

Mac にケーブルで iOS デバイスをつないでアプリのデバッグをしている時、iOS 7 からサンドボックスの関係で Mac 上の Console.app にデバイスのシステムログが出なくなった（要出典）。

Xcode でアプリをランしている状態なら Xcode のコンソールを見ればよいが、ランしていない状態のデバッグ（例えば他アプリから呼ばれて起動する時の処理など）を見たい場合に困る。

ランしていない状態のシステムログを見るには、Mac と iOS デバイスをケーブルでつないで Xcode（6.x）を起動し、メニューの Window -> Devices を選ぶ。左のソースリストで iOS デバイスを選択し、下の方にある小さな三角を押す。

するとコンソールペインが開くので、そこでリアルタイムにデバイスのログを見ることができる。

ただしフィルタリングができないので見にくい。

参考 http://stackoverflow.com/a/19127459/1263865

[manabuueno]

Zzzzzzzzzzzz

Zzzzzzz. Zzzzzzzz. Zzzzzzzz.

[manabuueno]

Textwell からツイート埋め込み用 HTML を取得するアクション "Tweet Embedder"

↓こちらの記事にインスパイアされまして...

iPhoneでツイートの埋め込み用HTMLを取得する方法（TextwellとPuffin活用） http://d.hatena.ne.jp/hebyumetan/20140703/1404359923

Textwell だけでツイート埋め込み用 HTML を取得するアクション "Tweet Embedder" を作りました。

タップしてアクションをインポート →［Tweet Embedder］

まず Twitter クライアントなどで目的のツイートの URL をコピーした状態で、このアクションを実行すると、埋め込み用の HTML がカーソル位置に挿入されます。

↓ Blog Preview アクションで見てみるとこんな感じ。

挿入されるのは、Twitter のサイトで取得できる埋め込み用 HTML と同じものです。

（ちなみに "HTML Preview"などを使って、ローカルでプレビューした場合、スクリプトの関係で正常に表示されません。これはこのアクションのせいではなくもともとそういう作りです。"Blog Preview" ではプレビューできます。いずれにしても、サーバー上で公開すれば正常に表示されるはずです。）

なお、アクションのソースの上の方で、いくつかパラメーターを変更できるようにしてあります。

更にカスタマイズしたい場合はこのへんのページを見てやってください。

https://dev.twitter.com/ja/docs/embedded-tweets

https://dev.twitter.com/docs/api/1/get/statuses/oembed

＜追記＞

言語設定が英語になっていたので、日本語に変えました。

＜追記2＞

オプションのパラメーターについて。

アクションのソースを開くと、上の方に以下のようなところがあります。

var tweetURL = T.pboard; var maxwidth = 550; var hide_media = false; var hide_thread = false; var omit_script = false; var align = 'none'; var lang = 'ja';

これらを編集してオプションを設定できます。

tweetURL これは取得するツイートのURLをどこからもってくるかで、T.pboard は現在ペーストボードにある文字列を意味します。ここを例えば T.current にすると、現在カーソルがある行（または選択中の文字列）になります。（詳細はリファレンスを参照）

maxwidth これはツイートブロックの最大幅。デフォルトは550。

hide_media これはメディアの埋め込みをしないというオプション。デフォルトは false なのでメディア埋め込み有り。無しにしたければ true にする。

hide_thread これはスレッド（会話）表示しないというオプション。デフォルトは false なのでスレッド表示有り。無しにしたければ true にする。

omit_script これはスクリプト挿入しないというオプション。ここでいうスクリプトとは、ツイートブロックのHTMLの後ろに挿入される script 要素のことで、ツイートブロックを正しく表示させるためには必要だからデフォルトは false（挿入有り）。ただ、このスクリプトはページの中で一度読み込まれていればいいから、ページ内の他のところですでに同じスクリプトが読み込んであるならば true（挿入無し）にしてもよい。普通はよく分からないだろうから false のままにしておくのがよいと思う。

align ツイートブロックをページ内で中央や右に寄せたい場合のオプション。'none', 'left', 'center', 'right' のいずれかにする。デフォルトは 'none'。'none' は普通 left と同じ左寄せになると思う。クォーテーションが必要。

lang 表示言語指定のオプション。例えば日本語なら 'ja' だし英語なら 'en' など。

[manabuueno]

Textwell アクション "Flickr Code" をアップデートしました

Flickr の API が https でしかアクセスできなくなったため、Flickr Code をアップデートしました。

Flickr Code のプログラムはサーバーサイドにあるため、アクションを入れ直す必要はありません。

尚、抽出した写真ファイルへのリンクも https へリダイレクトされるようになったため、最初から https の URL で挿入されるようにしてあります。

"Flickr にある写真をウェブページに貼り付けるための HTML を生成する Textwell アクション「Flickr Code」" http://manabuueno.tumblr.com/post/66081452103/flickr-html-textwell

[manabuueno]

PDCA サイクルはどこかおかしい気がする

PDCA PDCA とみんな言いますが、僕はこれずっと何かおかしいと思っているのです。

ウィキペディアによれば PDCA とは、

Plan（計画）：従来の実績や将来の予測などをもとにして業務計画を作成する

Do（実施・実行）：計画に沿って業務を行う

Check（点検・評価）：業務の実施が計画に沿っているかどうかを確認する

Act（処置・改善）：実施が計画に沿っていない部分を調べて処置をする

であって、これをサイクリックに繰り返すとのこと。

これの何がおかしいと感じるかというと、最後の Act のところです。

まず計画を立てて、それを実行してみて、その結果を評価する。ここまではいい。 けれど、その次に評価の結果を見て改善処置をする Act というフェーズが、他の Plan Do Check と並列になっているのはおかしい。

もしこれがサイクルではなくて、ウォーターフォールとしてはじまりと終わりがはっきりしているのであれば、

計画 → 実行 → 評価 → 改善

というフェーズ進行は分かる。

けれどこれをサイクリックにやるとすると、こうなる。

計画 → 実行 → 評価 → 改善 → 計画 → 実行 → 評価 → 改善 → 計画 …

これだと、改善した後にまた計画することになる。じゃあその計画って何？ 改善したことと次の計画との間に繋がりがないんですよ。

もし改善した結果を更に評価して、次の計画のインプットにするのであれば、改善の後に「評価（Check）」のフェーズがもうひとつ入らないといけないですよね。

計画 → 実行 → 評価 → 改善 → 評価 → 計画 …

で、もしそういうふうに改善の後に評価が入るなら、Do と Act はどちらも「やる」という意味だから、要するに、

計画 → 実行 → 評価 → 計画 → 実行 → 評価 → 計画 …

というふうに、Plan Do Check の三つで十分ですよ状態なわけです。

じゃあなぜ、Do と Act という、同じような意味の言葉をあえて区別しているのか。

普通に考えると、継続する事業において、計画と実行をサイクリックに繰り返して行くというのはまああたりまえのことです。 その際、実行した結果の評価というのは、次のサイクルのインプットになるわけです。

つまり、

Plan → Do → Check → Act

という場合の Act とは、次の「Plan → Do → Check」一式を指しているべきだと思うのです。

ニュアンスとしてはこんな感じ。

Plan → Do → Check → [Act = Next PDC]

だから PDCA サイクルじゃなくて、PDC サイクルと言えばいいんじゃないかと思うのです。 Act というフェーズは、PDC と並列ではなくて、再帰的に PDC 一式を呼び出す変数と考えると、納得がいく。

そう考えてよいなら、これはまあアジャイル的なプロセス感というか、ここに書いたようなシンプルなイテレーション感として、デザインのプロジェクトにもフィットすると思うのです。

それともこれ、何か計画を実行するなら一度だけそれを修正するタイミングを織り込んでおけよ、という話なのかな？

例えば毎年事業計画を立てるとして、4月から実行して、毎年9月に一回見直せよ、という。

でもそれだと単なるルーチンだから、フィードバックループが成立してるとは言い難い。つまりサイクルじゃない。

[manabuueno]

Xcode で "unrecognized selector sent to instance xxxx" といったエラーログが出てるけどそれがどこから来てるか分からない時

Xcode で "unrecognized selector sent to instance xxxx" といったエラーログが出てるけどそれがどこから来てるか分からない時。

Breakpoint Navigator を開く

下の "＋" ボタンを押す

"Add Symbolic Breakpoint..." を選択する

表示されたポップオーバーの "Synbol" の欄に -[NSObject(NSObject) doesNotRecognizeSelector:] と入れる

この状態で Run するとエラーが起きてるところで止まるので Debug Navigator を見て関係するオブジェクトやメソッドを特定できる。

情報元: Quick and easy debugging of unrecognized selector sent to instance

[manabuueno]

https://www.sociomedia.co.jp/5187

”Nice to have is not to have.” なのです。

[manabuueno]

https://www.sociomedia.co.jp/5170

"UXを向上させるためには、Try（試しにやってみる）と Catch（状況を把握して分析する）のセットを反復的に行うことが大切です。"

[manabuueno]

Twitter について前からミスデザインだと思ってること

Twitter について前からミスデザインだと思ってること。 1. メンションしたものが相手以外の他のフォロワーのタイムラインに現れない その結果、会話が公開されたものか非公開なものか曖昧な位置づけになるし、そのルールは恣意的。 2. DMは自分をフォローしている人にしか届かない これもルールが恣意的かつ暗黙的すぎる。前にそのルールを知らず、ある人にDMをいくら出しても返事がないと思ってたら、こっちが向こうをフォローしてなかった。非公開のメッセージ機能として誰に対しても送れるようにするか、あるいは互いにフォローしあってないと送れないようにすべき。 3. フォロー フォローとリストの違いが不明瞭すぎる。リストの方が、複数もてるし公開非公開を選べるので、理にかなっている。つまりリストだけでいい。 ------ つまり全体的に、恣意的なルールや似たような機能が多すぎる。あの禁欲的なところがなければとっくの昔に破綻していただろう。検索機能がいまいち弱いのはビジネスモデル（統計データを売る）のためだろうか。 公式サイトのお仕着せコンテクストを見ても、デザインのセンスが良いとは言えない。

[manabuueno]

外に出ると創造性が高まるという話

先日来日していたマーク・レティグ氏と食事をしている時に、クリエイティブワークにおいてはなぜビットよりもアトムの方が優れているのかという話になった。

具体的には、なぜパソコンの画面の中だけで作業するよりも、ワークショップや、付箋紙を使ったカードソーティングを行った方がよいのかという話。

レティグ氏によれば、リアルな場で共同作業を行う利点は次の三つ。

・身体を動かすと脳が活性化する ・直接会話をすればミスコミュニケーションを減らせる ・時間と空間を共有するとチーム意識が高まる

すると、心理学的観点からのUIデザインに詳しいスーザン・ワインシェンク氏も、最近同じようなことを書いていた。

The Brain Science Of Why Stepping Away Increases Creativity

これによると、人は何かひとつの課題に取り組んでいる時、脳の PFC（前頭前皮質）がフル回転して記憶の貯蔵庫を検索し、関連のある事項を複数抽出して組み合わせ、解決策を得ようとする。しかしタスクに集中しすぎるとこの組み合わせが硬直化してしまう。

そこで休憩をとって、散歩に出かけたり、庭いじりをしたり、シャワーをあびたり、皿洗いをしたりすると、PFC がうまい具合に解放されて、柔軟な発想力が戻ってくるのだそうだ。

寝る前にアイデアを思いついたり、帰ろうとするとバグを見つけたりするのは、緊張が和らぐ瞬間に脳が活性化するためなのだろう。

[manabuueno]

タクシー運転手は客にシートベルトを促すべきか

私はタクシーに乗ると必ずシートベルトを締めるようにしている。運転の荒いタクシーも多いし、夜遅くまで働いて帰り道で事故にあって死ぬなんてまっぴらごめんだからだ。

ある夜、タクシーに乗ると、運転手は中年の女性だった。いつものように私はシートベルトを締めた。それと同時に、車内に例の「お客様の安全のためシートベルトをお締めください」という音声ガイダンスが流れた。するとその運転手が、にやにやと笑いながら、バックミラー越しにこう言った。

「あ、シートベルトは別に締めなくてもいいですよ。今のガイダンスは決まりで流れてるだけなんです。すみませんねえ。」

私はそれを聞いてカチンときた。強い口調で言った。

「あなたそれはどういうことですか？ シートベルトして何がいけないんですか？ 私が自分の安全のためにやっていることをなぜやめさせようとするんですか。私の安全を奪う権利があなたにあるんですか。」

すると運転手は驚いた様子で、小さく「すみません」と言って押し黙ってしまった。

そのまま目的地に着くまで、車内はなんだか気まずい空気が続いた。

次の日、この話を知人の女性に話した。ルールを無視することを客にすすめるひどい運転手がいたと。

すると知人の女性は、ひどいのは私の方だというのである。その運転手は悪くない。客に叱責されて可哀想だと。

知人が言うにはこうだ。

その女性ドライバーは、たぶん、夫に先立たれたか何かで、女手一つで家族を養ってる。昼間はパート、夜はタクシーの運転手をやっている。毎晩何人も酔っ払いを乗せて、絡まれたりゲロを吐かれたりする。きついけれど受験を控えた子どものために歯をくいしばってがんばっている。シートベルトをしろというガイダンスが流れると怒り出す客もいる。運転手が女性だと分かるとおっさんは急に威張りだす。決まりだからお願いしますなどというと「お前、運転手の分際で客に命令しようってのか？ このあま！ もういい俺は降りる。」なんていうふうに客を逃してしまうことも一度や二度ではない。だからその女性運転手は、シートベルトのガイダンスが流れると、いつもにこやかに「締めなくてもいいですよ」と言うようになったのだと。

ほ、ほぅ…

いや仮にそうだとしても、本当に客のことを考えるなら、自分の運転を過信せずに、シートベルトを促す方が正しいサービスのあり方なんじゃないか？

と言ったところ、

正しいとかそういうことじゃない、もっと運転手の立場も考えるべきだ。そういう正論は上から目線だ。

と言われてしまった。

タクシー運転手は客にシートベルトを促すべきか、というタイトルだが、実はそこは本題ではない。本題は、サービスのあり方やユーザー体験の意味は、人によってかなり異なるということだ。

我々は何かサービスをデザインする時、できるだけ問題の本質を捉えて、最短距離でそこにアプローチしようとする癖がある。ユーザーにとっての合目的性や手段の効率性を重視し、場合によってはユーザーが意識すらしないうちに結果を出してしまうようなものが良いサービスだと考えるところがある。

でもそういった合理主義からのデザインは、ともすれば客観的すぎて、人によっては不快感や不信感につながることもある。もっと何かシステムとして突っ込みどころのあるインタラクションの方が、自分の生活にフィットするという感じ方もあるということかもしれない。

[manabuueno]

油絵が風景の光をよく現せるのは油がテカテカしているから

プログラマーは、画面デザインを見た時に、どういうロジックでその画面状態が成立するのかを考えますよね。つまり画面に見えているものは、プログラム実行の結果であると。でもプログラミングの知見が全く無いデザイナーは、自分が Photoshop なり CSS なりで描いた結果として画面を見ていると思います。

見栄えの固定された画面であればそれでいいのですが、イベントドリブンで画面が部分的に変化していく GUI では、画面は、変化の中のある瞬間のスナップショットでしかないわけで、画面デザインはむしろ変化のルールを決めることですよね。

ウェブというのが静的なドキュメント配信から始まったために、ウェブから入ったデザイナーは、オブジェクト指向とかイベントドリブンとかっていう GUI 構築の基本的なセンスを身につけていないと感じます。

スマートフォンのアプリは、画面が狭いために、GUI 的な作業空間の提示というよりも、紙芝居的に画面遷移していく表現が多いですから、初期のウェブのデザインと同じような感覚で作れてしまう。

でも本当にソフトウェアならではのイディオムを生み出していこうとしたら、ソフトウェアとしての美しさや完全性を分かっていないといけない。

建築家は建築素材の特性を活かしてものを設計する（木の柱に暖かみがあるのは、木が暖かいから）だろうし、画家は絵の具の特性を活かして絵を描く（油絵が風景の光をよく現せるのは、要は油がテカテカしているから）わけで。

[manabuueno]

UIにおける無限と有限

ソフトウェアデザインの世界に「Zero One Infinity」という言葉がある。プログラマーにとっては三つの数字しか存在しない。0か1か無限だ。これはソフトウェアを設計する際の基本的なルールであり、美学である。

あるエンティティのインスタンスが存在しうる数は、0か1か無限であるべきである。

例えばファイルディレクトリーを設計する場合、ルートディレクトリーは0個の親ディレクトリーを持つ。各サブディレクトリーは必ず1つの親ディレクトリーを持つ。そして各ディレクトリーは無限個の子ディレクトリーを持てる。（http://en.wikipedia.org/wiki/Zero_one_infinity_rule）

アランクーパーの本にはこういうことも書いてある。コインを100万回投げて、99万9999回は表が出て、1回だけしか裏が出ない場合、普通の人にとってこのコインは「いつも表が出る」と言えるが、プログラマーにとってそれは偽である。確率としてはほとんどありえないことでも、100万分の1でも起こる可能性があるなら、プログラマーはその状況を考慮して対処しなければならないし、むしろそういったエッジケースの方に強い関心を寄せるぐらいだ。

Zero One Infinity のルールは、ソフトウェアに、拡張性、変更可能性、可搬性などを与え、またリファクタリング性を高める。つまり、より少ないコードでより多くの動きを実現することが自然に促される。シンプルな原理で世界全体を現せるなら、高い完全性を得ることができるのだ。

この美学こそが、ソフトウェアに独特のアートをもたらしていると思う。

しかしそこで問題になってくるのは、ユーザーインターフェースのデザインだ。

ソフトウェアのユーザーインターフェース（GUI）は、ソフトウェアデザインの一環ではあるが、スクリーンという有限な二次元空間を前提にしなければならない。

そこでUIデザインを、プログラミング経験のない者が行うと、「Zero One Infinity」の感覚がないために、ソフトウェアとして成立させるのが難しいものが出てくる。無理にそのデザイン（ここでは画面の見た目の意）を押し通すと、ソフトウェアとしての品質が下がる恐れがある。

例えば何かのリスト表示なのだけど各行がばらばらなレイアウトだったりする。画面によって同じボタンの振る舞いが少しずつ違ったり、要素同士の組み合わせがあるひとつの状態だけでしか意味をなさないビジュアル表現だったりする。

もちろんそれぞれの複雑さに意味があって、ロジックを定義できるのであれば、プログラムとしてそれを実現する価値がある。けれどロジックにならない静的な見栄えとしてだけで感覚的に作られたものは、ソフトウェアとして害となる。

紙のデザインや、静的な単独表現としてのウェブページデザイン、固定的なフローのウィザード画面ならそれでもよいが、ユーザーになんらかの操作空間を提供するアプリケーションでは、デザイナーはもっと「Zero One Infinity」を意識しなければいけない。

例えばメニューをデザインする時、スクリーンの大きさは有限なので、デザイナーは「じゃあメニューは10項目までにしましょう」といった恣意的な制限を軽く決めようとする。けれど、各項目の大きさは固定なのか可変なのか、固定の場合はラベルは何文字までとするのか、ラベルは改行するのか、文字数を限定した場合それはプログラムで制御する必要があるのか… など、ソフトウェアとして実現するには多くの仕様定義が必要になる。

恣意的な制約は次の恣意的な制約を呼ぶ。プログラムには無駄な処理が増え、保守性は低下し、そしてそういった有限性によって最後にはデザインが破綻することもある。例えば優先度の高い決定事項として後からメニュー項目が12個になりましたとか。全部やり直しである。

Sometimes a Word is Worth a Thousand Icons

MS Office のツールバーは分かりにくいというのを冗談でこんな風にして見せたりする。けれど、こんな風に、いろいろな項目を好きなだけ追加していっても破綻しない（使い勝手は破綻するけど）ようなUIを実装するのは、かなり大変なことだ。その点、このデザイナーとプログラマーはがんばったと思う。

増える可能性のあるものは増えることを前提にデザインしなければならないし、統一できる部分はよほど明確な条件を定義できない限り統一しなければならない。

例えばスクロールは、概念的にはどこまでも無限にできる。フォルダは無限に入れ子にできるし、テキストボックスには無限に文字を書き込める。もちろん現実にはメモリーのサイズやOSの仕様などで無限とはいかないだろうが、普通に使う上では、ユーザーはその限界を意識しなくてもよいというのがいいだろう。

ちょっと前のバージョンの Excel では256列までしか作れなかった。これはユーザーにとってあきらかに「システム都合の意味不明な制約」となってユーザビリティを阻害する。一方、行数の方は、100万行ぐらい作れるので、通常は制約にならない。

もし技術的な制約で無限を作れない場合でも、ユーザーが意識する必要がないぐらい限界が大きければ、それは許容されるだろう。

「お気に入りメニューには7個まで登録できます」とか、「3つ前のバージョンまで戻せます」とか、そういうすぐにユーザーがぶち当たるような制限は、設けるべきではない。どうしても何かの制約で少ない数に限定しなければならないなら、1個だけとした方が美しい。あるいはもうその機能はやめる（0個）。

で、そういうソフトウェアデザインの美学を意識できるようになったら、ようやく、あらためて、今度は二次元空間の有限性に取り組んでいく。

スクロールは無限かもしれないが、ファーストビューは有限だ。人の認知も有限である。だからファーストビューに何が見えているかというのは、ユーザーにとって大きな意味を持つ。

ブラウザーのタブは、数え切れないほど増やせるが、一度に見渡せる数には限界がある。ウィンドウの横幅に入り切らなくなった項目はおかしなドロップダウンメニューに入れられてお茶を濁す。これは美学としてはよろしくないが、かといってタブが無意味かというと、多くのユーザーはこれを気に入って使っている。ほとんどのユーザーにとっては、ウィンドウ幅におさまる10個程度の項目が見えていれば事足りるということだろう。

つまり、プログラムの上では等価なインスタンスとして扱われる項目であっても、ユーザーにとっては重要度に違いがあり、UIではそれを適切に反映しなければならないということだ。

タイムラインでは最近の項目がリストの最上段に表示される。これは論理的にはかなりおかしい。普通、情報を二次元で表す時は、上から下へ、左から右へ（アラビア語などを除く）進行するのだし、文も上から下に向かって読み進める。タイムラインを時間にそって読もうとすると、ページの一番下から上に向かってスクロールしつつ、個々の投稿エリアの中では上から下に読むという苦行を強いられる。

しかしタイムラインを眺めるユーザーにとっては、その時の最新の項目が最も重要なものである（ことが多い）ので、無限の時間軸をあえて壊して、ファーストビューに重要なものが配置される仕掛けになっている。

そういった観点で、iPhone の標準レイアウトを見てみると、次のように言える。

スクリーン上部には、トップバーを1つだけ置ける。

スクリーン下部には、ボトムバーを1つだけ置ける。

トップバーには、左端にボタンを1だけ置ける。

トップバーには、中央にタイトルを1つだけ置ける。

トップバーには、右端にボタンを1つだけ置ける。

スクロールビューは、項目を無限に並べられる。

ボトムバーには、ボタンを有限に置ける。

この例では、ボトムバー（この例ではツールバーという部品）に置くボタンの数だけが有限で、デザイナーが適当な数を決定することになる。最大で10個ぐらい置けるが、操作性を考えると、5個ぐらいが限度だろう。

この図で示すような標準的なレイアウトは、SDK を使えばものすごく簡単にできる。けれどこれを逸脱して、例えばトップバーにボタンを4つ置きたいとか、そういうことをやろうとすると面倒なことをしないといけない。

要はこういうところに、Apple は自分たちの美学を反映させているし、それがガイドラインやフレームワークに組み込まれているのだ。

ここで「Zero One Infinity」に反するのはボトムバーだけで、そこがデザイナーのがんばりどころとなる。

画面全体をオリジナルな感じにしようとする前に、このへんの基本的な方針を汲み取っておいた方がよいだろう。

[manabuueno]

iPhone のアンテナ本数表示のデザインについて

iOS 7 になって、アンテナ本数表示の表現が変わった。

それまでは一般的な棒グラフ風の表現だったが、ただ丸が並んでいるだけの表現になった。

iOS 6

iOS 7

はじめこれを見た時は違和感があった。携帯電話の電波状態を示すグラフィックとしては棒グラフ状のものが圧倒的にスタンダードだったから。

こんなところで奇をてらわなくてもよいのにと思ったが、考えたら、自分がデザインするとしてもこの新しい方に近い表現にするだろうという気になってきた。

スタンダードを破るにはそれなりの理由があるだろう。Apple はアンテナゲートの時にも少しアンテナの表現を変えた。

アンテナゲート前（iOS 4）

アンテナゲート後（iOS 5）

この時の変化はわずかだが、アンテナゲート前にくらべて後のデザインでは、バーの1本目と2本目あたりが長めになり、これはおそらくバーが1本しか立ってなくてもそれなりに電波は掴んでるだよということが言いたかったのだと思う。

アンテナゲート前のデザインでは、ハイライトしている部分の面積比として、アンテナが1本しか立っていない時と5本立っている時で、1 : 25 ぐらいの差がある。つまりぱっと見の感覚として、アンテナが1本しか立っていないと、理想時の 25分の1 ぐらいの電波しかないように見える。でも実際はそこまで弱くはないので（知らないけど）、これを少しでもマシに見せたかったのだと思う。

では iOS 7 では何が言いたかったのか。

これはまず、インディケーションとしての論理性を高めたということがある。

従来の棒グラフ風のデザインでは、5本の縦棒が並んでいて、電波の状態がよくなるほど、左から順にハイライトが増える。一番左のバーだけがハイライトしていればそれは「5段階中の1」を表すし、左から3本がハイライトしていれば「5段階中の3」を意味する。

けれど、ハイライトしているバーの数とは別に、バーの長さがそれぞれ異なって5段階になっており、右に行くほど長い表現になっている。これだと、ハイライトしてるバーのうち一番右にあるバーの長さが現在の電波の状態という意味になる。

つまり状態を識別する情報として、ハイライトしているバーの数と、ハイライトしている一番右のバーの長さと、ふたつの要素が同時にあってコンフリクトしている。

このコンフリクトを解消するには、

A. バーは1本だけにして、それが5段階に伸びたり縮んだりする。

B. 同じ大きさのマスが5つ並んでいて、ハイライトした枡が左から増えたり減ったりする。

のどちらかしかない。

A をとると、あの20ポイントの高さの中で伸び縮みさせても現在の段階を識別するのは困難なので、必然的に B をとることになる。

というわけで、あの丸が横並びになったデザインを採用したのだろう。

もうひとつの理由は、この表現をとると、アンテナゲートの後のデザイン変更で示そうとした「バーが1本しか立ってなくてもそれなりに電波は掴んでる」ということがより正しく表せるということがある。

丸がひとつしかハイライトしていない場合、それは理想時の 5分の1 の電波強度であるように見える。これは恐らく、25分の1 に見えてしまうというのに比べれば、実際の電波状態を正しく反映していることになるのではないだろうか。

ということで、丸が5つ並んでいるデザインは、超かっこいいということもないけれど、Apple にとってはスタンダードを破る価値のある変更だったのだと推測する。