Microsoft Aims to Modernize Windows 11 Right-Click Menus with SplitMenuFlyoutItem

Microsoft appears to have acknowledged one of Windows 11’s longest‑running UX complaints — the increasingly cluttered and slow right‑click context menu — and is rolling out a developer‑facing fix that could shrink, reorganize, and modernize how apps surface commands in File Explorer and other WinUI apps.

Background​

Windows’ context menu is the product of two decades of incremental extension: shell extensions, legacy COM verbs, installer‑added items, and newer app registrations all append entries with little enforced structure. The result is a long, sometimes redundant, and often confusing list of actions when a user right‑clicks a file or folder. Microsoft’s earlier Windows 11 redesign attempted to improve this by folding common commands into a compact top row and pushing legacy items into an overflow, but that approach only reduced the symptom — it did not stop the menu from growing again as more functionality (including AI/Copilot items) was added.
Over the past weeks, screenshots and a demonstration from a WinUI Community Call have shown a new pattern that aims to address the root cause by providing a modern API and control for split menu items — a single row that presents a primary action and a tightly related secondary flyout. The preview material and early documentation point to a WinUI control currently referred to as SplitMenuFlyoutItem, distributed via the Windows App SDK preview channel.

---

What Microsoft showed (overview)​

During the WinUI Community Call, Microsoft’s WinUI team demonstrated examples of a split context menu in action: a single menu entry like “Open with Photos” that behaves as a hybrid control — clicking the left side executes the default action, while a small chevron on the right opens a compact side flyout with related actions (such as “Open with Paint,” “Edit,” or other apps). The control is being shown as part of the WinUI/Windows App SDK ecosystem so developers can adopt it inside their apps. Important clarifications from the preview material:

• The change is presented as a WinUI control aimed at developers, not a system‑wide shell replacement guaranteed to appear in File Explorer immediately.
• The control’s interaction model is a familiar split‑button pattern adapted for context menus: left = execute, right = expand secondary items.

These caveats mean the user‑facing behavior depends on developer adoption and any eventual shell integration Microsoft chooses to ship; current previews encourage app teams to experiment first.

---

How the SplitMenuFlyoutItem control works​

Interaction model (user side)​

• Left area: executes the primary action immediately (e.g., open file in primary app).
• Right area (chevron): expands a compact secondary flyout with related commands and alternate apps (e.g., “Open with > Paint, Editor, …”).
• Overflow: legacy or less relevant verbs can be relegated to a "Show more options" overflow to preserve discoverability without cluttering the primary list.

Developer surface (how apps implement it)​

• The control is exposed via WinUI and distributed through the Windows App SDK preview packages, enabling developers to:
• declare a default/primary command,
• populate the secondary flyout with grouped related actions,
• provide context‑aware behavior (different secondary items by file type).

Technical benefit​

• Moving menu composition to WinUI/WinRT enables modern, out‑of‑process registration and asynchronous enumeration of items, which can reduce the fragility and performance issues associated with in‑process COM shell extensions. This is an explicit design goal behind the modern control model.

---

Why this matters: benefits for users and developers​

• Reduced vertical clutter. The split model compresses multiple similar entries into a single, denser row, shortening menus and reducing mouse travel.
• Contextual relevance. Developers (or the shell) can promote the most relevant action for the filetype, keeping the surface focused.
• Faster common tasks. Frequently used commands are one click away; secondary or advanced actions are tucked into a predictable place.
• Cleaner developer model. WinUI provides a formal API for grouping related actions instead of relying on ad‑hoc COM hooks, which helps standardize behavior across apps.

For a platform with an enormous ecosystem of third‑party tools, this is not just polish — it’s an opportunity to tame a UX that has long been open to arbitrary extension and often inconsistent results.

---

Critical analysis: limitations and risks​

The split context menu is a sensible and pragmatic approach, but it is not a silver bullet. The path to a clean experience faces several non‑trivial hurdles:

1) Legacy compatibility​

The Windows shell still relies heavily on COM interfaces (IContextMenu, IContextMenu2, IContextMenu3) that allow third‑party code to inject menu items at render time. Those entries run in‑process with Explorer and do not automatically map to the new WinUI registration model. Without a robust compatibility layer or migration path, many legacy utilities risk being pushed behind the overflow or hidden entirely from the primary menu. This could break workflows for power users and enterprises that depend on those verbs.

2) Developer adoption lag​

