土曜日は１５年前に初めて買ったRustyのショートボードを引っ張りだしてみた。何の知識もなくロスで買った、６フィートで薄めのパフォーマンス系ボード。全然初心者向けではない（笑）。どうりで立つまで時間がかかったはずです。久しぶりに乗ってみると、回転性が高く、頭ぐらいの掘れた波だと面白い。それにしても、土曜日は夕焼けがすごかった。空全体を覆っていた雲と、西の山脈の間に、５センチぐらいのスキマがうまれて、強烈な西日が差し込む。濃いオレンジの日差しは雲を突き抜けて青空を照り返し、ダークブルーの波間に強いコントラストをつくりだしていた。日が落ちると、東の空から淡いブルーとピンクのグラデュエショーンが広がり、諧調を取り戻した白い雲が浮かぶ水平線で色彩が移り変わる様は、なかなかにサイケデリック。
日曜日は、今年の夏に買ったクラシカルなボンザーでライド。テイクオフのバランスが狭い、かなりやんちゃなボードだけれど、走り始めれば長いセンターフィンが、抜群のスピードとドライブを生み出す。風波の割にロングライドを楽しめました。
注文は日本ではなく、米国のAmazon.comに。１０月２８日に注文すると、即日に米国ケンタッキー州から発送されて、１１月３日の朝には日本の我が家にデリバリーされました。まずは、このスピード感にびっくり。早速、開封して電源を入れると、Jun's Kindleと表示されます。Amazonが設定まで済ませてくれているようで、ログイン名の入力などは一切なし。
そして不思議なのは、いきなり無線ネットワークにつながること。Amazonが米国のAT&Tと包括契約をしていて、国際ローミングによって世界中の携帯3Gネットワークに契約不要でつながるようです。通信料は無料。Kindleの端末を持っていれば、世界中、どこでもいつでもAmazonから本を買うことができるのです。
Kindle with U.S. & International Wireless
天気もよいので、キンドルを持ってビーチに散歩に出てみた。同時に購入したパタゴニアのケースに入れると、こんな雰囲気。
液晶とは異なり、電子ペーパー（eインク）の画面は太陽の下でもくっきり見えます。電子ペーパーのもうひとつの特徴は、電源を切っても、文字はそのまま表示され続けるということ。本体も非常に薄い。多くのハードカバーの書籍より、薄くて軽いでしょう。
画面も高精細で、地図のページなども普通に見えます。ただ、サイズ的にはもう一回り大きい方が、ガイドブックなどを見るのにはよい気がする。大画面のKindle DXも国際版として出荷してほしいですね。
ウェブブラウザも一応搭載しています。例えば、ガイドブックにホテルや現地の情報のURLが記載されていると、リンクをクリックしてホームページを見ることができます。ブラウザの速度、表示はいまひとつですが、これが全世界、無料で使えるならば十分有用でしょう。
書籍の購入は、Kindle本体からできますが、書籍を探すのはPCの方が効率的。こんな感じで書籍の検索、購入をしています。
で、面白そうな本を探して、"Send sample now"ボタンをクリックします。
英語の書籍だけれども、分からない単語は、英英辞書ですぐに調べられるようになっているので、自分の興味のある領域であれば結構読めてしまいます。音声で読み上げてくれるテキストtoスピーチにも対応しているので、目と耳の両方で理解することもできる。まずは、これでどれぐらい英語の書籍を読むようになるかどうか、しばらく使ってみようと思います。
by G-Tools , 2009/11/09
先週から今週末にかけて、梅雨に戻ったような天気でしたが、波には恵まれていたようです。土日も強まった南風でサイズアップ。風波ながら、フィッシュなら、インサイドまで乗り継げる波も多く、楽しめました。そして何といっても、ついにウェットのいらない季節に！ 夏の日差しに、ひんやりとした海水が肌に気持ちがいい。朝からたっぷりと３時間以上サーフィン。
夕暮れ時に、久しぶりにカメラを持って浜辺に戻ってみると、吹き上げる上昇気流に乗る鳩の一群。夕闇がせまるなか、あと一本、もう一本と、名残惜しく波に乗るサーファーを眼下に見ながら、浜風を翼にうけて、気持ち良さそうに上昇と急降下を繰り返していました。
情報を組織化することで、ウェブサイトを訪れる人が理解しやすくなります。ウェブサイトに多くのコンテンツがある場合は、目的の情報を見つけるためのナビゲーション設計にもつながります。『デザイニング・ウェブナビゲーション』によると、情報の分類とは、
分類とは、ある共通した側面に基づいたアイテムの組織化です。それは、ある共通項をもったアイテムと、そうでないアイテムの間に先を引くことです。カテゴリ、組織化体系、ラベルは密接に関係しており、そのうちのひとつだけを取り出して考えることは困難です。
それでも、分類体系の一般的な種類をいくつか挙げることはできます。これらは、２つのタイプに分類できます。それは、客観的ではっきりした体系と、主観的で漠然とした体系です。
『 デザイニング・ウェブナビゲーション P.207』 より
客観的体系の３種類と、主観的体系の３種類を、それぞれ、具体的な例で考えてみます。
『 Information Architecture for the World Wide Web 3e（Chapter 5, p.7）』による客観的体系とは、
This is called kwon-item searching. You know what you're looking for, and it's obvious where to find it. No ambiquity involved.
ユーザーが何を探しているのか知っていて、それがどこで見つかるかが明確なケース。曖昧さは一切ない。
客観的な組織化体系として、両書共に Alphabetical, Chronological, Geographicalの三つをあげています。
意味的な関連性はないので、訪問者が目的の情報を具体的に把握している場合のみ有効。主に辞書や百科事典でなどで使われる。ウェブサイトでも、コンテンツを索引から閲覧する場合など。
年月日（と時間）に沿って組織化する。歴史的な事実などは年表形式でまとめるとわかりやすい。企業であればプレスリリース、イベント情報など。個人ではフォトアルバムなど。マイクロブログのTwitterは、完全な時系列。ブログも時系列をベースにした組織化だが、最新の更新情報を伝えると共に、個別アーカイブも作成する。アーカイブでは、カテゴリーやキーワードに応じて、情報を時系列で並べて表示する。このように時系列は、他の手法と組み合わされることも多い。
時系列から、過去の記事を読む理由には、二種類あるのではないだろうか。ひとつは単純に、その著者に興味があって、記事を読み進める場合。もうひとつは、将来的に興味のある記事が更新されそうかを判断するため。過去記事の内容や更新頻度を見て、RSSフィードリーダーに登録するかどうかを判断することも多い。
国、地域、都市、街などの位置情報で分類。天気予報や旅行、レストランなど地理と結びついた情報は多い。ニュースも、地理的に分類される。自分で地名をクリックする意外にも、最近ではiPhone、携帯GPSなどで位置情報を取得して、自動でコンテンツを表示することも可能。
『 Information Architecture for the World Wide Web 3e（Chapter 5, p.10）』による、主観的体系の説明。
There's a simple reason why people find ambiguous organization schemes so useful: we don't always know what we're looking for. In some cases, you simply don't know the correct label. In others, you may have only a vague information need that you can't quite articulate. For these reasons, information seeking is often iterative and interactive. What you find at the beginning of your search may influence what you look for and find later in your search. This information-seeking process can involve a wonderful element of associative learning. Seek and ye shall find, but if the system is well designed, you also might learn along the way. This is web surfing at its best.
Ambiguous organization supports this serendipitous mode of information seeking by grouping items in intellectually meaningful ways.
人々が、曖昧な体系を非常に便利だと感じるのには、シンプルな理由がある。それは、自分で何を探しているのかを、常に知っているわけではないから。あるケースでは、単に正しいラベルをしらないだけかもしれない。あるいは、はっきりとしない、漠然とした情報を求めている場合もある。このような理由で、情報の探索は、しばしばインタラクティブで繰り返しをともなう行為になる。最初に見つけた情報が、その後に何を探すかに影響をあたえるかもしれない。このような情報探索のプロセスは、連想的に情報を知るという素晴らしい側面も持っている。システムがうまくデザインされていれば、目的のものを探す過程でも、何かを学ぶことができる。これはウェブサーフィンの醍醐味のひとつである。
曖昧な情報の組織化は、物事を知的で意味のある形にグルーピングすることであり、探索の過程でのセレンディピティを高める効果がある。
『 Information Architecture for the World Wide Web 3e（Chapter 5, p.10）』 より
そして、Topic, Task, Audience, Metaphor の４種類をあげています（Metaphor については、ちょっと今回は割愛）。
トピックだけで情報を整理するサイトは多くないが、逆にほとんどのサイトでは、何らかのトピックを提示する必要がある。ウェブサイトのトピックとは、見る人に対して、そのウェブサイトがどのような目的を持っているかを説明するということ。 企業サイトであれば、製品、サービス、コンテンツなどをグループ分けして、目的の情報を探しやすくする。トップページのナビゲーションは、それ自体がサイトのテーマを説明する必要がある。ユーザーがトップページを訪れた際に、「そのウェブサイトで何ができるのか」を一目で理解できること。情報量が多い場合は、ディレクトリやツリー構造で表示され、少なければタブ・バー・垂直メニューなどで表現が可能。
訪問するユーザーごとにコンテンツを切り替えて表示したり、個別のナビゲーションに誘導する。Audienceによる情報の組織化は、ウェブサイトをブックマーク保存して、頻繁に訪れる場合に特に有効。ユーザーは、自分の用途にあったウェブサイトのセクションをブックマークすることで、絞り込まれた情報にすぐにアクセスできる。逆に言うと、明らかに自分には必要ない情報を除外することで、迷うことが少なくなる。大きなウェブサイトを、対象とするユーザー毎に、いくつかの小さなウェブサイトに分割して見せるような効果がある。
ユーザーに提供する機能ごとの組織化。eコマースサイトでの買い物、問い合わせ、ブログでの記事の更新、スケジューラーへの要件追加など、いくつかのプライオリティの高いタスクを行いやすいように組織化する。GmailなどのWeb化されたソフトウェアを除くと、タスクによる組織化だけで、ウェブサイトとして完結するケースは少ない。ウェブサイトのトピックの中に、機能モジュールとして埋め込まれることが多い。
『ウェブの仕事力が上がる標準ガイドブック2 Webデザイン p.33』では、Richard Saul Wurman氏のLATCH法が紹介されている。これは情報の組織化の方法を５つに定義するもの。ウェブサイトに限らず、情報を整理するための包括的な組織化体系です。
『 Information Architecture for the World Wide Web 3e（Chapter2, p.10）』では、情報アーキテクチャを構成する要素として、Context, Content, Users をあげています。
Context は、ウェブサイトを運営する組織が、何を目標としているのか、その組織としてのミッションをベースに組み立てられます。どのような方法で、何の価値を生み、また、どういった組織文化をもっているのか。さらには、（企業であれば）他社に比べて、どうユニークなのか。今は何が強みで、将来的にどこに向かっているのか。あるいは、人員、技術、予算面などでの制約や、必要なプロセスなどの制限事項も含まれます。そのような、個々の組織のコンテキストにあわせて情報設計がなされるべきであると。
User は、ウェブサイトを訪れるユーザーや、サービスの顧客が、どのような属性をもっているのか。いつ、どのようにウェブサイトを利用しているか。そして、最も重要なのは、どのような情報を、ユーザーが求めているのか。
Content については、以下の６つの側面から定義づけられている（Chapter2, p.13）。
一方、『デザイニング・ウェブナビゲーション --最適なユーザーエクスペリエンスの設計（p.166）』では、ナビゲーション設計の観点から、以下のようにコンテンツを分析します。
二冊の書籍は、それぞれ、情報設計とナビゲーション設計という面から、コンテンツを定義しています。以下の表にまとめてみました。確かに、コンテンツの状況を分析、定義するのに役に立ちそうです。
| Information Architecture | デザイニング・ウェブナビゲーション |
|---|---|
| Ownership（所有者） | |
| Format（フォーマット） | |
| Structure（構造） | |
| Metadata（メタデータ） | ジャンル（Genres） |
| Volume（量） | 量（Quantity） |
| Dynamism（変化） | 頻度（Frequency） 寿命（Longevity） |
| リンクと相互参照 （Linking and Cross Referencing） | |
| 権威性（Authority） |
この『ウェブサイトの情報設計』について、基本を勉強してみたいと思い、主に以下の書籍を参照しながら、何回かにわけてまとめてみたいと思います。なを、記述内容や図については、書籍を読解しつつ、自分で書き起こしているので、正確な引用ではありません。内容に興味がわいたら、ぜひ原書を読まれることを、おすすめします。
まず初回は『情報構造のパターン』について。『デザイニング・ウェブナビゲーション --最適なユーザーエクスペリエンスの設計（p.200）』では、以下の５つのパターンに分類されている。
そのサイトの目的が明確で、ゴールがはっきりしている場合に有効。例えばキャンペーンの告知と申し込み用のサイトなど。ユーザーはいくつかのステップを経由して、最終的な目的を達成する。ECサイトなどは、階層型と直線型の組み合わせで、商品の発見は階層型だが、その後の購入までのステップは直線型になる。
直線型の派生系ともいえる。中心（ハブ）から、ユーザーの目的を選択して、ゴールに向かってステップを進んでいく。ひとつの目的が達成されたら、サイトの利用を終了するか、出発点であるハブに戻る。複数の直線型が、一つのハブから始まる型。
開始ページや最終ページが明確に定められていない。各ページは、リンクや相互参照でつながっていて、中心のない構造。インターネット（WWW）全体を見ると、このような構造。
ウェブ型の各ページは『ハブとスポーク型』のハブとして機能する可能性を秘めている。例えば、ソーシャルネットワーク・サービスのユーザー同士のリンク。閲覧者はその間を自由に移動しつつ、各ユーザーのプロフィールページを起点に、日記などの情報を見たり、メッセージを送るなどのアクションを開始できる。ページ同士のリンクをナビゲーションとして整理することで、ウェブ型の情報を、構造化することが可能、ということでしょうか。
通常のウェブサイトでよく見られるパターン。サイトのトップページ（ホームページ）を起点に、情報を親子関係で整理する。階層構造内で、下の階層のコンテンツは、親コンテンツの意味や内容を受け継ぎ、それを次の階層につなげる。
『Information Architecture for the World Wide Web 3e』の5.4.1. The Hierarchy: A Top-Down Approachでは、階層型をさらに二種類に分類しています。
階層の横の幅と深さ、この二つの間のバランスがとれた構造が望ましいとされる。ただし、ユーザーにとっては、クリックして進んだ先を確認するより、カテゴリーのリストをざっと見て選ぶ方が、瞬間的に判断できるので、深い階層より、浅くて幅広いもののほうがナビゲーションしやすい。トップページは階層構造への入り口になるため、ユーザーが「ぱっと見て、どこに行けばいいのか」わかるように、選択肢を並べておくのが有効。
階層型の情報構造では、適切なラベル付け、グループ分けがされていることが非常に需要。理想的にはトップページのナビゲーションを見ることで、ウェブサイト全体に、どのようなコンテンツがあるのかを理解できること。また、ウェブ制作においては、後からコンテンツが随時追加されていく場合も多いので、それを見越してバランスを設計したり、必要に応じて定期的に見直す必要があるだろう。
ひとつのページやコンテンツが、複数の親に所属するケースは、ポリヒエラルキー（複合型階層）と呼ばれる。例えば、複数のコンテンツの『連絡先』をクリックすると、ひとつの連絡用フォームのページに遷移する場合など。パン屑ナビゲーションなどで、表示がおかしくならないように気をつけて設計をする必要がある。
ファセット型は階層型の代わりに利用することができる。馴染みのない名前だが、ECサイトなどでは頻繁に用いられる。例えば、一眼レフカメラのレンズをECサイト上で探す場合。目的の機種を探すために、様々な絞り込み条件を組み合わせることになる。
これらの条件は、どこから指定してもよいし、また一部を組み合わせるだけでもよい。予算が決まっている人は、まず価格帯を選び、望遠・広角などの焦点距離を指定して、そのなかで最も安いレンズを選ぶ。一方で、より専門的な目的でレンズを探している人は、レンズの焦点距離、明るさから選び、最終的に予算を決定するかもしれない。このように、「ユーザーはさまざまな角度から情報にアクセスしようとする（P.203）」という特性にあわせつつ、情報検索に大きな柔軟性を持たせることができる。
また、ファセットを構成するカテゴリは、相互に排他的なので、新たにカテゴリを追加したり、既存のカテゴリの内容を変更しても、それが他のカテゴリに影響をあたえることがない。これは親子関係が定義されている階層型と大きな違いで、高い拡張性をもたらす。
Wikipedia のように、事前に計画するのではなく、コンテンツの投稿者によって自律的に構造がつくられるもの。投稿者が一定のルールや規則に基づきながらも、自由にコンテンツの方向性をきめることができる。発生型の多くはウェブ型の階層をもつことになる。Wikipediaのように、wikiというツールの操作性がナビゲーションや情報の構造を規定するケースもある。
あいにくの天気の日曜。強い南風で波があるのは分かっていたので、雨と風がやまないかな〜と待ちつつ夕方。風は強いものの、ひとまず雨は上がったのでサーフボードを持って海に出てみました。あいかわらずの強風で、海は崩れた波頭とスープで真っ白。ほとんどクローズアウトだけど、ショップ下の桟橋の横からなら、なんとかアウトに出ることができました。でもジャンクなコンディションも結構好きだったりするんですよね。風が轟々と吹き、そこかしこで潮が吹き上がり、海全体が沸き立つように躍動している。荒々しいのだけれど、うるさくは感じない。波の谷間で揉まれていると、不思議と静かな気持ちになってくる。そういえば、同じように強風で荒れた海を１月に撮影した写真があったのでのせてみる。
二次会でも力説してしまいましたが、藤本さんの『Movable Type Developer's Guide』は本当にすごい。cheebowさんの『Movable Typeプラグイン開発入門』とあわせて、ひとつのソフトウェア、というよりは、WEBアプリケーション開発フレームワークとしてのMTについて、ここまで深く知ることができるのは素晴らしいと思う（あとPDFなので検索できるのが便利）。ひとつのウェブページを表示するための.htmlファイルの先には、(X)HTMLという奥深い世界が広がっているように、MTタグの裏側にはWEBフレームワークという深遠なる世界への入り口があって、その構造を知ることは、言語やプラットフォームの壁を越えて、純粋なテクノロジーの世界をかいま見ることができて、なんだかとてもワクワクするのです。
]]>症状としては、インストール後に、MAMPのコントロールパネルからサーバを起動しようとしても、Apacheは起動するけれど、MySQLは起動しないという状態。まずはエラーログを確認する。
% more /Applications/MAMP/logs/mysql_error_log [ERROR] /Applications/MAMP/Library/libexec/mysqld: unknown option '-skip-federated'
このエラーメッセージをググると以下の記事があった。
Installing Magento Commerce and MAMP on Leopard 10.5.6 - Russ Back
別途パッケージでインストールしていた古いMySQLのmy.cnfの設定ファイルが問題ということ。/etc/my.cnf の以下の設定をコメントアウト。
# Disable Federated by default # skip-federated
ちなみに、過去にインストールしたMySQLが、Mac起動時に自動で起動される場合は、/Library/StartupItems/MySQLCOM にあるMYSQL起動スクリプトを実行しないように、/etc/hostconfig を設定してあげればよい。
% sudo emacs /etc/hostconfig hostconfig内の MYSQLCOM=-YES- という記述を以下に変更 MYSQLCOM=-NO-
MySQL :: MySQL 5.1 リファレンスマニュアル :: 2.5 Mac OS X に MySQL をインストールする
以上で、MAMPからMySQLも起動できるようになった。あと、/Applications/MAMP/tmp/mysql/mysql.pid が関係するケースもあるそうです。
]]>この写真の３月１４日も、逆湘南マジックな日。昼過ぎに波チェックをした時には、写真のようにオンショアが吹き荒れていて、ジャンク＆ハードなコンディション。沖に出ている数人の気合いの入ったサーファーの写真を撮りつつ一度帰宅。３時過ぎにボードを持ってビーチに戻りました。ヘッドランド横の強烈なカレントを使ってパドルアウトできるものの、セットをくらいながらパドルし続けて、なんとかポジションキープという状況。しかし日が傾くにつれて、南風も徐々が収まり、そのうちに緩いオフショアにチェンジ。急速に波がまとまり初めて、いつのまにか頭半からダブルのパーフェクトなラインナップに包まれていたのです。雲も切れ、強いオレンジ色の西日が、押し寄せる広大な波の斜面を貫いて、透明なグリーンに輝かせる。残念ながら写真は無い。それが湘南マジック。
Flickr to HTML : 画像を選んで<img>タグに（改良後）
使い勝手を改善するついでに新機能も追加。
ちなみに、改良する前のデザインはこちら。
以前のバージョンはかなり適当なつくりだったので、jQueryを1.3.2にあげつつ、jquery UI 1.7.1を利用。
flickr_idという名前で、Cookieをセットする
$.cookie('flickr_id', $.flickr.s.user_id);
Cookieから値を読み込んで、input フォームに入力
$("#flickr_id").attr("value", function(){ return $.cookie('flickr_id') || "" ;});
getJSONメソッドを呼び出すだけで、callback実行まで自動でやってくれます。
$.getJSON(url, function(r) {
// JSONを読み込んだあとの処理を記述
$.flickr.loadImages(r, $.flickr.s);
});
表示したいローディング画像やdivなどに、id="loading"を追加して、jQueryで以下を指定。
$("#loading").bind("ajaxSend", function(){
$(this).show();
}).bind("ajaxComplete", function(){
$(this).hide();
});
formのsubmitボタンに、jQueryで functionを追加する場合は、最後に return false; することで、IEなど一部のブラウザで画面遷移してしまうのを防げる。
$("form#flickr_form").submit( function () {
$("#container").show("blind");
$.flickr.s.user_id = $("#flickr_id").attr("value");
$.flickr.s.tags = $("#flickr_tags").attr("value");
$.flickr.s.per_page = $("form#flickr_form input[name=per_page]:radio:checked").attr("value");
$.cookie('flickr_id', $.flickr.s.user_id);
$.flickr.request();
return false;
});
jQueryの強力なセレクタと、each メソッドの組み合わせで処理を簡潔に記述。
// 選択されているチェックボックスの値を配列に追加
$("input:checkbox:checked.imagechoice").each(function(){
$.flickr.order.push(this.value);
});
if, else がどんどん短くなって楽しい。
var size = $("#menu_l").attr("checked") ? this.jpg.medium : this.jpg.small;
あと、inputがnullだった場合などに、デフォルト値を設定するのに ||も便利。
$.flickr.s.user_id = $("#flickr_id").attr("value") || "デフォルト値";;
このあたりは、jQuery本体や，jQuery UIのソースコードを読むとすごく勉強になりますね。次はクロージャなどを、ちゃんと使えるようになってみたい。
大磯駅の山側、妙大寺の角をまがって静かな住宅街の坂を上る。大磯は海と山が近くて、少し歩くだけでも随分と景色がかわります。駅から湘南平までは、羽白山（111m）を登って、尾根づたいに林間を約1.5Km。気持ちのよい山登りコースです。花見帰りや、犬の散歩の人々とすれ違いなら、ゆっくり歩いて１時間ほどで湘南平に到着。
ちょっと曇り模様で、桜は８分咲きぐらい。それでも頂上は沢山の人で賑わっていました。コーヒーを飲んで暖まりつつ、雨がぱらつきそうだったので、別のルートから下山。正味二時間ぐらいで、なかなかいい散歩道ですね。来週は満開から散る桜を、もういちど見に来てみようかな。
訳者あとがきによれば、「クルーグのユーザビリティ法則」とは（p.245）、
また、別のページではWEBサイトを巡るありがちな宗教論争への解決策として、『平均的なユーザーという神話』というチャプターに続いて以下のように記している。
「大多数のユーザーは、プルダウンメニューが好きなんだろうか？」というような質問をするのは生産的ではない。正しくは「このページのこのコンテクストで、こんなアイテムとこういう表現を使用したこのプルダウンは、このサイトを使用するかもしれない大多数のユーザーに心地良いウェブ体験を与えるのだろうか？」と質問すべきだ。
『 ウェブユーザビリティの法則』 P.153より
個々のページで、具体的に『ユーザーを考えさせるものは何か？』をつきとめ、それを改善していく。そのために必要なのが、なるべく早いタイミングで始め、できれば月に一度、継続的に実施する、ユーザビリティテストである。つまりそれは、ユーザーを考え込ませないだけでなく、ウェブサイトを制作する側の人々をも、無益な議論から解放するためのテクニックなのだ。
書籍中盤の、具体的な問題解決のアプローチも面白くてためになるのだが、読みながら何度も「その通り！」と痛快に納得するのは、著者が実際にそのような現場での右往左往に数多く立ち会って来たからなのだろう。結局のところ、絶対的に正しい回答などない。さらに、ユーザーからしてみれば、そもそも制作者の意図を１００％理解する必然性はないし、イラッとしたらブラウザのタブを閉じてしまえばいいだけなのだ。しかし、だからこそ、いかにユーザーが自信を持って、楽しくクリックしてもらうか、そのひとつのクリックに、沢山の工夫とクリエイティビティを込めることができる。それが最終的に、『なんとなく全体的に気持ちがいい』ウェブサイト、ひいてはユーザーからの信頼感につながっていく。
最後に、著者のウェブサイトでも公開されている第二章から見出を引用。
How we really use the Web
Why are things always in the last place you look for them?
Because you stop looking when you find them.
探し物がいつも、最後に探したところで見つかるのはなぜ？
見つかったところで探すのをやめるから
--Children's riddle（なぞなぞ）
- We don't read pages. We scan them.
人はページ内の文章を読まない。ざっと見るのみ。
- We're usually in a hurry.
たいてい、急いでいるから- We know we don't need to read everything.
全部読む必要がないのを知っているから- We're good at it.
なれているから- We don't make optimal choices. We satisfice.
人は最良の選択に時間をかけるよりも、ある程度満足できるところで妥協する。
- We're usually in a hurry.
たいてい、我々は急いでいる- There's not much of a penalty for guessing wrong.
見当違いをしたからといって、たいしたペナルティがあるわけではない- Weighing options may not improve our chances.
選択肢を比較検討しても、勝算に大した差が無いかもしれない- Guessing is more fun.
推測するほうが楽しい- We don't figure out how things work. We muddle through.
人はものごとの仕組みを理解しない。何とか帳尻を合わせて切り抜ける
- It's not important to us. For most of us, it doesn't matter to us whether we understand how things work, as long as we can use them.
ものごとの仕組みを知らなくても、めったに問題が起きないから。- If we find something that works, we stick to it.
何かうまくいくのがわかったら、そのやり方に固執するから- If life gives you lemons...
これら人生の真理に打ちのめされたのなら・・・
- if your audience is going to act like you're designing billboards, then design great billboards.
もし私たちが相手にしている人々が、我々のデザインしたものを看板のようにしか扱わないのだったら、素晴らしい看板を作ろうじゃないか
著者のページ : Advanced Common Sense Home
]]>
この写真は夕方のもの。サイズはだいぶ落ち着いてきていますが、徐々に長くなる日の恩恵をうけて、あと一本、もう一本と、週末の波を名残惜しむサーファー達。
今日の最後の一本を乗ろうと、水平線に降りてきた宵闇に目を凝らしていると、ふと周囲の光景がかわっているのに気がつく。見上げると、夜の青が西の空まで手を伸ばし、海岸通りの街灯が輝きをましている。崩れる波が、暗闇でゆらゆらと光を反射する。
$ cd /usr/local/src/php-5.2.x $ make clean $ ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql=/usr/local/mysql --with-gd --with-jpeg-dir --with-png-dir $ make $ make test
いくつかエラーが出たが一応完了。php.ini をきれいにすれば、エラーが出なくなるそうだが、ひとまずは後で。次に、Apache 2を停止して、PHPをインストール。
$ /usr/local/apache2/bin/apachectl stop $ make install $ php -m | grep gd $ /usr/local/apache2/bin/apachectl start
<?php phpinfo() ?> を記述した、test.php などにブラウザからアクセスして、GDモジュールが表示されていればOK。 PHP付属のGDを利用する場合は、 # yum install php-gd はしなくてよいのかな？
参考
]]>
