<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>Kangaroonote</title>
    <link rel="alternate" type="text/html" href="http://vosegus.org/blog/" />
    <link rel="self" type="application/atom+xml" href="http://vosegus.org/blog/atom.xml" />
    <id>tag:vosegus.org,2009-11-26:/blog//2</id>
    <updated>2012-05-17T12:44:33Z</updated>
    
    <generator uri="http://www.sixapart.com/movabletype/">Movable Type Pro 5.0</generator>

<entry>
    <title>スクリーンサイズ</title>
    <link rel="alternate" type="text/html" href="http://vosegus.org/blog/2012/05/screen-size.html" />
    <id>tag:vosegus.org,2012:/blog//2.453</id>

    <published>2012-05-16T13:31:12Z</published>
    <updated>2012-05-17T12:44:33Z</updated>

    <summary>あらゆる時代のあらゆるひとにとって、世界の中心はまぎれも無く自分自身でしかない。...</summary>
    <author>
        <name>toshimitsu</name>
        
    </author>
    
        <category term="Web とは何か" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="design" label="Design" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="ja" xml:base="http://vosegus.org/blog/">
        <![CDATA[<p>あらゆる時代のあらゆるひとにとって、世界の中心はまぎれも無く自分自身でしかない。野球選手は野球から人生の多くを学び、デザイナはデザインから人生を学ぶ。だから野球選手はみんなが野球をやれば世界が平和になると信じているのだろうし、デザイナは全てのひとがデザイン思考をすれば世界は幸福になると思っている。</p>
<p>けれどそんなことは全く嘘だ。茶道からでも宗教からでも、人事や事務処理からでも、野球やデザインで学ぶのと同じことが学べる。</p>
<p>空間においてもまた、中心は常に自分自身になる。その証拠に、部屋の中央に居れば部屋は広くも感じるし、逆に部屋の隅に追いやられれば、まるで空間が縮んでしまったかのように狭く感じる。その部屋の物理的な大きさはなにひとつ変わらないのに、ひとは主観によってあらゆるものを歪めてしまう。</p>
<p><a href="/blog/2012/05/cognitive-model.html">インフォメーションアーキテクチャ空間</a>を設計するのなら、ひとにとっての広さや狭さ、距離というのを考える必要がある。</p>
<section>
<h2>主観による広さの違い</h2>
<p>部屋の隅に追いやられれば身動きがとりづらくなるように、スクリーンの端にあるものは扱いづらい。</p>
<p>あるひとにとっての十分な広さの空間というのは、そのひとが育った文化や時代に依存する。アメリカ人にとっては狭苦しい部屋も、日本人にとっては広すぎる家かもしれない。</p>
<p>けれどデザイナにとって幸いな事に巨人族は絶滅したようなので、ひとの身体の大きさはある程度予想できる範囲におさまっている。</p>
<p>大人と子供ではある程度違いがあるにしても、ユニバーサルデザインというコンセプトを取り入れることができるのなら、その物理法則のみならず、認知レベルの差でさえ、むしろ追い風に変える事が出来る。</p>
</section>
<section>
<h2>スクリーンを最大化する</h2>
<p>大きなものは大きいし、小さなものは小さい。</p>
<p>なにを当たり前の事をと思うかもしれないけれど、大きさや小ささというのは全て用途に依存している。例えば 1 メートルのプリンは大き過ぎて食べきる事はできないけれど、映画館のスクリーンが 2 メートルなら、それはむしろ小さいと感じる。</p>
<p>デバイスのスクリーンの大きさというのももちろん用途によって決まっている。ポケットに入れるスマートフォンと机の上に置いて使うデスクトップでは明らかに大きさが違う。多人数で共有するためのタッチスクリーンなら 2 メートルあっても狭いと感じるのかもしれない。</p>
<p>ではスマートフォンのモニタは小さいのだろうか。</p>
<p>ぼくはスマートフォンを使っていて&quot;小さい&quot;と思ったことはない。ただ、&quot;狭い&quot;と感じることはある。</p>
<p>けれども全てのデザインを狭いと感じるわけじゃない。よくできたデザインは十分な広さを感じさせてくれるし、一方で画面の要素が極端に少ない場合でも狭いと感じることもある。</p>
<p>その差のひとつの原因は、用途に応じた適切な大きさが設計されているか否かに依るように思う。</p>
<p>それは単にタッチするボタンの大きさの問題だけでなく、全ての要素の全ての大きさが目的的に設計されているのかの問題なのだと思う。</p>
<p>大きさとは最初に決めたひとつめで既にそれ以降の全ての大きさが決まっているものだ。</p>
<p>コルビジェは人体の寸法からモジュールという基準寸法をつくった。それに比べると、狭い GUI をつくるデザイナの大きさの基準はひどく恣意的なものになっているのだと思う。</p>
<p>大きくすればいいというものでもないし、小さくすればいいというものでもない。人間の手や声や視力聴力、むしろ建築物の大きさを決定するよりも GUI では多次元での設計が必要になってくる。</p>
</section>
<section>
<h2>画面上のユーザインターフェース空間</h2>
<p>現在スクリーンに映っているユーザインターフェースは今体感している広さ（狭さ）と直結している。</p>
<p>ならそれはある意味で最も大切な空間だといえる。では適切な大きさとはどうやって考え、決定すればいいのだろう。次はそれを掘り下げてみる。</p>
</section>]]>
        
    </content>
</entry>

<entry>
    <title>インフォメーションアーキテクチャ空間のモデル化</title>
    <link rel="alternate" type="text/html" href="http://vosegus.org/blog/2012/05/cognitive-model.html" />
    <id>tag:vosegus.org,2012:/blog//2.452</id>

    <published>2012-05-13T04:10:20Z</published>
    <updated>2012-05-16T14:35:25Z</updated>

    <summary>Web サイトがアーキテクチャ（建物）だとしたら、それは空間のメタファを利用する...</summary>
    <author>
        <name>toshimitsu</name>
        
    </author>
    
        <category term="Web とは何か" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="ia" label="IA" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="ux" label="UX" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="ja" xml:base="http://vosegus.org/blog/">
        <![CDATA[<p>Web サイトが<a href="/blog/2012/03/information-architecture.html">アーキテクチャ</a>（建物）だとしたら、それは空間のメタファを利用することでより強固なものになる。では自分が今いる Place （場所）と Place を内包する Space （空間）は、バーチャルな空間ではどのように認知されるのだろう。</p>
<p>実際にひとが Web を利用して情報探索をする場合には、複数の異なる次元の空間が並列に存在しているように思う。そしてそれは大きく分けると以下のようなものになる。</p>
<ul>
<li>画面上のユーザインターフェース</li>
<li>画面に表示されているページの Webサイト全体</li>
<li>情報探索の過程でつくられる概念空間</li>
<li>情報探索の前段階でつくられるユーザの予測（希望）による概念空間</li>
</ul>
<section>
<h2>空間の定義</h2>
<p>これらがユーザの頭の中でどのように利用され、関係しているかを考える前に、そもそもここでいうところの空間とはなにかを定義しておかないといけない。</p>
<p>まず、空間には基準点が必要になってくる。なにも無い空間は人間ではモデル化できないから、複数の基準点を内包した有限の距離をもった広がりを空間としたほうが都合がいい。さらに基準点は絶対的なものと相対的なもののふたつを用意すると迷子になる恐れが軽減できる。</p>
<p>例えば絶対的な基準点を自分の家とする。あとは自分の家を基準としてその他の基準点（会社や学校等）の相対的な位置関係を把握したほうが、全てを相対的関係として把握するよりも容易い。</p>
<p>ここではその絶対的基準点をユーザの現在地にする。</p>
<p>でもそうするとユーザの現在地は常に移動するから絶対ではなくなってしまうように思える。</p>
<p>けれどリアルと同じ意味での不動の場所というのは概念空間では存在しないので、ある時間におけるある場所を絶対的な基準点としたほうが無理がないように思う（もし単に Web サイトというだけのはなしならホームページを絶対的な基準点にすればよいのだけれど）。つまり絶対的な位置というのはある限られた時間内での絶対位置ということになる。リアルでも引越しなどで基準点は変わることはあるから、現実空間を利用した認知モデルが崩壊するわけじゃない。</p>
<p>ただ、その時間はリアルよりもはるかに短いものになるので、絶対的基準点がいつ移動するのかを常に考慮しながらデザインしなければ、ユーザが迷子になる恐れは増す。</p>
<p>以上のことから空間はユーザを中心として広がり、ユーザが把握しているか、もしくは存在しているだろうという予測が成り立つ範囲、さらに希望まで含むこととする。</p>
<p>予測や希望も含むから、当然それが実在しているのかは問わない。箱を空けてみて存在しなければ、その部分はその瞬間に消失する。</p>
<p>次元の異なる複数の空間であるから、距離や大きさ、広さも、画面上の物理的なものと、概念としてしか存在しないものがある。</p>
<p>一方、空間上に存在する場所（基準点）は常に実在していなければならないものとする。過去に居た場所、もしくは今いる場所がここでは空間上に存在する場所の定義で、これには予測や希望は含まれない。</p>
<p>つまり、まだ見つけていないものは、空間のどこかにある空間の一部であって、場所（基準点）とはならないものとする。</p>
</section>
<section>
<h2>各空間の具体化</h2>
<p>空間の関係を考える前に、まずは個々の空間がどのように捉えられ、利用されるかを考える。</p>
<p>画面上のユーザインターフェースは、物理的には存在しないけれど、まるでそこにあるかのように目には見えるので、他のものに比べると理解し容易い。なので<a href="/blog/2012/05/screen-size.html">次回はここから考えてみる</a>。</p>
 </section>
<div id="rebound" style="width:360px;height:240px;position:relative;border:1px solid #333;">
<div id="rebound-obj" style="position:absolute;background:url(/img/delft.png);width:121px;height:21px;"></div>
</div>
<script>
//<!--
var rebound = function(arg){
 var obj = arg || 0;
 var unit = {elm:$(obj.unit),h:$(obj.unit).height(),w:$(obj.unit).height()};
 var element = {target:$(obj.target),h:$(obj.target).height(),w:$(obj.target).height(),x:0,y:0};
 var dir = {x:4,y:4};
 element.x = Math.random() * unit.w;
 element.y = Math.random() * unit.h;
 
 setInterval(reboundAnimation,33);
 
 function reboundAnimation(){
  if(element.x < 0 || element.x > 240){
   dir.x = -(dir.x);
  }
  if(element.y < 0 || element.y > 220){
   dir.y = -(dir.y);
  }
  element.x += dir.x;
  element.y += dir.y;
  element.target.css({top:element.y+'px',left:element.x+'px'});
 }
 
}
rebound( {unit:"#rebound",target:"#rebound-obj"} );
//-->
</script>]]>
        
    </content>
