IA

A collection of 19 posts

IA

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

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

IA

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

2月9日に東京で開催された World IA Day 2013 に参加してきました。前回の記事 で書いた今後の IA の課題のヒントになるようなメッセージを、イベントを通して幾つか見つけることができました。 今回は吸収した内容を自分なりにインフォグラフィックにしてみました。 イベントを通して『情報』にはデータベースに蓄積できるようなものと、掴み所がないものと二種類あると考えました。言い換えれば右脳的な情報と左脳的な情報があるといったところでしょうか。まったく違う存在のようにみえる二種類ではありますが、4つの段階を踏んでアーキテクチャ(構造)を作り出しているようにみえました。 Deconstruct (分解) Sort(分類) Compose(構成) Adjust(調整) つまり、感情やニュアンスといった掴み所のない情報だったとしても、ビッグデータを活用した情報の解析だったとしても、進むべき道筋は大変似ているというところがありました。また、機械的に集めるデータだったとしても、人間的な非合理性・不確定性を加味するといった具合に、双方の特性を組み合わせてアーキテクチャの構築を行っている点も興味深かったです。分断しているかのようで実はそうではない・・・相互補完関係にあることに気付かされました。 相互関係として情報が繋がったとき、どのようなアーキテクチャが必要とされるのでしょうか。そのアーキテクチャはどのように生み出されるのでしょう。そして人々はどのように触れることになるのでしょうか。

IA

Big IA と Small IA の間で

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

IA

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

様々なパン屑リスト 利用者が辿ってきた道筋を示し、いつでも先に戻れるような配慮としてパン屑リストがあります。IA の専門家 Keith Instone によると、パン屑リストには以下のタイプがあると言われています。 場所の示す Webサイトをツリー状として捉えたときの利用者の現在地を表示する 経路を示す 利用者が現在地まで辿り着いた道筋を表示する 属性を示す 断面的な検索をして絞り込む際、選択済みの属性を表示する 進行状況を示す アプリケーションの利用の際、タスクの進行状況を表示する それぞれのパン屑リストには特有の機能があり役割を果たして来たわけですが、本当に必要かどうかを再考するべきタイプもあります。例えば経路を示すパン屑の場合、ブラウザで既に実装している「戻る / 履歴」と重複しています。また、利用者が幾つかのページをブラウジングしているだけの場合など経路を残すべきか判断しにくい場合があります。経路を示すパン屑リストへの疑問はヤコブ博士も随分前に供述しています。 本当に階層を知る必要があるのか? 現状、最も利用されているパン屑は場所を示すタイプでしょう。Webサイトはよくツリー状で設計される場合が多いため、その構造を UI として表現されているパン屑リスト。もちろん今の Web サイトにもある程度の構造は必要とされていますし、そのサイトが何を提供出来るのかを知る上でメインナビゲーションは重要な役割を果たしています。しかし、本当にサイト構造をパン屑リストとして示す必要性があるのかどうか疑問です。 利用者は検索でモノを探す傾向にありますし、ソーシャルメディアを活用した情報交換が、

IA

Intertwined WebとユビキタスIA

先月開催された IDEA 2010 というカンファレンスで「Web情報アーキテクチャ」や「アンビエント・ファインダビリティ」といった IA 関連の書籍の執筆者として知られている Peter Morville が、「Ubiquitous Information Architecture」という内容で講演をしました。Webの世界とリアルの世界があやふなになった現在において、Web だけでなく様々なチャンネルとプラットフォームを意識した情報アーキテクチャを考えなければいけないという内容でした。(講演のビデオを Vimeo で見ることができます) Peter MorvilleUbiquitous Information Architecture Peter Morville will discuss IA as it relates to channels previously unattributed to the field. As

IA

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

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

IA

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

