タブを以下の図に示します。ビューへの追加たとえば、自分がソリューション開発者であると仮定します。各ユーザーは、複数のドキュメントで同時に集中的なデータ編集を頻繁に行っています。ドキュメントを頻繁に開いたり閉じたりするため、ドキュメントを閉じるたびに保存を求めるメッセージが表示されない方がいいというのがユーザーの要望です。置き換えることができます。ファイルと同じファイルに定義されます。つのノードにすぎません。内部階層は、リボンの内部階層とほとんど同じです。ブロックにもタブが採用されています。含めることができます。レベルのボタンもホストします。コマンドとして表示されます。グループとではコンテンツの空間的構成が異なりますが、どちらも数多くの同じ種類のコントロールをホストします。働きは、どちらのグループとも同じです。機能拡張の構造および機能の詳細については、今後のベータ版ドキュメントで公開される予定です。センターに公開される予定です。サンプルが含まれます。引き続きそのメニューは使用できます。ソリューションの開発者から要望の多かった機能です。(選択されている場合)。グループのレイアウトが変更されます。これらのすべての要望に対応しました。ソリューションの開発シナリオを考えてみましょう。タブに特定のデータ型が含まれている場合、ユーザーがあるデータ型を操作したときに、適切なタブが前面に表示されるようにしたいとします。ことでこの機能を実現できます。該当するアドインの名前空間を指定した文字列型パラメーターの追加が必要です)。グループのレイアウトが変化することにおそらく気がつくことでしょう。ウィンドウを拡大すると、リボンの各グループのスペースが広がりラベルが表示されるか、一部のコマンドのサイズが大きくなります。ウィンドウを縮小すると、各グループも小さくなり、狭い領域に多くの機能が詰め込まれます。ソリューションのユーザーが、複数のアプリケーションを同時に表示できるよう、ウィンドウを最大化したくないと思っているとします。つにリサイズされ、余分なクリック操作が必要になったりするのは望ましくないとも思っています。グループのサイズが適切に変更されます。グループのサイズ変更の例を以下の図に示します。つのボタンで表示されるときに使用されるアイコンとして、グループにそのアイコンを割り当てておく必要があります。メニューのカスタマイズを検討されたことでしょう。モデルで拡張可能になっています。モデルでアクセスできないものがあります。メニューに追加できません。モデルを使用できます。メニューに追加できるようになりました。新しいトップレベルのノードとしてアクセスできます。ソリューションを作成できます。プレビュー版でもう既にこれらの機能を使い始められていることと思います。引き続きご意見をお寄せいただければ幸いです。投稿の最後の「参考サイト」のセクションに、参照サイトのリンクを追加。公開ベータ版のリリースとともに提供された技術情報の追加。Backstage、機能拡張、リボンこれはローカライズされたブログ投稿です。FeedbackTrademarks。