Liner Note http://note.openvista.jp 情報(ユーザー中心デザイン・ユーザビリティ)と技術(ウェブプログラミング・ウェブサービス)についてのメモ書き Mon, 23 Dec 2013 06:43:43 +0000 ja hourly 1 http://wordpress.org/?v=3.8 Webアクセシビリティの広さと深さ http://www.openvista.jp/archives/note/2013/width-and-depth-of-accessibility/ http://www.openvista.jp/archives/note/2013/width-and-depth-of-accessibility/#comments Sun, 22 Dec 2013 05:38:10 +0000 http://www.openvista.jp/archives/note/?p=1469 こういう言い方が適切かわからないけど、Webアクセシビリティにも広さと深さがあるなと思う。

広さ

広さとは、ある文書がどれだけ扱いやすい、接近しやすいかということです。

例えばプログラミング言語にとっては、PDFはライブラリなどを使わないことにはアクセスしづらいですし(狭い)、一方でMarkdownのようなプレーンテキストであれば、どんなプログラム言語からでも容易にアクセスできます(広い)。
また例えば人間にとっては、Wordで書かれた文書はWordを持っていないとアクセス出来ないのでこれも狭いといえるでしょう。

深さ

深さとは、文書内の特定の情報に対するアクセスのしやすさです。

例えば、ある文章のキーワード、タイトルなどの情報がすぐにわかれば、区民が区役所の文書にアクセスする際に探しやすくなります。また区役所内の方が文書にアクセスする際には、タイトルやキーワードに加え、少なくとも執筆組織/者、関連担当組織/者、執筆時刻、承認者あたりは簡便にアクセスしておきたいでしょう。それが担保できていれば深く、できていなければ浅い文書というわけです。

深さを担保するコスト

これであれば、ガリガリとマークアップしたHTMLが最強という感じがしますが、実際はそんなに簡単な話ではないでしょう。

深さは上記のように文書の目的から決まってきますが、あれもこれもとあちこち深くすることを求めると逆に作成コストがかかってしまい、執筆者の意欲を失わせますから、逆説的に浅い文章しか生まれなくなってしまいます。ですから、実際のところは広さを担保しつつ、執筆者のコストとユーザのメリットがとれたあたりで深さを担保することになるでしょう。

So what?

なぜこういうことを考えたかというと、Markdownは確かに文書へのアクセシビリティを高める上で重要なアプローチだと思うのですが、それはあくまで広さを広げるものだと思うのですね。

Markdownで文書をあまり深くはできないし、文法や理念的にもそうするものでもない(あまり拡張性を求めないほうが良い)と思うので、YAMLなどのMarkdownと相性のいい(人間が読み書きやすいという意味で)構造化データと組み合わせて使うのがよいのかなと。それで、広さとは別にどうやって深さを深めていくかという議論も、文書標準化と絡めて考える必要があるでしょうね。

…と、@zerobaseさんの一連のツイートを見て思った次第。

ちなみに、ここで扱っているWebアクセシビリティとは、情報への到達しやすさを示すものであって、自分の考えるWebアクセシビリティ(利用者の目的を達成するために文書内容を活かして伝える)の中の一要素という感じです。

]]>
http://www.openvista.jp/archives/note/2013/width-and-depth-of-accessibility/feed/ 0
font-awesome の アイコンから目的のアイコンをちゃちゃっと絞り込む http://www.openvista.jp/archives/note/2013/font-awesome-icon-finder/ http://www.openvista.jp/archives/note/2013/font-awesome-icon-finder/#comments Tue, 17 Dec 2013 17:53:15 +0000 http://www.openvista.jp/archives/note/?p=1465 作りました

ローカルで動かしたい人はGithubからどうぞ。

一覧はfont-awesomeのウェブサイトから持ってきているので、アップデートされても安心。入力欄になにか入れると、マッチしたアイコンだけに絞りこまれます。

Alfred2とのコンビのほうが10倍くらい便利な気がしますけど、仕事場はWindows環境なのでやむなく・・

]]>
http://www.openvista.jp/archives/note/2013/font-awesome-icon-finder/feed/ 0
ウェブはつながることで強くなれる(地域観光情報編) http://www.openvista.jp/archives/note/2013/connect-web-on-sightseeing-information/ http://www.openvista.jp/archives/note/2013/connect-web-on-sightseeing-information/#comments Sun, 15 Dec 2013 11:37:15 +0000 http://www.openvista.jp/archives/note/?p=1457 この記事はWeb Accessibility Advent Calendar 2013の15日目の2本目の記事です。1本目の記事はこちら

さて、私は旅行が好きなほうで、季節が変わるごとにどこかに出かけたりするんですね。それで、ある程度がっしり計画を立てる派なので(もちろん自由時間は作りますけど)、行きたいところを付箋に洗い出した上で、、電車のダイヤ(自動車免許がないのでレンタカーが選択肢にない)を見つつ、Powerpointの旅程表に落としていくわけです。

これが結構骨が折れる作業なのですが、本筋とはあんまり関係ない話なので端折ります。端的にいうと、地方は鉄道で移動する場合、便数があんまりないところがあり(1,2時間に1便とか)それが旅程を組む上でのボトルネックになるので、試行錯誤をしないといけなくてたいへんだということです。

「地方政府の観光サイトより観光雑誌のほうが便利」問題

で、まあそんなこともあって、旅程立てるツールでも作ろうかなと手を動かしていたんですね。これに加えて観光情報も選べるようにしてサービス化できれば面白いなあと思って、地方政府の観光案内サイトを見ていたら、問題意識がふつふつと湧いてきました。

僕は行きたいところを選ぶ時には、適当にるるぶやことりっぷのような観光雑誌をザッと読んで、行きたいところに付箋でマークするみたいなやり方を取ってます。でも、「行きたい都市の名前 観光」でぐぐれば、だいたいはその地方の観光案内サイトなりページなりが出てきます。観光振興のために作ってるんですね。

各地方政府の観光情報サイト

でも、僕はあんまりそういうサイトを見ることはなくて、なぜかというとサイトの構成が市区町村毎に違っているので、学習するのが大変なんですね。その点、観光雑誌はどの雑誌もある程度似た構成で、かつもちろんどの市区町村でも同じフォーマットになっている。

観光ガイド

余談:ただ、観光雑誌に不満がないかというとそうではなくて、口コミサイトに慣れた身には10も20もある飲食店からどうお店を選べばいいかわからないし(決定に必然性がない)、各観光スポットへ行く電車がどれくらい出ているのかがわからない(電車があまりないので行かないということもよくある)。