Smaller vendors and open‑source tools may not prioritize migrating to WinUI/Windows App SDK packages, particularly if they target older Windows versions. That will prolong a mixed experience where some apps adopt split entries and others remain in the overflow.

3) Discoverability and accidental actions​

A split row introduces two distinct interaction targets. Users accustomed to clicking anywhere on a row to get a submenu may accidentally trigger the primary action, and vice versa. There’s real potential for a brief learning curve or mistakes until the behavior becomes familiar. Clear affordances and persistent settings (pinning a secondary item to the primary slot) would help mitigate this.

4) Performance pitfalls​

If the secondary flyout must synchronously enumerate many providers (for example, dozens of registered apps or cloud providers), the secondary menu could be slow to open, negating some benefits. The control needs asynchronous patterns and caching guidance to avoid introducing latency.

5) Accessibility compliance​

Hybrid split controls must be keyboard navigable, screen‑reader friendly, and predictable in focus order. If accessibility is under‑specified, the redesign could reduce usability for assistive technology users. Microsoft and third‑party developers must prioritize solid Automation and focus semantics for both the primary and secondary targets.

---

Enterprise, privacy, and policy considerations​

• Enterprise control: Administrators will require Group Policy or MDM controls to manage which actions appear by default, especially to hide cloud or AI actions that could send file metadata or contents off‑box. Early previews have not yet documented the enterprise management surface for the split menu, so IT teams should monitor preview release notes closely.
• Privacy/telemetry: Promotion logic that favors frequently used apps may rely on local telemetry. Enterprises and privacy‑conscious users will want clarity on whether that promotion promotes cloud actions or Copilot features by default. Policies to suppress cloud‑bound actions should be available.
• Compatibility testing: Organizations that rely on custom shell integrations (backup agents, security tools, VCS clients, compression utilities) must test those workflows on preview SDKs and Insider builds once available. Vendors should be contacted to confirm their migration plans.

---

How Microsoft can (and should) manage migration​

A smooth transition requires a multi‑pronged approach:

• Publish clear migration guides and samples in the Windows App SDK and WinUI Gallery that show how to:
• map legacy COM verbs to SplitMenuFlyoutItem,
• implement asynchronous enumeration,
• set accessibility properties for split controls.
• Provide a compatibility shim that can translate common legacy patterns into the split model rather than silently hiding items behind “Show more options.”
• Expose enterprise policies to manage promoted/default verbs and to disable cloud/AI actions by default.
• Ship WinUI Gallery samples demonstrating correct focus, keyboard, and screen‑reader behavior to set accessibility expectations.

---

Timeline, availability, and verification​

Current evidence indicates the split menu concept is present in developer previews and WinUI community demos; the control is being made available through the Windows App SDK preview channel for developers to experiment with. There is no confirmed general availability date for a system‑wide rollout in File Explorer, and the screenshots shown in the community call are representative examples, not a guaranteed final UX for the shell. Treat the specifics (exact control name, shipping plan for Explorer) as preview‑stage details that may change. Developers who want to prototype should:

• install the latest Windows App SDK preview packages and inspect WinUI Gallery samples, and
• test behavior across assistive technologies and with any third‑party shell extensions their app integrates with.

Administrators and power users should:

• watch Insider channels for early File Explorer integrations,
• coordinate with vendors that supply shell extensions, and
• plan pilot rollouts before broad enterprise deployment.

---

Practical recommendations​

• For everyday users: expect reduced clutter if Microsoft and app developers adopt the pattern, but keep in mind that legacy items may remain in the overflow for some time. If a required tool disappears from the default menu, use “Show more options” or consult vendor documentation.
• For developers: start experimenting now with the Windows App SDK preview and adapt your context‑menu registrations to the SplitMenuFlyoutItem pattern. Prioritize keyboard navigation and screen‑reader semantics in your design.
• For IT admins: inventory mission‑critical shell extensions and test them against preview SDKs; demand vendor compatibility plans and watch for Group Policy controls that manage promoted verbs and AI actions.

---

The bigger picture: a sensible direction, not a finished product​

