2ページ/17ページ

現代的なデザイン

あなたの世界はあなたの見るものでできている。

わたしの世界はわたしの聞くことでできている。

あなたが見ることができるのはあなたの見えるものだけで、わたしが聞くことができるのはわたしの知っている言葉だけだ。

わたしの知らない言葉はわたしにとってはただの音の連続で、あなたはあなたの見えないものがあることにすら気付いていないのかもしれない。

現代的なデザインというのは、つまりあなたの見えないものをあなたに気付かせ、あなたに聞こえない言葉をあなたの言葉に翻訳する。そういうことじゃなかろうか。

 

three.js で遊んでみる – 追いかける

※マウス操作でカメラをコントロールできます。

three.js で遊んでみる – ひろがる

モバイルファーストから AI ファーストへ

Googleが、モバイルファーストから AI ファーストへの移行を発表したのだけれど、AI ファーストといったとことろで、実際何をしていいのやらよく分からない。そこで、現場ではこれから何が求められそうなのかとか、そういうことを考えてみた。

さて、AI ってのは賢いんだから、とくに何もしなくても、今の Web を立派な情報資源に変えてくれるに相違ない、なんてことも思ったりはするけれど、実際今のところ AI は思っているほど賢くはないし、日々追加・更新される膨大な Web の文書を逐次処理していては、それだけで甚大なリソースの消費になる。

そこで Web を AI ファーストな立派な情報資源に変えるための道程は、いわゆるセマンティック Web を進めていくのと同じ道程だと思う。Web を意味的にしていけば、機械的な処理が可能になるため、情報の確実性も高まり、意味がつながれば、そこから推論も可能になる。

ポイントは

  • 共通スキーマに基づいた表現の充実
  • Web アプリケーションを AI が操作するためのプロトコル(の策定ができたら)実装

だろうか。

共通スキーマに基づいた表現の充実

「RDF やら Microdata やらなにやら聞きいたことはあるようなナイような気がするけれど、なんなのかよく知らないし、そもそもなんの役に立つのかわからないな。どうせ君達の自己満足でしょ?」的なことを言っていた彼らをついに黙らせる時がきたようだ。

それはさておき、AI との共通言語は schema.org などのパブリックなセマンティクスを利用することになるはず。そうして RDFa や Microdata で表現されたセマティックな HTML ならば、AI は不確実な自然言語解析に頼ることなく、明確な定義にもとづいて Web ページから商品の価格や組織の情報、イベントの開催日時などを取得し、ユーザに提示することができる。セマンティック Web のキラーアプリケーションは、人工知能だった。

Web アプリケーションを AI が操作するためのプロトコル(の策定ができたら)実装

「ヘイ!シリ、明日の航空券の予約を頼む」

「かしこまりました... 航空券の予約が完了しました」

もう画面を操作する必要なんてない。キーボードを使ってカチカチ Web 予約をしていたぼくらは新しい世代に蔑まれる。インテリジェントなエージェントがセマンティックな Web アプリケーションで人間の素朴な作業を代替してくれるからだ。これできっと楽天の HTML も随分美しくなるに相違ない。

デザインの成立

「デザインって何ですか?」と聞くひとがいる。

この質問は抽象的すぎて質問の意図がよくわからないのだけれど、質問をしたひとがデザイナでなく、デザインに関する仕事に関わっているのだとしたら、おそらく質問の意図としては「デザインが成立しているというのはどういうことですか?」ということを聞こうとしているのだと思う。デザインはしないけれどデザインの評価をしないといけなかったり、それを売る必要がある場合に、果たして何を評価の基準としたらよいのか、もしくは製品としてそれは成立しているものなのかを判断しなければいけない場合、この質問は非常に真摯なものになる。それに対して「デザインって正解がないからさぁー」的な思考停止な回答は、誠意のないものになってしまう。

もちろんこの質問の回答に困るは、デザインという言葉、というか対象の多様さにある。

一般的にデザインといって思い浮かぶのは、ファッションだったり、家具などのフォルムに関するものが多い。「このデザインいいよね」という場合、それは洋服の模様だったり、流線型のフォルムだったりする。

最近はコンピュータが普及し、マンマシンインターフェースと日常的に触れ合うひとたちが増えたことで、デザインは形状の美しさだけでなく、使いやすさやレスポンスの速さなども含まれるようになってきた。

建築物のデザインも第三者にはその外観の美しさや新規性を評価されることも多いのだけれど、維持コストや耐震性、耐久性、快適性なども、実際に利用し、費用を支払う側からすれば重要なデザインだと認識されはじめている。

