Hidden interface controls that affect usability

There is a sweet spot in between those two extremes if you stop trying to build a compromise of a UI for both, touch screens and desktops. (sadly we still do not have the reality demoed by apple and google 10 years ago, where touch screens have hover detection, maybe XR gaze detection will bring this) You can pack extreme amounts of features without cluttering the interface or sacrificing discoverability by only showing most features on hovering certain areas. This is risk and effort free from user perspective, as users are much more explorative when no clicking is involved and it is clear an interaction will not trigger features by accident in the discovery process.

Im especially passionate about this because having ADHD makes one sensitive to irrelevant stimuli in the periphery but being a power user for most software the dumbification of software happening since mobile apps drives me insane. I want software where a feature being used by the top 5 to 10 % power users once a month is not being ripped out if that once a month use provides high value for that group.

On the risk of sounding like a grandpa, but there used to be a pretty effective "division of labor" for this in UIs:

(1) The "fast" path: Provide toolbars, keyboard shortcuts and context menus for quick access to the most important features. This path is for users who already have the "knowledge in the head" and just want to get there quickly, so speed takes priority over discoverability.

(2) The "main" path: Provide an exhaustive list of all features in the "title bar"/"top of the screen" menus and the settings dialogues. This path is mainly for users who don't have the "knowledge in the head" and need a consistent, predictable way to discover the application's features. But it's also a general-purpose way to provide "knowledge in the world" for anyone who needs it, which may also include power users. Therefore, for this path, discoverability and consistency is more important than speed.

Crucially, the "main" features are a superset of the "quick" features. This means, every "quick-access" feature actually has at least two different ways to activate it, either through 1 or through 2.

This sounds redundant, but makes perfect sense if it allows peoples to first use the feature through 2 and then later switch to 1 when they are more confident.

My impression is that increasingly, UIs drop 2 and only provide 1, changing the "fast" into the "main" path. Then suddenly "discoverability" becomes a factor of its own that needs to be implemented separately for each feature - and in the eyes of designers seems to become an unliked todo-list bullet point like "accessibility".

Usually then, it's implemented as an afterthought: Either through random one-time "new feature" popups (if it popped up at an inappropriate time and you just closed it to continue with what you wanted to to, or if you want to reopen it later - well, sucks to be you) - or through unordered "everything" menus that just contain a dump of all features in an unordered list, but are themselves hidden behind some obscure shortcut or invisible button.

> if you stop trying to build a compromise of a UI for both, touch screens and desktops

Agree many of the problems have to do with this, yet it’s barely mentioned by armchair designers. Temporally hidden and narrow scrollbars? Makes perfect sense for scrolling on touch screen (since you don’t touch them directly), but very annoying on desktop.

Back in the pre-touch days we’d have a lot of hover menus. But with a phone today? Nobody likes the hamburger/three dots, but there isn’t a better alternative without losing context. And nobody uses hover anymore for functional purposes.

But, I also don’t think building entirely separate apps and especially web sites for different form factors is desirable. We probably should be better at responsive design, and develop better tooling and guidelines.

I think this "fast" and "main" path is good (I shouldn't usually need toolbars since they may take up space, but keyboard commands are good), but it is not a substitute for good documentation.