Build 2014 : Day 1-1 Windows Phone

ついに今年の Build が始まります。まずは初日の Keynote です。いつものごとく DJ を呼んでかなりのボリュームで音楽を流し続けており、朝から盛り上がります!(個人的にはラスベガスでの MIX を思い出します。)

TerryMyerson

Operating Systems Group の EVP である Terry Myerson が仕切り役となって始まりました。Keynote は day 1 と day 2 の2回がありますが、初日は Devices & Services / Mobile first, Cloud first といったビジョンステートメントでいうところの Devices / Mobile に特化した話となりました。私としてもクライアントサイドの話は主戦場でありますので、大変期待している内容でした。マイクロソフトの全てのプラットフォームに携わる者が目指していることは、関わっていただいている全てのパートナーや開発者をモチベートし、「your creativity come to life : 皆さんの創造性を輝かせること」である、と話していたことが冒頭では印象的でした。

JoeBelfiore

まずは Mobile first の先鋒として Windows Phone について Joe Belfiore : CVP, Operating Systems Group が詳細に伝えています。 彼は以前から Windows Phone の顔役といった感じですが、出世して担当範囲が広くなった今でもやはり彼が話さないと始まらないといった感じです。特に新興国などでのビジネス的な成功や新たなパートナーシップについて伝えたのち、メジャーアップデートになる Windows Phone 8.1 について話しています。Windows Phone について「最もパーソナライズドされたスマートフォン」と位置づけ、 More personal, tailored (もっとパーソナルに、仕立てられた) 体験を意識して開発されたとのことでした。

ActionCenter
[command center]

InteractiveLockScreen
[Interactive Lock Screen]

BackgroundTiles
[image live tiles]

これまで以上にインタラクティブなロックスクリーンテーマの導入や、タイルカスタマイズなどが発表され、その後「She comes to life」という発言が出た時に会場の多くの人たちが次に起こることに気づいてざわめいていました。噂されていた Cortana の発表です。 iOS における Siri の位置づけに当たるものと思って間違いありませんが、大きく違うのは Bing と連携することによってユーザーの指向性を把握しており、よりアクティブなパーソナルアシスタントとして振る舞う事だと話していました。(もともとは Halo というゲームに出てくる AI の名前です)開発にあたっては、実際にパーソナルアシスタントとして働いている人々にインタビューを行い、良い仕事をするために何が必要なのかをリサーチした結果を反映しているとのことでした。(その過程も気になるところです)Beta 版とのことでしたが、かなり認識率も高く(確認できたのは英語だけではありますが)きわめてスムーズな言葉で回答を返していました。Windows Phone に内蔵された通知機能と連携して、場所やスケジュール、人と関わるタイミングなどでタイムリーな通知を行うというデモが行われています。Bing と連携をし、かつパーソナルな情報を Phone で保持することによってアクティブにサポートしてくれるパーソナルアシスタントとして開発されているようでした。

Cortana
[Cortana]

notebook
[Cortana’s notebook]

interests
[interests]

QuietHours
[quiet hours]

Places
[places]

FOundFlightInEmail
[メールの中から旅程を見つけてトラックするかどうかを聞いている]

ScheduleConflict
[スケジュールコンフリクトを知らせている]

findRestraunt
[Bing の検索結果と合わせて四つ星レストランを検索]

Siri との大きな違いは、 Cortana が サードパーティアプリケーションでも利用できるという事でしょう。具体的な API がどうなっているのかなどについては Keynote では触れられていませんでしたが、 Hulu でウォッチリストに動画を追加したり、Facebook で特定の個人のタイムラインを閲覧することなどをボイスコマンドで行っていました。個人的にも音声インターフェイスによるアプリケーション操作については大変興味のあるところなので、これを開発に組み込めるとしたら大変素晴らしいことだと思います。(できれば Windows 8 でも使えるようになってほしいですね。)「競合」とは違って、ローエンド端末を含む全ての 8.1 アップデート対応端末で利用できるとのことでした。 Cortana は当初はUSからBetaが始まり、その後UK、中国と開始されていくとのことでした。(日本でどうなるかは不明です)

