マイクロソフトが現在のUIのようなUIを構築するためにUXフレームワークをリリースしないのはなぜですか？

.NETフレームワークでプログラミングの学習を始めたとき、UIテクノロジとしてWinFormsを使用することから始めました。このオフィス2000と同じように「クラシック」メニューを使用しています。Office2007 がリリースされて数年後、リボンが誕生しました。 さらに数年後、Office 2010がリリースされ、ステージなどの新機能も追加されまし た。数日前Office 15のプレビュー版がリリースされ、より豪華な新機能が追加されました： これは大きな進歩であるIMOですが、開発者がそのようなUIを構築できるようにしないのはなぜですか？.NETを見ると、まだリボンを作成する方法がありません。拡張性の高いWPFを使用しても、事前に作成されたコントロールはありません。したがって、コミュニティはこれらすべての「機能」を作成するためにいくつかのプロジェクトを開始しました。今日、マイクロソフトはWinFormsとWPFのリボンをリリースしましたが、それはまだコアフレームワークの一部ではありません（4.5のものでもありません）。しかし、私が知る限り、これは.NETに限定されていませんか？今日、アンマネージアプリケーションがこれらのリボンUIを作成するためのAPIはまだありません。

ドイツでは、すべてが自分のスタイルに合うように、無料のUXトレーニングを提供しています。http://j.mp/NZGgH9

マイクロソフトが開発者にクールなものを提供しないのはなぜですか？彼らは彼らのアプリケーションがユニークであることを望みますか？

彼らはリボンをサポートするUIフレームワークをリリースしました-.NETの代わりにMFCでのみサポートされています。

彼らがなぜそのように物事を行ったのかについては、かなりの議論の余地があると思われますが、とにかく彼らはそうしたのです。

Metroスタイルのアプリははるかに広くサポートされているようです。C++だけでなく、C＃、VB、JavaScriptもサポートされています。

彼らはこれらのもののいくつかを解放します。

これが .NETアプリケーションで使用できるリボンです。

そして、これがMetroです。これは、WPF / XAMLまたはHTML / JavaScriptを使用してプログラミングできます。

残念ながら、

Visual StudioでのMetroスタイルアプリの開発は、Windows 8 Release Previewでのみサポートされています。Windows 7はサポートされていません。

歴史的に、Microsoftは常に標準のWindowsアプリケーション（MFC、WinForms、WPF）を作成するためのツールを開発者に提供してきました。

ここでの問題は、Officeが開発者ツールとフレームワークを提供するグループとは異なるグループによって開発されていることです。つまり、OfficeグループがリボンやBackstageのようなものを作成する場合、機能を提供する再利用可能なコントロールを作成するために、開発者ツールグループはキャッチアップを再生する必要があります。

また、2つのグループ間で競合が発生し、リボンの利用が大幅に遅れたと考えています。私の推測では、OfficeグループはリボンをOfficeアプリケーションに固有のものにしたいと考えており、開発者ツールグループはすべてのユーザーがリボンを使用できるようにしたいと考えていました。