[toss1]

I'm not a UI/UX designer, and am equally frustrated by the failures described in the article and other comments.

One item I can bring to the table from the world of designing cockpits for racecars and airplanes is that the primary principle to follow is:

Reduce Driver/Pilot Workload.

Does whatever you are doing around the workspace increase or decrease the work that the driver or pilot must do? Can the status of [thing] be discovered (read/heard/felt) with minimum time and effort? Does [thing] create an otherwise unnecessary need to take even a quick glance at something? Is something in the way of taking an action, requiring an extra motion?

Of course, there are some things that maybe it IS desirable to add an extra bit of work, e.g., a switch that kills critical [thing] maybe should have a cover over it requiring to flip up the cover then hit the switch; an extra moment of thought.

This one principle translates well to software interfaces. Screw whether it "looks clean" or not — does it reduce or increase the user's workload? Even a tiny change can make a huge difference, because many actions are repeated.

I hope this helps

[grishka]

Also, frequently needed actions should be doable mindlessly. With hotkeys, for example. The example from the world of physical UIs would be that one Tesla car that does everything — including shifting gears and adjusting AC — through a huge touchscreen. You need to actually take your eyes off the road and dashboard to operate it because you can't do it without receiving visual feedback. If it had a physical lever for gears and knobs for the AC, you would've been able to control these things using just your muscle memory.

[toss1]

A few key items to consider in reducing workload:

Reduce the thinking load

Implement things that actually reduce the need for the driver/pilot/user to think, allowing just trained reactions.

Be careful with this sort of "automation" — it has to be absolutely reliable, i.e., the unthinking response needs to be correct every time, and the feature does not lead the driver/pilot/user into errors — the occassional errors will force the driver/pilot/user to think MORE, e.g., "wait, will this lead me to an error this time?!?", making everything actually slower. OTOH, if you can truly reliably automatically manage some part of the driver/pilot/user workload, that frees up mental space for every other part of the workload.

Speed Is Life

The interface MUST be faster than the fastest driver/pilot/user. ANY perceptual delay causes multiples of that delay in the response input from the driver/pilot/user, or creates a bad feedback loop (start correcting, response data is delayed, leading to overcorrection, then bigger input the other direction, which data is also delayed, bigger over-reverse correction... crash). In software UI/UX, there may bot be a risk of physical crash, but the effects of microscopic delay are actually insanely corrosive on productivity, think 1-2 orders of magnitude.

[ProxCoques]

> the primary principle to follow

Yes. I spend a lot of effort with people at all levels trying to get them to agree on what, fundamentally, the system should achieve for the user. Sometimes it's speed, sometimes entertainment, trust or some other outcome. But that principle needs to be expressed and agreed by those executing the design, if only to prioritise features. I'm always astonished that they seldom want to talk about that, as if it's mindlessly theoretical or something.

> a switch that kills critical [thing] maybe should have a cover over it requiring to flip up the cover then hit the switch; an extra moment of thought.

As an aside, in the digital world a better pattern is usually to have an undo (probably executed as a delayed trigger allowing you to undo it for a time). This allows you to be confident in using the system in the knowledge that if you do something you don't intend, you can just take it back. Not a thing for cars or planes though, I admit.

[interestica]

> I'm not a UI/UX designer,

> One item I can bring to the table from the world of designing cockpits for racecars and airplanes

Sounds like you are most definitely a UI/UX designer. Those are interfaces. Those are experiences.

[rerdavies]

I wish somebody would take that approach with Visual Studio Code, which is -- I think -- a particularly egregious offender. I would dearly love it somebody would take a 21st-century approach to time-and-motion studies for programming in Visual Studio code. I think Visual Studio actual did something along the lines of time-and-motion studies at some point in its long history. But I'm increasingly thinking that Visual Studio Code is having a a 3 or 4x impact on my productivity.

Things seem to start out well with blank projects; but eventually, somewhere around the mid-scale 30k+ line point, all the advantages of all those incredibly great features in VS Code seem to be offset by scaling issues.

There was a point recently at which I seriously thought I was losing my programming edge. But a recent adventure with a non-VSCode project, and a recent discovery with respect to the VSCode debugger is making me wonder whether it's my tools that have lost their edge.

There are a bunch of things going on in that user interface of Visual Studio code that are completely tanking my productivity.