また、モデルプランがそのまま活かされることはほぼないので、結局旅程を一から組み直しになるのも面倒です。

この状況は地方政府にとって、とてももったいないものです。厳しい財政の中からそれなりの予算を立てて、観光案内サイトを構築・運営しているわけですから、どうせならそれらがうまく活用されるようにしたい。前の記事でも言いましたが、これはコンテンツの活用性の価値の問題です(内容面の話もなくはないですが・・)

だから、各地方政府が作ったコンテンツをつなげて、活用できるようなプラットフォームを考えたいなと思ったのです。

地方政府の観光情報を役立てる仕組み

それで考えた仕組みがこういうものです。基本は最初に言った旅程構築ツールなのですが、その中で地方政府の観光情報が役に立つというもの。

もうちょっと詳しく書くと(結構端折ってますけど)

  1. まず、各地方政府は各スポットの情報(名前、種類、写真、必要費用、営業時間、日平均訪問者数、住所、簡単な説明や見どころなど、スペシャルサイトのURLなど)を投稿します。項目は標準化されていて、入力後は横軸での検索なども行いやすくなっています。
  2. 各スポットは地図上にマッピングされ、訪問者数が大きいところほど大きいマーカーで表示されます。
  3. ユーザは地図上から各スポットの情報を見ながら、気に入ったところに★をつけていきます。
  4. ★をある程度付け終わったら、旅程構築に移ります。★スポット同士を結んでルートを構築していきます(電車の便数が少ない観光地は淡く、電車の便数が多いところは濃く表示されます)
  5. 作ったルートは一般や仲間内に公開でき、かつ旅行当日にスマートフォンで確認することもできます
  6. 他のユーザは既に作られた観光ルートをforkしてカスタマイズすることもできます

特に、最後のルート公開・共有がポイントかと思っています。

旅行者はそれぞれ自分の行きたいところがあるわけですから、地方政府や観光雑誌の紋切りプランではなく、自分なりに行きたいところなども混ぜて再構築できることが、納得できるプランを作るために必要になってくると思っています。

また、一方で初見の人はどんなところが人気があるかわからないわけですから、定番を一度見てみるというニーズもあると思っています。知らない場所に行った時に、食べログでこのへんで一番人気のある店って何かな?と探したことってありませんか?そんな感じです。

できれば地方政府の連合体なりがやって欲しいけど・・

僕は、各地方政府が個別バラバラに特集サイトを持つのではなく、あるプラットフォーム、できれば地方政府がお金を出し合って、旅行準備というユーザのタスクに着目した上で、こういう風にサービスを構築して、三方良しな状況が生まれたら素晴らしいなあと思うのですね。

まあ、あんまりそういう動きも目にしないので、勝手に作ってみようかなという状況ですが。

]]>
http://www.openvista.jp/archives/note/2013/connect-web-on-sightseeing-information/feed/ 0
ウェブはつながることで強くなれる(ご飯屋さん情報編) http://www.openvista.jp/archives/note/2013/connect-web-on-gourmet/ http://www.openvista.jp/archives/note/2013/connect-web-on-gourmet/#comments Sun, 15 Dec 2013 02:39:58 +0000 http://www.openvista.jp/archives/note/?p=1426 この記事はWeb Accessibility Advent Calendar 2013の15日目の1本目の記事です

コンテンツはもうウェブには充分すぎるくらいあるのだけれど

僕は割とランチを楽しみにしていて、勤務先の新宿界隈にある美味しいランチがある記事はよくブックマークしています(まあ、遠くて昼休みには行けない店のほうが多いのですが・・)。そういう記事をさっき調べてみたのですが、本当にいっぱいあるのですね。

はてなブックマーク上の多くの飲食店系記事

ただ、実際にそのブックマークを開くかというと、あまり開きません。昼休みになって、ビルの階下に降りてごはん屋を決めるまでのその間は、ブックマークをガツガツ開いて状況にピッタリのお店を探すには少し短すぎるからです。

多くの飲食店情報ページは情報掲載量も違いますし、Googleマップや食べログなどユーザが利用したいサービスに自分で登録する必要があります

できれば

「ここから徒歩10分以内で行ける、美味しいパスタが食べられて、男子でもそこそこお腹がいっぱいになるくらいの料理を出してくれる上限1,000円程度のお店」と言えば、
「はい、それですと〇〇というお店がいいですね。ここからあのビル方向へ徒歩5分、先月△△さんの記事で見つけたもので、人気メニューは☓☓です。よければ口コミも見ます?」

とか

夜中11時に「うどん屋さんでまだ空いてるところってあるかな?」と言えば、
「この近くにはありません。隣の駅で良ければ、2件のうどん屋さんがまだ空いています」

と言ってくれるくらいだといいですね(まあ、ある程度はSiriで実現できるのですが)

Googleマップ for iPhoneで各店舗をブックマークしている状態

ただまあ、そこまではできないのですが、Googleマップに入れておけば場所くらいはわかります。なので、無いよりはマシということで、最近はそういう記事を見つけては、店舗の住所をGoogleマップの検索欄に放り込んでで検索、スターを押して後で参照できるようにしています。その時はもう機械のようにやっていますが、さすがに最近は面倒になってきてやることも減ってきました…


コンテンツの2つの価値

もちろん面倒さに負けてそっとタブを閉じるのは本意ではないのです。読んでみて美味しそう!と思ったのだからそのお店には行ってみたい。行ってみてやっぱり美味しかったのであれば、またそのサイトをチェックしてみたい。

そう思うと、コンテンツの価値って2つに分けられるのかなと思うんですね。

内容面での価値と、活用性という面での価値です。ここでは前者は、記事を読んで美味しそう!行ってみたい!いい情報をありがとうと思わせるような価値、後者は実際にその情報がどれくらい使われるかどうかという価値です。

いくら読ませる記事でも実際に使わなければ、結果的にリーチしたかどうかという点で考えると、不十分でしょう。要するにそうした観点での価値とは、記事のPVではないですし、はてなブックマークでブックマークされた数でもないですし、twitterやFacebookで言及された数でもありません。

僕のブックマークには、そうした活用性という点ではまだ今ひとつな記事が、残念だけど結構ありました。でもそれはマッチングミスであって、もったいないことです。

こういうウェブ上に散らばった情報が、サービスをまたがってつながって集約できるとしたなら、それはウェブ自体の価値を大きく高められるんじゃないか。これが今、僕がWebアクセシビリティを意識している動機です。