3rdPartyApps
[3rd party apps]

また、ビジネス利用についても力を入れていることが発表され、 Enterprise VPN への対応、 S/MIME への対応によるセキュアなメール利用、 MDM によるローカルコピーの禁止制御などがデモされていました。その他にも細かい機能への対応として、適切な Wifi を案内する Wifi sense や Word flow keyboard 、設定情報のデスクトップとの同期や IE11 などが発表されていました。実際の市場への投入は今後数か月をかけて行われるとのことです。

nickHedderman
[Nick Hedderman]

WordFlowKeyboard
[wordflow keyboard]

この後発表されているユニバーサルアプリも考えると、Cortana など個人的にも利用したくなる機能もあり、日本での投入が期待されるところです。(続く)

Windows Storeの登場は何を意味するのか?

//build/ 以後詳細な情報が公開されていなかった Windows Store ですが、遂に先日サンフランシスコにてイベントが行われ、ビジネスモデルなどの計画が明らかになりました。


Windows Store のビジネスモデル

多くのスマートフォンにおけるストアタイプの利益構造と同じで、初期の利益シェアは70%であるものの、25,000ドル以上を売り上げた場合80%に上昇するようです。多くのアプリの平均的な金額がどのあたりになるのか気になるところです。もちろん最大のインパクトとになるのは、このストアの対象になるのが現在4億を超えるPC全体に対するものになることです。Windows 8 自体が普及するのには時間がかかるのかもしれませんが、ARM CPU ベースの Windows 8 デバイスが出荷されることになれば、かなりのスピードで分母が増えていくことでしょう。既に Windows Live をベースにして課金可能な安定した基板を持っており、XBOX Live などでも応用をしているマイクロソフトですから、インフラが問題になることも無いのではないでしょうか。個人的にも、どのようなアプリケーションがストアに並ぶことになるのか、非常に楽しみです。エンタープライズ用途向けにはストアを経由しないアプリケーション配置の方法も用意されるようです。とはいえ、企業向けのアプリケーションであっても、ストア経由のアプリケーションから様々な影響を受けることは間違いないでしょう。


開発組織に対するインパクトは?

それでは、この動きは開発組織に対してどのようなインパクトをもたらすでしょうか。直近のスマートフォン市場を例にして考えてみます。現在非常に元気のよいスマートフォン市場ですので、新たにネイティブアプリケーションの開発に着手されている会社も多いようです。しかし、多くのケースで「これまでの開発とのスピード感の違い」について違和感を覚えておられます。これまでであれば、たとえコンシューマー市場向けのアプリケーションであったとしてもある程度バージョンリリースで開発期間を固定できたのに対して、スマートフォン向けアプリとなった場合には終わりのないアップデートが待っています。ストアというインフラを通じて販売機会がこれまでになかったほど広がるのと同時に、多くの選択肢の中から選択され続ける努力を怠ることができない、待ったなしの環境に踏み込む事にもなるのです。

そうなってくると、これまでの開発の速度/体制では顧客からの要求に追いつけなくなってしまうケースも多く出てくることでしょう。そんなタイミングであるからこそ、インフラジスティックスとしては UI コンポーネントを利用して開発生産性をこれまで以上に高めることで、この流れに是非乗って頂き、他社との差別化を行い、機会の増大による新たな利益を手に入れていただきたいと考えております。


インフラジスティックスがお手伝いできることは何か?

