Category Archives: Uncategorized

Textwell のスクリプトでURLエンコードする意味と方法

この記事は、ノンプログラマー向けに、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 のタッチジェスチャと Textwell

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 […]

UX は iPhone によって発見された説

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 […]

UXの語感

UXという言葉は2005年ぐらいにはすでにバズワードだったが、その後もますますバズっぷりを増している。 UXという言葉は人によっていろいろな意味で使われるとよく言われる。実際、私も仕事でいろいろな人がいろいろな意味で(そして真面目に)UXという言葉を使っているのに遭遇する。 デザインコンサルタントとしては、UXを何かひとつ定義づけることよりも、世間でこの言葉がどのような使われ方をしているのかを知ることの方が重要だ。 ちなみに、私の定義はとても簡単だ。誰かが私に「UXとは何ですか?」とたずねれば、私はこう答える。 「利用者体験のことです」 それ以上でも以下でもない。英単語の直訳で十分意味のある言葉だと思う。 例えば「デザインって何ですか」とか「UIって何ですか」といった質問に答えることの方がずっとコンセプチュアルで難しい。UXは簡単だ。 ただ世間でいろいろなニュアンスが盛られて使われているようだ。 UXという言葉が使われる時の観点をざっくり分類すると、 UIの操作性の観点 デザインプロセスの観点 マーケティングの観点 組織スローガンの観点 といった感じになるように思う。もちろんそれぞれはクロスオーバーしている。 この分類に従って、以下に、私がよく見聞きする、UXという言葉の使われ方を挙げてみる。 UIの操作性の観点 UXとは、UIのこと それまで良いUIというものを意識的に作ろうとしたことがなかった現場においては、ちゃんとUIを作るという発想自体がかなり新しいパラダイムとなる。彼らはそれをUXと呼ぶ。このニュアンスで RFP に「UXのリニューアル」とか「UXの全面見直し」と書かれていたことがある。 UXとは、ユーザビリティを考慮した画面設計のこと このニュアンスは SIer や情シスなどの人々の言葉でよく耳にする。「今度の案件ではユーザーがUXを要求しています」といった感じで使われる(ここでいうユーザーはユーザー企業/部門=クライアントのこと)。聞いていくと、使い勝手を考慮した画面のことらしい。このニュアンスで、RFP に「UX納品:○月○日」とか「UXを適用する」とか書かれていたことがある。 UXとは、直接操作感とマイクロアニメーションのこと スクロールのスムーズさとかタッチ入力の精度をもってUXが優れているなどという。ビューが遷移する時のトランジション効果とか、タッチ操作に対するUI要素のビジュアルフィードバックなど、従来なら実装コストの関係でオミットされていたような小粋なアニメーションを積極的に取り入れることも重要。製品やサービスのアハ体験。ただサイドイフェクトとして、学習可能性や発見可能性を無視した珍妙なUIを見て「このUXは新しい」などと持ち上げる素人評論家が多数発生しているのも事実。 デザインプロセスの観点 UXとは、観察インタビュー、プロトタイピング、ユーザビリティテストなどをやること 要するに UCD とか HCD と呼ばれるプロセスだが、以前から提唱されてきたそういった方法論や呼び方を知らない人々がその手の取り組みセットをUXと呼んでいる。サービス事業者のインハウスデザイナーなどが「うちでもUXを取り入れないと」などと言ってる場合はこれに近い。UXという何か決まったメソッドが存在しているという前提でこの言葉を使う。膨大なポストイットにいろいろ書いて壁一面が埋め尽くされることで俺たち仕事した感が漂ってしまったりするのもこれ。このニュアンスで、RFP に「UXを行うこと」と書かれていたことがある。 UXとは、アジャイルにデザインすること ウォーターフォールに対するカウンターとして、ユーザビリティ担保のコスト最適化として、あるいは資金調達の攻略テクニックとして、プログラミングの世界で実践されてきたスパイラル式のイテラティブプロセスをデザインプロジェクト全体に適用しようという、たいへんまっとうな取り組みが盛んになりつつある。ただしデザイン全般となるとプログラムのようにはモジュール化できないので、実際にはモバイルアプリのような小規模なシステムでしか実践は難しいと思われる。そもそも今デザインスプリントとか言ってる層が大規模エンタープライズシステムなどの開発プロセスに口を出せることはほとんどない。自然にスクラムとかを回してるようなスタートアップにおけるUX。 マーケティングの観点 UXとは、サービス企画のこと ユーザーモデルとか課金モデルとかプロモーション方針とかを最上流で定義すること。いってみればサービス企画。「UIは画面のことで、UXはもっとサービス全体のこと」といったことを言う人は、だいたいこれ。代理店の下請けとかが多い制作会社の人などが「うちらももっとUXやりたいよね」などと言う。 UXとは、クロスチャネル/ロングタームのサービス設計のこと あるサービスについて、複数の媒体や製品を通じて価値提供するためのサービスモデリング。マーケティング視点での要求分析フェーズ。従来からブランド戦略などと合わせて普通に取り組まれていたことだが、「モノよりコト」みたいな俺いいことに気づいた的な新人デザイナーなどが俺らもクライアントのビジネスにコミットしなきゃ的な勢いで To-Be のジャーニーマップを小綺麗に作ると最先端のUXを設計したことになる。エクスペリエンスという言葉をサービス利用のストーリーと解釈し、ユーザー行動をコントロールしようとする。 UXとは、ユーザーがはまる仕組みのこと アプリなどで、メインの機能仕様に加えて、オンボーディングとかソーシャルマネージメントとかあなたの友達もこれを使っていますとか既読とかガチャとかそういうの。こういったユーザーに行動変化を促すノウハウは Persuasive Technology といった言葉で言われてもいたが、競争が激しくなった結果、これらはユーザーの時間やお金をいかに奪うかというチャレンジとなり、一種の広告宣伝活動に変化した。そしてそれらをプロダクト自体に組み込むのが流行ったため、今や多くのアプリは釣り記事とかカジュアルゲームと同じ大量消費の対象物となっている。すでに運用中のサービスに後付けすることができるのがこのUX。「うちのサービスにはUXが足りない」などと言う。 UXとは、とにかくマーケットインでデザインすること とにかくユーザーからの評価とか利用ログをインプットにして製品改良を重ね何でもいいから売れるものを作りたいという人々にとっての活動。行動経済学的知見をデザイン知見だと考える。ユーザビリティテストにしろ A/B テストにしろ、サービスモデル全体のデザインより特定の機能や表現についての部分最適化が促進される傾向をもたらすが、経営者層に対してはビジネスノウハウの一環として最も説得力があるUX。利用者体験というよりも顧客体験。顧客の行動特性を応用して財布の紐をゆるませることがUXのミッションとなる。 組織スローガンの観点 UXとは、デザインを重視して製品を作る組織活動のこと […]

