Long Tail World さんから Apple ネタを中心に ･･･

今週も面白い話が満載です！

どうやって、こんなに面白い話を見つけ出してくるのやらと、いつも感心してしまう Long Tail World こと Satomi Ichimura さんですが、今週も楽しい話題が満載です。 なかでも、株の世界で損している人 『 No.1 』 が、あの Steve Jobs さんだったとは、読んでみればナルホドなのですが、にわかには信じられない話です。また、iPad の影に隠れて値崩れしまくっている iPhone の話など、米国事情を楽しくお勉強してください。 ーーー A.C.

May 24, 2010 史上最も株ですった男ジョブズ The Dumbest Trade Ever = Steve Jobs’ $10B Loss May 25, 2010 米ウォルマート、iPhone 3GSを8720円で叩き売り Wal-Mart slashes iPhone 3GS price to $97 May 26, 2010 コンピュータウィルスに感染した人間 First human ‘infected with computer virus’ – BBC May 26, 2010 アップル、マイクロソフトを抜く Apple Overtakes Microsoft May 28, 2010 ハーバード大心理学講師が語る「今日から幸せになれる5つの方法」 Five Ways to Become Happier Today May 29, 2010 こっちの朝刊にまでギズの被り物が… Gizmodo Japan staffs on Mercury News

それと、Agile_Cat 的にお薦めなのは、今日から幸せになれる5つの方法です。これまた、読んでみればナルホドです。  、、、というわけで、幸せな日曜日を ど～ぞ。

ーーーーー

＜関連＞
App Store を凌駕する、Touch Screen Web サイトの成長
Apple は Web-based サービスの重要性を理解していない、、、と Tim O’Reilly
米当局が Apple を反トラスト法で調査？ May 3, 2010
歓迎すべきことに、Apple は制空権を失いつつある
Jobs の Adobe 批判って、自爆してません？

メジャー･クラウドの比較テスト Part_1 ： 性能は Amazon S3 と Azure が圧勝

End-To-End Performance Study of Cloud Services
Wednesday, May 26, 2010 at 4:49PM
http://highscalability.com/blog/2010/5/26/end-to-end-performance-study-of-cloud-services.html

メジャー･クラウドを並べた、初めてのテストだと思います。性能に関しては、Amazon S3 と Azure が圧勝と書きましたが、あくまでも Many-Wtite-Many-Query の形態のようであり、Write-Once-Read-Many ではありません。 そのため、Google App Engine などは散々な結果となっています。 文中にも、イベンチュアル･コンシステンシーを前提としたテスト（Part_2?）を計画中と書いてありますが、そちらでは別の結果がでると予測されます。 クラウドにおけるワークロード･モデルは 1つでは有りませんが、一般的なエンタープライズ･モデルにおいては、このテスト結果 Part_1 が適用できるはずだと思います。ーーー A.C.

ーーーーー

Cloud computing promises a number of advantages for the deployment of data-intensive applications. Most prominently, these include reducing cost with a pay-as-you-go pricing model and (virtually) unlimited throughput by adding servers if the workload increases. At the Systems Group, ETH Zurich, we did an extensive end-to-end performance study to compare the major cloud offerings regarding their ability to fulfill these promises and their implied cost.

クラウド･コンピューティングが約束するのは、データ･セントリックなアプリケーションのディプロイメントにおける、数多くのアドバンテージである。 最も顕著なものには、ワークロードの増加に応じたサーバーの追加により、pay-as-you-go の料金モデルと、（事実上）無制限のスループットを実現し、コストを削減することも含まれる。 ETH Zurich の Systems Group では、大規模な End-to-End パフォーマンス実験を行い、それらの約束と暗黙のコストを満たす能力について、メジャー･クラウドを比較した。

The focus of the work is on transaction processing (i.e., read and update work-loads), rather than analytics workloads. We used the TPC-W, a standardized benchmark simulating a Web-shop, as the baseline for our comparison. The TPC-W defines that users are simulated through emulated browsers (EB) and issue page requests, called web-interactions (WI), against the system. As a major modification to the benchmark, we constantly increase the load from 1 to 9000 simultaneous users to measure the scalability and cost variance of the system.  Figure 1 shows an overview of the different combinations of services we tested in the benchmark.

