Agile Cat — in the cloud

クラウドへ行ったら、もう ファイルなんか触らないぞ!

Posted in .Selected, Miscs, UX by Agile Cat on August 10, 2011

There Will Be No Files In The Cloud
Fred Wilson is a VC and principal of Union Square Ventures
http://www.avc.com/a_vc/2011/08/there-will-be-no-files-in-the-cloud.html

image

I’ve spent a bunch of time talking to entrepreneurs who are building companies in and around the cloud storage space. It’s not a space I like very much because I don’t think we’ll be using files in the cloud. Now Dropbox is a brilliant company and an amazing service and they are doing very well, but will we need a service like Dropbox when everything is in the cloud? I don’t think so.

先日、ある企業家と 1時間ほど話をしたが、彼はクラウドのストレージ・スペースのことを考えていた。しかし、それは、私の好むスペースではない。なぜなら、クラウドになってまで、私たちはファイルを利用するとは思えないからだ。 いま、Dropboxは輝いており、驚くべきサービスを、とても上手く提供している。しかし、すべてがクラウドに移行したとき、Dropbox のようなサービスが必要とされるだろうか? 私は、そう思わない。

imageI was in DJ Woooo’s Dance/Electro Turntable room last week. I heard a remix track that was super fun. I hit the button to send the track to Rdio. I went to Rdio and listened to it a few times. Then I went to SoundCloud, found the track and then reblogged it into Tumblr. Not once in that experience did I have to touch a file. If Turntable and Rdio had good links into SoundCloud (I’m sure they will in time), I would not even have had to do any searching. It would have been click this, click that, click this and I would have been done. That’s how I think things are going to work when everything is in the cloud.

先週のことだが、私は Woooo’s Dance/Electro Turntable にいた。 そして、素晴らしく楽しい、リミックス・トラックを聴いていた。 そして、そのトラックを Rdio に送るためにボタンをクリックした。 続いて Rdio へ行き、数回か、それを聴いた。 さらに、SoundCloud へ行き、そのトラックを見いだしTumblr に ReBlog した。 これまでは、ファイルに触れることなく、こうしたエクスペリエンスは実現できなかった。 Turntable と Rdio が、SoundCloud 内に適切なリンクを持っていれば、いかなる探索さえ不要となるだろう。 あれをクリックして、それをクリックして、これをクリックすれば、すべてが終わっていたはずだ。 すべてがクラウドにあるとき、このように動くだろうと、私は思っている。

This is why I love Google Docs so much. I just create a document and email a link. Nobody downloads anything. There are no attachments in the email. Just a link. Just like the web, following links, getting shit done. I love it.

それが、Google Docs の好きなところだ。 ドキュメントを作成し、そのリンクを電子メールで送るだけで済む。 何かをダウンロードする必要がない。 電子メールにはアタッチメントがなく、リンクがあるだけだ。 Web とまったく同じように、リンクにしたがって、それを得ることができる。それを、私は好む。

That’s the future. I’m pretty sure of it. Mobile is a bit of a complicating factor because we are still stuck with downloadable software and unreliable and slow internet connections. But I think we’ll fix all of that in good time.

そこに、未来があると思う。 私は、そう確信している。 モバイルに関しては、ソフトウェアのダウンロードがあり、遅くて当てにならないインターネット接続もるため、少々複雑である。 しかし、それも、時が来れば解決されるだろう。

So if you are working in the cloud storage space, I think you’ve got a bit of a conundrum. The reality of the market today is that people use files. You need to support that use case, enhance it, and make people’s lives easier. But over time, that use case will go away. And what people will want is a service that doesn’t have files as the atomic unit. And how do you elegantly morph from a file centric model to a document centric model? It won’t be easy, I’m sure of that.

したがって、前述のクラウド・ストレージ・スペースを使う場合に、ちょっとした疑問が湧くと、私は思う。 しかし、人々がファイルを使うという考え方が、現時点のマーケットの現実である。そのユース・ケースをサポートし、それを拡張しながら、より使いやすくする必要がある。 しかし、時間をかけながら、こうしたユース・使用ケースは消え失せるだろう。 そして人々が欲しがるものは、最小ユニットとしてファイルを持たないサービスである。 そして、ファイル・セントリック・モデルから、ドキュメント・セントリック・モデルへと、エレガントにモーフィングするには、どうしたら良いのだろうか?それが容易ではないことも、私は確信している。

ーーーーー

まったく同感です。 Agile_Cat が Evernote 好きなのは、ファイルという概念が上手く隠されていて、見えないようになっているからです。 そして、マルチタグで、1つのドキュメントを複数のグループに登録できるところが気に入っています(以下の関連リンクを ご参照ください)。 ツリー構造のディレクトリとファイルという概念は、唯一無二のものを明確に指定できるので、とってもマシン・リーダブルなのですが、いい加減で、とかく曖昧になりがちな人間には、合わないと思うのです。ーーー __AC Stamp 2

このポストは、@afujimura さんから教えて頂きました。 いつも、面白い記事を、有難うございます。

ーーーーー

<関連>

OneNote 2010 が Evernote に負けているのは ココだ!

Microsoft は Silverlight をあきらめ HTML 5 へと走る

Posted in Apple, HTML5, Microsoft, UX by Agile Cat on October 31, 2010

Microsoft Giving Up On Silverlight, Joining HTML5 Party
By Ryan Lawler
Oct. 29, 2010, 4:00pm PDT
http://gigaom.com/video/microsoft-giving-up-on-silverlight-joining-html5-party/

_ Gigaom

We now have further confirmation that Microsoft is giving up on its Silverlight rich Internet application platform. Bob Muglia, Microsoft’s president in charge of server and tools, told ZDNet that the company is “shifting away” from Silverlight as a cross-platform development framework, and pushing the HTML5 web standard instead.

私たちは、いま、Microsoft が Silverlight RIA プラットフォームを断念していると、かなりの確信をもって言える。 Microsoft における Server & Tool 担当 President である Bob Muglia が、ZDNet に対して、以下のように語っている。 クロス開発プラットフォームしての Silverlight から『 シフト 』し、それに換えて Web スタンダードである HTML5 をプッシュしていく。

image

Microsoft will continue to develop and lean on Silverlight, especially for application development on its recently launched Windows Phone 7 operating system for mobile devices. However, Muglia told ZDNet, “HTML is the only true cross-platform solution for everything, including (Apple’s) iOS platform.”There’s been plenty of evidence to suggest this was the case. After all, with the launch of Internet Explorer 9, Microsoft has fully embraced and touted many of HTML5′s features. But it doesn’t just stop there; Microsoft will be leveraging HTML5 for the latest version of its Bing search engine, and is using H.264-encoded HTML5 video in lieu of Silverlight Smooth Streaming for delivery of live video on its Xbox 360 game console.

Microsoft は継続して、Silverlight を開発し、そこに依存していくだろう。 とりわけ、モバイル・デバイス用として、最近になって立ち上がった Windows Phone 7 OS の、アプリケーション開発にとって大きな存在となる。 しかし、 Muglia は ZDNet に対して 『 HTML は、すべてのための唯一のクロス・プラットフォーム・ソリューションであり、そこには Apple の iOS プラットフォームも含まれる 』と発言している。それが現実であることを示唆する、たくさんの証拠が存在する。結局のところ、Microsoft は Internet Explorer 9 に取り組みはじめた後に、たくさんの HTML 5 機能を受け入れ、また、それを売り込んでいる。 しかし、それだけでは止まらない。Microsoft は、Bing サーチ・エンジンの最新バージョンにおいて、HTML5 からの影響を受け入れ、また、Xbox360 ゲーム・コンソールに ライブ・ビデオを配信するための、Silverlight Smooth Streaming に換えて、H.264-encoded HTML5 ビデオを使用している。

That Microsoft would align itself with Apple, especially in the embrace of a web standard, might seem peculiar to some. After all, the two software makers have been battling for decades in the PC space, and now are bumping heads in mobile as Microsoft tries to offer up a compelling alternative to Apple’s iPhone.

とりわけ Web スタンダードの容認において、Microsoft が Apple と提携することで、いくつかの企業にとって特殊なことが起こるかもしれない。 結局のところ、この 2つのソフトウェア・メーカーは、PC の世界において十年戦争を繰り返している。そして最近といえば、Apple の iPhone に換わるものを Microsoft が提供しようとするにつれて、両社が衝突する機会が増えている。