</entry>

<entry>
    <title>ワードプレス テーマのカスタマイズ</title>
    <link rel="alternate" type="text/html" href="http://vosegus.org/blog/2012/05/wordpress-theme-customization.html" />
    <id>tag:vosegus.org,2012:/blog//2.451</id>

    <published>2012-05-07T11:56:39Z</published>
    <updated>2012-05-10T16:56:56Z</updated>

    <summary>今まではあまり使うことはなかったけれど、必要に迫られてきていろいろ調べてみたので...</summary>
    <author>
        <name>toshimitsu</name>
        
    </author>
    
        <category term="CMS" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://vosegus.org/blog/">
        <![CDATA[<p>今まではあまり使うことはなかったけれど、必要に迫られてきていろいろ調べてみたので、記録。</p>
<p>正式な情報は<a href="http://wpdocs.sourceforge.jp/">公式ドキュメント</a>を参照。</p>
<h2>最初にすること</h2>
<ol>
<li>デフォルトのテーマフォルダ（ Twenty Eleven ）をコピーして[テーマ名]にリネーム</li>
<li> style.css のテーマ詳細をサイトの情報に合わせる</li>
<li>/wdd-content/themes/[テーマ名]/screenshot.png を入れ替える</li>
<li>全ファイル の Twenty Eleven の付いたコメントを[テーマ名]に合わせる</li>
<li>テーマを有効化</li>
<li>追加するテキストファイルは /wdd-content/themes/[テーマ名]/ に入れていくと管理画面から編集可能になる</li>
</ol>
<h2>Twenty Eleven のファイル構成</h2>
<h3>テンプレート</h3>
<dl>
<dt>404 テンプレート (404.php)</dt>
<dd>404 ページのテンプレート</dd>
<dt>固定ページテンプレート (page.php)</dt>
<dd>固定ページのデフォルトのテンプレート</dd>
<dt>Showcase Template 固定ページテンプレート (showcase.php)</dt>
<dd>固定ページで選択できるテンプレート（サイドバー無）</dd>
<dt>Sidebar Template 固定ページテンプレート (sidebar-page.php)</dt>
<dd>固定ページで選択できるテンプレート（サイドバー有）</dd>
<dt>単一記事の投稿 (single.php)</dt>
<dd>投稿する記事のテンプレート</dd>
<dt>投稿タグテンプレート (tag.php)</dt>
<dd>タグで関連づけされた投稿の一覧ページのテンプレート</dd>
<dt>content-status.php (content-status.php)</dt>
<dd>投稿画面で選択するフォーマットのテンプレート</dd>
<dt>content.php (content.php)</dt>
<dd>投稿画面で選択するフォーマットのテンプレート</dd>
<dt>content-aside.php (content-aside.php)</dt>
<dd>投稿画面で選択するフォーマットのテンプレート</dd>
<dt>content-featured.php(content-featured.php)</dt>
<dd>showcase.php で利用されてるテンプレート</dd>
<dt>content-gallery.php (content-gallery.php)</dt>
<dd>投稿画面で選択するフォーマットのテンプレート</dd>
<dt>content-image.php (content-image.php)</dt>
<dd>投稿画面で選択するフォーマットのテンプレート</dd>
<dt>content-link.php (content-link.php)</dt>
<dd>投稿画面で選択するフォーマットのテンプレート</dd>
<dt>content-quote.php (content-quote.php)</dt>
<dd>投稿画面で選択するフォーマットのテンプレート</dd>
<dt>content-intro.php (content-intro.php)</dt>
<dd>showcase.php で利用されてるテンプレート</dd>
<dt>content-page.php (content-page.php)</dt>
<dd>page.php と sidebar-page.php で利用されてるテンプレート</dd>
<dt>content-single.php (content-single.php)</dt>
<dd>single.php で利用されてるテンプレート</dd>
<dt>sidebar-footer.php (sidebar-footer.php)</dt>
<dd>フッターに配置されるウィジェット</dd>
<dt>theme-oddtions.php (theme-oddtions.php)</dt>
<dd>テーマのオプションを作成 管理画面からレイアウト変更を選択できるなど</dd>
<dt>widgets.php (widgets.php)</dt>
<dd>ウィジェットの Class ファイル（?）</dd>
<dt>アーカイブ (archive.php)</dt>
<dd>アーカイブページのテンプレート</dd>
<dt>カテゴリーテンプレート (category.php)</dt>
<dd>カテゴリーページのテンプレート</dd>
<dt>コメント (comments.php)</dt>
<dd>コメントパーツのテンプレート</dd>
<dt>サイドバー (sidebar.php)</dt>
<dd>サイドバーのテンプレート</dd>
<dt>テーマのための関数 (functions.php)</dt>
<dd>テーマで使用されるの関数を定義（?）</dd>
<dd>関数の追加もこのファイルにする</dd>
<dt>フッター (footer.php)</dt>
<dd>フッターのテンプレート</dd>
<dt>ヘッダー (header.php)</dt>
<dd>ヘッダーのテンプレート</dd>
<dt>メインインデックスのテンプレート (index.php)</dt>
<dd>メインインデックスのテンプレート</dd>
<dt>作成者テンプレート (author.php)</dt>
<dd>記事詳細にある投稿者のアカウントリンクの先の投稿者別記事一覧のテンプレート</dd>
<dt>検索フォーム (searchform.php)</dt>
<dd>検索フォームパーツのテンプレート</dd>
<dt>検索結果 (search.php)</dt>
<dd>検索結果のテンプレート</dd>
<dt>画像添付テンプレート (image.php)</dt>
<dd>記事のフォーマットで画像を選択した場合の詳細画像のテンプレート</dd>
</dl>
<h3>スタイルシート</h3>
<dl>
<dt>RTL スタイルシート (rtl.css)</dt>
<dd>Right to Left で表記される文字（アラビア文字等）のための CSS（デフォルトは Left to Right なので使用されていない）</dd>
<dt>スタイルシート (style.css) </dt>
<dd>テンプレートを整形している CSS</dd>
<dt>ビジュアルエディターの RTL スタイルシート (editor-style-rtl.css)</dt>
<dd>Right to Left で表記される文字（アラビア文字等）のための CSS（デフォルトは Left to Right なので使用されていない）</dd>
<dt>ビジュアルエディターのスタイルシート (editor-style.css)</dt>
<dd>投稿・固定ページ編集画面のビジュアルモードで描画される CSS</dd>
</dl>
<h2><a href="http://wpdocs.sourceforge.jp/データベース構造">データベース</a></h2>
<dl>
<dt>wp_commentmeta</dt>
<dd>コメント・トラックバックのメタデータ</dd>
<dt>wp_comments</dt>
<dd> コメント・トラックバックのデータ</dd>
<dt>wp_links</dt>
<dd>リンク（ウィジェット）情報</dd>
<dt>wp_options</dt>
<dd>管理画面で設定したオプション情報</dd>
<dt>wp_postmeta</dt>
<dd>投稿のメタ情報（画像やテンプレートの使用状況等）</dd>
<dt>wp_posts</dt>
<dd>投稿・固定ページの内容</dd>
<dt>wp_term_relationship</dt>
<dd>オブジェクト（wp_posts テーブルの各投稿記事、wp_links テーブル内の各リンク）と wp_term_taxonomy の（少なくとも 1）カテゴリ・タグとの関連付け情報を格納</dd>
<dt>wp_term_taxonomy</dt>
<dd> wp_terms の分類情報</dd>
<dt>wp_terms</dt>
<dd>投稿およびリンクの分類（カテゴリ・タグ）に使われる語句の基本情報 </dd>
<dt>wp_usermeta</dt>
<dd> ユーザ・メタデータ情報</dd>
<dt>wp_users</dt>
<dd>ユーザ情報</dd>
</dl>
<h2>その他参考</h2>
<ul>
<li> <a href="http://kasegoo.info/fast/799/">WordPressの「投稿記事」と「固定ページ」の違い</a></li>
<li> <a href="http://kachibito.net/wordpress/add-post-formats.html">お手軽WordPress Tips：1行のコードで追加できる便利な新機能「投稿フォーマット」を使ってみよう</a></li>
<li> <a href="http://blog.openmedialabo.net/archives/2090">WordPressでカテゴリID/カテゴリ名を取得する</a></li>
<li> <a href="http://wpdocs.sourceforge.jp/Using_Permalinks">パーマリンクの使い方</a></li>
<li> <a href="http://ja.forums.wordpress.org/topic/1164">自動整形 &amp; タグ除去回避プラグイン PS Disable Auto Formatting </a></li>
<li> <a href="http://www.devolen.com/blog/wp_custum/to-delete-a-comment-feed-in-twenty-eleven/">[WordPress]ワードプレスベーシックテーマ「Twenty Eleven」で head内のコメントフィードを削除する方法</a></li>
<li> <a href="http://www.devolen.com/blog/wp_custum/new_info/">[WordPress]ワードプレスでトップページなどに新着情報を表示する方法</a>
<ul>
<li> <a href="http://www.devolen.com/blog/wp_custum/cat_distinction_new_info/">ワードプレスでトップページなどに、カテゴリー別の新着情報を表示する方法</a></li>
<li> <a href="http://www.devolen.com/blog/wp_custum/number_letters_restrictions_new_info/">ワードプレスでトップページなどに表示する新着情報を、文字数制限をして表示する方法</a></li>
</ul>
</li>
</ul>]]>
        
    </content>
