ここ最近、有料版に出席していたものの機を逸してBlogをUPせず状態・・・いかんよなあ。途中まで書いて力つきるという情けなさ。

…ということで、「鉄は熱いうちに打て」ということで、さっそく覚え書きという名のレポート。

今回はWebデザインやコーディング技術に関する話というよりも、意外と知られていないアルファベットや欧文の表記の仕方など、デザインを考える上で非常に重要なタイポグラフィの話です。

私自身は建築系のデザイナーから出発しており、その業務の中で若干のDTP制作や、学生時代に写植の初歩中の初歩を教わったり、タイポグラフィの授業があった程度なのですが、Webデザイナーはフォントの扱いについて、あまり丁寧ではないと言われています。
これはMacやWinがDTP業界に進出し、ベタ打ちのままでもそれなりにできてしまうからという側面がありそうですが、その中でも「なんとなーく」流し込んでいるアルファベットや欧文に関する話です。

正直、欧文に関しては「なんとなーく」入力していたので、目から鱗な数々です。
以下、各セッションのタイトル部分の人物名は敬称を省略させていただいています。

【知って得するアルファベットの基礎知識】スピーカー: 高岡昌生（有限会社嘉瑞工房）
タイトル通り、アルファベットの始まりや活版印刷などの初歩的知識を紹介されていました。
簡単に…とはいいつつも、非常に興味深い話も多く、私たちが「なんとなく」使っている言葉の中には、活版印刷時代の状況から名付けられたものや、アルファベットは当初大文字しかなかったことなど、アルファベットというものを考える時に知っておいた方が良い話が満載でした。

一例を挙げると

1. 大文字はCAPITAL、小文字はlower caseと呼ばれる
2. 最初は大文字、以降は小文字で組むのはCap & low
3. 全てを大文字で組むのはall caps
4. small capsは大文字の形態を持ちながら、小文字のサイズを持っている。当然、文字の太さや幅が調整されているので、CAPITAL（大文字）を単に縮小して使うと太さや幅がおかしくなるので、やってはいけない。

また、「lower case」という名前は、活版印刷に使う小文字の活字が手前のケースに入っていたため呼ばれるようになり、現在もその名称が生き続けているらしい。

こういう一例を見ると「そういう意味だったんだ！」と目から鱗がこぼれまくり。
この講演は基礎知識の本当のさわりで、深堀すれば非常に奥が深そう。
「欧文組版 組版の基礎とマナー」という書籍が発売されており、組版を勉強するなら手に入れておきたいところです。

有限会社嘉瑞工房は活版印刷も依頼することができる希少な印刷会社です。少量でも時間をかけて質の高い印刷物を作ることをモットーとする同社と高岡氏にふさわしく、すばらしい名刺を頂くことができました。

印刷会社の方から名刺を頂いたことは何度もあるのですが、だいたいがインクジェット製で、今回のように頂いて「すてきな名刺！」と思ったのは、本当に久しぶりです。
インクジェットは大量に安価で制作することが可能ですが、やはり技術に基づいた製品は本当に感動します。

【欧文を扱う上での誤りやすい例】スピーカー: コン トヨコ
高岡氏のセッションに引き続き、目から鱗がぼろぼろ落ちるセッション。自分がモノシラズということがはっきり実感できます。
事前にいくつか問題が出されていまして、それの正誤解説だったのですが、これがもう…。本当に自分はモノシラズ炸裂で、全然わからないままやってたんだなあと強く反省。

