211–220 of 279 posts
I hate this trend. Give me back menus and toolbars. I avoid using VS Code for this reason.
But menus? Nobody would need them if command palettes would have some discoverable hierarchic structure to them. That's the last missing part to make command palettes "perfect".
The complexity of software has caught up with the GUI. Getting a generation of people to approach and use computers was great. But the GUI was never "intuitive" unless "intuitive" means that you can be trained to recognize a certain number of symbols. And that number is finite, when they're always changing. Here's how it struck me like a freight train: I was looking at some instructions for installing certain "driver…
Something I've been noticing lately is the disappearance of the “power user”. Someone who's not a programer, but has learned lots of smart and efficient ways to getting their computer work done over the years. Shortcuts (keyboard or otherwise), click-hold-cmd-tab-drop or similar patterns, tags/labels for deep file organization, etc. It seems like there's now a much wider gap between the smartphone tap-only user and…
I agree. I've been learning MS Word for many years at the level of creating my own templates and styles, using macros, assigning my own shortcut keys to building blocks, and using snippets in conjunction with AHK. My documents look exactly like Latex files with SVG images and nice look, but with __so much__ less trouble. Anyone who thinks Word is not capable of typesetting excellent documents has not given it a shot.…
Earlier quoted context omitted.
I can't speak to every field but in Architecture/Engineering the software became a lot less power user friendly with the switch from AutoCAD to Revit. AutoCAD had a command line. You could pick commands from the menu, or type them directly. You could make shortcuts for the commands. From there it was a short jump to stringing together several typed commands into a short script. There was a built-in scripting language…
Serious apps should come with event logs and command lines, period.
Something I've been noticing lately is the disappearance of the “power user”. Someone who's not a programer, but has learned lots of smart and efficient ways to getting their computer work done over the years. Shortcuts (keyboard or otherwise), click-hold-cmd-tab-drop or similar patterns, tags/labels for deep file organization, etc. It seems like there's now a much wider gap between the smartphone tap-only user and…
I'm not sure how related they are, but I noticed an inverse correlation with users have full access to their systems. As companies locked down systems, users had less opportunity to explore, learn, optimize (and also break or infect) their systems. Given solid UI design, the security tradeoff is probably worth it if the two are actually connected.
With power comes great responsibility; I'm confident it was a tradeoff, because for every one competent and savvy user, there were ten that would have to call IT every week with yet another virus or breakdown.
Something I've been noticing lately is the disappearance of the “power user”. Someone who's not a programer, but has learned lots of smart and efficient ways to getting their computer work done over the years. Shortcuts (keyboard or otherwise), click-hold-cmd-tab-drop or similar patterns, tags/labels for deep file organization, etc. It seems like there's now a much wider gap between the smartphone tap-only user and…
It's because general purpose PCs aren't as profitable as consoles. Companies want to make phones, tablets and computers into "app players" in order to extract maximum profits from app stores and subscription services. There is no room for power users in that market, only passive consumers. Besides, power users might be motivated to circumvent their systems and do things that companies can't extract rent on.
Because their old system didn't work. They were forced to always bolt on new features and redesigns, whether they added value or not. And there were plenty of people who never upgraded, because what they had worked just fine.
On Windows, you could press ALT to navigate the menu bar: each menu item would have a letter underlined to tell you how to select it, and when you picked a letter the menu would expand and each new item would have an underlined item etc. So you quickly discover and commit to muscle memory that ALT + F + S would select File then Save. This worked for dialog pop-up options as well so you didn't have to click. You can't…
Especially in Excel, using the keyboard to do everything is vastly superior in Windows. However in MacOS `command-shift-/` (⌘?) immediately shifts focuses to the help menu where you can begin typing to navigate directly to any command that appears in an application's menus, without needing to know where the command is hierarchically organized. It's very fast, and seems to work everywhere. I have Karabiner-Elements co…
It’s mentioned in the comments but is worth highlighting. Quicksilver was so far ahead of it’s time that I would say that Spotlight, Alfred, Mac’s Help search, and a whole boatload of Windows/Linux apps were a direct result of it. If you get an opportunity, run an early version coded by Merlin in an old version of OSX
Earlier quoted context omitted.
I feel like from a design and architecture point of view, building an application with the command line as a first class citizen will ensure that the application is well designed.
It ensures separation of concerns is at least minimally applied in order to support two separate presentation layers (GUI & CLI). CLIs are also much more testable in general, so usually it’s easier to write e2e tests if a CLI is present. It might not cover 100% of the code because it doesn’t test the GUI, but does often get you something substantial like 90% of the way there.
- you can test the rendering layer in isolation by using the GUI to display two pieces of information manipulated by the CLI and comparing the renders, eg blank screen -> add some object.
- you can comparison test the GUI, eg pressing button X produces the same result as CLI option Y.
Properly testing a GUI requires having an internal CLI, in places I’ve worked — eg, app companies.