catch

Web制作フローの再考とDesigning in the browser

多様化するwebサイト、増加するデバイスに適応していくために今までのWeb制作のワークフローも見直す必要があるのではないでしょうか。またその一つの手法としてDesigning in Browserについて書きました。

Web制作フローの再考

現在ではWebサイトも、インタラクティブなサイト、アプリのようなサイト、可変するサイトなど様々なスタイルが見られるようになってます。
また、Webを閲覧できる環境もPCからスマートフォン、タブレット、テレビ、カーナビなど増加し続けてます。
それに伴い今まで以上にテストケースが増えてきてます。
今までのような静的なデザインを作ってから開発、テストというWeb制作のワークフローでこの変化の流れに対応できてるのでしょうか。

今までの制作フロー

まず静的なデザインはあくまでこのように見えるという仮説であり、
解像度やスクリーンサイズが異なれば見え方も変わってきます。
更にどのように動くのかまでは表現できれません。
また従来のワークフローではテスト段階で不具合が見つかると、場合によってはデザインからやり直さなければならなくなり非効率的です。

デザイン・開発・テストを同時に進行することでこれからはより効率的に安全に制作を進められるのではないでしょうか。

こらからの制作ワークフロー

Designing in the browser

(※Designing in the browserの内容はSwapSkills doubbble vol.05斎藤 祐也さんの話を参考にさせて頂きました)

デザイン・開発・テストを同時に進行するための一つの方法がDesiginig in the browserです。
Photoshopなどのグラフィックソフトで静的なデザインをするのではなく、直接ブラウザでデザインしていきます。

例えば下記のようなものであれば数十分で作れます。
ミニマル・シンプルなサイトであればもう少し時間をかければほぼデザインできるでしょう。

注意点

Photoshopが不要になるということではありません。
あとでも述べますが画像を使わずにできることはまだまだ限られていますし、
クオリティの高い素材・質感や、表現方法を実現するのにPhotoshopのようなグラフィックソフトが必要です。
今の段階では「デザインを直接ブラウザで行う」と言うよりは、「開発・テストを早い段階で試せる」ことの意味合いの方が強いと思います。
言葉の概念に捕らわれずに一つの方法として柔軟に取り入れるのもまた大事なことでしょう。

Designing in the browserが向いてるケース

Webアプリ・Webサービス
早い段階でテストができる
レスポンシブデザイン
各ブレークポイント間の表示は静的なラフでは予測できない
パララックス効果など動きのあるサイト
動きを早い段階でテストできる。また静的なラフでは動きが伝わらない
ミニマルなサイト
CSS3のみでもデザインが可能

Designing in the browserが向いてないケース

LPやビジュアル重視のサイト
大部分をグラフィックソフトで作る必要があり、そのイメージを共有する必要がある
想定するテストケースが少ない
閲覧するデバイスが決まってたりインタラクティブでない場合メリットは大きくない(※)

※それでもDesigining in browserで進めるほうが効率がいい場合もあります

Designing in the browser導入で抑えときたいポイント

グリッド

griddleIt

必ずしもグリッドレイアウトにしなければならない訳ではないですが、
グリッドを使ってデザインすることで整ったレイアウトを素早く構築できます。

Griddle.itを利用すると、
下記のような記述で簡単に背景にグリッドを表示できます。

			body {
			  background: url(http://griddle.it/1120-12-20) repeat-y center top;
			}
			

この場合は全体が960px、12カラム、カラム間30pxでグリッドが表示されます。
同様にBasehold.itを利用するとベースラインを表示させることができます。

関連サイト

Website layout made easy | Griddle.it
Basehold.it – quick, painless, javascript-free baseline overlays

CSS3

ブラウザ上でデザインを行うのにCSS3は欠かせません。
角丸、グラデーション、ドロップシャドウなどの表現がCSSのみでできます。

LESSやSassなどのCSS拡張メタ言語

less

CSSで変数やMixinなどが使えるので作業が捗ります。
例えば下記のように角丸を半径を指定して簡単に作れます。

			/*Mixin*/
			.border-radius( @radius: 3px ) {    
				-webkit-border-radius: @radius;    
				-moz-border-radius: @radius;    
				border-radius: @radius; 
			}
			#hoge{
				.border-radius(5px); /*()内の数値で角丸が作成される*/
			}
			

僕はLESSを使ってるので、
デザイン中はjavascriptでクライアントサイドで処理して、最終的にはcssにコンパイルしてます。

関連サイト

