ePubの話もその性質上触れざるを得ませんが、今回は主に「HTML5」に特化した内容となる予定です。限られた時間になるので、現状の分析やHTML5による電子書籍や雑誌の構造解説などをしつつ、これから先の未来に向けてWebデザイナーさんやコーダーさんはもちろん、コンテンツを配信する側の人たちが頭の片隅に置いておきたい話が中心になるかと。他の出演者のお二人含め、現時点での全体的な内容は CSS NiteのFacebookページで公開されています。

なお、最新情報では残席が70ぐらいだそうです（お申し込みはこちら）。

※今回のCSS Nite、LP Disk 18のjQueryの回と同日連続開催になっています。

まずは、この場を借りてお礼を。ありがとうございました（深々）。

さて、当日はFireworks特集となるイベントでしたが、ボクの担当は他の登壇者の皆さんの内容とはちょっと毛色が異なるカラーマネジメントの話でした。「FireworksのTipsやテクニックなどを知りたい方が多いんじゃなかろうか、今回の内容に関して大丈夫かな？」と思っていたのですが、予想以上に良い反応をいただいておりホッと胸をなで下ろした次第です。

とはいえ、プレゼン自体はボロボロだったので、その反省や参加いただいたお礼をこめて当日伝えきれなかったことをこちらのエントリーにまとめてみました。

＃前もって書いておきますが、長いです（笑）。

カラーマネジメントを意識して作業するってことは…

Webの世界は閲覧環境がバラバラ、人によってモニタでの表示状態が変化してしまうという特徴があるのは事実です。現時点では、それを完全に制作者側でコントロールすることは不可能でしょう。

ただ、多くの環境である程度は制作者側が意図した色合いに近い状態で見てもらうということは可能です。裏を返せば、何も気にしないで作業していたら、最悪他の環境での表示状態がまったく合ってないってこともあるわけです。

カラーマネジメントを意識して作業をするというのは、多様な環境でできるだけ色を合わせるって意味はもちろんですが、それ以上に「多様であるが故におこりうる色の違いに関するクレームに自信をもって対処できるように制作物（納品物）を仕上げる」ためでもあります。自分の制作物が正しいのかどうか自信が持てなかったら、クライアントやお客様に適切な説明もできませんよね。

そのためには、閲覧環境の違いを認識することや制作環境の状態を把握することも大事ですし、色空間やプロファイルの存在を知ったり、アプリケーションの適切な使い方を覚えることも必要なのです。

ブラウザのカラーマネジメントについて

sRGBの色空間として考えられるインターネットの世界において、ブラウザのカラーマネジメントは「JPGに埋め込まれた異なるプロファイルを正しく解釈できる」と考えてもらえば良いでしょう。そこからモニタやOS環境にあわせて再度色味の調整がおこなわれる、と。

たとえばWindows環境下なら半ば強制的にsRGBにされるわけで、プロファイルのあるJPGでもsRGBの色空間であるものとして表示されて色が変わってしまうわけです。使用中のブラウザがこのプロファイルを認識できるかどうかは、こちらのページでチェックできますので試してみましょう。

リンク先で表示された写真は4分割されています。それぞれがまったく別の色に見えてたらカラーマネジメントはされてない（プロファイルの解釈ができない）ことになります。Firefoxの場合は、3つ同じになるはずです。

ちなみにFirefoxは、カラーマネジメント機能を「about:config」の画面で調整可能です（現在のバージョンは、デフォルト有効）。

「gfx.color_management.mode」のトコの数値がそれです。「0がオフ、1と2がオン」なのですが、1と2ではページ全体をカラーマネジメントするか、プロファイルのある画像だけを対象にするかといった違いがあります（参考リンク）。

このようなブラウザやOSによる挙動の違いは、これまでこのブログで何度も紹介しているmiyahan.comさんの「液晶ディスプレイとカラーマネージメント」が大変良くまとめられているので、是非ご一読を。

やらないよりはやった方が良いに決まってるキャリブレーション

キャリブレーションについては、「色を合わせるというより、正しく色が表示できるようにする」と考えていただいた方が良いでしょう。やるとやらないでは、見え方が大分違うんじゃないですかね。

より厳密にやるのであれば、ハードウェアキャリブレーションをおこなうツール類が販売されていますので、それを用いた方が良いに決まっています。ただ、世の中の皆さんすべてが予算がとれる環境ばかりではないので、今回は簡易的なキャリブレーションの方法として、Windows環境では「Adobeガンマ（※現在配布されていません）」や「Calibrize」、Macは「システムの環境設定→ディスプレイ」を紹介しました。