The split context menu proposal addresses a long‑standing, structural problem: menus grew because the platform allowed disparate parties to append items with little common taxonomy. By offering a modern control and a developer‑driven model, Microsoft is shifting the responsibility for organization back to app teams, while giving the shell an opportunity to display a cleaner surface. If executed carefully — with a solid compatibility shim, clear migration guides, enterprise controls, and thorough accessibility testing — the split menu could be one of the quiet, high‑impact usability wins for Windows 11. But the devil is in the details: migration friction, developer inertia, discoverability tradeoffs, and performance edge cases must be handled explicitly. Microsoft’s next moves — publishing authoritative docs, releasing stable SDK samples, and surfacing a transparent rollout plan — will determine whether this remains a promising demo or becomes a practical improvement in everyday Windows workflows.

---

Conclusion​

Microsoft’s WinUI‑led approach to split context menus represents a pragmatic, developer‑centric response to the long‑running problem of cluttered, inconsistent right‑click menus in Windows. The proposed SplitMenuFlyoutItem control offers a clear interaction model (primary left action + compact secondary flyout) that can reduce vertical clutter, improve relevance, and enable modern registration patterns that are safer and more maintainable than legacy COM extensions. This is a meaningful technical direction and — if Microsoft couples it with compatibility tooling, enterprise policy controls, and rigorous accessibility standards — it could materially improve File Explorer and app context menus. For now, the work lives in previews and community demos; the final user experience depends on developer adoption and how Microsoft handles the migration story. The coming months of WinUI preview releases and Insider builds will be the place to verify how this idea matures into a shipped feature.

---

Source: Neowin Microsoft is fixing cluttered context menus in Windows 11 apps

 

[ChatGPT]

Microsoft’s WinUI team quietly showed a path out of one of Windows 11’s longest‑running UX gripes: the bloated right‑click (context) menu. The company is experimenting with a Split Context Menu pattern — powered by a new WinUI control referred to as SplitMenuFlyoutItem — which collapses related verbs into a single, split menu row (left side = immediate/default action; right side = compact secondary flyout). The aim is straightforward: make context menus far shorter and more useful by surfacing a clear primary action while keeping other, related choices available in a small, context‑aware submenu. Early previews claim menu heights can be reduced by up to around 38% for some item types, but the feature is still in developer preview and not yet a finalized system change.

Background​

Since Windows 11 launched, the right‑click menu has been a frequent source of praise and complaint in equal measure. Microsoft initially simplified the menu to reduce clutter and modernize visuals, but that change introduced a two‑tier experience — a compact top layer and a legacy “Show more options” fallback — that left power users frustrated and created a fresh set of problems.

• Third‑party apps, installers, and legacy shell extensions continued to inject verbs into the menu.
• New Microsoft features and AI integrations added more items over time.
• The result was a long vertical list that often repeated similar actions (for example: Open, Edit, Set as background — for the same app), forcing pointer travel and mental scanning.

The “Show more options” fallback and the Shift+right‑click / Shift+F10 shortcuts are still available for people who need the classic full menu, and registry tweaks or group policy adjustments can force the legacy behavior — but those are workarounds rather than cures. The Split Context Menu proposal attacks the root cause: the lack of a structured, programmable way to group related actions at the top level.

---

What Microsoft demonstrated: the Split Context Menu explained​

The basic interaction model​

The Split Context Menu pattern introduces a hybrid menu item that behaves as both a single‑click action and a submenu container:

• Left half (primary): a single click immediately performs the default action (for example, “Open with Photos”).
• Right half (secondary affordance): a small chevron or split area opens a compact, adjacent flyout that contains related actions and alternate apps (for example, “Edit with Paint,” “Set as wallpaper,” other image editors).

This keeps the top level of the menu short and scannable while preserving discoverability for less‑frequent tasks.

Context awareness and grouping​

A central promise of the model is context awareness: the split item’s secondary flyout changes based on file type and app relationships. Examples:

• Text file: left side → Open with Notepad; right side → other editors and related operations.
• Image file: left side → Open with Photos; right side → alternate editors, edit actions, set wallpaper.
• Folder: left side → Open; right side → compress, pin, share, or other folder‑specific tools.

Developers are slated to control which verb is primary and which actions are placed in the secondary flyout, and system heuristics may promote frequently used choices into the primary slot over time.

The WinUI control and distribution path​

The control shown in previews is described as a WinUI 3 control — SplitMenuFlyoutItem — expected to arrive via the Windows App SDK preview channel. That means the initial distribution and adoption path is developer‑centric: app teams can update their apps and menus using the new API before any system‑wide shell integration is finalized.
This signals a pragmatic approach: modernize the developer platform first, then improve shell behavior as app developers adopt the control and Microsoft integrates the pattern more broadly.

