【Photoshop】非コーダーなWebデザイナーにお願いしたい11のこと


コーディングをして初めて分かるWebデザインの大切なポイント

世の中には二種類のWebデザイナーがいる。
コーディングをするやつと、しないやつだ。
by Webooker

お久しぶりです。Webooker(の中の人)です。

コーディングをしないWebデザイナーと接する機会が多い時期、Photoshopのデータで不自由を感じたことがあったのでまとめてみました。

私自身はデザインもコーディングもやるのですが、それでも完璧にコーディングフレンドリーなデザインデータを作成できているかは怪しいです。いわんや実際にコーディングをしないWebデザイナーはなおさらです。

そこで、「コーディングをするやつ」なWebデザイナーとして、「ここに気をつけてくれたら効率があがる」「ここがちゃんとしてないとコーディング時に困る」というポイントをまとめましたので、”専業Webデザイナー”や”新人Webデザイナー”、DTP畑からWeb畑へのシフトを考えている方たちの助けになれば幸いです。

※もし間違ったことを書いていたらTwitterなどで教えてくださいませ。

おしながき

フォントまわり

シェイプ関連

全体

フォントサイズはキリの良いサイズにする

フォントを拡大縮小した名残なのか、12.53pxなどの半端な数字になっていることがあります。フォントサイズの変更は拡大縮小ツールではなく、「文字」パネルから手動で行ってください。 Webでは12.53pxなどの半端なサイズを決め打ちで指定することはまずありません。(レスポンシブデザインのサイトの場合、自動的にそういうサイズになることはあり得ますが、敢えて半端な数値を指定することはありません。)

ダミーテキストに「□」などの記号を使わない

ダミーテキストに記号を使うと折り返さずにはみ出す

ダミーテキストを使ってデザインをする際、「□■●(記号)」を使ったものを見かけたことがあります。これをそのままPhotoshopからコピーしてコーディングに使うと、文章が折り返さないため、デザインが崩れてしまいます。(崩れの原因が分からず小一時間行き詰った悲しい思い出…。)

別のところからダミーテキストを用意する手間が増える(※)ので、最初から「この文章はダミーです。」といった普通のテキストが入っていると嬉しいです。

※ちなみに、テキストエディタに拡張機能のEmmetを入れていれば、ダミーテキストの入力が非常に楽です。(英文ですが。)
参考:Emmetを使用してダミーテキストを作成する – Qiita *

デバイスフォントなら「ヒラギノ角ゴ」か「メイリオ」、画像で切り出して欲しいフォントはそれ以外でデザインする

デバイスフォントに充てるフォントはその時々で変わっていくかもしれませんが、今のところ「ヒラギノ角ゴ」(Mac)や「メイリオ」(Win)はデバイスフォントとしてコーディングすることにしています。

コーディング時に迷うのが、それ以外のフォントを使っている箇所。装飾があしらわれていたら画像で切り出しますが、単に文字だけの場合は画像で切り出すべきフォントなのか、それとも気分で変えたものなのか判断がつきません。

デバイスフォントとそうでないフォントを明確に!

装飾が要らないのであればデバイスフォントのほうが綺麗に表示されるので、「ヒラギノ角ゴ」(Mac)や「メイリオ」(Win)を使う方がいいと思います。もちろん、紙のデザインとはちがうので字詰は必要ありません。逆に、画像として切り出す文字は字詰が必要です。

※補足:最近はWinでも游ゴシック体で良いのかもしれませんね。
参考:Windows10のフォントを変更 | にゅーてみ

テキストエリアは改行で調整しない

テキストエリア内の折り返しを改行で調整するのは止めましょう。コーディング時にPhotoshopからコピペした場合、その改行を取る無駄な作業が発生します。

何よりデザイン時に幾ら調整したところで、実際は綺麗な文章の区切りで改行はしません。

例えばこういったデザインデータを作った場合。

テキストは改行で調整しない

このテキストボックス内の文章をコーディング時にコピーアンドペーストすると―。

改行されたテキストデータを流し込んだところ
改行されたテキストデータを流し込んだところ、テキストエディタ(右側)に不要な改行がそのまま残っています。また、ブラウザ(左側)で見ると改行された箇所に不要な半角スペースが入ってしまいました。

この改行をひとつひとつバックスペースで消す作業が大変ですし、本当に必要な改行なのか(たとえば句点「。」で終わっているところの改行は必要そうに見える)を判断する手間もかかります。

