Category Archives: Uncategorized

Among software designers, Apple’s “Human Interface Guidelines (HIG)” is a very popular document. According to Mike Stern, Design Evangelism Manager at Apple, this document was first released in 1978, and it has been occasionally revised along Mac OS updates until today. Actually, HIG is written for developers for Mac applications. It introduces the user interface […]

神輿とその渡御には様々な方式があるようだが、そこにはオブジェクト指向プログラミングに通じるコンセプトがあるように思う。 インスタンス 神輿は祭の際に一時的に神霊を運ぶ輿であるが、神輿が氏子の町内を渡御している間、神様は神社を留守にしているのだろうか。複数の氏子町内で同時に渡御が行われることも普通であろうから、ひとりの神様が一度に一ヶ所にしか存在しないと考えるのは不自然だ。やはり同時に複数存在できるのだろう。これはインスタンス化のコンセプトと似ている。神社にある宮神輿がプロトタイプであり、その性質を継承した町内神輿がインスタンスとして new されていると考えるとよいだろう。 カプセル化 神輿は神社をかたどっている。神社は神様の家だ。神棚などと同様に、擬人化した偶像ではなく、その家をもって神のメタファーとしている点が興味深い。神殿の中には神様がいるはずだが、その中を覗くことはできない。社というインターフェースがエクスポーズされているだけだ。人々はそのインターフェースを通じて神とインタラクトする。これはカプセル化のコンセプトと同じだ。 ポリモーフィズム 神輿の形状や担ぎ方には様々なスタイルがあるだろうが、概ね似ている。人々は何本かの棒の上に社を乗せて、それを担いで運行する。神輿はとても重く作られているし、担ぎ棒は決して人間工学的に担ぎやすいようにはできていない。むしろできるだけシンプルでプレーンな構造を保っているから、それを担ぐものは身体的苦痛を余儀なくされる。しかしその苦痛が祭の高揚感と相乗して、独特の興奮をもたらす。神輿の楽しみは、神輿自体のインターフェースにあるのではなく、それを担いた者の内部に起こる集団心理的なエクスタシーから成っている。このシンプルなインタフェースと多様なアウトプットは、ポリモーフィズムと言えるだろう。

プロレタリア文学やプロレタリア児童文学というジャンルはあるが、プロレタリア絵本というのは聞かない。 そこで単なる思いつきではあるが、好きな絵本の中でそれっぽいものをとりあえず三つ挙げる。 3位 – 『みんなの世界』 マンロー リーフ（光吉 夏弥 訳） 「もしも、このひろい世界に、人がたったひとりしかすんでいなかったら」という問いかけで始まるこの本は、民主主義のコンセプトを、身近な事柄を例にしながら順序立てて、子どもに教えてくれる。（そこまでプロレタリアというわけではない…） 社会とはどういうものか、なぜ社会にはルールがあるのか、なぜ選挙で投票に行くべきなのか、といったことを、暮らしの中の必然として、やさしい言葉と無邪気な絵で説得していく。 2位 – 『絵で見る日本の歴史』 西村 繁男 巨匠西村繁男の歴史もの。各時代を見開きで描き、石器時代から戦後の高度経済成長までの、日本の生活風景を絵巻のように展開する。 普通、歴史ものというと、各時代の権力闘争や上流階級の文化様式が主題となる。しかしこの絵本の主人公はあくまでも市井の人々だ。 弥生時代に卑弥呼は出てこないし、安土桃山時代に戦国武将は出てこないし、太平洋戦争の時に兵隊は出てこない。描かれるのは、農民、古墳や城を築く労働者、空襲で逃げまどう銃後の人々である。 1位 – 『とべバッタ』 田島 征三 田島征三も名作ぞろいだが、これはもう歴史的大傑作と言わなければならない。「とにかく騙されたと思って読んでみな」と言われて読んだら、途中から瞳孔が開きっぱなしになった。 内容については、もう、「とべバッタ！ とべバッタ！ とべバッタ！」としか言えない。 以上。