余談:ちなみにですが、僕は情報の内容面での価値を、減損なくフルに伝えるための活用性こそがWebアクセシビリティであると捉えていますし、これは一般的な定義よりは広いものだと思っています。

一般にアクセシビリティとユーザビリティは区別されますが私は一体で捉えています。背景として便利なウェブサービスが一般化してきた昨今、使いやすくなければ利用されないというケースも出てくるのではないかと思っていて、ですから、ある情報のアクセシビリティ=情報へアクセスし、利用できる度合いを考える際には、使いやすさ(それはサイトやサービスのユーザビリティではなく、ユーザのタスクに対するユーザビリティです)のような要素も加味しなければならないのではないかと考えています(もちろん、狭義のアクセシビリティが満たされることで、他のユーザビリティの高いサービスがそれを利用して、結果としてユーザビリティが高まることはもちろんあるでしょう)

情報アーキテクチャの領域(データを整理し、統合し、組織化することで、わかりやすい形として提供する、あるいはそのための環境を設計する)に近いかもしれません。

飲食店をマークアップする方法

じゃあ、どうするの?というところですが、実はMicrosoft,Google,Yahooというウェブの巨人がこういう風にマークアップしてくれたら検索エンジンが情報をクロールする際に、意味まで解釈して拾うことがりやりやすくなるよ!という標準パターンを作ってくれていたりします(schema.orgというサイトで公開されています)

そして、飲食店をマークアップするための標準も公開されています。

これに則って、先日行った鶏の炭火焼が美味しいお店をマークアップするとこうなります。

HTMLソースコード
<div itemscope itemtype="http://schema.org/Restaurant">
  <p itemprop="name">白銀屋</p>
  <p itemprop="description">魚と鶏の炭火焼のお店。メニューは魚が多いけど、大山鶏の刺身ステーキというもも肉を焼き上げた定食がおすすめ。外はカリカリ、けど中は生肉。生肉好きには結構お勧めです。大根おろし、柚子胡椒、ワサビなどの薬味?と一緒に添えていただきます。中は結構狭くて小さいのでMAX3名程度。</p>
  <p itemprop="aggregateRating" itemscope itemtype="http://schema.org/AggregateRating">★★★★☆ (<span itemprop="ratingValue">4</span>/<span itemprop="bestRating">5</span>)</p>
 
  <dl>
  <dt>住所</dt>
  <dd itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
<span itemprop="postalCode">160-0023</span>
    <span itemprop="addressRegion">東京都</span>
    <span itemprop="addressLocality">新宿区</span>,
    <span itemprop="streetAddress">西新宿7丁目19-7 1F</span>
  </dd>
  </dl>
 
  <dl>
  <dt>営業時間</dt>
  <dd>昼:<meta itemprop="openingHours" content="Mo-Sa 11:30-15:00">月〜土 11:30-15:00</dd>
  <dd>夜:<meta itemprop="openingHours" content="Mo-Fr 17:30-23:30">月〜金 17:30-23:30、<meta itemprop="openingHours" content="Sa 17:30-22:00">土 17:30-22:00</dd>
  </dl>
 
  <dl>
  <dt>価格帯</dt>
  <dd><span itemprop="priceRange">1000円前後</span></dd>
  </dl>
</div>

これは面倒・・。ここまで面倒だと手で書くことを前提としたものではないのでしょう。

改善策

そうすると、策は2つかなあと思います。

シンプルマークアップ+外部データ形式

手で書けるくらいルールをシンプルにしてしまいます。また、住所や営業時間の詳細な店舗データはGoogle Placesのような外部のサイトからAPI経由で参照する形式にします。

HTMLソースコード
<div itemtype="http://example.com/SimpleRestaurant" itemhref="https://plus.google.com/116216321529596287243/">
  <p>店名:<span class="name">白銀屋<span></p>
  <p>感想:<span class="description">魚と鶏の炭火焼のお店。メニューは魚が多いけど、大山鶏の刺身ステーキというもも肉を焼き上げた定食がおすすめ。外はカリカリ、けど中は生肉。生肉好きには結構お勧めです。大根おろし、柚子胡椒、ワサビなどの薬味?と一緒に添えていただきます。中は結構狭くて小さいのでMAX3名程度。</span></p>
  <p>評価:<span class="rating">4/5</span></p>
</div>

MarkdownやYAMLのようにテキストはプレーンに近い形にしておいて、書くハードルを下げるものです。ただ、似た仕様を乱立させることになるのもあまり良くないと思うので、こちらは無いのかなあという気がしています。

ウィジェット形式

例えば、食べログなどの飲食店検索サービスがウィジェットを配布していて、それを使えば上記のようなコードが簡単に自分のブログに埋め込めるというもの。twitterのツイートやYoutubeの動画を埋め込むような感覚ですね。

今のところ、ウィジェット形式でできるといいなと思い、ただそうしたことをやっている有名サービスは知らないので、フォームなどに店名などの情報を入力することで簡単に埋め込める飲食店ウィジェットを考えているところです。

公開できるようになったら、またこちらのブログでお知らせします(※著作権的に問題のない情報をどう持ってくるかが今のところの課題です)

ウィジェット実装例

大サイズはレビュアーの感想に加え、店舗写真、各サービスへの追加ボタン、店名、評価、地図、住所、最寄り駅、定休日、営業時間、予算を記載しています

小サイズはレビュアーの感想に加え、店舗写真、各サービスへの追加ボタン、店名、評価、最寄り駅、予算を記載しています

まとめ

上記ウィジェットについて利点をまとめておくと、

ウィジェット利用者のメリット
  • 簡単にお店の情報を引っ張ってこれるので手間がかからない
  • 詳細に構造化されたコードが貼り付けられるので、いわゆるSEO効果が期待できる(参考:Google – リッチ スニペットと構造化データについて
  • 今までより実際に利用される確率が高まり、サイトリピート率向上が期待できる
閲覧者のメリット
  • Googleマップ、食べログなど自身のワンボタンですぐに利用できるようになり、情報を有効に活用できる
  • おみせ情報を統一した形式で見ることができるため、情報の過不足などがなく、知りたい情報がサイトによらず入手できる
  • ぐぐらビリティが上がることによって、掲載サイトを忘れたとしても検索して呼び出しやすくなる?

という感じでしょうか。

さて、飲食店以外にもトピックはあるというか、前振りのつもりでこの話を書いたら長くなってしまいました。それはまた別記事で

]]>
http://www.openvista.jp/archives/note/2013/connect-web-on-gourmet/feed/ 0
UXデザインとレイヤー思考 http://www.openvista.jp/archives/note/2013/layered-thinking-of-ux-design/ http://www.openvista.jp/archives/note/2013/layered-thinking-of-ux-design/#comments Sat, 14 Dec 2013 02:47:44 +0000 http://www.openvista.jp/archives/note/?p=1413 UX Advent Calendar 2013というユーザエクスペリエンスに関する記事をみんなで書いて繋いでいこうという趣旨の企画があるのですが、今年はこれにのっかって、UXデザインに関する記事を書いてみることにします。