A telling example: When using the Visual Studio Code GDB debugger, Visual Studio code fetches the local variables of ALL stack frames on ALL threads every time you single-step. This happens even when the thread views are collapsed. As a consequence, it takes between 10 and 30 seconds (depending on how thread-heavy your app is) to single step once. I was pushed over the edge when I dropped into a new project and Visual Studio Code was take three minutes to single-step. (Not a memory issue, not a disk issue, not an inadequate machine issue).

So I did some research. This has been an issue since 2016 in Visual Studio code! The solution (according to message posted in 2016 somewhere on the internet): switch to the CodeLLDB debugger extension.

The result: on the 3-minute code base, single steps take distinctly less than a third of second.

It's like the frog in a boiling pot of water: you don't realize the toxic effect that kind of latency has on your your debugging productivity until it instantly goes away. 3-minute single-stepping is obviously impossible to work with; but the cumulative effect of taking 10 seconds to single step is definitely large. I can debug things orders of magnitude faster than I could before. I don't lose my train of thought. I can set breakpoints fearlessly, and single-step through dozens of lines of code -- all things I couldn't do with the default Visual Studio debugger.

The only peculiar side-effect of CodeLLDB: the debugger expression evaluators use RUST expression syntax even for c++ code. Which isn't actually terrible. It's just very strange.

But there are other things as well: the latency on Intellisense updates, where you have to wait 10 or 20 or 30 seconds for the error squigglies to update. Every edit becomes: type a few characters, wait for 30 seconds to see if Intellisense likes its, type a few characters.... And WHATEVER you do, don't unbalance parens or curlies, which will pin all available CPUS for minutes at a time! (Huge recent productivity improvement -- set the number of Intellisense threads to number of CPUs minus 1!).

In the old days, on much less capable hardware, a compile would fail in 3 or 4 seconds; so you could just "type a few characters; press F7, wait 4(!) seconds, and see if the squiggly went away. Although typically, you would fix a few things, wait 4(!) seconds and see if the squigglies went away. (More-or-less instantaneous checks were run in the editor to check for paren/brace balancing).

Instead, VSCode accumulates rats nests of red squigglies that wont go away until background intellisense completes (which could be 90 seconds or more), or until a compile completes, which runs the constant risk of facing a list of "12,000+"(!) errors in the error window, because you have an unbalanced paren or brace, which can take 10 or 15 minutes to straighten out. And the three or four G++ errors that are legitimate get buried in thousands of Intellisense errors that wont go away (that's a recent regression; you used to be able to temporarily filter out Intellisense errors).

I'm increasingly thinking that Intellisense for C++ is dramatically tanking my productivity as well! I mean it does actually work on toolable languages, like C#+Visual Studio, or Java+Android Studio, where the tooling update time is sub-10-seconds. But for C++ it seems to be a disaster. (Wondering whether it actually does work, though).

Build turnaround: there is NO obvious point in the Visual Studio UI to indicate that a build has completed. A tiny status message buried in the status bar. For some reason, my build output window always seems to come unglued from auto-scroll. And VSCode auto-tabs away from the Errors Window to the Build Window without un-de-autoscrolling. So you hit the F7 key, your eyes glaze over while a toxicly overlong build runs for a minute past the point where the error occurred, and you snap to 3 minutes later realizing that the build finished with errors, ages ago.

Mouse-keyboard context changes. Switching your left hand from mouse to keyboard and back is an expensive operation relatively speaking. By my best estimate, I spend about 40% of my editing time switching between mouse and cursor keys. Whereas... on Visual Studio, major editing operations can be performed entirely from the keyboard. (ctrl+space, cursor cursor, carriage-return is burned into my muscle memory for some reason, even though it's been years since I used Visual Studio -- or is that Android Studio?). There's something seriously wrong there too in the arrangement of short-cut keys, mouse and cursor movements.

Ctrl+Left/Right Arrow! There's a simple thing that is bizarely broken, that has a dramatic effect on my productivity. It does something seriously wrong, I'm not sure what, but it's not productive! It consistently takes you to the wrong edge of identifiers and operators, so you end up pounding on unmodified left or right arrow to get to the right place. I'm DEAD certain Visual Studio does it differently; and it's not a problem I've noticed at all in Android Studio.

I'm convinced that a little time spent on time and motion studies could increase the productivity of average developers by dramatically large amounts. Something in the order of 2 or 3- or 4-times more productive. Most especially for Visual Studio Code, which -- for reasons I still don't completely understand -- seems to be extra-double-plus toxic for productivity.