せっかくなので、WindowsのCalibrizeでの手順を書いてみます。

インストール後、起動する

配布サイトからダウンロードしインストールが終わったら、起動して「Next」を押してモニタの明るさとコントラストを調整します。そして再度「Next」を押すとこの画面です。

RGB各色のスライダを調整する

この画面があらわれたら、RGB各色の下にあるスライダで調整します。中央の●と周囲の色が同じになるようにスライダを動かすのですが、この違いを真面目に見つめてはいけません。1〜2mモニタから離れて、目のピントを合わせないでスライダを動かすのがポイントです。

で、同じになったら保存

RGB各色の調整が終わったら「Next」を押して、出てきた画面で「Save」を押して保存しましょう。

シレッとインストールされます

ダイアログも出てこないので「どこに保存されたの？」って感じなのですが、ちゃんと更新されるはずです。コントロールパネルの「モニタ」や「色」に関する設定を開いてみましょう（WindowsはOSのバージョンでまちまちなので、それは自身で調べてください）。

ちなみにモニタのプロファイルなどは、「C:¥Windows¥System32¥spool¥drivers¥color¥」にあります。日付でソートして最終更新日を確認すれば、どれがいじられたものか分かるはずです。

Creative Suiteのカラー設定について

今回は、Fireworksの特集であったので、Creative SuiteやPhotoshopのカラー設定についてはサラッと流したのですが、Creative Suite全体のカラーマネジメントは「Bridge」でコントロールします。

Photoshopのカラー設定について

せっかくなので、Photoshopのカラー設定も書いておきましょう。
基本的にCreative Suite全体のカラーマネジメントの支配下におかれて同期されていますが、編集メニューから内容を修正することも可能です。

ソフトをインストール後の初期設定は「一般用 日本 2」か「Web・インターネット用」になってるんじゃないでしょうか（インストールするSuiteによって違うかもしれませんので確認を）。ここで大事なのは「RGBの作業スペース」と「カラーマネジメントポリシー」です。

作業スペースが「sRGB」になっていれば、新規ファイルを作成したり、埋め込まれたプロファイルを作業スペースに変換してファイルを開いた場合は「sRGB」になります。

カラーマネジメントポリシーは、埋め込みプロファイルが異なる場合やプロファイルがない場合の処理になります。設定によってはチェックが外れている場合がありますので、一致しないものやプロファイルがないものは処理をダイアログで決定するようにしておけば確実です。

RGBのカラーマネジメントポリシーを変更することもできます。自身の設定が「作業用RGBに変換」なのか「埋め込みプロファイルを保持」なのかを確認してちゃんと覚えておきましょうね。

sRGB以外の色空間を取り扱う機会が多い場合など、「必ずしもsRGBばかりで作業するわけじゃないから自分で全部コントロールしちゃうよ」って時は、設定そのものをオリジナルで保存しておけば良いでしょう。WindowsならどのみちsRGBが基本なので、モニタのプロファイルを選んでも大差はないかと（もちろん環境で変わりますので、この辺がわかってる人はお好きにどうぞ）。

その代わり、カラーマネジメントポリシーでとりあえずダイアログが出るようにしないと、モニタのプロファイルになってしまいますからね。

色空間の存在などを知らない状態で、この辺の設定をスルーして第三者のファイルを処理しちゃったりするから問題が起こるのです。「自分の見ているのは何なのか」はちゃんと知っておきましょう。

色空間をちゃんと扱わないと…

Fireworksの話をしなければならないのですが、ちょっと脱線して…。たとえば、「Adobe RGB」のプロファイルをそのまま使ってファイルを開いたとします。

以下の画面で使ってるファイルは、こちらにあるわざとAdobe RGBのプロファイルを埋め込んだJPGです。これ以外にも試してみたい方は、こちらとかこちらにあるのをご自由にお使いください。

それを「sRGB」の色空間に変換せず、そのままJPGとしてプロファイルを埋め込んで書きだした場合は、カラーマネジメントの効かないブラウザでは当然のことながら色が変わってしまいます。

どのように見えるかっていうのは、Photoshopの「色の校正」でも確認できます（※上の「校正設定」で「インターネット標準（sRGB）」を選択してから）。上の写真と比べてみると明らかにおかしいですね。

適当にやっちゃうとこういうことになってしまうのです。

異なる色空間は適切に変換する

Photoshopの余談を続けましょう。

作業スペースが「sRGB」であっても、埋め込まれたプロファイルをそのまま使えば、ファイルの持っている色空間で作業することになります。これを「sRGB」の色空間に適切に変換するためには、Photoshopの「編集」にある「プロファイルの変換」を使います。「プロファイルの適用」ではないので気をつけてください。