</entry>

<entry>
    <title>CSS の基本設計</title>
    <link rel="alternate" type="text/html" href="http://vosegus.org/blog/2012/04/css-designing.html" />
    <id>tag:vosegus.org,2012:/blog//2.446</id>

    <published>2012-04-28T04:23:02Z</published>
    <updated>2012-04-29T11:43:32Z</updated>

    <summary>だいたい仕事でやっていると、学習の結果が自己完結してしまって、それを後で体系的に...</summary>
    <author>
        <name>toshimitsu</name>
        
    </author>
    
        <category term="CSS" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="design" label="Design" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="ja" xml:base="http://vosegus.org/blog/">
        <![CDATA[<p>だいたい仕事でやっていると、学習の結果が自己完結してしまって、それを後で体系的にまとめたりだとか、説明的に再解釈するというプロセスを端折って次へ進んでしまうということに成りがちなので、それを誰かに説明したりする場合に、言葉にできていない部分が多々みつかって、うまく伝えられないという事態を被る事がある。</p>
<p>そんなわけで、自分なりの CSS のデザインのやり方をまとめてみる。</p>
<h2>デザインの戦略</h2>
<p>デザインを行うにあたっては必ず戦略をたてる。何が正しくて何が間違っているのかを決定していくためには、その拠り所になるものを決めていないと、結果キメラが出来上がってしまいかねない。戦略とは法律に対する憲法のようなもので、法律は絶対に憲法に違反することができないように、デザインはデザインの戦略に服従する。それに違反した場合には、違憲立法審査権を発動できるアーキテクチャをつくらなければ、デザインはいずれ崩壊している。</p>
<p>さておき、複雑なことはあまり考えたくないので、選択するのはだいたい以下の三つの戦略のどれかしかない。</p>
<ul>
<li>独立型</li>
<li>モジュール型</li>
<li>拡張型</li>
</ul>
<p>どれを選ぶかは都度変わるし、明確な優劣はない。どれも一長一短があって、そこにはデザイナの好みの問題も入ってくる。</p>
<p>それでは以下のように、基本的な構造が同じで、幅や背景だけ違うスタイリングを行うための実際のコードを交えつつ、各戦略を具体的に説明してみる。</p>
<figure><img src="/blog/img/css-designing.png" alt="整形された HTML の画像" /></figure>
<p>各戦略共 HTML の基本構造は変わらないけれど、それぞれ id や class の付け方が変わってくる。</p>
<p>基本的な構造は以下の通り。</p>
<p><code>&lt;article&gt;
 &lt;h1&gt;heading&lt;/h1&gt;
 &lt;div&gt;&lt;/div&gt;
 &lt;div&gt;&lt;p&gt;text text text text text text text text text text text text text&lt;/p&gt;&lt;/div&gt;
&lt;/article&gt;
&lt;article&gt;
 &lt;h1&gt;heading&lt;/h1&gt;
 &lt;div&gt;&lt;/div&gt;
 &lt;div&gt;&lt;p&gt;text text text text text text text text text text text text text&lt;/p&gt;&lt;/div&gt;
&lt;/article&gt;</code></p>
<h3>独立型</h3>
<p>独立型はコンポーネント単位で CSS が完全に分離している。</p>
<p>コードの視認性も高く、追加・削除しても他の影響を受けることがない。</p>
<p>反面グラフィックデザインに高いレベルの計画性がなければ、ただ煩雑なだけのコードになってしまう。</p>
<h4>HTML</h4>
<p><code>&lt;article id=&quot;alpha&quot;&gt;
&lt;h1&gt;heading&lt;/h1&gt;
&lt;div class=&quot;box-a&quot;&gt;&lt;/div&gt;
&lt;div class=&quot;box-b&quot;&gt;&lt;p&gt;text text text text text text text text text text text text text&lt;/p&gt;&lt;/div&gt;
&lt;/article&gt;

&lt;article id=&quot;beta&quot;&gt;
&lt;h1&gt;heading&lt;/h1&gt;
&lt;div class=&quot;box-a&quot;&gt;&lt;/div&gt;
&lt;div class=&quot;box-b&quot;&gt;&lt;p&gt;text text text text text text text text text text text text text&lt;/p&gt;&lt;/div&gt;
&lt;/article&gt;</code></p>
<h4>CSS</h4>
<p><code>#alpha{
 background:#DDD;
 margin-bottom:20px;
 padding:10px;
 width:520px;
 overflow:hidden;
}
#alpha .box-a{
 background:#000;
 float:left;
 width:100px;
 height:100px;
}
#alpha .box-b{
 width:380px;
 float:right;
}
#beta{
 background:#EEE;
 margin-bottom:20px;
 padding:10px;
 width:820px;
 overflow:hidden;
}
#beta .box-a{
 background:#000;
 float:left;
 width:200px;
 height:100px;
}
#beta .box-b{
 float:right;
 width:580px;
}</code></p>
<h3>モジュール型</h3>
<p>モジュール型はコードを特定の色や余白などの単純なスタイルで分離し、その組み合わせで最終的な整形を行う。</p>
<p>拡張性が高く、組み合わせによって様々なスタイルがつくれる。</p>
<p>反面ひとつの変更でも影響範囲が大きく、ガイドラインを明文化し、それを徹底しなければ、コードの切り分けに一貫性がなくなってしまうため、返って混乱を招く恐れもある。</p>
<h4>HTML</h4>
<p><code>&lt;article class=&quot;w-520 gray mgb-20 pad-10 clearfix&quot;&gt;
&lt;h1&gt;heading&lt;/h1&gt;
&lt;div class=&quot;left black-box w-100 h-100&quot;&gt;&lt;/div&gt;
&lt;div class=&quot;right w-380&quot;&gt;&lt;p&gt;text text text text text text text text text text text text text&lt;/p&gt;&lt;/div&gt;
&lt;/article&gt;

