テレビ放送用のWeb標準規格言語
![]()
今後のWebにつながるデバイスとして

![]()


以前も記事に書いたデザイナー主体のハッカソンプロジェクト「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を入れてサブミット" >
とかするとお問い合わせフォームでも使えるので良いでしょう。
Designers Hackのフロントエンドエンジニアのメンバーと話していると、Android大丈夫?的な声が。。。
確かにiPhoneはレンダリングも強力なので割とフリックなど滑らかなんですが、GALAXY S2やXPERIA ARCなどで試したら結構厳しいところもあります。
クオリティを考えるとAndroidはもっと別のUIを考え、振り分けた方がいいのでは?という意見が続いています。
あと、このUIは今は横幅320pxとハードコーディングしてます。解像度のちがうAndroidではCSSを触らないといけなくなりそうです、というよりボツになりそうです。
例えばhtcとかの機種では横が空いてしまいますので。。。
これはもうちょっと改善できたらいいなと。
ただ、このようなUIの制作を色んな仲間の意見をもとに作れ、勉強しているって恵まれてるなあと感じます。
精進精進。
このあいだも、Googleのハッカソンに呼ばれて東京に行って思ったんですが、「知識が豊富なエンジニア達の中にデザイナーを投入してハッカソンを行おう」と、最近そんなことを企画するところが増えだしたな、という気がします。
しかし、企画側の理想は分かるんですが、今までのハッカソンの感覚でやるとまったく意味がないと感じています。
むしろデザイナーを投入するだけ時間の無駄とも言えます。
エンジニアの会話というのは、エンジニア同士でないとなかなか伝わりません。
だから、その場にデザイナーが入り込むと誰とも会話が出来なくなります。
ただし、アプリ全体の完成度を考えると、デザイナーという分野の力は欠かせません。
なぜなら、単に動くだけでは、コンシューマにとって魅力を感じないからです。

まず、アイデアソン(アイデアを話し合う)に完成のイメージを明確にしないとデザインは出来ません。
つまり、そのフェーズを踏まない以上、「デザイナーハッカソンは不可能」と考えて下さい。
では、そのアイデアソンのフェーズなんですが
さらに、「これは守りましょう」というルールを設けるのもいいでしょう。
・アイデアが出来ないうちに、誰かひとりでもコードを書き始めるとNG(多少の検証はしょうがないとして)
・エンジニアもチーム内すべてが、デザイン面のアイデアソンに加わること
実際の仕事(案件)でも最低限これだけはないと、デザイナーが動けません。
むしろ、将来の私達の業界は、手を動かす人(デザインする人だろうがコードを書く人だろうが)すべてプロジェクトのゴールを明確に見据えるために、発案から参加するスタイルがどんどん必要とされています。
すでにシリコンバレーなど、先進的なITの現場では、このスタイルを導入しています。
「指示が降ってくる」なんて言葉は過去の言葉になるのでしょう。
つまり、この流れを実際にハッカソンで行う事が、私達の制作現場の将来のスタイルを想定しているわけで、私達が5年後、10年後、もっと周囲からの評価が高い仕事を続けていくためには、いまからこのコミュニケーションという難題に触れ、経験し、可能であればその問題解決のすべを自分なりの方法で得なければなりません。
簡単に考えている人は、やってみるときっと頭を打たれるほどの難しさを肌で感じる事でしょう。
とてもシンプルなWebアプリケーションを作るだけでも、リリースまで想定するのであればなんらかの「設計上のデバッグ」が必要となります。
当初のやりとりでうまくいくと想定しても、一つの仕様変更で次々と連鎖的にやり直しとなるでしょう。
でも、ここで見つかったバグをつぶさないと進めてはいけないので、とても進まない事にジレンマを感じます。
デザインのアイデアから設計にいたるまで、チーム全員が参加する必要があるのはそういった理由があるからです。
徹底すると質の高いイベントとなるでしょう。
実はハッカソンに参加したデザイナーの力作が、アプリに反映出来なかったらとても残念な気持ちになり、その気持ちがチームのみんなに伝わらないのは余計つらいんです。
こういった経緯があって、「じゃあ、自分達で企画しよう」ということになりました。
先日和歌山の和歌浦アートキューブに泊まりがけで合宿を行ってきたんですが、これがとても良かったです。

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

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

iPhoneのSafariで動くことを想定したWebアプリです。最終的にはAndroidでも使えるようにしたいと考えています。
【アプリの概要】
・アルバイトのスケジュールをカレンダーに記帳できる。
・複数のバイト先を新規登録/管理でき、次からスケジュールを記帳しやすいようにする。
・アルバイト先の職種(力仕事やコンパニオンなど)を勤務先単位で登録する。
・職種ごとにアバターが成長していく
【目的】
スケジュール帳として厳密なものではなく、ビジュアルで楽しめる、モチベーションが上がるアプリを目指す。「なんじゃこのアバター?」と思えるようなユルいキャラから変なキャラまで用意。
【メンバー】
・フロントエンドエンジニア...2名
・ビジュアル/UIデザイナー...1名
・キャラクターデザイナー......2名
・HTMLコーダー.....................4名(上記から3名が兼任)
・マネージャー.....................1名

というメンバーで、実はエンジニアがあと2人参加予定だったんですが、風邪と社員旅行で参加出来ず、タイムオーバーとなり、一部実装は持ち越し。
単純なアプリと思っていても、結構大変なコストがかかるという事に打ちのめされます。


あと数回の顔合わせをして完成するというスケジュールになります。
このプロジェクトを企画した目的は、僕らデザイナーが良いと思った色やレイアウトを、クライアントという「素人判断」に覆されないためにも、このチームで意図して出来上がったものの価値で、本当に良いものに理由を付けたいと思ったから。
「よいと思うものに言葉はいらない」という人もいるし、すごく分かるけど、ビジネスとしてお金をもらってデザインをする立場だったらそこには説得させる材料が必要。
僕らのハッカソンプロジェクトはそれを実現させて、参加したメンバーが将来本当の意味で良いデザイナーの仕事を続けられるように今から出来る事をしたい、そう思って作りました。
もう「上から仕様変更が...」といって、リリース前に中身のコードをツギハギにしてグチャグチャでも「なんとか動いた」の状態でリリースするような仕事をしなくてもいい将来を作りたいです。



