XAML Ribbon

[adambarlow]

Proposal: XAML Ribbon

Summary

tl:dr; Provide a Ribbon control for XAML apps which utilizes recent advancements in XAML commanding infrastructure, which is simple to implement and simple to interact with.

Since the release of the ribbon in Microsoft Office products in 2007 it has been a successful and frequently imitated commanding paradigm. It's success is demonstrated in the many implementations in frameworks on various platforms, as well as the ongoing requests for it's inclusion in WinUI.

This proposal details the creation of a simplified single-row Ribbon control, which can natively host XAML controls with great styling out of the box. This ribbon control will be familiar to those who have worked with the commandbar control and will allow for apps with more advanced commanding capabilities than are currently possible with XAML.

Rationale

Implementing a XAML Ribbon will provide the following for the community:

1. Allow for the creation of apps that scale to have offer many commands to users (e.g sophisticated apps with more commands than comfortably fit in, say, a current XAML commandbar)
2. Provide users with commanding UX which is familiar, usable, and coherent with what they see across other apps on Windows (e.g. Microsoft Office)
3. Provide a commanding surface that complements our existing suite of XAML commanding assets (e.g. button, ToggleButton, SplitButton, XamlUICommand, StandardUICommand, CommandBarFlyout, CommandBar, Menubar, etc.)

Terminology

• Ribbon A set of toolbars that are grouped by tabs
• QAT "Quick Access Toolbar" a small group of commands in the Ribbon which always stays around no matter which tab currently has focus
• Contextual Tab A tab of commands representing actions that are available only because of the current app context
• File Menu A section of the Ribbon which contains commonly used commands that refer to the document in general or the app in general. Commonly used for, "open, save, close, etc."
• Chunk A sub-section of a given tab. These can be named and are separated by vertical separators
• Overflow An area which contains commands that do not fit in the currently visible ribbon tab

Functional Requirements