&lt;article class=&quot;w-820 light-gray mgb-20 pad-10 clearfix&quot;&gt;
&lt;h1&gt;heading&lt;/h1&gt;
&lt;div class=&quot;left black-box w-200 h-100&quot;&gt;&lt;/div&gt;
&lt;div class=&quot;right w-580&quot;&gt;&lt;p&gt;text text text text text text text text text text text text text&lt;/p&gt;&lt;/div&gt;
&lt;/article&gt;</code></p>
<h4>CSS</h4>
<p><code>.clearfix{
 overflow:hidden;
}
.left{
 float:left;
}
.right{
 float:right;
}
.gray{
 background:#DDD;
}
.light-gray{
 background:#EEE;
}
.black-box{
 background:#000;
}
.mgb-20{
 margin-bottom:20px;
}
.pad-10{
 padding:10px;
}
.w-820{
 width:820px;
}
.w-580{
 width:580px;
}
.w-520{
 width:520px;
}
.w-380{
 width:380px;
}
.w-200{
 width:200px;
}
.w-100{
 width:100px;
}
.h-100{
 height:100px;
}</code></p>
<h3>拡張型</h3>
<p>拡張型はある意味で独立型とモジュール型のハイブリッドといえる。</p>
<p>基本を独立型で整形しつつ、それをモジュールで拡張していく。</p>
<p>拡張と再利用が容易で、バランスのとれた方法ともいえる。</p>
<p>反面依存関係が複雑なため、一部でも無計画になると、コード書いた当の本人ですら依存関係が分からなくなる恐れもある。</p>
<h4>HTML</h4>
<p><code>&lt;article class=&quot;unit-2col unit-mystyle-a&quot;&gt;
&lt;h1&gt;heading&lt;/h1&gt;
&lt;div class=&quot;box-a&quot;&gt;&lt;/div&gt;
&lt;div class=&quot;box-b&quot;&gt;&lt;p&gt;text text text text text text text text text text text text text&lt;/p&gt;&lt;/div&gt;
&lt;/article&gt;

&lt;article class=&quot;unit-2col unit-mystyle-b&quot;&gt;
&lt;h1&gt;heading&lt;/h1&gt;
&lt;div class=&quot;box-a&quot;&gt;&lt;/div&gt;
&lt;div class=&quot;box-b&quot;&gt;&lt;p&gt;text text text text text text text text text text text text text&lt;/p&gt;&lt;/div&gt;
&lt;/article&gt;</code></p>
<h4>CSS</h4>
<p><code>.unit-2col{
 margin-bottom:20px;
 padding:10px;
 overflow:hidden;
}
.unit-2col .box-a{
 background:#000;
 float:left;
 height:100px;
 width:30%;/*default value*/
}
.unit-2col .box-b{
 float:right;
 width:60%;/*default value*/
}
.unit-mystyle-a{
 background:#DDD;
 width:520px;
}
.unit-mystyle-a .box-a{
 width:100px;
}
.unit-mystyle-a .box-b{
 width:380px;
}
.unit-mystyle-b{
 background:#EEE;
 width:820px;
}
.unit-mystyle-b .box-a{
 width:200px;
}
.unit-mystyle-b .box-b{
 width:580px;
}</code></p>
<h2>弱点を補うアーキテクチャ</h2>
<p>それぞれに利点と欠点があるので、ガイドラインなどを用意してそれを補う仕組みをアーキテクチャに組み込む必要がある。</p>
<p>まあなんにせよ、万事環境変数に依存する以上、うまくいくときもあればうまくいかない時もある。けれど始めから何も考えなければ、まともな失敗すら出来ないのだから、うまくいかなかったとしても、それよりはいくらかマシなんじゃないかと思う。</p>]]>
        
    </content>
</entry>

<entry>
    <title>異文化</title>
    <link rel="alternate" type="text/html" href="http://vosegus.org/blog/2012/04/intercultural.html" />
    <id>tag:vosegus.org,2012:/blog//2.445</id>

    <published>2012-04-22T14:47:51Z</published>
    <updated>2012-04-24T16:32:09Z</updated>

    <summary>昔の家には電気がなかったから、当然夜になれば真っ暗だというのは想像できたけれど、...</summary>
    <author>
        <name>toshimitsu</name>
        
    </author>
    
        <category term="日記" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="lifelog" label="LifeLog" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="ja" xml:base="http://vosegus.org/blog/">
        <![CDATA[<p>昔の家には電気がなかったから、当然夜になれば真っ暗だというのは想像できたけれど、それよりもあの昼間の薄暗さには驚いた。</p>
<p>先日、大分県杵築市にある武家屋敷跡に行ってきた。</p>
<p>あの辺りは空襲をうけずにすんだらしく、高台の上に武家屋敷がのこっていて、その一角は土壁で囲まれた日本家屋の集まった雰囲気のある観光地になっている。</p>
<div><img alt="kitsuki_0.jpg" src="http://vosegus.org/blog/kitsuki/kitsuki_0.jpg" class="photo" /></div>
<p>土壁も修復したりしていなかったりで、ある部分は剥げかけていたりで中の構造が見えるなど、演出も細かい。</p>
<p>観光地観光地していないので、リアルな歴史的建築物感が生々しく感じられる。</p>
<p>武家屋敷は中に入ることも可能で、実際につかわれていたのだろう釜などもあって、そこで暮らしていたひとたちの生活も窺える。</p>
<div><img alt="kitsuki_0.jpg" src="http://vosegus.org/blog/kitsuki/kitsuki_1.jpg" class="photo" /></div>
<p>実際に行ってみるとよくわかるのだけれど、懐かしい日本の生活という感じはまるでない。</p>
<p>もう全くの異国に来たのと同じで、薪で火をおこす釜やら、やたらと小さく感じられる部屋のつくりやら、昼間なのに薄暗い採光やらで、むしろ幕末期の外国人の気持ちのほうがよくわかる。</p>
<p>とにかく、目に映るもの全てが珍しい。</p>
<p>特に庭はすごく奇麗だった。現代の公園はほとんど意味不明な遊具がいくつかあるばかりで、ノルマでもあるのかというようなデザインが多いけれど、さすが武家屋敷の庭は違った。</p>
<p>勿論、その庭の写真なら撮るのを忘れてきた。</p>]]>
        
    </content>
</entry>

<entry>
    <title>モーダルミックスデザイン</title>
    <link rel="alternate" type="text/html" href="http://vosegus.org/blog/2012/04/modal-mixed-design.html" />
    <id>tag:vosegus.org,2012:/blog//2.444</id>

    <published>2012-04-10T14:48:10Z</published>
    <updated>2012-04-10T15:54:50Z</updated>

    <summary>スマートフォンやらタブレットやら HTML5 やらで、そろそろ Web もモーダ...</summary>
    <author>
        <name>toshimitsu</name>
        
    </author>
    
        <category term="デザイン" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="ux" label="UX" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="ja" xml:base="http://vosegus.org/blog/">
        <![CDATA[<p>スマートフォンやらタブレットやら HTML5 やらで、そろそろ Web もモーダルミックスを独立した概念としてあつかうようなデザインになってきている。</p>
<p>もちろん Web サイトは未だ視覚、聴覚に訴えかけるだけだけれど、普通のひとがごく当たり前にスマートフォンを持ち歩き、タブレット端末がレストランのメニューになっているのだから、今までのデザインではすぐに時代遅れになってしまうのは目に見えている。</p>
<p>リアルではモーダルミックスデザインは当たり前に行われていて、例えば気の利いたレストランでは内装、盛りつけ（視覚）や、アンビエントな BGM （聴覚）、食事を取るのに相応しいサイズと座り心地の椅子（触覚）などで、モーダル（感覚）にコンセプトが伝わるようエクスペリンスデザインがされている。</p>
<p>触覚と Web 、味覚と Web のリアルミックスデザインが、人間のモーダルをアップデートする。</p>
<p>昔はテレビのチャンネルまわしてたのに、いつのまにか未来になっているんだな。</p>]]>
        
    </content>
</entry>

