.NET Framework 3.0 のユーザーインターフェース

.NET Framework 3.0においてユーザーインターフェースを担うWinodws Presentation Foundation (WPF) が.NET Framework 3.0 の一部として昨年11月に正式にリリースされてから3ヶ月が経ちますが、現状では開発ツールがないということもあり、本格的な開発はまだこれからという方が多いかもしれません。   開発ツールとしては、現在ベータが提供されている Expression Blend などが近々リリースされるのを筆頭に、現在CTPが提供されているVisual Studio の将来バージョンにもWPFアプリケーションの開発機能が盛り込まれ、徐々に環境が整備されてくることになります。   カンファレンスなどで、短いデモに多くの機能を盛り込み、かつインパクトのあるものを作成しようとすると、ついつい派手なグラフィックスになってしまうせいでしょうか、WPFというと派手なグラフィックスに目が行きがちなようです。   もちろん、DirectXの機能を簡単に使えるという点も含めて、高いグラフィックスの表現能力はWPFの最大の売りの一つではありますが、それだけではありません。むしろ、これらのグラフィックス機能は、どんな要求にも答えることができるための潜在能力としてとらえた方が良いのかもしれません。機能が豊富なことに越したことはありませんが、何を使うかは開発者次第ですし、作るものによっても多く左右されると思います。   派手なグラフィックスに押されて、いまひとつ注目度が高くない部分に目を向けると、大きな利点としてXMLであるExtensible Application Markup Language (XAML)による記述があります。   XAML にはUIの静的な設計だけでなく、ロジックを含めることもできますので、UIの動的な情報も含めて、XAMLに含めることができますし、つまり、動的な情報も含めてUIの一部としてまとめることができ、業務ロジックとは明確に分離して開発することができるようになります。   また、XAMLではWebページのようにページからページへとナビゲートすることができ、画面遷移を中心としたUI設計が可能になります。一方でWebのようにまったく関連無く作成されたページ間がリンクされるモデルの場合には利点となるステートレスなモデルも、WPFアプリケーションでは、ステートの管理が煩雑になるなど必ずしも適しているわけではありません。そこで、WPFでは、新しいイベントモデルを導入し、Webのようにページ間を移動できるようにしつつも、イベントは一括して処理できるようになり、またコードやステートを共有することが可能なモデルになっています。   最後に、配布形態の面でも自由度が非常に高められています。ブラウザアプリケーションとして、Webブラウザ内で動作するアプリケーション作成することもできますし、従来のクライアントアプリケーション同様、Windowsから直接起動するアプリケーションを作成することもできます。また、クリックワンスもXAMLの使用により起動時間を短縮することが可能になりました。他にも、ここに挙げきれないほどWPFには革新的な機能が盛り込まれています。   日本語の取り扱いに関しても、Text Services FrameworkもSystem.Windows.Inputとして標準で組み込まれていますので、IMEをコントロールする場合にもPlatform Invokeは必要なくなるのが大きな利点でしょう。   開発ツールに加えて、(決して派手という意味でなく)WPFの表現能力やその他のメリットを活用したコントロール群などがリリースされていくにしたがって、本格的なWPF時代が到来するのも、そう遠い将来の話ではないという気がします。


ユーザー インターフェイスを考える

