Author Archives: Manabu

銀の弾丸に関するノート

銀の弾丸の意味について簡単に書いておく。 『銀の弾などない』について まず、フレデリック・ブルックスの有名な論文「銀の弾などない ― ソフトウェアエンジニアリングの本質と偶有的事項」(1986)の内容は、次のようなものである。 ソフトウェアの構築には、本質的作業と偶有的(副次的)作業がある。前者は「何を作るか」についてのテーマであり、後者は「どう作るか」についてのテーマである。 「どう作るか」については様々な技法が生まれており、高水準言語、タイムシェアリング、オブジェクト指向プログラミング、人工知能、ワークステーションなど重要な技術革新はあったが、決定的なものとは言えない。 またそもそも「何を作るか」のテーマにおいて、ソフトウェアには困難が本質的に内包されているのである。 ソフトウェアの「何を作るか」には4つの性質がある。 複雑性: ソフトウェアは、同じコードは1度しか書かないという作り方をするので、他のどの人工構造物よりも複雑性が高い。 同調整: ソフトウェアは、現実世界の複雑な要求に合わせて作られるので、ソフトウェアだけで単純にすることはできない。 可変性: ソフトウェアは変更しやすいと考えられているので、追加や修正が強制され続ける。 不可視性: ソフトウェアは目に見えないため、デザインプロセスや関係者間のコミュニケーションを妨げる。 これらの困難はつまり、ソフトウェアに生得的なものであって、これらを一気に解決するような、飛躍的な改善方法というものは無い、というのである。 ― それはそうだろう、と思う。 ブルックスは基本的に、ソフトウェア技術者として、ソフトウェア技術によってソフトウェアの問題を解決しようとしている。だから解決できない。ソフトウェアが本有する問題は、ソフトウェアによっては解決しないから。 “技術の本質は技術的なものではない。- マルティン・ハイデガー” “私たちが抱える重大な問題は、それを生み出したのと同じレベルの思考では解決できない。- アルベルト・アインシュタイン” ハイデガーやアインシュタインが言うように、問題の本質は問題の中にはないのである。問題を解くには、問題の外に出なければいけない。 問題の中で考えていても問題は解決しない。解決するには問題の外に出なければならない。 pic.twitter.com/a8dGduAdwZ — Manabu Ueno (@manabuueno) December 17, 2019 では、ソフトウェア開発の問題の外に出るとはどういうことか。 実はブルックス自身が、この件について『銀の弾などない』の中で考察している。彼は、本質的困難に対する有望な攻略として、次のアイデアを示している。 作るのではなく購入する: ソフトウェアを作るのが難しいなら、既製品を買って使えばよい。 ラピッドプロトタイピング: 要件を繰り返し抽出し、洗練させ、「何を作るか」を確かにする。 構築ではなく育成する: ソフトウェアを、一度作って終わりではなく、継続的に育ててくものと考える。 偉大なデザイナーを育てる: 偉大なデザインは偉大なデザイナーから生まれる。企業はコストをかけてデザイナーを育てるべき。 ブルックスがこれを書いたのは80年代だが、奇しくも現在、この4つの方針のうち最初の3つは、多くの開発組織において実践されており、ソフトウェア開発の問題に対するソフトウェアの外からのアプローチとして一般化している。その意味でブルックスは非常に優れた予言者だった。ただし4つ目のデザイナー(この場合は広義のソフトウェアデザイナー)育成の重要性については、まだ広く認識されているとは言えないが。 そのような意味で、ブルックスはかなり本質的な施策を持っていたことになる。しかしそれでもこれらは銀の弾には至らなかった。なぜなら、これらは依然としてソフトウェア開発の困難に関する解法であり、ソフトウェアが本有する問題自体はどこにも行かないからだ。 『オブジェクト指向UIデザイン』について 『オブジェクト指向UIデザイン ― 使いやすいソフトウェアの原理』では、OOUI のコンセプトを通じて、その身体的な意味と、精神的な意味で、ふたつの「転回」について書いている。 身体的な意味としての OOUI とは、知覚される表象として、タスクではなくオブジェクトをベースにUIを構成するということ。 […]

モードについてのノート

