モードレスデザイン

多分、前著以上にあまり考えが合わない

アイコンや、自著の宣伝に伴うハイプ感が、多分あまり自分のセンスとかち合わないっていう中身とは関係のない部分で...

OOUIを「銀の弾丸」と言い切れるところとか

けど、そういう部分も含め自分の視え方は「デザイン」出来ていないんだ、とは思う

視え方のいなたさ、というか

Bibiographyに出典元のページ番号が無い

テキストそのものの抜粋なので入れるべきでは？　とくに訳文に関しては

誰の訳文かってのが肝心なので

関数型的な世界観で言えば、タスク = 現実世界の状態に副作用をもたらすアクション もまたオブジェクトである (IO Monad)

Smalltalkは、確かにオブジェクト指向的だが、Haskellのような厳格さでタスクの実行に伴う副作用を分離したり、関数をオブジェクトとして扱うのは、(サポートはされているものの) あまり前提とされていない

OOP is not OO

「OOPは長らく「クラス継承」だのと、Smalltalk的なOO観から誤読されてきた。だから本来のOO性を換骨奪胎する必要がある」っていう話は、Smalltalk界隈のトレンド。

OOP自体はその名の通りプログラマーにとっての体験であって、ユーザーにとってのオブジェクト指向ではない

メモ

ジョン前田のデザインの定義違うだろブログ

気になる

存在論的デザイン

モードへの反抗

ボタンとその効果が非自明なのに対して、ステアリングと車の回転が自明なのはどういう線引き？

車の回転とステアリングの回転は果たして同型と言い切れるのか

結局自明さ、自然さ、直感性なんてのはなくて、そこにあるのは学習による慣れ

気になる

OOUIではタスクとオブジェクトの二項構造を前提としていたが、「〜すること」というタスクが為す動作そのものはオブジェクトたりえないのか？

「『Aに100円送金する』を隔週で行う」のような表現をOOUIのパラダイムで扱うには、「(口座)に(N)円を(時間)間隔でおこなう」という、それ専用のタスクを用意する必要がある、直交性に欠ける

That being said...

けど上野さんのOOUI周りのprinciples自体はすごくまとまってるし、彼がコンサルするようなSIer, 業務システム系に関して言えば、UIの実装として参考になるんですよね…

What he has written regarding OOUI itself is quite helpful for me to implement UIs, at least for relatively simpler interfaces like ones in ATMs -- and also could be good principles/guidelines for his own clients.

of course I'm sure it does not meet the requrements expected of a high-level creative professionas, as I've argued in the HCI community

なんなら深津さんも実はUI設計に関しての話は普通に共感してる