But it also makes sense that Microsoft would begin de-emphasizing Silverlight as a cross-platform development platform. Despite some of the advances Microsoft was able to push with its development, including HTTP and adaptive bit rate streaming, it wasn’t able to dethrone Flash as the de facto rich Internet application and video platform on the web. And with the emergence of HTML5, it was no longer a matter of playing second fiddle to Adobe, but lagging behind a web standard that was also being rapidly adopted.

しかし、それよりも興味深いのは、クロス・プラットフォーム開発のための Silverlight を、Microsoft が重視しなくなる可能性である。HTTP と適応性のあるビットレート・ストリーミングを含めて、Silverlight には先進性があった。そして Microsoft は、Silverlight を促進することが可能であった。しかし、Web 上のリッチ・アプリケーションとしての、そしてビデオ・プラットフォームとしてのデファクト・スタンダードから、Flash を引きずり下ろすことはできなかった。 そして、HTML 5 の出現により、Adobe の後塵を拝することはなくなったが、急速に採用されていく Web スタンダードで遅れをとることになった。

To see what Adobe CTO Kevin Lynch has to say about adoption of HTML5 and its positioning against Flash, come see him speak at NewTeeVee Live on November 10 in San Francisco.

Related content on GigaOM Pro:

ーーーーー

文中で参照されている、ZNet への Muglia さんのコメントですが、リンク先は Mary Jo Foley さんの All About Microsoft でした。

Silverlight is our development platform for Windows Phone,” he said. Silverlight also has some “sweet spots” in media and line-of-business applications, he said.

『 Silverlight は、Windows Phone のための、私たちの開発プラットフォームである 』 と、彼は発言した。そして更に、メディア や LOB のアプリケーションにおいて、いくつかの『 スイート・スポット 』を Silverlight は持つと、彼は付け加えた。

これは、ショックを和らげるためのリークであり、そのための緩衝材として、All About Microsoft を使ったとみるべきでしょう。なお、ぐぐってみたら、以下のニュースが見つかりました。

Microsoft favoring HTML5 over Silverlight: reports
Microsoft nails Silverlight’s future to Windows Phones
Is Microsoft Turning Off the Silverlight?
Microsoft claims HTML5 is important
Silverlight is dead, long live Silverlight?
Microsoft switches focus from Silverlight to HTML5
Silverlight is dead. Long live
Microsoft Has Seen The Light. And It’s Not Silverlight.

ここまできて、誤報というのは、あり得ないと思うのですが。 ーーー A.C.

ーーーーー

<関連>
PDC と Silverlight について – Bob Muglia
PDC10 後の Windows Azure は、AWS とガチンコ勝負か?
Google Chrome での Flash サポート: Chromium Blog でのリリース:対訳
Jobs の Adobe 批判って、自爆してません?

Infragistics – UX と テキスト の関係を、論理的に解明する

Posted in UX by Agile Cat on August 2, 2010

Text Treatment and User Experience

image

Infragistics text_1

Before user interfaces became graphical, text was the primary input/output defining the human-computer interaction. Even today, much of the information presented on UIs is text-based. The right text treatment can measurably improve productivity and increase user satisfaction. Because of this, text treatment should not be underestimated. With new technologies becoming available (e.g. larger monitors, higher resolutions, etc.) a good base knowledge of text treatment helps to create usable UIs quicker.

ユーザー・インターフェイスがグラフィカルなものになる以前は、人間とコンピュータのインタラクションは、主としてテキストの入出力により定義されていた。 今日の UI においても、大量の情報がテキスト・ベースで表現されている。 テキストを正しく取り扱うことで、生産性の改善とユーザー・エクスペリエンスの向上が、一定の範囲で達成される。 したがって、テキストの取り扱いを過小評価すべきではない。 高解像度の大型モニターなどの、新しいテクノロジーが利用できるようになってきた。それにつれて、テキストの取り扱いに関する適切なナレッジ・ベースにより、利用価値の高い UI の作成が短時間で実現できるようになる。

User Experience

User Experience (UX) is a concept pertaining to the overall – or holistic – encounter between users and interactive technical systems. More concretely, it’s the degree of usability and appeal that a website or application provides to its users. Great usability implies that an interactive product allows its users to efficiently accomplish their goals. Well-known guidelines are provided by ISO 9241-110 [1] and Nielsen’s Heuristics [2].

ユーザー・エクスペリエンス(UX)とは、ユーザーと対話型のテクニカル・システムの間に存在する、全体的あるいは総体的なコンセプトのことである。より具体的に言うと、Web サイトやアプリケーションが、ユーザーに提供する有用性と魅力の尺度となる。 有用性に優れるということは、対話型のプロダクトにより、ユーザーのゴールを効率よく達成することを意味する。 そのための、広く認識されるガイドラインとしては、ISO 9241-110[1]と  Nielsen’s Heuristics [2]がある。

Infragistics text_2

<Figure 1: User Experience>

Appeal refers to the emotional tie between users and a system they are interacting with. Do users love it? Hate it? Do they think it’s attractive or modern or engaging? Do they feel pride when they interact with it? Although appeal cannot be defined as concisely as usability, it is of equal importance for the success of a product because appealing systems are more enjoyable and desirable which increases their value.

魅力的な UI とは、ユーザーとインタラクティブ・システムを、感性的な側面から結びつける要素である。 それはユーザーが好むものであり、 また、嫌うものでもある。 さらに言えば、魅力的で近代的であり、 心地良くインタラクトできるだろうか。 魅力については、有用性ほど簡潔に定義できないが、プロダクトの成功において双方が均等に重要性を持つのは、魅力的システムは楽しさを備えるものであり、自身の価値を高めるからである。

Text Size

Font size is a crucial parameter determining character legibility. Practitioners in software development often use common font sizes (e.g. Verdana 10 points or Arial 10 pixels) that are recommended throughout countless internet sites. While it makes sense to recommend standard font sizes for developing a product, keep in mind that font size is not the only determinant of the physical character size on a computer screen. It is more appropriate to recommend parameters for character size that are based on physiological measures. In other words, what’s crucial is what the end-user actually sees on the screen, not what has been programmed.

フォントのサイズは、キャラクタの明瞭性を決定する、きわめて重要なパラメータである。 ソフトウェア開発に長けているエンジニアは、無数のインターネット・サイト全体で推薦される、一般的なフォント・サイズ(Verdana 10 point や Arial 10 pixel など)を使用する。 プロダクト開発における標準的なフォント・サイズの推薦が意味を持つにしても、コンピュータ・スクリーン上での物理的なキャラクタ・サイズの決定において、フォント・サイズだけが唯一の要因ではないことを念頭におくべきだ。 それよりも適切な方式は、生理学的な基準に基づいていてキャラクタ・サイズのためのパラメータを推奨することだ。 言い換えれば、最も重要なことは、プログラミングされている内容ではなく、実際にエンドユーザーがスクリーン上で見るものとなる。

Different guidelines and standards recommend slightly different character sizes. ISO standard 9241-3 [3] states:

その意味で推奨される、ガイドラインおよびスタンダードでは、少し異なるキャラクタ・サイズが用いられる。 それは、ISO 標準の 9241-3 [3] である。

"Character heights from 20 to 22 minutes of arc are preferred for the most tasks. The minimum character height shall be 16 minutes of arc."

そこでは 『 大半の作業において、キャラクタの縦幅は 20~22 分(角度の)が好まれ、最小のキャラクタは 16分(角度の)の縦幅である 』とされる。

1 minute of arc is equal to 1/60 (0.0167) degree, therefore the respective line-of-sight angles in Figure 2 are:

ここで言う『分』は、1/60 度に等しいため、それぞれの角度は以下のとおりとなる。

  • 16 minutes of arc = 0.267 degree
  • 20 minutes of arc = 0.333 degree
  • 22 minutes of arc = 0.367 degree 
  • 16 分 = 0.267 度
  • 20 分 = 0.333 度
  • 22 分 = 0.367 度

Infragistics text_3

<Figure 2: Relationship between line-of-sight angle, viewing distance and character height>