UXデザイン(UXD)や人間中心デザイン(HCD)は勉強してみて、自分の仕事(UIデザイン)で日々役立ってると感じるんですが、それはUXデザインの手法を知れてよかったというより、その考え方や視点を得られてよかったというものですね。

いろいろあるのですが、今回はレイヤー思考というのについて書いてみたいと思います。

天気予報のベストなUIって?

UIデザインのディスカッションは、しばしばそこだけに視点を限定してしまって近視眼的になりがちです。

例えば、天気予報会社がスマホ用の天気予報アプリを作ろうとなった場合、最初のスクリーンで調べる地域を指定するUIは何がいいかという話で、日本地図から絞り込むのがいいか、住所を直接キーワード入力させるのがいいか、いや、地域指定はGPSを使えばそもそも必要なくなりますよね、という話とかがあるかもしれません。

しかし、この議論は地域指定をどうやってしてもらうかが議題で、指定すること自体は前提になってしまっています。

ただ、アプリケーションの想定利用シナリオが「多忙な社会人が朝出かける前に今日傘が必要か確認しておきたい」というのであれば、そもそも指定すること自体が時間のロスになるわけですから、一度すれば後は不要という仕組みのほうが望ましいでしょう。一例として、雨が振りそうな日は指定時刻(例えば家を出る5分前とか)に自動でプッシュ通知で教えてくれる「あめふる」というアプリがあります。

いろいろな天気予報アプリ

けれど、天気予報を見るときに僕らが見るのって降水確率だけではないですよね。寒い日は一枚余分に羽織って行ったり、さらに風が強い日はマフラーをしたりするかと思います。

すると、先ほどのシナリオは「多忙な社会人が今日の格好や持ち物を手早く決めるための情報を入手したい」と再定義できます。そう考えると、朝起床する時間に自動でアプリが立ち上がっていて、傘の必要性やどういう格好をすればいいかについてアドバイスを得られるというコンセプトが考えられます。

コンセプト例
行動するための天気予報アプリ1(風が強くなる場合)

もはや天気予報アプリではないかもしれませんが、だからこそ天気予報のUIを議論しても仕方がなくて、利用シナリオからUIの方向性を考えなければいけません。

ちょっと話をまとめておきましょう。さきほどのシナリオの「〜入手したい」の価値を考えた上で、サービスの価値 → その価値を実現する利用シーン → 利用シーンに最適なUI/操作というステップでまとめてみます(ちなみに、こういうシナリオを段階別にまとめたものを構造化シナリオと言います)

ユーザ
朝早く出勤し、夜遅く帰宅するような多忙な社会人
シチュエーション
朝出かける前
利用シナリオ
  1. サービスの価値:出かける準備に無駄な時間を使わず、余裕を持って家を出られる
  2. 価値を実現する利用シーン:傘や服装について必要かどうか手早く決められる
  3. 利用シーンに最適なUI/操作:朝起きたら、アプリが傘の必要性が必要な服装について教えてくれる

構造化シナリオ例

上記の「傘や服装について必要かどうか手早く決められる」ですが、これはアプリでなくても、メール、テレビでも実現できるでしょうね。変わり種で言えばPhilips Hue雨の日に明かりを青にするとか空想で良ければ自動的に最適な格好を選んで出しておいてくれるクローゼットなんかもあるかもしれません。

要するに、最適なUI/操作はあくまで手段なので、それを実現する手段はいろいろあるわけです。それは価値を実現する利用シーンという目的次第で、ユーザに一番最適なものを選べばいいわけです。

ただ、その利用シーンも目的ではなくて、それ自体もサービスの価値を実現するための手段だったりします。例えば「出かける準備に無駄な時間を使わず、余裕を持って家を出られる」のであれば、それこそ毎朝料理を宅配する、簡単に作れる料理を検索できる、外出がある予定の日にカバンの中身を入れ替えられるバッグインバッグなどそれを実現する利用シーンは無数にあります。

手段は目的次第ですから、今議論していることは何の目的を実現しようとしているのかを常に意識しておく必要があると思います(付け加えると人間は忘れっぽいものなので、目的を常にどこかに見えるようにしておくとベターです。利用シーンとUIを一緒に並べて対応関係を見るストーリーボーディングとかいいかもしれませんね)

でないと、地域指定UIは何がいいかねという議論、あるいは地域指定のリッチなUIの開発という本質的でないところ、必要でないところにリソースを割いてしまうことになります。

利用シーンを俯瞰して考えてみる

その必要でないところ、というので言うと、さきほどのアプリについて例えば想定ユーザの8割がテレビで天気予報を見ていて、「傘がいるか」「服装はどうだ」みたいな情報を得ているのであれば、アプリさえも不要でしょう。

それは競合アプリが何をしていて、うちはこれがない、あれはあるとかいう枠内で見ていてもしょうがなくて、そのニーズに関する生活シーン全般を見渡して、果たして何が満たされていて、何がそうでないのかを考えないといけないと思うわけです(僕らはしばしば事業者視点でユーザを縦割りにして考えがちですから)

一人暮らしの料理を例にしたカスタマージャーニーマップの例

カスタマージャーニーマップというのは、そういう生活シーン全般を見渡して、俯瞰するような役目があって、そうすることでニーズ全体の何がどういう手段で満たされていて、何が満たされていないかを掴むことができます。

また、それを描いておけば、利用状況も実感を持って描けますから、各UI/操作へブレイクダウンする際に最適解を考えやすくなります。

レイヤー思考

ここまで、段階別のシナリオを立ててUIから利用シーン、価値へとさかのぼって考える、利用シーン全般を描いて俯瞰することで必要性や利用状況を明らかにする、ということを見てきました。

僕自身はUIデザインの仕事をしているのですが、UIだけを考えるのではなくて、実際は価値・利用シーン・UI、あるいは製品の組織や地域/社会における意味みたいな複数のレイヤーを行ったり来たりしながら、UIデザインをしています。

