Rebuilding the shortcut framework

01

Overview

CargoWise's legacy WinForms application had grown keyboard shortcuts over three decades. Expert users relied on them constantly, but there was no single place that listed them, no consistent logic behind how they'd been assigned, and no plan for how any of it should carry over to the web.

I led the research and strategy work to define what a keyboard shortcut system should look like on Glow, CargoWise's web platform. That meant auditing what already existed in WinForms, understanding where those patterns broke down in a browser, and building a framework flexible enough for other teams to apply to their own workflows.

The project didn't end with a single shipped feature. It ended with a documented framework and a redesigned way to discover shortcuts in the product. Another team was already using it to solve their own shortcut problem before the project wrapped.

02

Context

Keyboard shortcuts matter more in enterprise software than almost anywhere else. CargoWise is used constantly by logistics operators processing hundreds of records in a shift, and shaving a second off a repeated action adds up fast across a team.

The WinForms application had decades of shortcuts baked in, some documented, most not. Glow had none. Users moving between the two environments expected some level of consistency, but a browser reserves a large number of key combinations for its own use, and there was no existing precedent for how to handle that conflict at this scale.

03

Understanding what already existed

There was no published list of WinForms shortcuts. Searching didn't help much either. AI tools could surface fragments but nothing close to complete, because the shortcuts lived in a contextual help panel that only ever showed what was relevant to the screen you were on.

I started with a shortlist of around sixteen high value shortcuts, built from a mix of internal knowledge and AI assisted research, aimed at getting something useful into Glow quickly. To properly understand the full scope though, I worked with a developer to query the WinForms codebase directly. That surfaced 111 distinct shortcuts across the application, giving me a real picture of what expert users had been relying on for years.

04

Where the desktop model broke down

I shared the initial shortlist for feedback and it landed well, but it also surfaced a problem. Several of the shortcuts collided with combinations the browser already reserved for itself, things like save, find, and closing a tab.

The fix seemed obvious at first. Wrap everything in a consistent modifier key so the whole system moved out of the browser's way at once. Applying that consistently created a second problem though. Shortcuts that had never conflicted with each other in WinForms started colliding once the same modifier sat in front of both of them. One close action and one unrelated lookup action ended up wanting the same combination.

That forced a bigger question. Was the goal to replicate thirty years of WinForms shortcuts as faithfully as possible, or to use the move to the web as a reason to reconsider which of them still earned their place.

05

Weighing the options

I mapped out four realistic strategies rather than pushing straight for one answer. Each had a real cost, and none of them made the others irrelevant.

• Maximum legacy support: keep WinForms shortcuts unchanged wherever possible. Minimises relearning, but a meaningful chunk of shortcuts can't be reproduced in a browser at all.
• Universal modifier: apply one consistent modifier across every shortcut. Solves most browser conflicts in one move, but introduces new collisions between shortcuts that never used to clash.
• Start from scratch: design a shortcut system native to the web, unconstrained by WinForms' history. Clean, but means expert users have to learn two systems if they still touch both environments.
• Dual shortcuts: support the legacy shortcut and a modern equivalent side by side, similar to how some productivity tools handle the same problem. Maximises flexibility, but stacks the conflict issues of the first two approaches on top of each other.

06

Landing on an approach

I recommended the universal modifier as the primary direction, keeping the original key from the WinForms shortcut and asking users to add one consistent modifier on top. It gave the biggest reduction in browser conflicts for the smallest amount of relearning.

Getting it right meant going past the browser and thinking about the keyboard itself. On many international keyboard layouts, the modifier I'd chosen is the same combination the operating system uses to type accented characters, so I specified detection for that and a fallback modifier for those layouts. Screen reader software uses a similar modifier for its own navigation, so I specified a separate accessibility preset that switches automatically when a screen reader is detected. The spec also keeps shortcuts switched off while someone is typing in a text field, so the system doesn't fight with what a person is trying to write.

Alongside the strategy, I redesigned how people discover shortcuts in the product. WinForms only ever showed you what was relevant to the exact field you had focus in.

I designed a single, searchable reference that lists every shortcut across the application, grouped and filterable, with a toggle to preview the modifier on or off and clear flags on anything that still conflicts with the browser.

07

Outcome

By the time I moved on, the initiative had produced more than a set of recommendations.

• Audited and catalogued 111 WinForms shortcuts with no prior documentation
• Defined a modifier-based shortcut framework for Glow with a documented accessibility and internationalisation fallback
• Designed and prototyped a redesigned shortcut reference panel
• Another CargoWise product team adopted the framework directly to resolve their own shortcut needs, working through it with me over several rounds of feedback
• That team's real usage pressure tested the framework and refined it. High-value shortcuts people already knew by heart, like save, were kept unmodified rather than wrapped in the new modifier, while less universal ones followed the new system

08

Reflection

Not every research project ends with a single, clean answer, and I think this one is better for it. Handing over a rigid one-size-fits-all rule would have looked cleaner in a deck, but it would have broken the first time a team ran into a shortcut too important to touch.

What made this project work was building something flexible enough to survive contact with a real team's real constraints, then watching them do exactly that. They kept what already worked, adopted what didn't exist yet, and pushed back where the framework didn't fit their workflow. That's a better outcome than a rule everyone follows without thinking about it.