ヒキダスブログ

テック系や最近見たもの感じたことを書いて残す引き出しスペースです

レアンドロ・エルリッヒ展で見つけた、サプライズとUX

六本木ヒルズ森美術館で、「レアンドロ・エルリッヒ展 : 見ることのリアル」が開催中だったので行ってみました。
行こうと思ったきっかけには、サイトに載っていた壁にしがみつく様のインパクトに強く惹かれたことと、以前どこかのデザイン系雑誌で見た覚えがあり、いつか実物を見てみたいと思っていたのもあったためです。

www.mori.art.museum

レアンドロ・エルリッヒ 氏はアルゼンチン出身のアーティストで、日本では金沢21世紀美術館に展示されている「スイミング・プール」でも有名になっています。
今回は新作を含む44点うち8割が日本未公開ということで、これは行く前から期待大でした。

例えばこの作品だと、

f:id:pujoru35:20171210014002j:plain
反射する港

ゆらゆら揺れており、一見会場内に水を張って船を浮かべているかと思いきや、実は水面に映った形の船を作りコンピュータ制御で揺らしているという仕掛け。暗闇とおぼろげなライティングもあってあたかも水面に浮かんでいるように見えてしまいます。

他にも、

f:id:pujoru35:20171210014524j:plain

正面から見ると雲に見えますが、実はスライス板に着色しそれをいくつも重ね合わせて雲のように見せています。Webのフロントエンド領域でも、雲状のものを層状に重ねてみせる実装が取り上げられたことがあり、あたかもそうあるように見せるやり方には共通するものを窺えました。

そこで、一連の展示から学んだ点を備忘録及び後学として自分なりに整理・解釈しました。


騙し絵・トリックアートといった視覚表現の空間拡張版

エルリッヒ氏の作品には、どれも驚き要素が内在しているように見受けられました。それは、騙し絵だったりトリックアートの類に近いものを感じます。平面と思いきや飛び出しているように見えたり、物理的にありえないような形状をしていたりと、それらと同じく思い込みや固定観念をひっくり返すアプローチをとっています。
ただ、これまでの騙し絵・トリックアートと違って、3次元の物体だったり空間を対象にしているのが特徴的と考えます。平面に比べて3次元を扱うのは見られる視点も多岐にわたり、そこもカバーできる世界観と精密さが必要と言えそうです(展示によって一方向から見てもらうものもありますが、本展示では小型模型も設置されているところから、エルリッヒ氏の作るものの外形・アングルまで考慮しているものと推察しています)。

f:id:pujoru35:20171210024241j:plain
階段

窓からのぞくというなにげなさへの仕掛け

作品のいくつかは、「窓」の形態と「覗く」行為をパターンにしているように見受けられました。電車の窓だったり、飛行機の窓だったり、部屋の窓だったりを、来場者に覗いてもらうというフローです。

f:id:pujoru35:20171210021107j:plain
部屋

この作品だと、ブラインド越しに他の部屋の模様を垣間見ることができたりします。パッと見展示スペースもそこまで広くないのに、覗いた先にリアリティある光景があると奥行きある空間に見えてしまいます。
他にも、電車の車窓が壁に埋め込まれているが、そこにはいろんな国の電車から見える光景が逐次切り替わって表示されたりと、ありえない要素もなかには含まれており、飽きさせない仕組みになっています。

サプライズ性が参加体験型展示にマッチしている

先述とも重複しますが、エルリッヒ氏の作品にはどこかにサプライズを仕込んでいます。鏡と思ったら実は鏡でないところもあったり、観る人の先入観を予測し逆手にとったアプローチが秀逸に思われます。
話は変わりますが、前に電通CDCの高崎卓馬さんの著書 「表現の技術」を読んだことがあります。その本には、人が笑ったり泣いたりするにはその前に驚く要素が必要と書かれていました。驚くことで感情の振り子を動かし、笑い泣くといった共感を作り出すというものです。
高崎さんは仕事上CMを軸に説明されていましたが、エルリッヒ氏の作品もそれに通じるものがあるように感じます。
僕の場合ですと、アーティストの展示作品を見て「あぁすごいな」と思いそこでまた次の作品に移ってしまいますが、エルリッヒ氏の作品を見ると「えっ何これ?」と驚きそれがどういう意図や仕掛けでそうなっているのかを見るとついつい笑みがこぼれてしまいました。
「建物」という作品にしても、実物を見て自分で実際に壁にへばりついてポーズを決めたりしては楽しんでいる大人や子供もいて、「驚き」と「参加型展示」は必要な組み合わせで、これはUser Experience(UX)にも通じるインタラクション要素なのだと思われました。

