へたれwebディレクターの覚え書き

ただの感情論なのですが、酔った勢いでエントリーです。



世の中は100年に1度の不景気だそうです。
きっと今年も、いくつもサービス閉鎖のニュースを聞くことになるのだと思います。


ITバブル崩壊のときも、いくつかサイトが閉鎖しました。
ただそのころは、サイトのコンテンツは企業が作成したものが多かった時代です。
企業が作成したコンテンツを同じ企業が削除する。ユーザーにはそれほど影響はありませんでした。


しかし今回の不景気は、CGM全盛時代の出来事です。
どのサイトでも「ユーザーの投稿」機能が当たり前のようについています。サイトの閉鎖をするということは、それらユーザーの投稿データ消失を意味します。

つまり今の時代、サービスの閉鎖で消えてしまうのは単なる情報ではなく、ユーザーの記録や思い出なのです。



正月休みに、実家に顔を出しました。
アルバムを見ていたら、去年他界した、祖母の若いころの写真がありました。60年以上前のものが今でも残っているのです。

サービスの閉鎖とは、このアルバムを燃やすこと、に例えられるかもしれません。
どうしても燃やさざるを得ないなら、せめて中の写真は保存されるべきではないでしょうか。

サービスが閉鎖されるなら、中のデータは別サービスに自動で（ここ重要）移管されるとか、それが無理でもせめて、しばらくは自分の投稿データをダウンロードできるとか、それくらいのことをして欲しいです。
ダウンロード可能期間は長ければ長いほどいいと思います。（個人的には、『ライブドアfrepa』の3ヶ月弱でも短かったと思います）


もう一度書きますが、サービスの閉鎖で消えてしまうのは単なる情報ではなく、記録や思い出なのです。
現実的には厳しいとは思うのですが（厳しいから閉鎖するわけですし）、もし閉鎖する予定のサービスがあったら、少しでもユーザーによる投稿データのサルベージ方法を考えてあげて欲しいと思うのです。


webにアップされたデータが60年でも100年でも守られて、普通の人が安心してデータを保存目的でアップロードできる。そんな時代になって欲しいと思うのです。

楽天やライブドアのページにアクセスすると、広告枠にバナーが表示される直前に一瞬、なんか数字のカタマリのようなものが表示されるのが気になっていました。

サブリミナル効果を狙ったなにかなのかと思っていたのですが、IT-PLUSの「行動ターゲティング広告はどこまで許されるのか」という記事で、ドリコムが開発した『ad4U』という広告配信システムがあることを知りました。どうやらそれが使われているページは、このような現象が起きるようです。


ad4Uとはドリコムによるターゲティング広告の一種で、ユーザーのブラウザーからアクセス履歴を取得し、ユーザーの特性を把握して、そのユーザーに合った広告を配信するシステムのようです。

たとえば、わたしが楽天にアクセスしたとします。楽天はわたしのブラウザーに「Yahoo!不動産」へのアクセス履歴があるかどうかをチェックし、あるのなら、「いまわたしは物件を探している」と判断し、不動産系の広告を表示する、という動きをします。


仕組み的には、数年前にいちどセキュリティーへの不安が議論になったことがあるもので、目新しくはありません。以下のようなものです。


（中略）


この仕組みは過去に議論になっていますし、海外のエロサイトでもすでにこの技術は使われているようですので（なぜ海外のエロサイトのことを知ってるの？という疑問についてはノーコメント）、ドリコムが特許を取得できてるとは思えません。楽天やライブドアの技術力をもってすれば、ドリコムに頼ることなくad4Uと同等の広告システムは開発できたと思われます。
それでも独自開発しなかったのは、リスク判断が行われた結果なのかな、とか思ったりもします。


ad4Uはセキュリティー的にどうなのか、という議論はあるでしょう。楽天に掲載されている説明文を読むと、ユーザーのブラウザー履歴データはサーバーに送信されることなく、広告配信までの処理はすべてクライアント側で行われているようではあります。
ただ「ブラウザーの履歴を勝手にチェックされ利用されている」というのがいい気分ではない、という意見があることは理解できる気がします。


ネット上では、「悪意のある者がこの仕組みを利用して悪事を働くことができるのでは」という理由から、この仕組みについてオープンにしてはいけない、といった意見が多いようです。

しかしわたしは、この件は隠し立てされることなくネット周辺でもっと情報が広まって議論され、その結果ブラウザーメーカーやセキュリティーソフトメーカーが判断して対応すればいいのかな、と思います。
すでに楽天やライブドアといった大手が採用している時点で隠し立てするのは無意味だと思われるからです。
それならば、（もし問題があるのなら）少しでも早くなにかしらの対策がなされるよう、オープンに議論したほうがいいのではないでしょうか。