モードとは何か。ある事象について、そこにモードがあるという人と、そこにモードはないという人がいる。だからモードは少なくとも「解釈」に関係している。物事の解釈の仕方がモードそのものであると言ってもいい。それはどういうことか。 例えば、四季はモードだという人がいる。昆虫の変態はモードだという人がいる。一方で、自然界にモードはないと私は言う。これは単純に言えば、自然をモーダルに見ているか、モードレスに見ているかという、世界の捉え方の違いによるものだろう。 辞書を見てみる。mode は、何かが起きたり、経験されたり、表現されたり、行われたりする上での方法、もしくはマナーである。 「モードとは?」と問われたら、「いつもとマナーが違っている状況のこと」と答えるのが一番簡単だろう。 ソフトウェアデザインにおいてモードが指摘されるのには、大きくふたつの状況がある。ひとつはモーダルダイアログのような「一時的に操作が制限された」状態。通常は許されている操作が、ある条件下では許されないというもの。これを仮に「制限型モード」と呼ぶ。 制限型モードの多くでは、UI全体へのランダムアクセスが制限される。またモードから出るために決まった手続きが必要になる。例えばダイアログの OK/Cancel ボタンを押すなど。これらは対象への直接操作性をスポイルし、UIの情報理論的な効率を下げる。 もうひとつは、単に「ジェスチャの解釈が違う」状態。例えばひとつのボタンが、ある時は「ON」で、ある時は「OFF」の働きをするなど。リターンキーは、改行文字の挿入、直前のコマンドラインの実行、デフォルトボタンの代替、など状況に応じて働きが変わる。これを仮に「転換型モード」と呼ぶ。 転換型モードはUIのいたるところにある。コンピューターというものがそもそも多態性をウリにしているので、転換型モードがなければ汎用性を保てない。だからといってこのモードが常に問題を引き起こしているわけではない。転換型モードが問題になるのは、意図しないかたちでモードが転換した時だ。 転換型モードについてジェフ・ラスキンは『ヒューメイン・インタフェース』の中で詳しく考察した。まずこれを考える上では「ジェスチャ」と「注意の所在」がキーワードになる。ジェスチャとは、一旦開始すると自動的に完了する一連の動作のことだという。 例えば、the というような良く使う単語を入力する場合、初心者のタイピストにとっては各文字のタイピングが個別のジェスチャになる。一方熟練者のタイピストにとっては、単語全体で一つのジェスチャになる。つまり同じ操作をしても、ジェスチャの単位はユーザーによって異なるのである。 次に、注意の所在とは、あなたが意図的かつ活発に考えている対象、つまり現在意識を向けているもの。人は一度にひとつのものにしか意識を向けられない。UIを操作している時、画面上には様々なものがありそれぞれが固有の状態を持っているが、ユーザーの注意の所在は、常にたったひとつのものにある。 リターンキーの例のように、UIではジェスチャに対して複数の解釈が用意されている。これはある人にとっては期待どおりの自然な振る舞いだが、ある人にとっては予想外の反応となる。UIがジェスチャに対してどのように反応しているかは、モードによって決定される。 しかしこれには解釈の余地がある。例えば a という文字をタイプした後でバックスペースを押すとその a が削除される。b という文字の後でバックスペースを押すとその b が削除される。起きたことだけを見ると、バックスペースは、時には a 削除し、時には b を削除するので、モードがあることになる。 しかしテキスト編集中にバックスペースにモード性を感じることはほとんどない。それは、バックスペースの働きについて「直前の文字を消す」という解釈をしているからだ。なぜそのような解釈ができるのかというと、バックスペースを押す時には現在のカーソル位置が注意の所在になっているからである。 操作対象の状態が注意の所在となっていれば操作の意味を解釈でき、その振る舞いを予測できる。注意の所在となっていない、あるいはなっていても状態が曖昧な場合、転換型モードは問題となる。例えばテキスト編集中にカーソルを見失った状態でバックスペースを押せば、予想外の結果になるだろう。 あるジェスチャの解釈が一定である間、そのUIは同じモードにある。ジェスチャの解釈が異なる時、そのUIは別のモードにある。同じ操作が人によって問題であったりなかったりするのは、ジェスチャの単位や注意の所在が、人と状況によって異なるからだ。 その意味で、あるジェスチャに対してシステムが問題的にモードを持つのは、UIの現在の状態がユーザーの注意の所在となっておらず、そのジェスチャに対して複数の異なった応答がUIによって実行される場合、なのである。 “インターフェースデザインにモードを導入する場合、そのモードによって制御される状態がユーザーの注意の所在となっており、同時にそれがユーザーから可視となっているかユーザーの短期記憶に存在することを保証することによってのみ、ユーザーをモードに起因する間違いから解放できる。” Jef Raskin さてここまで制限型モードと転換型モードについて見てきたが、ではなぜこのふたつが同じ「モード」として認識されるのだろうか。ラスキンは、UIの操作として意味を持つ最小の単位「ジェスチャ」のレベルからモードの問題を指摘した。ジェスチャは組み合わさって別のジェスチャになる。 例えばクリックをふたつ組み合わせるとダブルクリックになる。ドラッグとドロップを組み合わせて移動のジェスチャになり、さらにモディファイアキーを組み合わせて複製のジェスチャになったりする。それらがさらに組み合わさって、次第にUIの操作イディオム(慣用句)ができあがる。 制限型モードは、言ってみれば、イディオムレベルでの転換型モードなのである。モードは解釈の仕方なので、ある状況に属した解釈の仕方がある、というだけですでに操作の一貫性は損なわれる。モーダルダイアログが不自由に感じるのは、それまでと地続きでない別の場所に行ってしまうからだ。 モーダルダイアログの中で一生を過ごすのであれば問題にならない。しかしモーダルダイアログと普通のウインドウを行き来しなければならないとすると、そこにイディオムレベルの転換型モードが顕在化する。モーダルダイアログの問題は、モードに入ることではなく、モードが変わることにあるのだ。 例えば「書類を保存しますか?」というモーダルダイアログで「保存する」を押すことが習慣になっているユーザーにとっては、一連の振る舞いがイディオムとなっているので、モードの問題は起きない。逆にこの習慣は「保存する」の選択を自動化してしまうので、ダイアログの意味がなくなるのである。 モードとは解釈の仕方だが、その解釈とは、システム側ではなくユーザー側の解釈である。そしてモードの問題は、モードに入ることではなくモードが変わることにある。モードが無いことをモードレスというが、それは悪い解釈が無いというより、解釈が変わらないということなのである。 モーダルとはモードが変わることである。モードレスとはモードがひとつだけあることである。ソフトウェアは、ユーザーの入力を正規化してプロトコルに照らす。そこには常にプログラマーの計画がある。この計画=解釈の仕方がなければコンピューターはただの箱だ。モダリティは計画を反映している。 モードは、物事のオブジェクティブな無為の在り方ではなく、サブジェクティブな作為の在り方だ。決められた解釈を強要し、あなたを駆り立てるもの。そのような徴用性が、モダリティなのである。 モダリティは、モードが変わることで現れる。モードがひとつであれば、モードは無いということ。a のキーを押して a が入力されるのはプログラマーの計画によるモードだが、もしそれが常に a の入力であれば、モードは顕在化せず、問題にならない。 例えばテキストボックスも、ウインドウも、アプリケーションも、コンピューター自体もモードだ。だから初心者は解釈しきれず混乱する。しかし慣れると、良くデザインされた部分については一定の解釈が可能になる。ダメな部分は、ダメなままなのである。 ソフトウェアのモードが混乱を呼びやすいのは、その計画がいくらでも恣意的にできてしまうからだ。ユーザーにはコントロール権がない。あるとすれば、プログラマーがそれを与えた時だけだ。しかしそれには高い技術がいる。UIをモードレスにする技術である。 モードレスネスには、一貫性、直接操作性、可視性、即時フィードバック性などが関係している。Macintosh は初期からOSレベルでアプリケーションの見た目と振る舞いを統一させた。Mac のモードレスネスが今も高いのはサードパーティにその思想が根付いているからなのである。 自然界に話を戻す。季節はモードと言えるだろうか。例えば夏の空気は暖かくて冬の空気は冷たい。これはバックスペースの話に似ている。もし現在の時期や場所が注意の所在にあるなら、それは同じ空気として一定に解釈されるだろう。何もわからず外気に突然さらされるなら、モーダルになるだろう。 […]

