Archives

Semantic-UI をCakePHPに導入

UIフレームワークといえばtwitter-bootstrapが有名ですけど、なんか既視感がある。

そんなとき、次の選択肢としてSemantic UIがあるかと思います。

ちょっとCakePHPで使う機会があったので簡単だけど導入まとめ。

  1. zipでダウンロード: http://semantic-ui.com/build/semantic.zip
  2. 解凍した後、packagedフォルダをCakePHPのapp/webroot/にコピー
  3. packagedフォルダの名前をsemanticとかに変更する
  4. ctpに以下を追記
<link rel="stylesheet" type="text/css" href="/semantic/css/semantic.css">
<script src="/semantic/javascript/semantic.js"></script>

 

フォトリフレクタで指動作認識できなかった

前回arduinoにつないでprocessingで値を読み取るまでをやったフォトリフレクタですが、これで指の動作認識ができないかと考えました。

指を伸ばした時と曲げた時とでは皮の厚みが異なるので、透過率の違いとして認識できませんかねということです。

1 ページ

 

そんでまあ、結果としてはできませんでした。何故かというと、指の皮は思ったより厚くて、伸ばした状態でもフォトリフレクタの値はかなり低いままだったからです。

Camera 360

 

しくみは単純で、指サックにフォトリフレクタを取り付けただけ。

Camera 360

 

それでも悔しいのでなんかできないかと探してたらこんなのがありました。

この方法ではフォトリフレクタを皮膚を離しておいて、リングを指に押し付けたときに指との距離の変化の度合いを見て指の柔らかさを認識する、ということが行われているようです。

今度はJST ERATOの五十嵐健夫先生のプロジェクトであった伸縮性認識でも試しにやってみよう…
MetaSkin: 薄くて伸縮性のある皮膚のようなインタフェース

エレベータボタン問題に潜むUXの構造的問題

  1. http://fladdict.net/blog/2013/01/cognitive-buttons-for-elevator.html
  2. http://d.hatena.ne.jp/wa-ren/20130129/p1

を読んで、ボタンのデザインとしては1が分かりやすくてとても良いと思うのですが、2で指摘されている部分、

もそも根本的な話として、ひらくボタンはどういう時に使うのか? それは閉まりかけのドアに無理に入り込もうとする人を助けてあげるときや、先に入った人が後からくる人のために開けて待っているというシチュエーション。でもそれって、エレベーター利用者全体のUXを悪化させていると思うわけですよ。そもそも駆け込み乗車(乗籠?)は危険だからやるべきじゃぁない。また、Aさんが先に入って、歩みの遅いBさんのために開けたまま状態を延長することは他の階で待つユーザのUXを悪化させる。ひらくボタンが存在することによって悪化するUXはもっとある。駆け込み乗車しようとするCさんを先に乗った(こちらも急いでいる)Aさん見限るケースもそうだ。Cさんとしては『あ、あいつひらくボタンを押さずに俺を見捨てやがったな』と感じるし、Aさんとしても『もしAさんが間に合ったら、ここでひらくボタンを押さなかった私を恨むだろう。でも私だって急いでいるからあなたを待ちたくはないのだ….』と心おだやかではなくなるはずだ。

これはUX的視点としてとても重要です。で、ここで指摘しているにもかかわらず、ひらくボタンを無くしてとじるボタンを残すと、「目の前で閉めやがった」という状況が起こることには変わりないわけです。僕はどちらであろうと気にしませんが。

スクリーンショット_13_01_29_13_03

叫ぶ云々はどうでもいいですが、対策としては、「エレベーター内部から近づいてくる人が見えないようにする」という方法が考えられます。

ev

 

レッシグ先生の「アーキテクチャ」的解決です。オフィスビルなんかではエントランスを煩雑にしないためにエレベーターホールが隠されてますが、そんな感じです。

つまり言いたいことはですね、UXを考えるならアーキテクチャも必要だよねってことです。そして、ボタンのデザイン(大きさ、色やら)は問題の発生確率を下げるように考えるわけですが、完璧なものはなくて2のように色々と副作用が生まれてくるわけです。