作品に込められたテーマが明快

これも自己体験ではありますが、エルリッヒ氏の作品には解説を見なくてもおぼろげながらどういうことを主題にしたのかを感じられる作品が多かったりします。

f:id:pujoru35:20171210023922j:plain
根こそぎ引っ張られて

例えばこの作品なら、家が宙吊りになり土台部分に根が張っているというものです。これは、家に根が張っている->人がその場所で暮らした時間が家にも生き物のように根ざした形で反映されている、と作品解説を見ずにそう感じました。
説明せずとも、直感的にテーマを考え楽しめるというのは作品の明快さと同時に、作品に対する親近感を示しているとも言えそうです。


サプライズ性はエンターテインメントには必要な要素であり、かつ作品や世界観に没入していくとっかかりやトリガーになるのだなと、本展示の体験を通して実感しました。
それは別段アートやエンタメ領域に限らず、分野や職種を超えて、人に何かを伝え共感する上でも必要とも言えるわけですし、今後そういうことを自身の活動や仕事面でも意識していきたいなと感じました。

CreateJS勉強会 (第9回)に行ってきた

12月7日、 Adobe Creative Cloud 道場 にてCreateJS勉強会がありました。

私自身、 CreateJS を昨年から触り始め実案件でいくつか導入してみました。その他2D Canvasライブラリだと Pixi.js も使ったことがありますが、日本語のドキュメントが少なく、バージョンも適宜更新されてネットで探した記事だと記述が前のバージョンだったりして。
CreateJSについては、 ICSさんのCreateJS入門サイト があったので、比較的スムーズに覚えて徐々に調べつつ進められました。

今回は、CreateJSが正規版1.0.0にあがったことで何ができるのか、登壇された3名のお話を聞いて自分なりにまとめてみました。

CreateJSの概要 + Animate CC 2018の新機能 (ICS 池田さん)

  • 2012年頃、カナダのFlashクリエイターGrant SkinnerがHTML5向けにCanvasライブラリを立ち上げた(ちなみに、Canvasを使った事例は ここ にあるらしい)
  • 当初、EaselJSのみ提供していたが、ローディング・音声等包括してCreateJSという名称に
  • CreateJSの得意分野は、インタラクションコンテンツ、自由度の高い表現。苦手分野は、ユーザーインターフェース(HTMLでやった方がスムーズ)
  • 使える用途として、ゲーム・スペシャルサイト・バナー広告
  • 他ライブラリに比べCreateJSの利点は、Animate CCとの連携(HTML5 Canvasドキュメントで内部的にCreateJSが利用されている、CreateJSで書き出しされる)
  • 最新Animate CCでは、カメラ機能・深度機能が加わった(その他、Robert Penner式のイージング設定とか、タイムライン上に秒数が表示される、絶対時間を保ったままFPSを変更できるとか)

CreateJS 1.0.0で何が変わったか (野中さん)

  • こちらのレジュメ を元に進行
  • StageGLによるWebGL対応が可能になった
  • コンストラクタStage()の呼び出しをStageGL()にする
  • デフォルトだとステージがグレーになるので、StageGL.setClearColor()メソッドにカラーを渡す
  • Shapeオブジェクトをキャッシュさせる
  • フィルターは機能するが、マスク・合成機能がStageGLで動作しない

我々はCreateJSをどう使うべきか? (世路庵 沖さん)

  • アニメーションを使う意図として、[フィードバック]・[世界観の演出]・[ストーリーの伝達]がある
  • アニメーションにしか伝えられないことがある
  • 今のアニメーション実装方法(DOM / CSS3 / Canva)は、コード思考のアニメーション
  • Animate CCのような、タイムライン思考のアニメーションにしか伝えられないことがある