この作業におけるフォーカスは、ワークロード（Read / Update）の分析というよりは、トランザクション処理にあった。比較のためのベースラインとしては、Web-shop をシミュレートするための標準的なベンチマークである、TPC-W を用いている。この TPC-W が定義するのは、EB（Emulated Browser）を介してエミュレートされるユーザーと、ページ･リクエストの発行であり、それれは、システムに対する WIPS（Web Interaction Per Second）と呼ばれるものとなる。 このベンチマークに対する主要な修正としては、対象システムのスケーラビリティとコスト相違を測るために、シュミレートされる同時使用ユーザー数を、1～9000 間でリニアに増やせるようにしたことである。  Figure 1 が示すのは、このベンチマークでテストしてサービスの、それぞれの組み合わせに関する概要である。

Figure 1: Systems Under Test

The main results are shown in Figure 2 and Table 1 – 2 and are surprising in several ways. Most importantly, it seems that all major vendors have adopted a different architecture for their cloud services (e.g., master-slave replication, partitioning, distributed control and various combinations of it). As a result, the cost and performance of the services vary significantly depending on the workload. A detailed description of the architectures is provided in the paper. Furthermore, only two architectures, the one implemented on top of Amazon S3 and MS Azure using SQL Azure as the database, were able to scale and sustain our maximum workload of 9000 EBs, resulting in over 1200 Web-interactions per second (WIPS).  MySQL installed on EC2 and Amazon RDS are able to sustain a maximum load of approximate 3500 EBs. MySQL Replication performed similar to MySQL standalone with EBS, so we left it off the picture. Figure 1 shows that the WIPS of Amazon’s SimpleDB grow up to about 3000 EBs and more than 200 WIPS. In fact, SimpleDB was already overloaded at about 1000 EBs and 128 WIPS in our experiments. At this point, all write requests to hot spots failed. Google AppEngine already dropped out at 500 emulated browsers with 49 WIPS. This is mainly due to Google’s transaction model not being built for such high write workloads. When implementing the benchmark, our policy was to always use the highest offered consistency guarantees, which come closest to the TPC-W requirements. Thus, in the case of AppEngine, we used the offered transaction model inside an entity group. However, it turned out, that this is a big slow-down for the whole performance. We are now in the process of re-running the experiment without transaction guarantees and curios about the new performance results.

Figure 2 と、Table 1 ｰ2 示される主な結果は、いくつかの面で驚きをもたらす。 最も重要なことは、それぞれのクラウド･サービスにおいて、メジャー･ベンダーが異なるアーキテクチャを採用している点だと思われる（たとえば、マスター･スレーブ･リプリケーション／パーティショニング／分散制御／多様な組み合わせなど）。 その結果として、サービスにおけるコストとパフォーマンスは、ワークロードに応じて大幅に変化する。個々のアーキテクチャに関する詳細は、このペーパーで提供されている。 さらに、だた 2つのアーキテクチャである、Amazon S3 と MS Azure（SQL Azure ）に実装されたものだけが、9000 EB という最大のワークロードをスケールし、また、維持することが可能だった。 それは、毎秒 1200 WIPS という値に相当する。 Amazon の EC2 と RDS 上インストールされた MySQL は、3500の EB の最大ワークロードを支えることが可能だった。 MySQL Replication のパフォーマンスは、EBS を用いたスタンドアロン MySQL と同等であるため、Figure 2 から削除している。 また、Amazon SimpleDB の WIPS は、最大で約 3000 の EB と、200 の WIPS まで伸びている。 ただし、 私たちの実験では、SimpleDB は 1000 EB と 128 WIPS の辺りで、すでにオーバーロードをきたしている。 つまり、この時点にいおて、ホットスポットに対する、すべての書込みリクエストが失敗している。 Google AppEngine は、500 EB／49 WIPS 辺りで、すでに脱落している。Google のトランザクション･モデルが、このような高度な書込みワークロードに対応していない点に、その要因がある。 このベンチマークを実装するときのポリシーは、最も強固なコンシステンシーを保証するものであり、それは TPC-W 要件に最も近いものとなる。 したがって、AppEngine のケースでは、エンティティ･グループ内にトランザクション･モデルを提供する手法を用いた。 しかし、結局のところ、その手法がパフォーマンス全体を大きくスローダウンさせることになった。 そのため、現時点において、トランザクション保証と従来からの観点を用いることの無い、新しいパフォーマンス結果をもたらすための、再実験を進めているところだ。

