目次


Web サイトから Web アプリケーションへの変換

第 1 回 Web サイトと Web アプリケーションの違い

Web コンテンツを分析して賢い判断を下す

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: Web サイトから Web アプリケーションへの変換

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:Web サイトから Web アプリケーションへの変換

このシリーズの続きに乞うご期待。

はじめに

iPad、iPhone、Android といったアプリケーション中心の機器が溢れる今の世の中、「静的な Web サイトを作った」と言うのでは時代遅れです。Web サイトには、高度な検索機能があったり、購入方法が最低でも 3 種類は選べるようになっていたり、あるいは高度な Ajax 対話によるページが複数あったりするようでないと、「あまりにも 1998年的」だとみなされてしまいます。そんななか、多くの開発者たちは経営者側からの要求への対応に追われています。それは、対話性をもっと広げるようにという要求だったり、Amazon.com や Bing、あるいは IBM に後れをとるなという要求であったり、あるいは Web サイトを、なんと Web アプリケーションにしろという要求であったりします。けれども、その場その場で取り繕うのでは、焦点の定まっていない (そして場合によっては機能性を損ねた) Web コンテンツになりかねません。

Web サイトは、根本的に Web アプリケーションとは異なります。Web アプリケーションを構築するのであれば、何が Web アプリケーションと Web サイトとを区別するのかを知っておかなければなりません。一方、静的で JavaScript を使わないページを構築するのに慣れているとしたら、そのうちサイトを Web アプリケーションに変換しなければならないという焦りを感じてくるはずです。

この記事では、Web で実現したい目標に応じて、Web アプリケーションを構築すべきなのか、それとも Web サイトを構築すべきなのかを情報に基づき判断する方法を学びます。Web サイトと Web アプリケーションの違いを学び、この 2 つの概念が大きく異なっていることを理解してください。その主な違いを理解すれば、Web コンテンツのあるべき姿を判断する (あるいは、少なくとも影響を及ぼす) 準備が十分に整うはずです。

Web サイトは (必ずしも) Web アプリケーションではありません

読者の皆さんのなかには、既に構築済みの Web サイトがあるため、それを Web アプリケーションに変換する正当な理由はないという方もいるでしょう。あるいは、Web アプリケーションに相当な時間をかけているものの、実際には空回りしているだけの開発者を目にしている方もいるかもしれません。場合によっては、Web アプリケーションに変換するのはやめて、ごく単純な Web サイトを維持するほうが賢明なこともあります。そこでまず、このセクションでは Web サイトと Web アプリケーションの違いについて概説します。

Web サイトの主体は情報提供です

純粋な静的 Web サイトの最も簡単な定義は、情報提供を目的としたサイトであることです。その典型例はウィキペディアで、このサイトはもっぱら情報を提供するためだけに存在します。ウィキペディアは派手でもなく、刺激的でもなく、画像のポップアップやスクロール機能を完備した地図が散りばめられているわけでもありません。ハイパーリンクが張られた辞書と大差ない形で、そのままの情報が記載されているだけです (図 1 を参照)。

図 1. ウィキペディアの例
ウィキペディアのページのスクリーン・ショット。ページのほとんどがテキストです。
ウィキペディアのページのスクリーン・ショット。ページのほとんどがテキストです。

情報を最も良く伝えるための手段となるのは、大抵の場合、静的 Web サイトです。製品やサービスに関する情報、あるいは情報自体を広めることを目標としている場合には、Web サイトが絶好の出発点となります。当然、Web サイトには大きな反感もあります。Web サイトは華やかでもなければ、Twitter のつぶやきのネタになることもありません。そうは言っても、ほとんどの人々は新しいトピックを調べる際の最初の場所としてウィキペディアにアクセスします。このことから、静的サイトの真の価値は明らかです。

Web サイトは動的に駆動されることもあります

