マイクロソフトが現在のUIのようなUIを構築するためにUXフレームワークをリリースしないのはなぜですか？
.NETフレームワークでプログラミングを学び始めたとき、UIテクノロジとしてWinFormsを使用することから始めました。このオフィス2000と同様に、「クラシック」メニューを使用します。 
数年後にOffice 2007がリリースされ、リボンが誕生しました。 
そして数年後の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はサポートされていません。
歴史的に、マイクロソフトは常に標準のWindowsアプリケーション（MFC、WinForms、WPF）を作成するためのツールを開発者に提供してきました。
ここでの問題は、Officeが開発者ツールとフレームワークを提供するグループとは異なるグループによって開発されていることです。これは、OfficeグループがリボンやBackstageのようなものを作成する場合、機能を提供する再利用可能なコントロールを作成するために、開発者ツールグループが追いつく必要があることを意味します。
また、2つのグループ間で競合が発生し、リボンの利用が大幅に遅れたと考えています。私の推測では、OfficeグループはリボンをOfficeアプリケーションに固有のものにしたいと考えており、開発者ツールグループはそれを誰もが使用できるようにしたいと考えていました。