実は、入社してからの数カ月の間に多くのお客様とお話させていただいた結果として、弊社の製品にご満足いただき、大変うまく活用していただいているお客様にはある共通点があることがわかりました。それは「設計の段階で要件を UI コントロールで満たすことが出来るかを評価」され、それによって開発の難易度を判断し、機能開発の可否判断をされていることです。大変シンプルな事実なのですが、いざ開発に入ろうとする瞬間に生産性をあげるために UI コントロールを探され、結果として弊社の製品にたどり着いて効果を上げる場合ももちろんあるのですが、ユーザインターフェイスに関わる仕様が開発の手戻り要因の多くを占めることは明らかであり、設計の段階で正確なイメージを持っていただくことが難しい領域の一つです。この段階で、弊社の UI コントロールとその機能をひな形として使って頂き、これで十分か、これ以上に必要なところはあるか、と仕様を詰めていただくと、多くのケースで認識齟齬が少なくなり、正確な見積もりをしていただくことが可能になります。もちろん、 UI コントロールを積極的に使っていただくことでプロジェクト期間全体を短くしていただくことが可能です。(仕様を詰める段階で、弊社のサンプルブラウザを使っていただいてるお客様もいらっしゃいました)

effective way to utilize UI controls

ラフな形でコントロールを並べた状態をプロトタイプとして捉え、前述のような設計の推敲に活かされているお客様もいらっしゃいます。やり方はともかく、弊社の UI コントロールを使っていただくことで「UI 開発における手札が多く増えた状態」になるはずですので、設計時点で具体的な状態を意識して頂ければ一層効果が期待できると思われます。また、設計時点での可否判断において弊社のサポートをうまく利用して頂ければ、一層効率よくその後の開発プロセスを進めていただけるはずです。(ある特定の仕様が弊社の UI コントロールで実現できるか?といった内容でサポートへの問い合わせをしていただくケースも多くございます。)

また、そのようなお客様では、年に2回以上行われている弊社の製品アップデートに関しても、新たに手札が増え、既存の環境に対しても新たに価値提供できる可能性があると考えていただいているケースが多く、弊社の製品アップグレードがそのままお客様の製品の価値向上につながっている状態になっているケースもあり、インフラジスティックスとしても大変嬉しく感じております。

もちろん、最初から弊社のコントロールを購入して頂いて手札を増やしていただけると大変嬉しいのですが、それが難しい場合でもトライアルを利用していただくことで、20日間サポート付きでご利用頂けますので、この期間を有効活用していただいてうまく設計工程を進めて頂き、結果として弊社のコントロールが役に立つとわかれば購入していただく、という流れが自然かつ満足度が高いのではないかと思います。

また、要件から実際の実装される姿を想定して設計する時に、 UI コントロールを利用したどのような実装パターンがあるのかについても検討することになるかと思います。弊社はこれまでも Quince という UI パターンブラウザを提供して参りましたが、それらを具体的にどのように UI に落としこんでいくかについて UXワークショップにおいて詳しくお伝えしておりますので、こちらへの参加も合わせてご検討いただければと思います。

Metro の原則でも出てきましたが、あくまでも重要なのは「何を見せるか=コンテンツ」であり、皆様のアイデアから生まれる創造的な部分です。これに対してインフラジスティックスは様々な「ひな形=パターン」を提供し、皆様が本当に差別化出来るポイントに集中していただくためのお手伝いをしたいと考えております。是非弊社の製品/サービスの活用をご検討いただければと思います。


今回は非常に抽象的な内容となってしまいましたが、この数ヶ月感じていたことを Windows Store の報道をきっかけとしてまとめて書かせて頂きました。つい先日NetAdvantage 2011 Volume 2 をリリースさせていただいたところですが、今後も更なる価値向上を目指してアップデートを続けていき、定期的に私を含めたチームBLOGにてご案内していきますので、是非よろしくお願いいたします!

Metro : Windows Phone から Metro を考えてみる(2) – Windows Phone Design Day–(5)

今回も引き続き Windows Phone Design Day のネタをお届けします。このネタで既に5回目なので、リンクをしておきますね。

Metro : Windows Phone から Metro を考えてみる(2) - Windows Phone Design Day – (1)
Metro : Windows Phone から Metro を考えてみる(2) - Windows Phone Design Day – (2)
Metro : Windows Phone から Metro を考えてみる(2) - Windows Phone Design Day – (3)
Metro : Windows Phone から Metro を考えてみる(2) - Windows Phone Design Day – (4)