内蔵のCMSを使って、色空間を変換します。

表示されたダイアログで、変換後の色空間に「sRGB」を選択して「OK」を。

書き出します。CS4からは「Webおよびデバイス用に保存」のダイアログで「sRGBに変換」というチェックボックスが表に出てきたので、面倒だったらそれで変換しても結果は同じでしょう。

左が「Adobe RGB」の元ファイル、右が「sRGB」に変換して保存したJPGです。大丈夫そうです、偉いぞCMS（笑）。では、PhotoshopはこれぐらいにしてFireworksに戻ります…。

Fireworksの挙動を再確認

CS4以降のFireworksは、プロファイルの埋め込まれたPSDファイルであれば、内部でsRGBに変換処理をおこなって表示するようになっています。

しかし、問題は「プロファイルの埋め込まれたJPG」です。たとえば、下の写真。

左が「Adobe RGBのプロファイル付きのJPG」、右が「sRGBのプロファイル付きのJPG」です。sRGBなら、まぁFireworksもsRGBなので問題はないでしょう。しかし、Adobe RGBの…は…、明らかに…、色がち、違います…。

試しに「Adobe RGB」なPSDを開いて比べてみるとご覧のとおり。

これでは困りますよね。困ります。クライアントの支給データなどなら、担当者がコンパクトデジカメで撮影したデータだったりして、なんとなく「sRGBだろうな…」って想像は付きます。しかし、カメラマン提供のJPGになってしまうと、「Adobe RGB」や「ProPhoto RGB」の色空間である可能性が出てきてしまいます。それを知らずにFireworksで開いたら…。怖い怖い。

プロファイル付きのJPGを「sRGBのプロファイル付きのJPG」へ

Fireworksの挙動は前述したとおりです。Photoshopを持ってなくて、Fireworksしかない場合にプロファイル付きのJPGが届いたら困ります。その問題をクリアするツールを紹介しましょう。

使うのは「Image Magick」。Webサーバの中で画像処理をおこなったりしているソフトウェアですので、「おや、どこかで聞いたことがあるぞ？」という方も多いかもしれません。

実はこのソフト、WindowsでもOS Xでも使えます（実際の変換処理はコマンドラインになりますが…）。まぁ、騙されたと思ってダウンロードしてインストールしてみましょう。

変換処理は、コマンドプロンプトでおこないます（OS Xならターミナル）。まずは、変換するファイルと同じディレクトリにシステムの中にある「ICCプロファイル（.iccとか.icm）」をコピーしてきましょう。

Windowsなら「C:¥Windows¥System32¥spool¥drivers¥color¥」、OS Xなら「/Library/ColorSync/Profiles/Displays/」とかにあります。

そして以下のコマンドを入力します。

convert 変換するファイル -profile プロファイルのファイル名 変換後のファイル名

※色空間のとこは、「sRGB〜」みたいなのが入ります。ファイル名さえわかればいいので、sRGB.icmとかsRGB.iccにしておくと楽です。

変換が終われば、ファイルができています（何も言ってはくれませんｗ）。

Adobe RGBのファイルと変換処理したファイルをFireworksで開いてみましょう。左が「Adobe RGB」まま、右が「sRGB」に変換したもの。

成功ですね、くすんでません。これでFireworksだけでいけちゃいます。

FireworksからPhotoshopに持っていく

ここからは、Fireworksで保存・書き出したファイルをPhotoshopに持っていく場合の補足です。

Fireworksで保存・書き出したファイルにはプロファイルが付きません。ファイルを開いた際にカラーマネジメントされてるかどうかは、環境（カラーマネジメントポリシー次第）で変わるので、再度色空間を確認、必要に応じて指定しましょう。

Fireworksの作業空間がsRGBなので、そのファイルもsRGBとして扱います。色空間を指定する（変換ではない）時は「プロファイルの指定」を選択して適切な色空間を適用します。

※「プロファイルの変換」は色空間をコンバートする、「プロファイルの指定」は色空間を強制的に適用する、ってイメージです。

カラーマネジメントされてないのであれば指定しましょう。

sRGBのプロファイルを選択して「OK」を押せばオッケイ。

他の色空間にしたい

ここで気をつけたいのが、仮に元のファイルがAdobe RGBの色空間であったとしても、Fireworksに持っていったらsRGBになります。

何かしらFireworksで処理したファイルを開いて、「元がAdobe RGBだったよな」ってことで「Adobe RGB」を指定したら色が変わります。これでは間違い。

安直に「プロファイルの指定」で「Adobe RGB」を指定するとダメ。