Figure 2: Comparison of Architectures [WIPS]

Table 1 shows the total cost per web-interaction in milli dollar for the alternative approaches and a varying load (EBs). Google AE is cheapest for low workloads (below 100 EBs) whereas Azure is cheapest for medium to large workloads (more than 100 EBs).  The three MySQL variants (MySQL, MySQL/R, and RDS) have (almost) the same cost as Azure for medium workloads (EB=100 and EB=3000), but they are not able to sustain large workloads.

Table 1 が示すのは、WIPS に関する 1/1000 ドル単位でのトータル･コストであり、変動する EB に対応する別の指標となる。 ミドルからラージの負荷（100 EB 以上）では Azure が最も低価格なのに対して、Google AE はスモール（100 EB 以下）で最安値となる。 MySQL の 3つの派生物（MySQL、MySQL/R、RDS）は、ミドルの負荷（100~3000 EB）では Azure に等しいが、ラージの負荷を維持できない。

Table 1: Cost per WI [m$], Vary EB

The success of Google AE for small loads has two reasons.  First, Google AE is the only variant that has no fixed costs. There is only a negligible monthly fee to store the database. Second, at the time these experiments were carried out, Google gave a quota of six CPU hours per day for free.  That is, applications which are below or slightly above this daily quota are particularly cheap.

スモールにおける Google AE の成功は、2つの理由による。  最初に、Google AE は固定費を伴わないという、唯一の例外であることが挙げられる。 ただし、データベースをストアするための、微細な月額料金が必要になる。 次に、この実験が実施されたとき、 Google は 6 CPU 時間／日を無償にするという割引を提供していた。  そのため、上下の Table における適用は、通常より低価格となっている。

Azure and the MySQL variants win for medium and large workloads because all these approaches can amortize their fixed cost for these workloads. Azure SQL server has a fixed cost per month of USD 100 for a database of up to 10 GB, independent of the number of requests that need to be processed by the database.  For MySQL and MySQL/R, EC2 instances must be rented in order to keep the database online.  Likewise, RDS involves an hourly fixed fee so that the cost per WIPS decreases in a load situation.  It should be noted that network traffic is cheaper with Google than with both Amazon and Microsoft.  

Azure および MySQL 派生物が、ミドルからラージの負荷において勝者となる理由は、その全てのアプローチにおいて、固定的なコストを償却できるからだ。 Azure SQL Server は、最大で 10GB のデータベースのための USD 100／月への固定コストを伴なうが、データベースが処理する必要のあるリクエスト数は、そこから独立している。  MySQL と MySQL/R では、データベースをオンライン状態に保つために、EC2 インスタンスをリターンしなくてはならない。  同様に、EDS は 1時間単位の固定コストを伴うため、 WIPS ごとのコストが負荷の状況にいうて減少する。ネットワーク･トラフィックに関しては、Amazon と Microsoft よりも Google の方が安価なことが指摘されるべきだ。

Table 2 shows the total cost per day for the alternative approaches and a varying load (EBs). (A "-" indicates that the variant was not able to sustain the load.)  These results confirm the observations made previously:  Google wins for small workloads;  Azure wins for medium and large workloads.  All the other variants are somewhere in between.  The three MySQL variants come close to Azure in the range of workloads that they sustain. Azure and the three MySQL variants roughly share the same architectural principles (replication with master copy architectures). SimpleDB is an outlier in this experiment. With the current pricing scheme, SimpleDB is an exceptionally expensive service.  For a large number of EBs, the high cost of SimpleDB is particularly annoying because users must pay even though SimpleDB drops many requests and is not able to sustain the workload.