Mac の Cocoa フレームワークには First Responder という概念がある。First Responder は、ユーザーのマウス操作やキーボート操作などのイベントに最初に反応するオブジェクト、つまり現在フォーカスされているUI要素を参照する変数である。ユーザーがアプリケーションを操作してフォーカスが別のコントロールに移ると、First Responder の示す先もそれに応じて変わる。これは GUI におけるポリモーフィズムを実現するための仕組みだ。例えば Finder のメニューバーには「File > Open」という項目があるが、現在フォルダが選択されている時にこれを実行するとそのフォルダが開き、アプリケーションアイコンが選択されているとそのアプリケーションが起動し、ドキュメントファイルが選択されていると適当なアプリケーションが起動してそのファイルを読み込む。このように選択されているものによって処理が異なるのだが、メニュー項目の「Open」が行っているのは、現在の First Responder に対して “Open” というメッセージを投げることだけである。フォルダ、アプリケーション、ファイルなどはそれぞれ種類の違うオブジェクトだが、いずれも “Open” というメソッドを持っているので、それぞれが自分の Open メソッドを実行して、それぞれの振る舞いをするというわけだ。Open 以外にも、Close、Save、Print、Select All、Find、Undo など標準的な名前のメソッドを各アプリケーションが実装していれば、キーボードショートカットも含めて、システム全体で操作が一貫する。 GUI におけるポリモーフィズムというのは、インタラクションデザインの上で重要な意味を持つ。GUI における操作シンタックスの基本は「オブジェクト選択 → アクション選択」である。操作の対象となるオブジェクトが画面に見えていて、ユーザーがそれをマウスなどで選択し、次にメニューなどからアクションを選択する。このシンタックスこそが GUI を GUI たらしめているのであり、CLI との最大の違いはこのシンタックスにある。CLI では先にコマンド（アクション）を指示するが、これはあらかじめユーザーが学習によって記憶しているか、あるいは操作の度にヘルプを参照しなければならない。GUI の最初の行為であるオブジェクト選択は、選択肢が目に見えていてそれを指し示すだけなので、事前の準備はいらない。また CLI においては、コマンドを打った後に引数となるパラメーターを指示することになるが、これもまた頭の中に記憶しているものかもしくは画面に見えている文字列を打ち直すことになるので、認知負荷が高い。GUI においては、コマンド選択はメニューを見ながら行うか、もしくはダブルクリックなどのジェスチャで行うので、認知負荷は低い。その際、ジェスチャやキーボードショートカットなどのグローバルなコマンドは用意できる種類と数が限定的だし、メニューにしてもある程度項目数を絞らないと使い勝手が悪いので必然的に、複数のオブジェクトが共通のアクションを持つことが望ましくなる。そのために、First Responder のような仕組みが役立つのだ。CLI では、システムの拡張はコマンドの追加によってなされるだろうが、GUI では、オブジェクトの追加によってシステムが拡張するのである。 この GUI のオブジェクト指向性は、CLI のタスク指向に対して、よりモードレスである。なぜなら CLI においては、引数を必要とするコマンドを打った直後は、続けて引数を入力することがシステムから期待されている。一方 GUI […]

シェアメニュー 他のアプリにコンテンツをルーティングするための一元的なメニュー。Textwell/DraftPad のアクションメニューとほぼ同じコンセプト。今でこそ当たり前の機能だが、ルーティング用のメニュー（しかも項目を追加していける）というものを iOS で最初に作ったのは DraftPad だと思う。 アクションシートのエクステンション アクションシートにサードパーティがアクションを追加できる。Textwell/DraftPad のアクションと似たコンセプト。 アプリ内からツイート OS X と iOS ではアプリ内からツイートする仕組みがある。それができる前、Twitter の iOS 用 SDK もない頃から、テキストエディタである DraftPad 内から直接ツイートできた。 自動保存 OS X のドキュメントベースアプリケーションでは、適当なタイミングで自動保存がかかる仕組みがある。Textwell/DraftPad が先にやっていた。（デスクトップではよくある機能ではあったが） 自動ヒストリー OS X のドキュメントベースアプリケーションでは、適当なタイミングで自動保存がかかり、それはバージョンと呼ばれるヒストリーとしてドキュメント内部にスタックされ、あとからリストアできる。これも Textwell/DraftPad が先にやっていた。バージョンでは、リビジョンを通じての検索はできない。Textwell/DraftPad ではできる。（検索できないとリビジョンを作る意味が半減すると思うのだが） フリーカーソル iOS 8 から、テキストビュー上でカーソルを指の動きに合わせて全方向に移動できるようになった。ほぼ同じ実装を Textwell が先にしていた。 （追記: 2019-10-08） iOS 13 ではテキストビューのジェスチャがまた変更され Textwell に更に近づいた。すなわち、テキストビューの上で1本指で直接カーソルを自由な場所へ移動できるようになった。これにより Textwell のフリーカーソルとほぼ同等のことが標準のジェスチャでできるようになったので、Textwell の時期バージョンでは独自のフリーカーソル実装を捨てることになるだろう。 JavaScript でマクロ OS X […]