Please Enter Your Phone Number

Google 画像検索で “Please Enter Your Phone Number” を検索すると、電話番号入力のジョークUIがいろいろ出てきて面白いので集めてみた。(いずれもあちこちでコピーされておりオリジナルのありかは不明瞭…) UIデザイナーは普段、どうすれば効率的かつ分かりやすいものになるかを考えているけど、逆に、GUI としてのプロトコルを保ちながらどれだけ非効率で分かりにくいものにできるかを考えるのは有益な気がする。ばかばかしいものを作るには、入力操作における合理性が通常どこで担保されるのかを認識している必要があるから。 なお、おもしろいボリュームコントロールも同じようにいろいろ作られていて、ここでまとめられている。

荷風を訪ねたキーン

“永井荷風とは一度だけ会ったが、それも一時間足らずだった。それに、その時、私はひどい二日酔いで、何か意味の通ったことを言うことはほとんど不可能だった。私は彼がどんなに気むずかしい人か前もって知らされていた。”

A history of Apple HIG table of contents – the philosophy and principles

Here I introduce some TOC of the past versions of Apple Human Interface Guidelines, especially looking into the philosophy and principle chapters. The document structure of HIG has been significantly and surprisingly changed through versions. It means that Apple keeps seeking the best way of organizing design documentation. The list of design principles has been […]