マテリアルは逆説じゃなかった

“エントロピーとデザイン” で私は、「ソフトウェアによって将来、この物理世界とは全く違う価値観からの精神活動が営まれるであろうことは想像に難くない。」と書いた。だから無限のデジタル世界と我々がインタラクトするには、新しい言語が必要になる。少なくともまだしばらくそれは、共時的な情報を表すのに適した、視覚言語であるはずだ。 デジタル世界のイディオムが発展して、物理に束縛されない秩序によって精神活動が営まれるようになるということは、言語に高い抽象化の性能が求められるということだろう。 幾何学的で平面的なグラフィックは、コミュニケーションの抽象化に則したチャレンジだ。そこではもはや、GUI の表現力はスクリーンサイズに比例しない。 Google のマテリアルデザインは、きっとその名前からは逆説的に、視覚表現の抽象化の指針として作られたのだと期待していた。けれどこのビデオを見ると、どうも違ったようだ。 Making Material Design 彼らは GUI を、薄っぺらい紙をいくつか重ねたものだと考えているらしい。重ね順に気をつけろとか、影の落ち方に気をつけろとか言っている。逆説でもなんでもない、彼らは本気で物質(マテリアル)感を醸し出そうとしているではないか。ならばこれはスキューモフィックのひとつにすぎない。時代に逆行してないか? たぶんあれだろう。スクリーンを埋めるビューとそのヒエラルキーとかトランジションとか、ちゃんと整理して構成しろよっていう、そういう実装モデルにひきずられてしまったんだろう。 GUI が努めるべきはむしろ、物質感の排除だ。デスクトップメタファから脱するには、グラフィックの記号性をもっと高めて、デジタルネイティブなイディオムを発明していく必要がある。もう奥行き感とかドロップシャドウとかやめないといけない。巻き物メタファのスクロールもやめていい。 その意味では、Apple Watch のグラフィックはちょっといい線を行っている気がする。二次元的とも三次元的ともつかない、黒い背景に記号だけが漂っているような調子がいい。抽象的な図形とマイクロアニメーションで構成されたインタラクション。小さなスクリーンを前提として、はじめから箱庭を捨てている。    Apple Watch に見られる GUI イディオムはまだ模索されはじめたばかりなので中途半端な部分も多いが、いろいろと表現を試してみる価値のある方向性だと思う。

鏡はなぜ左右は反転するのに上下は反転しないか

