Firefoxで一時的にFlashをoffにする方法

例によってまわりで知ってる人が少なかったのでエントリー。
もう本当にどうでもいい内容です。


たまに仕事で、Flashをインストールしていないときの動作をテストすることがあります。


テスト環境を用意するために、Flashをアンインストールしたり、Firefoxに『Flash Switcher』というアドオンをインストールする人が多いのですが、

「アドオンの設定画面で無効化すればいいだけなのに…」

といつも思うのです。

画面1・Flashアドオンの解除


Flash Switchrはなぜだか不安定なので、こちらのほうが安全ですね。


すごくくだらない内容なのですが、でもまわりでやってる人が本当に少なかったのでエントリーしてみました。

Web > 覚書き | comments (0) | trackbacks (0)

ユーザー中心デザインの学習(3)「創造性とデザインの方法」

読書メモの続きです。


創造性とデザインの方法



創造性とデザインの方法

  • ダニエル・ピンクによる『6つの感性』
    • 機能だけでなく「デザイン」
    • 議論よりは「物語」
    • 個別よりも「全体の調和」
    • 論理ではなく「共感」
    • まじめだけでなく「遊び心」
    • モノよりも「生きがい」

すべて「動詞で考える」につながる
生活における経験価値なく、生活全体の視点から見る力→「生活における経験価値」


クリエイティビティは「ひらめき」や「アイデア」と同等か?


ブルーノ・ムナーリによる「ひらめき」や「アイデア」の分類
  1. ファンタジア
    • これまでなかった新しいことを考え出せる能力。実現可能か機能面はどうかなどは考えなくて良い。
  2. 発明
    • 認識している事柄同士が持つ関係を利用してこれまでなかったものを考え出す。
    • 最終的にこの関係を実用性に向かわせる。美的問題は含まない。
  3. 創造力
    • ファンタジアのイメージ面と、発明の機能面の両方を多角的な方法で利用するもの。企画設計する手段あるデザインの分野で活用され、一つの問題のあらゆる側面(心理的、社会的、経済的、人間的そう工面など)を内包する手段。
  4. 想像力
    • ファンタジア、発明、創造力によって考え出されたことを目に見えるようにする手段。

創造力(創造性)が特別な「生まれつきの才能」ではないことがわかる。


創造性とコミュニケーション

  • 心理学でいう「心の理論」
    • 心的状態を推測
    • 人は相手の表情など、無意識の動作にてよっても心理状態を想像している
  • インタビュー法より行動観察が有効
    • 人は普段、それほど意識的に他人の行動を見ていない
    • 意識と行動は、その本人の中ですら一致していない
  • →ユーザーテスト法でも行動と発話の両方からユーザーの行動分析を行う
    • 調査のあとにユーザーの行動を物語風のシナリオとして書き出すと、観察できていたかどうかハッキリする

ユーザー調査はユーザーに何かを教えてもらうためのものではない。それではどこにも創造性が関与しない


まとめ


いまちょうど会社でユーザーテストを行っています。

ユーザーの動作を注意深く観察して、わずかな行動に気づき、あとからその行動の理由を尋ねながらシナリオのようなものを作っていくのは、確かに効果がありそうです。

ただ現時点では、どこまで正しくユーザーの行動を終えているのかわかっていません。

とりあえず今は、
観察するということに慣れてくると、それまで見えていなかったものが不意に見えるようになる瞬間があります。意識化できなかったものが突然意識でき、目の前で行われていたユーザーの行動を改めて発見するのです。

これを期待して、この学習とユーザーテストを繰り返し続けることにしようと思っています。


Web > UI / design | comments (0) | trackbacks (0)

「ユーザー中心デザイン」学習(2)

ペルソナ作って、それからどうするの?』の学習時メモを公開します。


第1章・デザインの問題を特定する


  • デザインとは「どんな世界を実現したいのか」という哲学
    • これがないとデザインする課程で必ず発生するトレードオフに対して明確な選択ができない
  • ニーズを調査で集めても「今のユーザーのニーズ」だけではデザインを決められない
    • ユーザーのニーズは何かの拍子に変わってしまうので
    • ならば「何かの拍子」を最初からデザインそのものに負わせるほうが良い


「デザイン」とは?(言葉の定義)


  • 作ろうとするものの形態
  • 行おうとすることの形態
  • 行為の導線
  • 行為の軌跡
  • 計画・目的・意図=グランドデザイン
  • 「建築家の仕事におけるデザインに近い」かもしれない。
  • 美的な意味合いでの「構想力」
    • 「企画としてのデザイン」「そのやり方を知ってれば簡単」
    • 日常生活の動作は、デザインにとって最も重要
      • 「動きの中にしかデザインはない」
      • 「たとえば茶道では、あたかも無意識にやったかのように意図的に非常に無駄のない線をたどっていくことを極めている」
    • デザインの仕事について。
      • 「デザインは製品にかたちを与えることだと思われているが、それだけではなく
        それがかたちを成すための要因をしっかり見せることもデザインの仕事。」
    • 「名詞ではなく動詞で考える」
      • 改良の余地のないようなものでも、それが「使われている状態」で見れば改善点が発見できることがある


ウェブの制作とデザイン


  1. デザインはスタイリングではない
  2. デザインの成果は人間の目的に適応した人工物
    • ユーザーが必要な情報に迷わずたどり着けるようにするナビゲーション・システムの設計や、 ユーザーとどのようなコミュニケーションを行うことで、どのようにしてウェブサイトのビジネス成果(商品やサービスへの資料請求やECでの販売など)を上げるのかを設計しているという点ではウェブサイトをシステムとしてとらえていると言える
  3. デザインには誰もが習得できる方法がある
    • ウェブサイト制作の現場で行われているかどうか怪しい
    • 現場メンバーの属人性に頼る部分を少しでも減らす
    • 「問題を解くためのデザインの方法」をデザインする
  4. 日常生活の観察がデザイン問題の解決につながる
    • ウェブサイト制作の現場で行われているかどうか怪しい
    • そもそもあまり認識されていない
    • ユーザーテストを実施していても正しいタスクで実施されていないため、ユーザーの日常生活とはなんの関係もない行動の観察になってしまうケースがある
    • テストが目標に対して正しく対応していなければ、目標は達成されることがない。
  5. デザインはディレクション、プロデュースと同義


我々の事業は何か、ミッションは何か?


  • 事業は何か
  • 何であるべきか
  • どんな問題も、内部の視点だけで解くことはできない
  • 社会の人々の、現在よりも将来の生活や暮らしを見据えた外部の視点から、問題そのものを発見しそれを解いていく必要がある



まとめ


  • デザインとは
    ある問題に対する解決策を具体的な形や振る舞いとして実現するための一連の作業過程、およびその成果物のこと
  • ビジュアル・デザイン(orスタイリング)とは
    「具体的な解決咲くとしてのものの形や視覚的な表現、スタイル」のこと



Web > UI / design | comments (0) | trackbacks (0)

「ユーザー中心デザイン」学習

前回のエントリー、『インターフェースとマーケティングとの関係』について、『DESIGN IT! w/LOVE』さんから厳しめのご指摘をいただきました


ご指摘内容についてはすべて「おっしゃるとおりですスイマセン」と思わされるものでした。


前回のエントリーでわたしが書きたかったのは
「なにを達成すればゴールなのか」をまずは深く掘り下げることをし、その上で「そのゴールを達成するためにはなにをするべきか?」を検討する。それを詰めていく課程が「サービス企画」なのでは
というものでした。