たとえば、元のAdobe RGBの色空間に戻す、戻した方が都合がよい場合は（があるかどうかはさておき）、一旦sRGBなり作業用の色空間を適用した後に、「プロファイルの変換」を使って「Adobe RGB」に変換します。

はい、これで適切に変換されました。

OS XでのFireworks

基本的な仕様とか挙動は、Windowsと変わりません。

Windows同様、プロファイル付きのJPGだと色は異なります。

Photoshopとの間でデータをやりとりする場合、sRGBの作業スペースで完結していれば、FireworksのファイルはsRGBのプロファイルを指定しましょう。

なので、sRGBで作業スペースを統一しておくと楽なのはOS Xも一緒です。

OS Xで環境をカスタマイズしている場合は…

DTPなどの仕事と併用していてsRGBの色空間以外などを使う機会が多い場合などは、自身の環境がカスタマイズされていることも多いかと思います。その場合は、モニタをベースに作業する方が余計な手間（プロファイルの適用とか変換とか）がかからないこともあります。

「ハードウェアキャリブレーションしてない環境でモニタにあわせるのは危険では？」というご指摘もうけましたが、安全を取るならもちろん環境を「sRGB」に統一した方が良いでしょう。オリジナルの設定でできるようなレベルの方は解説の必要もないと思われますので、ご自身で最適な方法を選んでください。

これはボクのPhotoshopのカラー設定です。RGBの作業スペースはモニタ、CMYKの変換テーブルもオリジナル、みたいな人も中にはいるのではないでしょうか。

上記の設定でファイルを開いた状態。左はAdobe RGBの色空間、真ん中と右はFireworksのPNGを開いてるのでカラーマネジメントされずモニタの色空間になってる状態。

ファイルがsRGBの色空間ですから、プロファイルの指定で「sRGB」の色空間を指定する、と（左と真ん中が同じ状態、右はそのまま）。これを間違えてsRGBに変換したら別のものになっちゃいます。Photoshopには、前述した「色の校正」ってのがありますので有効活用しましょう。

今どのような状態なのか、ってのを知ることが大事なんです。

というわけで、長々と失礼しました

実のところDTPの黎明期に近い時分から写真と印刷物の色合わせ、富士ゼロックスのプリンタの色あわせとか仕事としてやってきましたけど、環境でコロコロ変わる色の話を真面目にしようとすると簡単には書けないんですよね…ホント。

30分（実際はしゃべりすぎて40分…）という時間でFireworksを絡めた内容を伝えるため、後半が駆け足になってしまって聞き苦しい点も多々あったのではないかと感じてますが、聞いてくださった皆さんに何かしらの気づきを与えられたのであれば幸いです。あらためてありがとうございました。

→ CSS Nite

おまけ

おまけというわけではないのですが、「プロファイルを埋め込むとファイルサイズが増えるよね」というご指摘もいただいていたかと。確かに微妙にその分サイズは増えてしまいます。sRGBの色空間で最終的に処理し書き出してれば、プロファイルを埋め込まなくてもいいっちゃいいでしょう。

他のセッションで、Fireworksの方が書き出しサイズが小さくなるとか、最適化したPNGにすれば軽くなるということを紹介されていましたが、書き出したJPGファイルもPNG同様にさらに小さく最適化することができます。

インストールするタイプではない画像の最適化に使える有名なオンラインサービスとしては、米Yahoo! の「Smush.it™」や「PunyPNG」なんかがありますね。JPGとかは、プロファイル分ぐらいのデータサイズなら余裕で減ります。試してみてください。

ボクの担当は「写真の色に関するトラブルをなくせ 〜 その色、本当にあってますか？」ということで、Webに掲載する写真やその処理過程におけるトラブルをなくすため、Web制作の現場において ‘意外と軽視されがちな’ カラーマネージメントのこと、Photoshop/Fireworksの双方のユーザーで抑えておきたい注意点などをギュッとまとめてご紹介する予定です。

iPhoneアプリの「Instagram」で、写真だけをネタに12,000人超のフォロワーを獲得している人の写真の色の扱いの話です。その謎が解けるかも！？（なんてね 笑）。

＃本イベントは3月5日開催ですが、2月5日17:00までのお申し込みまでは早期割引が適用されますので、参加をご希望の方はお早めにどうぞ。

本セッションで使用したスライドについては、別途実行委員会の方から公開先URLを連絡していただくことにして、セッション中で紹介したことのいくつかをこちらでフォローアップさせていただきたいと思います。

Dreamweaver CS3 でZen-Codingを使用する方法

現在配布中の「Zen-Coding for Dreamweaver」はCS4対応版ということになっています。残念ながら、それをCS3にインストールしても正常に動作しません。