#	Feature	Priority	Wave
1	Basic Ribbon tabbing experience (e.g. a tabbed set of command bars)	Must	0
2	Animation when switching tabs	Should	1
3	Contextual tabbing support	Should	1
4	Support for overflow of items (one per tab)	Must	1
4.1	Ability for the end-user to add and remove items from the overflow	Could	2
4.2	Split or dropdown buttons in the overflow have cascading menus	Should	1
4.3	Overflow area organized by the ‘chunk’ commands came from	Could	2
5	Supports resize behavior (e.g. losing labels, dropping commands into the overflow for each tab on window resize	Should	1
5.1	Support for mandatory text labels	Should	1
6	Optional built-in menu for ‘File Menu' (a contextflyout hosted in the ribbon for commands like Save and Open)	Should	1
7	Support for a QAT menu for frequently used commands	Should	1
7.1	Ability for end-users to add / remove items from the QAT	Could	2
8	Able to host a set of commonly used controls in the control without the need to style them (drop in support) List: - Button - Split Button - DropDown Button - Combo-box - Toggle Button	Should	1
9	Ability to host arbitrary XAML (developer would not get styling for free)	Should	1
10	Supports icon only commands	Should	1
11	Integrates with XamlUICommand registry (when developed)	Could	1
12	Built-in search bar across XamlUICommand registry	Could	2

Open Questions

• What is the object model for Ribbon (is it multiple command bars in a tabbing control? QAT as a separate commandbar, file menu as a MenuFlyout?)
• How do we achieve the drop in styling? (is it an interface, like IRibbonStylable that Button, DropDownButton, etc. implement?)

[mdtauk]

The Ribbon control was mentioned at Build, as something coming to XAML in 2019. Of course the data validation for text fields was delayed, so who knows if any work has begun on it.

Office UWP apps would be a good guide to implementing it - in fact if the Office UWP team were to commit their work, it would be something to build off.

However the Ribbon shows up in UWP, it needs to be consistent from app to app. Implement UICommands as with CommandBarFlyouts and ApplicationBars. Be responsive for device type, and window size. And perhaps some thought about how to integrate visually with an extended Title Bar and the Sets Tab.

[adambarlow]

@mdtauk Yes, we mentioned it at Build and continue to move the conversation forward, which includes this feature proposal.

I agree that we will want to ensure it's consistent app to app and that it is responsive to screen size and all input modalities. I am working closely with Office and intend for the designs to align as much as possible.

So i am sure, what are you referring to specifically when you say extended Title Bar and the Sets tab?

[mdtauk]

@mdtauk Yes, we mentioned it at Build and continue to move the conversation forward, which includes this feature proposal...

...So i am sure, what are you referring to specifically when you say extended Title Bar and the Sets tab?

I hadn't realised this was an official proposal, as in you are someone at Microsoft beginning the process, and just wanted to ensure there was not cross purposes, like a third party proposing a Ribbon, whilst an official one was being made. No offence intended. :)

The Ribbon usually is set to the top of the window in which it is placed. Many apps extend their app into the TitleBar area to give a cleaner UI and use Acrylic. And then there is Sets which will someday replace the default TitleBar experience in UWP apps.

The Windows 7 and right back to the original implementation of the Ribbon UI, custom drew the Titlebar for the window they were in, but those Windows Vista/7 Ribbons need not dictate the new implementation of it - and UWP apps have different ways of handling the window chrome.

When developing a design for the UWP Ribbon, and devising how it is recommended for use in an App's UI - the fluent team should consider how it will look and work in both of those scenarios (extended title bar and within the tab used by Sets), as well as while using the current default TitleBar, and a coloured TitleBar.

Rather than just designing the control in isolation, from how it fits in with the rest of the App UI, Window Chrome, and the OS Shells.

[adambarlow]

@mdtauk, don't worry, absolutely no offense taken. Thanks for the clarifications and the explanation. I agree completely and I'll work on a way to ensure this goal is included in the proposal as we continue to flesh it out in more detail.

[mdtauk]

For what it is worth, here are my initial thoughts on how you would integrate the Ribbon with the various combinations of TitleBars you would get.

If these were to be considered, the Tab Bar, and the Tool Bar would each need their own Background Brush property, which would allow both to use the same colour/acrylic - or different ones.

And for comparison, here are other design patterns in Sets and Extended Titlebars.

[contextfree]

Win32 Office ribbon (including the single-line version in Outlook) also supports browsing through tabs using the mouse scroll wheel. This is something I miss in the OneNote UWP ribbon, which doesn't support it; it somewhat replicates the browsability of traditional menu bars, where you can hold the mouse conveniently "scrub" through the menus to see all the commands available. If it were expanded to also support horizontal scrolling with two-finger touchpad or swiping with touch, it would also be more consistent with the Pivot model, which the ribbon now resembles visually with its current design.

[contextfree]

Collapsed-mode ribbon (where the tab contents are hidden by default and appear transiently on demand on click) is another aspect of most of the various existing ribbon implementations not explicitly called out in the requirements. UWP OneNote, Win32 Office (including Outlook's one-line version), Windows ribbon all support some form of this (with various ways of toggling it - double-click on a tab, expand/collapse button, dropdown menu in the title bar).

It does work differently in UWP OneNote than in the Win32 implementations though - instead of a persistent mode, it's just a way to temporarily collapse an existing tab by tapping/clicking on it again. While this isn't as important with the single-line ribbon as it was with the full-height version, I still have found it handy to collapse sometimes while using OneNote on smaller screen sizes. Is it a decision to not include this or just not gotten to it yet?

[mdtauk]

Collapsed mode would make a lot of sense, and the NavigationView / SplitView control does this already for the sidebar when in collapsed and overlay modes.

There could be a property like DisplayMode for the Ribbon. With options like Expanded, Minimal, Collapsed and when it is set to collapsed, only the tabs are displayed permanently, and the toolbar appears when an item is pressed, with a light dismiss interaction.

I would like to suggest that if it is set to collapsed or minimal - that a chevron be added to the right of the tabs, to toggle it into view.

[TiredTrident]

@adambarlow How easy will it be to try to invoke the ribbon animation/content changes, when the app context changes, rather than the tab? For example, what has been seen in Outlook with the Email/Meetings/Contacts button that changes the ribbon contents but not the tab.

[adambarlow]

When you say it changes the Ribbon contents, you mean the contents of the tabs themselves? I don't quite understand the scenario you are describing. What's an example of the context switch you are describing?

[TiredTrident]

Sorry for the confusion @adambarlow . If I was looking to develop an application where the context referenced in the main window could change, would it possible to push an event to swap the contents of the Ribbon to match the new contents?

For example, when using Outlook and I switch from the email page to my calendar, the contents of the Home tab on Ribbon change swap with an animation.

[adambarlow]

Yes, good point. This certainly should be possible. I'll include this in the requirements section.

[mdtauk]

When I mentioned contextual tabs, I am referring to these...

@TiredTrident What it sounds like is the ribbon being swapped with a different one depending on the workflow. Is this a feature of the ribbon, or just replacing one ribbon with another?

[mdtauk]

Good luck @adambarlow with making this control a reality. Hopefully the Office team will be able to help, as well as getting the Windows teams on board, for that one day in the future re-write of File Explorer which may have need for it. 😆

[lukeblevins]

I'm no XAML expert, but we could base the Ribbon control off a custom TabView that contains a CommandBar as TabContent. Further, the selection indicator should have CornerRadius. I managed to recreate this control in my own app if anyone is interested.

[lukeblevins]

Another "nice-to-have" is the ability to collapse the ribbon.

[lukeblevins]

@adambarlow Developers should also have access to guidelines regarding how to differentiate the Ribbon from the rest of the UI. For instance Z-depth, background colors, acrylic?

[YuliKl]

@adambarlow Developers should also have access to guidelines regarding how to differentiate the Ribbon from the rest of the UI. For instance Z-depth, background colors, acrylic?

@duke7553, you're absolutely right. When this control is implemented (we're a little busy working on WinUI 3.0 at the moment), it will incorporate the styles into its default template. Are you noting this need because you want to incorporate into your custom control?

[lukeblevins]

@YuliKl I was just trying to ensure the makeshift XAML ribbon I created was in-line with Fluent Design guidelines, so I'll be anxiously awaiting the official WinUI ribbon control.

[YuliKl]

@duke7553, while I don't yet know what colors the ribbon control will use, I'm fairly confident in saying that it won't use acrylic or shadow, at least not in its non-transient pinned state. Shadow is designed to show elevation (which the ribbon doesn't have relative to the rest of its parent page), and acrylic is for temporary UI surfaces.

