Tagged

IA

A collection of 19 posts

IA

UIの意味付けに情報アーキテクチャは強い味方

Atomic Designは数ある分類方法のひとつ Atomic Design [http://atomicdesign.bradfrost.com] のように UI の『粒度』で分類することがあります。ボタンやフォーム要素のような小さな『分子』。大小様々な要素で構成された『ページ』と呼ばれる大きな集合体。UI を積み木構造のように考えやすくなりますが、Atomic Design 特有の思想であって、特定のアプリケーションの UI に適した分類ではない場合があります。 汎用性をもたせるために、Atoms、Molecules、Organisms、Templates、Pages の 5 段階が作られていますが、web サイトやアプリケーションによっては段階が多すぎます。無理に当てはめようとするあまり、Molecules かOrganisms かを議論するということにもなりかねません。 よくある話でボタンの分類があります。ボタンは Atom と呼べますが、アイコン付きボタンはどうでしょう。 2 つの Atom によって構成されているので
IA

情報アーキテクチャの脊髄を視覚化

2月9日に東京で開催された World IA Day 2013 [http://2013.worldiaday.org/locations/tokyo-japan] に参加してきました。前回の記事 [http://www.yasuhisa.com/could/article/btwn-big-ia-and-small-ia/] で書いた今後の IA の課題のヒントになるようなメッセージを、イベントを通して幾つか見つけることができました。 今回は吸収した内容を自分なりにインフォグラフィックにしてみました。 [http://www.flickr.com/photos/yhassy/8467245165/] イベントを通して『情報』にはデータベースに蓄積できるようなものと、掴み所がないものと二種類あると考えました。言い換えれば右脳的な情報と左脳的な情報があるといったところでしょうか。まったく違う存在のようにみえる二種類ではありますが、4つの段階を踏んでアーキテクチャ（構造）を作り出しているようにみえました。 1. Deconstruct （分解） 2. Sort（分類） 3.
IA

Big IA と Small IA の間で

Big になり過ぎている IA Big IA 広義としての IA 。映画監督やオーケストラの指揮者のような存在で、製品やサービスのビジョンを形にする役割。 Small IA 狭義としてのIA。プロジェクトに関わる人々が理解できるようにビジョンの詳細を設計し、具体化していく役割。 Peter Morville 氏が 2000年に寄稿した記事 [http://argus-acia.com/strange_connections/strange004.html] で、Big IA と Small IA に明確なラインを引かず、情報システムの構造化という IA の核心を軸にしてコラボレーションをすれば良いと説いています。実際、多くの IA プロフェッショナルは Big / Small といった分類を過剰に意識することなく、いずれの設計に携わることもありますし、UXデザイナーと呼ばれる方とコラボレーションをしている場合もあります。 こうした現状を理解しているわけですが、IA で語られる話題が Big （ビジョンの設計）に偏り過ぎていないかと感じることがあります。
IA

パン屑リストについてもう一度考えてみる

様々なパン屑リスト 利用者が辿ってきた道筋を示し、いつでも先に戻れるような配慮としてパン屑リスト [http://ja.wikipedia.org/wiki/%E3%83%91%E3%83%B3%E3%81%8F%E3%81%9A%E3%83%AA%E3%82%B9%E3%83%88] があります。IA の専門家 Keith Instone [http://instone.org/] によると、パン屑リストには以下のタイプがあると言われています。 場所の示すWebサイトをツリー状として捉えたときの利用者の現在地を表示する経路を示す利用者が現在地まで辿り着いた道筋を表示する属性を示す 断面的な検索をして絞り込む際、選択済みの属性を表示する進行状況を示すアプリケーションの利用の際、タスクの進行状況を表示する それぞれのパン屑リストには特有の機能があり役割を果たして来たわけですが、本当に必要かどうかを再考するべきタイプもあります。例えば経路を示すパン屑の場合、ブラウザで既に実装している「戻る / 履歴」と重複しています。
IA

1991年の資料から学ぶ情報デザインチェックリスト

Web デザインをきっかけに知ることになった方も多いと思いますが、IA (Information Architecture) の歴史は長く 30,40 年ほど遡ることが出来ます。IA と明確に書かれていない書籍でも IA に関わる資料が昔からたくさんあるわけですが、当時はどのようなことが書かれていたのでしょうか。今と変わらないもの、そして今とは違う事柄はあるのでしょうか。Volkside の「17 guidelines for better information architecture…from 1991 [http://www.volkside.com/2010/03/15-guidelines-for-better-information-architecture-from-1991/] 」という記事で Kent L. Norman が執筆した「The Psychology of Menu Selection: Designing Cognitive Control at the Human/Computer
IA

様々な意味をもつWebサイトのスピード

「UXの測定要素 [http://www.yasuhisa.com/could/article/ux-metrics/] 」で最初にスピードを挙げたのは、Webの体験において近年重要なポジションになってきているからです。ブロードバンドだからこそスピードを要求されますし、モバイルだと欲求はさらに高まるでしょう。プログラムがより早く動作するように記述の工夫や構成の検討したり、CSS や HTML といったマークアップからでもパフォーマンスを上げることが出来ます。こうした技術的なアプローチだけではなく、情報の整理の仕方や心理的な部分からスピードを表現することが可能です。 例えば、トップページのように様々な導線も含まれた情報量の多いページがあるとします。技術的な工夫を施し、表示速度が早いページにしたとしても、情報が入り組んでいて利用者が見つけ難い構成であれば「時間がかかる＝遅い」と感じるでしょう。「２つ以上の製品を比較したい」「製品の特徴を把握したい」という利用者に明確な目的がある場合はどうでしょうか。一見、きれいに情報が整理されているページだったとしても目的を達成するために複数のページを横
IA

関係作りとしての IA の役割

IA (Information Architecture) において「関係」は重要なキーワードです。ページを構成する情報と情報との関係、サイト内のページとページとの関係。コーポレイトサイトであれば、メインサイトとサテライトサイトというサイトとサイトの関係も考慮します。これに加え、利用者という別の軸の関係も考慮して情報を組み立てて行きます。こうしたことから、IA の専門家達は、建築、情報科学、インダストリアルデザイン、認知学など様々な分野の知識に長けている方が少なくありません。彼等はその広い知識を活用することで様々な情報と コンテキスト [http://www.yasuhisa.com/could/diary/css-nite-lp7/] を繋ぎ合わせている（関係を作り上げている）といえるでしょう。 近年、情報とコンテキストが多様化し初めています。 情報の種類はテキストから動画まで様々ですし、サイズや扱われ方もたくさん出てきました。また、利用者が情報にアクセスする背景を考えてみると、自社の Web サイトという小さな存在だけでは語り尽くせない状態です。Web がパソコンからの情報だけの
IA

探索的検索という違う時間の流れ

検索とひとことで言ってもいろいろな形があります。私たちが Google などでキーワード検索するときは、答えを導き出すためのキーワードが分かっている場合がありますが、いつもゴールへの辿り着き方が分かるとは限りません。ゴールが何か明確でない場合もありますし、辿り着くためにまずは関連情報を学ぶ必要があるかもしれません。閲覧 (Browse) と検索 (Search) が合わさったような利用者の行動を Exploratory Search (探索的検索) と呼んでおり、ここ数年様々な研究・調査がされています。概要が知りたい方は Wikipedia の記事 [http://en.wikipedia.org/wiki/Exploratory_search]が参考になります。 今すぐ欲しい情報を探すのであればキーワード検索でも十分ですが、調査、仕事のプロジェクト、ライフプランなど中・長期に渡って探し続ける情報をいかに補助するかが課題です。今でもブックマークを使ったりメモソフトを組み合わせることで管理が出来ているものの、別の解も考えられます。探索的検索を理解することが出来れば、キーワードから導き
IA

CSS Nite LP7 で IA に関する講演をしました

撮影: 飯田昌之 [http://www.masazo.net/]2009年9月12日ベルサール神田にて CSS Nite LP, Disk 7「IAスペシャル」 [http://lp7.cssnite.jp/] が開催されてました。IA を語るならこの人と呼ばれる方々から様々な視点の IA を聞くことが出来ました。6時間という長丁場で、しかも相当量の情報があったと思うので消化するのは少し時間がかかるかと思いますが、既に たくさんの方 [http://cssnite.jp/archives/post_1619.html] が、レポート＆感想を書いています。 私はイベントの一番最後に「IAからWebサイトデザインへの突破口 」という題名でプレゼンを行いしました。長丁場の終盤だったので来場者の多くは疲れていたと思います。そんな中で漠然とした内容のプレゼンを聞いても頭にピンと来なかった方も多かったのではないかと心配していますし、伝える力が足りなかったのではないかと反省しています。幸い Twitter 上では [http://twitter.com/#search?q=
IA

効果的なプロトタイプを早く作るコツ

プロトタイプを作るのは重要ですが、作るためにおおくの時間を割きたくないところ。特に作ったあとも何回か調整をするわけですから、あまり作り込むわけにはいきません。しかし、あまりに単純な見た目だと情報共有が難しくなります。自分が使い慣れているツールを使うのは第一歩ですが、ちょっとしたことを気をつけることで、効果的なプロトタイプを早く作れるようになります。 スゴいコツだ！というのはありませんが、心がけてるだけでも少しばかり早く作れるようになりますよ。 使えるパレットを用意するよく使う UI 要素やコメントを付けるためのパーツはパレットにしておくと効率的。以前紹介した、OmniGraffle用 [http://www.yasuhisa.com/could/roundup/graffletopia/]とPowerPoint用 [http://www.yasuhisa.com/could/article/powerpoint-prototyping/]を利用すると手軽です。 テンプレートを用意するOmniGraffle では、通常のファイルを新規作成が出来るだけでなく、テンプレートを作成すること
IA

各プロトタイピングの長所・短所

ウェブサイト制作でもプロトタイプを作成する機会が増えてきたと思います。しかし、プロトタイプ一言でいっても様々な方法で作ることが出来ます。今まで 様々な種類のプロトタイピング [http://www.yasuhisa.com/could/?s=%E3%83%97%E3%83%AD%E3%83%88%E3%82%BF%E3%82%A4%E3%83%97] を紹介したことがありますが、どの方法を使った方が良いか迷うところです。短時間で作れるかどうかだけでなく、誰と共有するのか、変更がしやすいか、完成品とどれくらい近づけるのかなど考慮したい項目は幾つかあります。Adobe Dev Center の「Industry trends in prototyping [http://www.adobe.com/devnet/fireworks/articles/
IA

Powersetが提案する情報の見せ方

一部ではGoogleキラーと呼ばれている [http://www.abcnews.go.com/Technology/PCWorld/story?id=4833769]次世代検索エンジンPowerset [http://www.powerset.com/] 。キーワードだけでなく自然な文章でも検索出来るというところまでは他のサービスも行っていますが、検索結果の見せ方や情報の見せ方に幾つかの工夫がなされています。今のところ Wikipedia の記事 (英語のみ) を検索出来るだけですが、なかなかおもしろいです。個人的に「キラー」と呼ぶのは大袈裟だと思いますが、 Powerset では独自の情報の見せ方を提案しており、UIデザインや情報整理の観点からみると大変興味深いサービスです。今回は Powerset で見つけた興味深いアプローチを幾つか紹介していきます。 A. 概要 検索するとページの一番上に最も該当する項目が表示されます。通常のリスト表示ではなく写真付きで記事をある程度読むことが出来るようになっています。Googleでもこうした見せ方は一部のキーワードで行っていますが、Powe
IA

リンクタイプの構成案

可能な限りフィードバックを得れるような状態にしながら、徐々に方向性を固めて組み立てれるように複数のサイクルで構成されたプロセス [http://www.yasuhisa.com/could/article/multiple-cycle-process/] を提案しました。今回はその第一弾である「リンク」タイプのデザインに取りかかろうと思います。リンクは「クラフトっぽいアート作品いろいろ [http://www.yasuhisa.com/could/links/craft-art/] 」のようにゆるいテーマがあるかもしれないですが、リンクが羅列しているようなエントリーのことを指します。 このタイプのエントリーはあまりブックマークもされることもなく、どちらかというと検索からくる方のほうが多いです。サイトへのロイアリティもあまり高くないので、最近のエントリーやタグリストなどといった全体像が分かるものを省いて、読者が必要しているものをはっきり見せることが必要とされるタイプになります。リンクタイプはイントロダクションのような文章もない単純なリスト（ <dl> で記述）なので、文体も統一されてい
IA

サイドバーの行方

サイドバーはブログが広まる前から存在していたコンポーネント。メインコンテンツ以外の情報を上部に載せることが出来るので、多くのサイトでサイドバーが採用されています。実装も簡単に出来ますし、３カラム、４カラムと増やすことも出来るわけですが、実装の敷居も低いのでただの賑やかしになってしまいがちの部分でもあります。情報の配置の仕方によって、情報が活かされるときもあれば、そうでないときもあります。サイドバーもメインコンテンツ以外の情報を放り込む場所ではなく、的確な情報が載る場所として扱わなくてはいけません。 ブログのサイドバーで必要なもの サイドバーによくある情報は * 最近のエントリーリスト * 最近のコメントリスト * アーカイブリスト * カテゴリリスト * タグクラウド * Feed をはじめとした購読ボタン * ウィジェット諸々 アクセス解析やサイトコンセプトによってサイドバーの使い方も変わってきます。このサイトは Feed は多くの方に登録されていますが、サイトまで訪れる方はその中のわずかな数ですし、エントリーによってアクセス数も数倍違うこともあります。よって、情
IA

今時のプロトタイピング

この記事は「PowerPoint を使ったプロトタイピング [http://www.yasuhisa.com/could/article/powerpoint-prototyping/]」の続きにあたります。 ページベースの Webサイトを制作するのであれば、多くの方が利用出来るということも含めて PowerPoint [http://office.microsoft.com/ja-jp/powerpoint/default.aspx] や Keynote [http://www.apple.com/jp/iwork/keynote/] といったプレゼンテーションアプリが最適だといえます。しかし、Ajax や Flash を利用したページを移動することなくデータにアクセスするサイトや Webアプリケーション、ショッピングサイトのような会員/非会員によって異なるコンテンツやフォームを必要とするサービスでは、ページベースで Webサイトを考えるのは困難です。 ユーザーテストをする際も PowerPoint や Keynote では難しい場合もあるでしょう。共に高度な描写が可能になり見た目
IA

拡張性のあるデータ配置を模索する

そろそろ大まかな形でワイヤーフレームを作っていこうと思っているわけですが、その前にいろいろ準備しておきたいことも幾つかあります。そのひとつが、拡張性を考えて、どのようなデータをどの辺りに配置するのがベストかを考えること。これは Webアプリケーション開発において特に重要になってくることだと思いますが、大幅な改変をしなくても、機能やミニコンテンツといったコンポーネントを付け加えることが出来るように設計しておく必要があります。もちろん、すべての可能性を考慮することは不可能ですが、あらかじめ拡張されることを考慮して設計を始めるか始めないかでは大きな違いがあります。 下の図はページを大まかに4つに別けて、異なる配置を考えたものです。 ※ ワイヤーフレームの基盤のような存在なので、実際のサイトのワイヤーフレームを作っているわけではありません。 ナビゲーションサイトのグローバルナビゲーションに当たるエリア。Webアプリケーションにおいては機能を示すことが多いコンテキスト / データセット 現在観覧しているページがどういったページが示していたり、サイト全体からみたページの位置を示しているエリア。
IA

タグの役割を考えた見せ方

この記事は「カテゴリとタグを上手に使い分ける [http://www.yasuhisa.com/could/article/category-tag/] 」の続きにあたります。 カテゴリに関して迷っている方は少なくないみたいですね。前回、提案したブログエントリーをタイプ別に分類する提案をしましたが、それに対して様々な意見や感想が出ているので、ここで共有しておこうと思います。 > lilac [http://www.yasuhisa.com/could/article/category-tag/#comment-19]さん (カテゴリは) ふつうにいらないんじゃね？みたいな。明確に必要、という答えが出せないんですよね・・・ 他の方も書いていらっしゃいましたが、機能が提供されているからといって使わなければならないというわけではないと思います。無理にいろいろ使おうとするとかえって複雑化してしまうので、そういった場合は思い切って省くことも重要です。これはデザインするときには重要な考え方のひとつでしょう。 今回のようにカテゴリをタイプと見なして使うのは自分のサイトにはフィットしているように思
IA

カテゴリとタグを上手に使い分ける

CMS にタグというコンセプトが組み込まれる以前は「カテゴリー」はどういった情報がコンテンツに含まれているのかを示すものでした。例えば、Mac、映画、ライフハック、仕事といった具合だと思います。しかし、タグ機能が CMS に導入されるようになると、以前カテゴリ名として扱っていた名称 (キーワード) がタグへ移行していきました。 ここで課題になってくるのが、タグがコンテンツに含まれている情報を示すようになったので、カテゴリに明確に違う役割を示さなくてはならないところです。もし従来のように「Mac」というカテゴリを作ってしまうと、Macに関する情報が書かれたエントリーに Mac というタグを書き込むことは重複になりますし、管理する側もこれはカテゴリなのかタグなのかというのが分かり難くなり、記事によって異なる示し方になりかねません。 ブログエントリーとひとことで言ってもエントリーによって様々なタイプ (形式) があります。徒然と文章が書かれていることもあれば、リストだけで終わっているものもあります。どういったブログエントリーを書くかによって、文章の構成は変わりますし、場合によっては文体も