が、わたしの理解度や知識があまりにも浅く、それが内容のおかしさや用語の混乱になっていたかと思います。


自分のダメっぷりをインターネットで大公開した、というのは良い機会だと思われます。
これ以上の痛い目を見る前に、いまこのタイミングでキチンと学んでおくべきだと思いました。


ということで、以下を行うことにします。

  • 「実現したいことの明確化→サービス企画」のフローを、業務で使えるレベルまでに高めることを目的に、学習を行う
    • まずは『ペルソナ作って、それからどうするの?』を基本的に本の章立て通りに読み進める
    • 問題ない範囲で読書メモをブログで公開する
    • 途中で「実際に手を動かしてみるべきだ」と判断したら、それを行う


一緒にこの本で学んでいこうという方が近くにいたら、読書会っぽくするかもしれません(ただわたしは読書会というもに参加したことがないので、進め方もよく分かってないです)


上記フローについては途中で読み進めていくうちに変更するかもしれません。(要はわたしのスキルが上がればいいわけで、読書メモの公開が目的なわけではないのです)


最後になりますが、『DESIGN IT! w/LOVE』さん、いろいろご指摘いただきありがとうございました。


Web > UI / design | comments (0) | trackbacks (0)

インターフェースとマーケティングとの関係

DESIGN IT! w/LOVE』さんのエントリー、『製品中心から人間中心のデザインへ』と『マーケティングとユーザビリティに対するデザイナーの失望』はとても興味深い内容でした。
私のブログのテーマである「インターフェースとマーケティングとの関係」について触れられており、また私が曖昧にしていた部分(理解できていない部分)をわかりやすく明文化されていて、職場で読んでいてかなりテンションが上がりました。
(同時に自分のダメさ加減にショックを受けました)


いい機会なのであらためて、「サービス検討段階でマーケティングはどのようにかかわればいいのか?」をテーマに
  • ユーザーのNeedsを正確に把握し、サービスとインターフェースに落とし込むプロセス
  • その課程でマーケティングはどのようにかかわればいいのか

について考えてみます。

もう少し整理してからエントリーしたかったのですが、なんとなく機を逃してしまうような気がしたので、触発されたままのイキオイでアップしてしまいます。
あとで修正するかもしれません。


ユーザーの「達成したいこと」(Needs)から、「本当の目的」(Wants)を導き出すプロセス



サービスとは目的達成に近づくための手段であることを再確認しよう


製品やサービスは本来、なにかの目的を達成するため(もしくは目的達成に近づくため)の手段です。
言い換えると、手段であるサービスを検討するためには、目的を正確に把握することが重要になってきます。

ただ前提として、「一般の人は自分の本当に欲しい物を分かっていない」ということを理解しておきたいです。
ユーザーのニーズを得るのは比較的簡単です。しかしNeedsを満たしても、Needsはユーザーの本当の目的ではなくたくさんある手段のうちの一つであることが多いため、ユーザーの本当の目的を達成していないということがほとんどなのです。


家計簿サービスを例に考えてみる


例として家計簿を挙げてみます。

家計簿は、「つけれるものならつけたほうがいいよね」の筆頭かと思います。三日坊主で終わった人も多いでしょう。

家計簿のNeedsは、家計簿をつけている人(またはつけようとして断念した人)にアンケートを採れば簡単です。
  • 入力をもっと簡単に
  • ケータイからも入力できるように

という意見がほとんどです。
つまり「簡単に楽しく家計簿をつけたい」のですね。


しかしこれらを解決すれば、ユーザーの本当の目的は達成できるのでしょうか。
いやそもそも、本当の目的ってなんでしょうか?


NeedsからWantsへさかのぼる


本当の目的を把握するためには、NeedsからWantsにさかのぼる作業をします。
これは、マインドマップをさかのぼる作業に似ています。
図1・NeedsからさかのぼるだけWantsに近づく

NeedsからWantsへは、さかのぼればさかのぼるほど、ユーザーの本当の目的に近づいていきます。
ただし、逆に内容はアバウトになっていきます。
「お金の出納を把握する」ではまだまだ具体的ですが、「なりたい自分になる」あたりではいかにもアバウトで、企画が曖昧になってしまいそうです。

どこまでさかのぼればいいのか?といのは僕にはまだ良くわかっていません。
ただし少なくとも企画段階では、家系図でいう5親等くらいの広がりは検討した方がいいような気がします。
これを『Wants5親等の法則』と呼びます(いま考えた)。


NeedsとWantsの階層を上下するには、リサーチ資料が必要なのではないか


さて、Needsをさかのぼりつつ「なりたい自分になる」というWantsにたどり着くには、
「20代後半から30代前半の人は、理想とする自分の将来像を持っており、自分が理想に近づくための金銭的・時間的投資を惜しまない傾向にある」というリサーチ結果を把握している必要があります

また、このリサーチ結果を検討材料に含めるかどうかは、サービスの対象に「20代後半から30代前半の人」が含めるのかどうかにもよります。

この時点である程度のマーケティング的判断が必要になってくるのではないでしょうか。


サービスとインターフェースに落とし込むプロセス


NeedsとWantsを把握できたとして、次にそれをサービスとインターフェースに落とし込むプロセスについて考えてみます。

これには主に
  1. ペルソナ・シナリオ
  2. 利用可能な技術
  3. 数々のアイデア

の3つの要素があると思います。

図2・サービスとインターフェースに落とし込むプロセス


1・ペルソナ・シナリオ


UIをペルソナに合わせる、というのはよくあることだと思いますが、私は機能すらもペルソナに左右されるべきだと思っています。

「なりたい自分になる」家計簿サービスという視点で考えてみます。

20代のペルソナを用意した場合、20代というのはいまあるお金の投資方法によって自分の成長具合に変化があるわけですから、目的に達するためには、ただ収支を管理するだけでなく、「なににお金を使うべきか」「あなたが使ったお金はどれだけ将来の自分に対する投資となっているか」をなんらかの方法で把握できる機能が必要かもしれません。
逆に60代の人が使うサービスなら、「成長のための投資」機能は(20代と比較して)要求度は低いです。生涯に使える予算がすでにある程度分かっているなかで、リスクを避ける運用方法や、単純に「今月はあといくらお金を使えます」機能が重要視されるかもしれません。

ペルソナによって
  • どんなoutputが求められているのか
  • どんなinput量、input方法なら負担に感じないか

などは大きく異なるわけですから、機能も、目的とペルソナによって左右されるべきではないでしょうか。


2・利用可能な技術


ペルソナとも関係あるかもしれません。

技術には制作者が利用できる技術とユーザーが利用できる技術、二つの視点が必要です。
「今現在」利用可能な技術だけでなく、1年後にはどのような機能がユーザーに使われているか?それは今回の企画でユーザーインターフェース改善に使えるか?を考える必要があるかと思います。

たとえば、対象とするペルソナが「ケータイの機能をいつでもフルに使いこなしている新しい物好き」であるならば、
  • ケータイで撮影した画像は自動的に共有フォルダにアップロード
  • GPS使い放題

を前提に機能やUIを検討してもいいかもしれません。


3・数々のアイデア


アイデアの出し方と反映方法については本稿とは別テーマなので割愛しますが、このアイデアの数(と有用性)が、サービスの独自性につながるのだと思います。


検討した結果