そこで、配布サイトのIssuesにおいて、CS3で現在のバージョンを動作させるために入れ替える「zen-editor.js」というファイルが公開されてます。こちらのファイルをシステム内のDreamweaverのConfigurationフォルダ内にある「Commands → ZenCoding」の中の「zen-editor.js」と入れ替えてください。

展開される内容を変更するには

Zen-Codingでは「en-US（本家はru） / UTF-8」が初期設定になっています。これが影響するのは「html」を展開した際に出てくるlang属性やmeta要素ぐらいですが、気になる場合はあらかじめ上記フォルダ内にある「zen-settings.js」の中の冒頭あたりにある指定を変更すれば大丈夫です。それ以外にも、展開後にあらかじめ属性を入れたい場合などは、こちらのファイルの該当部分を修正しましょう。

Zen-Codingのチートシートの所在

HTMLにしてもCSSにしても、基本的に省略形を入力し展開しなければなりません。HTMLは基本的に要素名と同じのものが多いのですが、中には「:」を使ったオプションもいくつか用意されています。CSSも基本的にプロパティの頭文字の組み合わせになりますが、やはり「:」を使って特定の値まで一気に入力することも可能です。

こちらの省略形やオプション指定については、配布サイトで公開されているチートシート「ZenCodingCheatSheet.pdf」に詳しく載っておりますので参考にしましょう。慣れないうちは、なかなか大変かと思いますが、普段使うものなんて限られてるのですぐ覚えられます（笑）。

Zen-Codingは不定期にアップデートされています

Zen-Codingは実は2年ぐらい前からあるんですが、不定期にバージョンアップされていますので、たまには配布サイトを覗いてみましょう。新しいバージョンが公開されたら、追加された書式の使い方などもあわせてそちらに掲載されます。

Zen-Codingが使用できるエディタなど

そもそも欧米圏で利用者の多いテキストエディタやIDE用のプラグインとして公開されていたZen-Codingですが、国内で利用者の多いエディタやCMSなどにも導入できるようにしたものがいくつか公開されています。Dreamweaver以外でも使いたいな、という方は「使用中のエディタ名 Zen-Coding」といった感じで検索してみましょう。

最後におまけ

先日のセッションでは基本操作を中心に解説したのですが、デモ中で使用していたラフを実際にコーディングしていく様子をPV的に編集したものがあります。あの程度の内容であれば、HTMLとCSSの双方をコーディングし完成させるまで30分ほどあれば大丈夫かと。興味のある方は以下のリンクよりご覧ください。
→ WebDevelopment with TextMate and Zen-Coding

以上でフォローアップとさせていただきます。
仙台は素敵な街ですね。また遊びに行きます。ありがとうございました。

今回のテーマは『Dreamweaverを使いこなす』ということなのですが、私の担当は「Zen-Coding」であります（笑）。

お題は「Zen-Codingはみんなのもの」

Zen-Codingはよく「ゼロからコーディングするのに向いている」という風に思われがちなのですが、実は原稿ベースでマークアップしていくこともできます。もちろんCSSも省略形といくつかの入力方法さえ覚えれば、Dreamweaverの入力補完の機能にプラスアルファして効率アップが図れます（慣れは必要ですが、すぐ覚えます）。

こちらのブログでの紹介や以前Ustreamでやったデモなどではゼロからのコーディングに重きをおいたので、今回のこのイベントでは原稿ありきのコーディングデモやCSSの入力などまでちゃんとカバーしたいと考えてます。詳細は、CSS Nite in SENDAIのWebサイトでご確認ください。

早期割引は終わってしまってますが、まだ事前登録していただければ当日¥3,500のところ¥3,000で参加できますので…（ごめんなさい）。仙台近郊の皆さんにお会いできるのを楽しみにしています。

＃私今回初めて杜の都仙台の地にまともに足を踏み入れるのですが、「牛タン」が大の苦手という残念な人間です…。こちら事前情報として提示しておきます（笑）。

キーワードの選定にあたっては、「来場いただく皆さんの求めてるものは何だろうなぁ…」といろいろ考えるのですが、なんせWebといっても幅が広すぎます。新しい技術的なものなのか、制作手法や考え方に関わることなのか、Web業界を取り巻くトレンドなのかと、1時間弱という枠で話せることも限りがありますし。どこに絞った方がいいかを直前まで悩んだ挙げ句、あのようなごった煮的なものになっていたというわけですね。

補足情報をちょこっと

web creators編集長の佐藤さんのブログでプレゼンデータなどが公開されているので、既にご覧になった方もいらっしゃると思いますが、ボクの担当した内容に関する補足をいくつか。

