OOUI
https://scrapbox.io/files/6799a984460287f425c84099.png
俺、この液晶の券売機見て絶望したことあるんだよね。
一部の変態を除くと、客は電車に乗りたいんじゃなくて目的地に行きたいんだし、切符が買いたいんじゃなくて目的地に行きたいんだよ。
指定席だ自由席だを先に選ぶんじゃなくて、目的地を選んでから在来線特急を選んでその後席を選ぶUIが望ましい。
この辺の議論はまさにOOUI
けど思うんが、OOUIのオブジェクトは唯物論的すぎる気がしている
IOアクションや関数もまたオブジェクト
OOUIのOは、ObjectというよりはObjective（目的語）
OOUIとオブジェクト志向
上野さんの本のATMの例があったように
OOUIの、フォルダや口座のような「モノ」とアクションやタスクのような「操作」が綺麗に二分できるという世界観に、関数型言語的に慣れている身として違和感があるんだけど（IOアクションも関数もオブジェクトなので）、ObjectじゃなくてObjective（目的語）-oriented と捉えるとしっくりくる
https://scrapbox.io/files/666baeeeeefc9e001d6a7713.png
オブジェクト指向UIデザイン
使いやすいソフトウェアの原理
ソシオメディア株式会社、上野 学、藤井 幸多（著） 上野 学（監修）
技術評論社
あるドメインの人（業務システム、SIer方面）にはすごくいい本だと思うんだけど、読んで色々思う所があった
「銀の弾丸」…。
オブジェクト指向、オブジェクトとメッセージングが区別され過ぎている
「メッセージングすること」という動作もまたオブジェクトである
ある種のIOアクション値
ATMの例が良く登場するが、依然として「出金」はタップ可能なアイコンとして存在していて欲しいんだけども。
normalize.fm で、どんだけツールの自由度が高くてもある側面では檻に閉じ込められているの意で、冗談で「自分らはノイマン型アーキテクチャの中で出来る発想に縛られている」と言ったことについて考えていた。 思えばノイマン型コンピュータ上にソフトウェアとして構築された制作ツールが前提とするメンタルモデルは、ノイマン型にすら至ってない。
何がノイマン型なのか、そもそもノイマン型という呼称が歴史的に適切かどうかについても議論はあるが、さしあたり「データとプログラムと区別せず記憶領域に収める設計思想」と単純化してみる。
しかし殆どのGUIベースの制作ツールは、慣例的にプロジェクトファイルとスクリプトとを別々に扱う。また操作の対象はグラフィックや音声クリップといった静的なデータに向けられており、「操作」自体を操作の対象とすることが出来ない。
つまり、「モノ」としてのデータと「操作」としてのプログラムとを厳格に区別するよう仕向けられている。
「操作」を操作する
プログラミング言語機能でいう第一級関数、関数オブジェクト、高階関数のこと。
関数にも、状態を持たないフィルターとしての関数と、副作用を伴い、外界に作用するアクションとしての関数が存在する。
フィルターの例: パスを角丸にする、画像にボックスブラーをかける、音のピッチを上げる
アクション例: .mp4 に書き出しする、選択範囲を削除する、画面にログを出す
操作の操作とは、たとえば「ある操作から、『その操作n回適用する』操作を作り出す」のようなもの。
TypeScript風に書けば (f: (x: T) => T, n: number) => ((x: T) => T)
f にボックスブラー、nに十分高い数を与えれば、ガウシンアブラーを作り出すことが出来る
実際、アニメ撮影なんかではグローの減衰を自然に見せるために、レイヤーをコピーして半径を変えたブラーを重ねがけするというノウハウがある
AfterEffectsにおいては、カーネルを指定可能なブラーエフェクトを使うよりも、こうするほうが処理が早いという仕様も関係していたりする
「操作を組み合わせて操作」機能があれば、こんな面倒くさいことしなくてもいいのにね
数学的な例: ハイパー演算、N回微分
関数型プログラミングを通して身につけられるメンタルモデルは、データとプログラムの両方を、メモリ空間上に何らかの形で表現されたオブジェクトとして区別なく扱う考え方。
一般に副作用を伴うアクションをオブジェクトとして捉えるのは直感に反するが、HaskellはIOアクションという形で「モノ化」して捉えている。
ただし、GPUプログラミングは基本的に非ノイマン型。シェーダとバッファは別々の記憶領域に収められ、GLSLの中でシェーダプログラムそのものをuniformとして渡すことは出来ない。
非ノイマン型のメンタルモデルはアプリ設計者の発想をも制限している
その代表例がOOUI（Object-Oriented User Interface） 言いたいことは理解できるし、ある種のエンドユーザー向けのツールを設計する上ではとても有用なものだけど、結局「オブジェクト」と「タスク」を二元論的に捉えすぎていない？
一方で、別に食べログやATMの入出金システムの設計には必要十分だとも思うし…
タスク志向型UIをtask(object1, object2)だとすると、OOUIは object.task(...args) の世界観。SVO文型。
けど考えてみれば、S(ubject)とO(bject)の区別は限りなく曖昧じゃない？
例: ミラー反転操作。反転操作 mirror、反転軸 axis、反転させる対象 target を考えた時、何をオブジェクトと見做すかに恣意性がある。
axis.mirror(target):
target.mirror(axis)
mirror.apply(target, axis): これも「反転操作」を「もの」と見做せばOOUI的と言える。エフェクトパネルから「何にしようかな♫」と選んでいる最中のユーザーの脳内では、操作であるはずのエフェクトを「オブジェクト」として捉えている
オブジェクトとタスクは反転し得る。物理的な音楽演奏において、楽器やエフェクターはオブジェクトであり、楽譜は「どう弾くか」というタスク。一方DTMにおいては、ピアノロール上のノートが操作可能なオブジェクトであり、それをその音源とどのフィルターを用いて音として鳴らすかがタスクとなる。
というかOOUIが問題にしているのは、実のところオブジェクト = 目的語 ではなく、サブジェクト = 主語 のような気がする。SOUIと呼ぶべき?
タスク志向型UI、OOUIを包括する考え方として、タスクとオブジェクト、アクションと値とを区別なく「もの（Thing, Entity）」として並置する世界観があるのではないか
LispのS式は構文論的に「操作そのもの」「操作するもの」「操作されるもの」「操作に必要な追加情報」の区別が薄い。 (task object1 object2) のように。たまたま最初に来る要素が「操作」と解釈され、残りの引数を補助情報として新しいオブジェクト（それはフィルターでもアクションでもデータでも構わない）を返す。
https://scrapbox.io/files/63240b861d5e13001dd34982.png
上の図すら日本語のフレキシブルさを言い得てない。Verbが中心的な役割を果たしているかのように描かれているから。「この軸であの図形を反転する」という文にしたって、「この軸」や「反転」全てが名詞的に並置されている中で、位置や順序によってではなく、「で/を/する」といった助詞がそのオブジェクトの文における役割を決める。 PythonやSmalltalkのキーワード付き引数に近い。が、関数名そのものもキーワードによって修飾されている。
「この軸で、あの図形を、反転する。」
「あの図形を、この軸で、反転する。」
「反転する。あの図形を、この線で。」
OOUI自体は古くからある考え方ですよね
Smalltalk的な意味でのObject-orientedと、OOUIが意味するところのObject-orientedは違う
具体的にどこが?
どう実装するの?
task、object1、object2、何を先に選んでもいい。それが情報として過不足ない時には即座に実行され、情報に欠けがある時には (___ object1 ___) 、(task ___ ___)のように残りの情報をユーザーに穴埋めしてもらう。
そのためには、タスクもオブジェクトも区別なく画面上で扱える必要がある。
プロジェクト上で、イメージや音声、テキストと同様に「操作」そのものを操作可能な対象として扱うことができれば、ユーザーは操作を組み合わせて操作を作り出すことが出来る
パラメーターの種類に、数値、色、レイヤー参照の他に、エフェクトを追加する。ユーザーはエフェクトからエフェクトを作り出せる。
After Effectsにおいてそれを部分的に実現しようとしたのが ISF4AE。