第2回コーディングコンテストに応募しました
ちょっと前の話なのですが、CSS Nite LP9の連動企画「第2回コーディングコンテスト」に応募しました。（既に応募は締切られています）
去年に案件としてHTML5とCSS3で作ったことはあったのですが、一般公開するサイトでしたのでIE6などの後方互換を考慮する必要があり、新機能をふんだんに使った構築！というわけにはいきませんでした。ですが、今回はターゲットブラウザがSafari4とFirefox3.6と限定されたものだったので、アドバンスな仕様をフルに盛り込めると思い、腕試しもかねて応募してみました。
課題内容などの詳細は第2回コーディングコンテストの公式サイトを参照してください。
作っていて気付いたこと
今までは画像で切り出していた視覚効果をドロップシャドウやグラデーションなどのプロパティでロジカルに組み立てる必要があります。複雑に入り組んだPhotoshopレイヤーのエフェクトを数字で拾っていかないといけないので、マークアップエンジニアやコーダーといえどもPhotoshopのオペレーションに慣れていないと却って時間がかかってしまいます。また、Fireworks派の方もPSDでカンプがくるとメイクデータに合わせてPhotoshopを使わないとCSS3のアドバンスは活かすことができないように思います（逆も同じ）。レイヤーが統合されていた場合も、モノによってはグラフィックデザイナーの方にレイヤーが保持された状態のデータをもらわないといけないかもしれません。
Photoshopでグラフィックを作り込むデザイナーの方も、マークアップ＆スタイリング行程をスムーズに進めるため、レイヤー構造は分かりやすく、ノイズレイヤーを排除してカンプを完成させる必要があるようです。（デキるデザイナーの方にとってはもはや常識なのかもしれませんが）
HTML5について
正直いってフロントエンドにそれほどインパクトはないような気がします。恐れる必要はありません。セマンティク要素やアウトラインロジックなど、新しく気をつけるべきものはありますが、今のところ、クセあって悩ましげなものはないように思えます。（といいつつも私の作品は抜けていたところがあったのですが・・・）
CSS3について
ドロップシャドウ・角丸・グラデーション・複数の背景画像・ボックスディスプレイなどなど、新しくできることがたくさんあります。Photoshopとにらめっこする時間が増えてしまいますが、これも慣れの問題のような気がします。基本的なテクニックについては既にネットに情報がたくさんあるのでそちらを参考にしていただいたほうがよいかと思いますので、ここでは私が作っていて発見だったポイントを以下にあげます。
- 複数背景は最初に指定したほうがレイヤーが上
- -moz-box-shadowは複数指定できる。また、"inset"指定で内側につけることもできる。（-webkit-box-shadowでは無理っぽい）
例）外側に3pxのグローと内側に5pxのインナーシャドウをつける
-moz-box-shadow:0 0 3px rgba(109,195,212,0.58),inset 0 0 5px rgba(0,0,0,0.43);
shadow boxing with -moz-box-shadow | fredericiana
- グラデーション（gradient）で背景色を指定すると、背景画像が置けなくなる（同じ要素内でグラデーションの上にアイコンを置くことができない。別要素でラップして、セレクタを分ける必要がある）
他の参加者の作品
こちらでアグリゲートされています。
第2回コーディングコンテストが締め切りになりました＋ソースコードやメモを公開いただいたブログのご紹介
締め切り後は公開OKとのことで、ソース一式をさらしている方も。すばらしい作品が多く、自分のコードがゴミのように思えてしまいましたｗ
- :before :after などの疑似セレクタを使えば無駄なdivなどがもっと減る。文書構造とデザインのdivineが加速する
- 高さの違うマルチカラムの高さをそろえるには display:box がベストソリューション（私は気付かずdisplay:table-cell とか使ってました・・・）
- time要素を使って日時をマークアップ
- HTML5からはa要素でブロック要素をラップしてもOK
参加された方のソースやブログエントリは、HTML5とCSS3のノウハウがたくさん詰まっています！これだけでもこのコンテストが行われた意味は見いだせるのではないかと思います。
このコンテストの結果は4月17日のCSS Nite LP, Disk 9「Coder's Higher」で発表されるようです。こちらには参加しないのですが、どんな作品が出てくるのか、発表が楽しみです。
駅.LockyのiPhoneアプリが便利すぎる
電車にまつわるiPhoneアプリはたくさんありますが、駅.Lockyほどかゆいところに手が届くアプリはないと思います。単純明快、「次の電車が来るまであとどれぐらいか、をカウントダウンする」ただそれだけ。
使い方駅選択画面：位置情報から近い駅選択をレコメンドしてくれるし、登録リストから選ぶことも可能。
カウントダウン：ストップウォッチのように、次の電車までの時間を表示。電車のイラストをフリックすれば次の電車も見ることができます。
時刻表：こんなにカンタンにアクセスできる時刻表は見たことがない。
- 駅.Lockyの画面。カウントダウン・駅選択・時刻表
何がどう便利かというと、「自分が今目指している駅」を軸に設計されていること。普通の乗り替え検索だと、出発駅と到着駅を入力して検索。うまい具合に見つからなければ、時間指定して検索、それでもだめなら時刻表を見たいのだが、また駅入力を迫られる。。何がアクションの度に入力しないといけません。
比べて駅.Lockyだと、最初に選択しておけばその駅を軸に情報をクロールすることができます。最短ルートなどの機能はバッサリ落とし、汎用性を犠牲にして特定のスコープに集中されたデザインは、使っていて惚れ惚れします。
- 確認が簡単なこと
- やたらと入力を求められることがない。動線の設計がよく練られている。
- 時間の鮮度が高い
- カウントダウン形式なので、毎秒情報がアップデートされます。
- 具体的な数字で見える化できること。
- 電車の時間と現在の時間を引き算して・・といままで頭の中でやっていたことをアプリが代行。
この３つが便利さのキーワードになっています。
ISO 9241-11の定義するユーザビリティの定義、「特定の利用状況において、特定のユーザによって、ある製品が、指定された目標を達成するために用いられる際の、有効さ、効率、ユーザの満足度の度合い」をうまくクリアした、ちょっと心をくすぐるアプリだと思います。
帰ってきたWeb研にいってきた
3月9日（火）にお茶の水でデジハリで開催された「帰ってきたWeb研 Vol.3」に参加してきました。
今回のお題は「WebディレクターのためのIA入門（ダイジェスト）」でスピーカーはネットイヤーグループの坂本 貴史さん（@bookslope）。日本におけるIA最前線のお一人です。去年9月に行われたCSS Nite LP, Disk7 IAスペシャルでのワークショップが非常に印象に残っていて、またお話を聞きたいなぁと思っていたところでした。
内容はIAの基本的な部分をぎゅうぅっと凝縮した感じ。気になったキーワードを以下にあげます。
- IA=スキル。専門領域ではなく、おのおのが持つべきスキル
- Web検定本 デザイン編より
- デザイン実行力とデザインマネジメント
- リーダーシップとプロジェクトマネジメント
- 顧客とのコミュニケーション能力
- IA100より
- メタ化能力
- ワークショップファシリテーション
私の中で特に突き刺さったのは以下。
- IAはあくまでツールであり、これをやったからといって必ずしも良いアウトプットが出る訳ではない。
- タスクや成果物には必ず目的があって、後行程のことを考えて作る必要がある。つくったものを関係者に共有して補完しあえることが大事。
- 中間成果物は「ポリシー」としてガイドラインなどにまとめることができる。それらはメタ化、モデル化して抽出したもの。
特に最初の項目はセッションを通じて常に強調されていました。
IAに限らず、UCDやRIA、SEM/SEOやLPO、もっというとWeb標準など、「これをやればユーザーの満足度があがる、PV増える。結果、数字があがる」みたいに言葉ばかりが一人歩きしてしまいがちなものばかりです。どれもこれも銀の弾丸ではなく、もっと根底の「(Web)戦略」ありきで組み立てないと効果は出ないはずです。
これはクライアントはもちろん、われわれ創る側も十分認識して望まないと「策士策に溺れる」ではないですけれど、思うようなアウトプットができず、付加価値を乗せることができないような気がします。
また、「IAは大事」と思っていても実行しないと意味がありません。そのためにはクライアントにその価値を認めてもらう必要があるかもしれませんし、ひょっとしたらプロジェクトメンバーにも説明がいるかもしれません。
技術的なことや知識ももちろんとても大事なことなのですが、バランスをとりながら推進していく力と信念が必要になってくると感じました。こう書いてしまうとなんだか抽象的ですけど、吸収したものを自分の一日一日の業務に落とし込んで、少しずつ形にしていこうと思います。
またセッションの中では、IAの理解に役立ちそうなリソースを惜しげもなく披露されていました。こちらも後日まとめていきたいと思います。
拡大するtextareaはmax-width / max-heightで制御できる
textarea拡大に潜むレイアウトの危険性
SafariやGoogleChromeでは、textarea要素の右下をドラッグするとボックスが拡大できるようになっています。ユーザーが入力内容に応じてカスタマイズできる、という点ではとても便利な仕様になっています。
しかし、Webデザイナーにとっては意図したレイアウトを壊されてしまう可能性が潜んでいます。縦に伸びるのは特に問題ないのですが、横に際限なく広げられてしまうとカラムをまたいでしまったり、他の要素とfloatで左右に配置している場合は段落ちしてしまったりと、レアケースながらもディレクターやクライアントに指摘されてしまうかもしれません。
対処方法
width / height プロパティで制御できそうなものなのですが、残念ながらこれでは拡大を制御できません。制御するにはmax-width/max-heightを使います。拡大によってレイアウトが崩れてしまう場合は、「ここまでは大きくしてもいい」大きさを指定します。
textarea {
width:300px;
height:100px;
max-width:400px;/*←ここが限界！*/
}こう考えるとtextareaの場合、width / heightはそれぞれ他の要素におけるmin-width / min-heightのような挙動になるのでしょうか。
なお、拡大させたくない場合はwidth=max-width/height=max-heightで指定すれば期待通りになります。
width:300px; height:100px; max-width:300px; max-height:100px;
でもテキストボックスの右下にある「ドラッグできるデザイン」はそのままなので、「テキストボックスは大きくすることができる」ことを学習したユーザーの期待に反してしまうので、あまりよろしくないですね。。
IEではimgを含むインラインでlihe-heightが効かない
久しぶりに使い慣れたCSSプロパティで引っかかったのでメモ。
内容はタイトルの通り。例えばこんな感じ。
サンプル
Windows Internet Explorer （ウィンドウズ インターネット エクスプローラー）とはマイクロソフトが開発するウェブブラウザである。
以前の名称は Microsoft Internet Explorer であった。一般的に、MSIE や IE という名称で指される。
コード
<p style="line-height:3">Windows Internet Explorer （ウィンドウズ インターネット エクスプローラー）とはマイクロソフトが開発するウェブブラウザである。<img src="http://img.f.hatena.ne.jp/images/fotolife/c/commom/20100308/20100308232408.jpg">以前の名称は Microsoft Internet Explorer であった。一般的に、MSIE や IE という名称で指される。</p>
対策
こちらに詳しくありました。
IEバグ：img要素などの置換要素を含む行の前後では、line-heightが指定した値より小さくなる｜CSS HappyLife
ハックかけて、インラインにまぎれたimgにパディングをつけましょう、とのこと。こんな仕様にだれがした。
CSS3 のドロップシャドウと角丸でつまづきそうなところ
CSS3はとても便利なプロパティが満載ですが、まだまだ使い慣れていないため、へんなところでつまづいてしまいます。実際に作っていてドロップシャドウと角丸でハマってしまったところをメモ。
CSS3のドロップシャドウ
-moz-box-shadow:0 0 3px #cccccc; -webkit-box-shadow:0 0 3px #cccccc;
プロパティの内容は以下の通りです。
box-shadow: [横方向のオフセット] [縦方向のオフセット] [ぼかしの半径] [影の色]
上の例では3pxのシャドウ（#cccccc）がグローエフェクトのようにボックスの周りを囲みます。このときボックスレイアウトは左右に3px広がったと解釈されるようです。
つまりシャドウを指定しているボックスが300pxで指定されていれば306pxでレンダリングされるようです。センタリングされているコンテンツエリアとかであれば問題ないのですが、例えばウィンドウいっぱいに広がっているボックスにこのドロップシャドウをかけると横幅がオーバーフローして横スクロールが出てきてしまうことがあるみたいです。
回避するには、横方向のオフセットをぼかしの半径分ネガティブ指定する必要があります。
-moz-box-shadow:-3px 0 3px #cccccc; -webkit-box-shadow:-3px 0 3px #cccccc;
今後のボックスモデルには[ボーダー]／[パディング]に加えて[ドロップシャドウの幅]も勘案する必要があるのかもしれません。。（シャドウは通常のレンダリングフローから外してほしかったです。
角丸のプロパティ指定
CSS3のプロパティは先行実装されたブラウザでは[-webkit-]とか[-moz-]とかのプリフィクスをつける必要があります。ですが、それ以外にも書式が少し異なるという話。
Firefoxの場合は
-moz-border-radius-bottomleft:2px; [プリフィクス]-border-radius-[指定コーナー]
となっていますが、Safariの場合は
-webkit-border-bottom-left-radius:2px; [プリフィクス]-border-[指定コーナー]-[指定コーナー]-radius
となっています。順番とコーナーの指定方法が違うようです。
私はFirefoxベースで作成するので、最初に-moz-でスタイリングしてからそれをコピペしてプリフィクスを-webkit-に付け替えるのですが、border-radiusの個別指定はその方法でデザインが反映されません。おかげでダダハマりしてしまいました。。。
Webに必要な人材
デザインや使いやすさよりも、はるかにSEOやSEMにお金が流れ易いジレンマ*ホームページを作る人のネタ帳
ちょっと釣り気味ではありますが、これジレンマすぎます。Webデザインって、技術的にも業界的にも人材的にも、まだ体系的に確立されていないのかな？もしくは「Webデザイン」というワードを「表層的なデザイン」とするからこうなってしまうのかな？それとも「SEO/SEM」と「Webデザイン」を同じレイヤーで考えてしまうからこうなるのかな？
戦略にもとづいた「design（＝意図に適ったものを創る）」と考えれば、受注した瞬間から「design」が始まるので「企業戦略→Web戦略→Webサイト設計→Webデザイン」のフローが一本筋の通ったものになりやすい。SEOもSEMも、この開発フローから完全に外れたところにある訳ではないのでSEOの方がお金とりやすい、とかWebデザインなんてなんでもいい、なんて状態にはならないような気がします。ただ、上記の流れにそった「Webサイト開発」をそれぞれバラバラのアライアンスパートナーに外注していて、PMを担うポジションがそれぞれのアウトプットの背景とか因果関係を把握できず、戦略からデザインまで一枚の大きな絵を描けなく（もしくは途中から描けなく）なってしまっているとすれば不幸すぎる。
アウトプットがバラけないように標準化したり、UIデザインの効率性の重要さを理論的に数字を元に説明できる人材を育てたり、そもそもクライアントにブランド戦略とサイトのトーン＆マナーをリンクさせた啓蒙を進めたり、業界的にできることもたくさんありますね。少なくともクライアントにSEOはアクセス数UPは経過点であって目的ではない、など目的と手段を切り分けて説明できる素地が必要ですね。
私は2年前に事業側のWebデザイナーに転身しました。以前のクライアントワークでは作っては捨てての繰り返しでしたが、果たしてこれが事業側に移ったからといって解消された訳ではありませんでした。クライアント- インテグレーターと同じ関係でビジネス-クリエイティブと部署が分断されていて、ビジネス側の人は課せられた数字達成のために詰められてない施策を大雑把なデザインでリリースしてしまい、クリエイティブ側も短納期で課せられたタスクを捌くのに精一杯で知らず知らずにロークオリティなアウトプットをビジネスに渡してしまう。ちょっと大げさですけど、だいたいこんな感じです。
誰が悪いというわけではないのですが、仕事を分業し過ぎなように思います。分業と協業は違っていて、我々は垣根を作って分業するのではなく、越えて協業すべきなのです。以前参加したセミナーで「分業は必要悪と考えた方がいい。本当は自分一人でやりたいのだけど、全部はやりきれないので仕方なく....と意識すべき」という話を聞きました。
これまでは「スペシャリティ」という名目でSEOしかできないデザインしかできない、でもよかったのかもしれませんが、未来を見据えると「一つのスペシャリティを持ちつつ、垣根を越えて他分野の専門家とも渡り合える知識や経験をもった人材」を目指すべきですね。