追記（1/11 1:00）：
ブラウザー履歴の取得方法やサンプルの掲載部分を“（中略）”としました。

職場の同僚が「Firefoxで社内イントラのログイン状態を保存してくれなくなった！」と叫んでいるのを聞いて、「大変だなぁ」と人ごとのように思っていたのですが。


昨日、わたしの自宅PCでもその現象が発生しました。

その対処方法を覚え書きとして残しておきます。

ログイン状態を保存してくれなくなった

現象としては、Yahoo!やmixiのログインページで、ログイン状態を保存するように設定しても、一度ブラウザーを閉じると、次にアクセスしたときにはログインし直しになってしまう、というものです。

おそらくですが、Firefoxのcookie保存設定がおかしくなってしまったものと思われます。

Cookieの保存内容をチェックしてみたところ、Firefoxの「サイトから送られてきたcookieを保存する」をonにしているにもかかわらず、ブラウザを閉じるとcookieがクリアされてしまっているようです。


ネットで検索してみたのですが、対処方法にはヒットせず。


困っていたところ、『Net MOUNT』さんで、Firefoxがパスワードを記憶してくれなくなったときの対象法について書かれているエントリーを見つけました。

それによると、プロファイルのパスワード設定に関するファイルをいったん削除してしまうのが有効、ということでした。


パスワードが保存されない問題が関連ファイルを削除することで解決したのなら、cookieも同じやり方でいけるかも！と思い試してみます。

解決方法

1. Firefoxが開いていたら、いったん閉じる
2. プロファイルを開く
   • win-xpならコマンドラインから
     %APPDATA%\Mozilla\Firefox\Profiles\
     を実行
3. 表示されたフォルダの中の、「cookies.sqlite」をリネームする
   • 削除しないのは、いざというときに復帰させるため
4. firefoxを再起動する

これでログイン状態を保存してくれるようになりました。問題解決です。


ログイン状態が保存されなくなった！と思ったときは、このやり方をお試しください。

自分用覚え書きです。タイトルで言い尽くしている気もします。


ちょっとSEOについて学んでいたりしたのですが、いまだに『Googleウェブマスターツール』を利用したことがないので、試してみることにしました。


しかし、Googleウェブマスターツールにこのサイトを登録する作業中、
「サイトを確認できませんでした。404 (ファイルが見つかりません) ページのヘッダーで 200 (ファイルが見つかりました)」
とのエラーメッセージが表示され、登録作業が完了しません。


ヘルプを見てみると

存在しない URL では 4xx ステータス コードを返すことが重要となります。存在しない URL に対して他のステータス コード (2xx や 5xx など) を返すよう設定されているサイトは、誰でもサイトの所有権を確認できてしまうため、Google でサイトの確認を行うことができません。

との記述が。


Live HTTP headersで、studio-no9.com上に存在しないURLにアクセスしとときのステータスコードを確認してみたところ、どうやら302が返されているようです。302は一時的リダイレクトが発生しているときに返されるコードですね（うろ覚えですが）。

URLが存在しないということを正しく（ややこしいですね）通知するなら404を返すべきなのですが。


原因ですが、レンタルサーバーやプロバイダーのwebスペースでは良くあることのようですが、存在しないページにアクセスしたときに、そのレンタルサーバーやプロバイダーのPRページにリダイレクトして表示することがあるようです。このサイトで利用しているBANANAサーバーも同じです。


404を返して欲しいので、.htaccessファイルに
を設定します。


これでもまだ302を返します。


ここで自力解決はギブアップ。ネットで検索してみたところ、「御の字でございます」さんで以下のような記述を見つけました。

チカッパやロリポップのレンタルサーバーは、存在しないURIにリクエストがあると302で広告ページにリダイレクトをかける。
.htaccessでErrorDocumentを「相対パス」で指定すると404のステータスコードを返す。

ということで今度は.htaccessファイルを、
に修正してみます。


これでアクセスしたところ、無事404ステータスを返してくれるようになり、Googleウェブマスターツールの使用も可能になりました。
解決です。


ついでに、『百式』さんで紹介されていた「Custom 404 pages」も採用してみました。


無事に動いているようです。良かった良かった。
（存在しないURLを入力したときの表示例はこちら）

まとめ

レンタルサーバーで404ステータスを正しく返してくれないときは、.htaccessで独自に用意した404ページを相対パスで指定してみるといい。

雑談エントリーです。


相変わらずAmazonおまかせリンクの精度がイマイチです。




なぜダウニー…。