[mdtauk]

The OneNote UWP app's Ribbon has a shadow and has an implied elevation.

By default it may not have an Acrylic brush as its background colour, but that would be possible by changing the brush to an Acrylic one.

Settings also uses Acrylic for it's sidebar, which aesthetically (along with extending into the Titlebar area) is quintessentially the Fluent design style which distinguishes Windows modern design.

Alarms & Clock uses Acrylic for its Top orientated NavigationView which extends into the Titlebar area.

The Microsoft Store uses in-app Acrylic as you scroll down a page, so the contents can be seen through, which would equate with a collapsible Ribbon which you pull down on top of the view, rather than the static/pinned one which pushes the content down.

---

By default I expect the control will not have Acrylic, but I think these combinations should be possible with the control.

[lukeblevins]

@mdtauk While the acrylic material looks really nice, it and other Fluent effects should really be used sparingly. Otherwise, it rapidly becomes either distracting or loses its “Wow” effect. While transient UI deserves acrylic, and context flyouts deserve Z-depth, pretty much everything else needs to be approached from a utilitarian point of view. I, for one, appreciate the revisions that have been made to the design system to reflect this understanding.

However, it definitely should (and likely will) be possible to theme these XAML controls with acrylic.

In my application, I found it to be less distracting by removing the acrylic from the areas that are adjacent to content.

Regarding the Ribbon, I think a better solution for developers to provide users with a sense of “context” would be to theme something like the title bar, when appropriate, as one would do for horizontal navigation.