Table 2 が示すのは、1日あたりのトータル･コストであり、変動する EB に対応する別の指標となる。 （"ー" は、それらの形態でサポートできなかったことを示す）  この結果から確認できるのは、1つ前の観察と同じでことある。 つまり、スモール負荷では Google が勝者であり、ミドルとラージでは Azure が勝者である。  その他すべては、この両者の中間にある。  MySQL の 3つの派生物は、それらが維持できるレンジにおいて、Azure に近い結果をもたらす。 それら全ては、アーキテクチャにおいて、同一の原則を共有している（マスター･コピーを用いたリプリケーションのアーキテクチャ）。 この実験において、SimpleDB は異常値を呈している。 現行の価格スキームにおいて、SimpleDB は例外的に高価なサービスとなる。  大量の EB における SimpleDB は、たとえ多数のリクエストをドロップし、また、ワークロードを維持することが不可能であっても、ユーザーからの支払いが低減されないため、敬遠される存在になる。

Table 2: Total Cost per Day [$], Vary EB

Turning to the S3 cost in Table 2, the total cost grows linearly with the workload.  This behavior is exactly what one would expect from a pay-as-you-go model.  For S3, the high cost is matched by high throughputs so that the high cost for S3 at high workloads is tolerable. This observation is in line with a good Cost/WI metric for S3 and high workloads  (Table 1). Nevertheless, S3 is indeed more expensive than all the other approaches (except for SimpleDB) for most workloads.  This phenomenon can be explained by Amazon’s pricing model for EBS and S3. For instance, a write operation to S3 is hundred times more expensive than a write operation to EBS which is used in the MySQL variant.  Amazon can justify this difference because S3 supports concurrent updates with an eventual consistency policy whereas EBS only supports a single writer (and reader) at a time.

Table 2 における S3 に目を向けると、そのトータル･コストがリニアに伸びているのが分かる。  この傾向は、pay-as-you-go モデルに基づく期待値を、正確にトレースするものとなる。  S3 おいては、コストに応じたスループットが提供されるが、それにより、大きな負荷での高いコストにも納得できるようになる。この観察結果は、S3 と高負荷における Cost/WIPS 指標とも、きれいに一致している。 そにもかかわらず、S3 は作業負荷に関する大半のケースにおいて、他のアプローチ（除くSimpleDB）より高価である。  この現象は、EB と S3 に関する Amazon の価格モデルにより説明することが可能だ。 実際に、S3 への書出しオペレーションは、MySQL 系で用いられる EB 書出しオペレーションと比べて、100 倍ほど高価になる  S3 はイベンチュアル･コンシステンシーのポリシーを用いて、複数の同時アップデートをサポートするのに対して、EB では 1回に 1つの書き込みだけがサポートされるため、Amazon は違いを正当化できるだろう。

In addition to the here presented results, the paper also compares the overload behavior and presents the different cost-factors leading to the here presented numbers. If you are interested in these results and additional information about the test-setup, the paper will be presented at this year’s SIGMOD conference and can also be downloaded here.

ここで提供される結果のほかに、オーバーロードにおける振舞いを比較し、また、異なるコスト要因を提供するペーパーもある。 もし、それらの結果とテスト環境に関する詳細情報に興味があるなら、今年の SIGMOD カンファレンスで提供されるペーパーも、ダウンロードできるようになる。

ーーーーー

それにしても、素晴らしいテストを行ってくれたものです。 このテストの形態は、性能について、また、価格について、クラウドを測定する際の 1つの指標になるでしょうね。 次に予定されるイベンチュアル･コンシステンシー･テストが楽しみです。 ーーー A.C.

 

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

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

初めての方は、その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 が示すのは、何らかの影響を受けた Ｌ／Ｍ／S コーンに基づく、カラー欠陥の発生率である。 1000人のうち80人の男性が、ある種のカラー欠陥を持つが、女性に関しては 4人だけとなる。 Ｌコーンと M コーン のカーブは近い位置にあるため、それらが原因となるカラー欠陥の影響は、類似したものとなる。 L／M コーンに関連する問題が生じる大半のケースにおいて、それは、青と黄色の色合いに基づいたカラー･アピアランスの問題となる。つまり、赤と緑の組み合わせによる、補足的なカラーの知覚が不正確なものとなる。

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］。

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を参照）。 あるいは、このカラー･ホイール内の、対極に位置するカラー（補色）を選択することも可能だ。 ただし、赤と緑の組み合わせは、その知覚に欠陥を持つ人々にとって、重大問題を引き起こすことを忘れないで欲しい（上記のカラー欠陥）。

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.

