<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>underconcept &#187; ui</title>
	<atom:link href="http://www.underconcept.com/blog/archives/tag/ui/feed" rel="self" type="application/rss+xml" />
	<link>http://www.underconcept.com/blog</link>
	<description>概念未満 - 長谷川敦士</description>
	<lastBuildDate>Thu, 12 Jan 2012 02:35:56 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=</generator>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>機会損失的側面の計量方法</title>
		<link>http://www.underconcept.com/blog/archives/458</link>
		<comments>http://www.underconcept.com/blog/archives/458#comments</comments>
		<pubDate>Fri, 03 Oct 2008 01:01:45 +0000</pubDate>
		<dc:creator>Atsushi</dc:creator>
				<category><![CDATA[UX]]></category>
		<category><![CDATA[HCD]]></category>
		<category><![CDATA[IA]]></category>
		<category><![CDATA[ui]]></category>

		<guid isPermaLink="false">http://www.underconcept.com/blog/?p=458</guid>
		<description><![CDATA[ユーザーインターフェイス、情報アーキテクチャ設計において、ここのところ機会損失の影響について考えさせられることが続いている。
一般に、ユーザーインターフェイスは必要な要件を積んでいっただけでは、いっぱいいっぱいになってしまい、飛行機の操縦席のようになってしまう。
最近では飛行機の操縦席も統合化されているようだが、とはいえ、エキスパートにはやはり物理的に計器が並んでいる方が「使いやすい」ことが多い。
しかしながら、初めて使う人、長期間にわたって使っているがコミットが低い人、などには、そういったいっぱいいっぱいインターフェイスは、どれからつかってよいかわからない、なにがなにかわからない、といった結果となってしまう。
ちなみにこれを最近「インターフェイスの共倒れ問題」と呼んでいる。
この問題自体はかれこれもう20年くらい語られてきていると思うが、じゃあ、どこまで単純化すればいいの、というポイント、（できるだけ）客観的なこの部分を評価するための指標、といったものをまだ見つけられていない。
おそらく安藤昌也氏の提唱した「長期的ユーザビリティ」の観点、インターフェイスの最低限の教示要件の観点、安全性能の観点（緊急停止とか、ミュートはダイレクトにやる必要がある、とか）、などの要件が足しあわされるのだと思うが、どうもそれだと通り一遍でつまらない。
最近のHCI関係ではそういったあたりも研究されていたりするのかな？
どういった分野を参照すればよいか、ご存じの方いたら教えてください。
]]></description>
		<wfw:commentRss>http://www.underconcept.com/blog/archives/458/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>ペルソナ法と塩野七生氏</title>
		<link>http://www.underconcept.com/blog/archives/453</link>
		<comments>http://www.underconcept.com/blog/archives/453#comments</comments>
		<pubDate>Sun, 21 Sep 2008 07:11:26 +0000</pubDate>
		<dc:creator>Atsushi</dc:creator>
				<category><![CDATA[memo]]></category>
		<category><![CDATA[persona]]></category>
		<category><![CDATA[ui]]></category>
		<category><![CDATA[塩野七生]]></category>

		<guid isPermaLink="false">http://www.underconcept.com/blog/?p=453</guid>
		<description><![CDATA[ペルソナ・シナリオ法という言葉がはやっている。
ペルソナ法とは簡単に言ってしまうと、デザインをするとき、一般的でない、具体的な利用者をイメージせよ、という方法。
先日もそういったセミナーを開催したが（すいませんQ&#38;Aの結果はもうじきこの場でお答えします）、その際いつも、「ペルソナ法だとその人向けだけに特化されてしまうのではないか？」という趣旨の質問をいただく。
毎回「そういうものではなく、具体的に対象者を想定することで企画が具体的になる、ということを意図しているんです」という返事をしているのだが、たまたま読んでいた塩野七生さんの「男たちへ」にそのものずばりの解答が載っていた。
（略）ここには、創作活動のカギの一つが見事に言いつくされている。（略）その私でも書くときは、読者は頭になく、眼の前の担当編集者に向かって書く。彼を、でなければ彼女を、うならせてみたいという思いだけで書く。なぜなら、それが上手くいけば、その向こうにいる不特定多数の読者にも自然に通じる、と確信しているからである。（太字は傍点部）
男たちへ―フツウの男をフツウでない男にするための54章 (文春文庫)
とまあ、そういうわけなんです。
]]></description>
		<wfw:commentRss>http://www.underconcept.com/blog/archives/453/feed</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>TC協会シンポジウムにむけて</title>
		<link>http://www.underconcept.com/blog/archives/448</link>
		<comments>http://www.underconcept.com/blog/archives/448#comments</comments>
		<pubDate>Sat, 02 Aug 2008 07:39:18 +0000</pubDate>
		<dc:creator>Atsushi</dc:creator>
				<category><![CDATA[IA]]></category>
		<category><![CDATA[TC]]></category>
		<category><![CDATA[ui]]></category>
		<category><![CDATA[UX]]></category>

		<guid isPermaLink="false">http://www.underconcept.com/blog/?p=448</guid>
		<description><![CDATA[ウェブサイトなどのデザインにおいて、機能（裏側）とユーザーインターフェイス（触れるところ）のデザインは通常別に職能を持った人が行い、フェーズとしても分かれている。
Linuxに必要なのは見た目か &#8211; コデラノブログ３
さて、LinuxにMacOSのような見栄えが必要かと言えば、うーんまあ今ぐらい頑張ってればいんじゃない? と思う。実際に使うのはアプリケーションだったりオンライン上のサービスだったりするわけだから、デスクトップやファイルのアイコンなどは、既存OSのい いとこ取りをして使い勝手が良ければ、それで十分だろう。
それよりも、ちょっと使い勝手を変えたり、ツールを入れたりするときに、やっぱり10年経ってもsudoしてコマンド打ち込んだり、エディタで設定 ファイル開いて書き直すみたいなことになっている。多くの人を取り込もうと思うのならば、この辺をGUIで何とかした方がいい。
OSの動き全体をコーディネートする人がいて、その人のポリシーを実現しようとするような集団が後ろについているような状態、つまり会社内の命令系統のような形でチームが固定化されないと、なかなかすべてをGUIでデザインするのは難しい。
そのあたりが、多くの推進力を有志のプログラマ集団に依存しているGNU/Linuxというものが構造的に抱え続けている問題だと思う。
この融合については、いくつか方法を試したり、検討がなされていたりしている。
昨日、テクニカルコミュニケーター協会（TC協会）シンポジウムでのパネルディスカッションの事前打ち合わせのために、TC協会理事の高橋さん、HCD-Net機構長の黒須さん、ソシオメディアの篠原さん、テクニカルライターの高橋さんなどとミーティングをしてこのテクニカルライティング業界でも同じようなことが起きていることに気づいた。
テクニカルライティングは、通常「マニュアル執筆」という形をとることが多いが、これはわりと後工程として製品私用ができあがってから、その説明書、という形で書かれる、ことが多いようだ。
が、いま情報プロダクトを企画するとき、「どう使えるのか」というメッセージは、説明書で説明するものではなく、機器自体に埋め込まれていなければならない（あるいは箱に書いてある、とかでもいいかもしれないけど）。
この部分にテクニカルライティングの専門家が関与していない、できていない、というのは大変もったいない。
「テクニカルライティングの専門家」がどこからどこまでの領域の技能を指すのかは定義が難しいような気がするが、そこが明らかになれば、サービスや製品の企画・設計の段階にもっと関与できるようになると思う（というか、参加していただきたいです）。
若干はしょり気味で書いたのでわかりにくいですが、今後深掘りする必要があるテーマに思う。
]]></description>
		<wfw:commentRss>http://www.underconcept.com/blog/archives/448/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Symbian vs. Andoroid (and iPhone)</title>
		<link>http://www.underconcept.com/blog/archives/438</link>
		<comments>http://www.underconcept.com/blog/archives/438#comments</comments>
		<pubDate>Wed, 25 Jun 2008 17:09:22 +0000</pubDate>
		<dc:creator>Atsushi</dc:creator>
				<category><![CDATA[concept]]></category>
		<category><![CDATA[Andoroid]]></category>
		<category><![CDATA[Apple]]></category>
		<category><![CDATA[google]]></category>
		<category><![CDATA[iPhone]]></category>
		<category><![CDATA[Nokia]]></category>
		<category><![CDATA[Symbian]]></category>
		<category><![CDATA[ui]]></category>

		<guid isPermaLink="false">http://www.underconcept.com/blog/?p=438</guid>
		<description><![CDATA[NokiaはSymbian OSのSymbian Limitedを買収すると発表した。
これに伴い、AT&#38;T、LG、Motorola、NTTドコモ、Samsung、Sony Ericsson、STMicroelectronics、Texs Instruments、VodafoneとNPO Symbian Foundationを設立することを発表した。
Nokia to acquire Symbian Limited to enable evolution of the leading open mobile platform
http://www.nokia.com/A4136001?newsid=1230415
これに対して、The Wall Street JournalはGoogleのAndroidの携帯電話への搭載の遅れを記事にしている。
Google&#8217;s Mobile-Hnadset Plans Are Slowed
http://online.wsj.com/article/SB121418837707895947.html
記事によると、今年後半に発売予定だったAndroid搭載携帯電話は第四四半期まで発売されないとのこと。
Googleと30社のパートナーによるアナウンス、という書き方をしているが、T-MobileなどのAndoroid搭載機を発売予定だったキャリアとメーカーはリリーススケジュールの調整に苦労している、とのこと。
ドコモはOSにAndoroidを採用するんじゃなかったっけ？
ＮＴＴドコモ、携帯ＯＳ簡素化発表
http://www.yomiuri.co.jp/net/news/20080428nt0b.htm
（もっと長い記事があったのだが、削除されている）
アメリカではいろいろな端末が入り乱れているが、イギリスでは街を歩いているとみなNokiaだった。
４年くらいSymbian S60端末を使ってきているがSymbian携帯の最大の使い勝手（この場合、長期使い勝手：Long Term Usability）上の課題は、アプリケーションのマルチタスク切り替えではないかと思う。
S60では、「アプリケーション立ち上げ」の概念が重要で、一度立ち上げたアプリケーションは「切り替え」で移動、さっきまでの動作を引き継ぐことができるが、これを覚えていないとうまく使いこなせない。
また、各アプリケーションの中の振る舞いはアプリケーション依存なので、たとえばブラウザはタブのように複数ウインドウを立ち上げられるが、メールは「書きかけ」バッファは一つで、複数書きかけられない（「Draft」フォルダに入れればできるけど）。
もちろん、こんな面倒なことを考えずとも使うことはできるが、たとえばメールからURLをクリックしたとき、ブラウザのメールアドレスをクリックしたとき、Google Searchアプリの検索結果への遷移等、アプリ連携があるときの振る舞いは挙動不審なことが多い。
また、致命的なのは、ボタン操作で、上記の「アプリ切り替え」は「メニューボタン長押し」なので、これは使いこなせている人、アプリケーション概念を理解している人にしかうまく使えないだろう。
iPhoneではこの問題を「操作ボタンは一つ」という方法で解決している。
ユーザーは別アプリに移る際は常に「HOME」ボタンを押すしかなく、このとき立ち上がり済みかどうかはまったく意識する必要もなく、むしろ通常は意識できない。
操作上もすでに立ち上がっているアプリでは直前までの振る舞いが継承されるが、特に立ち上がり時間等で意識することはまずなく、自然で違和感がない。
iPhone 3Gによる黒船襲来に対して、日本では「デザイン優先携帯」としての扱いを行っているように見えるが、さすがにこういった「UIの基本文法」に関してのクオリティはAppleの企業資産として生かされている。
これは、開発プロセス、評価手法、設計のツール、関与するスタッフの種類、どの段階でだれが口を出せるかという文化、どの程度リサーチやプロトタイピングに時間を費やしそれらを前提にするか、ユーザーテストの実施とタイミングといった要素の有機的な組み合わせ方の、勘所や雰囲気といったもので作られるものだ。
Appleの内部事情はよく知らないが、たとえばどの程度の開発チームでどの程度のタスクを実施することが最適か、という経験則もここには含まれる。
経験された方はわかると思うが、モデル作りや、コアなコンセプト作りにおいては、あまり体制が大きいとなかなかプロジェクトが進まない。この場合はリサーチやプロトタイピングに最低限のスタッフと、意志決定に必要なキーパーソンのみの関与、がベストな体制となる。
このApple社のアドバンテージはとても重要であり、今後はPC関係だけでなく、情報プロダクトのデザイン一般において意味をなしてくるだろう。
]]></description>
		<wfw:commentRss>http://www.underconcept.com/blog/archives/438/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>クロスメディアバーはメディアスイッチか？</title>
		<link>http://www.underconcept.com/blog/archives/435</link>
		<comments>http://www.underconcept.com/blog/archives/435#comments</comments>
		<pubDate>Wed, 18 Jun 2008 03:31:58 +0000</pubDate>
		<dc:creator>Atsushi</dc:creator>
				<category><![CDATA[IA]]></category>
		<category><![CDATA[concept]]></category>
		<category><![CDATA[google]]></category>
		<category><![CDATA[psp]]></category>
		<category><![CDATA[search]]></category>
		<category><![CDATA[sony]]></category>
		<category><![CDATA[ui]]></category>
		<category><![CDATA[wii]]></category>
		<category><![CDATA[xmb]]></category>

		<guid isPermaLink="false">http://www.underconcept.com/blog/?p=435</guid>
		<description><![CDATA[ソニーのお家芸となったクロスメディアバーにGoogle検索が追加されるとのこと
 PSP システムソフトウェア 4.0 まもなく提供　XMBにGoogle検索追加
SONY WEGA｜体験！XM

ソニー、SME製品に適用されているクロスメディアバー（XMB）はテレビ、ゲーム機、HDDビデオなどなど、ジャンルを問わずにソニー製品に適用されているインターフェイス。
XMBの世界観では基本的に横軸にメディアフォーマット、縦軸にコンテンツ（チャンネル）が表示される。
つまり、横軸で、「テレビ」とか「音楽」とか「ゲーム」とかそういったメディア特性を選び、縦軸で映像名や番組名を選択するということになる。
これは、行為としても、

見たいコンテンツのメディア特性を意識する（メディアの選択）
目的のコンテンツを選ぶ

というステップとなる。
これは、あまりコンテンツがないときには若干面倒だ（PS3などでは通常挿入したソフトがそのまま再生されるので実用上の問題は少ない）。
また、ネットワーク越しにコンテンツを探すとき、あらかじめメディアを「ムービー」「ミュージック」「フォト」等決めてからDLNAサーバ内を探索することになる。このとき、同一フォルダ内に異なるメディアフォーマットのファイルがあっても表示されない。
これは、動画を見たい、と思っているときにはよいフィルタリングになるが、アーティスト切り、つまり「My Bloody Valentineの動画と曲を集めたファイルの中からいろいろ見たい」といった時には面倒になる。
これに対して、すべてのコンテンツをメディア特性を気にしないですべて横並びにしてしまう、という方法も考えられる。
これはWiiの「Wiiチャンネル」の考え方だ。
Wiiチャンネルでは、メディア特性は意識しないで、「天気予報」「バブルボブル（ダウンロードしたファミコンのゲーム）」「Wii Fitチャンネル」・・・といった風に、乱雑に並べられる。
この方法は、「メディアを意識させないで（メディアを横断して）」という意味では、ある意味「クロスメディア」と呼べるであろう。
このチャンネルは平面的だが、数的に一画面には12チャンネルしか入らないので、それ以上になると画面を切り替えることになる。
このとき、デフォルトのページに入りきらないものは、「二軍落ち」扱いになり、ものすごく利便性、アクセス頻度が下がる。
ウェブの世界では、ブラウザに表示される領域のうち、最初に見える領域を「ファーストルック」もしくは「ファーストビュー」と呼び（和製英語ですが）、この領域の価値が最も高いと考える。
逆に、画面下端や、検索結果の２画面目、３画面目というのはほとんど見られない前提で考える。
また、携帯電話などでもこの傾向は顕著であり、紙の時代にはヒットチャートはBest100まで一覧できていたのが、いまではどうがんばっても上位10曲となり、しかもその上位数曲に人気が集中する結果となっている。
オンラインメディアではこの「見える領域」の価値は絶大であるのだ。
この「見える領域」については、また別の機会に論じる。
さて、話をWiiチャンネルに戻す。
こちらの方法は、コンテンツを目的意識で選択することが可能であるが、「12チャンネル」に優先順位の高いものを集める必要がでてくる。
これはWiiをゲーム機として考えれば、普通の家庭で同時に楽しもうとするゲームはせいぜい数個だろうから（Wiiスポーツと、Wiiフィット、マリオカート、あと１，２個とか？）問題ないが、マルチメディアプレイヤー、あるいはWiiのコンセプトの「家庭のテレビにチャンネルを増やす」という点からすると、ちょっと足りないかもしれない。
このときにあるとうれしい機能は、フィルタリングだ。
通常は、優先度の高い全部が見えていても、たとえば「マリオ関係」とか「スポーツ関係」とか「料理」とか、タグ的なものでさくっとフィルとリングして、いるものが見つけられればありがたい（要はファセット分類）。
このとき、タグであるのがポイントで、「ムービー」というタグと「My bloody Valentine」というタグはどちらもありうる。
どういうインターフェイスにするかは要検討だが、すくなくともこのタイプのインターフェイスの場合は、メディアに限らず「特性」を後からフィルターする機能は必要といえるだろう。
と、ここまで二つの「クロスメディア」インターフェイスを見てきたが、ここで悩ましいのがネットブラウザの位置づけだ（ようやく本題）。
ネットのブラウザは、はたして一つのメディアチャンネルなのだろうか？というとそうではないのは明白だろう。
たとえばYouTubeは「インターネット」経由ではあるが、動画メディアであろう。
いまピュアな動画メディアではないように見えても、目指したい方向としてはそうであると思われる。
こういったものは、上記のタグや、あるいはソニーXMBであれば後から「ムービー」メディアにYouTubeを追加する、といった機能で対応するのが現時点では妥当だろう。
では、Googleは？
Googleはメディアか？というと、Googleは上記の文脈で言うところの「クロスメディア」インターフェイスに該当するものである。
通常のいま風のブラウザであれば、みなブラウザのツールバーには「戻るボタン」「ブックマークするボタン」などと並んで「検索窓」が用意されている。
Googleのヘビーユーザーでも、むしろヘビーユーザーほど、Google.comというトップページに行くことは少なくなる（ちなみに筆者はMacのショートカットキーユーティリティのLaunchBarからGoogleやAmazonを呼び出すことが多い、この場合ブラウザすら開いていない）。
Googleもこのことには自覚的で、スマートフォン用には待ち受け画面から検索窓だけ直接開けるアプリケーションを用意している（待ち受け画面に検索窓がある感覚）。
Google Releases Native Search Client for S60
また、Amazon Kindleも物理的にSearchボタンが用意されており、ここにキーワードを入力すると、ネット（A9経由か？）、Wikipedia、ローカル（書籍）内を検索した結果が表示される。
今回のPSPのアップデートは、このダイレクト検索窓がPSPに搭載されるという記事であった。
同様にPS3やWiiといった「デスクトップ」クロスメディアマシンのフロントページインターフェイスにも、今後はこういった検索窓が用意されていくだろうと考えられる。
このとき、検索エンジンだけでなく、diggやdel.icio.usといったソーシャルコンテンツアグリゲーターなどはもっとクロスメディアバーの操作感、Wiiチャンネルの操作感と並列に議論を行う必要がある。
先日のIA SummitでもPeter MorvilleのSearch Patternセッションが人気を博していたが、これもブラウジングと検索の関係性についての関心の高さを表している。
ソニー社内ではクロスメディアバーコミッティーが存在し、事業横断的な仕様検討や新しいメディアへの対応などについて集約して検討がなされているが、こういった方向性への対応も期待したい。
（080618 14:30 昨日を先日に修整）
]]></description>
		<wfw:commentRss>http://www.underconcept.com/blog/archives/435/feed</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
	</channel>
</rss>