池田さんのお話で印象に残ったのは、Animate CCの新機能でした。
カメラ・深度機能が追加されたことで、同じAdobe製品のAfter Effectsを彷彿とさせました。
グラフィックやイラスト主体にした平面表現であれば現状機能で事足りるでしょうが、
奥行き感をもたせた3Dライクな2Dコンテンツを作るのであれば、必要な機能と言えるでしょう。
この辺りは、レイヤー間の動きが映像作品のように緻密になってきそうなので、ビジュアルエディタによるところが大きいと思われます。

映像だと、湯浅監督が「ピンポン」や「夜明け告げるルーのうた」でFlashを制作ツールとして使うという事例もあるので、上記機能による活用性が広がりそうな気がします。

野中さんによる、CreateJS新機能も着目すべき点でした。
これまでContext 2D Canvasでの表現にとどまっていましたが、WebGL対応によりパーティクルだったり数の多い物体のアニメーションを高速で処理できるようになり、リッチ表現の幅が広がることが期待されました。
一方で、これまでの記述と違う点(ごく部分的なところのようです)や、マスクや合成が動作しなかったりと、WebGLがすべての表現において有効手段とは言い難いともいえます。この辺りはICSさんの方も以前 検証 をしていたようです。

最後、沖さんのお話は現在の実装方法とも絡めたアニメーションの重要性という意味で考えさせる内容でした。

確かに、JSやCSSによるアニメーション記述が豊富になってきたことでコードで考えるアニメーション実装が増えてきました。頭の中でシミュレーションして、立てたロジックの試行錯誤と調整。現在それの行き着くところが、Three.jsを使った奥行きも加味した3D表現だったり、GLSLや数学演算を用いてランダム性を持たせたり数千数万の物体を操作するプログラマブルリッチコンテンツになるのでしょう。

一方で、グラフやイラストといった少数を対象にフォーカスさせるアニメーションとかは、タイムラインの必要性は大きいでしょう。映像作品を作るように、視覚的に気持ちの良い動きかどうか、相互のフレーム間の調整がしやすいところが強みと言えます。それは、Animate CCに限らず、3D系のビジュアルエディタであれば、Unityとか Play Canvas も候補として考えられます。

ということをつらつら考えつつ、コード・タイムラインという手段を、フロントエンドエンジニアとして両輪うまく生かしていきたいなと思った勉強会でした。

参考:
https://wired.jp/2014/09/10/science-saru/
https://gigazine.net/news/20170417-masaaki-yuasa-interview/
https://ics.media/entry/5140

WebRTCサンプルが Safari × Codepenで動かなかったこと

iOS11の実機で、WebRTCを使ってカメラアクセスができるか試してみました。
WebRTCはhttps環境のサーバ、あるいは例外的にlocalhostで動作するようになっているが、実機でみることからhttps環境のサーバにあげることになりました。

ただ、自前のサーバを整備していないので、
Codepen に記述してそれをブラウザで見たところ、
PCのChromeブラウザでは問題なく表示されたが、
実機及びPCのSafariブラウザでは表示されずDOM Exception的なアラートが出ました。

よく分からないので、実機にUSBつなげてコンソールで見てみると、
以下のようなメッセージが出ているみたい。。。

Trying to call getUserMedia from a document with a different security origin than its top-level frame

どうもiframe内ではgetUserMediaが動作しないらしいです。
そして、iframeを使ったエディタツールにCodepenと JSFiddle があるようです。

ひとまず JS Bin のOutputの外部表示でやってみてます。
(Outputだけだったり、htmlとかのタブも立ち上げててもiframeで処理されてるので)

ちなみに、WebRTCの記述は以下のように書いています(videoタグを使って、カメラからのストリーム情報を受け取るという想定で)。
前はnavigator.getUserMediaと書かれていたものが、記述的に非推奨になった模様。
そして、以降の処理をPromiseを使って成功・失敗時で振り分けているようです。

[ HTML ]

<video src="" id="video" autoplay playsinline></video>  

[ JavaScript ]

var medias = { audio: false, video: true },
    video = document.getElementById('video');  
    
// カメラ接続
var promise = navigator.mediaDevices.getUserMedia(medias);
promise.then(successCallback, errorCallback);
  
// カメラ接続成功時
function successCallback(stream){
  video.srcObject = stream;
}

// カメラ接続失敗時
function errorCallback(err){
  alert(err);
}