今回は  “perceived performance” = 見かけのパフォーマンスに関する話題になります。多くのアプリケーション開発ではパフォーマンスを高くするにあたって色々な悩みがあると思います。レスポンスを「即時に」するという仕様は「言うは易し行うは難し」で、特にネットワークを経由したアクセスを前提にしている場合にはどうしてもユーザーを待たせることになってしまいます。その時、どううまく待ってもらえるかがとても大事になります。

perceived performance
[ Perceived Performance ]

100 ms 以下(ボタンタッチ時の挙動など)、500 ms から1秒(リストビューでスワイプした時の Pivot アニメーションなど)、2秒以下(アプリのローディングやメールが飛んでいくアニメーションなど)、2~5秒、5~10秒、10秒以上、もっと長いプロセスと分けて説明していて、2秒以下のものは基本的に Built in common controls に挙動を任せています。適切に UI がフィードバックを返していなければ、デバイスが活きているのかどうかもわからないと感じるものです。メトロの原則にもあるように、アニメーションなどをうまく利用してデバイスが活きていることを伝え、結果として見かけ上のパフォーマンスを高く感じさせます。なんの反応もなく2秒待つことは経験的にもどのユーザーも相当イラッとしますね。w

waiting type
[ Perceived Performance (Cont.) ]

もう少し問題なのは2秒以上待つようなケースです。このようなケースではローディングのためにプログレスバーを出すことになりますが、5秒までなら短時間であるとしてプログレスバーのみ、10秒までなら「%」表示、それ以上の場合は「サーバに接続しています」「データを取得しています」などのサブステップを見せるようにする、などの工夫が必要になるとしています。10秒以上のケースではユーザーはとにかく何が起きているのか不安になりますから、その時点でなにが進行しているのか知らせる必要があります。(場合によっては処理をキャンセルする可能性もあるわけで、その時何が起こるのかも一緒に設計する必要がありますね)

古くは「砂時計」が有名な待たせるモーションでしたが、最近 SAMSUNG の Windows 8 スレートを使っていて気づいたのが、HDDのアクセスランプがないために、何が起こっているのかわからないケースがありました。無意識にアクセスランプを見て、ガリガリと何かやっているな、ということで納得していたのでしょう。タッチインターフェイスになって、より一層全てをダイレクトにユーザーが感じるようになった時、アプリケーションが適切に「頑張っています」「悩んでいます」「誰かの応答を待っています」と伝えてくれなければ、固まってしまったと感じ、その体験が「パフォーマンスが悪い」というイメージの固定化を招いてしまいます。そうならないためにも、適切なモーションを利用するようにしましょう。2秒以下の状況で使うものにも、メールのアニメーションのようにそれぞれのアプリケーションでは工夫の余地が出てくると思います。

Windows Phone Design day では、この他にも様々な話題が取り上げられていました。

Designer insights into Panorama and Pivot ( Chad Roberts, Amy Alberts, 32:18)
→Pivot と Panorama に関する詳細な説明です。
Making Audio Sing on Windows Phone (Matthew Bennett, 34:26 )
→音とアプリケーションの関わりに関する説明です。
Windows Phone Voice ( Karen Kesler, 32:00 )
→セールスやマーケティング的な側面でどのようなメッセージングを行うべきかという話題について説明しています。
Designer Resources: Expression Blend Overview and Roadmap ( Celso Gomes, Peter Blois, 41:20 )
→Blend で WP7 アプリケーションを開発する流れに関する説明です。 
Designer Resources: Windows Phone Documentation ( Chris Kilbourn, 11:18 )
→用意されているガイドラインなどのドキュメントに関する説明です。
Designer Resources: Windows Phone Design Templates ( Chad Roberts, 04:01 )
→.psd で用意されているデザインテンプレートに関する説明です。