「UXの測定要素」で最初にスピードを挙げたのは、Webの体験において近年重要なポジションになってきているからです。ブロードバンドだからこそスピードを要求されますし、モバイルだと欲求はさらに高まるでしょう。プログラムがより早く動作するように記述の工夫や構成の検討したり、CSS や HTML といったマークアップからでもパフォーマンスを上げることが出来ます。こうした技術的なアプローチだけではなく、情報の整理の仕方や心理的な部分からスピードを表現することが可能です。 例えば、トップページのように様々な導線も含まれた情報量の多いページがあるとします。技術的な工夫を施し、表示速度が早いページにしたとしても、情報が入り組んでいて利用者が見つけ難い構成であれば「時間がかかる=遅い」と感じるでしょう。「2つ以上の製品を比較したい」「製品の特徴を把握したい」という利用者に明確な目的がある場合はどうでしょうか。一見、きれいに情報が整理されているページだったとしても目的を達成するために複数のページを横断しなければならないのであれば「時間がかかる=遅い」になってしまいます。 単体ページの情報整理だけでなく、ゴールまでの導線という複数ページの流れでもスピードは表現出来ます。製品をカートに入れてから決済までの流れ。トップページから目的に行き着くまでもステップ。導線までの道筋をいかに負荷を減らして作り上げるかが課題になります。OpenID を利用して会員登録への敷居を低くしたり、システムを再検討してステップを少なくしてくれるカートを導入するといった技術的な解決方法もありますが、デザインからも利用者の負荷を低くすることは可能です。カートだけでなくアンケートでもよく導入されていますが、スタートからゴールまであとどれくらいかかるのか、次のページには何があるのかといった表記がされていると、たとえ時間がかかるプロセスでも心理的な負荷を減らすことが出来ます。 ジョン・マエダ氏の著書「シンプリシティの法則」

IA

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

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

IA

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

検索とひとことで言ってもいろいろな形があります。私たちが Google などでキーワード検索するときは、答えを導き出すためのキーワードが分かっている場合がありますが、いつもゴールへの辿り着き方が分かるとは限りません。ゴールが何か明確でない場合もありますし、辿り着くためにまずは関連情報を学ぶ必要があるかもしれません。閲覧 (Browse) と検索 (Search) が合わさったような利用者の行動を Exploratory Search (探索的検索) と呼んでおり、ここ数年様々な研究・調査がされています。概要が知りたい方は Wikipedia の記事が参考になります。 今すぐ欲しい情報を探すのであればキーワード検索でも十分ですが、調査、仕事のプロジェクト、ライフプランなど中・長期に渡って探し続ける情報をいかに補助するかが課題です。今でもブックマークを使ったりメモソフトを組み合わせることで管理が出来ているものの、別の解も考えられます。探索的検索を理解することが出来れば、キーワードから導き出されるサイトを提示するのではなく、利用者にとって意味がある情報が上位になるようなパーソナライズ化がさらに進むと思います。 もし何か調査をしているのであれば、ひとつ前に検索したキーワードが今検索しているキーワードの結果に影響しても良いと思いでしょう。今検索しているキーワードが数日前に検索した別のキーワードの関連しているのであれば、そこから答えや経路を提案しても良いでしょう。ユーザーがコミュニティに属しているのであれば、他のメンバーが検索で導いた答えやメモを参考にすることが出来かもしれません。 探索的検索ワークショップ 昨年、 National Science Foundation が

IA

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

撮影: 飯田昌之 2009年9月12日ベルサール神田にて CSS Nite LP, Disk 7「IAスペシャル」が開催されてました。IA を語るならこの人と呼ばれる方々から様々な視点の IA を聞くことが出来ました。6時間という長丁場で、しかも相当量の情報があったと思うので消化するのは少し時間がかかるかと思いますが、既に たくさんの方 が、レポート&感想を書いています。 私はイベントの一番最後に「IAからWebサイトデザインへの突破口」という題名でプレゼンを行いしました。長丁場の終盤だったので来場者の多くは疲れていたと思います。そんな中で漠然とした内容のプレゼンを聞いても頭にピンと来なかった方も多かったのではないかと心配していますし、伝える力が足りなかったのではないかと反省しています。幸い Twitter 上では、プレゼン力に高い評価を頂き大変感謝をしています。今回、出演されている他の方々と同じ場所で話すということ。そして一番最後ということでプレッシャーもありましたが、それゆえプレゼンには細心の注意を払って当日に挑みました。 それが結果に繋がったのは良かったですが、プレゼンのインパクトだけが残って内容が残らなかったのではないか、思惑(テーマ)が来場者にきちんと行き届いたのかが分からない講演になってしまったのが私の反省点です。 実は共有知識になっていないという事実 私のセッションだけでなく他にもいえることですが、今回は IA