2007年も始まってひと月がまもなくすぎようとしています。私もベータの頃からWindows Vista、Office 2007など試用し、正式リリース後からは製品版を使っていますが、まだ十分に操作に慣れていないせいか、「これを使うにはどうしたら・・・」といった感じです。そんな中で、お客さまのお問い合わせを検証するために、過去のOSや製品を使ったりすると、やはり隔世の感があります。 Vistaなどは、最初は、角がさらに少なくなったことや3Dの透明感の表現などビジュアルな側面に気が付かれることが多いと思いますが、操作をしていると、ふと不思議に思える点や、そこに目に見えない共通のルールやテーマのようなものが見え隠れします。コンピュータ科学やリサーチの世界だとHuman Computer Interaction (HCI) といった分野で、人間とコンピュータの対話の観点から様々な研究が行なわれていますが、弊社などは世界中のお客さまからのフィードバックなどにより、実製品として多くの方々に使われるところへ応用されていきます。使っていると「以前と違うので違和感が・・・」と最初は思うのですが、「これは何をしたいのだろう」、「これは誰に使ってもらうためのものだろう」といったことをやはり調査していくと、それなりに資料が見つかります。 2001年の秋ですのでXPの時代のものですが、Win32やCOMのユーザー インターフェイスの技術文書として “Inductive User Interface Guidelines (英語)” (日本語にすれば「誘導的ユーザー インターフェイスのガイドライン」といったところでしょうか)が出されています。技術文書といってもリサーチ向けの文書ではなく、開発者のみなさんにお読みいただくために文書として書かれているようで、その分野の用語はそれほどありません。Inductive UI (IUI) と呼ばれるこのUIとは対極に近いものが、Deductive UI(日本語にすれば「推定的 UI」といった感じでしょうか)として紹介されていますが、これは今日使われている、ダイアログ上にコントロールを貼ったものです。こちらの文書では前者のIUIは、「ソフトウェアは使いづらい」という問題を解決し、後者のDUIは、「これを提示されてもユーザーは何をして良いのかよく分からないだろう」といった論調で書かれています。    リンク先の文書は英語ですが、図も何点かあるので見ると、「ウィザードで作ること」に結論付けられる方も多いのではと思われます。しかし、最初のステップに書かれているようにユーザーの作業(task)に着目することから解析を行なう必要性があり、ウィザードのようなものは表現の手段にすぎないようです。ちょうどこの時期の前後にWebのユーザビリティでも、ある方が「ユーザー中心の考え方ではなく、ユーザーの行動に着目すべき」といったことを書かれていたと思いますが、これはそれなりに話題になっていたことを覚えています。この文書でも「WebのUIはこちらに近い」といったことが最後に書かれているので、着目する点に相似するものがあるのでしょう。 2003年の秋ですが、弊社のUser Experience GroupがAeroのガイドラインのなかで “Picking the Right Degree of Control for User Interfaces (英語)” として「日常の作業の度合い」と「ソフトウェアとユーザーのどちらが主導的に操作すべきか」を比較し、IUIとDUIの双方を肯定しています。IUIが非Web系の今日のクライアントのUIだとすると、これは辻褄が合います。よくWebの開発に携わっていらっしゃるお客さまが、「いままでWindows クライアント向けで作ったものをWebに書き換えて欲しい」という依頼で、お困りであるという話を聞きます。これは、このUIや通信が含まれる操作の特性をご理解いただけないまま、同じものをWebで再現するような要求が発生してしまったためではないかと察します。 2004年の初夏 には、”IUIs and Web-Style Navigation in Windows Forms (英語)” としてWindows フォームでIUIをどのように実現するかという内容が2つに分けられて投稿されています。これらはUIへの投資回収といった観点から始まり、実際に弊社のサンプルでおなじみのNorthwindのデータベースを実装していますが、現行のWindows フォームでの実際の動作を見るには良いでしょう。 ここから先の資料があまりないので、これ以上ご紹介することができないのですが、最近のWPFのショーケースやガイドラインなどを見ていると、IUI、DUI双方の要素を取り入れつつ、表現力豊かで創造性の高いアプリケーションが、これまでソフトウェア開発に関わっていらっしゃらなかったような方々も含めて開発なされていて、ますます楽しみです。さて、私たちも今年はWPFや ASP.NET AJAXといったユーザー インターフェイスを改良する技術や、それを開発するツールなどをみなさまのお手元にお届けさせていただく作業に携わることになります。これまでも、ソフトウェア開発にデザインという要素はございましたが、今後、ますます多様なお客さまからのご意見を取り入れて、さらにより良いものを作っていかなくてはいけないと思います。日本ではこういった機能が必要だ、こういったところに手が届くようになってくれないと、といったご意見やご要望をぜひ今年もお聞かせ下さい。