[shaheedmalik]

I'd like to see it tie in more with the other UWP designed apps with the back buttton, share button, profile, search, etc. Here's an example of those tied in.

[mdtauk]

I'd like to see it tie in more with the other UWP designed apps with the back buttton, share button, profile, search, etc. Here's an example of those tied in.

There could be a BeforeRibbonTabs area where a back button could be placed if needed. And an AfterRibbonTabs area which is to the right hand side. This area could have a chevron button to collapse the Ribbon?

[YuliKl]

There could be a BeforeRibbonTabs area where a back button could be placed if needed. And an AfterRibbonTabs area which is to the right hand side. This area could have a chevron button to collapse the Ribbon?

When we get around to putting more thought into the Ribbon control, we will undoubtedly borrow concepts and APIs from the new Tabs control, #304.

[Poopooracoocoo]

I hope we also get a full ribbon. I hope we get some WinUI on Office and still keep the amazing customisability and functionality.

Honestly, OneNote's new-ish undo and redo placement bugs me. It would be nice in the titlebar like other Office apps but that's a little off topic.

[shaheedmalik]

I hope we also get a full ribbon. I hope we get some WinUI on Office and still keep the amazing customisability and functionality. Honestly, OneNote's new-ish undo and redo placement bugs me. It would be nice in the titlebar like other Office apps but that's a little off topic.

If anything, they need to move away from putting stuff in the title bar. Those title bar buttons were a mess for implementing into sets.

[mdtauk]

Sets is dead btw

[Poopooracoocoo]

reply to @shaheedmalik

in addition to what @mdtauk said, OneNote already has things in the titlebar (name and navigation arrows)

[shaheedmalik]

OneNote's placement isn't consistent with the rest the apps.

[lukeblevins]

How about having a collapsed state for some ribbon items when the window is resized small enough before the overflow has to kick in? This can look something like this: Full Size:

[sharpninja]

I think it's important to allow icons and buttons of differing sizes as it helps the user identify common and not-common functions in the same group.

[yoshiask]

I started creating a Ribbon control with the intent of it being added to the Windows Community Toolkit at yoshiask/UWPRibbon. It's far from complete, and I could use a little help with it. It's written using C# and templated controls, so I don't know how easy or difficult it would be to add to WinUI.

[yoshiask]

Regarding current implementations of ribbons in UWP, I'd argue that they're not ribbons. They look, act, and feel just like a left-aligned CommandBar. Look at the ribbon in PowerPoint:

• It has the Quick Access Toolbar, which can be implemented as it's own control and optionally placed in the TopHeader of a RibbonControl.
• Office's ribbons have "Gallery" controls, which allow users to select options from a grid of thumbnails/icons. Some examples include the shape picker in the "Drawing" group, the "New Slide" dropdown, and the theme picker in the "Design" tab.
• Unlike most UWP ribbons, Office ribbons use Split and DropDownButtons a lot.
• Buttons in a ribbon can be a lot of different sizes, depending on the context. For example, the "Clipboard" group has one large primary button, and to the right of it are three smaller secondary buttons, stacked on top of each other. These buttons can have labels, like they do in the "Slides" group, but it's not required.
• Groups group together related controls. A RibbonControl should probably only accept RibbonGroups as content, rather than allowing RibbonButtons and such directly. Groups can be divided into columns (the "Slides" group has two, the "Font" group has one, and the "Drawing" group has four). These columns can be divided into one big row for a full-size ribbon button (like the Paste button), two 1/3rd-height rows centered vertically (like the "Font" group), or three 1/3rd-height rows (like the "Editing" group).
• Office also has what I think is called "backstage". It's what shows up when you click on the "File" tab: While it would be cool for this to be a control on its own, it might be difficult to implement, since it covers all of the window's content. This should probably be left to developer to implement for their own app(s).

I tried to make this as comprehensive as possible, hopefully this serves as a guide to what features and paradigms user's are familiar with from the Office suite.

[yoshiask]

Might also be worth checking out the VSTO docs for the object model: https://docs.microsoft.com/en-us/visualstudio/vsto/ribbon-object-model-overview