かなりたくさんの情報がありますね!Windows Phone 7 はマイクロソフトがとても力を入れているプラットフォームですから当たり前といえば当たり前ですが、これが次期 Windows となればもっと情報は充実してくるでしょう。このとき、タッチファーストであるが故に既存のアプリケーション開発での留意事項と異なることが出てきます。このようなことに対処するためにも、Windows Phone 7 を使ってウォーミングアップをしておくと、スムーズに新しい世界に入っていけるのではないかと考えております。

ここまでお読み頂きました皆様、是非弊社の NetAdvantage for Windows Phone もチェックしてみてください。現行のリリースもたくさん役に立つコントロールがありますが、近々リリースさせていただく11.2においては、Google/Facebook/Windows Liveを利用したアクセスコントロールや、Silverlight では既に提供しております、コントロール設定を維持するための Persistence Framework など、新機能がたくさん追加されます!(現時点ではあくまで予定です。近日中に詳細な情報が弊社BLOGなどで公開されます。)これらのコントロールも活用していただいて、AppHubが賑やかにしてやりましょう!

 

Metro : Windows Phone から Metro を考えてみる(2) – Windows Phone Design Day–(4)

今回も引き続き、Windows Phone Design Day を追いかけていきます。

Deconstructing a Windows Phone application, part 4: Globalization (Ayman Raslan, Franklin Yow : 37:45 )
→国際化対応とローカライズに関する説明です。今回は動画の中身は比較的軽めです。

個人的に、国際化対応は Windows Phone というプラットフォームを扱う上で極めて重要だと考えています。現時点での日本でのシェアはまだまだ少なく、少数のユーザーを相手にアプリケーションをリリースするよりも、NOKIAが大きく力を入れていたりする北米、ヨーロッパなどの市場の多数のユーザーを狙っていかなければアプリケーションを通じての売上は難しいと言えます。逆にいえば、北米、ヨーロッパを入れてもまだまだリリースされていないタイプのアプリがたくさんあることも事実で、iPhone やAndroid に比べて手付かずの領域があるうちに進出しておいたほうが良いと思います。そのためにも、多言語化対応などについては最初から検討に入れておくとよいでしょう。

動画の内容としては、可能な限りコード変更の発生を避け、ja-jp や en-us などのカルチャー単位(英語を利用していても、国によって単位フォーマットなどは異なるケースもあります)でプログラムとは別に管理したリソースを出し分けるように開発しましょう、というような一般的な話が多かったです。

Final messages (Cont.)
[ Globalization : Final messages ]

編集フィールドとコントロールが欧文以外の文字列をしっかりと扱えること(弊社の UI コントロール製品はもちろんそのようになっております!)、IMEなども含めた入力を受け付けられること、ユーザーカルチャーに依存する日付、時間、通貨、数値などを正しく表示できること、U.S. 向けのアプリをただ翻訳しただけのものにしないで、ターゲットユーザー市場に対してデザインされたものであること、などを確認しましょう。

Final messages for intenationalization
[ Globalization : Final messages ]

UTF-8のような正しいエンコードを利用していること、正しいローカライズガイドラインに従っていること(MS は MSDN などでガイドラインを公開しています。)などについても確認しましょう。URLに記載されているサイトではサンプルも含めて様々な情報が公開されていますので、一読されることをお勧めします。

また、一般的な国際化に関する話題を2008年の MIX で講演させていただいた時の動画も紹介しておきます。英語はいまいちですが、内容はそれなりに詰まっているはずです!

http://channel9.msdn.com/Events/MIX/MIX08/T15

次回は、モーションを利用してどのように見かけのパフォーマンスを高く見せるか、という話題について取り上げます。お楽しみに!

Metro : Windows Phone から Metro を考えてみる(2) – Windows Phone Design Day–(3)

取り上げた題材が大きかったためか、なかなか先に進みませんが、前回前々回に引き続き Windows Phone design Day に関する記事となります。タッチインターフェイスにおけるターゲットサイズについて取り上げます。

