HTML5でできるカメラアプリ・予習(2)-撮影から画像生成まで-

main.jpg
gayouさん、ありがとうございます。
というわけで、Android版Opera Mobile 12.00というバージョンで対応していることをこちらでも確認しました。
ただ、今回お話する「設定」の部分がTP(テクニカルプレビュー、前回から使っているアイコンに「LAB」がついたもの)と違いがあり、ちょっと混乱しそうなので、前回ダウンロードしたLAB付きのOpera Mobileを使ってチャレンジしてみたいとおもいます。
ではCSS Nite in OSAKA, Vol.30の予習記事その2ということで挑戦してみましょう。
さてこれまでで、AndroidのカメラからHTMLベースで写真を撮影することができました。こんどは、撮った画像をサーバにアップするために、img要素を生成しましょう。
まずは前回のとおり、撮影した映像をvideo要素に取り込みます。
今回は最終的にはそれをPHPに向けて送信するため、「video要素からcanvas要素に描画した画像をPNGやJPEG形式の画像に書き出す」までをおこないます。
ただし、AndroidのWebブラウザは通常それを許可していません。
色々な理由、セキュリティやプライバシーの問題もあってのことでしょう。
canvas要素にはtoDataURL()というJavaScriptの命令があります。
これでcanvas要素から画像を生成することができます。
しかし、これが許可されてないんです。
(Android、というよりブラウザで制御している、と言った方が正しいかも)
ただし、これはOpera Mobile上のコンフィグという「設定」で解除することができます。
実験的にこのtoDataURL()をつかいたい場合、まずはこれを解除しましょう。
URLに「opera:config」と入力します(最後にスラッシュはつけないでください)。
すると「設定ファイルエディタ」というページが表示されるはずです、下図を参照してください。
config01.png
config02.png
config03.png
ここでちょっと下にスクロールすると「Security Prefs」というタブがありますので、
「Allow Camera To Canvas Copy」という項目にチェックをいれます。
さらにその下の「保存」ボタンを押して下さい(結構忘れがちです)。
以上でOKです。
これでtoDataURL()が有効になり、canvas要素からPNGやJPEGのような画像が生成できます。
(注意!)
これは、テストが終わったらかならず設定で元に戻してください。
そうすればカメラの映像は外部に漏れることはないので、セキュリティ上、充分注意して使ってください。

ボタンが押されたらvideo要素からcanvas要素に静止画を書き出す

上記の設定が済んだら、撮った写真をcanvas要素に描画します。
以下のサンプルではbutton要素が押されたらvideo要素の画像をcanvas要素に描画します。

<!DOCTYPE HTML>

<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, user-scalable=no">
<title>カメラの映像を映す!</title>
<style>
html, body, video {
margin: 0;
padding: 0;
}
video, canvas, button {
display: block;
}
</style>
<script>
function init() {
var video = document.getElementsByTagName("video")[0];
var canvas = document.getElementsByTagName("canvas")[0];
var ctx = canvas.getContext("2d");
navigator.getUserMedia("video", function (s){
video.src = s;
});
document.getElementsByTagName("button")[0].addEventListener("click", function () {
ctx.drawImage(video, 0, 0);
}, false);
}
</script>
</head>
<body onload="init()">
<button>撮影</button>
<video autoplay></video>
<p>▼ここからcanvas</p>
<canvas></canvas>
<p>▼ここからimg</p>
<img alt="canvasから書き出された画像" />
</body>

</html>

  

device.png
 
device4.jpg
もちろん、このとおりvideo要素とcanvas要素のサイズが合ってないので、実際完成させるにはこのサイズを同じにしてしまわないといけません。(今回は省略します)

canvas要素からJPEG画像をつくる

それではimg要素にcanvasの画像を出力します。
canvas要素にはtoDataURL()というメソッドが用意されています。
これを使うと、Base64と呼ばれる文字列が吐き出されます。
この長い文字列は、画像だけでなく、PDFファイルなど色々なファイルに置換できます。
ボタンを押されたときに、alert(canvas.toDataURL())を仕込むと下図のようにアラートが表示されます。これがBase64の文字列です。よく見ると、これはPNG形式の画像を文字列にした、ということがわかります。

今回はJPEG画像にするので、canvas.toDataURL(“image/jpeg”)とします。
省略するとPNG形式になるようです。

device3.png
これをこのままimg要素のsrc属性の値にすると、画像が表示されます。

<!DOCTYPE HTML>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, user-scalable=no">
<title>カメラの映像を映す!</title>
<style>
html, body, video {
margin: 0;
padding: 0;
}
video, canvas, button {
display: block;
}
</style>
<script>
function init() {
var video = document.getElementsByTagName("video")[0];
var canvas = document.getElementsByTagName("canvas")[0];
var ctx = canvas.getContext("2d");
navigator.getUserMedia("video", function (s){
video.src = s;
});
document.getElementsByTagName("button")[0].addEventListener("click", function () {
ctx.drawImage(video, 0, 0);
document.getElementsByTagName("img")[0].src = canvas.toDataURL("image/jpeg");
}, false);
}
</script>
</head>
<body onload="init()">
<button>撮影</button>
<video autoplay></video>
<p>▼ここからcanvas</p>
<canvas></canvas>
<p>▼ここからimg</p>
<img alt="canvasから書き出された画像" />
</body>

</html>

device2.png
さて、これで「撮影して静止画をimg要素に書きだす」までできました。
次回はいよいよ、サーバ上にあるPHPにこの画像を送って保存しましょう。

HTML5でできるカメラアプリ・予習(1)

webrtc.png