デザインには他にランドスケープデザイン、プロダクトデザイン、グラフィックデザイン、制度設計、あるいは在り方をどうするのか、というさら抽象度の高いアーキテクチャ(法則)のデザインも含まれる。

これらに対する一般解の導出が困難なためか、あるいは単に応えを持ち合わせいないのかは知らないのだけれど、この質問をしてまともな回答が返ってきたためしがないので、デザイナでないぼくがこの質問の一般解を考えてみた。

回答は一言で済む。それは「ゲシュタルト(形態。全体性を持ったまとまりのある構造。)ができていること」。

単なる部分の集合ではなく全体がひとつの意味をもち、部分同士は互いの関係が明確になっている。これなら対象がグラフィックスであれ、建築であれ、インターフェースであれ、満足のいく応えに成り得るんじゃないだろうか。

カッティング・エッジ

究極のダンスは踊らないことなのだという。舞台に立ったダンサーに観客は息を飲み、期待し、そうして全てが終わった後に、ようやく全てが始まっていたことをしる。

研ぎ澄まされたものからは余計なものが消えていく。全てを知ったマスターは、何が必要なのかを知っている、だから、その必要なもの以外を全て削ぎ落とし、残った僅かなものだけで全てを完成させてしまう。

だとしたら究極の絵画は一本の黒い線だ。線には無限の選択肢がある。キャンバスの大きさ、素材、位置、長さ、太さ、角度、濃さ。それぞれたった 10 の選択肢しかなくても、組み合わせは 10 の 7 乗になる。もちろん実際はもっと多くの選択肢があるのだから、その途方もない可能性の中から唯ひとつの選択、何の不足もない完全な線としてひかれたそれは、きっと見るだけで人生を変えてしまうに相違ない。

では究極の歌はどんなものだろう。恐怖は正に叫び声、歓喜は笑い声、哀しみは泣き声だろうか。歌が仮に感情のみを表現するものだとしても、それではきっと貧弱過ぎる。基本欲求と原始的な感情を表現することが究極の歌だというのなら、ディーバも乳飲み子で事足りる。

究極のインターフェースはインターフェースのなくなる事で、モーダルよりもモードレス、マウスよりもダイレクトなタッチパネルらしい。拡張現実も現実と区別がつかなくなれば、それはもう立派な現実だし、ビットとアトムも概念で生きる人間にとってはほんとうは何の区別もない。けれどもそんな恐ろしいことはない。

リアルとバーチャルに境がないのなら、生も死も意味がなくなり、命を持たない人間が、肉体の中で生きる人間と同じように活動し、作用し始める。けれど彼らには肉体がないのだから、生き物ではないし、死人でもない。だからそんな恐ろしいことにならないためにも、究極のインターフェースとは、やはりそれはそれで境界としてあり続けなければいけないのじゃないだろうか。

Matter.js に入門してみる – 実験

今まで学習したクラスを使って実際に動かしてみる。Body クラスの applyForce を使って、円を飛ばして矩形にぶつけてみる。

Matter.js に入門してみる – Matter.Body クラス

Matter.Body は剛体を操作するためのクラス。

正確な情報は公式ドキュメント Matter.Body を参照してください。

例:ボタンを押すとタイムスケールが変化します。

メソッドは以下。

applyForce フォースを適用
applyGravityAll 重力を適用
create 剛体を生成
nextGroupId ユニークなグループIDを取得
resetForcesAll フォースをリセット
rotate 回転
setStatic 剛体を動かなくする
scale 拡大縮小
translate ベクトルを適用
update 状態を更新
updateAll 全てのBodyを更新

プロパティは以下。

angle 角度(ラジアン)
angularSpeed 角速度
angularVelocity 角速度
area 面積
axes 衝突検出のために使用される一意の軸ベクトル
bounds 境界
density 密度
force フォース(ベクトル)
friction 摩擦
frictionAir 空気抵抗
groupId 自身が属しているグループのID
id 自身のID
inertia 慣性
inverseInertia 慣性逆モーメント
inverseMass 逆質量
isSleeping スリープ中か
isStatic 静的か
label 剛体のラベル
mass 質量
motion 運動量
position 位置 { x: 0, y: 0 }
render
  • fillStyle

    塗り
  • lineWidth

    線の太さ
  • sprite

    texture
    スプライトのテクスチャ
    xScale
    スプライトの横軸のスケール
    yScale
    スプライトの縦軸のスケール
  • strokeStyle

    輪郭のスタイル
  • visible

    見えるか
restitution 弾力性
sleepThreshold スリープのしきい値
slop -
speed 速度(スカラー)
timeScale タイムスケール
torque 回転力
type オブジェクトの型
velocity 速度(ベクトル)
vertices 剛体の頂点