サイトを利用していると、たまに「あぁ、ここ使いづらいなぁ」と思うことがあります。

そのうちもったいないことに、「きっと、ある問題を解決しようとして頑張ったら、別の問題を引き起こしちゃったんだろうな」というものがあります。今回はそれについて3つほど例を挙げてみました。

1. fon-familyの指定
2. 多段型ドロップダウンナビゲーションメニュー
3. 入力フォームの説明文

font-familyの指定

いろいろなサイトを訪問していると、CSSのfont-famikyにヒラギノ角ゴを指定しているサイトが多いことに気づきます。

わたしはWindowsユーザーなのですが、ヒラギノが指定されているサイトを見ると、アンチエイリアスがうまくいかないようで、フォントがほころんだように表示され、読みづらくなります。


またWindowsでヒラギノフォントを表示させると、MS Pゴシックなどと比べてサイズが大きくなるようで、たとえばYahoo!ログールでは文字が重なってしまっています。

おそらくwindowsユーザーがヒラギノをインストールしているという状況を予測できていないために起きる現象だと思われます。ヒラギノフォントはMacOS Xの標準フォントで、ふつうのWindowsPCにはインストールされていません。

しかしWindowsユーザーでも、デザイナーならヒラギノフォントをインストールしている人は多いのではないでしょうか。また、初めてMacOS Ⅹに触れたときにその美しい文字に見とれてしまい、「ヒラギノをインストールすれば僕のwinマシンでもMacのようにきれいな文字になるんだ！」と勘違いして4万円はたいてフォントを購入してしまったわたしのような不幸な人もいるかもしれません。


ということで、「font-familyはわざわざ指定する必要があるのか？」というのを考えてみます。

font-familyを厳格に指定する必要性を考える

なぜわざわざfont-familyを指定するのでしょうか？
font-familyを指定する理由は、以下でしょうか。（ほかにあったらご指摘ください）

1. Mac用のIEだと、2バイトフォントを指定してあげないとinputフォームの内容が文字化けすることがある
2. IEでUTF-8だと、日本語文字と英数字で違うフォントが使われるので、それの対策
3. 一部のブラウザーの標準のフォントが明朝なのでそれをゴシックにしたい
4. 少しでも表示をかっこよく

１. Mac用のIEだと、2バイトフォントを指定してあげないとinputフォームの内容が文字化けすることがある

らしいです。Macを持ってないので動作確認できませんでしたが。


古いブラウザーに必死で対応しなくてはいけない理由がよくわかりません。

古いブラウザーはセキュリティー面でも不安がありますし、そもそもブラウザーを作ったメーカーがサポートをやめてしまっており、かつ代替となる最新のブラウザーが無償で提供されているわけですから、無理してサイト制作者が頑張らなくてもいいような気がします。

実際、GoogleやYahoo!が提供するサービスでは、古いブラウザーは推奨外とされています。


少数を切っていいと言っているわけではありませんが、頑張ってMacIEに対応するよりも、そのリソースを使ってサービス自体の質を向上させたほうがいいと思います。もし「少数を絶対に切らない！」というポリシーであるのなら、Mac用IEより利用者数の多いOperaやモバイルブラウザー、iPhoneへの対応を優先したほうが喜ぶ人も多いのではないでしょうか。

２. IEでUTF-8だと、日本語文字と英数字で違うフォントが使われるので、その対策

IEで文字コードがUTF-8のページをfont-familyを指定しないで表示すると、日本語はMSPゴシック体、英数字はセリフ体（日本語文字でいう明朝体に該当、たぶんTimes New Roman）で表示され、かつ英数字だけアンチエイリアスがかかるようです。これはちょっと違和感あるような気もします。


Googleでは「arial,sans-serif」を指定し、とりあえず日本語も英数字もゴシックで表示されるようにしています。「英数字だけアンチエイリアスがかかる」という問題は気にしていないようです（多分ですが、CSSがUSのものと共通なのでしょう）。
実際に表示してみると、個人的にはあまり表示の違和感を感じませんし、「英数字だけなめらかに表示されるからGoogleが見づらいよ！」という話を聞いたことがありません。
フォント名を厳格に指定することなく、フォントの違い対応しています。これでいいような気がします。


逆にYahoo!のトップページのように、MS Pゴシックが指定されているのはちょっとやり過ぎな気がします。

３. 一部のブラウザーの標準のフォントが明朝なのでそれをゴシックにしたい

２の「IEだと、日本語文字と英数字で違うフォントが使われる。それの対策」と同じですね。sans-serifを指定しておけば解決されると思います。

４. 少しでも表示をかっこよく