こちらのイベント「CSS Nite in OSAKA, Vol.30」で実演する内容です。
将来はこういったことは現実に私達の仕事になってくると思われる、HTMLベースのカメラアプリ。
video要素やcanvas要素を使って撮った写真を加工してサーバに残す、なんてことは特にスマホ案件で依頼が来るかもしれません、そうなって焦らないように今から勉強しておきたいですね。
せっかくイベントで発表させてもらうので、これからシリーズでブログに書いていこうと思います、いまから勉強するのは決して早すぎることはないでしょう。

カメラアクセス、2つの仕様

まずはHTML5関連で、ブラウザからデバイスのカメラやマイクにアクセスする仕様は大きく2つあるように思えます。
WebRTC 1.0: Real-time Communication Between Browsers
The Media Capture API
どちらともスマホのカメラで写真が撮れて、保存したりできそうです。
ただしこの2つの仕様の目的はちょっと違うようです。
WebRTCのほうは文字どおり、リアルタイムコミュニケーションをブラウザ間にて可能にするというもの、つまりスカイプのHTML版のようなものです。

壮大なWebRTCのゆくえ

WebRTCの仕様のページを斜め読みするだけでも、その目的が壮大で、
カメラにアクセスすることだけが主な目的ではないようですね。
その目玉といえるのは「Peer-to-peer connections(ペアトゥーペアコネクション)」。
この仕様は、カメラで録りっぱなしの映像(動画)を、別の人のブラウザに届け、お互い映像のやりとりをおこなうことを目的としてるようです。

デモを試してみよう

zuhan.jpg
Opera mobileのテクニカルプレビューをAndroidスマートフォンにインストールしましょう。
以下のサイトの「Android Build」のリンクをタップしてダウンロードしてください。
「LAB」と書いてあるOperaのアイコンです、起動してください。
まずはこちらのページにアクセスしましょう。
これを動画で見るとこうなります。

Opera MobileでgetUserMedia from Hideki Akiba on Vimeo.

最低限ソースコードでカメラ撮影、でも向きを変えると縦横非がおかしくなる…
ソースコードもシンプルですし、意外と簡単です。

<!DOCTYPE HTML>
<html lang="ja">
     <head>
          <meta charset="UTF-8">
          <meta name="viewport" content="width=device-width, user-scalable=no">
          <title>カメラの映像を映す</title>
     </head>
    
     <body>
         
          <video autoplay>
         
          <script>
               var video = document.getElementsByTagName("video")[0];
               navigator.getUserMedia("video", function (s){
                    video.src = s; // カメラ接続が成功したら、ストリームをvideo要素に接続
               });
          </script>
         
     </body>
</html>

navigator.getUserMediaというメソッドがカメラを取得するという役目を担います。
取得が成功したらvideo要素に映像ストリームを流すというものです。
注意としては、仕様書と、Opera Mobileの実装がコードを見るとちがいます。
将来は微妙に変わってくるでしょうが、基本的な原理の部分はほぼこのままでいてほしいです。
zuhan2.jpg
動画でもわかるとおりネイティブアプリのカメラ機能とちがい、できないことが多すぎます。
   * オートフォーカスの機能がつかえない
   * 撮影する写真の解像度を決めることができない
   * フラッシュなどの機能がつかえない
   * スマホの縦横の向きを変えると、映像の縦横比がおかしくなる
この、向きを変えたときに縦横比がおかしいのはちょっと使いにくいので、ちょっと工夫をこらしてみました。
もしもデバイスの向きが変わったら、一旦video要素に流れているストリームをとめて、
video要素のサイズをwindowのサイズにあわせた後にもう一度ストリームを流します。
どうしても、video要素を全体的に見せたい場合、横向きがこんな感じにしかならなかったんですが、これでなんとかなりそうです。

Opera MobileでgetUserMedia2 from Hideki Akiba on Vimeo.

今度は縦横比を修正しました
ソースコードは先ほどのものよりちょっと付け足しました。

<!DOCTYPE HTML>
<html lang="ja">
     <head>
          <meta charset="UTF-8">
          <meta name="viewport" content="width=device-width, user-scalable=no">
          <script src="../common/js/jquery-1.7.1.min.js"></script>
          <title>カメラの映像を映す</title>
          <style>
           html, body, video {
                margin: 0;
                padding: 0;
           }
          </style>
     </head>
    
     <body>
    
     <video autoplay>
         
          <script>
               var video = document.getElementsByTagName("video")[0];
               var stream = null;
               navigator.getUserMedia("video", function (s){
                    video.src = stream = s;
               });
              
               $(window).bind('load orientationchange resize', function(e){
                    // デバイスの向きが変わったら...
                    video.src = null; //一旦ストリームを解除する
                    if(Math.abs(window.orientation) === 90){
                         video.width = window.innerWidth; //video要素のサイズを調整
                    }else{
                         video.height = window.innerHeight; //video要素のサイズを調整
                    }
                    video.src = stream; //再度ストリームを接続する
               });
          </script>
    
     </body>
</html>

まとめ

将来は、撮影機能つきのWebサイト制作があるかもしれません。
そうなると今までAndroidアプリ開発のために、XMLをコーディングしていたデザイナーも、これからはHTMLやCSSでデザインをする時代がくるわけですね、そう遠くもないでしょう。
今は本当にテストビルドなので、簡素な実装です。
もちろん本格的に実装なんかしたらセキュリティやプライバシーの問題があるので、「あること」をしないと画像として送信できないことになっています。
しかし今はこれで充分楽しめます。
オートフォーカスもできないのであればちょっと実用はむずかしいかな?と思いますが、こういった部分はどんどん使える実装になっていくんでしょうね、楽しみです。
この次は録った画像をcanvas要素に描画して、色々と画像を操作することにチャレンジしてみます。
今回の内容は2012年5月4日(金)に大阪で開催されるCSS Nite in OSAKA, Vol.30で実演します。
他にも、録った写真をサーバにアップしたり、モノクロにしたり、色々なデモをやってみますが、会場に来られた方でAndroidをお持ちの方は是非、今回のテスト版Opera Mobileをダウンロードしてお越しください。
結構ディレクターさんとかにも聞いてほしい内容です。
これからのWeb技術なので知っておいてソンはないと思いますので。
参加表明はお気軽にFacebookからおねがいします。