Recommendations for the minimum viewing distance d between user and monitor screen range from 400 to 600 mm. ISO 9241-3 states 400 mm for normal office work. Given the fact that the near point of accommodation at the age of 50 is already 500 mm [4], a value of 500 mm for the viewing distance is more appropriate and is often recommended in ergonomic literature [5].

ユーザーとモニター画面の間隔 『d』 については、最小でも400 ~ 600 mm が推奨される。 一般的なオフィス・ワークを前提として、ISO 9241-3 には 400 mm と記載されている。 ただし、50 代の年齢に合わせた近点 『d』を前提として[4]、500 mm の視距離が適切であり、また、人間工学に関連する大半の文献でも推薦される[5]。

Assuming that a character is viewed orthogonally so that in Figure 2 the viewing distance d is at a right angle to the screen, the results from the trigonometric formula in Figure 2 are the following character heights for d = 500 mm:

Figure 2 におけるキャラクタを真正面から見るために、視距離を示す 『d』 がスクリーンに対して直角であり、また、『d』= 500 mm だと想定すると、三角形の法則から導かれる結果は、以下のとおりとなる:

  • Minimum character height: 2.3 mm
  • Preferred character height range
    • Lower end: 2.9 mm 
    • Upper end: 3.2 mm
  • 最小サイズのキャラクタ(縦): 2.3 mm
  • 好まれるサイズのキャラクタ(縦):
    • 最小 : 2.9 mm
    • 最大 : 3.2 mm

Usually the character height relates to upper case letters, so for the above parameters an “E” has to be at least 2.3 mm of height, preferably even larger then 2.9mm.

一般的に、キャラクタの縦サイズは大文字に結び付けられるため、たとえば  " E " に対する上記のパラメータは、最小でも 2.3mm であり、また、好まれるサイズは 2.9mm 以上となる。

The challenge is to understand the parameters that determine the physical character height, i.e. the absolute height that one could measure by using a ruler on the screen. In other words, now that we know the target character height, how do we ensure that the characters on the monitor screen really are this height? Apart from the font size, the physical character height is determined by:

ここでの課題は、物理的な文字の縦サイズを決定するパラメータを理解することであり、たとえば、スクリーン上のルーラーを用いて、そのサイズの絶対値を測定できる。 言い方を換えれば、対象となるキャラクタの縦サイズが分かっても、そのサイズがモニター画面上に反映されていることを保証できるだろうか? フォント・サイズとは関係の無いところで、物理的な縦サイズは、以下のように決定される:

  • Font size setting of the operating system (e.g. in Microsoft Windows: small, large)
  • Browser text size setting (e.g. in Microsoft Internet Explorer: smallest, small, medium, large, largest) for browser-based products
  • Pixel density, expressed in pixels per inch (ppi). This unit depends on:
    • Screen resolution (e.g. 1024×768 pixels)
    • Physical size of the visible part of the monitor
  • オペレーティング・システムのフォント・サイズ設定(たとえば Microsoft Windows の Small と Large)。
  • Web におけるブラウザーのテキスト・サイズ設定(たとえば Microsoft Internet Explorer の Small と Large)。
  • PPI( pixels per inch )で表現されるピクセル密度であり、以下に依存:
    • スクリーン解像度(たとえば 1024×768 Pixel)。
    • ディスプレイにおける物理的な表示領域サイズ。

While the effects of font and text size settings can be controlled, there is not a definite pixel density, because the end users’ monitor sizes and resolutions settings vary. To give an example, consider two persons A and B who use the same software. They both conform to the recommended 500 mm viewing distance and are using the same system settings – only person A uses a 14-inch notebook (visible width = 10.67 inches) while person B uses a 17-inch monitor (visible width = 14.22 inches). Since the definition of pixel density is:

フォントとテキストのサイズ設定効果が制御可能である一方で、一定のピクセルの密度が存在しないのは、モニターのサイズと設定が変化するためである。 例として、A と B という 2人が、同じソフトウェアを使う状況を考えてみよう。 両者とも、推薦される 500 mm 視距離と、同一のシステム設定を用いるが、A は 14 inch のノートブック(視覚幅 = 10.67 inch)を用い、また、B は 17 inch モニター(視覚幅 = 14.22 inch)を用いる。 そして、ピクセル密度の定義は以下のとおりである:

pixel density [ppi] = pixels / inch

we obtain the following pixel densities for an assumed screen resolution of 1024×768 pixels:

スクリーン解像度が 1024×768 Pixel だとすると、以下の Pixel 密度が得られる:

Infragistics text_4

<Table 1: Calculating pixel density>

Solving the above pixel density equation towards inches, we receive

上記の Pixel 値を inchi に置き換えるための計算式は、以下のとおりである:

inches = pixels / pixel density

The physical height of an upper-case character of 10 pixels height would consequently be:

10 Pixel を用いた場合の、大文字の物理的な縦サイズは、以下のとおりとなる:

Infragistics text_5

<Table 2: Calculating actual character height>

So for Person A the physical character height conforms only to the required minimum character height stated in ISO 9241-3 for a viewing distance of 500 mm, whereas for Person B the size even exceeds the preferred value range.

したがって、A にとっての物理的なキャラクタ・サイズは、500 mm の視距離を前提にした、ISO 9241-3  の最小サイズを充たすだけものとなる。 しかし、B にとっての物理的なキャラクタ・サイズは、好まれるサイズを充たすことになる。

Font Type

Developers have hundreds of font types at their disposal. One way to group them is into serif and sans-serif types. Serifs are small lines at the ends of the main strokes. Serif fonts improve readability in continuous text, because the serifs help to structure and discriminate characters [6]. Times New Roman, for example, is a serif font type. Typically, these kinds of fonts are used in newspapers and books.

デベロッパーは、自由に使うことができる、何 100種類ものフォント・タイプを持っている。 それらを体系化する方法として、serif と  sans-serif に分類することができる。 Serif は、文字の終端近くで細いラインを用いる。 Serif フォントが、連続するテキストの可読性を改善するのは、文字の構造化と差別化を促進するからである[6]。たとえば、Times New Roman は serif フォント・タイプである。 一般的に、これらのフォントは、新聞や書籍で使用される。

Infragistics text_6

<Figure 3: Examples of Serif and Sans Serif Font Types>

Sans-serif font types like Arial are those that do not feature these little “feet”. They are preferred on screens, as relatively low screen resolutions (typically around 100 pixels per inch, compared to 800 dots per inch) make serif fonts look fuzzier, especially in small sizes.

Arial のような Serif フォント・タイプは、終端を飾らない。 印刷などで用いられる 800 DPI(Dot Per Inch)と比較して、
比較的に解像度の低いスクリーン(100 PPI 前後)では、フォント・サイズが小さくなるにつれて、Serif フォントは不明瞭になる。

The new generation of e-books such as the Kindle from Amazon have much higher pixel densities than current PC monitors: around 170 ppi. This makes it possible to use serif font types similar to a real paper book – boosting the overall user experience. So the choice between serif and sans-serif font type depends on the capabilities of the target output technology.

Amazon の Kindle などの新世代 e-Book は、現在の PC モニターと比較して、170 PPI 前後の高いピクセル密度を持つ。 つまり、本物の書籍のように Serif フォント・タイプを使うために、全体的なユーザー・エクスペリエンスを引き上げている。 したがって、Ferif と Sans-Serif フォントの使い分けは、対象となるアウトプットに依存する。

Letter Cases

In the past during the mechanical printing process, individual letters were manually assembled into words and sentences. Miniscule letters (a, b, c, etc.) were in cases positioned below those for majuscule letters (A, B, C, etc.). Hence, we call them “lowercase” and “uppercase” letters.

従来からの機械印刷のプロセスでは、それぞれの文字が手作業により、単語と文章に組み入れられてきた。 小文字書体(a ,b, c など)は、大文字書体(A, B,C など)に対して、下合わせて位置決めされてきた。 それ故に、それらの文字は  “Lower Case” および “Upper Case”  と呼ばれる。

There are three major ways to use letter cases in text (see Figure 4): lowercase, mixed-case and uppercase. We see all three in our daily lives. Ergonomists have consistently recommended using mixed-case letters and shy away from using uppercase letters, especially for continuous text.