2018年のオブジェクトベースUI

2018年の10月に発売された『WEB+DB PRESS Vol.107』に私が書いた記事「速攻改善 UIデザイン 銀の弾丸! オブジェクトベース設計」がひとつのきっかけとなって、UIデザインに関わる人達の間で「オブジェクトベースUI / OOUI」が話題になったように思います。いくつものデザイン組織でオブジェクトベースUIについての勉強会が開かれていると、直接的および間接的に聞いていますし、またいくつもの関連ブログ記事が書かれました。 個人的にオブジェクトベースUIについてはもう10年ぐらいあちこちに書き続けており、このテーマ自体は1970年代からあるものでもあるので、これまでこのテーマにあまり注目していなかったデザイナーや、最近UIデザインに興味を持った方などに、オブジェクトベースUIの考え方について知っていただけたのなら、とても嬉しく思います。 前述の WEB+DB PRESS の記事以外にも、2月に香港で行われた World IA Day 2018 Hong Kong にて同テーマの講演をしたこともあり、私にとって今年はオブジェクトベースUIづくしの年となりました。 以下は、今年書かれたオブジェクトベースUI関連の記事に言及した私のツイートです。 先日の World IA Day 2018 Hong Kong の講演スライドをアップしました。モードレスデザイン入門編ということで、前帯状皮質と扁桃体、構文論的展開と思弁的実在論、情報階級闘争とイオマンテなどについてはもちろん触れませんでしたが、エッセンスを60分がっつり話しました。 https://t.co/RMD3BkTKvd — Manabu Ueno (@manabuueno) February 27, 2018 デザイン面・オブジェクトをまず選択させる事で、モードレスで自然なUIになる・オブジェクトで整理する事によって無駄のないUIを考えやすくなる技術面・UIとデータの処理が直接的になり、コードが複雑化しにくい・UIの複雑性を排除する事でデザイナーと協働しやすくなるhttps://t.co/Tm8il5dmqq — Manabu Ueno (@manabuueno) December 30, 2018 2018年ベスト記事賞を付与。https://t.co/5Lf0Y3Fw2T — Manabu Ueno (@manabuueno) March 22, 2018 10月24日発売の技術評論社 WEB+DB […]

History of Radio button and Checkbox

モードレスはどこから来たか – オブジェクト指向UIの起源 –

いや、「モードレスはどこから来たか」ではなく、本来の疑問は「モードはどこから来たか」なのだ。なぜなら自然界にモードはないから。 モードは何もないところに生まれる形だ。混沌に生じた秩序だ。例えばファッションがそう。一般的にモードという言葉は、新しい流行や様式を指す。そして文化的な多様性と進化を促す力として肯定的に受け取られている。つまりモードはデザイン性の証なのだ。 しかしユーザーインターフェースデザインの分野、特にコンピュータソフトウェアの操作性に関するテーマにおいては、モードはほとんどすべてのシステムが宿している原罪として、解決すべき問題として扱われる。 なぜ原罪なのかと言えば、コンピュータというものの発想自体の中に、用途によって役割を変える道具 = 無数のモードを持つ多目的な存在としての性質が込められているからだ。そしてコンピュータは、その宿命であるモードによって、生得的に使いにくいというジレンマを抱えているのである。 コンピュータはその原罪としてモードを宿しているため、それを自然に返すために ー 私たちがもっと自然に使えるようにするために、モードレスネスへの挑戦が必要なのだ。 Design Principle ユーザーインターフェースデザインにおいては、モードレスネス(モードが無いこと)が重要だと言われる。多くの研究者が、ユーザーインターフェースにはできるだけモードが無い方が良いと言い、またデザイン原則としてモードレスネスを提唱している。 例えば2011年の “Mac OS X Human Interface Guidelines” には次のような記述がある。 Embrace Modelessness Users appreciate apps that allow them to be in control and they generally dislike apps that wrest control away from them too often. One of the most common ways that apps take control […]

viewport-fit=cover is confusing for app developers

(Updated on Dec 8, 2017) First, you know the Safari on iPhone X automatically applies paddings. The contents will be restricted inside the safe area by default. Fig1. Safari with default paddings – portrait Fig.2. Safari with default paddings – landscape From web developer’s perspective, as Apple/ WebKit team mentions, you can exclude the auto-applied […]

iPhone X – Screen Real Estate Comparison

Now a question is raised. If you cannot place elements around the notch and under the bottom swiping space, is iPhone X’s screen real estate where developers actually place elements really that large (+20%) in comparison with iPhone 6/7/8’s? OK, I have tested with the simulators.