リアルタイムWebやソーシャルメディアの話

Googleなどの検索においても、ブログやTwitterの書き込みなどが数秒後、数分後には表示されているというのをお話しました。

実際にあった話をひとつ書いてみましょう。ここ数週間一部で盛り上がってる「Zen-Coding」。たまたま検索したタイミングでボクがやっていたUSTREAMのライブデモへのリンクが含まれるつぶやきがあらわれて、生で放送を見ることができたという方もいらっしゃいます。

これまでは「検索して表示された結果からブログを辿って、そこに書かれた情報を仕入れてまた別のサイトへ移動する」といった流れが一般的だったと思います。しかし、ブログやTwitterの書き込みがリアルタイムで表示されることをうまく利用すれば、タイミング次第では自サイトへうまく誘導することだってできる、と。

企業のWebサイトの担当者の方であれば、ソーシャルメディア系のサイトにおける自社製品のクチコミなどを調べたいと思うこともあるでしょう。海外のようにもう既にそれが盛んなところでは、アクセスログによる定期的な解析に加えてリアルタイムな解析の仕組みやサービスを取り入れていることが多いと思います。

先日話題になったリアルタイム解析の「Chartbeat」、以前紹介した「Viralheat」や「SWIX」といったサービスなどいろいろあります。いろんなものが半年や一年近く前からあるのに、日本で話題になるのはいつも遅い（笑）。ちなみにこのSWIXが先日世界レベルのブランドのソーシャルマーケティングの取り組みをまとめた簡単なレポートを公開しています。

いまどきのんびりと構えてログをみて「ここに手を入れて」「次は何を出そうか」なんて言ってる場合ではなくて、盛り上がってるタイミングで何かを投下するといったことぐらいやった方がいいんじゃないかと。企業側でももはやそういう体制作りが必要になってきてるんじゃないでしょうかねえ…。

Zen-Codingなんか良い例です。リアルタイムログを眺めていれば、どこかで話題になってアクセスが増え始めてるなんてすぐわかります。そのタイミングでここぞとばかりにそれに関する記事を増やしてみたり、内容に修正を加えたり、USTREAMのライブデモをやってみたりという策を打つことで人を集められます。

それが結果として、Twitterのフォロワー数やサイトのフィードの購読者数にも反映されると。企業やブランドに例えて大げさに言えば新たなファン層の獲得にも繋がるってわけです。もうその土台はできています。

このような業界全体の流れは、とっとと掴んでバンバン試した方が良いんじゃないかと。先に入手して機が熟すのを待つのは結構。でも、その存在すら知らず、手を打たないでいたらみすみす魚を逃がしていることもありますから。

くれぐれも昨年ぐらいからTwitter始めて、Twitterマーケティングがどうしたとかほざいてるような人たちには騙されないでくださいね（笑）。相談するなら、少なくとも2年以上動向を見てきたような人に頼みましょう。

Webサイトの表示パフォーマンスの話

GoogleさんやAlexaの基準では、今のところ「3秒」が標準的な速度になっているようです。日本のWebサイトはそれに比べて遅いねえ…と言ったわけですが、視覚的な表現も大事ですし画像を一杯使ったりすることもあるでしょう。必ずしも速くしなければならない、とは言いませんが、できれば速い方が見る側にとってはありがたいです。今後Googleさんのアルゴリズムに組み込まれる可能性はありますしね（なぜWebmaster toolsで結果を見れるようにしてるのか、と）。

ブロードバンド環境が整いつつありますが、その一方ではデバイス環境の多様化もあります。閲覧するための回線も必ずしも速いわけではありません。いろんな環境に対してできるだけストレスを与えないで閲覧できるようなWebサイト作りが今後求められるんではないでしょうか。アクセシビリティは身体的なことばかりではありません。境さんがおっしゃった「FlashとHTML 5」の話も同じ事です。

これまでのような「制作サイド目線でのWebサイト作り」はそろそろ意識を変える時期なのではないかな、とボクは思っています。いくら綺麗なもの面白いものを作っても、それを見てもらえなければ何も始まりません。

大人の事情もあるとは思いますが、まずは自分の置かれた環境で「できること、できないこと」を洗い出してみて、できることからやってみてはいかがでしょうか。大人の事情なんて制作側の身勝手な都合でしょ？（笑）。