検討した結果、考案されたサービスから得られるoutputがWants(なりたい自分になる)に近いかを吟味し、不十分だと思われたら、繰り返し繰り返し再検討する必要があると思います。


「インターフェースとマーケティングとの関係」:おわりに


私の考える「サービス検討段階でマーケティングはどのようにかかわればいいのか?」は以上です。

このエントリーを書いているうち、『マーケティングとユーザビリティに対するデザイナーの失望』で触れられている
ほとんどのマーケティングリサーチがデザイナーにとっては意味をなさない結果しかもたらすことができないのではないかと僕もずっと感じています。つまりマーケティングリサーチの結果を知ったからといって、デザインをするうえで役立つ情報はまったく得られないと思っているわけです。

という一文は、機能とUIを検討するプロセスが別にあるためにおこる問題なのでは?と思えてきました。

具体的な解決方法は『製品中心から人間中心のデザインへ』で書かれている
製品ありきではなく、今回のように、あくまで人びとの行う行動ありきで、そこにどんな物があればよりその行動が円滑になるか、目的をよりよく達成できるようになるかを考えるという場合のほうが、より本来のUCDの良さを発揮できるんだなと、実際に作業を進めていて感じます。

ですでに見えているのでは、と思ったのですがどうなのでしょう?


【関連エントリー】
- へたれwebディレクターの覚え書き | タブインターフェースを使うための条件
- へたれwebディレクターの覚え書き | タブインターフェースと"世界観"
- へたれwebディレクターの覚え書き | モバイル版のインターフェース
- へたれwebディレクターの覚え書き | ツールとサービス
generated by 関連エントリーリストジェネレータ
Web > idea/plan | comments (0) | trackbacks (1)

Firefox3.1(3.5)では半角文字の途中でも改行できる

個人的には興味がない話題なのですが、調べたついでにエントリー。


なんとなくYahoo!BBのトップページにアクセスしたのですが、微妙に名前部分の表示が崩れていたのが気になりました。
どうやらIDの途中で改行コード(<br>)が挿入されているのが原因のようです。
画面1・名前表示途中で改行されている
画面2・改行が挿入されているソースコード
なんでbrタグを挿入しているのかというと、おそらくですが、FF3.0はword-wrapやword-breakが反映されないため、半角英数字の連続が途中で改行されず、表示が崩れる場合があるからだと思われます。その対策なのでしょう。


この手の表示崩れ対策を行っているサイトはけっこうあります。手段もいろいろあり、途中にbrタグを挿入、細かくwbrを挿入、unicodeのサイトなら幅0の空白を挿入、などが挙げられます。


しかし個人的には、brやwbrを挿入したりするのはなんとなく邪道な気がします。htmlは見栄えを制御するものではなく、文字に意味づけを行うための仕組みだからです。

表示崩れを気にするのなら文字を途中でカットするなりすればいいわけですし、もし本当に1行にすべてを表示しなければならないような情報なら表示領域を広げればいいのに、と思います。


mixiでは表示名が、最大文字数で入力してもちゃんと一行で収まるようになっています。
画面3・mixiは最大文字数で名前を入力しても正常に表示される

友だち一覧部分では表示が崩れることがありますが、無理矢理に改行タグを挿入したりしていません。htmlのルールを守っているからだと思われます。
画面4・一部の画面では表示が崩れる


さて、ここからが本題なのですが。