<entry>
    <title>CSS3 の Transition を試してみる</title>
    <link rel="alternate" type="text/html" href="http://vosegus.org/blog/2012/03/css3-transition.html" />
    <id>tag:vosegus.org,2012:/blog//2.442</id>

    <published>2012-03-29T07:43:18Z</published>
    <updated>2012-03-29T08:31:51Z</updated>

    <summary>平面の装飾だった CSS に奥行きと時間の概念が追加。使うことがなかったので使わ...</summary>
    <author>
        <name>toshimitsu</name>
        
    </author>
    
        <category term="CSS" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="css3" label="CSS3" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="ja" xml:base="http://vosegus.org/blog/">
        <![CDATA[<p>平面の装飾だった CSS に奥行きと時間の概念が追加。使うことがなかったので使わなかったけれど、そろそろ概念だけでも理解しておこうかと思ったので今更ながら試してみた。</p>
<p>Chrome でしか確認していないので Webkit 系じゃないブラウザではきっと動きません。</p>

<section id="flip">
<h2>裏返る</h2>
<div class="section-flip">
<div class="unit-flip">
<div><img src="/blog/img/amz_cybernetics.png" alt="人間機械論" width="100" height="100" /></div>
<div><img src="/blog/img/amz_machi.png" alt="まちづくりの新しい理論" width="100" height="100" /></div>
</div>
<div class="unit-flip" style="top:0px;left:100px;">
<div>Click</div>
<div>Click Reserve</div>
</div>
</div>
</section>

<section id="pop">
<h2>浮かび上がる</h2>
<a class="pop-open" href="#pops">Click</a>
<div id="pops" class="pop">
<div class="close"><a class="pop-close" href="#pops">Close</a></div>
<iframe src="http://www.w3conf.org/"></iframe>
</div>
</section>

<section id="vibrator">
<h2>震える</h2>
<div class="vibrator">Click</div>
</section>

<section id="bubble">
<h2>縮む</h2>
<ul class="bubble">
<li>Click</li>
<li>Click</li>
<li>Click</li>
</ul>
</section>

<section id="rotate">
<h2>回る</h2>
<div class="rotate">Hover</div>
</section>

<section id="overlap">
<h2>重なる</h2>
<div class="overlap">
<div id="rap_0">Click 0</div>
<div id="rap_1">Click 1</div>
<div id="rap_2">Click 2</div>
</div>
</section>

<section id="parallax">
<h2>視差</h2>
<div class="parallax">
<p>Click parallax parallax</p>
<p>Click parallax parallax</p>
<p>Click parallax parallax</p>
</div>
</section>

<script>
//<[CDATA[
$(function(){
	//vibrator
	$('.vibrator').bind('click',function(){
		if($(this).hasClass('start')){
			$(this).removeClass('start');
		}else{
			$(this).addClass('start');
		}
	});
	//parallax
	$('.parallax').bind('click',function(){
		if($(this).hasClass('start')){
			$(this).removeClass('start');
		}else{
			$(this).addClass('start');
		}
	});
	//overlap
	var z = -2;
	var pic = 0;
	var lap_flg = true;
	$('.overlap').bind('click',function(evt){
		if(!lap_flg){
			return false;
		}
		$('.overlap div').removeClass('turn');
		$('#rap_'+pic).addClass('turn');
		lap_flg = false;
		setTimeout(function(){
			$('#rap_'+pic).css('z-index',z);
			if(pic >= 2){
				pic = 0;
			}else{
				pic += 1;
			}
			z -= 1;
		},800);
		setTimeout(function(){
			lap_flg = true;
		},1500);
	});
	
	//bubble
	$('.bubble').bind('click',function(){
		if($('.bubble li:eq(0)').hasClass('shrink')){
			$('.bubble li').removeClass('shrink');
			$('.bubble li').addClass('grow');
		}else{
			$('.bubble li').removeClass('grow');
			$('.bubble li:eq(0)').addClass('shrink');
			setTimeout(function(){$('.bubble li:eq(1)').addClass('shrink');},100);
			setTimeout(function(){$('.bubble li:eq(2)').addClass('shrink');},200);
		}
	});
	
	//pop
	$('.pop-open').bind('click',function(){
		var target = $(this).attr("href");
		var pos = $(this).position();
		$(target).removeClass('pop-hide');
		$(target).addClass('pop-show');
		return false;
	});
	
	$('.pop-close').bind('click',function(){
		var target = $(this).attr("href");
		$(target).removeClass('pop-show');
		$(target).addClass('pop-hide');
		return false;
	});
	
	//flip
	$('.unit-flip').bind('click',function(){
		if($(this).hasClass('flip')){
			$(this).removeClass('flip');
			$(this).addClass('flip-reserve');
		}else{
			$(this).removeClass('flip-reserve');
			$(this).addClass('flip');
		}
		return false;
	});
	
});
//]]&gt;
</script>]]>
        
    </content>
</entry>

<entry>
    <title>基本性能</title>
    <link rel="alternate" type="text/html" href="http://vosegus.org/blog/2012/03/spec.html" />
    <id>tag:vosegus.org,2012:/blog//2.441</id>

    <published>2012-03-24T16:17:28Z</published>
    <updated>2012-03-25T16:11:44Z</updated>

    <summary>人間の使うものにはだいたい確保しないと困る以下の三つの基本性能というのがある。 ...</summary>
    <author>
        <name>toshimitsu</name>
        
    </author>
    
        <category term="随筆" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://vosegus.org/blog/">
        <![CDATA[<p>人間の使うものにはだいたい確保しないと困る以下の三つの基本性能というのがある。</p>
<ol>
<li>安全性</li>
<li>快適性</li>
<li>耐久性</li>
</ol>
<p>例えばブレーキが効かない車は恐ろしくて誰も乗りたがらないだろうし（安全性）、家賃は恐ろしく安いが、一晩中女のすすり泣く声の聞こえる部屋には誰も住みたくない（快適性）。数千万の借金をして一戸建てを買ったのはいいけれど、次の年には配管が腐って水が吹き出してきたのではたまったものでない（耐久性）。</p>
<p>そして上記の三つの基準をクリアした上で求められるものに意匠性がある。</p>
<p>機能か意匠かという議論は、そもそも基本性能をクリアしているという前提があって論じられるべきなのだけれど、肉体的な危険性がない商品などは、意匠ありきで出来ているものもある。</p>
<p>その中間にあるのがファッションデザインのようで、例えば意匠性は優れているが履いていると足が痛くなって仕方の無い靴というのがあったり、近代ヨーロッパで流行ったコルセットなども、腰を細く見せるために肉体を締め付け、過剰な強制を行った結果として内蔵を悪くしたこともあるとかいうはなしを聞いた気がする。</p>
<p>製品として未熟なものや、そもそも何処に危険性があり、何が不快なのかもわからない新しい製品などは、当然規制などもなく、経験としても蓄積されていないので、対応は後手々に回ることになる。</p>
<p>けれど一定の普及を経て産業としての成熟をみれば、業界自体が自浄作用を発揮してくる。業界団体をつくり、そこで暫定的な基本性能を定義し、団体に所属し、基本性能を満たすことで品質を確保して利用者の利便性を上げ、産業としての社会的な地位を確保しようという動きが産まれる。こういった動きの産まれない産業は衰退していくか、そもそも社会的な必要性の低い産業だと自ら表現しているのと同じだから、自然と社会全体からそのような扱いをうけるようになる。</p>
<p>Web にも当然基本性能というのはあるし、それらの業界全体での合意は暗黙のうちに形成されている部分もあるのだろうし、工業規格としてのアクセシビリティもある。これらを Google などは意欲的に発信しているのだけれど、制作会社などではあまりみない。</p>
<p>さておき基本性能を理解しているのかいないのかでは、品質という概念からして根底から違ってくるのだから、そろそろ基本性能の定義がされて、業界の外のひとたちにもわかるように発信されればいいなと思う。</p>]]>
        
    </content>
</entry>