LESS « The Dynamic Stylesheet language
ASCII.jp:CSSの記述が3倍速くなる「LESS」の使い方
【Sassを覚えよう!】もくじ的なのと参考リンク – CSS HappyLife

Developer Tools

developer tool

殆どのモダンブラウザには何かしらのDeveloper toolが備わってます。
変更が即座にブラウザに反映されるので、ちょっとした変更を確認する時や動作の確認を調べる時に役立ちます。

スニペット(パターン)のストック

bootstrap

WebのUIには幾つかの決まったパターンが存在します。
そのような共通なパターンはストックしておくと素早く構築ができます。

同様に配色のパターンも複数用意しておくと便利です。
この辺りはTwitter BootstrapjQuery UI – ThemeRollerが参考になると思います。

関連サイト

Twitter Bootstrap
jQuery UI – ThemeRoller

Web Fonts

typekit

テキストのフォントを変更できます。
またアイコンフォントを使用するとフォントのみでアイコンの表示もできます。
日本語のWeb Fontは数が少なかったり、全部読み込むとデータ量が多いなどまだ課題が多いですが、
ここが解決するとグッと表現の幅が広がると思います。

関連サイト

Typekit
Google Web Fonts
Fontdeck web fonts: Real fonts for your website
画像アイコンはもう古い!CSSでスタイル自由自在のアイコンWebフォントまとめ5つ

Designing in the browserのメリット

早めにテストが行える

全てを作りこんでからテストした結果、バグが見つかって修正となると、
最悪の場合デザインから手直しするケースもあります。
そこを早めに知って対応できるのは効率的であり、また安全でもあります。

時間の短縮

グラフィックソフトでのデザイン工程がなくなる(少なくなる)ので時間の短縮に繋がります。

変更が容易

CSSの記述を少し変えるだけでレイアウトの変更が簡単に行えます。
特にLESSやSassでCSSを書いてると、文字や色の変更も変数一つ変えるだけでできてしまう場合もあります。

ラフと成果物の相違が無い

デザインを最終的な成果物のプラットフォームであるブラウザ上で行うため、そこで作られたデザインと成果物が違うということがありません。

Designing in the browserのデメリット

周りの理解が必要

一人で全てを行うのであれば柔軟に制作フローを変更できますが、
複数人で行う場合は全員の理解が必要です。
また、新しい手法なので予期しない事態が生じる可能性もあります。
慣れるまでは余計に時間がかかる場合もあります。
故に保守的な体制では受け入れられないこともあるかと思います。

もうひとつがクライアントです。
今までの制作フローを当然と思ってるクライアントは、まず静的なデザインを要求してくるかも知れません。
「このような流れで制作を行う」と事前の告知は必要でしょう。

デザインの限界

CSS3になってできることが増えたといっても、まだまだPhotoshopなどの表現には追いつきません。
ミニマル・シンプルなデザインであれば十分対応できますが、
デザイン性の高いサイトでは力不足です。

古いブラウザに対応させるか

IE8以前などの古いブラウザは多くのCSS3プロパティに対応していません。
そのような場合はJavascriptで対応させるか、プログレッシブ・エンハンスメントの考えで必要な情報が伝われば良しとするか検討して制作する必要があります。

最後に

このブログをリニューアルする時にも静的なデザインを飛ばして直接ブラウザでデザインしようと考えましたが、
各ブレークポイントのイメージを形として見たかったので結局Photoshopでデザインを作ってしまいました。
結果、コーディングしてから何度かデザインの微調整をするハメになりました。
トータルで考えると早めにテストしてた方が早くできたと思います。

Photoshopでのデザインに慣れてるデザイナーはいきなりDesigning in Browserへの移行は難しいと思います。
慣れた作業はやり易いですし、それを変えるのは抵抗も感じます。

それでも従来の制作フローを再考する時期にきてるとは思いますので、
(Desiging in the browserがそれの解になるかはまだ分かりませんが)
常に最適な制作フローを模索しながら一つ一つの案件に関わっていこうと思います。

参考サイト

インブラウザ デザイン | CSS Radar |
24 ways: Make Your Mockup in Markup
12 Killer Tips for Designing in the Browser | Design Shack

Add Comment

本文

  1. [...] Web制作フローの再考とDesigning in the browser │ Design Spice. カテゴリー: うぇぶでざいん   作成者: ootake パーマリンク [...]

  2. [...] Web制作フローの再考とDesigning in the browser http://design-spice.com/2012/06/29/designing-in-the-browser/ [...]

PAGE TOP