鏡はなぜ左右は反転するのに上下は反転しないのか? 私はこの素朴な疑問を「鏡問題」と呼んでよく考えている。 洗面台の鏡の前に立ち、右手を上げると、鏡の中の自分は左手を上げている。左右が反転している。 次に頭を振ってみると、鏡の中の自分は足を振るわけではなく、頭を振っている。上下は反転しない。 鏡問題については誰もが一度は考えたことがあると思う。誰もが何らかの回答を試みるが、この問題の面白いところは、人によって回答がいろいろであるところだ。 よくある回答のひとつは、「左右は主観的だが、上下は客観的だから」というもの。 左右の方向は見る立場によって変わるが、天地の方向は一定している。 しかし、では鏡の前で寝転がってみる。右手は天の方向にあり、左手は地の方向にある。そこで右手を上げると、鏡の中の自分はやはり逆の左手を上げているではないか。 よくある回答のもうひとつは、「左右は反転していない、前後が反転しているのだ」というもの。 いやいや、前後が反転しているのなら、私が鼻をかいたら、鏡の中の自分は頭の後ろをかいていないといけない。けれどそうはならない。 これと似たような回答に「左右は反転していない、表裏が反転しているのだ」というのもあるが、それだと鏡の中の自分は体の中身が皮膚の外に出てしまって見るに耐えない感じになるはずだ。だがもちろんそうはならない。 まれに、「左右だけでなく、実は上下も反転している」というのもある。 でもそれはおかしい。それだと鏡の中の自分は常に逆立ちをしていないといけないから。 そう言うと、上下反転論者は、「鏡を足の下におけば、左右も上下も反転する」という。 確かにそうかもしれないが、ではなぜ鏡の置き場所によって反転の具合が変わるのか? 上下反転論者はこの疑問には答えられない。 いろいろググって、鏡問題を比較的よく説明していると感じたのはこのページだ。 ここではこういう感じの回答をしている。すなわち、左右は反転していない。なぜなら自分から見て右方向の手を動かすと、鏡の中でも自分から見て右方向の手を動かしている。反転しているのは、鏡に垂直の方向である。自分が鏡の方を向いている時、鏡の中の自分は逆にこちらを向いている。左右が反転している気がするのは、「右手」「左手」のように、鏡の裏に回った自分の視点で手がかりを見ているからであると。 はい、そのようですね。けれど、このページの中にある、鏡の裏に回った自分を想像する時の回り込み方によって反転しているように見える方向が変わるというのは、ちょっとよく分からない。言っていることは分かるのだけれど、それが鏡問題とどう関係しているのかが分かりにくい。なぜなら私は鏡を見る時、べつに自分が鏡の裏に横からぐいっと回り込む様子など思い浮かべていないから。 鏡問題は、誰もが疑問に思うことであると同時に、誰もが感覚的には答えを知っているのである。 ただ、その答えをうまく言語化できないだけだ。 鏡問題は言葉遊びなのだ。だから鏡問題についてある程度考えた人はみな、「そもそも問題設定が間違っている」と言い出す。問題の認識がおかしいのだから、回答することよりも、認識を正すことの方が重要だと。 そのために、左右も上下も反転していないということを説明しようといろいろな例を出すのだけれど、それらがどうも生活感を伴っていない。 鏡問題の素朴さに対して、回答はどれも間接的でもやもやしている。こじつけ感がでてしまう。 左右は反転しているような気がするだけで実は反転していない? それは一体どういうことだろうか。 でもまあ、左右も上下も反転はしていなくて、鏡の外と中で、鏡を境に方向性が逆転しているだけなのだということで、しぶしぶ納得しかけるわけである。 ところで急に話が変わるようだが、iPhone の前面には FaceTime カメラというのがある。自撮り用にこちらを向いているカメラだ。 この FaceTime カメラを起動して自分を撮影しようとすると、あることに気づく。ディスプレイに表示されている自分は、鏡像になっているのである。 シャッターボタンを押して、撮影された写真を見ると、鏡像ではなく普通に自分を撮った写真になる。 これはおそらく、我々は普段自分の顔を鏡を通じて見ているのだから、ディスプレイに表示するプレビューは鏡像にした方が自然だと考えた仕様なのだろう。 だから FaceTime カメラは、シャッターを切らなければ、鏡としても使うことができる。 そこでふと考えた。FaceTime カメラがディスプレイに表示する鏡像は、どうやって作っているのだろうと。 それはおそらく、レンズが捉えている通常の映像を、デジタル処理で左右反転させているはずだ。 その時、上下は反転させていないはずだ。 つまり、映像を左右だけ反転させれば、それは鏡像になる。そして FaceTime カメラのディスプレイを見る限り、それは完璧に鏡をシミュレートできている。 だとするならば、鏡は、やっぱり、左右だけが反転していると言えるのではないか? 鏡問題というのは、「左右が反転しているような気がする」というトラップであるように見せかけて、本当のトラップは、「問題設定が間違っているような気がする」というところにあるのではないか。問題設定は間違っていないのではないか? 仮に鏡では本当に左右が反転していないとしても、左右を反転させた映像と鏡の区別が我々につかないなら、鏡は左右反転していると言ってしまって問題ないのではないだろうか? このように鏡問題は、我々の認知、言語、思考、などの間にある亀裂を発見する実験といえるだろう。 そして未だ、回答の決定版は出ていない。