[mdtauk]

Regarding current implementations of ribbons in UWP, I'd argue that they're not ribbons. They look, act, and feel just like a left-aligned CommandBar. Look at the ribbon in PowerPoint:

I think Office is considering it's ribbon design, as there is the full Win32 apps with its Ribbon, and the newer Simplified Ribbon.

Does a new Xaml Ribbon go for simple or dense - or does it do both, and it becomes a RibbonType property the developer chooses?

[yoshiask]

I think it should have both. If it's an option in Office, it should be available in the UWP version too. Same goes for the touch option.

[michael-hawker]

Hey All, I synced up with @yoshiask and the WinUI folks. @yoshiask's going to put together an initial version of this control for the Windows Community Toolkit.

Feel free to join the process and discussion over on our repo in this issue.

Thanks! 🦙❤

FYI @adambarlow @ryandemopoulos

[yoshiask]

@adambarlow In your proposal, you mention the "XamlUICommand registry". What is this? Is there any documentation of it (or what it's supposed to be)?

[adambarlow]

@yoshiask , the command registry was an idea that I had been exploring of having a component which would track the commands for the application. You would create an entry in the registry and then you could refer to the commands in the registry in other components like the ribbon or a menubar, etc. Essentially a way to have an app wide registry of UICommands which could be then bound to actions and exposed in various UI controls. It was never spec'd or built, IIRC.

[yoshiask]

Ah, okay. So is that something you'd still want in the initial version of the control, or can it wait at least until a full spec is written out?

[adambarlow]

There is not currently a plan or spec in place for the command registryl, so I don't think it should be a consideration for a V1 of a ribbon control.

[sharpninja]

@yoshiask , the command registry was an idea that I had been exploring of having a component which would track the commands for the application. You would create an entry in the registry and then you could refer to the commands in the registry in other components like the ribbon or a menubar, etc. Essentially a way to have an app wide registry of UICommands which could be then bound to actions and exposed in various UI controls. It was never spec'd or built, IIRC.

I have written this multiple times in multiple ways in both WPF and UWP. What I have found is that it requires dispatcher tracking to ensure that events are raised on the correct thread as the commands may be instantiated in different places. Or, you could have a CommandFactory that creates all commands from a single thread, but also tracks the thread that requested the command so that the command's updated event is dispatched correctly. Microsoft.Extensions.DependencyInjection would be perfect as the call to ServiceManager can be done from the GUI thread and thus the anonymous factory method just captures the Dispatcher and feeds it to the newly created command. I actually have a request with WinUI to allow specifying a DI provider for instantiating objects declared in Xaml that would go right with this.

[shaheedmalik]

There is not currently a plan to develop this control, so I don't think it should be a consideration for a V1 of a ribbon control.

If there is no plan to develop the control, what are all of the apps that use it are going to do?

[adambarlow]

@shaheedmalik , when you say use it, what are you referring to? I have edited my comment above, there is no current spec or plan for the command registry that we were discussing.

[yoshiask]

If there is no plan to develop the control, what are all of the apps that use it are going to do?

To be clear, we're referring to the command registry, not the ribbon control

[ad1Dima]

Just noticed that WPF Ribbon was opensourced https://github.com/dotnet/wpf/tree/master/src/Microsoft.DotNet.Wpf/src/System.Windows.Controls.Ribbon/Microsoft/Windows/Controls/Ribbon

[michael-hawker]

Thanks @ad1Dima, we've been aware. 🙂 I believe @yoshiask is looking at that occasionally as a reference, but WPF and UWP are pretty different and the UX designs for this pattern have changed recently, so we're not trying to port it directly in the work we're trying to do in the Windows Community Toolkit.

[yoshiask]

@adambarlow Can you elaborate on what you meant by "Support for mandatory text labels" in the original proposal?

[0x5bfa]

Hello,

How can I design it to look like this image? I'm new to XAML / C # (WinUI ??). I would like to know if possible. I also want you to upload that code as OSS to your GitHub.

Thanks.