大部分のブログは、実際には Web サイトです。ブログ・サイトは WordPress や Movable Typeなどのプログラムで駆動されているものの、結局のところ情報主体のサイトであり、そのページは基本的に変化がなく、対話性もないものです。このことは、Web サイトと Web アプリケーションの重要な違いを示しています。それは、Web サイトであるかどうかは、そのサイトがどのように生成されるかではなく、ユーザーがサイトの情報と機能をどのように使用するかによって定義されるということです。この違いを理解すると、Web コンテンツでのユーザー・エクスペリエンスに重点を置けるようになるはずです。

最初の段階では、ユーザー・エクスペリエンスに重点を置いてください。ユーザーは、そのサイトを背後で支えているのが HTML と CSS であろうと、あるいは ColdFusion、PHP、Perl のどれであろうと関知しません。ユーザーはただ単に、目で見たものに基づいてサイトを評価します。自分がどのようなサイトを構築しているのか、または検討しているのかを把握するには、プログラミングから一歩離れる必要があります。そしてブラウザーを起動して、自分のサイトまでナビゲートして評価してください。

Web アプリケーションの主体は対話です

情報提供を第一の目的とするサイトでないとしたら、そのサイトはおそらく対話型サイトです。対話型サイトとは単に、ユーザーが受け身でサイトを使用するのではなく、積極的に参加することを意味します。ユーザーは検索、ボタンのクリック、フォームの入力、購入などの操作を行い、通常は常にキーボードとマウスに手を置いたままとなります。

最も頻繁に対話を行う代表的なものとして、コンピューター・ゲームを考えてみてください。コンピューター・ゲームでは、ユーザーは完全に自分から積極的に対話を続けます。それがゾンビを倒していくゲームであろうと、地雷原を進んでいくゲームであろうと、ユーザーはボタンを押しまくって決定を行い、それがさらにボタンを押すという行為につながります。もちろん、そこまでの対話レベルに達するサイトはほとんどありません。

大多数の Web サイトは、ある程度、異種の要素が混在しているハイブリッド・サイトです。一例として、図 2 に示す Amazon.com のホーム・ページを見てください。Amazon.com はハイブリッド・サイトですが、それでも情報提供型サイトであることに変わりはありません。

図 2. Amazon.com
Amazon.com のスクリーン・ショット。ページにはリンク、画像、テキストがあります。
Amazon.com のスクリーン・ショット。ページにはリンク、画像、テキストがあります。

上記の画面には、情報が満載されています。本、著者、価格、カテゴリーはすべて情報です。その一方、このページでユーザーが第一の目的とするのは、対話することです。そして、より具体的なカテゴリーまでナビゲートしていきます。また、特定の本を探し出して購入することもできれば、検索したり、自分のカートの内容を確認したりすることもできます。そのすべてが対話です。

ある特定の Web サイトが何らかの情報を表示しているとしたら、そのサイトが情報提供型なのか対話型なのかを判断するには、バランスを見極めることです。そのサイトで主に対話しているのか、それとも情報を読んでいるのか、そして 1 つのページに費やしている時間が 30 秒なのか、10 分なのかを考えてください。対話が主でページに費やす時間が少ないのであれば、対話型サイトにアクセスしていることになります。

情報提供型サイトと対話型サイトとは、どこが違うのでしょうか

ここまでは、かなり単純な二者択一方式でのサイトの評価について説明してきました。つまり、サイトが情報提供型または対話型のどちらかであるかという、白か黒かの判断です。

けれどもほとんどの対話型サイトは、実際には情報提供の要素も含まれるハイブリッド・サイトです。情報がなければ、実際に対話する対象もないからです。本も DVD も記載されていない、ボタンだけが並ぶ Amazon.com を想像してみてください。まったく意味がありません。ユーザーが反応する対象となる情報がなければ話にならないため、対話型サイトであっても、実は情報と対話を組み合わせたハイブリッド・サイトということになります。

なぜ対話型と情報提供型との違い (分類) を重視する必要があるのか疑問に思われるかもしれません。それは、情報の提供を主な目的とするサイトと、対話を発生させることを主な目的とするサイトについて、それぞれ別の見方で考えることに真の価値があるからです。この考え方の区別が、実は、主要な設計決定のほとんどを左右します。情報提供だけ、あるいは対話だけを目的としたサイトを構築することはめったにないにせよ、情報提供と対話のどちらの傾向が強いサイトなのかを識別することが、重要な鍵となります。

