Split Context Menu: Windows 11's SplitMenuFlyoutItem UI overhaul for File Explorer

Microsoft is preparing a targeted overhaul of Windows 11’s long‑complained‑about right‑click menu in File Explorer — a redesign, previewed in WinUI developer materials, that replaces jammed vertical lists with split menu entries driven by a new WinUI control called SplitMenuFlyoutItem.

Background​

Since Windows 11 launched, the Context Menu (the right‑click menu) has elicited steady user criticism for being cluttered, repetitive, and inconsistent across shell surfaces. What started as a relatively compact list has accumulated entries from built‑in commands, app registrations, legacy shell extensions, and third‑party installers — often producing multiple near‑duplicate items for the same app (open/edit/set as background), and burying frequently used commands deeper under submenus. Microsoft has acknowledged the problem and is exploring UI and API changes to make context menus genuinely contextual again. The current proposal, shown in WinUI community previews and reported in multiple outlets, is branded internally as a Split Context Menu that groups related actions and surfaces a single primary action with an adjacent gate to secondary tasks.

---

What Microsoft is changing: the Split Context Menu explained​

The split entry model​

The Split Context Menu introduces a horizontal split in a single menu row:

• The left side is a primary action (one click performs the default operation, e.g., “Open with Photos”).
• The right side contains a chevron or small affordance that opens a compact secondary flyout with related actions or additional apps.

This hybrid control is intended to eliminate multiple vertical entries that are functionally related and replace them with a single, denser row that still gives quick access to secondary commands without lengthening the top‑level list.

The new WinUI control: SplitMenuFlyoutItem​

Preview materials name the control SplitMenuFlyoutItem — a WinUI3 control that behaves like a button + submenu hybrid. Developers can reportedly declare a primary action and populate the nested flyout with secondary commands. This design allows File Explorer and apps to show fewer top‑level items while preserving discoverability for advanced or context‑specific commands.

Context awareness and grouping​

A key promise is context‑aware grouping: the items shown in the nested flyout will adapt to the selected file type and user behavior. For example:

• Right‑click a .txt file → primary “Open with Notepad”, secondary editors in the flyout.
• Right‑click an image → primary “Open with Photos”, secondary items (Edit, Set as wallpaper, other image apps) tucked into the flyout.

Developers are expected to control which action is primary and which items are nested. System heuristics may promote frequently used apps into the primary slot over time.

---

Why this matters: UX and real‑world benefits​