現代の建築士は通路の設計はしますが、エレベータを特注でつくるとなると高コストなので普通はしないでしょう。エレベータ―登場のほんの初期には、建築士とも相談してやっていたでしょう。今よりももっと高コストだったでしょうけど。

要するに普通の設計案件において建築士がすべてのUIを操作することは不可能で、既成品の組合せで大体はどうにかすることになります。そうした時に、せめてエレベーター会社はUI設計の理念というか目的を明らかにするべきでしょう。

ひらくボタンをなくすのもとじるボタンをなくすのもそれぞれ言い点悪い点は状況によって存在するので、都会の駅ビルとか人が多すぎて匿名性が高くかつ回転率を上げたい所ではとじるボタンだけのを用意するとか、上で顔を合わすことになる小さい会議場のビルとかはひらくボタンは残すとかいう「想定する状況と目的」をあらゆるプロダクトについて考えるべきだと思うんです。組み合わせやすいようにパタン・ランゲージとか使えよ!ってことです。

UI快感原則

粘性のあるGUIを”なんか気持ちいい”と思ったことはないだろうか。クリックしたらパッと変化するんじゃなくて、うにょーんと動きが補完されているアレである。
ビジュアライジング・データでは、ばねの挙動(F=kx)でそれを実現していたが、そもそもアレはなんで気持ちいいのだろうか?
「き、気持よくなんか、ないんだから・・・ッ」ていう人はもうどうしようもないのでそっとブラウザを閉じていただくことにして、ここではアレは「ンギモッヂイイ」という前提で、だとしたらなぜ気持ちいいのか考えてみる。根拠は微妙。

f:id:Drunkar:20120713002650g:image:left f:id:Drunkar:20120713002753g:image:left

動きが遅くてあんまり気持ちよくないのは僕の岐阜技術のせいですきっと。

iPhoneはなぜ気持ちがよいのか? (1/5) | Telescope Magazine
上記の記事では、マウスカーソルの動きが手の動きと連動しているがゆえにカーソル自体は意識されずに、意識は画面内のコンテンツに向かう(カーソルの自己帰属率が100%とする)ので、その動きに一定の制限や変化を加えることで、自身が道具を操作していることに意識が向かい、(すなわち自己帰属率の操作によって)ひっかかりや滑らかさなどをユーザーに意識させることができるとしている。したがってただリッチなアニメーションを加えれば良いというわけではない、という主張も行なっている。

この視点で見ると、ばね補完されるコンテンツの変化は、ユーザーがマウスカーソルという透明な手の延長から加えた力が擬似的にコンテンツに伝達されているのだと言える。そして、なにかに自分の力を伝達するということは気持ちいいのだ。
これは球技などのスポーツをやっていた人なら経験的に感じていると思う。僕は野球をやっていたので野球で説明するが、野球のボールをうまく投げるためには、地面を蹴った反力に加え、体幹の回転と腕の振りからなるコリオリ力、そして筋肉の収縮力をタイミングよく強調させなければならない。適当なフォームだとうまくバックスピンしないので遠くまでボールが飛ばないし、力が体のどこかに集中することになるのでそこを傷めることになる。
という説明はどうでもいいのだが、これを習得すると、なんというか「投げるだけで気持ちいい」状態になるのだ。体を力が走り抜けていく感覚が気持ちよくて、放たれたボールがノビていくのも気持ちいいのだ。

別にこれは僕が変態だからではなくて、「狩猟時代の名残では」というのが野球研究家(?)の手塚一志氏の考えだ(確か「バッティングの正体」か「バッティングの極意」で読んだ気がする)。投石あるいは投槍は生死にかかわる技術であったろうというわけだ。
あと、ばね補完の「最初は速度が大きくて、最終的に0になる」ってのは投擲者の視点から見た投擲物の視平面上の速度でもあるので、注目してしまうってのもあるかもしれない。もっとも、人間の目が動きに反応するようにできてるので単にそのせいだとも言えるが。
f:id:Drunkar:20120713011236p:image
※この距離と速度の変化の割合はもちろん視対象との角度で違ってくる。