<entry>
    <title>インフォメーションアーキテクチャ</title>
    <link rel="alternate" type="text/html" href="http://vosegus.org/blog/2012/03/information-architecture.html" />
    <id>tag:vosegus.org,2012:/blog//2.440</id>

    <published>2012-03-13T11:16:36Z</published>
    <updated>2012-03-14T04:40:13Z</updated>

    <summary>よく聞くけれどいまいち意味が分からない言葉は沢山ある。 例えばコンプライアンスや...</summary>
    <author>
        <name>toshimitsu</name>
        
    </author>
    
        <category term="Web とは何か" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="ia" label="IA" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="ja" xml:base="http://vosegus.org/blog/">
        <![CDATA[<p>よく聞くけれどいまいち意味が分からない言葉は沢山ある。</p>
<p>例えばコンプライアンスやフィーチャフォンのフィーチャ。<a href="/blog/2012/02/management-of-content.html">コテンツマネジメント</a>なんかも、コテンツマネジメントシステムと混同していたりする。</p>
<p>インフォメーションアーキテクチャも何年か前からよく聞いていたのだけれど、正直意味がよくわからなかった。というか断片的には理解できるのだけれど、なぜわざわざそれを独立した一つの概念として取り扱うべきなのかが理解できなかった。</p>
<p>それが最近やっと分かってきたので、せっかくなので具体的に考えてみる。</p>
<p>まずは例によって <a href="http://ja.wikipedia.org/wiki/%E6%83%85%E5%A0%B1%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3">Wikipedia</a> で調べてみると、以下のような事が書いてある。</p>
<blockquote cite="http://ja.wikipedia.org/wiki/%E6%83%85%E5%A0%B1%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3">
<dl>
<dt>インフォメーションアーキテクチャ</dt>
<dd>知識やデータの組織化を意味し、「情報をわかりやすく伝え」「受け手が情報を探しやすくする」ための表現技術である。 </dd>
</dl>
</blockquote>
<p>専門的な話なので、無垢のひとが、これだけ読んで理解できることは少ないと思う。</p>
<p>例えば <q>「情報をわかりやすく伝え」「受け手が情報を探しやすくする」 </q>というだけなら単に情報の整理と言った方が余計な混乱が生じずに済みそうだ。</p>
<p>もちろんそれだけを言っているわけではないので、さらに Wikipedia を読み進めていくと、<q>情報アーキテクチャという語は、情報管理および情報ツールの利用に関する専門的能力の集合体を表す</q>と書いてある。</p>
<h2>じゃあインフォメーションアーキテクチャを日本語にしてみる</h2>
<p>少し前に書いたとおり、ぼくは<a href="/blog/2011/12/architecture.html">アーキテクチャ</a>を物理法則だと解釈している。</p>
<p>なのでそれを何の芸もなくただ訳すと「情報の物理法則」になる。</p>
<p>さて、意味不明だ。</p>
<p>なのでもっと素直になってみよう。</p>
<p>アーキテクチャとは元来建築物のことか、あるいは建築様式の事をいう。</p>
<p>「情報の建築」。</p>
<p>少しイメージが具体的になってきた。</p>
<p>しかし情報を建てるとはどういうことなのだろう。</p>
<p>情報は目に見えて建ってるものじゃあないのでイメージが掴めない。なので、ほんとうに建っている建物から考えてみるといい。</p>
<h2>建物的に情報空間を考える</h2>
<p>建物には必ず用途がある。ひとが沢山集まることを想定した建物は入口を大きくして沢山のひとが同時に通れるようにする必要がある。エントランスを広く設ければそこでひとの流れは一旦止まるだろうし、逆に狭ければ自然と奥へ進んでいく。</p>
<p>仮に入ってすぐに大きな階段があるとすれば、その建物の重要な用途は二階にある可能性が高い。逆に小さい階段が奥にあるだけなら、その建物の二階はプライベートな空間なのだろう。</p>
<p>他にも階段の真ん中に手すりがあって二つの空間に区切られていれば、その階段は昇り降りするひとの数が共に多いため、昇る階段は手すりを中心にして入り口向かって左、下りる階段は逆、というような暗黙のルールづけをされているのかもしれない。</p>
<p>つまり建物の大きさ、区切り、物の位置には、全て意図がある。それはそこに集うひとたちの無意識に語りかけている。その結果としてひとびとは早足になったり、気持ちが落ち着いたり、おしゃべりになったりもする。</p>
<p>進んで欲しい方向があるのならそのように設計すればいい。単に暗い入り口を設けて明るい出口を用意するだけで十分な場合もある。</p>
<p>そして建物にはこのような意図があり、その意図に基づいて設計されているのなら「情報の建築」を理解するのは容易い。</p>
<p>伝えたい意図を伝えるため、進んでほしい方向へ導くため、階段をつくり、壁を張り、手すりを設け、情報を建てる。つまりこれがきっと、インフォメーションアーキテクチャの正体に相違ない。</p>]]>
        
    </content>
</entry>

<entry>
    <title>データドリブン</title>
    <link rel="alternate" type="text/html" href="http://vosegus.org/blog/2012/03/data-driven.html" />
    <id>tag:vosegus.org,2012:/blog//2.439</id>

    <published>2012-03-09T10:03:50Z</published>
    <updated>2012-03-10T16:13:19Z</updated>

    <summary>データはもうひたすら増えていくだけだから、いずれ人間の手を離れないといけない。 ...</summary>
    <author>
        <name>toshimitsu</name>
        
    </author>
    
        <category term="デザイン" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="social" label="Social" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="ja" xml:base="http://vosegus.org/blog/">
        <![CDATA[<p>データはもうひたすら増えていくだけだから、いずれ人間の手を離れないといけない。</p>
<p>つまりデータの変化が別のデータを駆動させるように世界を作り変えていかないと、世界はビットで溢れ返って、みんな溺れて死んでしまう。</p>
<p>じゃあデータドリブンな社会がどんなものかを、<a href="http://www.amazon.co.jp/gp/product/4877382313/ref=as_li_ss_tl?ie=UTF8&amp;tag=yagatekanashi-22&amp;linkCode=as2&amp;camp=247&amp;creative=7399&amp;creativeASIN=4877382313">シチズンセントリック</a>（市民中心）な電子政府のごく初期の段階のシナリオを例にして具体化してみる。</p>
<h2>データドリブンな引越し</h2>
<p>引越しをすると、ほうぼうに連絡をしないといけなくなる。</p>
<p>住民票から電気ガス水道、会社にも報告しないといけないし、放っておくと NHK あたりは二重で課金してくるので性質が悪い。</p>
<p>同じことをひたすら何度も繰り返すのは馬鹿げていると思いながらも、こればかりは仕方ないと思っていたのだけれど、シチズンセントリックな電子政府に変われば事情が変わってくる。</p>
<p>つまり現在の電子政府はまだごく原始的な段階で、それは今までの役所の仕事の一部を情報システムに置き換えただけで、コンセプトと呼べるものはないらしい。</p>
<p>さておき、シチズンセントリックな電子政府の日本で引越しをすると、手続きは一度で済む。</p>
<p>役所に足を運ぶ必要すらない。ネットワーク端末に自分の共通番号と登録してある生体情報を入力し、住所の情報を書き換える。</p>
<p>すると住民票はもとより、電気ガス水道、固定電話に携帯電話、契約している保険の会社や NHK にまで、住所の変更が適用される。</p>
<p>住所変更に伴う各種手続きは、必要な認証が通知され、許可していけば全てが終わる。</p>
<p>住所のデータがトリガになって、関連する全ての情報が更新された。</p>
<p>去年引っ越しをしたぼくはこれを書いている間に、そういえば保険会社に住所変更連絡をしていないことに気づいたが、近い将来こんなことはなくなる。</p>
<h2>データドリブンなデザイン</h2>
<p>組織はもとより、個人ですら扱う情報量は増えるばかりだから、データの連携、対話の問題はそれに気づいた時にはもう可及の課題になっていた。だからこれからは、いろんなレベルでのデザインがデータドリブンになってくるはず。</p>]]>
        
    </content>
</entry>

<entry>
    <title>データは誰のもの</title>
    <link rel="alternate" type="text/html" href="http://vosegus.org/blog/2012/03/whose.html" />
    <id>tag:vosegus.org,2012:/blog//2.438</id>

    <published>2012-03-04T10:45:14Z</published>
    <updated>2012-03-04T16:09:50Z</updated>

    <summary>電気・水道の使用量の可視化や、自家発電した電力のビジュアライズなど、最近はたくさ...</summary>
    <author>
        <name>toshimitsu</name>
        
    </author>
    
        <category term="随筆" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="think" label="Think" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="ja" xml:base="http://vosegus.org/blog/">
        <![CDATA[<p>電気・水道の使用量の可視化や、自家発電した電力のビジュアライズなど、最近はたくさんの変化がデータとして蓄積されている。</p>
<p>データはひとつだけを見ていても有意義な情報は得られないから、文脈をよみ、蓄積した複数のデータと比較し、一ヶ月、一年を通じての変化を追っていくことで役に立ってくる。</p>
<p>そうやって蓄積されたデータはいろいろな発見をさせてくれるんだろうけれど、ところでそのデータは誰のものになるのだろう。</p>
<p>例えばもし、ぼくの部屋の電気の一年分の使用量の変化をデジタルデータで欲しいといえば、電力会社はそれに応じてくれるんだろうか。</p>
<p>あるいは電気とガスの使用量を比較したい場合、個人のデータを自由に比較することは可能なんだろうか。</p>
<p>もちろん、そういったデータは公共の利益のために利用されるべきだろうから、個人情報のような意味での権利の主張に意味はないにしても、せっかくデータがあるのなら個人にも利用可能になって欲しい。</p>
<p>他にも納税額や医療費、年金など、もっと Web をつかって状態にアクセスできるしくみがあれば意識に変化を起こせるものはたくさんある。</p>
<p>個人の情報を一元的に管理するためには共通番号の導入が不可欠なので <a href="http://www.yomiuri.co.jp/editorial/news/20120219-OYT1T00787.htm">2015 年 1 月</a>までは望めないのだろうけれど、その管理された情報はどこまでぼくらに開示されて、どのような形で利用できるのだろう。</p>]]>
        
    </content>
</entry>