Firefox3では半角文字が連続したときにテキストが改行されませんが、FFの次バージョンである3.1(3.5)では、CSS3に対応している(らしい)こともあり、改行の指定が反映されて表示されるようです。(サンプルコード
画面5・ブラウザ間のword-wrapとword-break比較画面

これで、特殊な手段で対応する必要もなくなりそうですね。


ちなみにIE8のβバージョンでは、word-wrapが正常に動作しませんでした。試す場合は正式版でどうぞ。


【関連エントリー】
- へたれwebディレクターの覚え書き | hostsファイルの管理ツールと、変更した...
- へたれwebディレクターの覚え書き | overflowを指定するとFirefoxで範囲選択がうまくいかない
- へたれwebディレクターの覚え書き | 目の前の仕事が2分で片付くと思えばその場で片付け...
- へたれwebディレクターの覚え書き | スケーラビリティとは
- へたれwebディレクターの覚え書き | 携帯から投稿テスト
generated by 関連エントリーリストジェネレータ
Web > CSS | comments (0) | trackbacks (0)

mixi日記の公開範囲設定は「誰に見せて誰に見せてないの?」がバレてしまう

まわりに知っている人がいなかったのでなんとなくエントリー。


mixiの日記には公開範囲設定機能がありますが、「誰に閲覧を許可しているのか」は、その日記の閲覧権限があれば、日記投稿者本人でなくても確認することができます。

画面1・mixi日記の公開範囲設定は日記投稿者以外にも確認することができる


たとえばAさんが書いた日記をBさんが読めたとすると、Bさんは

「この日記、オレには読ませてくれてるけど、Cさんには見せてないんだねニヤニヤ」

という楽しみ方ができるのですね。


個人的にはバレてもぜんぜん構わないと思っているのですが、この話をまわりの人としたとき、思いのほか「公開範囲がバレるのは気持ち悪い」という人が多かったのでエントリーしてみました。


【関連エントリー】
へたれwebディレクターの覚え書き | mixiが少しずつ脱テーブルしている件
- へたれwebディレクターの覚え書き | mixi年賀状サービスで良いと思った点
- へたれwebディレクターの覚え書き |mixiとYahoo! Daysで、編集途中の日記を自動保存 ...
- へたれwebディレクターの覚え書き | リストタグで構成されたメニューのアクセシビリティを ...
- へたれweb-directorの覚え書き | 購入した本・2007年5月
generated by 関連エントリーリストジェネレータ
Web > 覚書き | comments (0) | trackbacks (0)

overflowを指定するとFirefoxで範囲選択がうまくいかない

自分用メモ書きです。


CSSにoverflowというのがあります。
縦横サイズを指定したブロック要素に内容が入りきらない場合に、はみ出た部分の表示の仕方を指定するためのプロパティです。


このoverflow、どうもFirefoxで指定すると、マウスドラッグによる範囲選択がうまくいかなくなってしまうみたいです。

overflowが指定されたdiv要素の中からマウスをドラッグすると、選択範囲がdiv要素外に広がってくれないのです。


(サンプルに『World Wide Web Guide』様の画面を利用させていただきました)

画面1・Firefoxでoverflowを指定した状態

この動作が正しいのか正しくないのかは分かりませんが、Firefox以外のブラウザではdiv要素外も選択できますし、少なくとも使いづらいことは確かです。


と言うのもわたしは『evernote』というツールを利用しているので、マウスによる範囲選択をよく使うのです。

ブログなどはマルチカラム指定であることが多いのですが、その枠をはみ出さないようにoverflowが指定されていることがよくあります。
Firefoxだと、段落ごとにoverflowが指定されている『こうちゃんの簡単料理レシピ』がevernoteにうまくメモれないので困ってしまうのです。


Firefox3.1で修正されていて欲しいなぁ。


【関連エントリー】
- へたれwebディレクターの覚え書き | Javascriptを勉強し直したい
- へたれwebディレクターの覚え書き | XAMMP再インストールでMySQLが起動しなくなったら
- へたれwebディレクターの覚え書き | エコバッグとレジ袋を考える
- へたれwebディレクターの覚え書き | プルダウンメニューの利用に適した条件とは
- へたれwebディレクターの覚え書き | 「新世代」に対応したサイト内フローについて考える
generated by 関連エントリーリストジェネレータ
Web > 覚書き | comments (0) | trackbacks (0)

Firefoxでログイン状態を保存してくれなくなったときの対処方法

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


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

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


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


現象としては、Yahoo!やmixiのログインページで、ログイン状態を保存するように設定しても、一度ブラウザーを閉じると、次にアクセスしたときにはログインし直しになってしまう、というものです。
画面1・次回からIDの入力を省略(枠線)にチェックを入れてもログイン状態を保存してくれない
おそらくですが、Firefoxのcookie保存設定がおかしくなってしまったものと思われます。

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

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


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

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


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

解決方法


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


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


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


【関連エントリー】
- へたれwebディレクターの覚え書き | hostsファイルの管理ツールと ...
- へたれwebディレクターの覚え書き | 他力本願でモバイル版『へたれ ...
- へたれwebディレクターの覚え書き | ジェンカのアバターを自分のサイト ...
generated by 関連エントリーリストジェネレータ
Web > 覚書き | comments (0) | trackbacks (1)

.htaccessでErrorDocumentを指定するときは相対パスで

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


ちょっと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ファイルに
ErrorDocument 404 http://www.studio-no9.com/sb/err/404.html

を設定します。


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


ここで自力解決はギブアップ。ネットで検索してみたところ、「御の字でございます」さんで以下のような記述を見つけました
チカッパやロリポップのレンタルサーバーは、存在しないURIにリクエストがあると302で広告ページにリダイレクトをかける。
.htaccessでErrorDocumentを「相対パス」で指定すると404のステータスコードを返す。


ということで今度は.htaccessファイルを、
ErrorDocument 404 /sb/err/404.html

に修正してみます。


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


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


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


まとめ


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


【関連エントリー】
- へたれwebディレクターの覚え書き | PGでもSEでもないのにサイトを ...
- へたれwebディレクターの覚え書き | 他力本願でモバイル版『へたれ ...
generated by 関連エントリーリストジェネレータ
Web > PG | comments (0) | trackbacks (0)

mixiとYahoo! Daysで、編集途中の日記を自動保存しておくGreasemonkeyスクリプト

javascriptの勉強をしていて、自分への課題で作ったものを何となく公開します。
今回は「タイマーによる関数呼び出しを使う」、がテーマでした。


『mixi』と『Yahoo! Days』で、編集途中の日記を自動保存しておき、いちどブラウザを閉じても復帰できるGreasemonkeyスクリプト


タイトルが長いですね。おかげですべて説明しつくした気がします。

仕組み自体は相変わらずシンプルです。
  • 編集フォーム内でキーが押されたらその2秒後に編集途中のデータをローカルに保存する
  • 2秒のカウント中にさらにキーが押されたら、カウントを2秒前の状態にリセット
  • 日記編集が正常に終了(つまり日記投稿完了)したら、自動保存データをクリア
  • 日記編集画面表示時に、自動保存データがあるようなら、「復帰」というリンクをこっそりと追加

仕組みがシンプルなかわりに、ソースは初心者丸出しのスパゲッティかと思います(どのくらい効率悪いコードなのかも自分でよく分かっていない…)。

たぶんすでに誰かがもっと良くできたものを公開していそうな気もしますが、一応アップロードしておきます。

mixidiaryeditreminder.user.js(mixi用)
daysdiaryeditreminder.user.js(Yahoo! Days用)

なおDaysでは、単純にフォームの内容を保存すると復帰したときにエラーになってしまうため(フォームに貼り付けた画像の情報をDBと照合しているようです)、タグをすべて削った状態を自動保存するようにしています。そのため保存されるのはテキスト情報のみです。
「まあ、ないよりはいいよね」ということで許してください。


今回ハマったところ:iframe内の情報取得


初心者なわたしがハマったのなら、ほかの初心者な人も同様だろう、と思い覚え書きを残しておきます。

mixiの日記編集画面は単純なform - textareaタグで構成されています。そのため、編集中データの取得も
document.getElementsByTagName('textarea')[0]

こんな感じで簡単です。

Daysはさらに簡単で、textarea自体にid名“rteEditIframe”がつけられていたので
document.getElementById('rteEditIframe')
であっさり取得できる

…と思っていたのです、最初は。

でもまったく取得できず。

調べてみたところ、iframeの場合、
document.getElementById('rteEditIframe').contentWindow.document.body.innerHTML

のようにしないといけないのですね。

iframeの仕組みを考えれば当然なのですが、この部分だけで3時間くらいかけてしまいました…。

しかしそのおかげで、けっこう頑張ってソースを読んだことと(Daysのjsソースをみてiframe内情報の取得方法を知った)、“designMode”というものの存在を知ることができました。

怪我の功名です。


参考にさせていただいたサイト


Greasemonkeyの共通な落とし穴を避ける』(minghaiの日記さん)
を参考にさせていただきました。ありがとうございました。
Web > PG | comments (0) | trackbacks (0)

『Norton Internet Security』って利用期間内ならソフト自体もアップデートできるのを知らなかった

まわりに知らなかった人が多かったのでエントリー。
(わたしも今日まで知りませんでした)


Norton Internet securityはパッケージ購入してから1年間、ウィルス定義ファイルのアップデートが行えますが、その期間内なら定義ファイルだけでなく、ソフト自体も無償で最新版にアップデートできたのですね。知らなかった。


ノートン先生は2008から軽くなっているので、それ以前のバージョンを使っている方はアップデートしてみてはいかがでしょうか。

画面1・Norton Internet Securityのアップデートページ


もっとちゃんと告知すればいいのに、と思いました。

Web > 覚書き | comments (0) | trackbacks (0)

hostsファイルの管理ツールと、変更したhostsをすぐFirefoxに反映するアドオン

サービス開発中は、開発用、テスト用…と複数の環境を切り替えて利用することがあります。
環境の切り替えはhostsの変更で行うと思いますが、複数のプロジェクトを同時に進めていると、もうどのhostsがどれなのやら分からなくなってきます。

そんなときにわたしが使っているツールを、「便利なのに周りで使ってる人が少ないなぁ」と思ったのでご紹介します。

あらかじめ設定しておいたhostsファイルを簡単に切り替える“Hosts File Manager”


hostsファイルを拡張子.hostsで保存しておけば、あとはメニューから簡単に切り替えることができる便利なフリーソフトです。
画面1・Hosts File Managerのhosts変更画面

「hostsファイルのこの行の設定だけ解除」なども簡単にできるので、テストのときにかなり重宝しています。

リンク


“Hosts File Manager”(Software Factory)


Firefoxを再起動しなくてもすぐに変更したhostsを反映する“Firefox DNS Flusher”


hostsファイルは変更しても、ブラウザに反映されるまでに時間がかかります。急いでいるときは、ブラウザを再起動した方が早かったりもします。
そんなときでもfirefoxなら“Firefox DNS Flusher”を使えば、すぐにhostsの変更を反映してくれます。

使い方は簡単です。アドオンをインストールしていると、ステータスバーにいま表示されているページのipが表示されます。
ここをクリックするだけで、hosts情報をリセットしてくれます。
画面2・Firefox DNS Flusherでhosts情報をリセット中

実験的アドオンなのでmozillaサイトの登録が必要ですが、それをするだけの価値はあると思います。

本当はこの二つのツールが一つになってくれたら最高なのですがねぇ。

リンク


“Firefox DNS Flusher”(Marco Tulio氏)


余談


firefoxはアドオンをたくさんインストールすると重くなる、といわれますが、とはいえ便利なアドオンはインストールしたままにしておきたいものです。

僕の体感ではアドオンよりむしろプラグインのほうが影響あるような気がします。
使わないプラグインを無効化すると、アドオンを削らなくてもキビキビしてくれる、ような気がします。
画面3・Firefoxのプラグインを無効化する

お試しください。
Web > 覚書き | comments (0) | trackbacks (1)

タブインターフェースを使うための条件

メニューの表示にタブデザインを採用するサイトが増えています。

が、個人的には、ただ見栄えがいいからとの理由でタブデザイン(タブインターフェース)を採用するのは反対です。

ちょっと前に『タブインターフェースと“世界観”』というタイトルで、タブインターフェースを使うのに適した条件を、自分なりに考えて書いてみました。
が今読んでみると、内容がアバウトで我ながら意味不明な点もあります。
そこで今回は、もう少し具体的に条件を考えてみます。

これが正解というわけではなく、あくまで自分のための覚書きです。ご意見などあればいただけるとうれしいです。

タブインターフェースを使うための条件


  1. タブの中にある情報が一つ、もしくは複数なら並列関係である
  2. ページの遷移が発生しない
  3. 複数タブの情報を同時に見る必要がない
  4. タブがデフォルトのままでもコンテンツの価値を失わない
  5. コンテンツの内容をタブのタイトルだけで伝えることができる

以下、それぞれの説明です。

1・タブの中にある情報が一つであること、または複数なら並列関係であること


1-1・タブの中にある情報が一つ

タブは、一つのデータを複数の条件で出し分ける目的に向いています。

例として、wikiのようなサービスが挙げられます。
Wikiでは、1ページ毎に、それぞれのページに対応した「閲覧」「wiki文法での編集」「リッチテキストでの編集」「ページ管理」といったメニューが存在します。それぞれのメニューに主従関係はありません。
このようなコンテンツの場合、タブインターフェースによる切り替えは理にかなっているといえます。
画面1・wikipediaのタブインターフェース(クリックで拡大)
画面2・wiki『Confluence』の編集画面(クリックで拡大)

1-2・タブの中にある情報が複数の場合は、すべてが並列関係

タブは、上下関係のない同じ種類の情報が大量にあったとき、それをある一定のルールに基づいてグループ分けして表示する目的に向いています。

ニュースサイトは(通常)、1ページに1つの記事が掲載されています。それぞれに上下関係はありません。このような状態を「並列関係」と規定します。

Amazon.co.jpにはかなり大量の情報がありますが、商品情報は(基本的に)「1ページ=1商品」です。このような場合に、タブによるグループ分け表示は適しています。
画面3・amazon.co.jpのタブ(クリックで拡大)
タブは並列関係にある同じ種類の情報を、あるルールにのっとって分割するから意味があります。情報に階層関係、主従関係があると、デフォルトのタブを開いている状態のときに他のタブをクリックしたらどのような結果になるかをユーザーが想像しづらくなってしまいます。

Amazonの場合、並列関係にある商品のみにタブが使われています。もし同じ種類に属さない、商品以外の「欲しい物リスト」や「カートを見る」がタブに含まれたら、とたんに難しいインターフェースになってしまうでしょう。

2・ページの遷移が発生しないこと


タブインターフェースを採用するなら、タブをクリックしたときにページ遷移をさせないほうがいいと思います。
ユーザーが、「タブをクリックしたらページ遷移が発生する」と想像しづらいからです。
ページ遷移が発生するかどうかわからないということは、タブを切り替えたときに「切り替えた前の状態が保存されているかどうか」の予想がユーザーにはつかない、ということです。

タブインターフェースを採用しつつページ遷移が発生する例として、Yahoo!メールとYahoo!カレンダーで起こる問題を考えてみます。
画面4・yahoo!メールとカレンダーはタブで切り替えるようなUIを採用している(クリックで拡大)
会議参加依頼のメールが届いて、その予定をYahoo!カレンダーに登録しようするときのフローを考えてみましょう。

  1. 会議参加依頼のメールが届く。参加を決める。
  2. 予定を登録しようと、タブ「カレンダー」をクリック。自分のカレンダーが表示される。
  3. カレンダーに予定日時を入力。
  4. 続いて場所も入力…しようと思ったときにメールに書かれていたはずの場所を確認していないことに気づく。
  5. 場所を確認しようと、メールのタブをクリックして、該当メールに戻る…つもりがメールサービスのトップページへ遷移してしまった。
  6. 慌ててカレンダーのタブをクリックしたら、カレンダーサービスのトップ画面が表示。カレンダーに入力途中だったデータは消えた。最初から入力しなければ。
  7. 凹む。

ページの遷移が発生することをユーザーが想像しづらいタブインターフェースでは、情報のリセットが行われると想像するのが難しく、「元のタブに戻れば以前の状態が保存されている」ように錯覚しがちです。

これがもしタブインターフェースでなかったらどうでしょう。
もしボタンメニューだったなら、ユーザーは「メニューをクリックすると単にページ遷移が起きる、だから入力途中のデータはなくなる」と想像がついたはずです。

3・複数タブの情報を同時に見る必要がないこと


上記「ページの遷移が発生しない」の例でもわかるとおり、カレンダーとメールは同時に表示しつつ利用することがあります。このような場合は、タブインターフェースを採用するべきではありません。

タブは小さなスペースで多くの情報を表示するのに適していますが、それらの情報を比較しながら閲覧することに向いていません(というか同時に表示されないので比較すらできません)。

4・タブがデフォルトのままでもサービスが価値を失わないもの


タブは、クリック率の低いインターフェースです。

ですから、「タブをクリックしてくれないとユーザーに楽しさが伝わらない」「クリックしなければサービスの目的が満たせない」ような場面で採用するべきではありません。

ヤフーのトップページにあるニュースコンテンツは優れた例だと思います。
画面5・Yahoo!トップのニュースコンテンツは優れたUIだと思われる(クリックで拡大)
「トピックス」という名前で注目の記事が表示されています。一般のユーザーは、トピックスの記事を目にすれば十分です。
もし他の記事を見たくなったり、他の記事を見る必要が生じた場合には、きっとタブをクリックしてくれるでしょう。
もともとニュースを見ることが目的なら、きっと「一覧」をクリックしてくれるはずです。

仮にユーザーがタブをクリックしてくれなくても、トップページの価値が下がることはありません。

5・コンテンツの内容をタブのタイトルだけで伝えることができる


ユーザーは「そのタブをクリックすることが自分にメリットがある」と感じなければクリックしてくれません。
ユーザーにそう感じてもらうにはまず、デフォルトのタグタイトルとタブ内に表示された情報を見て「自分は他のタグをクリックするべきか?」を判断してもらう必要があります。

上述のニュースの場合、ニューストピックスが表示されている状態で、「エンタメ」とのタブタイトルが目に入りました。そのときユーザーは、「エンタメ」をクリックするとどのようなコンテンツが表示されるのか容易に想像することができます。

逆にいうと、クリックして画面遷移しないと中身が想像できないコンテンツにはタブインターフェースは向いていません。

Amebaもタブメニューを採用しています。この「トップ」画面で、「ルーム」というタブ名からそこになにがあるか想像できるでしょうか?
画面6・amebaのトップページにあるタブはタイトルから内容を想像できない(クリックで拡大)
タブ名「ブログネタ」も中身が想像できません。きっとブログを書くためネタがあるのかなと思いクリックすると、いきなり謎の生物が表示されます。

しかもamebaではタブを階層化させてしまっています。階層化された奥に「クチコミ番付」というコンテンツが存在するとは想像もできません。
「各コンテンツが並列関係にない」「各コンテンツが同じ種類の情報で構成されていない」ため、タブの中身を想像しづらくさせてしまっています。もし「ルーム」や「クチコミ番付」がキラーコンテンツだったらどうするのでしょう。(幸い、キラーではありませんが…)

余談ですがAmabaのトップページ、初めて「リクエスチョン」をクリックするといきなりタブメニューが消えてしまうのもインターフェースをさらに難しくしています。

最後に:ではいったい、タブメニューとボタンメニューではなにが違うの?


前述したYahoo!メールとYahoo!カレンダーは、見かけはタブメニューですがajaxを使っているわけではありません。実際の動きはボタンメニューのそれです。
しかしたとえ仕組みは同じでも、ビジュアルがタブかそうでないかで、ユーザーがうける印象は大きく異なるのではないでしょうか。タブメニューとボタンメニューの違いは、仕組みの違いだけで判断されるべきではないと思います。

ビジュアルの違いでユーザーが受ける印象はどう変わるのか?の例として、「なぜチェックボックスとラジオボタンは別のグラフィカルデザインが用意されているのか」を考えて見ます。

チェックボックスは複数項目が選択可能です。一方、ラジオボタンは一つだけ選択させるときに使います。

ではチェックボックスのプロパティになにかフラグが増えて、それがONなら複数選択できない、という仕組みがブラウザに用意されたらどうでしょう?
ラジオボタンは無用になるでしょうか?

しかしそれではユーザーが、「今、自分は複数の項目を選んでいいの? それとも一つだけ選べるの?」というのを、画面を見ただけでは判断できなくなってしまいます。
ユーザーは、自分にどのような行動が許されているのかを、画面からの情報で判断するからです。


タブでメニューの表現はもちろんできます。しかし状況を考えずに使ってしまうとタブメニューであるからこそユーザーが感じることのできる「ここにある情報は並列で、同じ種類のものだ」という意味づけを失ってしまいます

ユーザーの理解を助ける役割を果たしている「暗黙のルール」を、安易にweb製作者が破壊するべきではないと思うのです。

追記


今回のエントリーを書くにあたり、以下のページを参考にさせていただきました。

タブインターフェースを採用することが決まったら、次に検討するのは「見やすく」や「高速に」などかと思います。それらについては参考ページに詳しいのでそちらをお読みいただくのがいいかと思います。
Web > UI / design | comments (0) | trackbacks (0)

XAMMP再インストールでMySQLが起動しなくなったら

自分が何度も引っかかるので、覚え書きを残しておきます。
なお、以下の記述はWindows XP professionalでのものです。


XAMPPを何度かインストール(アップデート含む)をしていると、MySQLが起動しなくなるときがあります。
古いバージョンのMySQLがサービスとして残っており、それが新しいバージョンとconflictを起こしていることが多いです。

その場合、古いMySQLのサービスを止めてしまえば正常に動作するようになります。


  1. コントロールパネルの「管理ツール」を選択
  2. その中の「サービス」を起動
  3. 「Mysql」をダブルクリック
  4. 表示されるダイアログボックス内の「実行ファイルのパス」がXAMPPをインストールした場所と違うことを確認(同じなら正常に上書きインストールができているので原因が別のところにある可能性が)

画面1・Windows XPのサービス管理画面(クリックで拡大)
  1. コマンドプロンプトを起動
  2. 現在XAMMPがインストールされているディレクトリに移動し、その中の「mysql\bin」に移動
  3. mysqld-nt --removeを実行

画面2・コマンドプロンプトでコマンドを実行
  1. XAMPPコントロールパネルからMySQLを起動

画面3・XAMPPコントロールパネルからMySQLを起動
これで無事に起動に成功しました。


ネット上では「mysqld-max-nt --removeを実行」と書かれている情報があったのですが、mysqld-max-ntといファイルが見つからなかったので、とりあえず「mysqld-nt --remove」を実行したらうまくいったので、もうこれでいいことにしてしまいます。


以上、自分用メモでした。
Web > PG | comments (0) | trackbacks (0)

サイトのリニューアルは「これからはこう使ってほしい」との提案があるべき

サイトをリニューアルするとき、今あるコンテンツの扱いをどうするか検討すると思います。
アクセス数をチェックして「このコンテンツは人気があるからもっとフューチャーしよう」「このコンテンツは使われていないから位置を下げよう」といったやり方が一般的です。

しかし、必ずしも今のユーザーの利用動向に合わせたリニューアルが、イコール正しいリニューアルというわけではないと思います。

私は、サイトのリニューアルは、「今こう使われているから」を考慮しつつも、「これからはこう使ってほしい」との提案があるべきだと思います。(そしてその提案は、トップページを見たら伝わる、というのが望ましいです)

機能が使われていないのは、「そのコンテンツが必要とされていないから」ではないかもしれません。
ユーザーに魅力を伝えきれていないからかもしれませんし、そもそもユーザーの興味をひいていないから、ひょっとしてユーザーが気づいてすらいないから、かもしれないからです。

サービスを提供する目的は「使ってくれると絶対に便利」「使ってくれたら絶対に楽しい」のはずであり、それには必ず使われ方の理想形があるはずです。


また、それらを明確にしよう、という視点で考えると、ペルソナやシナリオを作る意味もぐっと高まるように思います。


私たちがインターネットを通じて提供しているのは、単純にサービスではなくライフスタイルなのだ、というのを忘れないようにしたいです。
Web > idea/plan | comments (0) | trackbacks (0)

僕が『はてなハイク』をいいと思う理由

明けましておめでとうございます。今年もよろしくお願いいたします。

今年は
「『いい(もしくは悪い)』と思ったものがあったら、なぜそう思ったのかを文章化する」
というのを目標に持とうと思っています。

最近「いい」と思ったサービスに『はてなハイク』があります。毎日のようにログインしています。
ハイクについて、「どうして『いい』と思ったの?」というのを考えてみます。

例によってあまりまとまってないのですが、書きながら考えがまとまればいいなぁ、と思いながら支離滅裂なままアップします。


1. 「個人のつながり」「同じ趣味つながり」を一つの場所に集約している


コミュニケーションが発生するための条件は、主なものだけを大雑把に分けると
  • 「人をベースにした個人的つながり」(日記、など)
  • 「モノや場所をベースにした同じ趣味を持った人とのつながり」(コミュニティ、など)

の2つです。

今までのサービスでは、両者は別々のものとして扱われていました。たとえばmixiなら、「日記」と「コミュニティ」は別のコンテンツです。
しかしユーザーはそれらを、サービス運営者の期待通りには区別してくれません。たとえば「浜崎あゆみのライブを見に行った」人がそのことを書くとき、内容は「浜崎あゆみコミュニティ」に書き込むのがふさわしいようでも、日記として投稿することのほうが多いようです。

「同じ趣味を持った人がつながる」ためのトリガーが投稿されているにも関わらず、その投稿先が日記であったために、コミュニケーション発生のチャンスを逃しています。

いくつかのサービスでは、これらをどうにかしようという努力はされています。
voxでは、日記を投稿するとき、同時にグループ(コミュニティに該当します)にも投稿することができます。
mixiでは、日記とコミュニティは分離していますが、それぞれのページに遷移しやすいように導線が引かれています。
ブログなら、タグやカテゴリわけがその役割を担っています。

それに対してハイクでは、ひとこと日記を書けば、それがそのままテーマに変わります。「日記」と「コミュニティ(のテーマ、つまりトピックス)」がシームレスに繋がっているのです。

その結果、ユーザーは日記を投稿しようがコミュニティ的投稿をしようが、それをトリガーに「個人」「同じ趣味」、そして『はてなスター』による「レビュー」という三方向からのコミュニケーションが発生するのです。
投稿が「日記」なのか「トピックス」なのかは、受取り手(閲覧者)の都合で判断されます。

ハイクのキモは、「人つながり」と「テーマつながり」を同じ場所に展開させているところなのだと思います。


2. 書き込むためのネタが提供されている


投稿系サービスで、いきなり「なにか書いてね」と言われると困ってしまいますが、「○○について書いてね」と言われると、その○○に興味があるのならなんかしら書けそうです。

各サービスでは「今日のテーマ」のようなものを用意して投稿を促しています。
テーマをユーザーから募集しているサービスもあります。
mixiがニュースに力を入れているのも、投稿のネタとして有効だからだと思います。

ハイクでは、誰かがなにかを書き込むと、それがそのまま「テーマ」になります。タイトルが「キーワード」となってほかの人のページに表示されます。
同じテーマの投稿が重なると、コミュニティが自然発生します。

この流れがスムーズに行なわれるには
  • 日記に必ずタイトルがつく
  • 日記のタイトルと、コミュニティ的テーマ(トピックス名)は、扱いが似ている
との条件があり、一見難しそうに感じられますが、ハイクではそこをうまく成立させています。

ひとこと日記を書くときって、テーマもなく書いているように感じますが、実際には日記を書く過程で、脳内に「見えないタイトル」が存在していることが多いです。
たとえば過去に自分が書いていたタイトルのない日記(twitterとか)にタイトルをつけようと思えばつけられます。ただの雑談ですら「雑談」というタイトルをつけることができます。
テーマがない日記を書いているわけじゃなくて、「わざわざテーマをフォームに入力させる必要がなかった」だけであり、実際にはテーマは存在しているのです。

よって、タイトル≒テーマは成立します

これは「日記を書くモチベーションってなんだっけ?」というのを、ペルソナ、日記を書くまでのシナリオを組んで検討すれば誰でも気づけることなのかもしれません。が、気づくのは簡単でも、その解決策を思いつくのは難しいものです。ハイクのすごさは、それをやったところなのだと思います。(ペルソナとシナリオを実行するような会社だとは思えないので、たぶんひたすらブレストした結果なのでしょうが)


まとめ(というには支離滅裂)


はてなは「はてなスター」あたりから、明らかにサービスの対象を一般人向けにシフトしてきていると思うのですが、今回のはてなハイクもその路線を踏襲し、上流工程がよく検討されているサービスとの印象を受けます。

リリース直前にお絵かき機能をつけたことと、ITmediaのインタビューで書かれている「個人が一発アイデア勝負できる時代」は終わりつつあるという(ITmediaより引用)とは一見、矛盾しているように思われますが、それまでにさんざん検討を繰り返して上流工程を固めきったあとでしょうから、それをもってジャストアイデアだとは言えないと思います。

はてなスターも(内容から想像するに)アーリーマジョリティーを対象にしたサービスだったと思うのですが、うまく行っているとは言えません。が、ハイクと連携することによってキャズムを超えるかもしれません。


ハイクの今後ですが、「同じテーマで書き込んだ人」同士をより結びつけるための導線、そしてそれらを受け止める場所、が必要になってくるのではないでしょうか。
だたこれを用意するのは今まで述べた(僕が思う)ハイクの魅力と相反する部分もあるので、今はあえてコミュニケーションが行なわれる場を流動的にしておきたいと考えているかもしれません(それならそれで、画面上に「過去に自分と関係しているキーワード」が占めまくりすぎな気はするのですが)。


元同僚で、今ははてなにいる知人が
「仕様はシンプルに。機能でカバー」
と発言してたことがあります。僕はこの言葉を本当に真理だと思っているのですが、(彼がハイクに絡んでいるかどうかは知らないのですが)それを見事に体現したサービスだと思います。


ハイクをtwitterクローンとして見てしまうと、真価がわからない気がします。


追記


はてなのサービスって、もちろんサービス検討の際には「ひらめき」からスタートするのだとは思うのですが、ひらめきを仕様に落とし込む過程はかなりロジカルに思えます。サービスを検討する段階では「ひらめき」と「ロジカル」を絶えず行き来している印象です。
ひらめきのままに進んでいるように見えるのは「今までの常識」「すでに確定しているように見えるルール」を壊しているからだと思います。はてなの場合、その「今までの常識」「すでに確定しているように見えるルール」を壊すかどうかをとことんロジカルに判断しているのではないでしょうか。ちょっとどこで読んだか忘れてしまったのですが、「通勤時間と会社支給交通費に対する考え方」を読んだときにそう思いました。

そういう意味で、『「へんな会社」のつくり方』はネットを利用しているかどうか関係ない人に読んで欲しい本であり、『ウェブ進化論』より売れてよかったんじゃないかと思います。
Web > 覚書き | comments (0) | trackbacks (0)

mixiが少しずつ脱テーブルしている件

mixiが少しずつ、テーブルタグからの脱却を計っているようです。


先々週くらいにサブメニュー(トップページ-メッセージ-日記-動画…の列)が、そして今週はトップメニュー(ホーム、検索、友人を招待…の列)が、脱テーブル化しました。


ちょっと前に、それまでテーブルタグの固まりだったYahoo!ブログが一気に脱テーブル化を果たしたのですが、同時にそれによる副作用(リリース直後の不具合)が発生していました。
それを考えると、mixiのような少しずつの対応という選択もアリなんだと思います。


それよりも脱テーブルの目的のほうが気になるわけです。

web標準化する理由って、
  1. コーダーとしてのプライド
  2. 修正運用が楽になる
  3. 容量を減らす(サーバー負荷軽減)
  4. SEO

などが挙げられると思うのですが、きっとmixiは4番目を狙っているのではないかと思うのですがどうでしょう。
今後の戦略としてある程度のオープン化を視野に入れており、その効果を最大化するための準備としてhtmlを修正している。


と、適当なことを書いてみます。根拠はありません。
Web > 覚書き | comments (0) | trackbacks (0)

スケーラビリティとは

  1. サービスの利用される量の拡大に合わせて、小規模から大規模にスムーズに拡張できること。
  2. ユーザーが増えれば増えるほど、サービスが使われれば使われるほど、コンテンツ自体の質が高まること。
Web > 覚書き | comments (0) | trackbacks (0)

『CSS Nite LP, Disc 3 -Coder's High-』の裏テーマ

5月12日の土曜日、『 CSS Nite LP, Disc 3 -Coder's High-』に参加してきました。
以下、備忘録としてのメモ書きと、簡単な感想です。

「ザ・コーディングの美学」益子貴寛さん


  • コーディングの真・善・美
  • コーディングガイドライン策定の必要性
  • インデントの工夫でコードはさらに読みやすくなる
    • 読みやすくなる=共有・運用性の向上

あとで鷹野さんのセッションのときに、「このやり方はDw-CS3があれば自動でやってくれるのか!」と思いました。

「フィロソフィー・オブ・コーディング」小久保浩大郎さん


  • webは特別なメディア
    • webでは、「情報という『マテリアル』」を「形を持った表現」に変えるのは「情報の受け手の領域」だった
    • しかし「web2.0」では、情報の送り手と受け手の間に「仲介者の領域」がある
  • こだわるべきは「web標準準拠」ではなく「web標準にする理由」
  • なぜHTMLをクリーンにしなければいけないのか?
    • 正しいコードが、結局は自らの環境を良くする

なぜweb標準のコードを書く必要があるのですか?という質問に対しての答えを示す、というのがこのセッションのテーマだった。

「Dreamweaverのコーディング機能再点検」鷹野雅弘さん


  • コードヒントのカスタマイズ方法
  • タグインスペクタの活用
  • ソースフォーマット

「プログラマー」はそうじゃないかもしれないけれど、「コーダー」にとって、やはりDwは使いやすいツールであるのですが、それをさらに便利にさせる帰宅したらすぐに試せるテクニックが紹介されました。
あとで資料が公開されたら、Dwユーザーならばすぐに試せると思います。

「LIVE コーディング(A)」神森勉さん


  • いつもは(今回は違った)下層ページから制作を始め、スタイルやコードが組み上がったところで、最後にトップぺージを作る
  • デザインビューを使って制作。デザインビュー状でh1などテキストの階層化をしていく手法
    • これによりCSSを切ったときにどう見えるのかを常に意識する
  • ブラウザチェックはFirefox→Safari→Opera→IE7→IE6→その他の順
  • globalメニューはliで
    • 選択中のメニューはemで強調

今回の隠れたテーマは「マークアップエンジニアからの提案」だったと思います。

コーディング中に「どんなところで時間がかかったか」というお話があったのですが、横3カラムの角丸部分の挙げられていました。
しかし単純に「角丸が大変だから」ということではないと思います。神森さんレベルの人が角丸のやり方をわからないわけがありません。
迷ったのは
  • このモジュールはどのように更新されるのか
  • 横3カラム角丸ブロックじゃなくてもしかしたら4段になるんじゃないか?
  • そもそもここはinformationだけに使われるのか?

などによってコーディングのやり方が変わってきます。時間がかかっているのはその判断であるとのことでした。

「Microformatsで上質コーディング」長谷川恭久さん


  • MicroformarsはコーダーのAPI
  • 低リスク
  • 次世代ブラウザ(Firefox3やIE8)で正式対応(の方向)
  • 企画が完全に統一されていないが、wikiで検討されている
  • スパム的な使われ方はあるかも
  • 小さなケアが大きな差を生む(神は細部に宿る)

プレゼン始めに「○○をご存じの方、手を挙げてください」ってよくあるパターンですが、
(すでにプレゼンスライドはできあがっているわけですから、挙手の結果によってプレゼン内容が変わるなんてことはありません。
挙手はあくまで、プレゼンのつかみ。それをヤスヒサさんは完ぺきに行うところがすごいです。

個人的には(仕事の関係もあり)XFNなどの繋がり系メタデータに興味があります。

と何かを書くより、実際にこのブログに簡単なものを反映してみました。(ちゃんとしたコードになっていませんが…)

「プロはこう使う! Another HTML-lint 徹底活用術」太田良典さん


  • Yahoo!Japanトップのhtmlはひどい
  • 『W3C Markup Validation Service』とは目的に違いがある
    • あくまで文法の正しさのチェックのみ
  • コマンドラインで使うと便利
    • 一気に複数のファイルをチェック
  • 満点を狙うのが目的ではなく、正しい(x)htmlを書くのが目的
  • 実は有料

web developer toolbarから利用されることが多いであろう『Another HTML-lint』を利用する目的の再確認とそのコツです。

「LIVE コーディング(B)」河内正紀さん


  • ほとんどコードビュー
  • 大規模なサイトの場合、CSSはモジュール化して使う
    • clearfix用のCSS!
  • まずdivを設定していく
  • あがってきたデザインを見て、そこからロジックを読み取っていく
    • 全体の規模を想定して
    • 将来的な展開を(どんなモジュールが増えるか、など)を想定して
    • 横3カラム角丸ブロックをリストタグで
    • 「リンクターゲットを考えないコーダーはダメだ」(小久保さん)
      • マウスオーバー範囲
      • リンク先が同じならばaタグもひとつ

    このセッションを最後に持ってきたのは良かったと思います。
    このセッションの感想が、ほぼ全体のまとめになるからです

    『CSS Nite LP, Disc 3 -Coder's High-』の裏テーマはやはり「マークアップエンジニアからの提案」だったのだと思います。

    「デザインからロジックを読み取っていく」力というのは、web標準が一般的になると、マークアップエンジニアの能力差がそこで判断されるようになるのではないでしょうか。


    今後、思いついたことをちょくちょく追記していくと思います。


    あと、受講票を忘れてすみませんでした…。
Web > 覚書き | comments (0) | trackbacks (2)

競合サイトを手に入れたらどうする?

同僚が日記にこんなことを書いてました。

「競合のうちトップのサイトを手に入れたときにどうするか、を普段から考えてないやつはその仕事をする資格がない」


たとえば、業務でSNSを扱っているなら、普段から
「あなたはいきなりmixiの買収に成功しました。さあ、次に何をする?」
を考えていろ、ということです。

覚え書きとして。
Web > 覚書き | comments (0) | trackbacks (0)

友だち関係の整理

ソーシャルなサービスを考えるときに、どのような繋がり方があるかには一定のパターンが存在すると思います。

  1. 面識アリ 面識なし
  2. byname 誰でもいい(longtail?)
  3. 一方的 双方向


そのサービスが、何が得意なのか、もしくは何が得意になるべきか、という視点で考えればいいのだと思います。
Web > 覚書き | comments (0) | trackbacks (0)

Dreamweaverのテストサーバー機能を使うための設定

わたしはサイトの制作にDreamweaverを利用しています。

サイトの構築では、本番環境に反映する前のテストランは欠かせません。

企業でサイトを構築するときには、本番と同じ環境のテストサーバーをたてると思いますが、個人で作るサイトのためにそこまではできません。おそらくローカルでテストする場合がほとんどだと思います。

Dreamweaverには「テストサーバー」という設定項目があります。しかしこれの使い方の説明がマニュアルにあまり詳しい形で記載されておらず、市販の本でもほとんど触れられていません。

テストサーバー機能は、
  • レンタルサーバーを借りている
  • 自分用のドメインを利用している
  • PHP、MySQLを利用している
  • 本番サーバーにアップロードする前に、ローカルでテストしたい

上記に該当する人(要するにわたし)に便利な機能です。

先日、PCを再インストールしたときにテスト環境も再構築しました。そのときのメモを自分用の覚え書きとして載せてみます。

なお、以下の記述はWindows XP professionalでのものです。環境により、異なる点はあると思います。

ファイルを変更するときは、その前にバックアップを必ず取りましょう。また、下記の作業をされる方は、自己責任でお願いします
続きを読む>>
Web > PG | comments (2) | trackbacks (0)

BANANAサーバー