参考:
https://developer.mozilla.org/ja/docs/Web/API/MediaDevices/getUserMedia
https://webrtchacks.com/safari-webrtc/

テクノロジーとマジックと

現在、フロントエンドエンジニアとして従事していることから、
自分で作ること以外に他サイトの演出やら表現を見る機会がしばしばあります。
その時、このサイトはどういう仕組みで動いているのだろうかと考えることがあります。

言うなれば、「マジックのネタがどうなっているかを探ること」に近いのかもしれません。

マジックは、見たことのない、ありえないことを目の前で見せ、
観ている人を驚き歓喜させ、どんな仕掛けでやっているのかと考えを巡らせたりします。
幼い頃、TVや商業施設のマジック実演に対し魔法を観たような感覚を覚え、
マジックのトリック本を買ったり、グッズを買っては実際にやってみた記憶があります。

Webサイトの表現やインタラクションであったり、
IoTプロダクトやインスタレーションの展示にしても同じように、


現実世界で見たことのない、あるいはありえないことをしてみせる


ところがあるのではないかと考えます。

エンジニアは、そういったものを見るとそのタネを探ってみたくなる。
そういう性分が多少なりあると考えるのは私だけですかね。

そういう考えに至ったきっかけに、
落合 陽一さんが提唱されていた「魔法化」にあったのだろうと振り返ります。

www.advertimes.com

iOS11からできる!WebRTCでできること

だいぶ前になりますが、9月にうちうちで発表した内容をブログで整理してみました。

今年のWWDCで、いよいよMac SafariiOS SafariでもWebRTCが正式サポートされることになり、
Webコンテンツでできそうなことを書いてみました。
ちなみに、WebRTCの醍醐味(?)とも言えるビデオチャットについては触れず、
カメラ・オーディオアクセスに焦点におきスタンドアローンでやれそうな事柄を列記しています。

スライドのうちできそうなことをまとめると、


- シームレスな導線設計
これまでカメラを使った施策だと、標準のカメラアプリを立ち上げたり、カメラロールから写真を選ぶという中間工程が発生するところを、カメラデバイスにアクセスすることで一貫した体験コンテンツが作れそう。
(既に撮影したものから選択するケースは、これまで通り<input type="file"...>を使ってカメラロールから選ぶことになりそうですが)

- カメラ撮影のカスタマイズ
カメラアプリだと、撮影エリアと撮影ボタン・カメラ切替ボタン(+撮影モードがいくつか)が標準ですが、Webページの中にカメラから投影された映像を埋め込めるので、周りをフィルタで飾ったりする等、撮影画面もクリエイティブに活用できそうです。
一方で、標準カメラアプリにないUIを独自でカスタマイズする(撮影ボタンをどこにおくかとか)が必要になります。

- 顔認識ライブラリと連携したコンテンツ
「シームレスな導線設計」にも関連しますが、顔認識はJSあるいはサーバサイドでカメラやカメラロールで取得した静止画像を使って認識するというものになっていました。
ただ、カメラから取得した動画ストリームを顔認識ライブラリで加工できるようになると、SNOWのようなアプリでしかできなかったことでブラウザでもできるようになりそうです。
この辺りは使うライブラリによって認識精度やフィジビリも変わってきそうです。

- マーカーを読み取ってのARコンテンツ
これも顔認識と同様、モバイルブラウザでできそうなインタラクティブ領域の一つです。
AR.jsというjsでARコンテンツが作れるライブラリを活用して、マーカーに反応して3Dモデルを表示したりと、アプリをインストールせずに遊べるコンテンツが作れそうです。

- マイクで取得した音声のビジュアライズ
WebRTCはカメラだけでなくオーディオデバイスへのアクセスも可能です。
そのため、スマホのマイクから音を拾ってボリュームなどに応じたビジュアライズコンテンツができそうです。音量が大きいとレスポンスを返してくれたりと、今後は音声解析も加えてモバイルでできると楽しそうです。


スマホアプリにはできてモバイルブラウザでできなかったことが、今後できることがいろいろ増えてきてフロントエンド側としてはモチベーション高まるものがあります。
ただ、WebRTC未対応のデバイス(iOS10以下)を使っているユーザも少なからずいるわけで、そうした人向けに対するフォローアップも必要と思われます。