他にもいろいろ例題があり、1番目の回答を示された時に「うわーーー。結構やってるよ」と思うことしきり。
欧文の場合「〜」や「ー」は使わない。この場合はEnダッシュ(Option+-(「わ」の右隣)｜Alt+0150を使用するのが正しいらしい。
また、am,pmはa.mとp.mという表記が正しい。
2番目はインチ換算なのだが、小数点という表記がなく分数で表す。主に分母は8/4/2で表示（16/32の場合もある）されるとか。
最後の省略のアポストロフィーは左向きが正しく、右向きはあり得ないらしい。

その他、

1. イタリック表記をする場合は、無理矢理イタリック表記（WordとかPhotoshopとかの設定で斜体にする）にするのではなく、イタリック書体を指定する。
2. 日本語の三点リーダーを使用せず、エリプシス（Option+;（Lの右隣）｜Alt+0133）を使用する
3. 半角引用符【’ ‘】ではなく、英文引用符【‘ ’】を使う。半角引用符は欧文組版では使わない
4. 文章の冒頭に頭文字が小文字であるプロダクト名や会社名がきた場合は、大文字にせず小文字にすることができる（ex.iTunes,adidas,ebay…）

などなど…。
例題はこの他にもあり、自分が非常に間違っていることに気がついたorz…
自分が今まで何となく流し込んできたテキストの多くは、やはり記号の使い間違いが多かった。

コン氏もこの前のセッションの高岡氏も同じことを言っていたが、日本企業の英文サイトには非常に間違いが多く「こうしてはいけません」というサンプルになってしまうそうだ。

英文表記がある場合、その綴りについては非常に気を使うが、それ以外のもの、特に記号の扱いや本来イタリックで使えるフォントタイプなのかどうかの校正はほとんど行われたことがなかったし、自分自身もそういう概念がないままテキストを流し込んでいたと思う。

モノシラズを改めて実感する講演だったし、非常におもしろかった。

【Webデザイナーのための欧文フォント入門】スピーカー: ヤマダコウスケ（PETITBOYS）
フォントブログで有名な方ですが、トレンドな欧文についての講演。

私たちが多用するArialとHelveticaとの熾烈な戦いや、Comic Sansの嫌われっぷりなど、フォントを巡る面白い話が聞けました。
また、日本語従属書体（欧文書体ではなく日本語書体）の単独使用はさけるという話もあり、聞けば聞くほど欧文も日本語もごっちゃにしていた自分のモノシラズ度が測れるというもので…orz…

個人的にはComic Sansの嫌われっぷりが半端ないので、かなり面白かったです。
このフォントは名前からして、コミックの吹き出しに使うにはいいと思うのですが、コーポレートサイトとかには使えないなあ…という書体です。
でも「ban Comic Sans」なんていうサイトもあるぐらいで、フォント制作者は「なんでそこまで…」という感想らしいです（苦笑）

【The Web Fonts】スピーカー: 小山田 晃浩（株式会社ピクセルグリッド）
鼻血が出そうなほど気になる最近のマイブームの一つ、Web Font。
Google Font APIの記事は過去に書いたことがあるんですが、最近はクラウドのWeb Fontのサービスが出てきて、かなり使いやすくなりました…とはいうものの、実案件では費用とかの問題で当分使えなさそうなのですが。

それにしても「オロナイン」のサイトは結構好きだったのですが、Web Fontなのは見落としていた。だめじゃんorz…

やはり日本語はたくさんあるし、フォントのライセンスも結構ややこしい。
勿論、商用使用可能な日本語フリーフォントはあるし、サブセット化すれば容量は圧縮される。
氏のブログ「ヨモツネット」には、Web Fontとして利用可能なフリーの和文フォントが紹介されている。
ここを参考にするのもいいと思います。

実務で使うのは大分先になりそうだけど、個人的には使ってみたい、興味津々。
個人的にはフォントプラスはどうかなと思ってますが、まあ、その辺りはお財布と相談です。

Web Fontがもっと自由に使えるようになると、更新時の作業が短縮できそうな気がする。
でも、メインとなる文字に関して、文字間とかを調整したいと考えると「うーん」な感じ。
どうやらjsで文字間などを調整できるみたいだけど、ちゃんと調べてBlogに覚え書きしようかしら。

数年前に比べて、Web Fontの実装に現実味が帯びてきたので、これからも楽しみな内容です。

今回の講演は、デザイナーならぜひ聞いておきたい話ばかりでした。
自分も含め、Webデザインというと最新技術に目がいきがちですが、基本中の基本を吹っ飛ばしてしまうと、後で苦労することも出てきます。
欧文フォントの約束事などは、Webに限らずデザイナー全般があまりよくわからない部分が多いところです。
情報の整理も兼ねるデザインの仕事としては、細かいお作法を押さえておいた方が、より正しくレイアウトできると思うのですが…本当に目から鱗が炸裂で面白かったです。

この講演を聞いていて、ふと思い出したのは資生堂のデザイン室の話です。
資生堂のデザイン部門に配属されると、新人が最初に必ずやらなければならないのが「資生堂フォントをレタリングする」ことらしいです。
なぜ、その作業をさせるのかというと、フォントのプロポーションを正しく理解するためだそうで…デザインにおいて、文字情報がいかに大切かという好例かと思います。

Webの世界も、色々な表現が可能になってきました。
そろそろフォントタイプに目を向ける時期に来てるのかもしれません。

さて、今年の課題の一つに「複数デバイス対応」というのが私の中にあります。
PCの他にスマートフォン・フィーチャーフォン（ガラケー）・タブレットとデバイスが増え、それら全てに対応する場合が多くなりました。
今のところ、各デバイスにあわせてデザインやコーディングをしているものの、更新効率などを考えるとワンソースで対応できた方が好ましいと個人的には思う訳です。

■モニター画素数

• iPad｜1024×768
• iPhone3G｜320×480
• iPhone4｜620×960
• Android｜480×720（機種によって違います）

SP（スマートフォン）については、現状で画素数が3つある。Androidに至っては、微妙に画素数が違うから少々厄介。画素数に合わせて画像を切り替えないと、iPhone3Gを基準として制作した場合、iphone4、Androidの場合は画像がぼやけます。
そこで使用するのがdevicePixelRatio。

iPhoneG3を基準として考えた場合、iPhone4は×2、Andoridは×1.5として考えます。Andoridは機種によって様々な画素数なのですが、1.5倍が妥当。
※参考サイト：「Android端末のdevicePixelRatio」

そこで、3種の画像を用意し、CSSのmedia queryを利用してそれぞれのCSSを適用させます。
※参考URL：「スマートフォンで解像度ごとに最適な画像サイズにするdevicePixelRatioの設定」

・・・・・面倒ですね。非常に面倒です。
なので、やり方としては、最大画素数にあわせた画像をCSSでサイズ変更して表示させる、という方法もあると思いますが、場合によっては表示が遅くなるので注意が必要です（私自身はこの方法を使ったことがありません）。

また、SPには「傾き」という動作があります。
傾けた時におかしなレイアウトにならないようにするには、この「傾き」を感知する必要があります。
※参考URL：「スマートフォンで傾きを検知するJavascript」

私自身がそうなのですが、デザイナーはjsに弱い・・・ということで、下記のTipsを利用することに。
※参考URL：「iPhoneで傾きに合わせてスタイルを切り替えるjavascript」

上記2つの方法を使うと、ある程度満足な結果が得られると思うけど、画像は最大6枚必要になるorz….

ちなみに、同じく「傾き」があるタブレットについては「iPhone Safariの固有仕様を調べてみる」を見ながら、上のTipsをカスタマイズするといいかと。
今のところ、iPadで傾けた時に問題なく表示されることが多いので、iPad用に「傾き」を検知させたことがなく、そのうちきちんと調べてblogを書く予定です。

また、PCと他のバイスの大きな違いの一つに「postion:fixedが使えない」という仕様がある。
どうしてもfixedを使いたい場合は「iScroll.js」または「Skroll.js」を利用するといいです。
私自身はiScroll.jsを利用したことがありますが、ちょっとした問題が・・・。

問題が起きた理由は、PCサイトのデザイン制作後、ワンソースでSPやiPadに対応するという後出しじゃん拳的な状況が起きたところから始まる。
PCサイトについては、お問い合わせフォームがあり、モーダルで個人情報保護方針を表示させる仕様になっていた。モーダルの選択も実装も自分ではなかったので、これがますます厄介なことになった。
iScroll.jsの場合、touchMoveイベントが無効になっているため、モーダル内のスクロールも無効となる。
これは悩んだ・・・。ひとまず、無効になっているtouchMoveイベントを復活させるとモーダル内のスクロールは復活し、postion:fixedも再現できていた。

この場合は、モーダルをやめれば良かったし、iPhoneやiPadでは別ウィンドウか同レイヤーに表示されるようにjQueryでhtmlコードを変更させれば良かったのだが、モーダル内のボタンとお問い合わせフォームが連動しているため、容易にその変更をすることができなかったorz…
で、苦肉の策がコレ。

ワンソースで複数デバイス対応するには、制作初期の段階で対応するデバイスをきちんと考えておく必要がある。
そうでないと意外なところで苦しむことにorz…
ただ、この問題が起こったおかげで、いろいろ知ることができたのがせめてもの救い。

今年は更に、多デバイス対応が加速する気配を感じる。
一昨年末(2010年)から去年(2011年)の今頃の状況を思い出すと、一昨年（2010年）末はPC/FP（フィーチャーフォン）対応。年が明ける(2011年)とPC/FP/SP対応。ただし、SPはiPhoneでちゃんと見えれば良いと言っていたのが、春頃にはXperiaにも対応してほしい、つまりAndorid系にも対応になり、年末にはiPadに対応する事案が発生した。
おそらく、今年はiPad以外のタブレットの対応も出てくるだろうなあ・・ますます実機が必要になるけど、お金がついていきませんよー（遠い目）

Webサイト制作の他にも、個人的には電子書籍やWebフォントに非常に興味がある。
今年の課題も盛りだくさんになる気配。

そんなことを思いつつ、ふと「Mac（Apple）とワタシ」のつきあいを振り返ってみたくなった。
あの頃は、まさかAppleのプロダクトがここまで生活に根ざすとは思ってもいなかった。
今では、MacもiPotも無くてはならない生活の一部だ。

はじめて触ることになったのは、1997年札幌の某企業。
【Power Macintosh 7300/180】という機種だ。
それまでPCなんてふれたこともなかったので、業務をしつつ使い方を覚えた。
就業末期にはキーボードのreturnキーを連続2台破壊するわ、突然OSが認識されなくなり、頭真っ白になりながら復旧するわ・・結構思い出がある。
この頃のOSは、漢字talkって呼ばれていて、この機種は漢字talk7.5、HDは2GB。
あの頃、作るデーターは軽いものが多くて、FDでデーターを業者に渡していた記憶があるなあ。
Illustratorは5.5、Photoshopは4くらいだったと思う。インターネットはまだなかった。
そして、初期投資として最初の1台目は、周辺機器もろもろ含め200万くらいかかったらしい・・と聞いた。
中小企業としてはすごい投資だ。

そして1999年。iMac登場。
Steve Jobsが中心となって開発された伝説的なプロダクトだ。
ここからApple復活が始まる。

この頃から、Macの値段もかなり安くなり、容易に手が届くようになった。
インターネットも庶民の手に届くものになり、23時から早朝まで定額制になる「テレホーダイ」というサービスも始まっていた。

そう、光でもADSLでもISDNでもない。この時は電話回線でネットをつないでいたのだ。
今から思えば、すごい低速度だったよね。
動画なんてみれたもんじゃないし、メールも重い添付ファイルなんて御法度だった。

プリンターやらスキャナやら、周辺機器を合わせて30万円で購入。
この時は、ニコニコ現金払いをした。場所は、今はなき札幌の大塚商会。
しかし、実際に手元に届いたのは1ヶ月後。この頃、iMacは爆発的に人気があり、5色iMacになってからは、ボンダイブルーの代わりとして一番人気のカラーだった。

私が買った初めてのMacで、これで初めてのインターネットをし、フリーランスを始めた頃には、この機種で図面トレースをした。
丸いマウスはあまり評判が良くなかったが、馴れると使い勝手も悪くなかった。

大分気に入っていたが、突然電源が落ちるようになり、フリーランスにもなっていたこともあって、タワー型Macを購入することになった。

それが【Power Mac G4 (Quick Silver)】なのだが、これを購入した直後に新機種が出るという不運が・・・orz…思えばiMacも納品を待っている間にRev.Dが出てしまったりと、どうも間が悪かった。
そのうえ、この機種の時についてきたOS Xは、まだまだ使い物にならなかった。

とはいうものの、このMacの顔は一番お気に入りで、現在も部屋にある。CPUはのっけ替えてるので純正品とは言い難いが、思い入れがあるし、なによりOS9が単独起動するので、処分できないままでいる。

この頃、液晶が市場に出てきた頃なのだが、Apple以外の液晶のカラーが微妙だったので、泣く泣く高い純正モニターを買った。

G4とディスプレイの購入は、まったくの予定外だったので、かなり懐が痛かった記憶がある。おまけに、購入1ヶ月後、プリンターまでお釈迦になり、再び出費した。
今でもそうなのだが、私の購入するのはA3ノビ対応なので、大きいし金額も高いし・・ともかくあまりいいことがないのだが、A3をプリントすることが多かったので仕方ないと言えよう。
今ならキンコーズで出力という所だろうが、この頃はそんなもの近所になかった。まだ、札幌にいたし。

そんなお気に入りのG4でしたが、やはりパワー不足と言うことで、【iMac (Early 2008) 20インチ：2.66GHz】を購入。
この機種は、インテルベースなので、Windowsも走るというすてきなMac。
それまでは、Windowsノートを使っていたものの、とても使い勝手が悪く、一台で二度美味しいこの機種は、IT系の仕事にシフトしていた私にとって、まってました！な機種でした。そして、現在も自宅で絶賛使用中。

ただ、少し前から、ファンが異常に動くことが時々あり、そんな時は辟易していたりします。
ファンが異常に動く時はSpotLight のインデックス作成をしてる場合が多いようですが。

そして、次に購入したAppleのプロダクトが【iPot(第3世代）】。
元々音楽を持ち歩かないせいか、大分後になってから購入した製品。
今では外出時には必ず持ち歩くので、買わず嫌いだったのかなーとは思ったりします。
今じゃ完全な生活の一部。

そして、次に購入したのが【Mac Book Air】。動機は税金対策。・・・だったのだけど、結局購入してよかったね、な機種になりました。
帰省時にこれで仕事したり、セミナーに出動したりとフル回転で働いています。
ただ、最近11inchが出たので、そっちが欲しいと思ったりして。

そして現在。
勤め先では【Mac Pro】を使っている。
元々はCTOの持ち物だったが、後に会社で買い上げとなった。

業務のわりにマシンパワーがあるので、高画質の画像を取り扱うのは非常に楽だ。

こうやってみると、本当にお世話になってるなあ。
というより、Macがなかったらデザイナーにはなれなかったかも。
なにせ、トンボも満足に引けない専門学校生だったからなあ・・・と回想してみる。

Steve Jobsは、私たちが見た事のない地平線の向こう側が見えていたかもしれないが、今となっては、そのビジョンを見る事はかなわない。

人が亡くなると「ご冥福をお祈りします。」という言葉を多く見るが、Steve Jobsに対してはしっくりこない。

Thank you, Steven Jobs

この言葉が一番ぴったりなような気がする。

ありがとう、Steven Jobs。

過日、CSS Nite LP,Disk17及び18が開催されました。
この二つを聴講すると13：30〜20：00という長丁場になるものの、どちらも気になる内容なので参加しました。
私的意見バリバリのレポートです。
これはあくまでもワタシの主観なので、講演を受けられた方は色々と思うところもあるでしょうが、こういう見方もあるってことで。

CSS Nite LP, Disk 17「HTML5による電子書籍」については、国内での状況と実際に電子書籍と制作時のトライ&エラー、電子書籍のためのWebLayoutという事で、電子書籍にとどまらない「複数デバイスにおけるデザイン」という感じの内容でした。
本格的な電子書籍制作という点では物足りない内容ではあったかもしれませんが、電子書籍というジャンルがそれほど活用されていない雰囲気の現時点では、将来を見据えた形の今回の講演で良かったのではないかと思います。

今回、電子書籍の講演で一番期待していたのは金内 透氏の【『ナストマ・マガジン』制作のおけるトライ&エラーの共有】の一節です。

長らくデザイナーをしているにも関わらず、こう言った講演に参加していなかった理由は、非常に多忙でスケジュール調整がつかなかったところが大なのですが、もうひとつ「（持ってる案件内では）実務に取り入れることができる内容が少なかった」というところがあります。

これは、受注している案件の業界的な傾向が左右する部分があると思うのですが、保守的クライアントの承諾を得られない、制作期間がタイト過ぎて、ターゲットとなる全OS／ブラウザ上での同一閲覧の担保ができないなどの理由により、新しい技術などが使いづらい場合があったりします。
そのため、新しい技術はあえて使わず（情報自体を仕入れない事もかなりある）、古い技術を使い続ける・・ということも結構多いのです。

制作上のトライ&エラーというのは、個々で経験を積むしかないところもありますが、まったく知らないまま制作に入るのと、ひとつでも知っているとでは、その後の動きに大きな差が出ます。
制作者としては、手戻りをいかに少なくして高品質な制作物を仕上げるか、ということは非常に大事なところです。
そう言った意味で、他スピーカーの講演も非常に楽しみにしていたのですが、はっきりと「トライ&エラー」の講演である、という金内氏の講演内容は私としてはうれしい限りでした。

ちなみに、「ナストマ・マガジンvol.1」は、この記事内のリンクから見ることができます。
iPad限定なので、PCでは正しく見ることができません。iPadをお持ちの方には是非見て頂きたい。所持していない場合は、iOSシミュレーターでも閲覧可能です。
iPadを縦から横に傾けると、ちょっとした仕掛けが出てきます。こういった小さな「しかけ」が電子書籍の持ち味だと思います。紙の書籍ではできないことをやる、というのが電子書籍の使命の一つでもあるでしょうし。

デザイナーとしては、境 祐司氏の【電子雑誌のためのWeb Adaptive Layout】も絶対に外せないところ。
「ウェブマガジンと電子雑誌の違い」という部分でレイアウトが変わってくる、それはなぜか？
また、複数デバイスを見据えた場合、どのようなレイアウト調整が必要か？など、今後ますます増えるであろう、デバイス毎のレイアウト設計を考える上での重要なお話しを聞くことができました。

この講演内で「blogエントリーへのコメントが、エントリーより有益な内容であった場合、＜section＞でマークアップする方がよい」というような話には笑いました。エントリーより有益なコメントって（笑）　
でも、そういうblogがあった場合、＜aside＞ではなく、＜section＞でマークアップする方が文脈的に正しいというのは本当のことで、文章内の重さによって、マークアップが変わってしまうと言うのはhtml5の特性なのかもしれません。

後半はCSS Nite LP, Disk 18「その先にあるjQuery」。

実際に制作されたサービスを例にjQueryの高速化と、「ポチってもうた」制作時の設計に関する考え方を題材に講演されました。

Twitterでもつぶやかれていたのですが、jQueryの高速化については、PGにとっては「知っている」もしくは「本で読んだ」という内容であり、jsに弱いデザイナーにとっては「追うのがやっと」もしくは「お手上げ」と言った内容だったようです。

すべてのデザイナーに該当することではないですが、デザイナーはスクリプト系が苦手な人が多いです。
現在所属しているシステム制作会社では「デザイナーはjsもぐりぐりかける」という都市伝説が、一部でまことしやかに流れていたようですが、それは間違いですww　少なくともワタシは無理です。

ワタシ自身が、元々建築関連のデザイナーで、webの知識等については独学+実務経験で培った（それもすべてフリーランスの一匹狼時）と言うこともあり、jsに関しては非常に弱い。また、知り合いのフリーランスにしても、jsについては弱い人が多く、知り合いの企業にしても、別途javascriptデベロッパーがいるというのがデフォルト。
もう一つおまけに語ると「PGはjsもぐりぐりかける」というのも認識違いぽいらしく、実務の環境下によっては「それほどかけない」場合もあるそうです・・ただ、彼らの「ぐりぐりかける」能力の基準がどの程度を指しているかがわからないため、おそらく、デザイナーの言う「それほどかけない」認識から見ると、とても書けると思うんですけどね。

jQuery発生以前と後では、デザイナーの作業領域は爆発的に増えたと私は思います。
以前はFlashなどで行われてきたものが、jQueryを使うことである程度実現してしまう現在、デザイナーもjsは全く書けないとは言っていられない状況に入ってきたような気がします。
そういったデザイナーが対象の場合、今回の講演「jQueryの高速化」は有益な話であったと思います。

また、「ポチってもうた」を例にリッチウェブアプリケーションの設計手法が紹介されたのですが、これはアプリケーション制作時だけではなく、cssなどの設計にも言えることだと思いました。

簡単に言ってしまうと、小さな固まりを連結して、大きな一つのサービスを作るということなのですが、この設計を使えば、何らかの問題が起きた場合、その原因が比較的見つけやすい事や、パーツごとの流用が可能であることなど、次に続くより良い制作環境を構築するという意味で、色々なものに流用できる考え方だと思います。

************************************************************************
個々の習熟度によって、この講演を評する言葉は様々だと思いますが、私個人としては、期待以上の講演だったと思います。

CSS Nite LP, Disk 17「HTML5による電子書籍のタイトルにもあるように、今後ますますHTML5は現場になだれ込んでくると思います（私自身はすでに実務に組み込んでいるのですが）。

電子書籍、複数デバイスの対応など、物作りの世界はますます広がり、デザイナーと呼ばれる人たちも、今まで以上の技術と知識が必要になってきました。
まあ、私は毎年「これ以上覚えられない！おなかいっぱいいいい！」って叫んでいるんですが。
かれこれ10年強、叫んでますね ｳﾜｧｧｧｧｧｧヽ(`Д´)ﾉｧｧｧｧｧｧﾝ!

今後、国内の電子書籍市場はどうなるのか？スマートフォンやフィーチャーホンのユーザー数はどう推移していくのか？などなど、制作をするうえで色々と動向が注目されますが、「はらいっぱい！もう、無理。絶対無理！」とかいいつつ、別腹対応で情報収集していくしかないのでしょうね・・・・と黄昏れてみるorz….

嗚呼。
それにしても長い記事だ。
途中まで書いて「ふたつに分ければ良かったorz…」とか思いつつ、ながなが・ずるずる書いてみた(￣▽￣;)

CSS3にはグラデーションが設定できるので、Firefox・safari・chromeについてはcss3で、IEには独自フィルタでグラデーションを設定する事にした。

そこで問題が発生。

IEにおいて、a要素のdisplay:blockが効かない事が発覚した。

テストソース：IE独自フィルタ使用をIE6-8でためしてもらいたい。

リンク領域を拡大しているはずなのに、IEではカーソルは指にならない

テキストにカーソルを持って行くと、IEでも指カーソルになる

cssにはdisplay:blockとzoom1が設定されている。
通常、この設定だとリンク領域は拡大され、ボタンと同じような挙動にになる。
だが、今回の場合は領域がうまく拡大されていないようだ・・と思い、WebDeveloperで確認してみる。

Web Developerで確認したら、リンク要素blockになってるよ！

・・・・なんで？
領域は拡大されてるのに、なぜボタンのような挙動にならないのだあああーーーーー。

—*—+—*—+— 小一時間経過 —+—*—+—*—

なぜ、リンク領域が拡大されないのか？
どうやら、IEの機能拡張を使った事に原因があるらしい。
そこで、IE用には背景にグラデーション画像を用意してみた。

テストソース：IE独自フィルタを使用しない！を参照して下さい。

IEでも大丈夫

なんてこったいorz…..

a要素のリンク領域を拡張する場合は、IEの独自フィルタ使っちゃ駄目ってことなのね。なんて面倒なorz….

というわけで、IEにはグラデーション画像を使う事で回避するしかなさそう。
あいやー。

大まかな内容としては

1. 配色ではなく色彩設計をしよう
2. サイト運用のための色彩設計
3. 実例10歳とから学ぶ色彩設計

の3つ。

坂本 邦夫氏については、ウェブ配色ツール Ver2.0などでも有名で、webデザインではあまり語られない「色彩計画」についての専門家です。近著にはウェブ配色 コーディネートカタログ（技術評論社）などがあります。

色彩計画には3つの要素があり

1. 機能的な色彩
2. 視覚的な訴求力
3. 色彩戦略

これらに基づいて色彩計画をして行きます。

セミナーに参加しての感想ですが、今まで経験的に培ってきた内容に関して「それでよかったんだ」という確認ができてよかったと思います。
私自身は専門学校時代に色彩計画の授業があり、最低限の色彩計画についての知識はあったのですが、何ぶん大分前の知識だったため、「これでよかったのかな〜」と思う事しきり。
そういう部分がクリアになった事で参加したのは正解でした。

このセミナーについての報告ブログがいくつかあるのですが、意外だったのが「白黒での確認」という部分。

デザインカンプを制作している時に、どうもしっくりこないなーと思った場合、白黒にして明度を確認すると、カラーリングを見直すきっかけがつかみやすくなります。
個人的にはデフォルトな作業だと思ったのですが、意外とそうでもなかったようで・・・。
まとまりがない、ぼんやりしてると思ったら、白黒モードにしてみると、どこを見直せばいいかわかりやすくなります。

webデザインについては、効率的なコーディングや斬新な動きなど、「技」の部分にフォーカスされたものが多いような気がします（私が読むwebデザイン系の月刊誌はそんな感じ）。
しかし、モニターの向こうにいるユーザーの事を考えれば、色彩計画を含めアクセシビリティをいかに優先させるか、それをクライアントに納得してもらうには、どういった材料が必要かという事も非常に重要かと思います。

勿論、「技」フォーカスのサイトが悪いわけではなく、ターゲットがどこにあるかで、その優先順位は微妙に変わってくるとは思いますが。

webデザインの仕事をしている人や志望している人には、是非参加してほしいセミナーでした。
残念ながら終了してしまったので、興味のある方はウェブ配色 コーディネートカタログ（技術評論社）をどうぞ。

先に強く主張しておきますが、私は坂本 邦夫氏や技術評論社さんの回し者ではありませんwwww

カスタムフィールドのカスタマイズプラグインは色々ありますが、Custom Field TemplateかCustom Field GUI Utility 3 – WordPress プラグイン – かたつむりくんのWWWが使いやすいかなと思っています。

Custom Field Templateはエディタ付きテキストエリアも設定できるのですが、今回必要だった画像専用イメージフィールドがない。
Custom Field GUIと違って、インストール後の設定は管理画面から行えるので使い勝手はいいようですが、設定方法についての説明を見つけるのが大変かも。

・・というわけで、今回はCustom Field GUI Utility 3 – WordPress プラグイン – かたつむりくんのWWWに軍配が上がったので、そちらのインストールメモ。

難しい事は何一つなし。
プラグインインストールして、wp-content>plugins>custom-field-gui-utility>conf.iniを設定するだけ。
そうすると美しいカスタムフィールドができます。

このプラグインはCustom Field GUIをカスタマイズ+日本語化されたものです。

このカスタマイズされたプラグインの大きな特長は

1. 3つのカスタムフィールドを使い分けできる
2. カスタムフィールドの表示名を自由に変更可能
3. 画像専用のイメージフィールドを搭載
4. ファイル専用のファイルフィールドを搭載
5. 複数選択可能なチェックボックスグループを搭載
6. 必須項目を設定可能
7. 区切り線が使用可能

・・・と盛りだくさん。
conf.iniを開かなければなりませんが、Custom Field Templateよりも設定しやすい+フィールドが盛りだくさんな印象です。

でも、どうしても使いたい時がある。
それで使ってみるとIE6+IE7 VS Firefox+safariになる。
Firefox+safari+IE8で確認すると、意図する場所ボックスが移動しているのに、IE6+IE7は全然違うところにある。

おおおーーいぃぃぃぃ・・・。orz..

検索した結果、親要素に100%を指定すると問題は解決する。

おのれ、IE。

もういやん。（汗

クリエイターボックスで紹介されていた「Web屋さんのための新年の抱負アイデア24」。

様々なアイディアが読めるのだけど、この中で思いっきりビンゴだったのが、「11. スマートフォン用サイトを作る」内にあった「スマートフォンサイトをデザインする7つのポイント」へのリンク。

ビンゴだ・・思いっきりビンゴ！

私自身は今のところスマートフォンは使ってないのだけど、仕事上制作する機会ができて、多分、これからも増えていくだろうという予測をたてている。
社内デザイナーは私一人だし、フリーランス時代の知り合いは、そもそも携帯サイトも作っていないし・・身近から手に入れるのはかなり難しいので、こういった記事はありがたい。

今は時間がないので、あとでゆっくりと読もうと思ってます。

ちなみに。
クリエイターボックスさんは、画像直リンクの記事まるごとパクられ被害を受けていて、twitterではちょっとした祭りになっていた。
パクり先はかなり悪質なようで、有名ブログから無断転用、さも自分が執筆したような体裁を取っているらしい。

そこで、クリエイターボックスさんは、おちゃめな報復をとる。
画像を直リンされている状況を逆手に取って、画像をうんこや動物イラストに入れ替えたのだ。勿論、元の記事の画像は名称を変えてUPされているため、本物には影響は出ないが、パクリサイトはかなり面白いことになっている。
パクリ文章は真面目な文面なのだが、画像がうんこやウサギやキリンさん。そして「ここの記事はパクリですよー」と宣言している。

しかし。
なんでパクるかなあ。
記事を一生懸命書いている人に対しての冒涜だよね。

私も色々なブログを参考にして、ここの記事を書く事が多いけど、転記した際は元ページをリンクするのは当然だと思っている。
記事を書いた人に対する礼儀だよね。

と、言うわけで。

携帯サイトの覚え書き。

1.デザインカンプを制作する場合、画面サイズはw240pxを基準とする。スマートフォンの場合は320px。

携帯の場合、機種によってサイズは様々なのだが、今のところこのサイズを基準として考えた方がいい。
今後は変わってくるかもしれないけれど、ひとまずこれでデザインカンプを作る。

2.デザインカンプ制作の際は、24px、20px、16pxで考える。

デザインカンプの制作にあたり、この情報が一番欲しかった。
PCとは違って、携帯の場合のフォントサイズ指定は、large、medium、smallの3つになる。
細かく言うと、xx-lageとかxx-smallとかあるけど、キャリアによって解釈が違うorz..　はっきり言うけど、PCサイトなんか目じゃないほど厄介！！！！！！！！
というわけで、large=24px、medium=20px、small=16pxで考える。

3.コーディングの際は%設定する。

こうするとモニターサイズに合わせて可変するので、とりあえずはなんとかなる。画面サイズによっては、画像はちょっと荒れるけど、前述のように容量縛りがあるため、あんまり画像をきれいに書き出しても「表示できません」と言われて、悲しい事に。
PCと違って、画像のきれいさはあまり考えなくてもいいと個人的には思っている。

容量にも注意。
特にauは、容量縛りがめいちゃめちゃ厳しい。XHTMLの場合の1ページは 9KB いないでなければならないという厳しさorz..。
先日も、そこで引っかかって、色数減らしたりして画像を圧縮。なんとか表示させた事がある。

また、tableの入れ子レイアウトもやらない方がいい。
auで確認したら、入れ子にした所がまったく表示されなくなっていたorz….

おのれ、携帯め。
PC以上によくわからーん！！

とりあえず覚え書き程度。
そのうち携帯・スマートフォンについての記事は増えるかもね。