（余談）SEOなんかも同じで、付け焼き刃では効果はしれてます。Googleさんのアルゴリズムからリンクポピュラリティがなくなるとは思えませんが、仮になくなった瞬間に終了宣言されるサイトなんて腐るほどありますからね、日本のサイトは（謎）。ボクは「何とか最適化」ってのが嫌いです（言葉として文中で使いはしますが 笑）。何かに特化して施策を打つことがダメとは言いませんが、すべては相互に繋がっていているものです。もう少しトータルで考えた方がいいんじゃないかな？と。

モバイルの話

日本の携帯電話の場合、国内の三大キャリアさんが出している携帯電話のシェアが圧倒的に多いことは言わなくてもわかります。キャリア公式などのコンテンツに限らず非公式のコンテンツであっても、どうしてもこのキャリアさんの仕様にがんじがらめになってしまう傾向があります。端末の発売時期で画面解像度は違うわ、使えるHTMLやCSS、Flashのバージョンが違うわとか、まぁ大変です（笑）。

予算が潤沢にある場合は、専用の携帯サイトを作ったりすると思いますが、すべてのプロジェクトでそれができるわけでもありません。しかし、さすがに携帯電話の所有率を考えればまるで無視するわけにはいかないと思いますので、せめてそのような端末でも最低限の情報が閲覧できるような抜け道を作っておくのが良いんじゃないか、と。

映画のサイトのように全面Flashで展開するのは考えものです。携帯電話向けにはリダイレクトされて専用のページが出るかもしれませんが、iPhoneとかで閲覧すると何も見れません。上映劇場の情報だけが知りたいのにリンクがFlashの中にあるとか、もうアホかバカかと（結局それはポップアップするから普通のHTML 笑）。

Flash使っててもいいから、せめて利用者が必要としているだろう情報ぐらいはページのどこかにHTMLのリンクを入れるとかね。それが優しさ（アクセシビリティの向上）だったり、ホスピタリティってことでしょう。

iPhoneやAndroid端末といったスマートフォンにあたるデバイスの所有率は、いわゆる国内の携帯電話に比べればかなり低いものでしょう（東京の遭遇率は異常 笑）。でも、世界レベルで見てみるとスマートフォンを含むモバイル用に最適化されたページが表示されるサイトが増えています。別にiPhoneに限ったわけではなく、スマートフォンに採用されているブラウザがモバイルデバイス用のCSSだけでもいけるのが大きいのかな、と。

イベント中に紹介したギャラリーサイトで見せ方の研究をしたり（ソースは見れますからね 笑）、実際に「Mobify」などのモバイルサイトの構築サービスを試したり（他にもいろいろ）、iPhoneのデベロッパーサイトに掲載されているモバイルSafari向けの情報を見ながらHTML 5やCSS 3の先取りをしてみるのも良いかもしれません。

国内の携帯電話事情は今の延長線な気がしますし、スマートフォンが国内で流行るかどうかは別として、場合によっては最適化されたサイトが必要にもなります。何よりこの類のものは、聞くよりも自分で試行錯誤しながらでもやった方が早いです。

情報収集の話

RSSリーダの活用は一回やめたけど、最近「Feedly」を使って読むようになったと言いました。FeedlyはGoogle Readerと連携するRSSリーダになります。iPhoneでは今のところ「Reeder」が読みやすいので使っていますが、前述のFeedlyがそろそろiPhoneアプリを出すようなので期待しています。

また、普段ボクが見ているサイトは「Netvibes」というiGoogleのようなスタートページに集約されています（これもRSSリーダといってしまえばそうですが）。先日のエントリーにリンクを入れておきましたが（そろそろ消すのでお早めに消しましたｗ）、普段見ているのはあんな感じでタブ分けした世界中の情報です。英検4級のボクでも見てます（笑）。あとそれ以外には、先日伝え忘れていた「Hacker News」をちょこちょこ見ています。他にもあるけどあとは内緒（笑）。あ、国内の情報はほとんど見ません。

ここで「読む」と言わないで「見る」と言ってるのには訳があります。ああやって表示されたサイトの情報を逐一読んでるわけではありません。どちらかと言えば、「見出しを見て、興味があるものをピックアップする」→「全体を眺めて、大まかな内容を掴む」→「必要であれば、後でじっくり読むためにDeliciousなどのブックマークに登録しておく」といった流れで集めています。

自分はいらないけどTwitterでフォローしてくださってる同じ業界の方の参考になればということで、英文の情報ですけどそのままリンクを流してみたりといったこともしています。ボクのアカウント（@cipher）でたまに英文とURLが出てくるのはそういう意図です（ブックマーク専用のアカウントは、@proteanbm に移行してますので必要であればフォローしてください。結構うざいと思うので、Listがオススメ 笑）。