きれいの条件

きれいについて、前からずっと、自分は他人にくらべて少し感受性が不足しているのではないかと心配している。 何かを見て人が「きれい」と感嘆の言葉を発する時、自分はあまり感動していないことが多い。 例えば誰かと道を歩いていると、同行者が「あ、きれい」と言う。見ると歩道の脇に小さなハルジオンが咲いている。私はそれを見て、確かに花が咲いているなとは思うが、その美に感動してはいない。思わず感嘆の声をもらすほど感情の変化は起きない。 景色の開けた山岳を行く時、高層ビルから夜景を見る時、人は「きれい」というが、私はむしろ、彼らの「きれい」がどこから来るのかということについて、気になりだした。 「きれい」にはいくつかの種類があるように思う。 真新しく汚れがないもの、均一なもの (買ったばかりの車、沖縄の海、若い女性の肌、洗った後の手、白いハンカチ、しわのないカーペット、モノトーンのコーディネーション) 整然としたもの (掃除した後の部屋、整頓された本棚、組体操の列、碁盤の目) 無駄がなく優雅なもの (ペン習字のお手本、枯山水、漆器、日本舞踊) 繊細なもの (花、アクセサリー、ネイルアート、パステルカラーのコーディネーション) 対称的、規則的、幾何学的、反復的なもの (寄木細工、刺繍、ステンドグラス、柄模様) 雄大で複合的な自然風景 (視野いっぱいに広がる山並み、ところ狭しと生える森の木々、水面に映る雲々、入り組んだ海岸線、花畑) 光るもの、コントラストが高い状態 (宝石、電飾、磨かれた金属やガラス、星、夕焼け) カラフルなもの、鮮やかなグラデーション (虹、玉虫、フルーツ盛り合わせ、原色のコーディネーション) 艶やかなもの、豪華なもの (ナイトドレス、シャンデリア、振袖、ベリーダンス) 当然これらの条件は排他的ではなく、境界はあいまいだ。また「心がきれい」のように比喩的に言うこともあるが、ここでは視覚的な特徴に限定している。 上記のような条件を複数満たしているものほど、人は「きれい」を感じるようだ。 例えば満天の星空は、繊細で反復的で雄大で光っている。 上記の条件をさらにまとめると、大きく次の三つになるのではないか。 A. 一定している B. 有機的である C. 高コントラストである 一定しているというのは、淀みがなく全体が限定的なパターンで成っていること。有機的であるとは、複合的で各部分が密接に結合して影響しあっていること。高コントラストであるというのは、視覚に対して強い刺激を与えていること。 不思議なのは、A と B が逆のベクトルを持っているように思われることだ。 例えば A にあたる「白いハンカチ」は、均質で要素が少なく「無」に向かっている。一方 B にあたる「雄大な山並み」は、ランダムで要素が多く「有」に向かっている。 そして C はといえば、なぜか A とも B とも相性がよい。白いハンカチは眩しい光を放っているし、雄大な山並みはその稜線によって天と地をはっきり分けている。 だから「きれい」の条件は、「A + C」か「B + C」でよく満たされると考えられる。 […]

コンプレックスとソフィスティケイテッドの語感

コンプレックスとソフィスティケイテッドの語感について。 コンプレックス(complex)という英単語はよく「複雑な」と訳される。 ソフィスティケイテッド(sophisticated)という英単語はよく「洗練された」と訳される。 日本語の語感としては、「複雑」と「洗練」は反対の意味を持っているように響く。 複雑なものとは、要素が多く混沌としていてまとまりが見いだせないようなもの。 洗練されたものとは、要素が無駄なく整理されていて単純さの中に深みを感じさせるようなもの。 ところが英語での complex と sophisticated の使われ方を見ていると、どうもこのふたつは同じようなニュアンスを持つ言葉であるようだ。 complex は、複合的で込み入ってはいるが全体として綿密に計画されたものを意味する。 sophisticated は、精巧緻密で高度に手の込んだ凝ったものを意味する。 例えば宇宙は、コンプレックスかつソフィスティケイテッドなのである。 一方、日本語の「洗練」から感じる、単純であることが高度であるという価値観は、日本的あるいは東洋的なものなのかもしれない。