これが僕の考えるUXデザインのレイヤー思考というところで、上記のシナリオやカスタマージャーにマップにも見られるようにはそういうところがあるのかなあと思っています5 Planes Modelには明確に示されていますが、もう少し易しく話したいなと思って書きました)

あと余談として、もう少し僕個人の文脈を明らかにしておくと、お客さんからアプリケーションやウェブサイトの依頼をいただく時には、この画面をなんとかしてほしいというUI/操作の点の話が多いんですね(ディスカッションの現場ではもっと細かくてボタンの位置とかラベルとか・・)

でも、そのUI視点だけでデザインをすると泥沼になるし(そもそも目的がないからできないんですが)、本体必要なかったものを作ってしまうかもしれない。それは結果的にお客さん、僕、ユーザ、社会の誰も得をしない。いいものを作るためにはそのレイヤーに自分がどこにいるのかきちんと把握して、それを場面場面でうまく上下することがいいものを作る秘訣だなあと感じたのですね。

というわけで以上です。次はDaisuke Miyataさんですね!記事公開が遅くなってすみません・・

よくある視点ですけどね

ちょっと注記しとくと、別にこれがUXデザイン独自の考えだって言ってるわけではないです。目的と手段の峻別とかよく言いますし、「鳥の目・虫の目」とか「消費者はドリルではなく、穴を欲しがっている」みたいな言葉もだいたい同じことを言っていると思います。まあ、ただUXデザインはそういうことを考えるフレームワークはいろいろ用意されていて便利かもしれませんね。

関連ページ

]]>
http://www.openvista.jp/archives/note/2013/layered-thinking-of-ux-design/feed/ 0
Sassのサーバサイド自動コンパイラ http://www.openvista.jp/archives/note/2013/scss-server-side-compiler/ http://www.openvista.jp/archives/note/2013/scss-server-side-compiler/#comments Wed, 04 Dec 2013 17:13:47 +0000 http://www.openvista.jp/archives/note/?p=1408 今日から使える! Sass/compass ゆるめ勉強会

最近、このスライドを見てからSassをちょっとずつ使い始めているのですが、悩みどころなのがSassのコンパイル。もちろん、ある程度ツールを使うことで自動化はできるものの、うちにはWindows1台とMac2台があり、各環境ごとに用意しなければならないのがちょっと煩わしいなと感じます。

便利になるとはいっても、逆にそれで管理コストが増えるのはちょっと面倒。そもそも、CSSの延長線上にあるものなのであれば、あんまり変換とかコンパイルとか考えたくないですよね。サーバ側に配置したら、自動で勝手に透過的にコンパイルして表示されるくらいがいいですね。

幸運にも、サーバサイドでSassファイルをCSSに動的にコンパイルするライブラリはいくつかあったので、ラッパーを作ってみました。要するに、./hoge.scssとURIを指定して呼んでやれば、勝手にコンパイルをやってくれるというものです。

コードはGithub上にアップしてるので自由にどうぞ。ちなみにコンパイル以外にも記述最小化処理もやってます。続くTodoはCompass対応とファイル結合対応あたりかな。

hashcc/SCSS-server-side-compiler

Sass界隈はまだ不案内ですので、たぶん同じことしてる人が、世界に万単位でいそうな気もしますが・・


少し仕様を変更するよう更新しました。

今まで
./hoge.scssでURIを呼べば勝手に圧縮とコンパイルを行う
これから
./hoge.scssでURIを呼んでも何もしない。クエリで”min”や”compile”と指定することで圧縮、コンパイルを行う(./hoge.scss?min,compile)

]]>
http://www.openvista.jp/archives/note/2013/scss-server-side-compiler/feed/ 0
iPhoneの指紋認証機能が変えるウェブの利用シーン http://www.openvista.jp/archives/note/2013/impact-of-fingerprint-auth/ http://www.openvista.jp/archives/note/2013/impact-of-fingerprint-auth/#comments Tue, 10 Sep 2013 17:00:59 +0000 http://www.openvista.jp/archives/note/?p=1403 まもなく発表されるとか言う次期iPhoneに指紋認証が搭載されるという噂があるそうです。まあ、占いみたいなもので当たるかどうかはわかりませんが、個人的にはこの機能は昔から心待ちにしていた機能ではあります。

なぜかというと、それは単純に低コストの認証である以上に、認証が必要な行動が簡単に行えるようになることでウェブに結構影響を与えるのではないかなと思うからです(そういえばn-clickを1-clickにすると商売になる。1-clickを0-clickにすると革命になるという言葉がありますね)

で、じゃあどんなことになるのかなというところを、iPhoneが発表されるまでの束の間に妄想してみたのでメモっておきます。

  • 指紋認証機能を搭載した新iPhoneが発売
  • iOS7のパスワード管理システムiCloud Keychainサービスは指紋認証に対応。保存したパスワードを指紋認証で簡単に呼び出せるように。
  • これとは別に、Apple IDにユーザの住所、氏名、メールアドレスや、Google, Facebook, Twitterなどのアカウント情報を紐付けられるようになるような変更が加えられる。また、Apple IDがoAuthに対応し、こうした情報をサイト側に提供できるようになった。
  • 一見、認証とは関係無いようだが、これは指紋認証を介してこうしたアカウント情報や個人情報を、ID/PWを逐一入力する必要なく、低コストでサイト側に提供できるようになったということ
    • 多くのサービスでApple IDでの認証が可能になることで、各サイト独自の会員登録する必要がほぼなくなった。
    • ショッピングサイトは送付先や決済手段の入力が不要になり、短いステップで購入ができるようになった
    • 認証が簡単になることで、一部のブログやニュース記事は、コメントをApple IDと紐付けて投稿することを求めるようになった
    • Appleアカウント経由での決済が簡単にできるようになり、コンテンツ流通が活発になる。投稿した動画や記事に寄せられる読者からの寄付で生計を立てる者が現れてくる。一方で決済のハードルが低すぎることが問題となりペアレンタルコントロールの一種として、月額使用上限を制限する機能がOSに組み込まれていった

