Grad3の背景色を変えられるようにしました

grad3_bgchange.jpg

2012年3月にリリースしたHTMLベースでつくられたWebデザインのためのWebアプリケーションであるGrad3 – Easy CSS3 gradient editor -(http://grad3.ecoloniq.jp/)ですが、色々と使ってくれてありがとう、を言いたいわけでもあるんだけど、こんな要望がありました。
  • 背景色を黒でわかりにくいので白にできるようにしてほしい
  • ベンダープリフィックスを追加するブラウザボタンを一括解除できるようにしてほしい
という声にお応えして、改善しました。
背景色の件はつまり、背景が黒いとつくりたいWebサイトの背景が白い場合に色の差が大きくて、プレビューしながらつくり込んでも参考にならないことがあると思い、これは私もちょっといかんな、と思っていました。
ある程度の決め打ちの背景色を用意しましたので、アナタのつくりたいWebサイトの背景色にあわせてGrad3を使って自然なCSS3のボタンをつくってください。
あともうひとつ、ベンダープリフィックスボタンですが、altキーを押しながらクリックしてみてください。
クリックされたベンダープリフィックス以外は解除になります。
Photoshopのレイヤーのaltクリックと同じ機能を採用しました。
今後はボタンサンプルを増やしたいと思います。
それではこれからもどうぞ、素敵なデザインを!

家電のインターフェイスを僕ら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
若い頃から長く経験して思いますが、
精神状態や体力が良好なときに仕上がるデザインと、劣悪な状況で仕上がるデザインのクオリティを両者均等に保てる人なんてまずいません。
人間、クリエイティブとか感性とかを思考する行為って、単純ではありません。
もっとデリケートなもので、「強くなれ」とかいう概念とは次元が異なります。
クオリティは自身の様々な状況に影響します、それも自分が気づかないところで。

理想と現実

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

『第一回 全国統一HTML5実力テスト』を受験してみて改めて感じたこと

カヤックさんのWebサービスで、HTML5関連の自己スキルが試せるというものが公開されています。
html5cat.png
これはエンジニア向けのJavaScriptコース、そしてデザイナー向けのHTML / CSSコースの二つの科目(?)があり、それぞれ好きな方を選べるし、両方受験することもできます。
まあ、内容はもちろんここでは書けないけど、結構難しいことから、割と誰でも知ってそうなことまで幅広いので、自分のスキルを試すということで、やってみてはいかがでしょう?
高い点数だったら、みんなに自慢しちゃおう、ということでTwitterのアカウントでログインして受験してみるのもよいでしょう。
逆に点数が低いからといって、一方的に公開されるわけではありませんのでご安心を。
ちなみに僕はJavaScriptは専門外なので、HTML / CSSコースだけ受験。
惜しくも93点。
一問間違えてしまいました。。
よく考えたら分かることを、、、悔やんでしまいます。
score.png
HTML5がテーマとなる試験なので、セマンティックな考え方を理解しておいた方がよいですし、CSS3の知識も必要になってきますし、JavaScript APIとの絡みも理解が必要になってきます。
と、書くと、「何でJavaScript APIとの絡みが必要なん?」って思うかもしれません。
しかしこれは僕としては当たり前のことと思い、苦手だけど勉強中です。
(オライリーから出ているJavaScriptのパターン本を読んで、確かに面白いですが、これは僕がやる分野じゃないな、と思っています。)
ただプロジェクトって、制作に関わる人全てが同じゴールを見ないとチグハグなものが出来上がってくるのにこの日本ってのは、フロントに関わる大事な作業をする人がディレクターからの指示だけで動いているという現状があまりにも多く、ヒドい場合には途中で大幅な仕様変更などに何故そうなったかも理解出来ず、苦しむ場合があります。
「上が言ってるからそれは当たり前」とか「徹夜してでもやるべき」とかそんな言う人もいるけど、もの作りの本質からは確実にずれている気がします。
ただ、大きなプロジェクトになれば(何十人、何百人のエンジニアが動くプロジェクト)になると、さすがにそうも行かないケースもあるので一概には言えませんが。
少なくとも数人体制で制作にかかる場合、もっとフロント制作に関わる人(フロントエンドエンジニアやデザイナー)も会議に参加させて、その人のことをちゃんと信用していこうよ。
フロントに関してはその人の意見が一番知識があるし、的を得ているはずなのに、何故違う人が仕様を決められるのか?は問題として認識しておくべきかな?と。
理想的な話ばかりしてるけど、制作者は全てコミュニケーション能力がないとダメ。
上記のように、フロントエンドの人やデザインの人などは、信用されている以上、プロジェクト全体のゴールを見据えて話が出来て提案も出来ないと、ただの言いなりにしかなれない存在なんです、悲しいかな。
だから僕らの立場を5年先、10年先でももっと価値のあるものにし、言いなりにならずに「この人にお願いしたい」と言われたいので、今が訓練の時期だと思う訳です。
だから話が戻るけど、デザイナーの知識にとって「何でJavaScript APIとの絡みが必要なん?」という答えは、自分が作ったUIと密接に関わるからです。
自分がUIを設計する以上、最後はプログラムによってどのように動くかなんて知っていて当然、その挙動が予測できるようにならないといけません。
少なくとも、スクリプトを書けなくても、何が出来るか?
ここを最初に設計/定義しておかないと後々困る、という部分だけは抑えておきましょう。
これが今後、複雑な仕様になって広大なHTML5の技術に対する、僕らデザイナーの向き合い方だと考えて勉強しています。
こう考えると、色んなスキルが必要となってくるので、ひと独りでこのスキルを理解出来る人なんていないんじゃないかと思ってきます。
JavaScriptエンジニアと言っても、今までDOM操作が得意だったエンジニアだけでなく、描画アプリをcanvasやSVGなどを使って作ることを得意とするエンジニアやAjaxやWebSocketなどの通信系が得意なエンジニアとか色々、エンジニアのなかでも幅広く分野が分かれていくものと予感しています。
これはあくまでディレクターとしての一つの意見ですが。
デザイナーもそうです。
ビジュアルを担当するデザイナーから、ユーザの指や目の動きを考えたり使いやすい設計を考えるデザイナーなど、デザイナーといってもWebに関わらずプロダクトやエディトリアルデザインの世界でもいっぱいいます。
どれがWebの世界で一番重要かだなんて順位をつけられるわけがありません。
見た目も機能性も、全てにおいてクオリティを保たないとそれをクオリティとは言わないからです。
さ、そんなわけで、コレからも勉強、勉強、と。
お互いいい仕事をしたいですね!

今度は段ボールのアイコンを何個か作ってみました

box_1.png
ビジュアルデザインやってる人なので、ってわけでもないけど続編。

前回のエントリーの続きになるんですが、僕がビジュアルデザインさせてもらった「CSS Nite in OSAKA」のサイトで使っているアイコン、あれも僕が作ったものなので、使えるかもしれない状態にしておきます。

これも前回と同じように、個人、商用関わらず、改変使用もOKなので良かったら使ってください。
あと、今更ですが、ブログのfacebookページを作りました。
よかったらいいねしてもらえたら嬉しいなあ、、、いまのとこ3人っ!(笑)
(右サイドの下にあります)
boxes.png
ダウンロードは下記からどうぞ
あと、イーゼルとカレンダーのアイコンも使えるかもしれませんので上記のzipに入れておきました。
よかったらどうぞ。
calender_easel.png

デザイナーズハッカソンで改めてデザイナーとして感じたこと

東広島にあるSHARPさんの事業所、というか自然に囲まれたビルの一室で行われたAndroidアプリ開発イベント(ハッカソン)に2日間かけて行って参りました。
ハッカソンとは開発をされているプログラマーさんが、限られた時間の中でアイデアを出し、アプリを作るイベントなんですが、デザイナーには全く疎遠なイメージがあります。
(個々がどう思うかはさておき、一般的にそういった意識が多いのは事実です)
しかし今回はSHARPさんや運営に携わっているブリリアントサービスさんのアイデアで、デザイナーもハッカソンに入ってもらい、一緒にアプリを開発してみよう、という試みということで参加させていただきました。
当日朝早く新幹線に乗って東広島駅へ、そこからみんなでタクシーに乗ってSHARPさんの施設に向かったわけですが、空気がうまい。
ホント、いいところでした。
今回は、SHARPさんにはAndroid2011年夏モデル端末も用意していただき、5つのチームにそれぞれ色んな実機が貸し出されました。
チームで朝11時30分からアイデア出しを行い、どんなアプリを作るか話し合いが始まりました。
ただここで重要だったな、と思うのが、「メインとなるテーマを先に決めてしまおう」というところ。
闇雲にどんなものを作るか考えると、メンバー4人、個々の考えも違うのでなかなかまとまりにくいパターンに陥るケースがよくあります。
今回はまず、「夏」というテーマに限定。
ここで色々出てきます。
海、山、キャンプ、水着、クラゲ、スイカ…
で、決まったのは、そうめん流し。
アプリのアイコンはこれ。
icon.png
(流しそうめんという人もいる、ちなみにこちら参照 http://www.freeml.com/wefree/say/noodles/
さてさて、ここで面白い実験をしてそうめん流しアプリを作ろうということで、
・複数台の端末を縦に並べる。
・1番目のデバイスをタップしたら、そうめんが流される。
・2番目のデバイスに1番目のそうめんが流れてくる。
・3番目のデバイスに2番目で取りそこねたそうめんが流れてくる。
・3番目で取りそこねたら4番目のデバイスに…
といったように、流れてきたそうめんを取る(箸ですくう)ゲームなんですが、
何台も実機をつなげられる所がポイントで、通信手段はBluetoothを使ったものです。
スクリーンショット(2011-07-25 13.19.27).png
プログラムの仕組みとしては最初の「親」となる実機の次の「子」が2番目になり、3番目の実機から見れば、2番目の実機が「親」となる認識方法で数珠つなぎが構成されます。
そうして、あるデバイスが「最後の子(つまり一番最後)」であると認識したら、画面の下に「受けザル」を表示して、最後でなかったら、そうめんを流す竹を上から下まで表示させるというものです。
いきなりですが完成はこちら、動画は英吉さん(@)撮影。

下記の写真は同じメンバー「AndroidSDK開発のレシピ」の著者の@gabuさん提供です。
【6台つなげてデモした写真】
【ちょっと拡大】
と、思ったら、gabuさんのブログ、その名も「gabuchanの日記」にてそのレポが紹介されています。
そんなわけで、USTREAMでもその様子が公開されています、
下記URLは、制作発表のものです。
(僕の発表は30:30くらいからです)
僕が主にチームの発表をスピーチさせていただきました。
普段はたまにソースコードも書きますが、「今回は一切ソースコードは書かず、デザインに専念します」と宣言した経緯もあって、チーム内、開発者3名、そしてデザイナーは僕1人という構成でした。
チーム名が「デラリアル」と言いまして、「デラ」は名古屋弁で「超」とか「すごい」という意味です、つまり「超リアル」。
まあ、リアルにそうめんが流れたらいいな、という想い、、、だったんでしょうね。
今回はAndroidのキャラクタ、ドロイドくんを、デラリアルにしました。
スタートアップの画面で活き活きとしたイメージの実写版(?)ドロイドくんが一生懸命そうめんをすくっている印象を与えたかったので。
(gabuさんのブログに画像が載ってます。)
そんな楽しくワクワクさせるデザインというのは、とても大事です。

開発にとってデザイナーの必要性

アプリはデザインによって売れ行きが変わるということは、色々とアプリを作られた方から聞きます。
僕の周りにはWebデザイナーというデザイナー職の方が多いのですが、どうもこういったデザインの目的には着目されにくいな、と感じています。
人間中心としたWebサイトの設計、ユーザエクスペリエンスなど、セミナーでは色々取り上げられます。
それはとても大事なのですが、アプリの開発という分野のみならず、デザインで人を「おおっ」と驚かせることが必要な場面だってあるわけだし、そこにはアナログな感性(アナログという言葉は正確ではないにせよ、そこは汲みとってください)が要求されるものだから、自分の感覚をとんがらせておかないとダメだと思うのです。
そういった表現で人の心を動かせるデザインが売上につながるのであれば、そこにその場面においては全力を注げるデザイナーでありたい、だってそれで僕はお金をもらって仕事してるわけだし。

あくまでデザインは人に評価される、機械と仕事をしてるわけじゃない

自分で作ったスタートアップの画面

アプリのスタートアップの画面は、購入を考えているユーザへの大きなアピール(勝負)の場。
ドロイドくんがそうめんを一生懸命つかんで食べてやるぜ!というサマを演出したく、デザインにとりかかりました。

概ねデザインは好評をいただきました。

今回、実はこだわった目的は「リアル」ではなく、ただひとつ、それは、、、

「これを見た人が有料でも買いたくなるアイコンとスタートアップのデザイン」

今回はこれにつきます。

つまり、デザインに理論づける人はいるし、それは分かるけどもっと大事なことは、自分が客観的目線で見て、そのデザインで人を引きつけられる感性を養って、表現するチカラがあるか?ということ。

その判断力と表現力は理論では片付けられない。

なぜなら今までの経験で案件ごと内容は全く違う、そのプロセス数は無限大でした。
これは20年間デザインという仕事をやって、ようやく今になってなんとなくわかりつつあります。

もちろん、自分に自信があって言ってるわけではありません。

本当に売れているアプリやインターフェイスのデザインを見ると、自分のは、まだまだ作っては疑い、作っては疑い、の繰り返しだと思ってやみません。

自分のチカラというのは、いつになっても色んな意味で完成しません。
常にまだまだな状態だな、ということを改めて気づきました。

さて、まとめ。
ハッカソンですが、名前の印象からどうしても僕らデザイナーさんは敬遠しがちです。
そういう意味では大変意義のあるイベントだったと思います。
開発者の方とのやり取りが学べるいい機会だったわけですが、いざ始まると時間が足りず、自分の作業だけで精一杯なことがあります。
これは「一日でマスターできる◯◯講座」とかあるけど、僕から言わせたら「一日でマスターできる講座なんてあるわけがない!」というのと一緒。
デザインは一日にしてならず、なんです。
デザイナーとデベロッパーのフローをどうやって理解するか、これは何回でも積み重ね、可能な限り参加して経験していくことで、徐々に「こういったケースだとこうしよう」がわかってくるもの。
例えばアイデアに対し、自分の出せる引き出しの少なさが原因じゃなかったか?
デザインのトライアンドエラーを繰り返す際、仕方がない(やってみないと本当にわからない)ケースと、事前に察知して余計なトライは回避できるケースもあると考えています。
両方ともとっさの判断が要求されるとき、人は経験によって乗り越えられる場合と無駄足を踏んでしまう場合があります。
僕はこの仕事を20年やってきた今でもデザイナーとしてのエラーを経験して、少しでも効率の良いワークフローを実現できるようになりたいと考えています。
(効率、というのは、よくあるツールに頼るとかそんなのではありません、もっと自分の脳を鍛えるという意味が近いです。)
色々と今の自分の実力を再認識できた2日間でした、
SHARPの方、Androidの会の方、参加されたみなさん、勉強になりました。
ありがとうございました!!

坂本貴史さんのIAシンキングセミナーに参加

坂本貴史さんのIAシンキングセミナーで使った用紙

坂本貴史さんのIAシンキングという本がリリースされたタイミングでこのセミナーに参加させてもらいました。

坂本さんは横文字をよく使う。本人もそう言われていました。

僕はあまり使わない方。
というより、スキルがない。

だから用語があまり分からないまま参加したけど、
用語の意味を知る事が目的じゃなく、目的さえ果たすことがこの勉強のゴールって思ってたのであんまり、出題された問題に対して出来なくても気にはならなかった。
(「出来なかった人」って言われて手を挙げたのは僕くらいだったよ、、、)
ノートもロクに取らなかった。
全然後悔はしてないどころかそのほうが集中出来るからだ。

目的とは?
サイトの情報を設計する?
いやいや、言葉ではそういうけど、、、、僕にはそれ自体がピンと来ない。

僕はクライアントの目的を果たすための手段のたった一部分に過ぎないWebって媒体を使って顧客を適切に誘導し、クライアントにメリットを与えるってことが出来ることが目的だし、そのためのデザインであり、HTMLってものはそのためにあるようなものだと考えて仕事させてもらってるので、今日は自分のためになったと思う。

ワークショップでは、家電メーカーのデジタルテレビのトップページを設計するという課題で、自分だったらテレビを売るサイトをどう設計するか?ある程度自由に考えていいというものだった。

僕が考えた企画は以下の通り。

【対象】
テレビはいっぱいある。
だからどれを選んで良いかわからない、買う気になってるのに、判断するスキルがない。
買って後悔しないテレビを買う、僕の購買という行動の背中を押してほしい。

【そのためのサイトの設計】
◎人気順ユーザレビュー
 たくさんあるテレビ、選ぶのに悩む。
 通常レビューというのは、批判的なコメントもレビューだが、「人気順」というタイトルをつけることで、ちょっとズルいけど、批判的なコメントは軽減出来る可能性がある。
 買った人がどう思ってるのかはこれから買う人のフラットな参考材料。

◎キレイな画面を他社製のテレビと比較できるコンテンツ
 実際に「超解像度」とうたっている割には素人にはピンと来ない。
だったら視覚で訴求したい。走査線が見えるレベルまで拡大した画像や動画を用いて、ここまでキレイに見えるテレビなんだってアピールしたい。
HTML5のvideo要素やFlash Videoでもいい、技術的には充分可能。

◎次世代テレビをマウスで疑似体験
 機能が増えると「使いこなせるのかな?」という不安が。
 そこで、Web上にテレビ画像を入れて、マウスで擬似的にリモコンを操作したりして、操作に慣れてもらう。要はシミュレーター。
 ブラビアとか、人が離れると電源が切れます、Webの疑似体験ではマウスが離れると画面が消える、とか。
 あと、操作方法は「ここを押してみましょう、録画を開始します」という音声ナビを入れて、マウスでテレビを操作させることで、簡単なトレーニングになるので、ウチのオカンみたいに、携帯メールすらろくに送れない人でも安心して購入の意思を持つ事が出来るんじゃないか?と。

そんな感じで汚い絵を書いたのが上の写真です。

企画自体は我ながら面白いと思ったんですが、目的は導線。
このままでは楽しんで終わり、になりそう。
だから自分の採点では50点くらい。購入まで誘導するにはもうちょっと訓練が必要かな?

人の心を揺さぶるということが出来るのはわくわくするのですが、今回は最終到達という 部分では自分のスキルに不満を憶えたけど、ユーザのメリットをクライアントのメリットに反映させるスキルとしていいキッカケになったかな?と思いました。

参加して良かったです。
ちなみに僕は、この作業、Webデザイナーと呼ばれる人の仕事だと勝手に思っています。
(つまり自分です)

サイト設計者の意思をデザイナーに適切に伝えることも仕事だって坂本さんは言ってたけど、それを言われた通りに作るデザイナーではなく、意思を汲み取ってビジュアルデザインすると、わずか1pxの違いにも「意思」を持ったビジュアルを構築できるデザイナーの仕事が出来る。

そこが本当の意味のWebデザイナーという仕事だと思う。
ここに行き着くには、コーディングのスキルではなく、ヒューマンスキルを要求されると考えられます。

一般ユーザはWebに満足することは求めていない。
Webを使って得たもの(今回は自分に合ったテレビ)を買うことが目的だ、ということを忘れてはいけないのです。

・・・と、勝手に思いました。