CSS3コードジェネレータ「Grad3 – Easy CSS3 gradient editor -」公開

og_img.png

前にもここで告知しましたが公開しました、Grad2の後継バージョン「Grad3 – Easy CSS3 gradient editor -」[ http://grad3.ecoloniq.jp/ ]です。

円形グラデーションにも対応させてますが、古いWebKitの仕様と新しいWebKitの仕様だと、お互いできることとできないことがあるので、円の中心座標だけ決めてしまうというもので進めていこうと考えてつくりました。
アイコンも付けられますが実際はみなさんで微調整してください。
background-positionは暫定でつけていますので。
あと、動画をつくってみました。

なお、CSS Nite in OSAKA, Vol.30でもちょっとだけ紹介したいとおもいます。

CSS Nite in OSAKA, Vol.30

これからもどうぞよろしくお願いします!

HTML5でできるカメラアプリでサーバアップまでやってみる

keyvisual_30.jpeg

来る5/4(金曜)の19時から、ほんっと久しぶりにCSS Nite in OSAKAでお話します。

内容は「HTML5でできるカメラアプリを実際に体験しよう」です。
以前、たった1回のハッカソンでつくったHTML5でつくったOperaブラウザのカメラアプリの記事を書いたんですが…
実は撮影した写真をサーバにアップするというところまでやってみようと思います。
軽く動画を撮ってみました、これをベースに将来できることを考えたいと思います。

これは自作の簡単なテストアプリですが、HTML+CSS+JavaScriptで写真を撮影し、PHPに画像を送信しています。
これをもとに、HTMLベースで将来つくれる動画や音声を扱うWebアプリはどこまで進化して、僕らはどこまでその仕事に関われるんだろう?というテーマに突っ込んで触れていきたいと思います。
WebRTCという仕様があります。
簡単に言うとちょっと語弊があるけど、将来は映像チャットなどをブラウザとHTMLベースでやってしまおうという仕様で、デバイスのカメラやマイクにブラウザがアクセスしてJavaScriptで操作するものです。
スマートフォンの標準ブラウザは、まだこの仕様をサポートしていません。
しかしAndroid版のOpera Mobileとして公開されているブラウザが、この未来の規格を一部実装しています。
Androidをお持ちの方は、当日までに以下のリンクを実機でタップして、本体にダウンロード&インストールしてご来場ください、みなさんで楽しんでみましょう。
( ↓ Androidでアクセス、ダウンロードがはじまります ↓ )
あまりプログラミングよりの話はしませんが、Webディレクターさんやデザイナーさん、フロントエンドの方も是非おこしください!よろしくお願いします。

ABC2012 Springに登壇します

abc2012_demo.jpg
↑こんなデモをやろうとおもって練習中…
国内最大規模のAndroidの祭典「Android Bazaar and Conference 2012 Spring」に登壇させていただくことになりました。

http://www.android-group.jp/conference/abc2012s/

場所は東京大学!本郷キャンパスです。
そんなとこに入れるなんて一生ないだろうと思ってた…^^
僕のテーマは、最近デザインワークでよく考えさせられる「コーポレートアイデンティティ」というか「ブランディング」に大事なロゴについて。
とくにWebデザイナーがあんまり意識しにくい作り方の部分を実演させてもらおうかな?と。
論理的な話ではなく、実際どういうツールを使って作っているの?
というテーマで、実演をします!!
使うツールはデザイナーによって異なります。
僕は今回、デザインテイストに応じて、Illustratorその他、ほかにLightwaveというグラフックツールにて紹介をさせてもらおうと考えています。
講演時間は13時。C会場(工学部新2号館 241教室)という場所です。
タイムテーブル
会場地図
参加費無料とのことらしいです、まだ予定が空いている方はぜひどうぞ。

CSS3ジェネレータ「Grad3」を3.24に公開

grad3.png

(画像は開発中のものです)
去年の1月あたりに、CSS3のグラデーションを生成するサービス「Grad2」を作ったんですが、色々考えて後継バージョンをリリースすることにしました。
2012年3月24日に「Grad3」をリリースします。
主な追加機能としては、
  • 円形グラデーション
  • サンプルボタンを色相で検索できる新しいユーザインターフェイス
  • アイコンセットやbackground-imageパターンを商用利用可で提供
  • グラデーションだけではなくfont-sizeやcolorなどのプロパティのコードも出力
といったものです。
基本的ポリシーとしては「低機能で使いやすい」を考えてます。
世の中にはもっと高機能なCSS3ジェネレータもあるけど、高機能がゆえにちょっと使いにくい、と思える部分もあって、
自分で使ってみて「こういうの欲しい」というものにしました。
基本的にはGrad2の縦グラデーションしか出力できなかったのにちょっと毛が生えたぐらいで、
「低機能で使いやすい」をそのままコンセプトにしてます。
Fireworksでは「Adobe Fireworks CSS3 Mobile Pack」と言われるものがあるそうですが、
僕らPhotoshopユーザは何か別のツールで作ってたりするんですね、少なくとも僕の場合は。
そんな理由もあってPhotoshopユーザは特に、もし気に入っていただけたらぜひ使ってください。
ちなみに今回のロゴではカメレオンで作ってみました、もちろん僕薫製の3Dモデルでこしらえてます。

Grad3のロゴ

リリースしたらまたお知らせしますね、よろしくお願いします。

家電のインターフェイスを僕らWebデザイナーが作る未来

テレビ放送用のWeb標準規格言語

テレビのリモコンはどのデバイスでも共通のHTMLベースでできる未来?

おことわりですが、、この記事はちょっとした未来の予想と自分の仕事を重ねてみた「想像」が入ってます。
今日は、昨今Web技術が進歩しているなかで僕たちデザイナーがどうやってこのような技術に理解を深めれば良いのか?について考えてみたいと思います。
PCブラウザから始まり、現在はスマートフォンや電子書籍がWebにつながる端末として一般的な世の中になりました。
今年はテレビが来る、とみんな言ってます。
要はWebにつながるテレビ。
実はあまり知られていないことですが、もう10年くらい前に「インターネットテレビ(あえてそう言います)」は発売されていますが、正直普及しているとはいいがたく、例え使っている人にとってはおそらくそのテレビはそのうち使いにくいもの、あるいは使えないものになっているかもしれません。
理由はいくつかありますが、大きな理由はいくらテレビ本体(ハード)が魅力的でも、放送用のデータをやりとりするフォーマットがWeb標準に存在しない当時は、独自のフォーマットに頼ることしか手段がない、といったところかと思われます。
そうなると配信されるコンテンツも豊富になるとは思えません。
BML(社団法人電波産業会が策定した放送用のマークアップランゲージ「Broadcast Markup Language」の略)というものがあり、デジタル放送用に使われている言語ですが、世界に普及していません。
1999年に既に策定されているので、10年以上前の当時にはそういった標準規格があったようですが、世界とつながるWebだけに、日本独自とも言える規格ではせっかくのWebテレビもあまり魅力を感じられないといったところでしょう。
家電をWebにつなぐ、ということは、テレビに限らずこういった標準技術がしっかりしていないと、上で説明した通り全く意味をなしませんしビジネスとして成功を収めるのも困難でしょう。
しかしW3Cが徐々に家電用の標準規格策定に対する動きを見せています。
これが策定され勧告されだすと、世界中のWebにつながるテレビは(というより家電メーカーは)一斉にそっちの標準規格を採用すると言われているので、世界中のコンテンツにアクセスしやすい環境が生まれるわけですね。

今後のWebにつながるデバイスとして

上記から言える通りただ「Webにつながる」というキーワードだけではあまり意味がないのです。
Webにつながっても、それによって生活がどう便利になるか、が問題であり大事なんだと言えるのです。
さて、今後のデバイス、、、
例えばクルマ、電子レンジ、冷蔵庫といったように色々な生活に密着した機器がWebにつながり、僕たち人間が操作する側となる「インターフェイス」が、今のスマートフォンで操作しているタッチパネルと同じような「表層」をHTMLやCSSで構成されて、WebにつながるエンジンがJavaScriptによって情報をやりとりする時代が来ると予想する人も出ています。
まあ、今の流れからいうとありえるな、という気もします。
電子書籍の規格で有名なEPUBもXHTMLで情報が構成されています。
このバージョンが3.0になりHTML5+CSS3を使えるということらしいのですが、いずれにせよWeb標準フォーマットですね。
ある一定のフォーマット(規格)の域から外れずにデータのやりとりが可能なら僕たちのHTMLのスキルもひょっとしたら役に立つかもしれません。
あとは、デバイスの特性を考えた対策が可能な技術も必要でしょう。
例えばクルマを例えてみましょう。
移動するメディアなので、電波の届かない所にいることを考えないといけません。
カーナビがGoogleMapsのようなサービスと連動している場合、電波が届かない場所を走っているときは、あらかじめ周囲数10kmの地図情報をデバイスにキャッシュしておくなど対策がないと困るわけですね。
HTML5ではWebサイト(ページ)を本体にキャッシュしておける機能があります。
オフライン時、つまりネットにつながっていない環境でも情報を閲覧することが出来るわけで、これと似た機能でカーナビにも採用したりするといいでしょう。
(そもそもキャッシュとは既に閲覧した情報を貯めるので意味的にはちょっと違いますが…)
GMailなどはその例ですし、スマートフォンのWebアプリは「オフライン対策は必須だ」という人もいます。
もうひとつ例をあげましょう。
例えば電子レンジやオーブン、グリルなど「火」を扱う機器。
今のWeb標準技術には「熱」を感知するAPIは勧告されていません。
電子レンジのパネルに、料理のレシピサイトから提供されているレシピが表示され、ユーザはそれに従って食材を入れ加熱させるわけですが、その加熱時間はすでにレシピサイトからの情報を受け取っているのでユーザが時間を指定しなくても自動で行ってくれるのです。
ただ、何かの間違いで、指定外のものを入れてしまい加熱して事故になることも視野に入れなければなりません。
熱を感知して加熱を停止させる機能がないと、自動化などするべきではありません。
その機能が家電機器(ハード)に備わっていることも大事ですが、「熱(温度)」を感知する機器を例えばJavaScriptで判定するようなAPIも提供されていないと、Webアプリの開発には常に危険がつきまとうと言っても過言じゃありません。
このように安全面を考えると、「自動化=便利」の背景には「危険」と背中合わせの部分をどう対応するかが極めて重要です。
前面が全てHTMLでできたUIの電子レンジ?

Webにつながる家電に対するデザイナーの仕事として

今僕たちはスマートフォン用のWebサイトの制作に色々知恵を絞っています。
iPhoneだけなら単独プラットフォームなので、微妙なバージョンの違いでなければMobileSafariのレンダリング結果なんてそう差はないはずですが、Android用のWebサイトともなると、表示するだけならまだ良いとしてもWebアプリの機能が加わると色々手を煩わせられます。
この問題はスマートフォンというデバイスにおける問題と考えられが
ちですが、実はこれらは始まったばかりで、これからの未来を考えると、スマートフォンの悩みは氷山の一角にすぎません。
もちろん、こうしている間にもどんどんWebブラウザやそのレンダリングエンジンも整備され改善されていくでしょうから、未来は今程デバイスごとの表示や挙動の違いに悩まされていないかもしれません。
ところが、もしテレビのリモコンや電子レンジのパネルがタッチデバイスとなり、そのインターフェイスがHTMLやCSSで表示されている可能性はまったく否定できません。
テレビのリモコンはスマートフォンでも代替できるようにもなるでしょうが、スマートフォンを持っていないユーザもいることを考えて、やはりテレビ専用の次世代リモコンは付属、もしくは別売りとなるかもしれません、普及当初はスマートフォンがリモコンになる場合、ネイティブアプリが提供されるかもしれませんが、オープンなWeb標準技術で仕様書も公開されているなら、僕らがWebアプリとしてリモコンを作る仕事もあるかもしれません。
例えば、お年寄りにはシンプルな「音量」と「チャンネル」と「電源OFF」のボタン機能だけで良いと言う人もいるでしょう。
逆に多機能に予約録画ボタン、多重放送のプレビューが手元のデバイスでテレビと連動したほうがいいという人もいるでしょう。
ユーザの好みは多岐に分かれるのです。
今のテレビのリモコンはご存知のとおり「ハード」です、つまりボタンの位置をユーザ層によって付け替えることはできません。
しかしタッチパネルとなればそれが可能になるのです。
ユーザの好みで、インターフェイスデザインをカスタマイズすることなんてもう既にPCでは行われています。
HTMLやCSSをJavaScriptで操作して動的に表示すればよいわけです。
あるいは何パターンかユーザーインターフェイスを用意しておいて、まるでブログの「テーマ」のようにユーザが複数のデザインを自分用のリモコン画面として設定保存することが出来るのです。
今お話したことは全て僕たちが普段扱っているHTML+CSS、あるいはJavaScriptの知識資産を使って可能なことです。
もちろん、家電に向けたWeb標準がどう策定され勧告されるかはまだわかりません。
しかし可能性は否定できません。
そうなると僕たちの仕事のフィールドがPCからスマートフォンだけでなく、生活に密接な家電にも広がることになります。
例えばスマートフォンサイトで必須とも言えるviewportやメディアクエリーなんてもうスマートフォンのため、などと言えなくなる未来があるかもしれません。
特に日本の家電メーカーは今韓国などのメーカーに押され、大変な時期です。
Webがオープンな規格なだけに、他社製と差別化を計るのも以前より困難かもしれません。
家電がAndroidのようなオープンなOSを搭載する可能性もあるからですが、しかしながら明らかに独自路線を突っ走るよりはユーザへのサービスを充実させることを重点に置くべきことは家電メーカーも充分に分かっているでしょうし、そこを契機とし、起死回生を計ることができるかもしれません。
iPodやiPhone単体だけの成功ではなく、そこにiTunesというサービスと結びつけたからこそ成功したアップルの例からも言える通り、テレビを始めとする家電も、それだけではもう魅力的ではないのです。
そういった新しいサービスには僕たちデザイナーの活躍するフィールドがどこかに無いか?
と、最近いつもそんなことを考えている毎日です。
この可能性には否定的な意見もあると思いますが、明らかに言えることは、「可能性はゼロではない」ということで、
問題はどこにその可能性が秘められているかを早く見極めること、そしてそれに対する動きをとることが大事で、
場合によっては家電メーカーに売り込みに行くことも考えた方がいいかな?と思っています。

HTML上でiPhoneのフリック時刻用ドラムUIを実現するTimeFlickerJS

iPhoneのフリック時刻用ドラムUIを実現するTimeFlickerJSのサムネイル

以前も記事に書いたデザイナー主体のハッカソンプロジェクト「Designers Hack」で作っているモックをちょっと作り込みましたので、テストバージョンサンプルと動画をあげておきます。

DEMOはこちら(iPhone, Androidで見てください、PCブラウザでは動作しません)

TimeFlickerJS + iPhone4S

TimeFlickerJS + GALAXY S2

iPhoneのUIで見かける、数字を縦にフリックできる日付用のドラムっぽいあのUI。
あれ、HTMLのフォームなどで作ってほしいという要望がありがちです。

でも、「時」と「分」を同時にクルクル指でフリックさせて数字を合わせるHTMLのUIが無いので、作ってみました。
jQueryのプラグインみたいにしてます。

使い方は簡単です。


<head>
  <link rel="stylesheet" type="text/css" href="common/css/timeflicker.css">
  <script src="common/js/jquery-1.7.min.js"></script>
  <script src="common/js/jquery.timeflicker.js"></script>
  <script>
   $(function (){
    $("#timefrom").TimeFlickerJS();
   });
  </script>
</head>

 <body>
  <div id="timefrom">
   <span class="TimeFlickHour">4</span>
   <span class="TimeFlickMinite">10</span>
  </div>
</body>


以上です。
必要なのはHTML上でspan.TimeFlickHourを「時」として、span.TimeFlickMiniteを「分」とします。
これだけは必須なので忘れないように。
あとはその親divをjQueryな書き方でTimeFlickerJS()を付けるだけで準備はOKです。
親div(”4時10分”と表示されている部分)をタップすると、ドラムっぽいUIが降りてきたら成功です。

メソッド

一応、OKボタンが押されたタイミングでイベントを発火できます。


var jikan = $("#timefrom").TimeFlickerJS();
jikan.change(function (e, v1, v2){ console.log(v1+" "+v2); });

とすると、v1に「時」が、v2に「分」が帰ってきますので、
例えばform要素の中で使う際、
<input type=”hidden” name=”jikan” value=”ここにv1とv2を入れてサブミット” >
とかするとお問い合わせフォームでも使えるので良いでしょう。

シビアだけどAndroidでは不採用になりそう?

Designers Hackのフロントエンドエンジニアのメンバーと話していると、Android大丈夫?的な声が。。。
確かにiPhoneはレンダリングも強力なので割とフリックなど滑らかなんですが、GALAXY S2やXPERIA ARCなどで試したら結構厳しいところもあります。
クオリティを考えるとAndroidはもっと別のUIを考え、振り分けた方がいいのでは?という意見が続いています。

あと、このUIは今は横幅320pxとハードコーディングしてます。解像度のちがうAndroidではCSSを触らないといけなくなりそうです、というよりボツになりそうです。
例えばhtcとかの機種では横が空いてしまいますので。。。
これはもうちょっと改善できたらいいなと。

ただ、このようなUIの制作を色んな仲間の意見をもとに作れ、勉強しているって恵まれてるなあと感じます。
精進精進。

デザイナー主体のハッカソンをはじめました

※ハッカソンとは…プログラマが集まって一日、もしくは連日かけて共同で何かアプリなどを作る、というイベント。
Hack+Marathonの造語であるが、エンジニアの会話の中に入れないデザイナーとしては、あまり積極的に参加しにくい傾向があります。
※以降、デザイナーを交えたハッカソンのことを便宜上「デザイナーハッカソン」とここでは言います。

このあいだも、Googleのハッカソンに呼ばれて東京に行って思ったんですが、「知識が豊富なエンジニア達の中にデザイナーを投入してハッカソンを行おう」と、最近そんなことを企画するところが増えだしたな、という気がします。

しかし、企画側の理想は分かるんですが、今までのハッカソンの感覚でやるとまったく意味がないと感じています。
むしろデザイナーを投入するだけ時間の無駄とも言えます。
エンジニアの会話というのは、エンジニア同士でないとなかなか伝わりません。
だから、その場にデザイナーが入り込むと誰とも会話が出来なくなります。

ただし、アプリ全体の完成度を考えると、デザイナーという分野の力は欠かせません。
なぜなら、単に動くだけでは、コンシューマにとって魅力を感じないからです。

デザイナーを交えてハッカソンを行おうとするすべての企画側の人へ

完成のイメージを明確に話し合う、それがないとデザイナーハッカソンは意味がない

まず、アイデアソン(アイデアを話し合う)に完成のイメージを明確にしないとデザインは出来ません。
つまり、そのフェーズを踏まない以上、「デザイナーハッカソンは不可能」と考えて下さい。

では、そのアイデアソンのフェーズなんですが

  • 主なターゲット層を明確に(性別/趣味/年齢層/職業など)
  • UIやビジュアルデザインのイメージを明確に(上記のターゲット層が決定した後だと決めやすい)
  • 画面の手書きラフ(遷移図などを思いついたまま、だんだん清書していく)

さらに、「これは守りましょう」というルールを設けるのもいいでしょう。
・アイデアが出来ないうちに、誰かひとりでもコードを書き始めるとNG(多少の検証はしょうがないとして)
・エンジニアもチーム内すべてが、デザイン面のアイデアソンに加わること

実際の仕事(案件)でも最低限これだけはないと、デザイナーが動けません。

むしろ、将来の私達の業界は、手を動かす人(デザインする人だろうがコードを書く人だろうが)すべてプロジェクトのゴールを明確に見据えるために、発案から参加するスタイルがどんどん必要とされています。
すでにシリコンバレーなど、先進的なITの現場では、このスタイルを導入しています。
「指示が降ってくる」なんて言葉は過去の言葉になるのでしょう。

つまり、この流れを実際にハッカソンで行う事が、私達の制作現場の将来のスタイルを想定しているわけで、私達が5年後、10年後、もっと周囲からの評価が高い仕事を続けていくためには、いまからこのコミュニケーションという難題に触れ、経験し、可能であればその問題解決のすべを自分なりの方法で得なければなりません。

簡単に考えている人は、やってみるときっと頭を打たれるほどの難しさを肌で感じる事でしょう。
とてもシンプルなWebアプリケーションを作るだけでも、リリースまで想定するのであればなんらかの「設計上のデバッグ」が必要となります。

当初のやりとりでうまくいくと想定しても、一つの仕様変更で次々と連鎖的にやり直しとなるでしょう。
でも、ここで見つかったバグをつぶさないと進めてはいけないので、とても進まない事にジレンマを感じます。

デザインのアイデアから設計にいたるまで、チーム全員が参加する必要があるのはそういった理由があるからです。
徹底すると質の高いイベントとなるでしょう。

 

こうなったらデザイナーハッカソンを自分で立ち上げてみました

Designers Hack 001

実はハッカソンに参加したデザイナーの力作が、アプリに反映出来なかったらとても残念な気持ちになり、その気持ちがチームのみんなに伝わらないのは余計つらいんです。
こういった経緯があって、「じゃあ、自分達で企画しよう」ということになりました。

先日和歌山の和歌浦アートキューブに泊まりがけで合宿を行ってきたんですが、これがとても良かったです。

▽とてもおしゃれな和歌浦アートキューブ

とてもおしゃれな和歌浦アートキューブ

一日目はとにかく誰も実装ベースの作業は禁止!
ペンと紙と会話で「完成を想定する」ことで精一杯です。

▽モックをイメージしては書き出し、やりなおし。

モックをイメージしては書き出し、やりなおし。

アプリは「勤怠アプリ」にしました。私達クリエイターにとっては少々くだらないと思えるアイデアも、一般の人にはモチベーションが上がるようなものもあります。
単にアルバイトのスケジュール帳ではなく、稼ぐ毎にアバターが成長/変身していくというもの。

▽出来上がったアバターの原案

出来上がったアバターの原案

iPhoneのSafariで動くことを想定したWebアプリです。最終的にはAndroidでも使えるようにしたいと考えています。

【アプリの概要】
・アルバイトのスケジュールをカレンダーに記帳できる。
・複数のバイト先を新規登録/管理でき、次からスケジュールを記帳しやすいようにする。
・アルバイト先の職種(力仕事やコンパニオンなど)を勤務先単位で登録する。
・職種ごとにアバターが成長していく

【目的】
スケジュール帳として厳密なものではなく、ビジュアルで楽しめる、モチベーションが上がるアプリを目指す。「なんじゃこのアバター?」と思えるようなユルいキャラから変なキャラまで用意。

【メンバー】
・フロントエンドエンジニア…2名
・ビジュアル/UIデザイナー…1名
・キャラクターデザイナー……2名
・HTMLコーダー…………………4名(上記から3名が兼任)
・マネージャー…………………1名

▽いよいよ実装作業開始、想像以上にうまくいかない。。

いよいよ実装作業開始、想像以上にうまくいかない。。

というメンバーで、実はエンジニアがあと2人参加予定だったんですが、風邪と社員旅行で参加出来ず、タイムオーバーとなり、一部実装は持ち越し。

単純なアプリと思っていても、結構大変なコストがかかるという事に打ちのめされます。

▽シンプルな構成案でも矛盾が発生、議論はつづく…

シンプルな構成案でも矛盾が発生、議論はつづく...
▽休憩中に出来上がってきた遷移図のチェック

休憩中に出来上がってきた遷移図のチェック

あと数回の顔合わせをして完成するというスケジュールになります。

目指すところ

このプロジェクトを企画した目的は、僕らデザイナーが良いと思った色やレイアウトを、クライアントという「素人判断」に覆されないためにも、このチームで意図して出来上がったものの価値で、本当に良いものに理由を付けたいと思ったから。

「よいと思うものに言葉はいらない」という人もいるし、すごく分かるけど、ビジネスとしてお金をもらってデザインをする立場だったらそこには説得させる材料が必要。
僕らのハッカソンプロジェクトはそれを実現させて、参加したメンバーが将来本当の意味で良いデザイナーの仕事を続けられるように今から出来る事をしたい、そう思って作りました。

もう「上から仕様変更が…」といって、リリース前に中身のコードをツギハギにしてグチャグチャでも「なんとか動いた」の状態でリリースするような仕事をしなくてもいい将来を作りたいです。

デザインの「修正」に対して思う

fig01.jpg

今回は「デザイン修正」が起こった時の、デザイナーとクライアントとのコミュニケーションを考えてみました。

みなさんはクライアント、もしくは自分に仕事を発注するディレクターさんと、どんな意識の擦り合わせをしていますか?
例えば、ちょっと規模の大きいシステム開発の場合、「こんな風に動くものを作ってよ」と言われてすぐプログラムを組むデベロッパってそういないですよね。
実はシステム開発における予算の大半は「設計(要件定義を含む)」に当てられるほど重要なフローなんです。
つまりこの「設計」というフロー無しには、手を動かして作業出来ない(乱暴に言えば)ということです。
一般的なデザイナーの仕事にとって大変懸念すべき点があります。
それは「デザイナーのワークフローには設計や要件定義を行うフローをしないでデザインする事が多すぎる」んです。
今、とくにWeb制作の中で「デザイナーとデベロッパ」とまるで異次元の人種のようにぶった切られていますが、ホントにそうなんでしょうか?
僕はデザイナーですが、なぜ僕らは彼らデベロッパーのワークフローを踏襲出来ないんだろうか?と考えています。
「修正」
みなさんも好きな言葉ではないと思います。
何時間もかけて、あるいは一晩かけて最高のクオリティに仕上げたロゴやビジュアルを「イメージと違うんだよね」と言われて修正を食らう。
開発現場とデザイン現場にいた経験から、傾向としてはデザイン現場の要件定義フローは軽視されているようです。
【開発】
システム開発で後から修正を入れること自体プロジェクトを危険にさらすから最初にしっかり設計すること。
【デザイン】
上記の開発フローほど厳密に設計などを行わない傾向が高く、デザインの変更は後からでもなんとかなる、と思われがち。

システム設計ばりの「デザインの要件定義」をすること

「まあ、ちゃっちゃっと作ってみてよ」なんて言う人とは仕事はしないです。
少なくとも、デザインをアタマの中でイメージ出来る人はいいのですが、少なくともそんな人から来る仕事は割とスムーズに行くケースがあるので、打ち合わせ段階でコンセンサスを得やすいのです。
ただし問題は「何案か見てみたい」と言われた時のこと。
ほとんどが複数案を提案します。
ただし、今回問題としているのは、打ち合わせ段階でどれだけイメージが集約された複数案なのか?
それともただ、イメージが全然沸かないから、という理由の複数案なのか?
これの大きな違いが、最終的にクオリティやデザイナーの評価を落とす原因にまで発展します。

「何案か見てみたい」…この最悪のケースを想定する

発注者はこの時点で「キーカラーは何色にするのか」「ロゴのテイストはどうするのか」「ビジュアルは写真でいくのかイラストでいくのか」等といった具体的なイメージは出来ていません。
ここでそのまま持ち帰って多数案を提出した最悪のケースへの一歩がこれです。
「もっと別の案も見てみたい」
しかし、その背景(真実)はこういう事だったのです。
(案が多すぎて逆に決め切れなくなった)
つまり、集約するべきアイデアが分散してしまい、正常な判断が出来ない状況に陥った結果です。
こういった原因を作ってしまった張本人が僕らデザイナーだったりします。
そこにクライアントやディレクタの悪口を言うのは違います。
つまり提案が多ければいい、という段階はここで行うべきじゃなかった、ということです。
もっとそれ以前のコミュニケーション作業に答えがあります。

最悪のケースとは

こっちは一生懸命作ります、何案も。

でもその中の1つ以外はボツになり、ヒドい時はどれも決まらず全部ボツになる。
それが分かっている中で、全力を注ぐのは苦しい。
さらに多くの案に時間をかけると、一つ一つの案のクオリティを保つのは至難の業です。 
出来るだけ細部のクオリティに配慮できる時間や気持ちのゆとりが欲しいです。 
これがないと、別に手を抜いているつもりはなくても配慮に対する行動が手薄になりがちです。 
そう、自分が気づかないうちに。
僕はそれを「デザインに若さがない」という。 
若さというのは若者受けという意味ではなく、「あ、精神的に元気がいい状態でデザインしたな」という感じがつたわる空気みたいなものです。 
要は無駄が多いと、言葉では「頑張ってます」でも、クオリティは落ちるのです。 
メカじゃないから人間疲れます、色んな感性が疲れます。 
だから細部に行き届かない。 
だから無駄をすると、自分のクオリティ評価が下がるし、クライアントも幸せになったかというと疑問だし。
死ぬほど徹夜もして疲労困憊な中、努力したのに、クオリティも出せず、最後までデザインもまとまらず評価は最悪、、つまりこれが最悪のケース。

だからもっともっと相手とコミュニケーションをとるんです。

相思相愛の関係で生まれる不思議なコンセンサス

会話の中で、その人が好きなことや気になっていることをすくいあげて、会話の中に弾ませると、相手はもっと自分に興味を示してくれる。
お互い疑心暗鬼になっている状態だと、どちらかがいい案を出しても、ちょっと疑いたくなるのは心情。 
でも、好きになってくると、その人の意見をさらに膨らましてやろうじゃないか!という意欲すら沸いてきます。 
不思議です、今までそういうことが何度もありました。 
そうすると、ここで一旦まとめましょうよ、って場を仕切りやすくなるんです。 
クライアントの前でも「無駄がないように短期間で最高のものを仕上げさせてください」って意思表示が出来る空気にさせてしまうんです。 
無駄、という本質を理解してもらうのもデザイナーのコミュニケーション能力として大事なことです。 
決して楽をするためじゃなく、この仕事に愛情を注げる状態を僕に下さい、と言ってるようなものですからクライアントも徐々に信用してくる。 
そうすると、もう何案も「闇雲」に作るんじゃなく、「自分でも数案試してみたいんですよ」という状態まで持って来れる。
その数案はとても価値があるチャレンジだと思っています。

クライアントにコンセンサスを得るまで手は動かさない

この小見出しが全ての答えなんですが、案をいくつか出すにしてもプロジェクトコンセプトに対して理解するまでは絶対に手は動かさない(要はPCでデザイン作業をしない)ようにします。
理由はたった1つ。
的外れな案に労力をさくより、適案に最大限の時間をかけ、クオリティと「若さ」を全力で注ぐべきだから。
これにおける行動は重要ですが、ある意味、精神/体力勝負ともいえます。
これはクライアントに対し可能な限り要求を聞き出し、自分は持ってるだけのアイデアの引き出しをその場で広げます。
そこで的外れな案を相手に指示させないようにするには、こちらからのそれを覆すだけの理由が必要です。
がしかし、これは「知識」だけ突きつけてもダメな場合があります。
人を引きつける話術で覆すことも時として必要なんです。
しかも人間、フリスクの過去のCMのように、会議が長引くと思考が切れてモチベーションも下がるので、これらを出来るだけ短期間で行います。
そうでないと、余計な疲労が思考を妨げるから、良案もそう見えなくなってくる危険だってあるのです。
ここまで徹底的にやり切ってそこから数案を考える、という話に持っていくことが重要です。
何案か出す時には、より、その案が絞り込まれた中での案なのか、を打ち合わせ段階で明確にしましょう。
ちなみにクライアントにとっては、場合によっては非常に面倒くさがられることがあります。
「そんなことより早く作って見せてよ」というのが本音だからです。
ただし、ここを怠るともうすでに、システム開発では当然の「要件定義」を放棄しているようなもので、今までの経験からすると、こういったケースは最終的に「クオリティに全力を注げなかった残念なケース」に近づいていきます。
クライアントから気に入られたいがために、夜を徹して体力限界まで多数の案を製造してしまいがち。
しかもその状態で求められるクオリティはほぼ「完成形」に近いほどのクオリティだったりするのがほとんど。
fig02.jpg
若い頃から長く経験して思いますが、
精神状態や体力が良好なときに仕上がるデザインと、劣悪な状況で仕上がるデザインのクオリティを両者均等に保てる人なんてまずいません。
人間、クリエイティブとか感性とかを思考する行為って、単純ではありません。
もっとデリケートなもので、「強くなれ」とかいう概念とは次元が異なります。
クオリティは自身の様々な状況に影響します、それも自分が気づかないところで。

理想と現実

色々書いてきましたが、結局「そんな事言っても現実はそうはいかない」と反感を持たれる人もいると思います。
その通りで、場合によっては面倒くさがられて次から仕事が来なくなります。
自分がデザイナーとしてどう生きていきたいか?という大きなテーマに発展しうる問題です。
「やっぱりこの人にお願いしたい」
「この人にお願いするとちょっと高いけど、それでもいいものを作ってくれる」
「この人にお願いする場合、発注する側も刺激になっていいよね」
そんな風に思われるデザイナーになり、今後も高く評価されながら頼りにされることを目指したい。
そう思うなら、手先が器用なだけでなく、コミュニケーションを放棄しないデザイナーであり続ける事だ、と考えます。
話が戻るけど、システム案件の「設計」が必要なように、僕たちデザイナーもイメージの設計というフローが必要です。
そして業界全体のフローを自分自身で変えていければ、僕らの未来もきっと良いものになるでしょう。