情報は、そのままの形で伝えるのが最も効果的です

情報提供の傾向が強いサイトの場合には、サイトにアクセスする人々に情報を提供することがサイト本来の目的になります。したがって、どのように情報を提供するかが問題になってきます。ユーザーが情報を必要としているとしたら、その情報を伝えるのに最適な形、そして情報 (通常は大量の情報) をオンラインで対象読者に伝達する方法を考えなければなりません。

ここで電子書籍、高度な出版形式、次世代出版形式に取り組んでいる人々が必死に注目を引こうとしていますが、果たして情報は次世代の情報通の読者向けに表現すべきなのでしょうか。現在、私たちには、ツールチップ、追加情報を表示するクリック可能なポップアップ、そして埋め込みの動画など、情報を表示する新しい手段もあります。

次世代の手法に頼るという考え方の問題は、これまで取られてきた手法は重要ではなく、ユーザーには慣れというものがない、ということを示唆しているように受け取れることです。人々は本を読むこと、辞書の項目を読むこと、ウィキペディアを読むことに慣れています。これらの情報源から情報を読み取る方法は、大抵は視線をページの上から下に、そして多くの言語では左から右に移していくというものです。そうやって大量のテキストを読む人々は、大抵の場合、中断されることなくテキストを読み続けます。実際、このような大量の情報は、中断されることなく読みたいと思うものです。

情報提供型サイトは、巷にある非常に派手で魅力的な、そしてほとんどの機能を備えたサイトを見本にするべきでありません。画像を使って内容を説明するのが適当な場合もありますが、例えば dictionary.com、Wikipedia といったテキスト指向の傾向が強い既存の人気サイトを見習う必要があります。もちろん、視覚的な要素を考慮して、さまざまなフォントを使うことや、アクセスしやすく、わかりやすいナビゲーションを目指して努力することはできます。目的は情報を提供することであり、情報の価値を損なうようなことや、情報の提供を妨げるようなことをすると、最終的にはサイト本来の目的に反することになります。

対話は中断によって成り立ちます

対話を確立しようとする場合、情報を提供することと何が違うのかと言えば、情報提供型サイトは中断をなるべく最小限にしようとする一方、対話型サイトは中断を最大限にしようとします。対話型サイトは常に、ユーザーにクリック、ドラッグ、または強調表示させたいという気持を起こさせます。つまり、片方向の環境ではなく、双方向の環境を作成しているということです。そのような環境では、ユーザーは受動的にテキストを読んだり、画像を見たりするだけでは満足しません。ユーザーはサイト内で先に進むために何らかの操作を行う必要があります。

ユーザーの操作が対話の鍵になるということは、操作のための中断が必要になるということなので、意図的に対話のポイントを作成する必要があります。ハイパーリンクだけでサイトをナビゲートできるパスがあるとしたら、情報提供型および対話型のサイトを上手く設計したことにはなりません。一方、ユーザーがボタンをクリックしてフォームに入力し、それから折り畳まれた情報セクションを探らなければならないように設計したとしたら、正しい考え方をしているはずです。

サイトに対話を組み込むには、サイトのシーケンス・マップを作成するという方法もあります。これは、ある特定のページのスクリーン・ショットを撮って、サイトの次のページまたはビューをどのように見せたいかを決めるという方法です。そして次のページ、さらにその次のページとスクリーン・ショットを撮っていき、ユーザーが A 点から B 点に辿りつくまでの連続したページのスクリーン・ショットが 4 つ、5 つ、あるいは 10 になるまで、この作業を繰り返します。

シーケンス・マップを作成する作業では、ユーザーがある画面から次の画面に進むときの方法を決定します。決定しなければならないのは、単純にリンクをクリックして次の画面に進むのか、それともボタンをクリックするのか、そしてマウスを動かす量、画面で発生するアクションの量、ユーザーが行う操作などです。サイトのどこで中断が発生しているのかを把握するには、これは非常に効果的な方法です。サイト内での進行にユーザーがどれだけ頻繁に関わらなければならないか、ユーザーが関わっていないとしたら、どれだけの数の中断を設定するかを考えてください。

