Microsoft quietly showed a credible path out of one of Windows 11’s most persistent gripes — the long, crowded right‑click (context) menu — with a
split context‑menu concept surfaced during a WinUI developer presentation, but the change is still an early, developer‑first proposal and not a finished, system‑wide fix.
Background / Overview
Windows’ right‑click context menu has always been a powerful, composable surface: installers, shell extensions, and apps can add verbs and entries, which made sense in a world when most users ran a handful of programs. Over the last several years that open‑ended approach produced a cluttered, inconsistent menu that Windows 11’s initial redesign tried to solve by simplifying the top layer and pushing legacy items into an overflow. That attempt reduced surface noise for casual users but introduced a two‑tier discovery problem: everyday tasks were sometimes harder to get to, and the menu still grew as apps, cloud services and AI features added their own entries. In early November 2025 Microsoft’s WinUI team demonstrated an alternate path: a
Split Context Menu pattern driven by a new WinUI control (referenced in community reporting as SplitMenuFlyoutItem). The idea is simple and pragmatic — a single menu row acts as both a primary action and a container for related secondary choices, reducing vertical length while preserving discoverability. The preview is targeted at WinUI 3 apps via the Windows App SDK so developers can adopt the control and modernize their app menus. Early reporting and screenshots suggest the approach can meaningfully shrink menu height for common file types.
What Microsoft showed (the Split Context Menu explained)
The interaction model
- The top‑level menu presents a single, focused row as the primary action for a file type (for example, “Open with Photos” for images).
- The left half of that row executes the default action immediately when clicked.
- The right half — a small chevron or split affordance — opens a compact side flyout containing related actions and alternate apps (for example, “Edit with Paint”, “Set as wallpaper”, other installed editors).
- Less relevant or legacy verbs can be relegated to the overflow (“Show more options”), keeping the primary list short and scannable.
This pattern mirrors established split‑button UX but applied to context menus and tailored to the File Explorer scenario, where thousands of independent registrations previously made the surface chaotic.
The developer surface
The new control reportedly appears as part of WinUI 3 and the Windows App SDK preview channel. That makes this a developer‑first change: app teams can define a primary action and populate the secondary flyout with related commands. The result is a way to modernize context‑sensitive interactions without fragile, in‑process shell extensions. Early articles and community thread writeups reference a control called SplitMenuFlyoutItem in WinUI preview materials. However, Microsoft has not yet published a formal, stable OS‑level SDK announcement for a system‑wide migration of legacy shell verbs. Treat the control name and API shape as
preview information rather than finalized contract.
Example: right‑click an image
- Before: multiple menu lines (Open, Open with Photos, Edit, Edit with Paint, Set as wallpaper, and duplicated app entries).
- After (split pattern): a single “Open with Photos” row; click the left half to open, hover or click the chevron to reveal Paint, Snipping Tool and “Set as wallpaper” inside a compact flyout. The main menu is shorter, uses less pointer travel, and places the most common action first.
Why this matters: the potential benefits
- Reduced vertical clutter — Grouping related verbs into one split row directly addresses the “endless vertical list” complaint and reduces scrolling and pointer travel. Early materials claim menu height reductions for some item types in the 30–38% range.
- Better first‑click relevance — Promoting a sensible default per file type gives faster access to the action most users want, improving speed for common workflows.
- Developer‑led modernization — Moving context‑menu responsibilities into WinUI encourages consistent, testable registration patterns and reduces the fragility of legacy COM shell extensions. This should make menus more maintainable and interoperable over time.
- Opportunity to fix performance and accessibility — Because WinUI controls use modern accessibility APIs and async patterns, the move is an opportunity to address long‑standing performance and assistive‑tech regressions — if Microsoft enforces or encourages async enumeration for providers and robust screen‑reader semantics.
Realities and limits: why this is not an immediate cure
1) It’s a preview and developer preview at that
All coverage so far is based on a WinUI community demo and preview SDK signals; the split pattern is visible in demos but has not yet landed as an integrated system change or inside public Insider builds. That means the control is available for experimentation but not yet a universal File Explorer behavior. Expect a multi‑stage rollout if Microsoft decides to adopt this pattern system‑wide: preview SDK → app adoption → possible shell migration → Insider test builds → general release.
2) Legacy shell extensions and ecosystem compatibility
The Windows shell has thousands of legacy in‑process COM extensions. Without a robust migration path or compatibility shim, those verbs may remain in the overflow for years, producing a mixed experience. Enterprise tools that depend on custom context‑menu verbs (archivers, VCS clients, backup utilities) will need to update to the new registration model — or risk important commands being harder to reach. Preparing enterprise inventories and vendor coordination will be critical.
3) Discoverability and muscle memory tradeoffs
Split items introduce a dual target: left = execute, right = expand. Some users may click the primary action by habit when they intended to open the secondary menu. Microsoft and app teams must get the affordance right (visual cue, cursor hotspots, keyboard semantic) and provide discoverability (keyboard shortcuts, persistent user preferences) to reduce accidental actions.
4) Performance edge cases
If the secondary flyout requires synchronous enumeration of many providers (for example, scanning all installed editors or cloud providers), the split menu could stall and feel slower. The implementation must favor asynchronous enumeration with placeholders and incremental loading to preserve snappiness. If not handled, users could trade visual length for perceptible lag.
5) Microsoft’s incentives and priorities
The WinUI demo shows intent, but shipping a shell‑level change requires addressing migration, enterprise policy, accessibility, telemetry, and backward compatibility. Microsoft must weigh the engineering and compatibility costs against other priorities. The proof will be whether the company publishes stable WinUI/Windows App SDK docs, releases Insider builds with the pattern, and provides migration guidance to vendors. Until those steps appear, the community should treat this as a promising direction, not a committed product change.
Cross‑checking the claims (verification and caveats)
Multiple independent outlets reported the WinUI demo and the Split Context Menu concept after the community call, including WindowsLatest and PCWorld, which cite the WinUI presentation and preview SDK. Both emphasize that the change is currently available to developers as a WinUI control and not yet a system‑wide migration. Those independent reports line up on the core facts: (a) Microsoft has a split menu design under exploration, (b) the control is aimed at WinUI/Windows App SDK, and (c) there is no immediate public Insider build shipping the change yet. At the same time,
formal, stable Microsoft documentation or a blog post announcing a timeline is not yet available. Claims about exact API names, shipping dates or that Explorer will instantly adopt the control are drawn from demos and preview materials; those details can change before shipping. Where reporting names the control SplitMenuFlyoutItem, that is based on preview references and community screenshots rather than a final, immutable API contract. Treat that naming and behavior as highly likely but not guaranteed.
Practical implications for users, power users and IT admins
For everyday users
If Microsoft and app vendors adopt this pattern broadly, expect
shorter, cleaner right‑click menus and fewer duplicate entries. That will likely feel less noisy and more predictable. But there’s no instant way to force that on existing apps: the benefits depend on developer adoption and eventual shell integration.
For power users
- Registry hacks and third‑party tools currently still provide ways to change the context‑menu experience today (for example, restoring the classic menu or using customization tools), but those carry maintenance and stability tradeoffs and will not be necessary if Microsoft implements a clean migration path. Many power users will still want toggles to surface full menus by default; Microsoft should consider a Settings pane or official tool to control promoted verbs and visibility.
For developers
- Start experimenting with the Windows App SDK preview and WinUI packages to evaluate how the SplitMenuFlyoutItem pattern fits your app’s needs.
- Audit your context‑menu registrations: decide which actions belong in the primary slot and which should be secondary.
- Implement asynchronous enumeration for secondary items to avoid blocking UI rendering and add clear accessibility semantics.
For IT admins and enterprise
- Inventory any mission‑critical shell extensions and vendor context‑menu integrations.
- Coordinate with ISVs to ensure important verbs are re‑registered with a modern API or have an enterprise policy workaround.
- Pilot any WinUI preview changes in controlled environments before broad deployment; ensure assistive tech and keyboard workflows remain functional.
What Microsoft should do next (a practical wishlist)
- Publish a clear migration guide and compatibility shim for legacy COM shell extensions, with tooling to map or promote existing verbs to SplitMenuFlyoutItem registrations.
- Provide enterprise policy controls to pin, hide, or promote context menu items centrally.
- Offer a Settings page or official PowerToys‑style add‑on for right‑click menu customization — that gives non‑technical users safe toggles without using the Registry.
- Ensure keyboard and screen‑reader parity: keyboard nav must allow opening the secondary flyout without forcing pointer use, and screen‑reader labels must reflect the split affordance.
- Enforce async enumeration for third‑party providers and ship performance telemetry to detect slow providers that could degrade the UI.
Short‑term workarounds and sensible user choices
- Use Shift+Right‑click to bring up the classic, full context menu when you need it now.
- For persistent preferences, community registry tweaks can re‑enable the old menu surface, but these are not supported by Microsoft and may be reverted by future updates; back up the Registry before editing.
- Consider trusted third‑party tools if you need advanced, permanent customization today — but accept that they can become brittle after OS updates.
- Developers: try the Windows App SDK preview to trial the split pattern inside your apps and gather user feedback now.
Final analysis: promise with prerequisites
The Split Context Menu concept is a thoughtful, technical answer to a real UX problem: it shifts responsibility to app teams using a modern control and gives the shell an opportunity to display a cleaner, contextual surface. If Microsoft follows through with robust migration tooling, accessibility guarantees, enterprise policy controls and a staged rollout, this could be one of Windows 11’s quiet, high‑impact usability wins. However, the outcome depends on execution. Legacy compatibility, developer adoption lag, discoverability challenges and potential performance pitfalls are real risks. At present, the work is visible in WinUI demos and preview SDK channels — a credible signal that Microsoft is actively addressing the issue, but not yet a guarantee that File Explorer or the whole shell will adopt the pattern immediately. Treat the demonstration as a well‑designed directional fix rather than a shipped feature, and watch the Windows App SDK preview and Insider channels for the next concrete steps.
Closing takeaway
Microsoft’s split context‑menu idea solves the right problem in the right way: simplify what’s visible, preserve what’s discoverable, and give developers a sane API to express context. The UX payoff could be substantial for everyday productivity — but only if Microsoft couples the control with a real compatibility and accessibility story and helps ecosystem partners move their verbs into the modern model. For now, the change is promising, cautious and developer‑centric; the community should applaud the direction and, at the same time, demand the compatibility, policies, and controls that will make it durable for all users.
Source: TechRadar
https://www.techradar.com/computing...a-hint-that-it-could-become-more-streamlined/