認証はいわば情報流通の関所みたいなもので、その認証コストが情報流通の速度に結構影響しているのではと思うのです。Appleは決済手段+デバイスと結びついたID(Apple ID)を大量に持っている訳で、お金は動かせるし、IDを紐付けられるデバイスは大量に出回っている状況なので、ここで認証のハードルを下げればお金や情報が流通しやすくなって、面白い展開になるんじゃないでしょうか。

]]>
http://www.openvista.jp/archives/note/2013/impact-of-fingerprint-auth/feed/ 0
5分でわかるユーザビリティに配慮したデザインとユーザエクスペリエンスデザインの違い http://www.openvista.jp/archives/note/2013/usability-and-ux/ http://www.openvista.jp/archives/note/2013/usability-and-ux/#comments Sun, 30 Jun 2013 13:00:08 +0000 http://www.openvista.jp/archives/note/?p=1388 仕事ではウェブサイトやアプリのUX改善に携わっているのですが、先日、友達(ユーザビリティ/UXデザインの専門家ではない)に自分の仕事について聞かれてちょろっと答えたことがありました。ただ、いまいち腑に落ちなかったようで「結局、そのユーザビリティを良くすることとユーザエクスペリエンスを良くすることの違いってなんなん?」と聞かれてしまいました。

僕も数年前は同じ質問をしていたと思うのですが、最近こうかなあと思って話したことを(あんまり文書にしたこともなかったので)備忘録として残しておきます(大阪出身なので関西弁です)。ちなみに話し言葉なので厳密さは犠牲にしてます。


調整さんの画面

そやなー、例えばさ同じ会社の誰かが退職したとするやん?で、送別会やるやんね。そうすると、行きたいって人のメンバーの予定を調整するのに調整さんとか使うやろ?

ユーザビリティ、つまり使い勝手って言うのはこの調整さんが使いやすいかどうか。つまり参加者にとっては、どこで出欠登録ができるかすぐにわかるとか、◯✕つけるのがすぐにできるとか。あるいは出欠取る人にとっては日程候補がカレンダーから選べて土日がわかりやすいとか、皆に入力してもらった後に○付いているところがハイライトされてて、どこで調整付けられそうかひと目で分かる、とかそんな感じ。

つまり、ここで言うユーザビリティってのは調整さんって言うツール自体の使いやすさやね。

で、一方でユーザエクスペリエンスデザイン、つまりユーザの体験に基づいたデザインってので考えると、まず会社の人の送別会なわけやから、そのお知らせは会社のメールとか来るわけやんね(まあ、Facebookメッセージで来るってのもあるやろけど置いといて)

そうすると、社内予定の調整とか登録とかはサイボウズとかのグループウェアでやってるわけやから、わざわざ調整さんってツール使わんでもええっていうか、むしろグループウェアで調整とか、あるいはFacebookみたいにイベント建てられたほうが効率的かもしれんよね?あと、調整がついた時間をお店側の予約システムに伝えて予約可能かどうかすぐにわかるともっといいかもしれんね。

じゃあ、送別会の予定を調整するっていう任務があった際に、それを今よりもっと良く完了できるようにするには?って考えた時に、調整さんが使いやすくなったら良い、ってのも一つの策なんやけど、例えばそういう風にいつも使ってるツールではどうかってことで、その人の行動から考えたほうがいいよねってこともある。

それが言うなれば、ユーザ体験に基づいたデザインってことになるんやと思ってる。つまり、ここで言うユーザエクスペリエンスデザインってのは送別会行く人の行動とかを考えた上で、一つのツールに限定せず、最適解はなんやろねって考えることやね。

送別会もそやねんけどさ、だいたい一つのツールとかで物事が終わることってないやろ?もちろん、そういうのがあればいいんだろうけど、大抵なかったりあってもすごい複雑でわかりづらかったりするから、いろんなツールを適材適所でいっぱい使ったり、あるいは本来そういう目的じゃないツールも工夫して使いながらうまくいくようにしたりとか。ちょっと前にユーザビリティからユーザエクスペリエンスデザインへみたいな事が言われたけど、それはそういう場合に一つのツールだけ改善しても意味ないんやないのってのを含んでるんやと思う。もう少し広い視点で俯瞰した後に、じゃあ、この人の行動を助けるんやったらここをやるのが一番いいよねって、そうした方が一番いい効果が得られると思うやろ?(まぁ、ビジネス的にはそんなストレートにはいかんかもしれんけどさ)

で、サービス開発者の視点で見てみると、じゃあどこにリソースを投資しましょうっていう資源配分とか、場合によってはサイボウズと業務提携しましょうとかって話にも関わってくるんで、経営の視点でのサービス改善に近づいてくるんかもしれんね。そうすると、経営者と離れてユーザエクスペリエンスデザインをしようってのは難しいことがあるかもしれんね。


とまあ、こんな感じの理解です。

ユーザエクスペリエンスデザインって言ってますが、例えば僕が調整さん作ってる人だったとして、サイボウズ使う人は厳密には調整さんのユーザーではないので、ユーザエクスペリエンスデザインってか単にエクスペリエンスデザインと言ったほうがいいかもしれません。

ちなみに、話に出した送別会の幹事のユーザ体験は一連の行動を図にまとめたことがあります(見にくいと思うんで、気になる人はSlideshareのサイトでダウンロードして下さい)

上記の説明だと、買う前に興味を持ってもらって手にとって買ってもらうまでの話(予期的UXと呼ばれるもの)や使い慣れてからの印象や使い方、興味関心、使う意欲の変化の話(累積的UXと呼ばれるもの)など、長期的UXの視点をごっそり落としているのですが、話を単純化するためにそうしてます。

]]>
http://www.openvista.jp/archives/note/2013/usability-and-ux/feed/ 0
良いユーザ体験を目指すためにはアクセシビリティが大事だという話 http://www.openvista.jp/archives/note/2013/accessibility-for-good-ux/ http://www.openvista.jp/archives/note/2013/accessibility-for-good-ux/#comments Sun, 10 Mar 2013 19:33:27 +0000 http://www.openvista.jp/archives/note/?p=1355 ユーザ中心デザインとか、ユーザ体験デザインとかの勉強をしてかれこれ3年くらいになるんですが、そのためには情報のアクセシビリティが良くなることが特に大切だと最近は思ってるんですね。

で、今日はその理由とか、じゃあどうアクションするよ、みたいなところを書いてみます。

Google glassとアクセシビリティ

まずは、「アクセシビリティとユーザ体験ってどう関係あるのよ??」と思った人向けに小話をひとつ。

少し前にGoogleのメガネ型情報機器 Google Glass(以下、Glass)のデモ動画が公開されて、話題になりましたね。面白い動画なので未見の人は一度見てみてください。

動画の中で気になったところを見ていきましょう。