対話型サイトの事例研究: Audi.com

シーケンス・マップがいかに役立つかを確認するため、事例研究として、ハイエンドの自動車メーカーの Web サイトから抜粋した画面のシーケンスを見ていきましょう。自動車は非常に高価な買い物なので、このサイトはユーザーを引き付け、感動させなければなりません。

図 3 に示すのは、Audi.com の Web サイトにアクセスすると最初に表示される画面です。対話を始める前からすでに、サイトは実に巧妙に出来ています。

図 3. Audi.com の開始画面
Audi.com ホーム・ページのスクリーン・ショット。ページは、対話を始める前からすでに巧妙です。ページ中央の自動車の写真を中心に、下にはサムネール写真、上にはナビゲーション用のリンクが並んでいます。
Audi.com ホーム・ページのスクリーン・ショット。ページは、対話を始める前からすでに巧妙です。ページ中央の自動車の写真を中心に、下にはサムネール写真、上にはナビゲーション用のリンクが並んでいます。

ユーザーはこのサイトとすぐに対話できるようになっています。次の画面 (図 4 を参照) は、マウスを 1 回クリックするだけで表示されます。自動車の下に表示された色見本のいずれかをクリックすると、瞬時に自動車の色に反映されます。メニューを検索する必要も、あちこち調べ回る必要もなく、ユーザーはすぐさまページと対話できるというわけです。

図 4. ユーザーのクリックに応答する Audi フロント・ページの画像
上記のスクリーン・ショットと同じですが、写真の自動車は赤になっています。これは、ユーザーがサイトとすぐに対話できることを示しています。
上記のスクリーン・ショットと同じですが、写真の自動車は赤になっています。これは、ユーザーがサイトとすぐに対話できることを示しています。

この時点から、Audi.com は比較的古い技術を多用するようになってきます。ドロップダウンや、マウスを重ねると表示されるメニューは目新しいものではなく、DreamWeaver のユーザーがこれまでもずっと使い続けてきたメニューです。けれども Audi が目指しているのは対話型サイトであるため、ドロップダウンからクリックさせるのではなく、本格的なイメージ、諸元表、そしてネストされたページに相当するものを表示します。

図 5 は、フロント・ページというよりもサイト内部のページといった感があります。Audi.com は、メニューを単なるナビゲーション以上のものにしていて、メニューにマウスを重ねると、クリック可能な選択肢が表示されるだけでなく、本格的なイメージおよび選択肢のリストが表示されます。

図 5. マウスをメニューに重ねると表示される本格的なイメージと選択肢のリスト
追加の写真、テキスト、選択肢を表示するメニューのオーバーレイを示すスクリーン・ショット。
追加の写真、テキスト、選択肢を表示するメニューのオーバーレイを示すスクリーン・ショット。

これは賢い対話手法です。ユーザーが何度もクリックしなくても、サイトが豊富なフィードバックを提供してくれます。しかもそれは視覚的フィードバックです。このように、サイトでは多くのことが行われている感じがします。対話には常に複雑な Flash アニメーションや操作が必要であるというわけではありません。Audi サイトでのように、上手く配置されたイメージが完璧に必要を満たす場合もあります。

図 6 は、対話の別の重要な側面を明らかにしています。それは単純さです。この図に示されているのはテキスト・ベースのメニューで、何も特別なところはありません。それでも、メニューのドロップダウンは整然としていて、現在選択されている選択肢が強調表示されています。このメニューは特別に画期的なメニューというわけではありませんが、サイトの他のすべての部分を踏まえ、このメニューはすぐに内容を把握できる作りになっています。そしてメニューにマウスを重ね、選択肢を選択し、クリックするだけです。混乱するはずがありません。常に、見たいと思う内容を確実に表示することができます。

図 6. 単純で、内容がすぐにわかるナビゲーション・メニュー
展開されたドロップダウン・メニューで現在選択されている選択肢が強調表示されている様子を示すスクリーン・ショット
展開されたドロップダウン・メニューで現在選択されている選択肢が強調表示されている様子を示すスクリーン・ショット