<entry>
    <title>コンテンツのマネジメント</title>
    <link rel="alternate" type="text/html" href="http://vosegus.org/blog/2012/02/management-of-content.html" />
    <id>tag:vosegus.org,2012:/blog//2.437</id>

    <published>2012-02-26T10:52:46Z</published>
    <updated>2012-03-13T12:45:57Z</updated>

    <summary>そんなわけで、確かなものなど確かに無い。と言い切ってみた。 これは簡単に言うと意...</summary>
    <author>
        <name>toshimitsu</name>
        
    </author>
    
        <category term="Web とは何か" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="cms" label="CMS" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="ja" xml:base="http://vosegus.org/blog/">
        <![CDATA[<p>そんなわけで、<a href="/blog/2012/02/content-management.html">確かなものなど確かに無い</a>。と言い切ってみた。</p>
<p>これは簡単に言うと意味は認識する主体によって変化するし、その主体も時間や置かれた文脈に拠って解釈を変更するので、意味とは常にふらふらしているというような事をいいたかった。</p>
<p>仏教的に言えば諸行無常、色即是空。短くなって便利だ。</p>
<p>ちなみに虚無と無常は全く違う。例えば人類が滅んでも宇宙が消えても、それはただ無いという状態になるだけで、その無いという状態もまた無常なので、いずれなにかの拍子に在るようになるかもしれないし、在ると無いとは全く別の状態に変化するのかもしれないということだ。だから仏教には永劫はあっても永遠という概念はない。今でこそ否定的な印象もあるけれど、飢餓や病気、災害リスクが高い時代には、辛いことも一生続く訳じゃないという肯定的な解釈も成り立つ。</p>
<p>まあどうでもいいのだけれど。</p>
<p>認識主体（ターゲット）を明らかにしてその主体に応じた意味を見いだして概念を最適化するというのは普通のデザインプロセスなのでさておき、コンテンツマネジメントについてもっと考えてみる。</p>
<p>マネジメントされるコンテンツは最終的には八方美人にならないといけないはずだ。しかもそれでいて確固たる自分を持っていて欲しい。</p>
<p>ここでいう八方美人さとはあれだ。知的で無邪気で機知に富んだ会話をし、男をたてるが姉御肌、昼と夜とは別の顔で、愛され上手で愛し上手。家では優しい母親で、一歩外に出ればみんなの憧れ。ある時にはまるで処女のようで、時には薔薇の似合う娼婦のように、というような、自己矛盾した生き物であって欲しいということだ。</p>
<p>つまり対話する人間に応じて変わる。けれどもそれは、ただみんなにいい顔をしてるわけじゃない。それはその人にとって特別ないい顔でないと困る。最小公約数ではなくて、そのひとのためだけの素数だ。</p>
<p>まあ素数という表現が的確なのかは分からないけれど、最小公約数なんて言葉を使ったので、同じ数の概念で特別さを表したかった。</p>
<p>この辺は Google がプライバシーポリシーの統合で個人の趣向をまるっと分析してくるらしいので、これから徐々に可能性として見えてくるのかもしれない。</p>
<p>でもよく考えたら最終的なプレゼンテーションはコンテンツマネジメントというよりはコンテンツの表現のはなしなので、あんまり関係ない気もする。</p>
<p>コンテンツのマネジメントに、コンテンツをつくることも含まれるのかは、文脈と規模に依存するのだろうけれど、理想的にはつくるのではなく、管理する仕組みの洗練と運用になるんだろう。</p>
<p>じゃあ次は<a href="/blog/2012/03/information-architecture.html">インフォメーションアーキテクチャ</a>について考えてみる。</p>]]>
        
    </content>
</entry>

<entry>
    <title>コンテンツマネジメント</title>
    <link rel="alternate" type="text/html" href="http://vosegus.org/blog/2012/02/content-management.html" />
    <id>tag:vosegus.org,2012:/blog//2.436</id>

    <published>2012-02-22T10:59:16Z</published>
    <updated>2012-02-26T13:04:51Z</updated>

    <summary>概念は変化する。仕事だって変わる。 デバイスやプラットフォームの多様化で、生のコ...</summary>
    <author>
        <name>toshimitsu</name>
        
    </author>
    
        <category term="Web とは何か" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="cms" label="CMS" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="ja" xml:base="http://vosegus.org/blog/">
        <![CDATA[<p><a href="/blog/2012/02/interactive-content.html">概念は変化する</a>。仕事だって変わる。</p>
<p>デバイスやプラットフォームの多様化で、生のコンテンツやデータ中心の設計手法がいろいろ考えだされている。</p>
<p>ただの Web アプリケーションとしての CMS ではなくて、言葉のままのコンテンツマネジメントの必要性が増してきた。</p>
<p>けれどそもそもコンテンツとは何だろうか。データは粒度の細かいものなので分かり易いけれど、コンテンツというのは定義が曖昧すぎてよくわからない。調べてみると Wikipedia には「情報内容」と書かれている。では、と思い調べてみると、情報の項目には「あるものごとの内容や事情についての知らせのこと」と書いてある。これでは言葉を額面道りに解釈すれば、堂々巡りになってしまう。</p>
<p>じゃあさらに掘り下げて、内容とは何だろうか。内容とは、情報の意味のことを指す。</p>
<p>さて、では意味とは何だろう。</p>
<p>コンテンツをマネジメントしようと思えば、意味の意味をしらないといけないはずだ。何故ならコンテンツとは情報の意味だからだ。</p>
<p>そして情報の意味は情報の内容のこと言っているのだから、意味が何であるのかを理解していないと、何やら頭がこんがらがってくるじゃないか。</p>
<h2>意味の意味</h2>
<p>意味は認識できる記号があって、その記号に対する理解としてしか存在しない。</p>
<p>有形無形に拘らず、それがあるという認識があって、その認識されたものにたいする解釈として意味が付いている。</p>
<p>「意味がない」という言い方があるけれど、それは対象の使いみちがない、役に立たないという事を言いたいのだろうから、正確には「意義」がないといった方が適当じゃなかろうか。</p>
<p>「意味がわからない」というのは言葉のままで、それが何か理解できないということになる。つまり物があっても、意味を付加することが出来ない状態があるという事になる。</p>
<p>さて、では意味の意味とは何だろう。つまり意味という記号を解釈し、それをさらに意味的な記号として再解釈すると、一体全体何になるのだろう。</p>
<p>いや、全く自分でも質問の意味が分からないので、もっと具体的な意味での意味の意味とはなにかという質問にしてみないと困ってしまう。</p>
<p>つまり「鳥は何故鳥なのだろう？」とか「あいうえおは何故あいうえおなのだろう？」といったような、世界の意味を解釈し始めたばかりの子供がしてくる禅問答の類いのようにだ。</p>
<p>そういえば、ぼくが今より 20 kg 瘦せていた十代の頃、夜中に友達が「自分が何故生きているのかを考えだすと、暗闇の中に落ちていくようで不安になり、眠れなくなる」という類の事を言っていた。</p>
<p>また随分とロマンチックな悩みを抱えているんだな。と思ったけれど、ぼくはそういった事では悩んだことがないので、何も応えなかった。</p>
<p>さて、上の三つの質問は結局どれも同じことを聞いている。</p>
<p>つまり、意味のないものに、どんな意味があるんだろう？ ということを聞いている。</p>
<p>なぜならさっき「意味がわからない」の例で出した通り「物があっても、意味を付加することが出来ない状態がある」からだ。</p>
<p>いやしかし、それは意味を知らないだけで、そこには真実の意味があるという解釈も当然ある。けれどそれを証明するためには、唯一無二の真実の意味をみつけてこないといけないし、逆に無いという証明も同じ理由で出来ないので、結局は同じことになる。</p>
<p>意味とはひたすら恣意的に付けるだけのもので、あるものじゃない。意味があると思っているものは、社会的、体験的なものによって、自分で勝手に意味付けしたものでしかない。</p>
<p>これで三つの問題全てにすっきりと応えることができる。</p>
<h2>コンテンツの意味</h2>
<p>じゃあコンテンツマネジメントに戻ると、コンテンツの意味を探すと酷い目にあうに違いない。きっと暗闇に落ちて戻ってこれなくなる。</p>
<p>コンテンツの意味は付ければいい。自分たちにとって一番都合のいい解釈をして、時間が経ってそれに即さなくなれば、また変えればいい。</p>
<p>意味が付いて、その意味をみんなで共有すれば、やっとこさデータドリブンなデザインの準備が出来る。</p>
<p>でもその前に、<a href="/blog/2012/02/management-of-content.html">コンテンツマネジメントとは何だろう</a>。</p>]]>
        
    </content>
</entry>