というわけで、不要な改行はなくしましょう!お願いします(´・ω・`)

角丸シェイプを拡大縮小する際の処理

CSSで簡単に角丸を実装出来るようになったこともあり、デザインに角丸が登場する頻度も上がったような気がします。角丸シェイプを拡大・縮小ツールでそのまま変形してしまうと、角丸の形が歪んでしまうのをご存知でしょうか。

角丸シェイプのサイズを変えたい時は、パス選択ツールで拡大したい方向の2つの角を選択し、それからカーソルキーなどで調整しましょう。

…と書いたところで最新のPhotoshop(2015.5)で確認したところ、角丸の半径を保ったまま拡大縮小するように仕様が変わっていました。CS5くらいまでは歪んでいたようないないような。というわけで新しいPhotoshopを使っている場合は全く気にしなくて良いですね。

シェイプはラスタライズせず、ベクターをなるべく残す

なぜラスタライズするのか分からないのですが、例えば角丸背景をリサイズしたい場合にラスタライズされたレイヤーだと舌打ちしたくなりますw

デザインデータは常に変更がきくように保持していると応用が効きます。「デザインはこれでFIXだ」という場合にも、ベクターデータをラスタライズしないで残しておいてください。コーディング用に少し長めのパーツが必要になる時や、角丸シェイプの角の丸さが何pxなのかを調べたい時があります。また、マルチデバイス対応のため何種類かの大きさを用意する必要があったりします。

Webデザイナー側が全部把握して用意するなら良いですが、急遽必要なサイズが判明してコーダーが作る場合でもベクターデータなら安心です。

逆に、最初からラスタライズされているデザインパーツはあまり使わない方が良いかもしれません。先述の通り、ラスタライズされたデータは汎用性が低いためです。

シェイプは全て「エッジを整列」にチェックする

「エッジを整列」にチェックをせずにシェイプを描画すると、端がぼやけてしまう問題があったのですが、こちらも最新のPhotoshopでは解決しているようです。

参考:「ピクセルにスナップ(エッジを整列)」で端がぼやけるのを解消

境界線は必ず「内側」に付ける

境界線を内側に!

200pxのボックスに「レイヤー効果」で1pxの黒い「境界線」を追加する、もしくは、「属性」パネルで境界線を描く色を選択すると、簡単に枠線のついたボックスができます。

ところが、この「境界線」には「外側」と「内側」というオプション設定があります。設定が「外側」になっていた場合、ボックスのサイズは202pxという中途半端なサイズになってしまいます。

コーディング時に悩むのが、境界線の設定ミスによるハミ出しなのか、敢えて設定された+2pxなのか、です。 もし敢えて設定した場合、コーディング時に計算が面倒になるのでなるべくキリの良いサイズにしてほしいです。 もしミスだった場合、正直にコーダーに申告しましょうw

もちろん、198pxのボックスを作って外側に1pxの境界線を付けるのはOKです。ただし、スマートフォン用のデザインの場合は2倍で作りますので、4px分削った196pxのボックスでやらないといけません。計算が面倒なのでやっぱり200pxのボックスの内側に境界線(1pxまたは2px)をつけるのが一番楽かと思います。

余白を統一する

これはコーディング関係なくデザインの美しさの基本かもしれませんが、場所によって余白のサイズが違うととても困ってしまいます。例えばあるセクションの下余白は30pxなのに、次のセクションの下余白は40px、その更に次のセクションの下余白が50px空いている場合などです。

コーダーは1pxのズレを気にする世界です。場所によって余白が違っても、それがデザインならと全部測って設定してしまうかもしれません。各セクションごとにクラス名を付けて、更に別々のmargin-bottomを設定して…といった冗長なコードを書かなくてはなりません。

セクションごとの下余白は30pxで統一、各セクションの見出しの下余白は20px、などと共通化をお願いします。

コンテンツの横幅を統一する

コンテンツの横幅を統一する

先ほどの余白と同じかもしれませんが、各ページ・各コンテンツごとに横幅は共通の数値に設定しましょう。よほど奇抜なデザインでなければ、コンテンツの横幅は同じことが前提です。

写真のサイズはキリの良いサイズにする

画像はキッチリサイズでマスクする

提供された素材写真をそのまま縮小して配置しているときなどに起こりがちですが、写真のサイズが233pxなどになっていることがありました。これも230pxのシェイプでマスクするなどし、キリの良い数字にしてください。

  • 画像をそのまま変形すると端がぼやけてしまうことがある(上記の画像参照)
  • スマホ向けサイトのコーディングの場合、奇数だとretina対応できない(2倍サイズで切り出して1/2サイズを指定するのですが、奇数だとそれでもぼやける)

といった問題点を回避するためにも、キリの良い偶数に設定しておくのが無難です。(敢えて半端な数値にするメリットがない。)

まとめ

いかがでしたでしょうか。

「そんなの基本でしょ」ということから「鬼の姑チェック」のようなことまで色々言いましたが、デザインしかしないWebデザイナーが少しでもコーダーフレンドリーなデザインデータを作ってくださるように願っております。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA


*