テキストにおける文字の取り扱いケースには、 “Lower_Case”、"Mixedr_Case"、“Upper_Case” の 3種類がある(Figure 4 を参照)。 それらの全てが、日常において使用されている。 人間工学の研究者たちは、一貫して "Mixed_Case" の利用を推奨し、連続したテキストでの “Upper_Case” の利用は避けるべきだと言っている。

Infragistics text_7

<Figure 4: Example of different Letter Cases>

The reason is that the ascenders (extensions towards the top like in b, d, f, h, k, l, t) and descenders (extensions towards the bottom like in g, j, p, q, y) create the shape typical for a specific word [7]. It is therefore easier to recognize words while reading. Mixed-case also allows better comprehension of the sentence structure, since uppercase is used as the first letter in names or at the beginning of a sentence.

その理由は、アセンダー( b, d, f, h, k, l, t のように上へ突き出す)と、ディセンダー( g, j, p, q, y のように下へ突き出す)が、特定の単語のための、典型的な形状を作り出す点にある[7]。それにより、 読書の際の単語の認識も容易になる。 さらに、 "Mixed_Case" が文章構造の理解を促進するのは、大文字が固有名詞や文章の先頭に用いられるからである。

INTERESTINGLY, RECENT RESEARCH YIELDS OPPOSING FINDINGS. EXPERIMENTS SHOW THAT DUE TO THE SHEER SIZE, UPPERCASE IS MORE LEGIBLE IN TERMS OF READING SPEED THAN THE OTHER LETTER CASES, ESPECIALLY FOR VISUAL IMPAIRED PERSONS [8].

興味深いことに、最近の研究では、それに対向する調査結果がもたらされている。 スクリーン・サイズに応じたいくつかの実験では、とくに視覚障害を持った人々の場合に、他の文字種と比較して、大文字の方が読むスピードが速いという結果が示された[8]。

Looking at the difference between the last paragraph and the rest of this article, you can build your own opinion about what letter case style is easier and faster to read. I personally believe that mixed-case is superior at least for users without vision impairments.

この記事における上記の段落と他の部分を見比べることで、どのような文字種を用いれば、より迅速かつ容易に読めるかという観点で、あなた自身の意見を形成することができる。 私の個人的な意見としては、視覚障害のケースは別として、"Mixedr_Case" が読みやすいと思う。

Text Alignment

When continuous text has to be displayed on informational websites or in online help/documentation, there are two patterns that are commonly used to align the text (see Figure 5): “justified” so that the text body has clean edges to both the right/left and “ragged right” where the text body is left-aligned.

情報を提供する Web サイトやオンライン・ヘルプ/ドキュメンテーションで、テキストが連続的に表示される場合には、テキストを整列させるための 2つのパターンがある(Figure 5 を参照)。それは、テキスト・ボディを左右の両端まで広げた “justified” と、左詰めにした ”left-aligned” である。

c09ba195-74ca-4515-a062-5019975dfccb

<Figure 5: Example of justified versus ragged-right text alignment>

Although justifying continuous text provides a nice form factor, the extra spaces that have to be placed between the individual words create continuous vertical spaces that appear meaningful (like vertical rivers). This can be distracting to the reader [9]. It is therefore recommended to use “ragged-right” text alignment.

連続したテキストにとって “justified”  は適切なフォームを提供するが、単語の間に生じてしまう余分なスペースが、意味を持つかのようなスペースを作ってしまう(垂直の流れのような)。 それが、読み手の集中力を阻害する場合もある[9]。 したがって、”left-aligned” の利用が推奨される。

Text Orientation

Different layout conditions may require different text orientations. Figure 6 shows the standard horizontal text, marquee style text (where each individual letter is horizontal yet the letters are vertically aligned), and text that is rotated by 90° either to the right or left.

それぞれのレイアウト条件に応じて、テキストに対して別の方向性を要求することになる。 Figure 6 が示すのは、水平テキストおよび、marquee スタイル・テキスト(文字は水平で単語は垂直)、テキストが左右に90 度ローテートされるケースである。

Infragistics text_9

<Figure 6: Different Text Orientations>

Obviously, the best one can do is use horizontal text. After all, our books are not written in marquee or rotated text either. This may not be true for other cultures, but in the western world, this is what we know and are familiar.

明らかに、ベストは水平テキストの利用である。 結局のところ、英語圏における書籍では、marquee あるいはローテートのテキストは使用されない。 それは、他の文化圏に該当しないと思われるが、西欧世界では、それが共通の認識であり、習慣である。

Research confirms that horizontal text orientation is read the fastest [10]. It has also shown that it does not matter if text is rotated to the right or left (e.g. on vertical tabs). Reading speed is a function of where the items are placed on the screen (for aesthetical reasons the font should be directed inward). Of all text orientation styles, marquee yields the poorest user performance and is the hardest to read.

調査結果としては、水平テキストが最も速く読まれると確認されている[10]。 さらに、テキストが左右にローテートされていても(垂直タブでなどで)、そのことが重要ではないとされている。文字を読むスピードは、スクリーン上のアイテムの位置により影響をうける(アセンダー的な理由により、フォントの上部がディスプレイの中心へむける)。 テキストの方向性に関するスタイルにおいては、marquee が最低のユーザー・パフォーマンスをもたらし、また、読むことも困難となる。

image

References

[1] ISO 9241-110 (2006). Ergonomics of human-system interaction – Part 110: Dialog principles. Berlin: Beuth.
[2] Nielsen, J. ().Nielsen, J. (1994). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability Inspection Methods. New York City: John Wiley & Sons.
[3] ISO 9241-3 (1992). Ergonomic requirements for office work with visual display terminals (VDTs) – Part 3: Visual display requirements.
[4] Grandjean, E. (1986). Ergonomics in Computerized Offices. New York: Taylor & Francis.
[5] Kroemer, K, Kroemer, A. (2001). Office Ergonomics. New York: Taylor & Francis.
[6] Wheeler, S. G. (1996). TypeSense: Making Sense of Type on the Computer. Boston: International
Thompson Computer Press.
[7] Dul, J., Weerdmeester, B.A. (1993). Ergonomics for Beginners. Oxford: Taylor & Francis.
[8] Arditi, A., Cho, J. (2007). Letter case and text legibility in normal and low vision. Vision Research, 47(19), pp. 2499-2505.
[9] Watzmann, S., Re, M. (2008). Visual Design Principles for Usable Interfaces. In: A. Sears, J.A. Jacko (Eds.), The Human-Computer Interaction Handbook. Lawrence Erlbaum Associates, New York, pp. 329-353.
[10] Byrne, M. D. (2002). Reading vertical text: Rotated vs. marquee. Proceedings of the Human Factors and Ergonomics Society 46th Annual Meeting. Santa Monica, CA: Human Factors and Ergonomics Society.

ーーーーー

<関連>
ユーザーのためのデータ・ビジュアライゼーション Part_1
ユーザーのためのデータ・ビジュアライゼーション Part_2
カラー と ユーザー・エクスペリエンス _1
カラー と ユーザー・エクスペリエンス _2

Tagged with: , , , ,

Infragistics : ユーザーのためのデータ・ビジュアライゼーション Part_2 – 円グラフとピザ効果

Posted in UX by Agile Cat on June 29, 2010

Blog series: User-Centered Data Visualization. Part 2 – The Pizza Effect
http://blogs.infragistics.com/error.htm?aspxerrorpath=/blogs/ux/archive/2010/01/05/blog-series-user-centered-data-visualization-part-2-the-pizza-effect.aspx

image

The underlying data set is pretty simple. It consists of just 8 numbers which are used for four target/actual comparisons: how many swine flu vaccinations 4 organizations have requested and how many they actually received. And still, the way the data was visualized is problematic.

この、基礎となるデータセットは、かなり単純なものである。 それは、4つのターゲットと、現実的な比較のために使われる、8種類の数値だけで構成されている。つまり、4つの組織において、ブタ・インフルエンザ・ワクチンンの接種を求めた人数と、実際に接種できた人数を表現している。 そして、データのがビジュアライズには、依然として問題が残されている。

TimeMagazinScan

Estimating the area of a circle is hard. The area of a circle grows quadratically with the radius. You double a circle’s radius and the area gets four times as large. You may know this from ordering pizza: the diffe