ーーーーー

ーーーーー

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

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 です！ （面白すぎて朝になっちまったｗ）ーーー A.C.

ーーーーー

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

米政府の Recovry.gov が Amazon EC2 へ移行する！

White House moves Recovery.gov to Amazon’s cloud
by Alex Howard
http://radar.oreilly.com/2010/05/white-house-moves-recoverygov.html

2010年 5月 13日に O’Reilly Rader にポストされた、とても興味深い記事です。 出張中に知りましたが、そのときは 忙しくて読めませんでした。ーーー A.C.

ーーーーー 

Earlier today in a blog post on WhiteHouse.gov, federal CIO Vivek Kundra announced that Recovery.gov would be moving to the cloud. The Recovery Accountability and Transparency Board’s primary contractor, Smartronix, chose Amazon’s Elastic Compute Cloud (EC2) to host the site. NASA has used EC2 for testing, but this will be the first time a government website — a ".gov" — has been hosted on Amazon’s EC2. Kundra estimated the savings to the operational budget to run Recovery.gov at approximately $750,000, with $334,000 coming in 2010 alone.

今朝（5/13）早くの WhiteHouse.gov のブログ･ポストにおいて、連邦政府の CIO である Vivek Kundra は、Recovery.gov がクラウドに移行するだろうと発表した。 具体的に言うと、Recovery Accountability と、Transparency Board の主要コンストラクタである Smartronix は、そのためのサイトをホストする環境として、Amazon Elastic Compute Cloud （EC2）を選んでいる。 すでに、NASA でのテストにおいて EC2 は使用されているが、政府の Web サイトである「.gov」が Amazon EC2 上にホストされるのは、今回が初めてとなる。 Kundra の見積りによると、Recovery.gov を運用するためのコストは $750,000 が低減され、2010年の単年度においても $334,000 が削減される。

"This is a production system," said Kundra, during a press briefing today. "That’s a critical difference from other agencies that have been testing or piloting. We don’t have data that’s sensitive in nature or vital to national security here."

プレス･ブリーフィングの際に Kundra は「これはプロダクション･システムだ。つまりテストやプロトタイプなどを担当する、他の政府機関とは状況が大きく異なる。 ここには、本質的に機密性の高いデータや、国家機密に関する重要なデータは存在しない」と発言している。

The recovery board plans to redirect more than $1 million in computer hardware and software that were being used to host Recovery.gov to fraud oversight operations. It’s a move that Earl Devaney, chairman of the recovery board, said will help identify fraud, waste and abuse in the recovery program.

このリカバリー委員会が計画しているのは、不正を監視する Recovery.gov のホスティングで用いられる、コンピュータのハードウェアとソフトウェアに関する  $1 million のコストを方向転換することである。 それは移行であり、また、このリカバリー･プログラムにおける、不正／浪費／乱用の識別を促進することになると、同委員会の議長である Earl Devaney は発言している。

Devaney said that after a town hall, Smartronix evaluated the cloud computing options and decided to go with Amazon’s public offering. "In terms of competition, part of what we’re trying to introduce is Darwinian pressure in federal IT, including new entrants in government that haven’t been there before, such as Amazon," said Kundra.

タウンホール･ミーティングの後で Devaney は、Smartronix がクラウド･コンピューティングの選択肢を評価し、Amazon がパブリックに提供しているものを使用すると発言した。 また、「競争という観点において、私たちが導入しようとする部分は、政府の IT におけるダーウィン説の適用である。つまり、これまでにはなかった、Amazon のような新しい参加者を政府の中に取り込むことだ｣と、Kundra は発言する。

