[トラックバック歓迎] ユーザ(閲覧者/訪問者)は本当にタグを使っているのか

WordPressに限った話ではないけれど

WordPress 2.3でタクソノミー(タグ機能)が追加されて以来、タグ、タグ言うて、おでげぼののもタグクラウド、おりおあぷらどりもタグクラウド、チョッパーも杓子もタグクラウド(←これが言いたかったらしい)、といった感じでタグ花盛りですね。 ((あれ、ひろろNaoさんはタグ使ってない!?))

そんな感じなわけですが、MinamiさんにTwitterしたときふと気になりました。

はたして、ほんとうにユーザ(閲覧者あるいは訪問者あるいはビジター)ってタグ使ってくれてるの?タグクラウド表示やタグを付けてる意味ってあるの?投稿するたびに、せっせとタグ付けしてるのに、使ってくれてなければ意味ないんじゃ?

一度気になりだすと止まらないので、さっそく調べてみたよ。

アクセス解析といったらGoogle Analyticsだよね

カテゴリのような、記事がどういう分類に属しているかを示す指標、という使い方ももちろんあるわけですが、ここではタグURLやタグクラウドを使ってくれているかどうかに絞って分析してみます。

これはどちらも、タグURL(ex. http://example.jp/archives/tag/hogehoge/)にアクセスがあるかどうかで図ることができそうです。

さっそくGoogle Analyticsを使って、1ヶ月のおでげへのアクセスを分析してみました(※ログインユーザへはGoogle Analyticsの解析コードを読み込ませないようにしているので、以下のアクセス数に管理者である僕のアクセス数は含んでいません)。

先生、タグURLへのアクセスがありません!

2008年7月26日から8月25日までの、このサイトへの有効な総アクセス数(スパイダーやボットを除いたアクセス数)は15,581でした。なんだか、ちょっとどころかだいぶ減ってる気がしますが、まぁ更新ペースもだいぶ落ちてるのでしょうがないところでしょうか。

同様にタグURLへのアクセス数は143、カテゴリURLへのアクセス数は130しかありませんでした。

 Google Analytics 分析結果

グラフにすると、上の図のような感じ。

なんと、タグURLへのアクセス数は全体の0.9%しかないのでした!タグ機能、使われてないじゃん!(カテゴリもだけど)

タグ機能は不要なのだろうか?

Delicious Bookmarksでのタグによる分類は非常に重宝しているので、タグの有効性は理解しているつもりですし、そう何より自分のブログのユーザには自分自身も入っているはずです。自分用のメモ、とかしますしね。その際にタグは役立つかも。

だから、アクセスされてないことが、即タグ機能が不要というわけではないでしょう。

このブログのユーザはタグの意味を分かっていない、という可能性もあるかもしれません。普通のブログなので記事を読めればよくて、別の記事を求めることは少ないのかもしれません。はてブやニコ動のようなギークの利用者が多いサイトではある程度有効に機能しているのかもしれません。

しかし、しかし、残念ながらこのブログでは利用されていない、という事実に変わりはありません。

みんなのサイトはどうなの?

みなさんのサイトではどうでしょうか?利用されていないのは、おでげだけ、という可能性だってあるのかも。ぜひ、アクセス解析を使って、タグURLの利用度合を検証してみてください(アクセス数にBotやSpider、管理者自身を含めないようご注意ください)。

うちはタグへのアクセス多いよ!というサイトには、タグの利用を促すヒントがあるような気がします。何かしらの傾向を見つけられるかもしれません。

コメント・トラックバック歓迎します。ぜひ、この疑問に対するフィードバックをください。WP以外のCMSユーザさんからのご意見・検証もどしどしお待ちしています!

おで流WordPressテーマの作り方(4)

脱線続きでしたが、いよいよCSSを書いてデザインしていきます。

7. CSSをリセットする

ブラウザはHTML/XHTMLを描画する際にデフォルトの見栄えを持っていますが、その見栄えはブラウザごとに微妙に異なります(入力フォームを見ると分かりますよね。Internet ExplorerとSafariのフォームは全然違います)。

このデフォルトスタイルをリセットして、ブラウザごとの設定を統一するのがこの項目の目的です。

以前は下記のようにユニバーサルセレクタ(*)を使ってリセットする方法が用いられていましたが、

 

最近では必要な要素だけをリセットするのが望ましいとされています。

このあたりを参考にして、以下のようにリセットしてみました。

reset.css

CSSをリセット

最近は、ブラウザが持っているデザインを活かすべきだということで、CSSをリセットしない作り方をするサイトも増えてきているようです。ということは、サイト訪問者のブラウザによって見栄えが微妙に違ってくることになります。

サイト製作側のポリシーなんてサイト訪問者に押し付けてはいけないし、訪問者にはブラウザによらず同じ見栄えで見てほしいと思います。また、ブラウザごとの見栄えの差異に頭を悩ませるのは嫌だったので、今回はリセットを選択しています。

8. XHTMLの構造を見極める

CSSでデザインしていくにあたって、XHTML構造を把握しておくことが大事です。どのタグ、id、classにスタイルを加えればよいのか、というあたりをつけられるからです。

SandboxテーマのXHTML構造は大雑把に表現すると、以下のようになっています。

SandboxのXHTML構造

※#top-imageのdivはぼくが追加したもので、オリジナルのSandboxにはありません。

この構造をデザインモックに近づけるため、以下のようにもっていきます。

20080515b

この図から、div#containerを左に、div.sidebarを右にフロートし、footerの手前でフロートを解除してやればよさそうです。また、これだけだとdiv#containerの包含要素(主にブログの本文)が少ない(短い)場合に2つに別れているサイドバーが横に二段並んでしまうので、div#primary、#secondaryそれぞれでフロートをクリアして、再度右にフロートしています。

(注:フロート、フロートと書いているのはfloatは必ずしも回り込みをするものではないからです。通常の流れから取り除いて、左または右に寄せるものと考えると誤解がないと思います。参考:てんぽ : floatは「回り込み」ではない

このようにfloatで段組してまとめたのが以下のファイル。大枠のレイアウトはすべてこのファイルにまとめています。

layout-2column-right-sidebar.css

フロートの解除については、いわゆるclearfixの手法を使っています。

これはページ内でフロートを繰り返すことで発生するレイアウト崩れを防ぐ手法で、従来<div style="clear: both;"></div>という空ボックスをXHTML内に書いてフロートを解除する方法がよく取られていましたが、見た目の制御のために情報構造上まったく意味のないコードを書くことを嫌う流れから、CSSのみでフロートを解除できるよう開発されたものです。

様々な方法が開発されていますが、今回はモダンブラウザを対象にしているということで、

 

こんな感じにしてみました。これをフロートしているボックスの親にあたるボックスに指定してやればOKです(参考:スタイルシートをめぐる冒険: clearfixの決定版を作る -モダンブラウザ編-。上記方法だとNetscapeで不具合があるようですが、すでに開発終了しており、Firefoxへの誘導がされていること、アクセスログを見てもほとんどこのブラウザからのアクセスがないことから、問題視はしていません。)

9.ロゴを画像置換する

情報と見た目の分離を(過度に?)徹底するための方法として、ロゴ等をXHTMLではテキストで記載し、CSSで画像を定義して置き換える画像置換というテクニックがあります。

方法論やSEOの観点などから様々議論されていますが、以下のようなメリットとデメリットがあります。

メリット

  • XHTMLに依らず、画像を使った多彩なデザインが実現できる
  • (ロゴなど)プリインストールフォントが貧弱な日本語環境でフォントを擬似的に実現できる
  • CSSを切り替えることで、XHTMLを変更せずに画像を変更できる

デメリット

  • (方法によっては)CSS有効でJavaScript無効の環境で何も表示されなくなる=アクセシビリティ上問題が出てしまう
  • (やろうと思えば)テキストの情報とはまったく無関係の画像を表示できるため、SEOスパムと判定される恐れがある

ということが言われています。画像置換を行ったからといって、ただちに検索エンジンからスパム扱いされるわけではない一方で、alt属性をきちんと付与したimgタグを書いたとしてもSEO的に不利になることはないという考え方から、画像置換を使わないアプローチをするサイトも増えてきているようです。

今回はSandboxのテーマは後から変更することのないように、またデザインをCSSで差し替えられるように、最低限に止めつつ画像置換を使っています。

画像置換の手法は日々改良が加えられており、今回採用したのはGilder/Levin Methodの改良版です。

 

 

空のspanタグを追加する必要があるのが若干気持ち悪いですが、画像無効・CSS有効の際にはaタグの中の文字が表示されるため、弱点を克服したものになっています。

ただし、spanタグを拡大して文字を塗りつぶしているような手法になるので、spanタグの背景に指定する画像が透過していると下にある文字が透けて見えてしまうのでご注意を。

その他の画像置換はmezzoblue § Testing Grounds: Revised Image Replacementから。画像置換は英語でImage Replacementといいます。このワードで検索しても様々な情報が得られるでしょう。

次回はいよいよ最終回。Sandboxに緻密に組み込まれた仕掛けを利用したテクニックをいくつかご紹介します。

[WordPress]WordPress ME 2.0.4にバージョンアップ

WordPressWordPress ME 2.0.4がリリースされたということで、さっそくアップグレードしてみました。

今回は差分ファイルme203-to-204.zipをダウンロードして、解凍して、FTPで上書きアップロードするだけでよく、upgrade.phpを走らせる必要もありません。

WordPress Japanを見る限りではどこがどうなったのかよく分かりませんが、WordPress.orgを見るに…

WordPress.org » WordPress 2.0.4
やぁ、ジョージ。今回のWP 2.0.4は何と50以上のバグフィックスが入ってるんだ。
ジョージ:それはすごいね、ボブ!
ボブ:そうさ、だから今回のアップグレードはみんなにオススメしているんだ。
ジョージ:それなら僕もアップグレードが必要なのかい?
ボブ:もちろんさ。君もジョナサンもグスタフもンシャマベもみんなさ。
ジョージ:でも、ボブ。僕はまだWordPressをはじめてないよ?

※ボブとジョージは筆者の頭の中にいます。
※なんとなく訳したときのイメージを表現したフィクションです。

7月のWordPress交流会と今気になるプラグイン

先月に続いて7月のWordPress交流会に参加しました。気になるプラグインリストはこちら

MMRT daily life[まとめ] あなたのお勧めプラグイン10選
:: plasticdreams ::第6回WordPress交流会

今回のお題だった「お勧めプラグイン」のおかげでとても勉強になりました。せっかくなので、今まで自分で調べても分からなかったこともいろいろ聞いちゃいました。

ミクシィのWPコミュにも登録しているのですが、WPユーザは人に聞かずに自分でなんとかしちゃう人が多いのか(←私の印象。交流会で賛同を得られました(笑))、MTコミュに比べると盛り上がっていないんですよね。

まだまだかけだしのWPユーザである私にとって、熟年熟練ユーザの方々と交流できるこの機会はとても貴重なものです。ぜひ次回も参加したいと思います。

自分の備忘録も兼ねて、今気になるプラグインをリスト化しました。

  • Spam Karma 交流会で教えて頂いたもの。Trackback Refererの値を調整することで、言及リンクなしトラックバックをはじくことができるそうです。
  • WP-AddQuicktag 投稿画面のタグ挿入支援拡張。ただ今、Flockから投稿しようと思ってたりするので導入は悩み中…。
  • Comment Quicktags コメント投稿のタグ挿入支援。少しでもコメントが増えればいいなと。
  • Live Comment Preview リアルタイムコメントプレビュー。これも便利にするため。
  • Footnote 脚注が入れれるみたい。これは『街』好きにはいいかも。
  • Smart Update Pinger 更新ping発射装置。
  • Extended Live Archives 高機能Archiveページをダイナミック生成。人気が高いらしいので漏れも漏れも!って感じです。
  • Search Word Highlight for Multibyte 検索エンジンからの訪問の際に検索キーワードがハイライト表示されるというもの。デザインとの兼ね合いを検討中。
  • CodeHighlight 言語を色づけ表示。カスタマイズ系のエントリや、いじったときの備忘録でコードはよく扱うので。
  • Dunstan-style Error Page 404 Not Found ページを高機能化してくれるらしい。
  • More Smiles WP標準のスマイリーを拡張してくれる。アイコンを作ったら考えようかな。
  • PHP Exec エントリ内やページ内でのPHPスクリプト実行を可能に。MTの頃からこの手のものは入れつつ意外と使わなかったり。
  • WP-PageNavi WP-Paginateとどっちがいいでしょうね…。

Blogged with Flock

ケータイで見やすいブログデザインについてちょっと考えてみた

以下「おれはおまえのパパじゃない – ブログデザインの好みについてちょっといわしてもらいます」を読んで思ったことを書いています。

上記エントリの主張を要約すると、「(ブログやニュースサイトの)XHTML構成上、本文→サイドバーの順で記述するべき」ということになると思いますが、大賛成であります(マウスのホイールボタンは個人的に使わないのでスルーしてます。ごめんなさいm(_ _)m)。

ケータイ画面にだらだらと続くメニュー(ITMediaをケータイで表示)わたしもよくケータイからPC用に作られたであろうウェブサイトを見ることがあるのですが、本文を読みたいのに画面に表示されるのは長々としたメニュー。こうした状況によく出くわすのは、ケータイ用の自動変換プログラム(mt4iとかwp-keitaiとか)を用意していないレンタルブログ(ココログとか。 Typepadのテンプレートに因りますけど)やITMediaなどのニュースサイトです。たとえばケータイではてブを利用して、個々のエントリに移動する時に移動先がPC用サイトだとこうなります。うざったいことこの上ありません。

ケータイ用の変換プログラムを用意すればいいじゃないか、とか、ケータイ用のサイトを作ればいいじゃないか、とか、ケータイのフルブラウザで見ればいいじゃないか、といった意見もあると思うんですが、ケータイもPCも一つのHTMLファイルで済むのがスマートだし、ローコストではないかと思います。フルブラウザもいいけれど、電波は有限だし、ケータイのCPUも貧弱でレンダリングも遅いし…と考えるとプレーンなテキストで必要十分な情報を得ることのほうがケータイにはあっているのかもと思います。

そう考えると、ブログをデザインする上でテンプレートのXHTML構成を「ヘッダ→エントリ本文→サイドバー(メニュー含む)」という順番にしておけば、PCから見てもグッド、ケータイから見てもいきなり本文が読めてグッドな構成になります。SEO的にもこのほうが望ましいと聞いたことがありますし。

欲を言えば、メニューリンクに使うような画像もHTMLにimgタグを記述するのではなくて、テキストをCSSで置換してくれるとうれしい。CSSを解釈しないケータイは画像を読み込まず軽いテキストで済むからです(画像置換には異論もあるでしょうが…)。本文の画像はimgタグで OK←本文を理解するのに必要なことが多いためです。

ケータイで見やすいブログデザインまとめ:
XHTML構成は本文→メニュー/サイドバーとする。
メニューに使う画像はCSSで画像置換する。

ケータイがCSSのmedia属性handheldに対応してくれれば、handheldに対してサイドバー部分をhiddenしちゃう、とかっていう方法も取れると思うんですけどね。ま、今作成者側でできることをしましょうってことで。