デザイナーのサイトなら、どのフォントを使うか自体が重要なコンテンツですが、そうでもないかぎり、フォントをがっつりと指定する必要性をあまり感じません。


ヤスヒサさんは『Webサイトはまったく同じ見た目である必要はない』というエントリーの中で、以下のように語っています。

レイアウトが崩れていても良いという意味ではないですが、若干の見た目の違いは『仕方ない』ではなく『当然のこと』だと思います。異なる環境が構築されているパソコン上で異なるブラウザを使っているわけですし、OSもしくはブラウザにカスタマイズがされていればさらにバリエーションも増えるでしょう。ディフォルトだといってもパソコンメーカーごとに何かしらのカスタマイズがされている可能性があるので、純粋にディフォルト環境というものはないかもしれません。利用者側もコントロールが出来るわけですから、Webらしいといえば Webらしいわけですね。

「いま作っているサイトは、本当にフォントを厳格に指定する必要があるの？」というのを再度考えてもいいような気がします。

font-familyのまとめ

もしfont-familyを指定している理由が上記のようなものであるのなら、Googleのように最低限のfont-family指定にしておけばいいのではないでしょうか。（もちろん、個人サイトやデザイナーのサイトのような、サイトの見た目が大事な場合は別です）

どうしてもフォント指定したいのなら、せめてWindowsでもきれいに表示され、かつMacには存在しないメイリオを最初に指定するなどの工夫があってもいいと思います。
少なくとも、文字が重なったりはしないようにはしたいです。


余談ですが、知人のMac使いなデザイナーさんにこの話をしたところ、「メイリオでもMS Pゴシックでもなんでも、とりあえずWindowsで見やすいようにしておけばいいんじゃない？ Macならどのフォントが指定されようが、どうせきれいに表示されるんだから気にならない」だそうです。Macうらやましいなぁ。

多段型ドロップダウンナビゲーションメニュー

ナビゲーションメニューで、深い階層を指定できるようになっているサイトを見かけます。リンク先にあるようなナビゲーションですね。このナビゲーションが、使いづらいなぁと思うことがあります。

上の画像を見ていただきたいのですが、このFolder 2.1からFolder3.1.1にカーソルを移動しようとするときに、メニューの外にカーソルが通ります。そのときに、今まで開いていたメニューが閉じられてしまうのです。

このような多段型ドロップダウンナビゲーションメニューを用意するときは、カーソルがメニューから離れても、メニューが消え始めるまでにタイムラグを用意したいところです。Windowsのスタートボタンが良い例ですね。


なお個人的な感想ですが、ドロップダウンナビゲーションメニューが3階層以上のサイトを、使い勝手がいいなぁと思ったことがありません。
一般的には使い勝手が良い、とされているのでしょうか。気になります。

入力フォームの説明文

検索フォームなどに、薄い文字で入力例が表示されているサイトがあります。


しょっちゅう利用しているサイトでは、ページが完全に表示される前に検索キーワードを入力し始めたりするのですが、そのときにこの入力例が消えてくれないことがあります。


ctrl+A、Delete、キーワードの入力し直し
の3アクションをすれば済むことなのですが、この3アクションは本来ならする必要ないものであり、この必要のないアクションは体感的にかなり高コストに感じます。


Mixiなど、ページが表示中に検索キーワードを入力し始めたら入力例は表示しない、としているサイトもあります。可能な対策はしておくべきでしょう。

まとめ

どれもわたしが個人的に気になったというだけであり、同じような不満を持つ人はごく少数だと思います。自分で書いておいてなんですが、正直、言いがかりレベルの話です。

が、インターフェースデザインの担当なら、こういう細かいところにまでとことんこだわれる人でないといけないような気がします。

サイトの不満点に対して対策案を考えるにはまず、あらゆる不満点に気づくことが必要だと思うのです。

2008年も質、量ともにありえないくらい仕事でミスしましたが、一番悔しかったのが、ユーザーが間違ったアクションをしたときに「ただエラーメッセージを表示するだけ」という仕様を書き、それを第三者から指摘されて気づいたことです。

ユーザーがサイト上でアクションをしてくれる、というのは、サイト運営者にとってとても貴重なことです。
それを大事にしない仕様を書いてしまいました。なにが大事か、というのを理解していなかった証拠です。

『へたれwebディレクターの覚え書き』は、「分かっているつもりになっていることを文章化することで、本当に理解しているかどうかを確認する」という目的でやっています。
『思っている』を、ブログに書くことで『考えている』に昇華できたらいいなぁ、と思っています。

というわけでアクセス数の少ないこのサイトですが、今年も地味に更新していこうと思います。
本年もよろしくお願いいたします。