図 7 は内装のページです。極めて円滑に機能するフロント・ページは、印象の薄い、それほどのめり込むことのない内装のページとはペアを組みません。このページにはさらに多くの選択肢があり、どの選択肢をクリックするのでも、すべて中央のイメージに作用します。各モデルのページには、ユーザーの入力に応じて変更される多数のイメージがあります。色、ハンドルのタイプ、そして内装の模様のすべてが即時にイメージに反映されます。

図 7. 読むよりも、クリック操作が関係する視覚的な内装ページ
Audi.com の内装ページのスクリーン・ショット。自動車の各モデルの内装ページには、ユーザーの入力に応じて変更される多数のイメージがあります。
Audi.com の内装ページのスクリーン・ショット。自動車の各モデルの内装ページには、ユーザーの入力に応じて変更される多数のイメージがあります。

明らかに、このサイトでは多大な作業、設計、プログラミングが行われています。多くのサイトが採用するような対話モデルではないとは言え、そのシーケンスは重要です。このサイトでは、ユーザーが先に進むには一貫して対話の必要があります。対話すればするほど、提供される情報量が増え、ひいてはサイトからの応答も増えていきます。

スクリーン・ショットを印刷すると、ユーザーがどのように対話するか、そしてその対話がユーザー・エクスペリエンスの点で何をもたらすかが至って簡単に見て取れます。時間を割いて、この演習を行ってみてください。スクリーン・ショットの出力を床全体に広げるのは馬鹿げたことのように思えるかもしれませんが、ユーザーがサイトに飽きて、そこから離れてしまうよりはましです。

対話は自然に起こるわけではありません

対話型の手法で何よりも考慮しなければならならないのは、画面上で対話を設ける場所です。これは、「ウィジェットを画面左上に配置するか、右端に並べるか」というだけのことではありません。基本的な手法には、以下の 2 つがあります (一方の考え方はお勧めできません)。

  • 必ずしも物理的な中心位置に対話を配置することはせず、ユーザーがサイト内で進んでいく途中に配置する。そして、ユーザーが先に進むには、対話しなければならないようにする。
  • 情報を中心に対話を散りばめる。対話は刺激的ではあるものの、サイトの進行には必須ではない。

推奨されるのは、最初の手法です。対話は、既存のサイトの最上部に固定できるようなものではありません。なぜなら対話は、表示されている情報の周囲に差し込めるわけではなく、情報そのものに関連しているからです。上記の図 567 を見ると、対話が情報自体 (メニューの選択肢) に結び付いていることがわかります。対話と情報のどちらか一方だけを取ることはできません。

対話と情報を混ぜ合わせてください

サイトのハイブリッド化の概念に立ち戻ると、極めて対話性に優れたサイトであっても、ある時点で情報を表示する必要があります。コンピューター・ゲームを例に考えると、コンピューター・ゲームはサイトでさえもありませんが、あちこちで必要な情報を取得している間、画面が暗転するかロード画面を表示するという手段に訴えざるを得ません。

その一方で、情報提供に徹したサイトは、ある時点でユーザーがクリック、または検索できるようにする必要があります。検索、クリックの必要がないように、ウィキペディアの情報すべてが 1 つのページに記載されていたとしたらどうなるか想像してみてください!そうだとしても、ユーザーはスクロールしなければなりません。スクロールは、最も基本的な対話です。このように、すべてのサイトは情報と対話で混成されたハイブリッド・サイトです。ほとんどのサイトは、例えば情報が 90% で対話が 10%、あるいはその反対といったように、どちらか一方に極端に偏ってはいません。大抵は 75% 対 25% くらいの比率です。対話型サイトでは情報の割合を決定し、情報提供型サイトでは対話の割合を決定することになります。そしてこの決定は、適切なものにしなければなりません。

どんなに素晴らしい対話を作成できるとしても、情報を上手く提供できるようにならなければなりません。また、どんなに優れた情報設計者でも、何らかの時点で、ある程度の対話を作成する必要が出てきます。