IA

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

プロトタイプを作るのは重要ですが、作るためにおおくの時間を割きたくないところ。特に作ったあとも何回か調整をするわけですから、あまり作り込むわけにはいきません。しかし、あまりに単純な見た目だと情報共有が難しくなります。自分が使い慣れているツールを使うのは第一歩ですが、ちょっとしたことを気をつけることで、効果的なプロトタイプを早く作れるようになります。 スゴいコツだ!というのはありませんが、心がけてるだけでも少しばかり早く作れるようになりますよ。 使えるパレットを用意する よく使う UI 要素やコメントを付けるためのパーツはパレットにしておくと効率的。以前紹介した、OmniGraffle用とPowerPoint用を利用すると手軽です。 テンプレートを用意する OmniGraffle では、通常のファイルを新規作成が出来るだけでなく、テンプレートを作成することが出来ます。単位をピクセルにし、グリッド表示にしてあるファイルをあらかじめ用意しておけば、何度も設定する手間が省けます。 リンクを加える PowerPointでもOmniGraffleでもハイパーリンクを加えて別のページへ移動することを可能にします。特定のオブジェクトの表示・非表示も可能なので、工夫次第でページ内の変化も表現することも出来ます。PowerPointであれば、マウスオーバーといった別のインタラクションにも異なるアクションを加えることが可能なのでさらに詳細な表現が可能です。 スタイルを合わせてペースト 文字の大きさや色など、同じスタイルを毎回設定するのは面倒なので、「スタイルを合わせてペースト」を活用。PowerPoint だと、「Ctrl + Shift + V」がありますが、

IA

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

ウェブサイト制作でもプロトタイプを作成する機会が増えてきたと思います。しかし、プロトタイプ一言でいっても様々な方法で作ることが出来ます。今まで様々な種類のプロトタイピングを紹介したことがありますが、どの方法を使った方が良いか迷うところです。短時間で作れるかどうかだけでなく、誰と共有するのか、変更がしやすいか、完成品とどれくらい近づけるのかなど考慮したい項目は幾つかあります。Adobe Dev Center の「Industry trends in prototyping」という記事では、プロトタイプのメリットだけでなく、よく使われているプロトタイピングも紹介しています。この記事も参考にして、幾つかあるプロトタイピングの長所・短所を考えてみました。 紙のプロトタイプ すぐに作れるメリットはあるが、完成品と使い勝手が異なるだけでなく、再利用も難しい クリック可能なスクリーンショット PDFなどで共有がしやすい。最初にライブラリを作っておけば UI 要素の共有が可能。ただしコードの再利用は不可 クリック可能なHTMLファイル HTMLベースのサイトであれば、最も完成品に近くチームメンバーとの共有もしやすい。コードの再利用も可能で、プロジェクト全体のスピードも上がるが、下準備に時間がかかる Flash又はSilverlight UI要素の再利用だけでなく共有も難しくないが、HTMLベースのサイトのためであれば効果が低い 上記に書いた長所・短所は、

IA

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

一部ではGoogleキラーと呼ばれている次世代検索エンジンPowerset。キーワードだけでなく自然な文章でも検索出来るというところまでは他のサービスも行っていますが、検索結果の見せ方や情報の見せ方に幾つかの工夫がなされています。今のところ Wikipedia の記事 (英語のみ) を検索出来るだけですが、なかなかおもしろいです。個人的に「キラー」と呼ぶのは大袈裟だと思いますが、 Powerset では独自の情報の見せ方を提案しており、UIデザインや情報整理の観点からみると大変興味深いサービスです。今回は Powerset で見つけた興味深いアプローチを幾つか紹介していきます。 A. 概要 検索するとページの一番上に最も該当する項目が表示されます。通常のリスト表示ではなく写真付きで記事をある程度読むことが出来るようになっています。Googleでもこうした見せ方は一部のキーワードで行っていますが、Powersetではさらに検索したキーワードに関連するキーワードや、影響を及ぼしている項目を表示しています。例えば「Bauhaus」と検索すれば、それがデザイン運動の名称と認識し、合わせて読みたいキーワードを表示しています。 B. クイックビュー 概要の下に他の検索結果でも見られるようなリスト表示がありますが、こちらも工夫がなされています。各アイテムに表示されている矢印アイコンをクリックするとその場で記事を確認することが出来ます。もちろんビューエリアの大きさを変えたり文字の大きさの変更は出来ますが、興味深いのが記事全体を把握しながら読むことが出来るところ。これに関して後に紹介する [F] を参照してください。 C. キーワードクラウド Bauhausの記事をはじめとしたすべての記事に「Explore