Deconstructing a Windows Phone application, part 3: Target Sizes ( Tirthankar Sengupta, 13:39 )
→何年もタッチでのターゲットサイズについて調査しているラボの研究者の発表です。

target size 9
[ Target Size Guidelines : 9 mm ]

数百時間に及ぶユーザーリサーチや様々な研究の結果から、タッチターゲットのサイズにおける一種のマジックナンバーとして “ 9 mm ” が導きだされたようです。

targetsizesummary
[ Target Size Guidelines : Summary ]

推奨されるタッチターゲットサイズは9 mm 以上最低でも7 mm 以上とし、その場合は15 mm 以上の幅を持たせる。(てて幅に余裕がない場合に利用する)タッチできるアイテムのビジュアルサイズは4.2 mm 以上にする。ちさなコントロール同士の配置ではうまく間を取る、コントロールをタッチしやすくするためにパディングやバッファを使う、そのターゲットで実際に何が行われるか(task context)を意識して、エラー率を評価する。サマリーで以上のようなことが示されています。後のQ&Aで出てきますが、Windows Phoneにおける 9 mm とはおよそ90ピクセルとして考えているようです。ただし、極端に大きな画面サイズや小さな画面サイズがあった場合はこの限りではないと思いますので、実測の必要はあると思いますが、基本の DPI が 262 DPI と決められているため、想定はしやすいと思います。

仮にこれらのことを今後Windows 8 のメトロに適用する場合には、様々なハードウェアが存在することが予測されるため確実に実測が必要になると思われます。また、Windows Phone のオペレーションでは主に親指が使われるケースが多いですが、それが人差し指になった時、マルチタッチになった時なども想定しておく必要があります。 Windows 8 用のガイドラインも用意されるのではないかと思いますが、今のところ転用する場合には注意するようにしましょう。

implementation size
[ Target Size Guidelines : Implementation ]

上記スライドの右下部分を見てみましょう。これはアプリケーション一覧のある画面ですが、戻るボタンのビジュアルサイズが43ピクセルであるのに対して、タッチターゲットとしてはもう少し広く97ピクセルを確保してあります。そのため9 mm ルールを超えていますね。一方、アプリケーションアイコンについては62 x 62のサイズに対して、次のアイコンまで12ピクセルしか空白がありません。デッドスペースを作らずに上下を均等にタッチターゲットに割り振ってようやく7 mm を超える程度ですが、アプリケーションの名前を示している右のエリアが十分に幅をとっているため、縦幅が小さくてもタッチしやすい構造になっています。

左上で示されているように、実際に目指できる空間と、タッチできる領域間の空間、双方を意識する必要があります。このあたりは別にアプリケーションアイコンを配置する際に開発者が意識することではありませんし、テンプレートはこのようなルールを意識して作られていますが、テンプレートを超えた実装を行う場合にはこのルールを思い出す必要が出てきますね。

research background
[ Target Size Guidelines : Research Background ]

どうやって9 mm ルールに達したかの背景もしっかり書かれています。興味のある方はご覧下さい。実際には、エラー率などはタッチの反応レベルなどのハードウェアに依存したところもあると思いますので、実機でのテスト/評価が必須になると思われます。弊社のこれからのコントロールも、ビジュアルサイズと目標サイズの違いがあることなどを意識する必要がありそうです。このようなサイズの調整についてはXAMLでのカスタマイズであれば非常に都合がよく、HTMLベースのものだとかなり頑張らないといけないと思われます。いずれにしても弊社としては、XAMLベースプラットフォームも、HTMLベースのWebスタンダードも両方サポートしていきますので、今後もこれらのガイドラインと絡めて情報を提供してまいります。

次回は、国際化について書いていきます。重そうなテーマですが、現在 Windows Phone に取り組む上でとても重要なパートになりますので私も気合を入れて書きたいと思います。お楽しみに!