ADC OnAir シーズン 2 第 1 回のこぼれ話

上は、最初に小川さんからいただいた資料のワークフローです。プロトタイプのフェーズでは、Bootstrap 等のフレームワークを用いて開発する、するとコードをそのまま実装フェーズで利用できるというのがポイントの 1 つです。

プロトタイプは実際のコードを使って開発するので、デザインの確認をするにもコードを書くことになります。それだと、デザインとコーディングの両方できる人でないと現実的にまわせないのでは ? というのが気になって、同じプロセスの繰り返しでも、最初はデザインの確認の比重が大きくなるという考え方では行けませんか ? と質問したところ、実際それに近いです、ということで、本番で紹介したワークフローの図になりました。

こちらだと、最初のループでは、デザイナー主導でデザインの確認を繰り返す、というオプションも見えてきます。1 人でいろいろできてしまう小川さんの様な人には、むしろ区別すると効率が悪くなるのだと思われますが、それでも、プロトタイプを使って確認する対象が、ユーザ目線からの仕様と、開発者目線からの仕様の 2 種類あることを意識しておくのは有用だと思います。

いつまで繰り返すのか？という話

レスポンシブデザインでは、少しずつ確かめながら実装を繰り返すのが現実的だ、というのが番組での一致した見解でした。その主な理由が、実際にテストしてみないと分からないことが少なくない、しかし、全ての環境で問題の無いものを作るのは難しい、という話になったとき、ちょっと番組がおやっ ？ という雰囲気になりました。

Twitter からも経済面に関する質問があったように、確かに、これだと、どのくらい繰り返し作業を行えば良いのか ? に加え、そもそもどこまでできたら良いことにするのか ？ も不確かな状態で見積もりをすることになります。

この問題に対しては、いきなり、複雑なサイトをレスポンシブデザインで実現するのは避けて、ごく簡単なサイトから初めて、どの程度難しいのかという感覚をつかみながら、だんだんと複雑なサイトに挑戦していくのが 1 つの対処法になるかもしれません。そしてある程度実績や経験が積み重なって、こういう風に作れば問題が少ない、とか、だいたい世間はこの辺りで良いことにしているらしい、という情報が一般的に共有されるようになれば、状況は改善されてきそうです。

また、制作環境もだんだんと整ってくるはずです。ということで次の話題は、Edge Reflow です。

Edge Refllow

何のためのツールか ? という話

Edge Reflow のそもそもの始まりについては、昨年 10 月 6 日に開催された "Create the Web Tour" の際に、製品マネージャの Jacobs から紹介されています。（こちらにビデオが公開されています）

それによると、レスポンシブ、つまりステージサイズが可変であるデザインは、既存のデザインツール （固定されたスクリーンに正確なデザインをするためのツール） では扱うことが難しい。最初からレスポンシブデザインを前提として設計された新しいデザインツールの必要性を感じていた。のが出発点とのことです。

そして、その際に鍵となったコンセプトが、"CSS をヴィジュアル表現をコミュニケーションするための 「言語」 として捉える"、という考えだったということでした。その 「言語」 の表現するものを視覚的に表すためのツールとして作られたのが Edge Reflow というわけです。 （なので、Edge Reflow を使うと 「CSS ではここまでならできるんですよー」 というような会話がしやすいのは当然な訳です）

ということで、Edge Reflow が内部的に HTML/CSS を利用しているのは必然と言えるでしょう。

が、それはツールを作る側の都合として選択された手段です。サイトを制作する側としては、せっかく内部的には HTML コードを生成しているのだから、それを開発に利用したいと思うのは当然だとは思いますが、とりあえず、現在の位置づけは、"CSS が表現できること" を人に伝えるためのツールと考えておくのがよさそうです。 （レスポンシブデザインを含め）

プロトタイブとは何か ? という話