カーナビゲーション
車移動でのナビゲーション。どの通りを曲がればいいのか、その通りは何m先か、あと何分くらいで着くかなどを教えてくれています(地図情報や目的地の位置情報が必要そうです)

空港でのナビゲーション2
搭乗する予定の飛行機があとちょっとで出ちゃうってことで空港内をダッシュ。あらかじめインプットされていた出発時間や搭乗区間などが表示されています(チケットの情報が必要そうです)

空港でのナビゲーション1
ついでに詳細ってことで、ゲートの場所まで教えてくれます(結構、詳細なチケットの情報が必要そうです)

氷の像を彫る
彫刻師の方が氷から虎を掘っているみたいです。「虎の画像を見せてくれ」との求めに応じて、いろんな角度の虎の画像を探してきます(虎の画像と画像ごとの角度情報が必要そうです)

クラゲをWikipediaで調べる
水族館を散策中。クラゲで検索してくれと言われてWikipediaの解説を提示(Wikipediaの情報、その要旨が必要そうです)

素朴な感想ですが、Google Glassがもたらすユーザ体験は素晴らしいと思います。今までできなかったこと・やらなかったことをできるようにするという意味で、人間の知性を拡大する道具だと。

しかし、これを実現するには一方で、高度な技術と、必要な情報へアクセスできること(アクセシビリティ)が前提として必要になるでしょう。

技術はさておき、アクセシビリティについて考えると、地図情報にアクセスできなければ、Wikipediaの要約にアクセスできなければ、こういう体験は設計できなかったわけです。ですから、アクセス可能な情報が少ないということは、それだけ良いユーザ体験を実現するための制約が大きいということです。ユーザ体験デザインでいくら達成したい体験を明確にしたとしても、そうした制約が大きければ、結果として達成可能なデザインの幅は大きく狭まってしまうわけです。

これが、私がアクセシビリティを重要だと考える理由です。

もちろん、良いユーザ体験が必ずアクセシビリティを必要とするわけではないです。美味しい料理を出して、サービスも抜群のお店とアクセシビリティはあんまり関係なかったりしますね。可能性としての制約があります、という話です。

アクセシビリティって?

アクセシビリティというと、とかく高齢者・障害者にフォーカスされた話と受け取られがりですが、こういう例を出すとそうでないことはおわかりいただけてるかと(具体的施策としてそうした特定層が意識されることはよくありますが)。では、アクセシビリティの定義は何かと言いますと「様々な人が様々な利用環境(利用状況/媒体/方法)で、製品やサービスを問題なく利用できるレベル」と考えています。

要素毎に少し例を挙げてみましょう。

様々な人が利用する
小さな子供が、元気な高校生が、体力が落ちてきたおじいちゃんが、目が見えない方が…
様々な利用状況で利用する
静かで音が出しにくい場所で、うるさくて音が聞こえにくい場所で、急いでいて時間がない時に、傘を指してて片手が使えない中で、真っ暗で周りがよく見えない中で、寒くて手を出したくない時に、料理中で手が汚い時に…
様々な利用媒体で利用する
PCサイトから、スマートフォンアプリから、タブレットアプリから、テレビから、ウェブページを印刷した紙から、プロジェクタで映した画面から…
こう書くと、一見誰でも使えるようにするユニバーサルデザインと似てると思われるかもしれません。

ただ、目指す地点は同じでも取っているアプローチは両者で違うのだろうなと思っています。ユニバーサルデザインが単一の製品・サービスで様々な人・環境への適応を目指すのに対して、アクセシビリティを高める場合はいろんな選択肢を提供することで結果として多くの環境で利用できるようにすることを目指すというアプローチの違いがあると思います。

参考:UX,IA,UD,アクセシビリティの話(とくにUDとアクセシビリティの違い) – Togetter

アクセシビリティ向上への市場競争的アプローチ

じゃあ、アクセシビリティをどう確保するの?という話なんですが、その前に下敷きとして紹介したい話があります。

アクセシビリティを倫理的に語ることと制度設計について – Zerobase Journal

面白い話なので是非一読いただきたいですが、まとめておきますと、

  • アクセシビリティの向上を常に善とするのはとても乱暴。各事業者の活動は自由であるべきで、アクセシブルにしない自由がある
  • 公と民間は分けて考えたほうが良い。公でのアクセシビリティは民主主義的に確保されるべきだが、民間はそうではない。どうやって民間の取り組みを喚起するかがポイント
  • 民間事業者が「アクセシビリティが大事だ」と思わなくても、市場競争の結果として自然とアクセシビリティが高まる(高めることがビジネスにつながる、儲かる)ようなルール・言説を考えてみるのがよい

というところでしょうか。

なぜ面白いと思ったかというと、アクセシビリティの取り組みって、従来はその向上を規範(啓蒙)や法(R-508障害者差別禁止法)からアプローチするやり方が多かったと思うんですね。つまり、公的セクターに限定される話が多かった。

民間ではそれは難しいだろうなあと思っていたところに、(より相性のいい)市場競争からのアプローチを提言したところが面白いなと思います。これは勝手な推測ですが、Web標準も「それが正しい」「アクセシビリティが高まる」から普及したのではなく、「内容と表現を分離することで作業時間の短縮につながる、あるいはより高度な表現が可能になる」「SEO、つまり検索エンジンに拾われやすくなる」という市場競争の意味合いから普及したのではないかと思っています。

と考える一方で、そう言い切れない部分もあると思うんです。というのは、アクセシビリティはコンテンツの可能性というか未来に向いた話なんですね。Google Glassが出てくる前は、誰もお店の情報をメガネから見るなんて思っていなかった。だけど、市場競争の枠組みで考えるとどうしても近視眼的=現在かそのちょっと先になりがち、つまり可能性を限定しがち、なんです。そこはしょうがないと割り切る話なのかもしれませんが…

アクション

じゃあ、どうするかについては、大きく以下の2本立てで考えています。ちょっと長くなったので別記事に分けて考えてみます。

  • 提供する機能や情報にアクセスしやすいようにしておく
    • コンテンツをアクセシブルにするためのルールを(ある程度)守る
    • 情報や機能にアクセスするAPIを一般公開する
  • ユーザの主観的体験からアクセシビリティを評価する