サークルの面積を推測することは困難である。 サークルの面積は、その半径に比例して拡大する。 たとえば、サークルの半径を 2倍にするなら、その面積は 4倍の広さとなる。 ピザを注文するときに、この事実に気づくことになる。 つまり、14インチのピザ(medium)と 16インチのピザ(large)の違いについて、数字だけを並べてみても実感がない。 結局のところ、それは 2インチの違いに過ぎない。 しかし、16インチのピザ(large)を食べることは、14インチのピザ(medium)のときと比べて、まったく別次元の挑戦となる。これが、『半径を 2倍にするなら面積は 4倍』の効果である。

Columbia University requested twice as many vaccines than Goldman Sachs. This is very hard to see in the circle sizes: with both red circles being the same size (showing that they both received the same number of vaccines), Columbia’s large dotted circle does not look twice as large as Goldman’s – but it is. That’s the pizza effect. Were the actual numbers not shown below the circles, the visualization would be not very expressive. Because estimating the area of circles is so difficult, it’s also tough to compare the size of the red circles against the dotted circles for all of the organizations.

Columbia University は Goldman Sachs と比べて、2倍の量のワクチンを求めた。 それを、サークルのサイズで見きわめることは、きわめて困難である。 双方の赤いサークルは同じサイズ(双方が同じ数のワクチンを受け取ったことを示す)であるが、Columbia の点線によりサークルが、Goldman のそれと比べて、2倍の大きさに見えることはない。   実際には 2倍の大きさなのに、そう見えないことがピザ効果の結果である。 もし、サークルの下に実際の数量が示されていなければ、このビジュアライゼーションの効果は半減する。 それほどに、サークルの面積を推測することは難しい。 そのため、点線によるサークルを基準にして、赤いサークルのサイズを判断することも難しくなる。

Here’s one suggestion to visualize the data in an easier to interpret manner:

ここでは、データをビジュアライズするため方式を示唆するが、それは、データの説明を容易にするためのものとなる。

Infragistics_1

Because it’s much easier to estimate the length of a bar than the area of a circle, this graph makes it easy to see that Columbia ordered twice as many vaccines than Goldman – even without data labels next to the bars. It’s still a challenge to estimate the number of received vaccines for Goldman and Columbia. A logarithmic scale could resolve this problem, but people have hard times understanding log scales (see the first blog of this series).

サークルの面積を見積るより、バーの長さを見積もる方が、ずっと容易である。 そのため、Columbia が Goldman に対して、2倍の量のワクチンを発注したことが、このグラフから容易に読み取れる。 数値による説明がなくても、それが判るだろう。 しかし、Goldman と Columbia が受け取ったワクチンの数を見積もることが、まだ解決されていない課題として残される。 対数のスケールを用いれば、この問題を解決することが可能だが、一般的に受け入れられるものではない。 (see the first blog of this series )

People often say that bar charts or column charts are too standard and therefore boring ("not sexy"). These chart types are standard because they are superior to other ways of visualizing data. There are still ways (within limits) to make them attractive, but from a user-centered design perspective I believe that usability has the top priority.

バー・グラフやカラム・チャートは、あまりにも標準的であり面白くないという(not sexy)、数多くの声がある。 しかし、これらのチャート・タイプがスタンダードとして用いられるのは、データのビジュアライズにおいて、他の方法より優れているからという理由がある。これらのグラフを、さらに(適度に)魅力的にする方法はあるが、ユーザーを中心としたデザインの見地からは、有用性が最優先にされすべきだと信じる。

Here’s another interesting fact that neither the original visualization nor the bar chart reveal. It doesn’t seem like it was the intention of Time to focus on this, but since the ratios between requested and received vaccines are shown, it’s straight forward to calculate the actual value which then makes it very easy to see which of the four organizations got better off than the others. Here’s what the result looks like:

オリジナルのサークルでも、追加されたバーでも明らかにされていない、もう1つの面白い事実がある。 ワクチンに対する要求と受け取りの比率を表示できるのだが、そこに焦点を合わせることが、Time 誌の意図になかったように思われる。この比率を、4つの組織において比較することは、実際の数値を計算することで、シンプルかつ容易に行える。 つまり、以下のような結果が導き出せる:

Infragistics_2

Again I didn’t put data labels next to the bars. Not necessary. It’s obvious that the cancer center and Goldman Sachs have approximately the same ratio between requested and received vaccines – roughly 5% and that’s a third of what Citigroup got and twice as much as Columbia. It’s interesting that, unlike pie charts, bar charts require you to think about how to scale the x-axis. I put it to 100% max to show the distance between the optimum relative return (100%) and the best achieved relative return (17%). So the message is that none of the four organizations got a good portion of what they had asked for. If I had put the max on the x-axis to 20% it would’ve shown more clearly the differences between the organizations. So the message had been: Citigroup got a much higher relative return than the others. Which scaling is better? There is no right or wrong answer. It depends on the underlying question at hand and what you want to express. Doesn’t this demonstrate how manipulative data visualization can be? You betcha.

繰り返すが、バーの横にデータ・ラベルは配置していない。 なぜなら、必要とは思えないからである。 ワクチンに関する要求と結果において Cancer Center と Goldman Sachs が、ほぼ同じ比率となっている。 この、約 5% という値が、Citigroup の 1/3 に近く、Columbia の2倍に近いという事実が明らかになる。 サークル・グラフでは不可能であるが、バー・グラフにおける x軸のスケールを考えると面白い。 ここでは、最大値を 100% にして、最良の結果である 17% との対比を示している。 つまり、4つの組織のいずれもが、最良の結果を得られなかったというメッセージが発信される。 もし、x 軸のスケールを 20% にしたなら、今度は組織間の相違が明らかになる。 そして、Citigroup が、他と比較して高いリターンを得ていることも、メッセージとして発信される。 どちらのスケールのが適切なのだろうか? そこには、正解もなければ不正解もない。 それは、取り組んでいる基本的な問題と、明らかにするものに依存する。 つまり、データ・ビジュアライゼーションを、どれだけ巧みに操れるのかということが、証明されているのはないだろうか? そこに賭けるべきだ。

ーーーーー

image 

ーーーーー

<関連>
Infragistics : ユーザーのためのデータ・ビジュアライゼーション Part_1
カラー と ユーザー・エクスペリエンス _1
カラー と ユーザー・エクスペリエンス _2

IE9 の互換性リストが届いたけど、Acid3 って関係ないの ?

Posted in Miscs, UX by Agile Cat on June 3, 2010

よく分からないブラウザ互換性の基準

今朝ほどですが、Internet Explore 9 の互換性を示すメールが届きました ・・・

TechNet Flash: IE 9 compatibility results and new Microsoft Desktop Player
Microsoft [Microsoft@e-mail.microsoft.com]
Thu 6/3/2010 5:13 AM

This website contains several collections of new test pages that we developed in conjunction with the World Wide Web Consortium (W3C) working groups. These 192 test pages have been updated based on feedback and now include some new HTML5 test pages.

こうして見ると、きわめて正確な表示を実現するブラウザのようなのですが・・・

IE9 Compatibility Harf クリックで、他のブラウザ・データも表示

Acid3 のテスト結果が入っていないのです・・・

Mozilla のところに 94% がないとヘンですよねと思って、Web を調べてみたら 68/100 という IE9 のテスト結果がありました。 以下の IE8 と比べると、ずいぶんと良くなっているのに、なぜ、その結果を載せないのだろう?

Acid3 IE8

IE 8 の計測結果

Acid3 FF36

Firefox 3.6 の計測結果

ちなみに、Wikipwdia からの抜粋を転記しますと・・・

Acid3(あしっどすりー)はウェブスタンダードプロジェクトによるテストページである。ウェブブラウザが特定のウェブ標準にどれだけ従っているのかを調べることを目的にしている。特に DOMJavaScript に関連したウェブ標準を対象にしている。

このページは2007年4月から開発され[1]2008年3月3日にリリースされた[2]。主な開発者は Acid2 テストを書いたイアン・ヒクソンである。Acid2 が主に CSS に焦点を当てているのに対し、Acid3 テストでは ECMAScript や DOM Level 2 といった、現代的で双方向性の高いウェブサイトで使われる技術にも焦点を当てている。いくつかのテストは SVGXMLdata: URI にも関連している。2004年時点での仕様における要素のみが含まれている[3]

