時間を見ながらぼちぼちやっていましたが、
あんまりプロトタイプを引っ張りすぎると陽の目を見なくなるので、
（モノ作る時って何事も大体そうだよね）
とりあえずMUTTERのみリリース。
つっても、タグ周りとか古いままのページもありますけど。
今回デザインするに当たって考えたことは、こんなこと。
- エントリを見やすくする
- 情報を減らす、または整理する
- JavaScriptを必要最低限にする
長いことサイトで色々やってると、ゴミみたいなものが溜まってきます。
何かを試して止めたりとか、サイズや雰囲気合わないけどとりあえずくっつけてみるとか、
なんかそんなの。
そういうのを、棚卸し的な意味で一度整理してみようってことです。
次に何かデザインをするときに駄目出しできるように、
ポイントを自分なりにまとめておきます。
1. エントリを見やすくする
前回のブログデザインを見ていて、エントリが見にくいなぁと思うことが良くありました。僕なりに考えた結果でた、「なぜ見にくいのか？」の答えは2つ。
- 背景色と文字色のコントラスト
- 目線を支えるポイントの不足
背景色は薄いオレンジ、文字色は黒でした。
色合いとしては別に悪くはないのですが、白背景に比べると文字が浮き立たない。
全体的に何かぼんやりした感じが残ってしまいます。
また、そのぼんやりしたままスクロールしていくと、文字を追う“よすが”がなくなってしまい、
どこを基点に文章を読んでいけば良いのかがわかりづらい。
目の錯覚ではあるのですが、縦方向がそろっていないように見えてしまいます。
文字を追う“よすが”というのはどんなものかというと…簡単に言えば、ラインです。
例えば、良くあるB4ノートの場合、文字を書く補助線として横罫線が引かれています。
この線があることによって文字の下端が揃って書きやすく、読みやすくなります。
また同時に、この横罫線は縦方向に揃っているということも見逃せません。
それによって上から下へ文章を追うときにバランス良く視線を移動できます。
とはいえ、WEB上で横罫線を引くのはあまり現実的ではありません。
もちろん背景画像を用意し、文字の高さをpxで規定すれば実現は可能ですが、
画像やblockquoteなどの要素を入れにくいという欠点があります。
ではどうするか？
WEBでは始めから文字の下端は揃っています。なので必要なのは縦の補助線だけです。
これは別に特別なことでも何でもなくて、多くのサイトで実践されていることです。
いくつか例を挙げれば、
- 画面左端をテキストの基点として利用する
- テキストの左に配置した画像の右端を基点として利用する
- テキストを囲むブロックのボーダーラインを基点として利用する
- テキストを囲むブロックの背景色と、ページの背景色の差を基点として利用する
といった感じになるでしょうか。
どのサイトを見ても、このいずれかないしは全てが利用されているはずです。
では何故僕が前回のデザインでそうしなかったかというと…
縦にラインを引くのは難しくはないんですが、
テキスト以外のうるさい部分があるのが嫌だったんですね。テキストだけを表示したかったんです。
で、それが裏目だったというわけ。
画像を多く含むようなエントリや、定型的なエントリではそんなに見づらさを感じませんでしたが、
テキスト主体のエントリではCSS装飾の未熟さも相まって見づらかったのです。
そういうわけで、今回は「枠」を用意して、エントリ部分とそれ以外の部分を明確に分け、
同時にラインとして機能するようにしてみました。
昔のエントリを見返すとまだまだ微妙ではありますが、
その辺はきっとエントリを書くに当たっての演出能力の問題かなぁ。見出しとか。強調とか。
今回、CSSファイルもかなり整理して、その辺の追加もしやすくしているので、
徐々にやっていければ、と思っています。
こんなのとかね。
2. 情報を減らす、または整理する
前回からの情報の変動は、こんな感じです。- トップページ
- [+] Hot Tags
- [-] Recent 15 Mutters
- [+] Previously
- [+] Hatena Bookmarks
- [-] Recent Comments
- [-] Recent Trackbacks
- [-] Flickr Badge
- [+] Flickr
- [+] Categories
- [+] Profile
- [?] About Me
- エントリページ
- [+] Disqus
- [-] Comment
- [-] Trackback
- [+] Previously
- [+] Categories
- [+] Profile
まず、幅を広くしたことを書かないといけないですね。
これまでの常識では、
サイトの幅は800*600のモニターで見てスクロールバーが出ないように、
760px程度に収めるべきとなっていました。
まさにそのモニターを使っている友達がいたこともあって、
僕としては公私ともにその常識で動いていましたが…さすがにもう良いかと。
調べてみると現代のサービスは「幅1000px」か「全画面表示」かのどちらかが多いです。
- 全画面表示
- 幅固定（括弧内は幅、単位px）
幅が広く使えるならそれに越したことはないので…
ということで、幅1000px（遊びが左右20pxずつあるので実際には960px）を採用。
またリニューアルで無くなってしまいましたが、
僕はニコニコ動画のヘッダーバー（右上がいたとこ）がデザイン的に遊びがあって好きだったので、
その辺をイメージして情報バーをヘッダとフッタに設置（ここは全画面です）。
まだ適当な作りですが、なにがしか追加する予定です。
コメント/トラックバックについては、Disqusを導入することにしました。
これは以前TechCrunchで紹介されていて、
先日Ogawaさんが導入エントリ（およびツール群）を書かれていたサービスで、
コメントを自分のブログではなくサービスに管理してもらうというものです。
メリットは…SPAMなどに困らなくて済むことと、
コメント入力の手間が大幅に軽減されることですかね。
コメントを入力してみると解りますが、ページ遷移無しで非常に簡潔に終了します。
これまでサーバの影響かコメントが殆ど機能していなかったので、個人的に嬉しいです。
（コメントが付かないのはまぁいいんですが、処理が激遅だった）
テンプレ作成の手間も省けますし。
その他には、Flickr周りとか。
今までオフィシャルのブログパーツを、
CSS解析→CSSで無理矢理配置換えとかしていましたが、
JavaScriptが重いというのもあるし、そもそも融通があんまり利きません。
というわけで、自分で作っちゃいました。
ここでは詳細については省略しますが、要するにAPIを使って直近のデータを取得した上で、
ランダムにピックアップするということをしています。
利用しているモジュールはこの辺。
phpFlickr
あと、前回いったん削除していたカテゴリー一覧を復活させてみました。
やっぱり何かと便利だったりするので…
ただ右メニューに置くのは微妙だなーと感じていたので、ページフッターに同化させました。
最近のエントリもここ。
こちらは利便性からいうと右メニューにあるべき情報かもしれませんが…
サイトを訪れる人の85%が検索エンジン経由で、トップページはそれほど重要ではないので、
それなら常にしたにある方が良いかなぁと言うことで。
ちなみにこの辺のページフッターの使い方も、
Disqusですっきりすることがあってこそのこと。
普通にMovableTypeのテンプレートで考えると、アレ結構コメント周りの構造が複雑なので、
ちょっとだるいです。
それが何行かのコードだけで収まってCSSもシンプルと来れば、
デザイン的に見ても、使わない手はないです。
3. JavaScriptを必要最低限にする
これはあくまでオマケ的な話なんですが、このせいで前回少し重かったので。何で重かったかというと、次の2つを実装していたからです。
- リンクされた画像に出てしまう余分なアンダーバーを消す（CSS構造の問題で回避が難しかった）
- Flickr Badgeで表示される最後の画像は犬の写真に差し替える
どちらもDOMを使っているので、IEだと時間が掛かることがあったんですね。
2つ目はFlickr Badgeを使わないことで解決できました。
（というか、犬の写真の表示場所を変えたので必要もなくなりました）
また、ロード時に実行するプログラムの呼び出しが面倒になっていましたが、
prototype.jsを使って、Event.observeを利用することで交通整理が楽になりました。
prototype.jsを使ってみる 2-Event.observe[to-R]
※ すみません、間違ってました。1つめは現在も絶賛活動中でした。
※ 「getElementsByTagName」ならあんまり遅くならないみたいですね。
※ ちなみに正確には、rel=”lightbox”がついた画像に、アンダーバーを消すクラスを付与する、です。
過去エントリとのCSSの整合性とか、
コメントのDisqusへの移行とか、やることはまだありますが、
とりあえずは一段落付いたのでぼちぼちやっていこうと思います。