でも、この動きに反する動きでも気持ちいい時がある。

D
これはSHARPのAndroid用UIであるFeel UXである(ステマじゃないよ)。
0:56ぐらいに、Welcome sheetのタブを引っ張ると、画面が両側に引き上げていくギミックがあるが、僕はこれがけっこう気持ちいいんじゃないかと思うのだ。

これは「からくり」の気持ちよさだ。
フィルムで撮るカメラのレンズをカバーする部分とかによく使われてたと思う。なんにせよ、これは自分が加えた力とタイミングこそ同期すれ、片方はまったく反対の方向に動く。またしても先ほどの透明性の議論での説明になるが、これが自分の力と同じ方向だけならコンテンツの動き自体意識されないままになるだろう。しかしこの場合方向が変えられているために、一瞬「あれ!?」と感じて、自己帰属率が下がり、その運動を意識する。そして「自分の力が広範囲に影響している」という快感を得ることができるのではないか。
力が影響範囲に関して増強されているから、気持ちいいんじゃないか。
Clearでタスクを消すのが気持ちいいのも、ファーストアクセスでコンテンツを全面に出したUIもさることながら、指でチョイッとスライドした行が、ポチョムキンッっと落ちていくとかそういう要は「力の増強」を動きの因果関係(スライドしたから枠から外れて落ちる)で行うことで気持ちよさを実現していると考えることができる。

D
たぶんユーザーの「力の増強」の方向としては、
・作用範囲
・因果関係(効果音も含まれる)
・速度
・エフェクト(火花とかそういうの。効果音も。)
とかがあると思う。そしてこれらを、ユーザーのデバイスに対する帰属率を少し下げることで気づかせる必要がある。もちろん、単に速度を変えるだけでも帰属率は下がるだろうし、上記の「力の増強」によってほとんどそれらが行われる。
しかし、今度は逆に帰属率が下がりすぎるという心配もあるので、ユーザーの加えた力方向のベクトルを持つ割合の高い要素を増やすとかして対応するといいんでは。
そしたら運動方向だけに関してならベクトルの帰属率で解析できますね。

ここでもう1個の話。
今度はデバイスの視点になって考えてみよう。
デバイスはユーザー様に処理の過程をUIとして表示しなければならない。別にキッチンで料理をしているところを見せる必要はないけど、キッチンからテーブルに運ばれてくるまではスペクタクルである。「うおーうまそー」「ついに食べるんだ」っていう気持ちを持たせることが出来れば成功である。「明日また来てください。最高の(ry」とか言ってたらそのデバイスは捨てられるだろう。スピードも重要なのだ。

この、
・ユーザーが処理を行うまでのスペクタクル
・スピード
を実現しているのがうにょーんGUIだと言うわけだ。移動している間にユーザーはコンテンツを見ることができるし、だんだん遅くなるわけだからなんかこうデバイスがユーザー様の命じるとおりに素早く、しかも優しくコンテンツをサーブしてくれてるような感じを覚える。もちろん、移動中の操作をカバーしなければ意味が無いが。

このUIの実装の例は、データをリスト表示する際に、上からリストが降ってくるみたいなやつだ(ちょうどいいのが思い浮かばない)。デバイスの奥ゆかしい心が垣間見えて実に味わい深い瞬間である。

とりあえず僕が思ったのはこんな感じ。まとめると、
・自己帰属率の操作によってユーザーは操作を意識することになるが、そこにおける気持良さは「力の増強」であり、
  ・作用範囲
  ・因果関係(効果音も含まれる)
  ・速度
  ・エフェクト(火花とかそういうの。効果音も。)
 とかに対して行われる。
・自己帰属率の操作は「力の増強」そのものによっても下げられるが、下がり過ぎないよう補強が必要なときもある
・自己帰属率とは無関係に、ソフトの「奥ゆかしさ」も気持ちよさのひとつの要因である。

なんか当たり前なことしか言ってない気もするけどまあよしということで。