成功したとき、背景に色の付いた長方形とともに、Acid3 テストは次第に上昇するパーセンテージカウンタを表示する。パーセンテージは合格した部分テストの数に基づいている。これに加え、ブラウザは参照ページでレンダリングした通りにテストページをレンダリングしなければならない。Acid2 テストとは異なり、フォントのレンダリングにおける若干の違いを考慮に入れるため、参照レンダリングはビットマップではない。

う~ん、よく分からない。 いらないんでしょうかね、Acid3 って ・・・

ーーーーー

実は、Agile_Cat のフォント設定の間違いが、IE8 では判別できなかったということがあり、ひまを見ては Firefox で確認し、泣きながら手直ししているという状況でして、ちょっと IE に懐疑的なんですw ーーー A.C.

ーーーーー

<関連>
KONUREさんのブログ
The hunt for the Fastest Browser on Earth – Part II, Judgment Day

Tagged with: , , ,

カラー と ユーザー・エクスペリエンス _2

Posted in UX by Agile Cat on May 28, 2010

Colors and User Experience _2
http://community.infragistics.com/ux/articles/colors-and-user-experience.aspx

image

初めての方は、その1 を先にお読みください。

Color Deficiencies

When people talk about color blindness they usually refer to the inability of perceiving certain colors. It is more appropriate to call these conditions color deficiencies, because in the majority of cases people are not completely unable to perceive a certain color, but their perception is faulty [3]. Color deficiencies occur when a cone type is either missing or working abnormally. Figure 5 shows the incidence rates for color deficiencies based on the affected L-, M-, and S-cones. 80 out of 1000 men and only 4 out of 1000 women have some sort of color deficiency. Because the curves for the L- and M-cones are close to each other (see Figure 2), the effect of L- and M-cone based color deficiency is similar. When there are problems with L- or M-cones the color appearance is mostly based on blue and yellow hues, the complimentary color pair red-green cannot be perceived correctly.

色盲について語るとき、特定のカラーを知覚する能力の、欠落について言及されるのが一般である。ただし、こうした状態については、カラー欠陥と呼ぶ方が適切だ。なぜなら、そのような人々の大半は、特定のカラーを知覚する能力が、完全に欠落しているわけではなく、その知覚に欠陥があるからだ[3]。 つまり、コーン・タイプが不適切な場合や、正常に機能しないときに、カラー欠陥が引き起こされる。 Figure 5 が示すのは、何らかの影響を受けた L/M/S コーンに基づく、カラー欠陥の発生率である。 1000人のうち80人の男性が、ある種のカラー欠陥を持つが、女性に関しては 4人だけとなる。 Lコーンと M コーン のカーブは近い位置にあるため、それらが原因となるカラー欠陥の影響は、類似したものとなる。 L/M コーンに関連する問題が生じる大半のケースにおいて、それは、青と黄色の色合いに基づいたカラー・アピアランスの問題となる。つまり、赤と緑の組み合わせによる、補足的なカラーの知覚が不正確なものとなる。

UX_2_5

Figure 5: Color deficiencies.

Color deficiencies based on S-cones have the effect that color perception is based on red and green hues, the perception of the complimentary color pair blue and yellow is disturbed. It is a very rare condition though, only affecting 4 out of 100,000 men and 2 out of 100,000 women. The same is true for total color blindness which is caused by the absence of any cone types in the eyes: 3 out of 100,000 men and 2 out of 100,000 women cannot see any color hues, thus their vision is achromatic and solely based on shades of black, gray and white.

S コーンに基づくカラー欠陥は、赤と緑の色合いに基づく影響をもたらす。つまり、青と黄色の組み合わせによる、補足的なカラーの知覚が不正確なものとなる。 ただし、このようなケースは、100,000人のうち4人の男性と、2人の女性という、きわめて稀なものとなる。 また、あらゆるコーン・タイプの欠如により引き起こされる、色盲についても同じことが言える。 つまり、100,000人のうち3人の男性と 2人の女性が、カラー・アピアランスを見ることができない。したがって、それらの人々の視界は無色であり、黒/灰/白をベースにしたものとなる。

Based on the data in Figure 5 the typical person suffering from color deficiency is a man having problems perceiving red and green. The chance that a person has color perception problems other than for red-green is very low. Actually, the chance that a person will suffer epileptic seizures triggered by blinking UI elements on the screen is 400 times higher [6].

Figure 5 のデータから分析すると、カラー欠陥に苦しむ大半の人々は、赤と緑の知覚に問題を抱える男性となる。 したがって、赤と緑を除いたカラー知覚により、問題が引き起こされる確率は、きわめて低くなる。 また、スクリーン上で点滅する UI 要素により、てんかんの発作が引き起こされるという確率は、一般の 400倍以上という、きわめて高いものとなる[6]。

The question is to what extent color deficiency poses a problem for the usability of a product. The answer is that it depends on the nature of the application. In all those cases where colors are used for aesthetic reasons like on most company homepages, the impact of color perception problems is lower than for systems that use color to indicate status of any kind, e.g. control systems and dashboards. In general, it is recommend not to rely on color alone for coding important information. For example, indicating a system status via virtual red and green lights, is a problem for people with red-green color deficiencies. They would have a hard time differentiating between the red and green lights. So it is recommendable to provide a meaningful text label (“OK” vs. “Alarm”) or a symbol (checkmark vs. exclamation mark) in addition to the color coding.

ここでは、プロダクトの有用性に問題をきたさないためには、どの程度までのカラー欠陥が許容されるのか、という論点を掘り下げていく。 その答えは、アプリケーションの性質に依存するものとなる。大半の企業のホームページなどの、色彩感覚が重視されるケースでは、このような問題の生じる可能性は低くなる。しかし、たとえばコントロール・システムやダッシュボードといった、各種のステータスを示すためのカラーは、そうとは限らない。 一般的には、重要な情報を記号化する際に、カラーだけに頼らない方式が推奨される。 たとえば、仮想的な赤と緑のライトによりステータスを示すシステムは、赤と縁のカラー欠陥を持つ人に対して、問題を引き起こしてしまう。 それらの人々は、赤と緑のライトを識別するのに、苦労するはずだ。 したがって、カラー表現のほかに、意味のあるテキスト・ラベル(OK と Alarm)や、シンボル(チェックマーク や 感嘆符)なを提供する方式が推奨される。

Colors and Visual Appeal

Colors are well suited to increase the visual appeal of a software product. We associate certain meanings with specific colors (Figure 6). These color stereotypes can be leveraged when designing a UI. For example, it may make sense to base a clinical software application on white as this color is associated with cleanliness. Another example is the homepage of the United Nations [7] which is held in blue, thus conveying peacefulness.

ソフトウェア・プロダクトを、ビジュアルにアピールするためには、カラーの使い方が適切な要因となる。 そのため、私たちは、特定の意味を、特定のカラーに結びつける(Figure 6)。 こうしたカラーのステレオタイプが、 UI をデザインする際に促進される。 たとえば、白が清潔さと結び付けられるなら、病院用のアプリケーションを白ベースにすることが意味を持つ。 もう 1つの例は、ブルーの色調を保ち、穏やかさを伝える United Nations(国連)のホームページである[7]。

UX_2_6

Figure 6: Western color stereotypes.

It should be noted that the color associations in Figure 6 pertain to western culture. Because color stereotypes are culture-dependent, they can be quite different in other areas of the world. Red, for example, means “Death” in Egypt, “Life” and “Creativity” in India and “Happiness” in China [9].

Figure 6 におけるカラーの組み合わせが、西欧文化に付随している点に注意して欲しい。 カラー・ステレオタイプは文化依存であるため、世界中の個々のエリアにおいて、きわめて異なるものにもなり得る。 たとえば、赤は、エジプトでは死を、インドでは人生と創造力を、そして中国では幸福を意味する[9]。

Appealing UIs feature sets of colors that are coordinated and harmonious. Creating color schemes is a skill that is anything but trivial because there are many factors to consider, including that the company’s brand value has to be communicated and color associations may be needed to be provoked (see color stereotypes above). Care has to be taken that ergonomic issues are considered as well (see contrast effects above).