IA

リンクタイプの構成案

可能な限りフィードバックを得れるような状態にしながら、徐々に方向性を固めて組み立てれるように複数のサイクルで構成されたプロセスを提案しました。今回はその第一弾である「リンク」タイプのデザインに取りかかろうと思います。リンクは「クラフトっぽいアート作品いろいろ」のようにゆるいテーマがあるかもしれないですが、リンクが羅列しているようなエントリーのことを指します。 このタイプのエントリーはあまりブックマークもされることもなく、どちらかというと検索からくる方のほうが多いです。サイトへのロイアリティもあまり高くないので、最近のエントリーやタグリストなどといった全体像が分かるものを省いて、読者が必要しているものをはっきり見せることが必要とされるタイプになります。リンクタイプはイントロダクションのような文章もない単純なリスト(<dl> で記述)なので、文体も統一されています。マークアップ面では完全にパターン化されるので、独自の見せ方もしやすいです。 そのあたりを頭に入れて、とりあえず紙にワイヤーフレームやアイデアを書き込んでいきました。 リンクを紹介しているタイプなので、サイト名の文字を通常より大きくしたりクリックエリアを大きめにとるといった工夫は必須でしょう。また、リンク先のスクリーンショットも見えると良いですね。Snap Shots を使うという手段もあるかもしれませんが、ポップアップはちょっとうるさく感じることがあるので、ここは Simple API の力を借りることになるでしょう。 他に考えているのが、リンク集で扱っているようなサイトのリストアップ。これはタグをキーワードにして Google Ajax Search API

IA

サイドバーの行方

サイドバーはブログが広まる前から存在していたコンポーネント。メインコンテンツ以外の情報を上部に載せることが出来るので、多くのサイトでサイドバーが採用されています。実装も簡単に出来ますし、3カラム、4カラムと増やすことも出来るわけですが、実装の敷居も低いのでただの賑やかしになってしまいがちの部分でもあります。情報の配置の仕方によって、情報が活かされるときもあれば、そうでないときもあります。サイドバーもメインコンテンツ以外の情報を放り込む場所ではなく、的確な情報が載る場所として扱わなくてはいけません。 ブログのサイドバーで必要なもの サイドバーによくある情報は 最近のエントリーリスト 最近のコメントリスト アーカイブリスト カテゴリリスト タグクラウド Feed をはじめとした購読ボタン ウィジェット諸々 アクセス解析やサイトコンセプトによってサイドバーの使い方も変わってきます。このサイトは Feed は多くの方に登録されていますが、サイトまで訪れる方はその中のわずかな数ですし、エントリーによってアクセス数も数倍違うこともあります。よって、情報収集家が最も多いと仮定出来ます。もちろん、検索から訪れる方も少なくありません。つまり、レギュラー読者より初めてもしく時々サイトに訪れる方のほうが多いといえます。Feed を購読している読者もたまに訪れるわけでですから、彼らが久しぶりに訪れたときに便利な情報も欲しいところです。 ブログのサイドバーの情報の置き方で参考になるのは、ニュースサイトです。asahi.com>の記事ページをみると、サイドバーには「注目」

IA

今時のプロトタイピング

この記事は「PowerPoint を使ったプロトタイピング」の続きにあたります。 ページベースの Webサイトを制作するのであれば、多くの方が利用出来るということも含めて PowerPoint や Keynote といったプレゼンテーションアプリが最適だといえます。しかし、Ajax や Flash を利用したページを移動することなくデータにアクセスするサイトや Webアプリケーション、ショッピングサイトのような会員/非会員によって異なるコンテンツやフォームを必要とするサービスでは、ページベースで Webサイトを考えるのは困難です。 ユーザーテストをする際も PowerPoint や Keynote では難しい場合もあるでしょう。共に高度な描写が可能になり見た目の質は高くなりましたが、クリックしたときの動作や、「戻る」「進む」のようなブラウザを介した操作、そしてマウスやキーボードを使った操作までテストすることが出来ません。ページベースでプロトタイプを作るのでインタラクションも平面的になってしまい、テストをしながらプロトタイプを改善させるには少し物足りない場合も出て来るでしょう。 以前、「よりリッチなWebサイトプロトタイピング」で紹介した Axure はひとつの解といえるでしょう。Ajax のようなダイナミックなインタラクションをプロトタイプに付け加えることが出来るだけでなく、サイトマップやフローチャートとプロトタイプと連動させて作ることが出来ます。作成したプロトタイプはブラウザ上で観覧出来るのでユーザーテストも難しくありません。 Axure