そんなTwitterに関しては、イベントでも言ったように半分以上が情報収集の目的なので、自分のリスト（@cipher/inbox）に海外サイトのアカウントを登録しておいて眺めるようにしています。彼らは、自分のサイトの古い記事とかもテコ入れする感じで流してきますので、新しいのかどうなのか見極める必要がありますけど、中には有益なものもありますのでまぁ良しとしてます（同じようにすれば、我々もフォロワーの皆さんに昔の記事を読んでもらえるってことですけどね 笑）。

あと、最近はMashableやReadWriteWebといったIT系の情報を扱う有名サイトのiPhoneアプリがリリースされています。Hacker Newsもオフィシャルではないようですがありますね。それとつぶやきの集積サービスであるTweetmemeのアプリなんかも入れてます。移動中などで暇な時は、それらを見ながらTwitterに流してみたり、興味のあるものは直接ブックマークしたりといったことをしています（こういうサイトの情報を出すと嫌がる人いるだろうなぁ… 笑）。

ボクの場合、こういうWeb制作の考え方や技術に関すること、企業やブランドのサイトの運営や施策に関わること、原稿執筆といったようにジャンルを問わずいろいろ仕事をしている手前、情報は一次発信源に近いところで拾ってその真偽を確かめたり、誰かに伝える前には自分で試したりしています。性格上、そのまま受け流しは嫌なので。

イベントでも言いましたが、時差が2年出ることもあるわけです。2年あったらそこに向けて、種をまいたり知識を蓄えることもできます。未来がどうなるかわかりませんが、プライベートの時間を潰してでも、先を予想したり必要なものを見極めながら貪欲に仕入れていくぐらいの気持ちが、これからの時代を生き抜くために必要なのかな？って思ってます（というか、これまでもそうしてきましたから 笑）。

会社勤めだと自分の業務だけでいっぱいになることも多いと思います。でも、好きこそものの何とかです。覚えたい、自分のものにしたいと考えるのなら、どれだけ多くの時間やプライベートを犠牲にできるかでその後の成長は大きく変わってきます。当然、そうすれば失うものも増えます（笑）。

アホみたいにやってる人がかけてる時間と同じ時間をのほほんと過ごしてたらいつまで経っても追いつけません。第一線で活躍するプロスポーツの選手だって、生まれつきの天才以外は見えないところできっと自分の時間を潰してるはずです。

時代は情報過多です。何でも拾えばいいってわけではありませんし、自身のフィルターの精度が悪ければ間違えた情報に流されてしまうこともあります。気をつけましょう。信用できるソースをいくつか見つけておけば、時間の節約にもなりますし余計な時間は取られませんので。

最後に

web creatorsさんは紙媒体からオンラインへ移行します。今後も関わらせていただくかどうかわかりませんけど（笑）、こちらでも定期的に皆様のお役に少しでも立てるような情報をエントリーしたり、ゲリラ的にUSTREAMで喋ったりしますので頭の片隅、登録フィードの片隅にでも置いておいていただければ幸いです。

こちらのイベント、なぜか私こもりが出演します。

取り上げてほしい内容があれば、Twitterで募集中です

当日は、Webデザインに関する書籍を沢山執筆されているあの境祐司さんと一緒に「Webデザインやクリエイティブの過去、現在そして2010年について」語ることになっておりますが、二人とも普段のテンションが低いので大丈夫でしょうか…。当日二人がハイテンションになれるか、今からちょっと心配です（笑）。

ちなみに…。

この、Designer meets Designersスペシャル「WebデザインNight! by web creators」では、当日会場に来られる方だけでなく当日会場に来られない方にも参加していただけるように、当日テーマに取り上げてほしいことを Twitterで開催時間までに募集します。web creators編集部公式アカウント（@webcreatorsjp）にハッシュタグ「#webcre100」をつけてつぶやいてください。ほかの方のつぶやきに同意してRTしていただくのも大歓迎です!

http://www.mdn.co.jp/webcre/d2s/

といった感じで、当日会場に来れない方もTwitterで参加していただけるようにハッシュタグが用意されています（Apple Storeは映像での中継はダメらしいので）。取り上げてほしい内容などありましたら、上記アカウントへ直接、もしくはハッシュタグ付きで放り投げてください。

当日の様子はこちらを追っていただければなんとなく雰囲気は見てもらえるかと（誰がTwitterで中継していただけるのかわかりませんが… 笑）。

こちらのイベントは事前登録などはありませんので、フラッといらしていただいても大丈夫です。1時間ほどのイベントです。こもりが緊張してガクブルしながら喋ってる様子でも見てやるか（ウシシ）、と思った方は是非銀座まで。

→ http://www.mdn.co.jp/webcre/d2s/