UI をアピールするためには、調整され調和するカラーのセットが重要となる。 企業ブランドの価値を伝える必要性や、刺激的なカラーの組み合わせを含めて、考慮すべき多数の要因があるため、カラー・スキーマの作成は、きわめて重要なスキルとなる(上記のカラー・ステレオタイプを参照)。 また、人間工学的な視点に関しても、慎重に考慮しなければならない(上記のカラー・コントラストを参照)。

There are a couple of different ways to create simple color schemes without the help of a graphical designer [10]. For example, you can pick any three colors which are side by side on a 12 part color wheel (analogous colors, see Fig. 7). Or you can select colors that lie directly opposite to each other on the color wheel (complementary colors). Remember though that the combination of red and green is critical for people with red-green color deficiencies (see color deficiency above).

グラフィカル・デザイナーの手助けを必要とすることなく、シンプルなカラー・スキーマを作成するための、2つの方式がある[10]。 たとえば、12の領域に分割されたカラー・ホイールから、3つの隣接するカラーを選ぶことができる(類似色・Figure 7を参照)。 あるいは、このカラー・ホイール内の、対極に位置するカラー(補色)を選択することも可能だ。 ただし、赤と緑の組み合わせは、その知覚に欠陥を持つ人々にとって、重大問題を引き起こすことを忘れないで欲しい(上記のカラー欠陥)。

UX_2_7

Figure 7: Color scheme based on analogous colors.

<おわり>

References

[1] ISO 9241-110 (2006). Ergonomics of human-system interaction – Part 110: Dialog principles. Berlin: Beuth.

[2] Nielsen, J. (1994). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability Inspection Methods. New York City: John Wiley & Sons.

[3] Wyszecki, G, Stiles, W.S. (1982). Color science. 2nd edition. New York City: John Wiley & Sons.

[4] Gleitman, H. (1991). Psychology. 3rd Edition. New York City: W.W. Norton & Company.

[5] Kaiser, P. K., Boynton, R. M. (1996). Human Color Vision. Washington, D.C.: Optical Society of America.

[6] Fisher R.S., Harding G., Erba G., Barkley G.L., Wilkins A. (2005) Photic- and pattern-induced seizures: a review for the Epilepsy Foundation of America Working Group Epilepsia, 46 (9), 1426-1441.

[7] http://www.un.org/

[8] Waters, C. (1996). Web Concept & Design. Indianapolis: New Riders Publishing.

[9] Russo, P., & Boor, S. (1993). How fluent is your interface? Designing for international users. INTERCHI ’93. 342-347.

[10] Williams, R. (2008). The Non-Designer”s Design Book. 3rd Edition. New York City: Peachpit Press.

ーーーーー

image

ーーーーー

色を知覚するメカニズムについて、また、それに関連するアクセシビリティ、そして 文化(ローカルな特質)についてまで、とても興味深い内容のコンテンツでした。 以下は、本家ブログの方についているコメントです。

Great article. Color combinations listed in figure 4 provide a quick and efficient checklist.

I found this article very informative. I do defence based work, and work to strange HMI requirements like ‘avoid red text on dark blue background’ etc. After reading this I now understand the theory behind such requirements.

まさに、Great Article です! (面白すぎて朝になっちまったw)ーーー A.C.

ーーーーー

<関連>
カラー と ユーザー・エクスペリエンス _1
ユーザーのためのデータ・ビジュアライゼーション
UX と テキスト の関係を、論理的に解明する

Tagged with: , , ,

カラー と ユーザー・エクスペリエンス _1

Posted in UX by Agile Cat on May 26, 2010

Colors and User Experience _1

http://community.infragistics.com/ux/articles/colors-and-user-experience.aspx

image

UX_2_0

As the name suggests, GUIs (Graphical User Interfaces) present their features and functions visually. The human-computer interaction is heavily based on seeing things, looking for things and interacting with graphical UI elements. Color is a main characteristic of any visual scene, not only on computer screens, but in any situation where we see something. Because most of what we see and interact with in our everyday life is colored (as opposed to shades of white-gray-black), we are very familiar with colors – maybe so much that we don’t think about them a lot. On the other hand, it does bother us when we need to read a dark-gray label on a black button. So colors have the potential to boost or wreck the user experience. The rest of the article will introduce the concept of user experience and highlight some aspects of colors and color perception together with recommendations for UI design.

その名前が示唆するように、GUI(Graphical User Interfaces)とは、そこに含まれるが特徴や機能を視覚的に表現するものである。 人間とコンピュータのインタラクションは、グラフィカルな UI 要素を用いた、視認と、参照、そして相互作用に大きく依存するものとなる。 色の使い方は、ビジュアルな観点における最大の特質であり、コンピュータのスクリーン上だけではなく、私たちが物を見るという、あらゆる状況においても重要だ。なぜなら、日常の生活で見分けるもの、そして相互に作用するものは、その大部分が色付されているからである(white-gray-black による影の対極として)。それほどに、カラーは私たちにとって馴染み深いものだが、あまり深く考えられていないという面もある。 その一方で、スクリーン上の黒いボタンの上に書かれた、濃い灰色のラベルを読むときに、私たちは悩まされる。つまり、カラーにより、ユーザー・エクスペリエンスは向上することもあれば、劣化することもあり得る。 この記事では、ユーザー・エクスペリエンスの概念を紹介すると共に、カラーに関する側面や、UI デザインで推奨される色彩感覚について取り上げていく。

User Experience

User Experience (UX) is a concept pertaining to the overall – or holistic – encounter between users and interactive technical systems. More concretely, it’s the degree of usability and appeal that a website or application provides to its users. Great usability implies that an interactive product allows its users to efficiently accomplish their goals. Well-known guidelines are provided by ISO 9241-110 [1] and Nielsen’s Heuristics [2].

ユーザー・エクスペリエンス(UX)は、ユーザーと対話型のテクニカルなシステムの間を結ぶ、あらゆる局面に付帯する概念である。 さらに具体的にいうと、それは有用性の度合いであり、また、Web サイトあるいはアプリケーションがユーザーを惹きつける魅力のことになる。 優れた有用性とは、ユーザーによる効率的な目的の達成を実現する、対話型のプロダクトのことを意味する。 広く知られるガイドラインとして、ISO 9241-110 [1] と Nielsen’s Heuristics [2] が提供されている。

Appeal refers to the emotional tie between users and a system they are interacting with. Do users love it? Hate it? Do they think it’s attractive or modern or engaging? Do they feel pride when they interact with it? Although appeal cannot be defined as concisely as usability, it is of equal importance for the success of a product because appealing systems are more enjoyable and desirable which increases their value.

魅力のアピールとは、ユーザーと相互作用するシステムの間の、感覚的な絆のことである。 それを、ユーザーは好むのだろうか? それとも、好まないのだろうか?  ユーザーに対して、素敵だと感じさせ、モダンだと思わせ、とりこにすることが出来るのだろうか? そして更に、それと相互作用するユーザーに、誇らしい気分を提供できるだろうか? 魅力については簡潔に定義できないが、システムの魅力をアピールすることは、その価値を高める感覚的な要因となるため、プロダクトを成功させるという意味で、有用性と同等の重みを持つ。

UX_2_1 Figure 1: User Experience

Colors and the UI

Color is the sensation that is invoked when light of wavelengths between 360nm and 720nm hits our eyes and then is processed by our visual system [3]. Our eyes feature three types of color receptors, each maximally receptive to long, medium, and short wavelengths of light. These are known as L-, M- and S-cones. As it can be seen in Figure 2, a light with a wavelength of 530nm triggers the M-cones most, the L-cones slightly less and the S-cones just a little. The perceived color impression would then be a green.

カラーとは、 360nm~720nm の波長の光が、私たちの目を刺激するときに検知され、続いて、視覚システム[3]により処理される知覚のことである。 私たちの目は、3種類のカラー感覚器官を特徴とし、それぞれが、長/中/短の波長を極限まで受容する。 それらの概念は、L/M/S コーンとして知られている。 Figure2で確認できるように、530nm の波長を持つ光は、その大部分が Mコーンを引きおこし、Lコーンはやや少なく、Sコーンはほとんど無いという状況である。 この波長は、グリーンとして知覚されるだろう。
   