この記事の続きは今書いているところです。(できれば)3/12までに続きを公開する予定です

]]>
http://www.openvista.jp/archives/note/2013/accessibility-for-good-ux/feed/ 0
記事を読んでもらうために要約をつけよう http://www.openvista.jp/archives/note/2013/value-of-summary/ http://www.openvista.jp/archives/note/2013/value-of-summary/#comments Sun, 27 Jan 2013 12:55:27 +0000 http://www.openvista.jp/archives/note/?p=1324 ウェブ上のデザインパターンとして、あるページ(URL)に対して何か言及するというものがよく見られます。そこでは、おそらく読者が内容を推測しやすいように(読むべきかどうかを判断しやすくする)という配慮からか、ページ内容の”抜粋”を入れています。

しかし、この抜粋って内容をある程度つかむためにどこまで有用なのでしょうか。ちょっと例を挙げながら見て行きましょう。

抜粋表示の一例

facebookの例。冒頭の数百時が使われています。タイトルにある3つの設計思想が書かれていればよりわかりやすかったですね。
facebookの言及先URLを示した画面

このパターンの祖はおそらく検索エンジンでしょう。ただ、説明文からはタイトル以上のことはあまり読み取れません。
Googleの言及先URLを示した画面

はてなブックマークは内容冒頭の数百字を抜粋しているようです。新聞社など、先頭に記事の要約を持ってきている例は別として、そうでない場合は内容の把握には向かない印象です。
はてなブックマークの言及先URLを示した画面

ソーシャル・メディア上のニュースからユーザに合ったものを知らせてくれるGunosy。これもはてなブックマークと同じような見せ方ですね。タイトル以上の情報量がないケースが多いです。
Gunosyの言及先URLを示した画面

Gunosyと似たサービスで人気のあるiPhone向けNewsStormアプリ。結果は上と同じく。
NewsStormの言及先URLを示した画面

twitterは各ツイートを展開した時にURLの詳細が表示されます。ここには”抜粋”は表示されず、要約されたものが出てきます。内容もわかりやすいことが多いですね。
twitterの言及先URLを示した画面(Twitter cardでの詳細表示)

これはHTML上に適切に要約が書かれている時だけ表示するようだからで、書かれていない場合は抜粋表示すらしないようです。
twitterでの詳細表示

抜粋を要約にした例

では、実際にこれを要約にしてみるとどうでしょう。

facebookの例。
Facebook改善後の画面

Googleの例。
Google改善後の画面

Gunosyの例。
Gunosy改善後の画面

どうでしょう。少しはページの中身がわかりやすくなった気がしませんか?

コンテンツを理解してもらうためには、ページタイトルも重要ですが、それだけでは内容の一部しか示せません。タイトルは面白そうだけど内容まで読むのは面倒だし、と諦めてスルーしてしまう人もいるでしょう(機会損失)。

要約は内容を示すことで、そうした人の背中を押す効果があるのではと思います。

読むモチベーションの変化を示した図1(要約によるモチベーションの向上)

もちろん、逆に求めているものと違ったと思ってスルーしてしまう人もいるでしょう。ただ、これをPVが減るという目先の考えで捉えるのは筋が良くない、なぜならそうやって訪問する人はがっくりしてサイトを離れるでしょうから、あまりコンバージョン(コメント、SNSへの共有、広告のクリック)は期待できないからです。

読むモチベーションの変化を示した図1(要約によるモチベーションの低下)

要するに、「情報の匂い」を強くすることで、ユーザが自分にあった情報かどうか嗅ぎ分けやすくしようということです。要約を書くことで、届けたい人に届ける、つまり実質的なアクセシビリティを高めていくことにもなるかなと思います。

要約で理解を深めてもらう

要約が必要なのは、記事への流入を増やすという意味だけではありません。末尾に要約を加える事で、要点を再確認してもらい、記事への理解を深めてもらうことができるでしょう。

はてなブックマークやTwitterでは、コメントに本文の特徴的な部分を抜粋してコメントするなどの行動が見られますが、それも記事に何らかの理解の落としどころをつけようという意識の現れではないでしょうか。

長文を書く場合には、そうしたところをサポートするとよいのでは、と思います。

じゃあ、どうするか

まず、上記各社がどうやって要約を見つけているか、なのですが

ということで、各社バラバラです。ムキーとなりますが、結果を言えば、以下のコードをhead要素内に書けばオッケーです(もちろん、記事冒頭やRSSにも要約を入れておきましょう)

HTMLソースコード
<meta name="description" content="要約内容をここに" />
<meta name="twitter:card" content="要約内容をここに" />
<meta property="og:description" content="要約内容をここに" />

うちのサイト、実は書いてなかったので追加しました^^; 対応していないところについては、現状は難しいですが、こういった環境を広めて認知を拡大していくしかないのかなと思います。

ウェブサービスとしてもこういう要約を(なるべく負担に感じさせないように)ユーザに入力してもらう仕組みが必要だと思います。NAVERまとめはそのあたりきっちりやってますね(タイトル下の説明文がようやく)

要約で広がる活用の幅

要約を付け加えることで、情報自体の活用の幅も広がるだろうと思っています。

ポップアップでリンク先を示した例

例えば、今までタイトルだけでしか示せなかった情報が、例えばリッチなポップアップのような形で示すことができます。それによって、リンク先を確認しないと内容が十分にわかりづらかった(受け手にとっての情報量がゼロサム的)ものも、40-50%くらいの意味を伝えることができるかもしれません。

ホームページと呼ばれる大きなパッケージングされた世界へ訪れる時代から、RSS / RDF のような形式を介してコンテンツだけ抜き取って読む時代になりました。そして今は、ソーシャルという要素が加わり、様々な形式のコンテンツが小さく抜きとられた形で行き来するようになりました。

ブログのような数百文字のものから、Twitter のような百数十文字、Facebook のような「イイネ」で終わる世界へと、コンテンツの単位が次第に小さくなってきています。

小さいということは Web において幾つかメリットがあります。

  • どこにでも配信される
  • いつでも見れる
  • 組み合わせがしやすい
  • 求めている部分だけ手に入りやすくなる

小さくなる配信パッケージと思考・設計の変化 – Could

“要約”という扱いやすいサイズの情報を一緒に提供することで、情報自体のパッケージによらず、様々な場所でその情報の活用ができるようになるのではと思います。

ウェブは個々のページの集積体として成立しており、それらはリンクしあって成立しています。で、あればそれら1つ1つのページをより豊かに示せることがウェブ自体の活用につながるのだろうなと。

そういう意味でタイトルの「記事を読んでもらうために」は、個々の記事として流入増加もありますけど、サイト全体、ウェブ全体の価値を高めて、流入増加を考える視点も必要かなと思います。

]]>
http://www.openvista.jp/archives/note/2013/value-of-summary/feed/ 0