ハイブリッド・サイトとなると遥かに難易度が上がります

問題の核心は、対話を作成するのがどんなに得意であっても、情報設計にもかなり優れている必要があり、世界に通用する情報設計者でも、意味のある対話を作成する方法を覚えなければならないという点です。この 2 つの分野の両方で成功するのは、簡単なことではありません。大抵のサイト作成者はどちらか一方の分野を得意とし、サイトはその作成者の得意分野に偏っています。奇妙かつ皮肉なことに、一方の分野 (対話または情報提供) に非常に優れているサイトは、もう一方の分野がお粗末になっています。目標はもちろん、対話と情報提供の両方で成功し、極めて強力なサイトあるいはアプリケーションに仕上げることです。

何よりもまず、情報設計を除外して対話に取り組むという方法、あるいは対話を除外して情報設計に取り組むという方法は避けてください。そのような方法で作業すると、一方の分野が優れていても、もう一方の分野が弱点になってしまいます。どちらか一方の分野に集中して取り組んだ後は、必要に応じて臨機応変に、もう一方の分野にも取り組むことを目標にするべきです。1 つのサイトで、あるタイプのコンテンツと別のタイプのコンテンツを 75 対 25 の比率にするという考えに賛成であれば、75 パーセントを占めるコンテンツでの作業量を、もう一方のコンテンツでの作業量の 3 倍にすることをお勧めします。これはもちろん、出発点としての基準です。

次のステップは、作業を繰り返し行うことです。常にサイトを設計し、対話を作成し続けてください。余暇をWeb サイトの手直しに費やす設計者は、平均して、余暇をギターの習得に費やす設計者よりは優れた設計者に成長していきます。

そして最後に言っておくべき点として、苦手な分野には積極的に関わってください。来る日も来る日も情報がぎっしり詰まったサイトに取り組んでいるとしたら、ちょっとした対話を追加できる領域を探してみることです。JavaScript と jQuery を追加して、折り畳み可能な領域を追加してください。情報提供型サイトで対話を増やして、情報と対話の比率が 60 対 40 に見えるようにしてください。その逆も当てはまります。対話型サイトでは、サイト内の情報の量を増やす方法を見つけてください。例えば、適切なタイミングでテキストを表示するサイドバーやペインを作成するのも一考ですが、いつもより多くの情報を伝えるようにすることが肝心です。このようにして、弱点となっている分野を改善していきます。

自分のサイトを使用してください

ここまで読んできた皆さんは、呆れた顔をして、あまりにも当たり前の内容を説明しているこの記事の著者は、自分が何を言っているのかわからないのだ、と思っているかもしれませんが、もう少し我慢して、次の一言を聞いてください。

自分のサイトを存分に使用してください。

単純なことのように聞こえますが、自分の演技を見たくないと思っている多くの俳優や、自分の CD を聴こうとしない多くのミュージシャンと同様、多くの Web 設計者はサイトの開発が終わるなり、すぐに次のサイトの開発に取り掛かるものです。このような開発者は、コーディングし、設計し、アップロードした後は、そのサイトを忘れ去ってしまうため、サイトがどのように利用されているかがまったくわかりません。しかし、Web 設計者はユーザーがサイトをどのように利用するかを想像し、目に見えない架空のユーザーを前提に作業をしているため、開発後のサイトをおざなりにするのは良い習慣とは言えません。

ですから、自分のサイトを使用してください。使用してみて気に入らなければ、ユーザーもそのサイトを気に入らないはずです。「自分にはシステムしかわからない」、「自分と同じようなユーザーは一人もいない」として、問題を早急に片づけないでください。それよりも望ましい反応は、「このサイトをユーザーのために改善するにはどうしたらよいのだろう、ユーザーは自分と似ているのか、そうではないのか」を考えることです。このちょっとした思いやりが、サイトについての見方を劇的に変えることになります。

まとめ