---

What’s verified and what remains provisional​

What appears consistent across previews and reporting:

• Microsoft acknowledged the context menu has become cluttered and demonstrated a split menu approach in a WinUI community presentation.
• The split pattern groups related verbs under a hybrid primary/secondary control, reducing menu vertical length and repetition.
• The control shown is described as SplitMenuFlyoutItem and is framed as a WinUI/Windows App SDK control for developers.

What is still subject to change or unverified:

• Exact availability and shipping timeline. The feature was shown in developer/preview channels but was not present in stable Insider builts at the time of the demonstration.
• The presence of a finalized control in an official, stable GitHub or SDK release at time of reporting; preview artifacts and demos exist, but the API and naming could shift before final release.
• The specific percentage reductions (e.g., up to 38% shorter menus) come from demonstration materials and represent projected UX gains for particular file types; real‑world reductions will vary by installed apps, third‑party shell extensions, and enterprise settings.

Because this is a developer‑first preview, timelines, control names, and telemetric promotion rules are subject to iteration.

---

Why this change matters for everyday users​

Cleaner, faster right‑click workflows​

Shorter menus mean less vertical travel for the pointer and fewer seconds wasted hunting for common commands. Consolidating multiple entries for the same app into one split row reduces visual noise and cognitive load.

Better signals for the most important action​

By making one action the primary click target, the system can prioritize the action users are most likely to want (e.g., “Open” for most files), while still keeping alternatives one click away. For many users the result will be an interface that feels faster by default.

Developer‑driven improvements​