He also said this represents one of the "first bricks in the foundation that we’re laying" throughout the federal government, in terms of cloud computing. Kundra pointed to an upcoming forum on cloud computing on May 20 where many of the issues that the National Institute for Standards and Technology has been working on will be addressed, including the relationship between the public and private sector.

クラウド･コンピューティングという観点において、それは、連邦政府全体におよぶ基盤の、最初のブロックになるとも発言している。 Kundra は、NIST （National Institute for Standards and Technology）が対応している様々な問題が、公共／民間の関係を含めて、5月20日に開催されるクラウド･コンピューティングのフォーラムで、取り組まれるだろうと指摘した。

Kundra said that the move to Amazon’s public cloud went through tough cybersecurity vetting. "The board and vendor went through a rigorous process, in terms of FISMA checks and balances," said Kundra.

Kundra の発言によると、Amazon のパブリック･クラウドへの移行は、厳格なサイバー･セキュリティの調査を介して行われた。FISMA のチェックとバランスに関して、同委員会とベンダーは苛酷なプロセスを体験したとも付け加えている。

The federal government is actively developing cloud computing case studies, like the use of Saleforce.com’s public cloud by the Department of Health and Human Services (HHS). "Case studies are being used for the broader FedRAMP program," he said. "Look at the Department of Interior: The CIO is considering moving 80,000 emails to the cloud. Look at the investments made at GSA or a recent RFI [Request for Information] around email. Across federal government, you’re seeing a number of agencies putting in a plan."

Department of Health and Human Services （HHS）における Saleforce.com  パブリック･クラウドの利用のように、連邦政府は積極的に、クラウド･コンピューティングのケース･スタディを作っている。「それらのケース･スタディは、広範囲におよぶ FedRAMP プログラムのために使用されている。Department of Interior を見ると、その CIO は 80,000 のメール･アカウントをクラウドに移行しようとしている。 電子メールに関連する GSA あるいは、最近の RFI ［Request for Information ］への投資を確認してほしい。 連邦政府のいたるところで、数多くの機関が計画を実施している」と、Kundra は発言している。

Why move to the cloud now, rather than at the start? "We had concerns about data, pulling it off with hundreds of thousands of feeds," said Devaney. "We found it prudent to do it the old-fashioned way first, then move to the cloud."

スタートの時点ではなく、いまになってクラウドへ移行するのは何故だろう？ 「私たちは、何十万というフィードを用いて、データを上手く処理することに関心があった。 最初に、それを慎重に行うことは、古いスタイルあることに気づき、続いて、クラウドへ移行することにした」と Devaney は発言する。

On May 20, Kundra said the federal government will release data center numbers as part of a larger project to consolidate IT infrastructure. Based upon those findings, further migration to cloud computing may be forthcoming.

連邦政府は 5月20日に、IT インフラを統合するための大規模プロジェクトの一部として、そのデータセンター数を公表するだろうと、Kundra は発言している。 そこでの結論に基づいて、さらなるクラウド･コンピューティングへの移行が、もうすぐ始まるだろう。

ーーーーー

＜関連＞
とても重要な NIST のクラウド定義：対訳
総務省 自治体 クラウド ポータル サイトって、これで良いの？
台湾政府のしたたかなクラウド戦略
総務省と経済産業省は共振している: @ytaniwaki 氏のまとめ
経産省の Twitter に掲載された、とても真摯なメッセージ
総務省 スマート･クラウドに対するパブコメと議論 on Twitter （まとめ）

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

Colors and User Experience _1

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

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.

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

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種類のカラー感覚器官を特徴とし、それぞれが、長／中／短の波長を極限まで受容する。 それらの概念は、Ｌ／Ｍ／S コーンとして知られている。 Figure２で確認できるように、530nm の波長を持つ光は、その大部分が Mコーンを引きおこし、Ｌコーンはやや少なく、Sコーンはほとんど無いという状況である。 この波長は、グリーンとして知覚されるだろう。
   

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）を介して定義される。 これらの３つの色は原色と呼ばれ、Ｌ／Ｍ／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)。

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 が示すのは、適切なコントラストを提供する、バックグラウンド／フォアグラウンドの、カラーの組み合わせである。

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. 2^nd 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.

ーーーーー

＜続く＞

ーーーーー

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