<entry>
    <title>インタラクティブコンテンツ</title>
    <link rel="alternate" type="text/html" href="http://vosegus.org/blog/2012/02/interactive-content.html" />
    <id>tag:vosegus.org,2012:/blog//2.435</id>

    <published>2012-02-20T05:25:51Z</published>
    <updated>2012-02-22T12:19:59Z</updated>

    <summary>そんなわけで、現在 Web コンテンツは大きく分けると二つある。 ひとつは読むた...</summary>
    <author>
        <name>toshimitsu</name>
        
    </author>
    
        <category term="Web とは何か" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://vosegus.org/blog/">
        <![CDATA[<p><a href="/blog/2012/01/interaction">そんなわけで</a>、現在 Web コンテンツは大きく分けると二つある。</p>
<p>ひとつは読むための文書、もうひとつはそれ自体から何かを発見したり、楽しんだりするためのインタラクティブコンテンツ。</p>
<p>数年前ならただ Flash でつくってさえいればインタラクティブコンテンツだと思われていたけれど、最近じゃ様子が違う。</p>
<p>概念が成熟してきている。じゃあ今現在、インタラクティブコンテンツと呼ぶに値するものはどういったものなのかを考えてみる。</p>
<p>まず、インタラクティブコンテンツとは、ただ動いているだけのものではない。視覚効果、動きとしての装飾や、省スペース化のためのガジェット的な UI があるだけのものは、読むための文書になる。</p>
<p>あくまでそのコンテンツ自体が知的な発見や喜びにつながる目的でつくられたものでなければならない。</p>
<p>例えば本をめくるという視覚効果のついただけのコンテンツは、操作はインタラクティブではあっても、コンテンツとしてはインタラクティブではないので、読むための文書になる。逆に Facebook 等は視覚効果としての遊びは限られているけれど、コンテンツの目的自体はインタラクティブなので、インタラクティブコンテンツになる。</p>
<p>たとえば普通の企業サイトやショッピングサイトにただ「いいね」ボタンを設置しているだけのサイトがある。けれどもこれはインタラクティブコンテンツとは呼び難い。読むための文書にソーシャルメディアへのリンクがついただけだ。ボタンが押された結果、インタラクティブの波及を産むのはソーシャルメディアであって、ボタンのあるサイトではない。</p>
<p>ショッピングサイトは Web アプリケーションだからそれだけでインタラクティブかというとそうでもない。例えばスーパーに置いてある通販雑誌はインタラクティブコンテンツではないから、ただ物を売る仕組みだけつくっても別にインタラクティブコンテンツではない。</p>
<p>通販雑誌にはこの雑誌に載っている商品を買ってほしいという明確なインタラクションがある。</p>
<p>けれど読者がそこに FAX を送るなり、電話をかけるなりして商品を買った時点で通販雑誌としての目的は達成される。</p>
<p>あとはセールのお知らせの DM 等が送られてくるくらいだろうか。</p>
<p>ちなみに人間が人間に何かを伝えようとすればそれは全てインタラクションだし、その結果相手が何か反応すればインタラクティブだといえる。</p>
<p>けれどここで問題にしているのはコンテンツなので、インタラクティブというのはコンテンツのアーキテクチャの問題になる。</p>
<p>コンセプトとしてインタラクティブというのは容易い。明文化してしまえばいいし、それこそ「いいね」ボタンがあればもうインタラクティブだという解釈も成り立つ。概念では個々人の解釈の問題になるので、真偽は別にして、話としての論理に一見矛盾がなさそうで相手が納得したのなら、それはそうだということになる。</p>
<p>ところがアーキテクチャとしてのインタラクティブは難しい。なぜそれが必要で、それがあることによってコンテンツ自体にどういう効果が産まれるのか、その結果何が起こるかまでは分かるわけもないけれど、少なくとも打ち出したボールがどの方向の壁にぶつかるとどういう角度でかえってくる（きて欲しい）ということは考えていないといけない。</p>
<p>インタラクティブコンテンツの相互作用は、ユーザ同士が起こす必要はないし、ユーザと企業（の代表）でなくてもいい。つまり人間同士である必要はない。もちろんユーザは人間でなければ（ AI の実験でもない限り）意味はない。</p>
<p>コンテンツそれ自体がユーザに対して働きかけ、ユーザがコンテンツとやりとりをし、結果ユーザの心に変化が起これば、それはインタラクティブコンテンツと呼べる。</p>
<p>長々と書いたけれど、ぼくが Web の仕事をはじめた頃は、ユーザインターフェースにインタラクティブな要素があるものをインタラクティブコンテンツと呼んでいたのだと思う。けれど、その言葉のもつ概念は変化して、コンテンツとしてのインタラクティブ性に置き換わってるんだなあと。</p>
<p>じゃあ次は、<a href="/blog/2012/02/content-management.html">コンテンツマネジメント</a>について考えてみる。</p>]]>
        
    </content>
</entry>

<entry>
    <title>地域情報基盤としての Web の活用</title>
    <link rel="alternate" type="text/html" href="http://vosegus.org/blog/2012/02/place.html" />
    <id>tag:vosegus.org,2012:/blog//2.434</id>

    <published>2012-02-11T14:16:52Z</published>
    <updated>2012-02-13T10:07:21Z</updated>

    <summary>もう一月以上ぷーなので、なにか社会のお役に立てる事をと思い、ひとつ、新しい需要を...</summary>
    <author>
        <name>toshimitsu</name>
        
    </author>
    
        <category term="Webマーケティング" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="semantic" label="Semantic" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="ja" xml:base="http://vosegus.org/blog/">
        <![CDATA[<p>もう一月以上ぷーなので、なにか社会のお役に立てる事をと思い、ひとつ、新しい需要を産み出せるんじゃないかというプランを考えてみた。</p>
<p>コンセプトは、地域情報基盤としての Web の活用。</p>
<p>位置情報をコンテンツ化する仕組みには Google Place が既にあるけれど、恐らくはまだ実験段階なのだろうし、表現が限られている上に、情報は Google の資産としてもっていかれる。もちろん、検索結果に地図情報と共に出てくるらしいので、場所と業種の組み合わせによっては、勘違いした SEO よりもよほど効果があるのは間違いない。</p>
<p>さておき問題は表現の自由度、なによりそれ以降の再利用からなにからを全部 Google に持っていかれるという点にある。</p>
<p>検索できることは素晴らしいのだけれど、情報の在り方がパブリックでないので、蓄積される程一企業の優位性が増し、後から来たものは例え素晴らしいプランを持っていたとしても、お伺いを立てるか、一から収集しなおす必要が生じるので、なにやらどうも不健全にみえる。</p>
<p>じゃあどうするのかといえば、答えは簡単、普通の HTML にすればいい。普通に公開されている HTML が位置情報や業種と明確に結びつけて登録されていく仕組みがあればいい。</p>
<p>例えば schema.org の <a href="http://schema.org/LocalBusiness">LocalBusiness</a> に則ってマイクロデータでマークアップをする。それを登録するようにすれば自由度は格段に違ってくる。公開されている HTML なので他の検索エンジンにもインデックスされる。</p>
<p>しかし当然そんなことは Place 以前からあった構想だし、それだとどうしてもうまくいかない部分があったので Place という仕組みをつくったのだろうけれど。</p>
<p>しかし、文書内容表現としての HTML5 と共通語彙としての schema.org 、そして各種の公開された地図情報と基盤は整ってきている。人材の育成という面からみても Web デベロッパはたくさんいる。適当な仕様とバリデータがあれば HTML ベースでのデータベース形成も現実的なプランになってきた。</p>
<p>あとは解析機と解析後のデータを意味的に登録していく仕組みと検索のためのインターフェース、検索を実際に行うための Web アプリケーションを作成すればいい。</p>
<p>なので問題はその仕組みを誰がつくるのか、と、その情報に対する保証システム（その場所にそれがあるという程度の）しかないように思う。</p>
<p>自治体等はそういった観光資源や商業施設の利用を活性化するための地域情報基盤をつくりたがっているかもしれない。それに自治体なら保証システム等も登記に基づくなりして信用度の高いものを形成できそうだ。</p>
<p>なにより公共の情報資源を提供するなら政府や自治体、もしくはそれに準ずる機関、あるいは非営利団体でなければ都合が悪い。</p>
<p>仮に自治体がやってくれるなら、あとは蓄積された情報に対してのクエリとレスポンスを公開すればいい。</p>
<p>そうすればカーナビなりパソコンなり携帯電話なり、好きなデバイスで利用できるようになる。</p>
<p>ひとつつくってしまえば、それを再利用する形で他の自治体でも活用できる。そうやって共通のセマンティクスで広がっていけば、地域毎ではなく、横断検索も可能になってくる。</p>
<p>共通のスキーマに基づけば検索精度の高いシステムができあがる。検索精度の高いインターフェースで地域規模の横断的なコンテンツを発信すれば、利便性の高さから観光客は利用してくれるだろうし、小さな会社や店舗もコンテンツをつくろうという気になる。主体的な情報発信によって地域の魅力も今までよりもっと表現されるだろうから観光客も増える。やぁ、いい事づくめじゃないか。</p>]]>
        
    </content>
</entry>

</feed>