この記事は、ノンプログラマー向けに、URLエンコードとは何かを簡単に説明するものです。 Textwell のアクションでは、T( ‘urlScheme’ ) というコマンドを使って、Safari を呼び出したり、他のアプリを呼び出したりできます。 例えば、Apple のホームページを開きたければ、アクションのソースとして以下のようにスクリプトを書きます。 T( ‘urlScheme’, { url: ‘http://www.apple.com’ } ); “url:” という記述の後ろに、Apple ホームページのURLがクォーテーションで囲んで書かれているのがわかると思います。このURLの部分を変えれば、他のホームページやアプリケーションを呼び出せるようになります。スクリプトでは、任意の文字列（この場合はURL）はクォーテーションで囲まなければいけません。 T( ‘urlScheme’, { url: ‘http://www.google.com’ } ); このようにすれば、Google のページが開きます。 次に、Textwell のアクションから Google で何かのキーワードを検索させるにはどうしたらよいでしょうか。 Google のページでは、キーワード入力欄にキーワードを入れると検索が実行されて検索結果ページが表示されますが、ページ上でキーワードを入れなくても、URLの後ろにキーワードをつけたしてそれをブラウザで開くことで直接検索結果ページを開くことができます。 例えば、”Apple” というキーワードを検索した結果ページを開きたければ、ブラウザのURLに次のように打ち込みます。 http://www.google.com/search?q=Apple “http://www.google.com/” という Google の URL の後ろに “search?q=” という決まった呪文をつけて、その後ろにキーワードを書けば良いのです。 この URL を Textwell のアクションにしてみます。 T( ‘urlScheme’, { url: ‘http://www.google.com/search?q=Apple’ […]

UI理論101問題: このボタンは全て無くすことができますが、ひとつだけ残すとしたらどれでしょうか？ pic.twitter.com/UFcG2h4PE8 — Manabu Ueno (@manabuueno) 2015, 12月 18 このツイートが意外にもたくさんRTされていたので、解説してみる。 UI設計理論としてはまず、「目的達成までのユーザーの運動と認知の負荷を減らす」という考え方をするのが基本だ。同じ結果を得るためなら、操作や選択肢は少ない方がよい。UIはユーザーにとってオッカムの剃刀であることが望ましい。 ただしシステムを利用して目的を達成するプロセスには「テスラーの複雑性保存の法則」というものがあり、入力しなければいけない情報を一定以上減らすことはできない。 一般的なエレベーターを利用する上で必要となる最低限のインプットは、次の6つだろう。 エレベーターを呼ぶ合図 乗るためにドアを開ける合図 乗った後にドアを閉める合図 行き先階 出発の合図 到着した際にドアを開ける合図 テスラーは、複雑性は減らせないが移動はできると言っている。必要なインプットの負担をユーザー側からシステム側に移動することで、ユーザーにとっての労力を減らすことができる。 一般的なエレベーターにおいては、上記の6つのうち、2, 3, 5, 6 については適当なタイミングで自動的に行われるようになっているので、ユーザーが行うのは 1 と 4 だけである。1 はエレベーター外の上下ボタン、3 はエレベーター内の階数ボタンを使ってユーザーがインプットする。 これらはユーザーが特定の階に移動するために必要な操作だが、実際にはこれらに加えて、自動化された動作をキャンセルする機能があるのが普通だ。すなわち次の2つ。 ドアが閉じようとするのをキャンセルする合図 一定時間を待たずにすぐにドアを閉じる合図 7 は開くボタン、8 は閉じるボタンで行われる。開くボタンについてはスプリング式になっていて、押し続けている間その合図が継続する。また開くボタンは、エレベーターが移動している最中には安全のためにディスエーブルになっている。ふたつ以上の合図が同時に発せられた場合は、安全な方に寄せて他は無視される。 開くボタンは、自動的に閉まろうとするドアに（自分を含めた）誰かが挟まれないよう、エレベーター内の人が押すためのもので、安全のためのスイッチだ。一方、閉じるボタンは、急いでいる人が早くエレベーターを出発させたい場合にのみ使うものであるため、重要度は低い。閉じるボタンが無いエレベーターも存在する。 またドアには通常、安全装置があり、物が挟まるとドアが開くようになっている。これに加えて、赤外線センサーによってドアに物が接触するのを防ぐ機能を備えているものも増えている。 エレベーターのボタンの押し間違いで一番問題になるのは、「ドアを開こうとして間違って閉じてしまう」時である。なぜなら、安全のためにとった行為が、かえって危険な状況を作ってしまうからだ。このリスクを考えると、閉じるボタンの存在はかなり問題だろう。閉じるボタンが無いエレベーターではこの問題は発生しない。ボタンがふたつ並んでいれば必ず押し間違いが起こるが、ひとつなら起こらないからだ。 閉じるボタンの無いエレベーターでは、階数ボタンを押すとすぐにドアが閉まるようになっていたり、階数ボタンの長押しでドアが閉まるようになっていたりするのを 見たことがある。これらは、行き先を指定する行為＝出発の意思という解釈をしているのであり、複雑性の移動方針としては理にかなっていると思った。またこれらはいずれもセンサーつきであったため、閉まろうとするドアに挟まってしまうこともなかった。 つまりドア自体に備わっている安全装置がうまく機能するなら、7 と 8 は自動化されるので、開くボタンも閉じるボタンも理論上は不要になる。 銀座 Apple Store のエレベーターには行き先階ボタンも開閉ボタンもなく、自動的に全階に止まりながらシャトル運行し続ける。当然センサーによる安全装置が働いている。 さて、今回のエレベーターだが、駅によくあるタイプのもので、写真で分かるとおり、ふたつの階を行き来するだけのものだ。つまりユーザーの行き先は常にひとつしかない。現在ユーザーがとれる操作がひとつしかないなら、その操作は自動化できる。現在有効な選択肢がひとつしかないなら、オッカムの剃刀として、その選択行為は省略できる。 だから8つのインプットのうち、4 もシステム側に移動でき、写真にあるボタンは全て無くすことができる。 ここで、ボタンがなくなったエレベーターの動きを想像してみる。 […]

iOS には、あらかじめいくつかのタッチジェスチャを認識する API が用意されている。 ジェスチャとは、プリミティブな入力イベントの特定の組み合わせをひとつの意味として扱うものだ。例えばパソコンであれば、マウスボタンの押し下げ（マウスダウン）やそれを放すこと（マウスアップ）がプリミティブな入力イベントの例であり、このふたつを連続して一定面積内で行うと、クリックというジェスチャになる。一般的なマウスのジェスチャには他にも、ムーブ、ダブルクリック、ドラッグなどがある。 タッチデバイスではマウスのかわりにタッチイベントが用いられるが、プリミティブな入力としては、例えばタッチの開始や終了がある。指をスクリーンに触れて、それを一定面積内で放すと、タップというジェスチャになる。 iOS では、基本的なジェスチャとして次の7種類が想定されており、これらの動作を検出する API が用意されている。 タップ ピンチ ローテーション スワイプ パン スクリーンエッジパン ロングプレス それぞれには更に、指の本数や、動作の段階（ジェスチャが開始された、継続中、終了した）ごとに処理を変える仕組みが含まれている。 つまりタッチジェスチャは、マウスのジェスチャに比べて、バリエーションが多い。 バリエーションが多いと言っても、例えばダブルクリックがシングルクリックの二連続でできているように、ジェスチャによっては他のジェスチャの組み合わせでできているものもある。例えばスワイプジェスチャは、水平もしくは垂直方向に、一定以上のスピードでパンすることを意味している。 別な言い方をすれば、ある指の動作が、AのジェスチャなのかBのジェスチャなのかという判定は、マウスの場合に比べて、かなり微妙なものになっている。 また、同一画面上で同じ種類のジェスチャが複数の意味で実装されていることも多い。例えば iOS 9 のホーム画面では、水平方向のパンはアイコン一覧のページめくり、下方向へのパンは検索窓の表示、画面下辺付近からの上方向パンはコントロールセンターの表示、画面上部付近から下方向のパンは通知センターの表示、というふうに、いくつものパンジェスチャが実装されている。 複数のジェスチャを同一画面上に実装する場合は、通常、ジェスチャ同士に優先度をつけて、あるジェスチャが発動したら他のジェスチャはキャンセルされるようになっている。ホーム画面の例であれば、下方向へのパン操作が行われた時、それが画面上辺付近から開始されていれば、通知センター表示が優先され、検索ボックス表示の処理はキャンセルされる。 ジェスチャのバリエーションが複雑な分、こういった優先度づけやキャンセル条件などの処理は非常に入り組んだものになりがちだ。操作の示唆が暗黙的な分、ユーザーはうまく操作できないこともあるだろう。 Apple Watch のデジタルタッチ Apple Watch では、サイドボタンからフレンドを選んでデジタルタッチと呼ばれる特殊なメッセージを送信することができる。 デジタルタッチには三種類のモードがある。スケッチ、タップ、ハートビートだ。スケッチは指で線画を描くもの。タップはスクリーンをトントンと叩くもの。ハートビートは現在の心拍をモニターする。 これらのデジタルタッチは、リアルタイムに相手のウォッチ画面に表示される。タッチデバイスならではの非言語的なインスタントコミュニケーションだ。 デジタルタッチによるやりとりが実際に面白いかは置いておいて、その仕様はよくデザインされていると思う。 Apple Watch ではデザインガイドラインとして、ユーザーに複雑なことはさせるなと謳っている。デジタルタッチを送る時にも、送信ボタンを押したりモード変更の操作をする必要はない。 どのようにモードが決定されるのかというと、指でスクリーンをなぞる（パンジェスチャ）とスケッチモード、指でスクリーンを軽く叩くと（タップジェスチャ）タップモード、二本指でスクリーンを押さえつけると（二本指ロングプレス）ハートビートのモードになる。 このように事前の手続きなしでモードが作られるところがよい。三つが異なるジェスチャなので、判定が混乱せずに済むようになっている。 モードの決定はメッセージを作成する動作と自然に対応しているので、モードレスモードとなっている。 中でもハートビートは秀逸だ。 ハートビートは現在の心拍を継続的に相手に送りつづけるものだから、開始と継続と終了の合図をひとつの動作で行えるように、長押しのジェスチャーを用いるのは自然だ。また、センサーが正しく心拍をモニターするにはウォッチ本体を手首に密着させる必要があるが、二本指でスクリーンを押すという動作がそれを助けている。これがもし一本指だと、パンやタップのジェスチャと誤判定してしまったり、モニタリングに失敗するかもしれない。二本指の長押しという特徴的な動作が他のジェスチャとの明確な区別となっていて、はじめは学習が必要だが、ユーザーにとってのジェスチャの発動させやすさ、システムにとっての判定のしやすさ、そして心拍モニタリングを正確にするための「コンストレイント」になっている。 コンストレイントとは、デザインにおける制限のこと。ユーザーの行動を意図的に制限することで、誤操作を減らしたり有効な使い方を促したりするテクニックだ。 例えば、昔の自動車ではイグニッションキーとエンジンスタートのボタンが別々になっていたという。それだとキーを挿し忘れたままエンジンボタンを押すという操作ミスが起こる。イグニッションキーを刺さなければエンジンスタートの合図が出せないようデザインに制限を持たせることで、問題がなくなった。ユーザーにしてみればキーを使うこととエンジンを動かすことは目的が一致しているので、制約は自然なものとなり、行動が抑制されたような窮屈さは感じない。むしろ合理的であたりまえのデザインだと感じる。 タッチジェスチャは暗黙的でありかつ誤判定しやすいものだが、Apple Watch のデジタルタッチはそれをうまく扱っている。

UITextView のバグと対策 iOS 7 より UITextView の挙動が著しくおかしいということについて「iOS 7 のテキスト入力欄（UITextView）の問題について」に書いた。iOS 8 においても UITextView のバグは直されなかった。 iOS 9 が発表され、SDK をいじってみて、なんとなく直っているような気がしたが、それは気のせいだった。全体的には少しずつ改善されているように思うが、依然として振る舞いが安定しない。特に、カーソルがスクロール外の位置にある時に、ビューをカーソルが表示されるところまでスクロールさせるメソッドがうまく機能しないので、カーソルを見失ったような状態になりますい。この現象は純正アプリも含めて、UITextView を使った色々な箇所で見受けられる。 私がプロダクトマネージャーをつとめる Textwell の iOS 版では、UITextView のバグを回避するための補正処理として、具体的に、以下のメソッド/プロパティをオーバーライドしている。 ・scrollRangeToVisible: カーソルが見える位置までビューをスクロールするメソッドだが、テキストレンジの座標が正しく計算されていないようなので、自前でそれを計算し直し、”scrollRectToVisible:animated:” に投げる。 ・closestPositionToPoint: 特定の座標に一番近いテキストポジションを返すメソッド。タッチジェスチャとテキスト処理の橋渡しをする重要なメソッドだが、時々おかしな値を返してくるので、レイアウトマネージャーのグリフ情報を使って正しいポジションを返すようにする。 ・layoutManager.allowsNonContiguousLayout デフォルトでは NO だがこれを YES にする。 ・layoutManager.hyphenationFactor デフォルトで 0 のはずだが、何かの拍子に値が変わるのかもしれない。0 に指定し直すと挙動がましになる気がする。 これらを行うことで、概ね iOS 6 までの UITextView と同じ挙動になる。 Textwell v1.4 までのジェスチャ ここから本題。 iOS 9 をターゲットにリリースした Textwell v1.5 […]

UIデザインに20年近く携わってきた私としては、昨今、「UX と UI は違う」と多くの人が言うのを聞くたび、違和感を覚える。なぜなら、彼らが UX と呼んでいるものはまさに、我々がずっと「ユーザーインターフェースデザイン」と呼んできたものだからだ。それは決して画面の表層的なグラフィックを指すものではなかった。システムが提示する概念モデルや、サービスが提案する体験価値を、合理的なインタラクションの蓄積として現すこと。ユーザーが知覚するシステムの全体像を定める試み。それがUIデザインだったし、そういうスコープで HCI や UCD はテーマづけされてきたと思う。 そもそもユーザーインターフェースという概念はかなり抽象度が高いと思っている。まず、ユーザー（利用者）という言葉は、人間というものに対する人工物の存在を前提としていて、人が道具を作り道具が人を作るという、社会や文化の根本的な発展スパイラルを暗示している。人工物の機構がソフィスティケートされると、そのロジックは我々の運動や認知のプロトコルから乖離する。そこで、人と道具を仲介するための新しい抽象レイヤーとして、人と人工システムとの関係性をひとつの意味空間にまとめるものとして、ユーザーインターフェースの概念が生まれた。だからUIデザインというのは結局、サービスのモデリングであるし、体験のデザインなのだ。 90年代までに、特にソフトウェアのUIデザインというジャンルを強く意識していたのは、ほぼ確実に Mac ユーザーだったと思う。なぜなら、GUI が持つ道具としての魅力は Mac によって知らしめられたのだし、その設計思想や方法論を早くからまとめあげていたのが Apple だったからだ。”The Art of Human-Computer Interface Design”（『ヒューマンインターフェースの発想と展開―人間のためのコンピューター』）は1990年の出版だが、当初 Apple 社の Human Interface Group が教育用に企画したものであったこの本には、Alan Kay、Donald Norman、Ben Shneiderman、Bruce Tognazzini、Ted Nelson、Nicholas Negroponte、Timothy Leary といった面々のハードコアなユーザーインターフェース論が掲載されており、80年代後半から90年代前半までの熱狂的な（しかし世間一般ではまだジャンル化されていなかった）「UI熱」を感じ取ることができる。 しかし UX という言葉が台頭するに伴い、UI はソフトウェアの画面のことというふうに矮小化されてしてしまった感がある。 なぜ、UI は UX と言い換えられるようになったのか。 User Experience という言葉は、90年代後半には（小さなUIデザイン業界で）けっこう普通に使われていた。例えば私は1998年ぐらいに infoperience.com というドメインを取ったが、これは、User Experience の変化形として Information Experience […]