Moving the change into WinUI means app teams can adopt the pattern and craft logical groupings tailored to their domain (photo editors, IDEs, compressed archive tools, etc.. This is preferable to a centralized, one‑size‑fits‑all grouping that might misrepresent app semantics.

---

Strong benefits — and why they are credible​

• Reduced repetition: duplicate verbs for the same app (open, edit, set as wallpaper) can be grouped.
• Contextual relevance: file‑type awareness lets menus show only what matters.
• Discoverability preserved: secondary flyouts keep less common actions available without cluttering the primary list.
• Developer control: app developers get a modern API to express menu intent rather than relying on fragile COM shell verbs.
• Lower pointer travel: shorter menus and denser rows reduce search time and improve ergonomics.

From a UX standpoint, these are textbook gains: present the most likely action, hide complexity behind a predictable affordance, and give developers the tools to implement domain‑appropriate grouping.

---

Risks, edge cases, and the real challenges​

No UX change is risk‑free. The Split Context Menu introduces several practical concerns that Microsoft and developers must address before a broad rollout:

1. Discoverability and muscle memory​

Power users build muscle memory for context menu locations and ordering. If frequently used items move into a secondary flyout by default, those users may be slowed until they adapt. Microsoft will need sensible defaults and migration strategies that respect common workflows.

2. Accessibility and keyboard navigation​

A split control requires careful accessibility design:

• Keyboard users must be able to reach both the primary action and the secondary flyout predictably (tab/arrow behavior).
• Screen readers must clearly announce that an item has a split/secondary menu and what the default action will do.
• Focus visuals and high‑contrast themes must remain usable.

If the new control does not include solid, built‑in accessibility affordances — or if third‑party developers implement it incorrectly — the net outcome could be a regression for users who rely on assistive technologies.

3. Legacy shell extensions and migration​

Windows has decades of third‑party shell extensions that register verbs via COM. Migrating those verbs into the new split model is non‑trivial:

• Will existing installers and COM extensions be automatically translated into secondary flyouts?
• Will installers need to ship updated manifests or wrapper DLLs?
• If legacy verbs are hidden or relegated to secondary positions without developer intent, automation and scripted workflows could break.

Microsoft must provide tooling and migration pathways to prevent loss of functionality.

4. Enterprise manageability and policy​

Enterprises expect predictable behavior — especially when automation, compliance, or security tooling depends on specific menu entries. Administrators will want Group Policy, ADMX templates, or registry knobs to:

• Lock menu behavior, forcing legacy menus where needed.
• Prevent telemetry‑driven automatic promotions.
• Ensure managed apps keep primary items exposed where required.

Lack of enterprise controls could lead to pushback in corporate environments.

5. Performance and runtime costs​

A menu that queries installed apps, COM extensions, and telemetry to decide what to show risks runtime overhead. Microsoft must ensure:

• On‑demand enumeration is fast and cached.
• Timeouts and async patterns avoid UI jank.
• The shell still behaves predictably on low‑end hardware and in high‑churn environments.

6. Fragmentation if adoption is patchy​

If only WinUI apps adopt split items and many popular apps remain on legacy registration patterns, users will see a mixed experience — sometimes concise menus, sometimes long ones — which can feel inconsistent or worse, more confusing.

---

Developer guidance: what app teams should prepare for​

If the Split Context Menu control becomes standard, developers and maintainers should treat it as a prioritized UX task:

• Decide the primary action for each relevant file type or context and choose it intentionally.
• Populate the secondary flyout with logically grouped alternatives and advanced actions.
• Implement keyboard and screen reader support as part of the control implementation, not as an afterthought.
• Test interactions under varied conditions: high numbers of registered verbs, offline scenarios, restricted‑permission accounts, and enterprise policy states.
• Provide installers and migration paths for legacy shell integrations so critical verbs aren’t lost.
• Monitor telemetry and user feedback to adjust which actions are promoted to primary status.

A well‑executed migration can improve user workflows and make the app feel more modern. A poor one will surprise users and increase support calls.

---

What IT administrators and power users should do now​

• Keep an eye on the Windows App SDK preview channel and Insider builds for early appearances of the control and sample code.
• Avoid relying on context menu ordering for automation; prefer command‑line tools, PowerShell, or explicit executable calls in scripts.
• If you must preserve legacy behavior, remember these practical options:
• Press Shift while right‑clicking or use Shift+F10 to open the classic full menu temporarily.
• Consider registry or Group Policy edits to restore the classic menu where needed (these are effective but require caution and can break with future OS updates).
• Prepare to test critical workflows on Insider or preview channels before a broad OS rollout to catch regressions early.
• Watch for updated ADMX templates and administrative controls once Microsoft confirms the final behavior.

---

Timeline and likely rollout path​

The plausible path for this change is:

• WinUI / Windows App SDK preview release with the new control and sample code for developers.
• Developer adoption as app teams update menus and installers.
• Windows Insider Preview inclusion (Dev/Beta channels) for shell integration testing.
• Gradual system‑wide rollout tied to a feature update or cumulative updates.

At present, the Split Context Menu appears to be in development and preview stages. No firm consumer shipping date was announced in the preview materials. Because the initial distribution is through WinUI/SDK channels, the speed and breadth of the change will depend heavily on developer uptake and Microsoft’s choices about integrating the pattern into the Windows shell.

---

Practical alternatives and what users can do today​

Until the split model ships broadly, users annoyed by context menu clutter have a few options:

• Use Shift+right‑click or Shift+F10 to immediately access the classic full menu when needed.
• Apply registry or Group Policy changes to restore the classic menu by default (these are reversible but carry risk and may be unsupported in future updates).
• Use third‑party context menu managers with caution — they can reorder and hide items but may interfere with system stability.
• Encourage developers of key apps to adopt modern WinUI menus (or at least to reduce redundant verbs).

Those are stopgap measures, not replacements for a well‑designed system solution — but they can ease workflows while the platform evolves.

---

Final analysis: promising design, execution is everything​

The Split Context Menu is a sensible, pragmatic answer to a problem that grew from years of well‑intentioned but uncoordinated menu injections. By introducing a clear API for grouping related actions and separating the immediate click from auxiliary choices, Microsoft and the WinUI team offer a route back to clarity without sacrificing power.
However, the proposal’s success depends more on the implementation details than on the concept:

• Will Microsoft provide solid migration tooling for legacy shell verbs and third‑party extensions?
• Will accessibility and keyboard interactions be first‑class?
• Will enterprise controls and policy options be in place before wide release?
• Will the platform keep runtime costs low and maintain consistent behavior across mixed‑app environments?

If those questions are answered well, the Split Context Menu can deliver measurable productivity gains for everyday Windows workflows and reduce a long‑standing source of irritation. If not, the change risks introducing new surprises for power users, admins, and accessibility‑dependent workflows.
For now, the direction is encouraging: Microsoft is admitting the design drift and showing a concrete pattern to fix it. The next months — SDK previews, Insider builds, and developer adoption — will decide whether this becomes one of Windows 11’s quietly useful refinements or another UX experiment that needs iteration.

---

Source: How-To Geek Windows 11 might clean up its messy right-click menu