Edge Reflow の登場により、2 つ目の図に出てきたワークフローでは、2 つのループのうち、1 つ目は （コーディングの得意でない） デザイナーが Edge Reflow でできるところまで行い、2 つ目はデザインもコーディングもできる人が行う、という分業の可能性が見えてきます。相変わらず後半になると 1 人 2 役ができる人が求められますが、ワークフローとしての柔軟性は向上しそうです。

その際、それぞれのループでつくられるプロトタイプは、若干性質が異なりそうです。１ つ目のループでつくられるプロトタイプは見た目や使い勝手の確認ができればよしかもしれませんし、２ つ目のループでつくられるプロトタイプは、そのまま実装に使えないなら価値がないと言われてしまうかもしれません。

ということで、レスポンシブデザインのワークフローを詳細に語る場合は、プロトタイプ的なものを一括りにすると、明確に記述することが難しいケースが見つかりました。「何を繰り返すのか ？」 の最後に書いたように、何を検証するためのプロトタイプなのか、という点をはっきりとさせるのは大事な点と言えそうです。

Edge Code & Brackets

レスポンシブ開発者の立場は ? という話

レスポンシブデザインの実装方法として、最近良く聞かれるようになった言葉が、小川さんも紹介されていた "Designing in the browser" です。実際の動作を確認しながらデザインを実装できるのがとても魅力的な手法です。しかし、デザインの不得意な開発者が取り組んだ場合、かえって使いにくいものになってしまうこともあるかもしれません。

画面がレスポンシブになっても、やはり、デザイナーと開発者の連携は重要な場面はありそうです。その場合、開発者に期待される役割は、プロトタイプ開発や実装を効率的に行うことだろうと想像されます。

という理由で、番組では Edge Code のベースとなっている、オープンソースプロジェクトの　 Brackets のライブ開発機能をご紹介しました。この機能を使えば、エディタ内での修正の結果をリアルタイムにブラウザ内で確認できるだけでなく、ブラウザ内のテキストを直接編集したり、ブラウザ内の要素に適用されているスタイルのリストを表示して、そこからエディタ内の、選択したスタイルが定義されている行へとジャンプすることもできます。 （まだまだ開発中の機能ですが）

この機能が正式に利用可能になれば、エディタでコーディングしてブラウザでテスト、と比べ、随分と楽になりそうです。

分業制の場合のワークフローは ? という話

これまでに出てきたワークフローは、デザインとコーディングの両方を、多少なりともできる人を要求するタイプのものでした。デザインだけ、コーディングだけ、という立場の人だけでレスポンシブデザインに取り組むにはどのようなワークフローが考えられるでしょうか。

たとえば、1 つの案としては、

• デザイナ：「画面仕様 → Edge Reflow を使ったプロトタイプ → スタイルガイド」 を繰り返す
• 開発者：「機能仕様 → 実際のコードを使ったプロトタイプ → 実装」 を繰り返す

の 2 つのループを平行して進めるという考え方がありそうです。といっても、これは私が考えたわけではなくて、システム開発の世界でアジャイルを採用する時、しばしば用いられるアプローチです。

とはいえ、Edge Reflow が登場することで、やっとレスポンシブデザインでも現実的に議論ができるようになったアプローチです。

（改めて） Edge Reflow 今後は ? の話

これまでいくつかのワークフローが登場しました。

例えば、1 人で 2 役こなせる人、"Designing in the browser" を実践する人は、Edge Reflow に対して、実装に使える HTML を出力できるようになって欲しいとか、よく使われるフレームワークに対応して欲しい、という期待を持つのではないかと思います。

一方、デザインのみを行う立場で、先述の分業制のワークフローに参加する人は、CSS 書き出しや、スタイルガイドの生成機能などを期待するのではないでしょうか。

とすると、今後 Edge Reflow が進む方向性は、世の中のレスポンシブデザインのワークフローがどうなるかに大きく左右されそうです。ということで、無事、番組のメインテーマに戻りました。