• Shorter menus — reducing vertical length makes important items easier to find and reduces pointer travel.
• Less repetition — duplicate entries for the same app (open/edit/etc. can be consolidated.
• Preserved discoverability — secondary tools remain accessible, but off the primary path.
• Developer control — WinUI‑based apps can tailor menus by file type, improving the user experience for domain‑specific workflows.

For users who install many apps that previously injected multiple shell verbs into the top‑level menu, the split model should meaningfully reduce noise and cognitive overhead.

---

Implementation path: APIs, Windows App SDK, and preview availability​

Reports indicate the SplitMenuFlyoutItem control is a WinUI3 component and that the Windows App SDK preview channel is the distribution vehicle for new WinUI controls. Microsoft often surfaces new controls and API previews through the Windows App SDK preview packages and WinUI releases before broad OS integration, which allows app developers to experiment and adopt changes ahead of system‑wide rollouts. At the time of reporting, Microsoft has shown the concept in a WinUI Community Call and in developer previews, but the feature was not yet present in public Insider builds for general testing. That suggests the change will follow the standard preview → Insider → channel‑release path, and may depend on developer adoption to ensure ecosystem compatibility. Caveat: several outlets claim the API is available on official Microsoft repositories, but direct references or stable GitHub entries for a finalized SplitMenuFlyoutItem control were not reliably discoverable at the time these articles were published. This remains a point to verify as preview SDK releases and WinUI documentation update.

---

Developer implications: what app makers must consider​

• Adoption window — app developers who rely on Win32 shell verbs and legacy shell extensions will need migration guidance. The SplitMenuFlyoutItem is a WinUI control, so migrating may require updating app packaging or adding WinUI‑based menu registration layers.
• API surface — developers must choose which action is primary and which are secondary, meaning design decisions about task prioritization become part of app UX.
• Telemetry and promotion logic — if Windows promotes frequently used apps into the primary slot, developers should understand how telemetry, file associations, and user preferences influence that behavior.
• Compatibility with legacy shell extensions — many installers and utilities still register COM‑based shell extensions; Windows will need to bridge those extensions into the new model or provide transformation helpers.

The transition therefore requires clear documentation, migration tooling, and backward compatibility layers; otherwise, third‑party tools could be downgraded into hidden or secondary positions unexpectedly.

---

Risk analysis: technical, compatibility, and ecosystem concerns​

Legacy shell extensions and stability​

The old shell extension model exposes a technical risk: many third‑party handlers are poorly written or rely on synchronous COM callbacks that can hang File Explorer. If Microsoft reintroduces runtime hooks that still enumerate legacy COM extensions at top level, it must preserve the longstanding need for stability and timeout handling. The new split model could either reduce the top‑level enumeration cost (by hiding many extensions) or complicate it (if nested flyouts trigger on hover and cause late enumeration). The net effect depends on implementation details that are not public yet.

Discoverability and discoverability regressions​

Condensing multiple entries into a split row improves density, but also introduces a two‑target interaction model — a click target for the primary action and a smaller target for the secondary menu. That raises discoverability concerns for users who expect to see all available verbs at a glance, or who rely on muscle memory to execute a less common command. Accessibility considerations (keyboard navigation, screen reader labeling, and large pointer targets) must be carefully implemented to avoid regressing usability.

Enterprise management and security policies​

Enterprises that lean on Group Policy, AppLocker, or custom shell integrations will need control over the new behavior. Administrators will expect policy controls to:

• Enforce legacy menu visibility,
• Lock primary actions for managed apps,
• Disable telemetry‑driven promotions.

Absent management controls, the split model could frustrate IT departments that depend on predictable context menu behavior for scripted workflows. This is especially relevant for kiosks, thin‑client deployments, and automation tools.

Performance and runtime cost​

Although the split approach aims to reduce UI height, it may increase per‑item complexity (hover logic, fetch of secondary commands, grouping heuristics). If the nested flyout requires on‑demand enumeration of registered apps or COM extensions, there will be performance trade‑offs that Microsoft must mitigate with asynchronous patterns, caching, and robust timeouts.

---

Accessibility and keyboard behavior​

A two‑part control requires careful keyboard affordances:

• Keyboard users must be able to reach the primary action and the secondary menu with predictable keystrokes.
• Screen readers must announce both the primary behavior and the existence of a nested flyout.
• High‑contrast themes and focus visuals must remain intact for users with visual impairments.

If Microsoft follows established WinUI patterns, controls will gain built‑in accessibility hooks; however, third‑party apps that implement custom verbs will still need to follow new patterns to remain accessible. This is an area where developer guidance and sample code will be essential.

---

Administration and power‑user considerations​

• Power users who use shell tweaks or registry hacks to add custom verbs should expect migration guidance from Microsoft. The company will likely offer a transition path so that existing verbs appear in the secondary flyout rather than vanishing.
• System administrators should look for upcoming Group Policy templates and Windows ADMX updates in Insider releases to control the split behavior.
• Scripted workflows that rely on exact menu ordering or the presence of context menu items may need to be updated to use command‑line tools or explicit executable calls rather than a fragile UI path.

---

How and when you might see it​

Reports indicate the feature is still in early development and not yet available in Insider builds at the time of reporting. As with other UI changes, expect the following sequence:

• WinUI / Windows App SDK preview release with the control and sample code for developers.
• WinUI Community Call demos and developer preview guidance.
• Inclusion in Windows Insider Preview builds (Dev/Beta channels) for hands‑on testing.
• Incremental system‑wide rollout tied to a Windows feature update or cumulative set of updates.

No firm shipping date has been announced; developers and administrators should watch the Windows App SDK preview channel and Insider builds for the first appearance.

---

What we verified and what remains unverified​

Verified:

• Multiple independent outlets report Microsoft is working on a “Split Context Menu” and demonstrated the concept in WinUI community materials.
• The proposed control name shown in reporting is SplitMenuFlyoutItem, described as a WinUI3 component that supports split primary/secondary actions.

Unverified / flagged:

• Several articles state the API has been published in Microsoft’s WinUI GitHub repo or Windows App SDK; a stable, discoverable GitHub control entry or finalized API documentation for SplitMenuFlyoutItem could not be conclusively located at the time of reporting. Readers should treat claims of immediate API availability with caution until official WinUI/Windows App SDK release notes or GitHub commits confirm it.

---

Recommendations for users, admins, and developers​

For end users:

• Expect the context menu to evolve; if you rely on a particular verb that disappears from top level, check the nested flyout or “Show more options”.
• Keep Windows Insider and app update channels under observation if you want early access to and feedback on the change.

For system administrators:

• Monitor Insider channels and Windows App SDK previews for policy templates and ADMX updates.
• Validate critical scripts and automation against Insider builds before broad deployment.
• Prepare fallback automation that calls executables or PowerShell scripts directly instead of relying on UI elements.

For developers:

• Track Windows App SDK preview releases and WinUI samples for guidance on implementing SplitMenuFlyoutItem.
• Update installer and context‑menu registration strategies to opt into split behaviors where appropriate.
• Test accessibility, keyboard navigation, and performance on representative hardware and complex shell‑extension environments.

---

Final analysis: promise, but proceed carefully​

Microsoft’s Split Context Menu is a sensible, long‑overdue reaction to a real UX problem. Consolidating related verbs into a single row with a nested menu balances the need for speed (one‑click actions) and depth (secondary commands), and it gives app developers a modern API to express contextual actions cleanly. The design aligns with recent UI trends that prefer compact density and contextual reveal patterns.
However, the transition has feasible risks: legacy shell extensions, discoverability for muscle‑memory users, keyboard and accessibility regressions, enterprise manageability, and runtime performance trade‑offs. The success of the change depends not just on the control’s visuals, but on robust migration tooling, clear developer guidance, and enterprise policy controls.
Until Microsoft publishes formal WinUI docs, SDK releases, and Insider builds that implement the feature, readers should treat implementation details and timelines as provisional. The preview promises real gains for File Explorer users, but execution will determine whether the Split Context Menu is a well‑designed improvement or an interface fragmentation event that introduces new edge cases for power users and IT admins.

---

A thoughtful rollout that provides backwards compatibility, clear developer migration paths, and administrative control will determine whether this UI change becomes a genuine productivity win for Windows 11 or another well‑intentioned update that creates new headaches for power users and enterprises.

---

Source: PCWorld Microsoft is working on a fix for Windows 11's cluttered right-click menu

 

[ChatGPT]

Microsoft’s long‑running frustration with the bloated, cluttered right‑click menu in Windows 11 may finally be getting a pragmatic fix: Microsoft’s WinUI team has demonstrated a Split Context Menu design — driven by a new WinUI control currently shown as SplitMenuFlyoutItem — that promises to make File Explorer’s context menus far shorter, more contextual, and easier to scan without losing functionality.

Background / Overview​

Since Windows 11’s debut, the right‑click (context) menu has been a frequent target of user ire. Attempts to modernize the menu (compact top row, overflow “Show more options”) solved some surface problems but did not stop the menu from accumulating items from legacy COM shell extensions, third‑party installers, and new Microsoft features (including AI/Copilot entries). The result is a vertical list that is often repetitive, inconsistent, and hard to scan.
In a WinUI Community Call demonstration (shown November 5, 2025), Microsoft engineers showcased a different approach: let each menu row do double duty. The left half executes the default action (one click), while the right half exposes a compact, context‑aware flyout with related secondary verbs and alternate apps. That single UI pattern is being prototyped as a WinUI control — SplitMenuFlyoutItem — distributed via Windows App SDK preview packages so developers can begin adopting it inside WinUI 3 apps.

---

What Microsoft showed: the Split Context Menu explained​

The interaction model​

• The top‑level context menu presents a single, focused row for the most relevant action for the selected file type.
• The left side of that row performs the primary/default action immediately (e.g., Open with Photos).
• The right side contains a small chevron or split affordance; clicking or hovering it opens a compact secondary flyout with related commands and alternate apps (e.g., Edit with Paint, Set as wallpaper, Open with…).

This pattern mirrors established split‑button paradigms used elsewhere in UI toolkits but adapts them to the context‑menu environment where thousands of independently registered verbs historically created chaos. The apparent goal: preserve single‑click speed for the common case while making additional choices discoverable without vertical bloat.

The developer surface and API​

The control is being introduced as part of the WinUI/Windows App SDK preview surface. Microsoft’s existing MenuFlyout and MenuFlyoutItem model does not provide a built‑in split action control for menus; the new control would fill that gap and let app teams declare a single primary command and a nested collection of secondary items. The WinUI menu primitives remain the basis for menu construction, but SplitMenuFlyoutItem adds a hybrid left‑execute/right‑expand affordance. Developers can:

• Define which command is the primary verb for each file type.
• Populate the adjacent flyout with related verbs or alternate apps.
• Rely on the system or the app to dynamically promote frequently used apps to the primary position, if desired.

This move signals Microsoft’s preference to modernize menu registration through WinUI APIs rather than continuing to rely on fragile, in‑process COM shell extensions.

---

Why this matters: practical benefits for users and developers​

For everyday users​

• Less vertical clutter. Grouping related actions into a single split row reduces pointer travel and the time spent scanning long lists.
• Faster common tasks. A clear, single left‑click default speeds up the 90% use cases while still exposing lesser‑used options.
• Improved discoverability. Secondary options remain immediately accessible via the chevron, instead of buried multiple lines deep.

For developers​

• A modern contract. WinUI controls provide an official way to express primary vs secondary verbs, avoiding ad‑hoc shell registrations.
• Consistency across apps. When multiple apps adopt the same control semantics, menu behavior becomes predictable.
• Progressive rollout. Teams can ship split menus in their WinUI apps as they update, allowing an incremental adoption path.

For IT and admins​

• Easier auditing of menu surface. If vendors adopt the WinUI registration approach, admins get clearer control points for important verbs (as opposed to scattered COM extensions).
• Room for enterprise controls. Microsoft can layer Group Policy or MDM options to manage promoted actions, AI items, or cloud integrations.

---

Technical validation and current state​

• The demo was shown during a WinUI community call and has been documented in preview write‑ups, but the control and behavior currently exist in preview materials and the Windows App SDK preview channel — not yet as a guaranteed, system‑wide, stable change in File Explorer. Treat the control name and API shape as preview information; Microsoft may refine names, parameters, and behaviors before shipping.
• Microsoft’s MenuFlyout-based model (MenuFlyoutItem, MenuFlyoutSubItem, etc. is the established baseline for flyout menus in WinUI; the SplitMenuFlyoutItem extends that mental model to support split affordances that MenuFlyoutItem currently lacks. This is consistent with official Windows apps design guidance and the WinUI control gallery approach.
• Early demo slides claim meaningful reductions in menu height and duplication for certain file types. Those numbers come from demo material and are plausible in controlled scenarios, but real‑world gains will vary widely depending on installed third‑party shell extensions, user‑installed apps, and enterprise tooling. Treat prototype numbers as illustrative, not definitive.

---

Critical analysis — strengths, limitations, and risks​

Notable strengths​

• Targets the root cause rather than cosmetic rearrangement: by offering a programmable grouping mechanism, Microsoft shifts the surface from a flat append‑only list to a controlled taxonomy of primary/secondary actions. This addresses decades‑old architectural friction in the shell.
• Preserves discoverability while reducing noise. The split affordance keeps secondary commands available without forcing long vertical menus that are slow to scan and navigate.
• Developer‑centric rollout lowers risk. Delivering the control via WinUI/Windows App SDK preview lets app teams adopt the new pattern on their cadence, which should limit sudden breakage in enterprise environments.

Realistic limitations and risks​

• Legacy COM shell extensions remain the wild card. Countless third‑party installers use legacy shell extension points that are not managed via WinUI APIs. Unless Microsoft provides compatibility shims, migration tooling, or a central registry mapping, many legacy items will still appear in overflow menus or cause duplication. This could blunt the benefits of split menus for users with many legacy integrations.
• Developer adoption is uneven. The split menu will only clean File Explorer top‑level clutter to the extent that Microsoft and third‑party developers adopt the WinUI control model. Native and older apps that never update will continue to inject entries, preserving some clutter for years.
• Accessibility and keyboard navigation must be robust. Split controls introduce an additional interaction pattern — left = execute, right = open secondary flyout — that must be fully supported for keyboard navigation and screen readers. If accessibility semantics are not handled rigorously, power users who rely on keyboard workflows may lose efficiency or encounter confusing focus behavior. Early guidance urges keyboard and screen‑reader testing; this should be a red‑line requirement before broad rollout.
• Enterprise policy & telemetry concerns. If Windows automatically promotes apps based on usage telemetry, enterprises will want governance: which apps can be promoted, can cloud/Copilot items be hidden, and how are privacy and telemetry handled? Microsoft will need to provide group policy/MDM controls to meet enterprise security and compliance needs.
• Performance edge cases. The split pattern may reduce menu height but could add runtime complexity in enumerating promoted apps and assembling context‑aware flyouts. If these lookups run synchronously, they risk reintroducing the very lag complaints Microsoft sought to solve (for example, OneDrive context menu lag historically caused slow right‑clicks). Microsoft must ensure the control is performant and caches or defers expensive operations.

---

What remains unconfirmed (and cautionary notes)​

• No public shipping date. The WinUI call demonstrated the concept; Microsoft has not committed to a specific Windows Insider build or public release timetable. Expect this to appear first in preview/Insider channels and the Windows App SDK preview before a formal consumer roll‑out. Any timing quoted in early reports should be treated as provisional.
• API and control naming could change. "SplitMenuFlyoutItem" is the name seen in preview materials and community writeups; Microsoft has historically renamed and adjusted APIs between preview and GA. Developers should track official Windows App SDK release notes and GitHub repositories for authoritative API names and examples rather than relying solely on demo slides.
• Claims of specific percentage gains are context dependent. Early demo slides suggested significant menu height reductions (for example, “up to 38%” for some scenarios). Those are demonstrative figures from controlled examples and will not generalize to every configuration. Treat demonstration metrics as illustrative.

---

Practical guidance: what each audience should do now​

For everyday Windows 11 users​

• Treat future split menus as a usability improvement when your apps and system receive the change. No action is needed now.
• If you rely on the old full context menu, use Shift+Right‑click (or the registry fallback) to access the legacy menu; community guidance documents a registry trick that forces the classic menu if you prefer the old behavior. That approach works today but is a community workaround, not a Microsoft‑supported toggle.

For developers (WinUI/Windows App SDK projects)​

• Install the latest Windows App SDK preview packages and inspect WinUI’s control gallery.
• Prototype SplitMenuFlyoutItem in your app for relevant file‑type interactions.
• Prioritize keyboard and screen‑reader semantics: provide clear automation properties and focus targets for both primary and secondary areas.
• Consider telemetry responsibly: if your app participates in automatic promotion, ensure defaults respect user privacy and enterprise controls.

For enterprise IT and admins​

• Inventory mission‑critical shell extensions and third‑party tools that rely on context‑menu verbs.
• Test the new UI in pilot rings before broad deployment; watch for compatibility with legacy security tools and backup utilities.
• Watch Microsoft’s Group Policy and MDM announcements for controls around promoted verbs, AI items, and cloud integrations; demand vendor compatibility plans for critical enterprise agents.

---

UX and accessibility considerations Microsoft must address​

• Keyboard semantics: split items must be reachable and operable via keyboard alone (Tab/arrow key affordances; Enter or Space to activate left vs right actions).
• Screen reader labels: both the primary action and the chevron must expose clear, non‑ambiguous names and roles so users understand whether an item will execute or expand a nested list.
• High‑contrast and touch: the split control needs large enough touch targets and proper contrast states for accessibility.
• Migration story: for users and admins who rely on legacy verbs, Microsoft should publish migration guidance and compatibility shims to avoid losing essential functionality.

---

Broader context — will this finally end the “right‑click wars”?​

The Split Context Menu is a pragmatic and sensible evolution: it creates a clear API surface for grouping related commands while preserving discoverability. However, it is not a silver bullet. The long tail of legacy COM shell extensions, uneven developer adoption, and enterprise policy requirements means that clutter will likely reduce rather than disappear overnight. For users who have many third‑party context items, the overflow or legacy menu will remain an escape hatch for the foreseeable future.
That said, delivered carefully, this approach is one of the few structural changes that addresses the root architecture: it gives developers control of the menu surface and gives Microsoft a single place to apply modern policy, accessibility, and telemetry rules. If Microsoft complements the control with migration tools, robust accessibility support, and enterprise policy knobs, the split model could become a quiet but meaningful win for daily productivity.

---

Conclusion​

The WinUI Split Context Menu — exemplified by the preview SplitMenuFlyoutItem control — is a thoughtful and technically sound response to a persistent Windows UX problem. The demo shows how a hybrid left‑execute/right‑expand pattern can reduce menu height, eliminate repetition, and make the right‑click experience more contextual. That said, success depends on Microsoft’s execution: shipping a robust, accessible API, enabling developers to adopt it easily via the Windows App SDK, and offering compatibility and enterprise controls to manage legacy extensions and telemetry behavior. Until that full stack is in place, users should expect incremental improvements rather than an instant, universal cure.
Practical takeaways:

• Expect split menus first in WinUI apps and preview channels, not immediately across all of File Explorer.
• Developers should experiment now; admins should inventory shell‑extension dependencies.
• Users who prefer the old menu can still use Shift+Right‑click or community workarounds in the interim, but those are stopgaps rather than long‑term solutions.

Microsoft’s demonstration is promising — the platform finally has a clear technical pattern for taming context‑menu chaos — but the real test will be adoption, compatibility, and the company’s ability to translate a nice demo into a reliable, accessible, enterprise‑grade rollout.

---

Source: Moneycontrol https://www.moneycontrol.com/techno...ttered-right-click-menu-article-13660190.html

 

[ChatGPT]

Microsoft’s WinUI team has quietly offered a practical route to uncluttering one of Windows 11’s most persistent annoyances: the right‑click context menu in File Explorer and other shell surfaces. The proposal — shown in a recent WinUI Community Call demo and exposed to developers through Windows App SDK preview channels — introduces a split‑view context menu pattern (implemented as a WinUI control currently referenced as SplitMenuFlyoutItem) that keeps a single primary action one click away while tucking related commands behind a compact secondary flyout, dramatically reducing vertical menu bloat.

Background / Overview​

Since Windows 11’s launch, the right‑click (context) menu has repeatedly been criticized for becoming a sprawling, inconsistent surface. Items from built‑in commands, legacy COM shell extensions, third‑party installers, cloud services and recent AI/Copilot integrations have accumulated, producing long vertical lists that are slow to scan and, on some systems, noticeably laggy. Microsoft’s first Windows 11 redesign tried to curb the problem by compressing a compact top row and pushing legacy items into a “Show more options” overflow, but that merely masked the underlying structural issue: the OS historically allowed many independent parties to append menu items without a shared taxonomy.
The WinUI demo shows a different approach: treat each top‑level menu row as potentially two actions in one. The left half performs a primary/default action immediately; the right half opens a small, context‑aware flyout containing related secondary verbs and alternate apps. The interaction pattern is familiar (think split buttons in many toolkits) but applied to context menus to reduce vertical stacking while preserving discoverability. Microsoft is prototyping this as a WinUI control and making it available through Windows App SDK preview packages so developers can adopt the pattern inside WinUI 3 apps.

---

What Microsoft showed: the Split Context Menu, explained​

Interaction model — one row, two affordances​

The split menu row introduces two distinct hit targets:

• Left area: immediate execution of the primary action (e.g., “Open with Photos”).
• Right area (small chevron or split affordance): opens a compact, adjacent flyout with related commands and alternate apps (e.g., “Edit with Paint”, “Set as wallpaper”, other image editors).

This hybrid preserves the speed of single‑click workflows for the common case while making secondary choices discoverable without forcing the top‑level list to grow vertically. The concept was demonstrated publicly during a WinUI Community Call and captured in preview materials.

The WinUI control: SplitMenuFlyoutItem​

Preview materials and community coverage indicate the control is being shown as a WinUI 3 control — commonly referenced as SplitMenuFlyoutItem — that wraps a primary command and a nested collection of secondary items. Developers can declare the primary verb and populate the nested flyout; optional heuristics (local or system) can promote frequently used items into the primary slot over time. The control is being distributed via Windows App SDK preview/experimental channels, allowing app teams to prototype and adopt the pattern before any system‑wide shell integration.

Example: how an image file’s menu changes​

Before: multiple related entries such as “Open,” “Open with Photos,” “Edit with Photos,” “Edit with Paint,” “Set as desktop background,” each on its own line.
After (split pattern): a single top‑level “Open with Photos” row; clicking the left side opens the file in Photos; clicking the chevron reveals Paint, Snipping Tool, “Set as wallpaper,” and other related actions inside a compact flyout. The visible menu is shorter; commonly used tasks remain one click away.

---

Verified facts, provisional claims, and what to treat cautiously​

• Verified: Microsoft demonstrated the split context menu concept during a WinUI Community Call and preview material has circulated to developers via the Windows App SDK preview channel. Multiple independent outlets and developer write‑ups reported the demo and the developer‑first approach.
• Verified: The pattern is framed as a WinUI control (currently referred to in previews as SplitMenuFlyoutItem) designed for WinUI 3 apps and distributed through Windows App SDK preview/experimental packages for developers to test.
• Provisional / Unverified: Specific shipping labels and exact SDK iteration identifiers (for example, an explicit mention that this will appear in Windows App SDK 2.0 experimental release “exp3”) were not conclusively found in authoritative release notes at the time of reporting; treat precise release names or the stated milestone as provisional until Microsoft publishes definitive release notes or a changelog entry.
• Demo metrics: early preview slides and demo claims suggested meaningful reductions in menu height for representative file types (figures quoted in community material ranged up to roughly 30–38%), but those numbers are demonstration‑specific and should be treated as illustrative rather than guaranteed real‑world outcomes; actual gains depend heavily on what third‑party shell items are installed and how vendors migrate to WinUI.

---

Why this matters — benefits for users, developers and enterprises​

For everyday users​

• Cleaner, faster menus. Shorter top‑level lists reduce pointer travel, scanning time and the visual intimidation of a long list. The primary action is clear and immediate, meaning common tasks remain one click away.
• Reduced perceived lag. Fewer top‑level entries and fewer in‑process COM shell invocations can improve perceived snappiness, especially on systems where legacy shell extensions have slowed Explorer. The move toward WinUI/WinRT patterns can allow safer, async operations that don’t block the shell.

For developers​

• A modern API for menu intent. WinUI gives app teams direct control over which verb is primary and what belongs in the nested flyout, enabling consistent, testable, maintainable registration instead of brittle COM shell extensions. Developers can design domain‑specific groupings (image editors, compressed archive tools, IDEs) that make contextual sense to users.
• Safer integration. Moving functionality out of process or into safer WinRT constructs reduces the risk that a buggy third‑party extension will crash or hang File Explorer.

For IT and enterprises​

• Opportunity to standardize. If Microsoft provides Group Policy/MDM controls and migration tooling, enterprises can direct which verbs are promoted and whether cloud or AI actions are surfaced, ensuring predictable behavior for managed fleets.
• Migration planning. The developer‑first rollout gives organizations time to coordinate with vendors of critical shell extensions (backup agents, VCS clients, security tools) to map legacy verbs to the new model.

---

Risks, tradeoffs and concrete concerns​

• Discoverability and muscle memory
• Power users build finely tuned muscle memory for menu positions and ordering. Introducing a split target raises short‑term friction: users may accidentally trigger the primary action when they intended to open the flyout (or vice‑versa) until the pattern becomes familiar. Accessibility and clear focus/focus states need to be nailed to avoid confusion.
• Accessibility regressions
• Any new control must implement robust keyboard navigation, screen‑reader semantics, focus management and high‑contrast behavior. If the split target is not keyboard/narrator friendly, this change risks harming users who rely on assistive technologies. Microsoft and developers must publish explicit accessibility patterns and samples.
• Hybrid environment fragmentation
• Not all apps will migrate to WinUI simultaneously. A period of mixed menu behavior is likely: some apps will present clean split rows, others will continue to inject legacy verbs. The result could be a partially modernized but still inconsistent menu surface for months. This fragmentation will be most visible in enterprise environments with vendor tools that modify the context menu.
• Legacy tools getting relegated or hidden
• If migration tooling is weak, important third‑party verbs may be pushed into the overflow or disappear from the primary list, disrupting workflows that rely on quick top‑level access. Enterprises should inventory mission‑critical shell entries and coordinate vendor plans.
• Telemetry and privacy questions
• Promotion logic that auto‑promotes frequently used apps may rely on local telemetry. Enterprises and privacy‑conscious users will want to know whether promotion decisions are local only or if any data is sent to the cloud; policy controls should exist to opt out.
• Unclear timeline and naming conventions
• Some reports referenced Windows App SDK experimental releases and preview channels; however, exact SDK labels (for example an “exp3” identifier) and the timing for Explorer integration are not finalized in public release notes and should be treated as tentative until Microsoft publishes authoritative release documentation.

---

Migration, rollout expectations and what to watch​

Microsoft’s historical cadence for similar changes suggests the following sequence is most likely:

• Windows App SDK preview/experimental release(s) that include the control and WinUI Gallery samples for developers to test.
• Developer adoption and app updates for WinUI 3 apps that opt into SplitMenuFlyoutItem patterns.
• Inclusion in Windows Insider Preview builds (Dev/Beta channels) for hands‑on testing of shell integrations (e.g., File Explorer).
• Gradual staged rollout by Microsoft, potentially gated by server‑side feature flags or tied to a feature update — with enterprises receiving policy templates and ADMX updates to manage promoted verbs and cloud/AI actions.

At the time of reporting the split pattern is present in developer previews and WinUI demos but had not yet been confirmed in mainstream Insider builds; timelines may span months rather than weeks. Developers and IT teams should monitor the Windows App SDK preview channel and Insider releases for the first public SDK samples and shell demos.

---

Practical guidance: steps to prepare​

For end users​

• If a favorite context‑menu verb disappears from top level, use Show more options or the split’s secondary flyout to find it.
• Watch Insider channels and app updates if you want early access; otherwise expect the smoother experience to arrive gradually as apps and the shell adopt the pattern.

For developers​

• Install the latest Windows App SDK preview/experimental packages and inspect any WinUI Gallery samples for SplitMenuFlyoutItem.
• Prioritize keyboard and screen‑reader semantics in prototypes.
• Provide migration documentation mapping legacy COM verbs to the new split model.
• Test on representative hardware and with common third‑party shell extension environments.

For administrators and enterprise teams​

• Inventory mission‑critical shell extensions and coordinate vendor testing for compatibility with the new control.
• Pilot Insider/preview builds in a controlled ring and validate automation/scripts that rely on menu ordering; where necessary, use executables or scripts that do not depend on specific UI positions.
• Watch for Group Policy/MDM templates and ADMX updates tied to the Windows App SDK or Windows release that will allow administrators to control promotions and cloud/AI actions.

---

Cross‑checking and verification: what was checked and why​

Multiple independent reports and developer write‑ups independently described the demo and the WinUI control approach, which gives confidence that Microsoft is experimenting with split context menus and exposing a developer control in preview SDKs. The WinUI Community Call demo (early November community material) is the common primary source for these reports, and the Windows App SDK preview channel is the expected distribution path for experimental WinUI controls. Where claims diverged — for example, exact SDK release names (an “exp3” label) or a guarantee of immediate File Explorer replacement — those claims could not be conclusively verified in public release notes at the time of reporting and are flagged here as provisional.

---

Final analysis: promising direction, execution matters​

The split context menu shown in WinUI previews is a pragmatic, developer‑centric fix to a structural problem that Windows has accrued for decades. By giving app teams a modern control to express a single primary action plus a compact set of related tasks, Microsoft can reduce menu clutter, improve first‑click relevance, and reduce the shell’s exposure to fragile in‑process extensions — all of which should contribute to a snappier File Explorer experience for many users.
However, the change is not a magic bullet. Success depends on several non‑trivial execution items:

• Developer adoption. Apps must update their menu registrations to take advantage of the new control for the top‑level list to become consistently lean.
• Migration tooling. Microsoft should provide compatibility shims and mapping guides for common legacy COM verbs so that critical functionality is not effectively hidden from users.
• Accessibility & keyboard parity. The control must be fully keyboard and screen‑reader friendly out of the box to avoid regressing assistive workflows.
• Enterprise controls. Administrators will need policy surfaces to manage promotions, cloud/AI actions and privacy‑sensitive heuristics.
• Transparent rollout timeline. Clear release notes and SDK changelogs are essential to coordinate vendor testing and enterprise pilots.

Treat the WinUI split menu as a high‑value UX and platform improvement with real potential — but one whose practical impact will only be visible after careful rollout, robust developer guidance and enterprise readiness. For now, the community demo and SDK previews are a positive sign that Microsoft is addressing the root cause of menu bloat rather than simply cosmetically compressing the UI.

---

Microsoft’s approach gives users and organizations an explicit path to a cleaner, more contextual right‑click experience; the question now is whether the ecosystem — app developers, ISVs that ship shell extensions, and Microsoft itself — will coordinate to make that path smooth, visible and trustworthy.

---

Source: Windows Report Windows 11's Context Menus Are About to Get Less Cluttered