MSDN Library Onlineのコミュニティ コンテント

遅まきながら本年最初の書き込みになります。皆様、今年もディベロッパー製品開発統括部ブログをよろしくお願いいたします。 さて今日は、Web で提供している製品ドキュメント (MSDN Library Online) に、最近追加された新機能のお話をさせていただきたいと思います。 英語版のMSDN Library Online をよくお使いの方はすでに気がつかれているかもしれません。 例えば http://msdn2.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx を見ていただきたいと思います。ページ右側に表示されたドキュメント本文を下までめくってみてください。間もなく “Community Content” という緑色のタグが見えてくると思います。 ここから下はドキュメント利用者によるコメントで、製品のドキュメントではありません。言い換えると、利用者側で各ドキュメント本文に「関連する情報」を自由に追加できるようになっています。 単純な言い方をすると、皆さんが手許にお持ちの貴重な技術情報を、製品ドキュメントをベースにして公開し、共有しようという試みです。 皆さんは今までに、紙マニュアルや技術書のページの片隅にメモ書きをしたり、その情報があとですごく有効だったりした経験はありませんか? “Community Content” は、それをオンラインで実現する機能です。 現在は英語版で試験運用中ですが、日本語版についても現在導入を検討中です。決まりましたら、できるだけ早く提供できるようにしたいと思っています。 とはいえ、この説明だけではピンとこない方も多いかもしれません。 確かにその目的を正確に理解するには、FAQ や「運用規範」である “Code of Conduct” などの、提供されるドキュメントの内容を事前にしっかり読まなければいけないようです (それらの英語ドキュメントは、各ページ最下部のリンクから入手できます)。 それらを読めば、今後この新機能をどのように利用すれば有効なのか、十分理解していただけると思います。 日本語版 “Community Content” を提供することが決まれば、FAQ 等のドキュメントもすべて日本語化の予定です。準備が整いましたら、またこの場でお知らせしたいと思います。


Windows PowerShellの紹介

  Windows PowerShellは、主にシステム管理者を対象に設計されたWindows の新しいコマンドライン シェルです。PowerShell には対話型のプロンプトとスクリプト環境が備えられており、これらは別々に使用することも、組み合わせて使用することもできます。   ほとんどのシェルではテキストを受け取って返しますが、Windows PowerShell は .NET 共通言語ランタイム (CLR) および .NET Framework 上に構築されているため、.NET オブジェクトを受け取って返すことができます。   Windows PowerShell では、シェルに組み込まれているシンプルな単一機能のコマンドライン ツールであるコマンドレットの概念が導入されています。それぞれのコマンドレットは個別に使用できますが、このシンプルなツールを組み合わせて複雑なタスクを実行することでコマンドレットの威力を発揮できます。Windows PowerShell には、100 を超える数の基本的なコア コマンドレットが付属しています。これに加えて、自分でコマンドレットを作成して他のユーザーと共有することもできます。   多くのシェルと同様、Windows PowerShell でも、コンピュータ上のファイル システムへのアクセスが提供されます。加えて、Windows PowerShell プロバイダにより、ファイル システムにアクセスするのと同じくらい簡単にレジストリやデジタル署名証明書ストアなどの他のデータ ストアにアクセスできます。   Windows PowerShell では、Windows コマンドライン プログラムを実行できます。メモ帳や電卓などの、グラフィック ユーザー インターフェイスを持つ Windows プログラムは、シェル内で起動できます。さらに、Cmd.exe を使用した場合と同じように、プログラムによって生成されるテキストをキャプチャしてそのテキストをシェルで使用することもできます。     Usage for Windows PowerShell   さて、とりあえず使ってみましょう。…