優れた Web 設計をするための方法は、コンポーネントを作成して JavaScript でコーディングする間、この記事 (これ以外の記事でも) の説明を繰り返し引用することではありません。そうではなく、この記事で概説した原則を評価し、自分のものにした上で、それを土台に独自の原則を確立してください。この記事の原則をやみくもに実行するのではなく、この原則についてじっくり考えてこそ、サイトとアプリケーションは改善されることになります。

この記事では、皆さんそれぞれの Web コンテンツが現在、Web サイトのように機能しているのか、それとも Web アプリケーションのように機能しているのかを判断するための原則を説明しました。Web コンテンツをより情報提供型のサイト、または対話型のサイトにする必要があると判断したにしても、あるいは現状のままで問題ないと判断したにしても、重要な点は、自分が何をしているのかを考えることです。この記事を読んで、わずかな情報を基にした、明確な意図のない決定ではなく、情報に基づいた意図的な決定を下せるようになっているはずです。

この記事の内容を理解した上で、規則を破ろうとしたり、誰かが書いた内容に反論したりすることは、自分にとって最善の方法を見つけようとしていることを意味します。コンテキストは人によってさまざまです。一人ひとりにとって有効な方法を説明するには、その人自身が「独自の記事」を書く必要があります。それはそれで好ましいことですが、とりあえずは、この記事が名案を思い付くきっかけとなることを願います。記事の最後の「コメント」セクションで、私の考えに対する賛成意見、反対意見をお寄せください。皆さんからの意見を聞き、それぞれのコンテキストについて、そしてそのコンテキストに合わせてホーム・ページを進化させる方法について是非、お知らせいただきたいと思います。


ダウンロード可能なリソース


関連トピック

  • Web のユーザビリティーに関してディスカッションするなら、Jakob Nielsen の Web サイトにアクセスしないことには始まりません。このサイトには、多数の記事と優れたリソースが揃っています。
  • ユーザビリティーと密接に関連するのはアクセシビリティーです。使いやすいサイトは必ずと言っていいほど、高いアクセス性を誇っています。アクセシビリティーについての詳細は、Web Accessibility Initiative (WAI) を調べてください。
  • User-Centered Design and Web Development」(1998年7月) は古い資料ですが、この記事の最初のほうのセクションで説明した重要な問題について検討しています。
  • ウィキペディアのユーザー中心設計についての記事は大いに参考になります。ここには、他の資料へのリンクも記載されています。
  • XHTML と CSS については、『Head First HTML with CSS & XHTML』(Robson、Freeman 共著、O'Reilly Media, Inc.) で、初心者にもわかりやすい概要と、その概念についての丁寧な説明を読んでください。
  • Head First Web Design』(Wattral、Siarto 共著、O'Reilly Media, Inc.) を読んでください。Web デザインについて丁寧にわかりやすく説明しているこの一冊で、ユーザビリティー、色、レイアウト、ナビゲーションの詳細だけでなく、知的所有権についても理解できます。
  • developerWorks Web development ゾーンでは、多種多様な Web ベースのソリューションを取り上げた記事を揃えています。
  • Prototype: ページの操作、面倒な JavaScript アクションの自動化、そして画面エフェクトの統合に最も役立つ JavaScript フレームワークです。
  • script.aculo.us: もう 1 つの必需品、script.aculo.us は、移動、モーフィング、動画化など、絶妙な GUI のエフェクトを Web ページに追加するためのエフェクト・ライブラリーです。このライブラリーは、Prototype で駆動するサイトに追加するには最適です。
  • MooTools: 軽量で極めて巧妙な moo.fx は、script.aculo.us が Prototype に追加する究極の画面エフェクトを、MooTools に対して追加します。
  • Fundraiser Insight: 集めた資金額を示すウィジェットをサイトに追加しようとお探しの場合は、Fundraiser Insight を調べてください。金額を目盛りで示す、Web にぴったりの複数の温度計を用意しています。
  • PHP Fundthermo: この PHP イメージ・ジェネレーターは資金集めを目的としていますが、あらゆる類の進捗を示すために簡単に調整することができます。
  • ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Web development
ArticleID=498230
ArticleTitle=Web サイトから Web アプリケーションへの変換: 第 1 回 Web サイトと Web アプリケーションの違い
publish-date=06012010