IA

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

そろそろ大まかな形でワイヤーフレームを作っていこうと思っているわけですが、その前にいろいろ準備しておきたいことも幾つかあります。そのひとつが、拡張性を考えて、どのようなデータをどの辺りに配置するのがベストかを考えること。これは Webアプリケーション開発において特に重要になってくることだと思いますが、大幅な改変をしなくても、機能やミニコンテンツといったコンポーネントを付け加えることが出来るように設計しておく必要があります。もちろん、すべての可能性を考慮することは不可能ですが、あらかじめ拡張されることを考慮して設計を始めるか始めないかでは大きな違いがあります。 下の図はページを大まかに4つに別けて、異なる配置を考えたものです。 ※ ワイヤーフレームの基盤のような存在なので、実際のサイトのワイヤーフレームを作っているわけではありません。 ナビゲーション サイトのグローバルナビゲーションに当たるエリア。Webアプリケーションにおいては機能を示すことが多い コンテキスト / データセット 現在観覧しているページがどういったページが示していたり、サイト全体からみたページの位置を示しているエリア。パンくずがあるケースも メインコンテンツ ページのなかで最も重要とされるデータ。ブログであればブログエントリーのことを指す 関連データ / フィルター メインコンテンツに何かしらの形で関連したデータであったり、メインコンテンツを操作するためのコマンドがあるエリア どれが拡張する可能性があるのか見極める グローバルナビゲーションはサイト全体を大まかに見渡すことが出来る重要なエリアですが、サイトによっては幾つか増える可能性がある場合もありますし、ネーミングを長くしなければならないこともあるでしょう。そういった場合、ナビゲーションを横に配置すると、2列になってしまうなど限界が出てしまいます。名称が長いと、配置出来るナビゲーションの数も減っていくでしょう。そういう可能性があらかじめ分かっている場合であれば、横ではなく縦に配置したほうが良いです。 例えば Amazon.

IA

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

この記事は「カテゴリとタグを上手に使い分ける」の続きにあたります。 カテゴリに関して迷っている方は少なくないみたいですね。前回、提案したブログエントリーをタイプ別に分類する提案をしましたが、それに対して様々な意見や感想が出ているので、ここで共有しておこうと思います。 lilacさん(カテゴリは) ふつうにいらないんじゃね?みたいな。明確に必要、という答えが出せないんですよね・・・ 他の方も書いていらっしゃいましたが、機能が提供されているからといって使わなければならないというわけではないと思います。無理にいろいろ使おうとするとかえって複雑化してしまうので、そういった場合は思い切って省くことも重要です。これはデザインするときには重要な考え方のひとつでしょう。 今回のようにカテゴリをタイプと見なして使うのは自分のサイトにはフィットしているように思えたから採用しましたが、ブログによってはタグだけで管理したほうが治まりが良いのもあるような気がします。 タグの扱い方いろいろ 前回のエントリーではカテゴリにフォーカスした話題でしたが、タグはどうでしょう。役割が明確になってきたので、コンテンツに関わるキーワードを記入していけば良いわけですが、多くなって来るとどうページに表示させて良いか迷うところです。Tag Cloud の見せ方はいろいろあり、中には参考になるのも幾つかあります。情報を視覚的に見せるという意味ではタグ専用のページを設けて Tag Cloud にするのは有効な手段だと思います。しかし、これをサイドバーに掲載したとしても読み難いですし、多くなって来たときの問題解決にはならないでしょう。 そもそも Tag Cloud のようにしてすべて(もしくはほとんどの)タグをすべてのページに掲載したほうが良いのかという疑問が残ります。

IA

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

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