UX_2_2

Figure 2: Color perception is achieved through three cone types (after [4]).

On computer screens colors are defined through the RGB color model (R stands for red, G for green and B for blue). These three colors are called primary colors and correspond to the wavelengths the L-, M- and S-cone are most receptive for. Primary colors cannot be generated by mixing other colors. Instead, by mixing primary colors, all other colors can be generated. Each pixel on a screen shows a color generated by the interplay of one red, one blue and one green light source that are so close to each other that they cannot be distinguished.

コンピュータ・スクリーン上のカラーは、RGB カラー・モデル(R stands for red, G for green and B for blue)を介して定義される。 これらの3つの色は原色と呼ばれ、L/M/S コーンを受け入れる波長に対応する。 他の色を混ぜ合わせても、これらの原色を作ることはできない。 その反対に、原色を混ぜることで、すべての色を生成できる。 スクリーン上の個々のピクセルが識別できないほどに隣接し、また、赤/青/緑のライトが相互作用することで、カラーを生み出す。

Color Contrast

Typically, a colored object or area on a UI is not displayed in isolation, but is adjacent to or superimposed on another colored object or area. This creates contrast effects. Without sufficient contrast, we could not discriminate different parts on our screen. There is a good reason why office applications like MS Word, Powerpoint, Excel, Outlook, etc. are based on a white background with black as a default font color – this provides the maximum contrast and therefore optimum legibility.

一般的に、UI における色付されたオブジェクトやエリアは、個別に表示されるものではなく、別の色を持つオブジェクトやエリアと、隣接したり、重なりあったりする。 それにより、コントラストの効果が引き起こされる。 充分なコントラストが無いと、スクリーン上の個々のパーツを識別できなくなるだろう。 Word や、Powerpoint、Excel、Outlook といった Microsoft Office 製品が、デフォルトとして白い背景と黒のフォントを使う背景には、このような理由がある。つまり、最大のコントラストと、最適化された視認性を提供することになる。

Apart from this, color contrast can be deliberately used to draw the visual attention of users to relevant UI elements that feature important information or require inputs.

それとは別に、たとえば、ユーザーを視覚的に惹きつけ、重要な情報を提供する UI 要素や、入力を要求する UI 要素に対して、意図的にカラー・コントラストを適用することも可能である。

Color contrast also lends itself well to boost the visual appeal of a UI. Empirical studies show that warm colors (e.g. red, yellow, orange) are preferred on backgrounds of cool colors (e.g. blue, green, purple) and vice versa.

カラー・コントラストは、UI の視覚的なアピールを、それ自身で高めるという働きも持つ。実証的な研究では、暖色(たとえば red, yellow, orange)と、寒色(たとえば blue, green, purple)の対比が好まれるという、結果が示されている。

Contrast effects can also be detrimental for the user experience. Two prominent examples are discussed in the following. In general, any region in the visual field tends to induce its complementary color in neighboring areas. For example, a gray square will tend to look greenish when surrounded by red, and reddish when it is surrounded by green. This effect is known as simultaneous color contrast [4]. On UIs it can sometimes be seen that the same control, e.g. a push button, looks strikingly different on backgrounds of different colors.

また、コントラストは、ユーザー・エクスペリエンスにとって有害なものにもなり得る。 2つの顕著な例について、以下に説明する。 まず、一般的に、あらゆる視覚的な領域において、隣接するエリアを補色を誘発するという傾向を持つ。 たとえば、グレーの正方形は、赤に囲まれると緑色っぽく見え、緑色に囲まれると赤っぽく見えるという傾向にある。 この効果は、同時色対比として知られている[4]。 UI においては、たとえばプッシュ・ボタンなどの同一のコントロールが、異なる背景色の上では別のものに見えるという状況が、ときおり確認できる。

Another problematic contrast effect is chromatic aberration [5]. Lenses, including the lenses in our eyes, bend lights of different wavelengths by unequal amounts. The effect is that different colored stimuli are not projected at the same spot at the retina – an effect most noticeable for combinations of violet and red as well as blue and red (see Figure 3), because the wavelengths of violet and blue are at one end of the visual spectrum while the wavelength of red is at other end (see Figure 2).

コントラストにおける、もう1つの問題は色収差である[5]。 私たちの眼球を含めて、レンズは、それぞれの波長の光を、不等な量で屈折させる。 この効果により、それぞれの色による刺激が、網膜上の同じスポットに投影されなくなる。つまり、最も目立つ組み合わせは、violet/red と blue/red (see Figure 3) になるが、その理由は、violet と blue の スペクトルが左端にあるのに対して、red は右端にあるからだ (see Figure 2)。

UX_2_3

Figure 3: The effect of chromatic aberration.

Consequently, the text in Figure 3 looks blurred against the background. Because of this, contrasts of red and violet/blue should be avoided on a UI. Despite this, red-blue color contrasts are pretty common, possibly because the person designing the UI tries to avoid the combination of red and green due to color deficiency reasons (see color deficiency below). Figure 4 shows combinations of background and foreground colors that provide a good contrast.

したがって、Figure 3 のテキストは、背景に対して不鮮明になる。 このような理由から、violet/red と blue/red のコントラストは、UI では避けるべきものとなる。 それにもかかわらず、色覚異常の理由から  red/green の組み合わせは回避される。 そのため、残された blue/red の組み合わせは、UI デザイナーにとって一般的なものとなる。 Figure 4 が示すのは、適切なコントラストを提供する、バックグラウンド/フォアグラウンドの、カラーの組み合わせである。

UX_2_4

Figure 4: Color combinations providing good contrasts.

ーーーーー

References

[1] ISO 9241-110 (2006). Ergonomics of human-system interaction – Part 110: Dialog principles. Berlin: Beuth.

[2] Nielsen, J. (1994). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability Inspection Methods. New York City: John Wiley & Sons.

[3] Wyszecki, G, Stiles, W.S. (1982). Color science. 2nd edition. New York City: John Wiley & Sons.

[4] Gleitman, H. (1991). Psychology. 3rd Edition. New York City: W.W. Norton & Company.

[5] Kaiser, P. K., Boynton, R. M. (1996). Human Color Vision. Washington, D.C.: Optical Society of America.

ーーーーー

<続く>

image

ーーーーー

<関連>
カラー と ユーザー・エクスペリエンス _2
ユーザーのためのデータ・ビジュアライゼーション
UX と テキスト の関係を、論理的に解明する

Tagged with: , , ,

3D DESKTOP : BumpTop と Cube Effect を Youtube で ど~ぞ!

Posted in Google, UX by Agile Cat on May 3, 2010

Google が買収したらしいですね、BumpTop を・・・

デスクトップにはこだわりのある Agile_Cat ですが、BumpTop は知りませんでした。 以前に、Cube Effdect というのを使ってみたことがあるのですが、そちらが 凸型だとすれば、BumpTop は 凹型なのが新鮮です。 Chrome OS の目玉にするのでしょうかね? Maemo 5 にも分けてくださいな~~~。

engadget より ・・・

数年前からデモ動画が公開されては地味に話題を呼んでいた3Dデスクトップ BumpTopの一般向けダウンロードが始まりました。BumpTopはデスクトップを壁のある3D空間にしたうえで、ファイルやフォルダのアイコンに物理シミュレーションで重さや慣性、衝突判定まで持たせたデスクトップ置換環境。書類を積み上げたり脇に寄せるといったリアルデスクトップのあまり良くない面を再現できるほか、ファイル種別ごとにまとめてグリッド表示やカードを広げるようにファン表示したり、よく使う文書を大きく・重くする、作業のコンテキストごとにパイルを作って整理するといったことが可能になります。目的のファイルを探し出したいときはただキーボードで検索語を入力すれば、インクリメンタルに該当ファイルが絞り込み&ハイライトされてゆく仕組み。

http://japanese.engadget.com/2009/04/08/physics-3d-bumptop/

それで、こちらが 凸型 Cube Effdect です。 以前は重くて使うのをやめてしまったのですが、考えてみれば、その後にグラボを新調しているので、また トライしようかと思っています。

たかが DeskTop、されど DeskTop。 連休中にはもってこいの、お楽しみかもしれませんね。 ーーー A.C.

%d bloggers like this: