Author Archives: Manabu

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.

Apple deleted the “Design Principles” from its Human Interface Guidelines for Mac

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

Apple をインスパイアした(かもしれない)Textwell/DraftPad の機能

シェアメニュー 他のアプリにコンテンツをルーティングするための一元的なメニュー。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 が先にしていた。 JavaScript でマクロ OS X では AppleScript に加えて JavaScript でオートメーションスクリプトが作れるようになった。Textwell ではもっと前から JavaScript で自由にマクロを書けた。 デバイス間でコンテンツを半自動コピー OS […]