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 the Vim/Terminal ubergeek with almost nothing in between.
I remember being floored by bureau in the 90s that completely automated their Photoshop and QuarkXPress workflow with AppleScript just by hitting the record button (not a single line of code written), folder actions, smart file placement and similar tricks.
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 (AutoLisp, a lisp dialect). The command line was also a repl, so you could type snippets of code and execute them on your drawing and see the effects immediately, making it easy to experiment.
Revit has none of this. Everything is menu driven. There is a macro system, but you have to go hunting for it. There's also a way to build add-ons and extensions by downloading an SDK and learning C++ or C#, but that's not really the same as making a quick script to automate some repetitive task. There's no command line. Even the newer versions of AutoCAD hide the command line in the default configuration. If you don't know to go looking for it, you'll never find it.
I used to know an AutoCAD pro and watching him work was magic. He hardly ever touched the mouse and could type house plans about as fast as I could follow along. It seemed that a great knowledge of the commands combined with some mental math and an uncanny memory for multiples of 12 and 16 worked wonders.
Houses built with wood will place the wood at regular intervals. Walls are usually built with the boards at 16 inch intervals while floors are usually 12 inches and roofs may be 12 inch or 24 depending on loading conditions.
In order to be able to type a house you need to know the multiples of 12 and 16 up to about 30 or 50 x 12.
My grandpa was an engineer who used AutoLISP a lot to automate away a ton of work they were having to do back in the 80s and early 90s, his coworkers loved him because he got menial things done easier for everyone. I could only imagine tasks like what they were doing involving complex fluid mechanics to be something you'd have to have a programming environment to get at.
Correction:
Event logs should be transaction logs instead and you must be able to travel through it reverting and re-applying actions. It should be branch-able and allow you to jump between those branches.
For small values of easy: vim. (It is really easy to do I think, doing it correctly instead of just being clumsy and hitting some key that starts it, that is the challenge ;-)
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.
It depends on the application, but CLIs can make testing GUIs easier in two ways:
- 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.
Have you ever run `rm -f important_doc.txt` instead of intended `rm -f important_doc copy.txt`?
It doesn't matter if it is GUI or terminal interface, software must be _humane_, forgive mistakes and provide a way out. As much as love Unix coreutils and have them in may fingertips, those are the least humane programs I have ever used.
Surprisingly, git seems quite humane, even when you screw things up it gives you a lot of safety mechanisms to recover.
> Surprisingly, git seems quite humane, even when you screw things up it gives you a lot of safety mechanisms to recover.
You have to earn it. I admit that when I started using git sometimes I made a copy of the repo just in case I ended in a state that made it easier to nuke it and start again
The point of taking a copy of the repo is that you don't have to use git itself to get back to a known state, which is important when it's a tool that you're experimenting with and you're not sure on its use.
There's also a psychological element to it. If you can verify for yourself that the repo can't possibly contain anything that would mess you up after an earlier mistake, it's much easier to do things than if you have to worry about using the wrong branch name when you don't know how to delete branches, for example.
I totally agree, as long as that interface gives users knowledge as to how it forgives the user.
I use a Mac for work, and one of the first things I did was to alias `rm` to the utility `trash`[0] -- instead of immediately marking the bytes as free like `rm` does, it'll move the file(s) to the system's trash can.
Yeah, user facing filesystems should be change-based, and require elevated permissions to permanently delete data.
The problem is that filesystems don't get enough love. There are plenty of more fundamental problems that aren't going anywhere, so do not expect this to change.
I'd take a bit less of an absolutist standpoint myself, but, designing your application so that it has this event log (Command design pattern from back when, but I'm sure it has a more modern name nowadays) and its functionality is separated from its user interface are best practices.
Is it just possible that the workflow of a power user has changed now while still retaining the core value of finding smart and efficient ways to get work done? Some examples that come to mind:
The productivity industry is huge. Pop into the YouTube rabbit hole of people demonstrating how to use tools to be more productive, and you’ll stumble into a community that is bending every tool to basically serve their personal approach to life. The effectiveness of that is debatable but these are people who are absolutely pushing apps to their edge. A lot of them are mobile tap-only people too. But they also satisfy the condition of learning lots of smart and efficient ways of using their tools.
Content creators. Especially younger ones. I’m floored by the kinds of videos younger people, aged 16-23, are making by pushing the limits of their mobile devices to create engaging content. And I’m not even talking about the ones who make use of multiple tools across both laptops and smart phones. I’m just thinking of the people who will combine a few apps with the native functionality of something like TikTok and they create high effort content that is representative of someone who has taken the time to learn smart and efficient ways to get their work done. Again, the value of the output can be debated all day. But I think it’s obvious how far people are pushing their tool sets.
There are probably other groups I don’t know of because of my bubble, but I do think the above groups show that power users are alive and well even if they look different than they did in the past.
I respectfully don't consider the creators you described as "power users" in Parent's sense. What they do are mostly "productivity porn", i.e., fiddling with tools in a vacuum, without real professional contexts, and severing flaunting, sensual purposes. It's writing scripts for automating errands that I consider power user's workflow; decorating zettelkasten "gardens" filled with teaching from yet another productivity guru -- not so much.
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.
I think there's a strong correlation. We did gain a lot in security and simplicity with the App Store model. Lots of people that would never install apps on Windows or Macs, due to fear and ignorance, do so regularly on their smartphones. Moreover, they upgrade their OSs and pay with credit cards, etc.
On the other hand, those same people had folders on their desktops and managed files reasonably well. And now that even got a bit more confusing on the desktop, especially with MS/Apple insistence in selecting One/iCloud drive by default.
I don’t want to assume ages, so: there was a time way before the app store where installing an app on a mac was as easy as clicking download and extracting the “file” (it was actually a folder, just like current mac apps). Trying it out only needed a double-clicking on the resulting icon.
No install script, no pkg files, no hidden prefs, nothing.
Want to uninstall it? Drag it to trash.
It was only when Apple started to be affected by mac piracy that they started down the road of restricting everything and when they started making real money selling their own content on their own platform (music then movies through iTunes) they hit the friggin gas.
That’s still how I install 95% of Mac apps? (.dmg) I don’t think the Mac App Store is even that popular. Rarely is an app exclusively there, though times might be changing. About 5% of things come as .pkg installers but usually in a situation where it makes sense.
Default macOS will still check for Apple’s seal of approval on software, but this is done by developers signing their distributed app.
There's lots of software that is only distributed in the App Store, which can't be used without an Apple ID (even for free apps), which requires giving Apple a phone number and email address (and the App Store app uploading your unchangeable device hardware serial number).
Some apps, like Wireguard, can't even be installed outside of the App Store, because Apple won't sign the entitlements they need to run outside of it.
It’s like shipping entry level jobs to other countries: People lose the ability to learn and grow on the job. They lose the ability to work their way up. Instead you have to rely on an establishment that is hands-off.
> As companies locked down systems, users had less opportunity to explore, learn, optimize (and also break or infect) their systems.
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.
Generally agreed. Especially with ransomware these days I can only imagine how bad it would be if users had admin by default. I think the only reason we don't frequently see that attack vector now on home computers is because they aren't lucrative targets. If many/most corporate PC's were an effective vector into the rest of the systems because they had admin, it would truly be a nightmare. In the past when admin was common viruses were either just to cause a bit of chaos or exfiltrate data. Both bad, but now their is a direct financial incentive to shutdown the entire company.
That said, where I work there is a special path to admin if you have an actual need for it. It requires a security training course and special approval from a supervisor and the whoever leads technology in your division. And also signing a disclaimer that you now take full responsibility for any & all things that might possibly go wrong with your system due to use of admin privileges and all the consequences that entails, including "disciplinary actions" (screw up bad and you'll get fired). Makes one a bit more paranoid about security, which is healthy. I just wish the training & approval process included the education & tools needed to spin up your own VM's. It's not hard and the tools are free and (for anyone who really needs admin) relatively user friendly.
Otherwise things are very locked down. IT would much rather have you reboot than grant access to taskmanager to kill your own user processes.
It's also because while the number of programmers and basic users (smartphone tappers) have increased, the number of power users has not. People who would have been power users are pushed into programming due to demand.
power user as an intermediate state. Do they represent a lower activation energy or a hard-to-prevent adduct that occasionally gets all the way across?
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.
Which is one reason why they've switched to subscription systems to PC applications as well - Adobe's suite comes to mind, Office365, and probably Autocad and co as well?
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.
I'm an academic, on the humanities/social sciences side of things, and I have the impression that a fair proportion of my colleagues are power users as you define it. They don’t do programming per se, but they customize their software, write macros for their own use, and may occasionally venture into the command line. I fall into that category myself. I don’t know any who are smartphone tap-only users.
My colleagues in the sciences are, not surprisingly, even more computer savvy, though I don't know how many do actual programming.
Five years ago, there was a literature professor in my department who didn't even use a computer and had to be contacted by telephone, fax, or—gasp—a handwritten note slipped under his office door, but he has since retired.
> Are "power users" disappearing, or are they just being ignored?
I believe they are mostly ignored.
A power user is a user, who doesn't fear the technical outcall. (S)he wants to get work done and uses a computer as a serious, professional tool. Sooner or later this will require this kind of user to step into configuration, the command line, etc. These users will accumulate IT knowledge auto-didactically, by visiting forums, mailing-lists, etc.
However, they come from many different positions and professions. And as such, they are a moving target of many, often highly specialized, communities. Not the typical customer base a large corporation wants. The large corporation will delegate such communities to "consultants", which those communities either can, or can not afford. I am not an archaeologist, but I could imagine, that archaeologists may benefit from tablets, that can do photos on-site and a document format, that let's them keep track of their excavations, link those to relevant data, etc. Photos like this [1] clearly show a pattern, that relies on coordinates. However, I guess, they are notoriously underfunded and nobody cares anyway.
> Software (and online services) has been in a race to the bottom for over a decade.
I wholeheartedly agree.
I remember the times of ActiveScripting on Windows. It was a great (and much needed) idea, that, however, has been positioned at system admins only (the most typical power user in a Windows environment, typically just some secretary or coworker, who is ready to do it, than a full position) and thus never really took off. Same for XML. Just because software-engineers don't like the format, it must not mean, that there is not some people being "document-engineers". Not everybody, who wants to use a computer programmatically, works at a Web/Cloud startup, etc.
In my experience, it's not so much that the power user has disappeared, but their power user "surface" has been squeezed. I work in an environment where I see journalists using clunky Windows-based CMSs with 30 years+ of baggage that I assumed would be killing productivity through their awkwardness.
They might all hate the tool, but are able to navigate between entering and editing copy, editing layouts and running orders, searching wires then adapting it into stories etc. with great speed with shortcuts, saved workflows and yes, awkward cludges like always-open text files of boolean searches they frequently re-use.
The minute they need to leave their tool to do a peripheral task though, all of those gains are lost. The new web-based video subtitling tool might be better than their old workflow and something they use several times a week but there's an instant assumption that it's a mouse-only task, even if the tool is a11y-aware enough to not be. Lots of "oh is it ready? Ok now I...think I click this bit" because things like communicating status and progress aren't consistent or ubiquitous. It just doesn't have the efficiencies of their ugly old thing.
On the one hand they could learn how they could automate their browser to actually integrate these tools with their workflows better, but nothing about the browser environment seems to give the impression to this class of user that it can be used in this way.
I don't know if that's just about tools that each have their own look and feel, or that the browser metaphor is too overloaded (because that feels like a very 2003-era concern :p)
At work (generally, inclusive of but not only my company) you’ll find power users in Solutions Engineering implementing and automating nuts and bolts integrations and performing data wrangling on BI teams. There’s a lot of work to be done by people who don’t really code, and if they do it’s light scripting. They take a huge load off of the Engineering staff. I’ve also seen power users make their way into UI Automation.
It seems like once they get a few years under their belt they move into Product or Project Management or gain sufficient scripting experience that they move into an entry level Software role.
From my experience, apps are not developed anymore with power user in mind.
There use to be a terminal app (DOS) at a company I worked at which only worked with shortcuts, the learning curve was pretty steep but after a while using it you could be pretty efficient.
Now they replaced it with a nice UI but you don't have shortcuts. Maybe there wasn't enough demand for it.
In programming we mostly use tools we also use at home or elsewhere, so the learning cost is worth it (if I learn VIM, I will be more efficient at every programming job in the future, not just this one)
I have worked with many power-users in allegedly "non-technical" roles.
I don't think that they are disappearing; life will find a way. Although, I do think that the median software is becoming harder to automate or stitch together (at least for someone without existing scripting knowledge). Tools that do have APIs don't offer a nice, smooth gradient from beginner to "power-user" that anyone could find themself pulled up.
An exception to this is Excel, which I believe exposes this "gradient" rather well.
I don't know if they've disappeared -- maybe the numbers are diminished, but they still exist.
Take something like Tableau for instance. If you visit the Tableau forums, there's some really creative people who are constantly coming up with solutions for dashboard problems, anything from rewriting a SQL query to workarounds with Excel, just to get a dashboard to display the right way. Some of these solutions involve a deep understanding of how to manipulate data (windowing functions, pivots, date arithmetic etc.).
And at most big companies, you'll find Excel wizards who do wonderful (but cryptic) things with VBA macros. You'll find full mathematical models embedded as Excel VBA macros. Maintainability aside, you can do some pretty mind-bending things with VBA.
There are also the AutoHotkey users who automate GUI tasks by recording mouse/keystrokes and then tweaking them. We had more than a few of those in my last company (bigcorp).
If you look outside of the consumer macOS ecosystem, you'll find that power users are alive and well.
> If you look outside of the consumer macOS ecosystem, you'll find that power users are alive and well.
Interesting you say that in a comment thread about an article that mentions several times how macOS and a couple bits of software designed for it helped popularise the command palette (which is a power user-friendly tool). Apple’s OSes have always have advanced features for power users, from the Apple Script of all to Automator and Shortcuts, and all the places where Spotlight is used. MacOS is for noobs is quite far from the truth. Sure, it can be used by noobs, but it does not mean it is restricted to them.
I agree with all your points. I think your last point about macOS not just being for noobs is true. I don’t think I implied anything in my comment contrary to it.
I do think that despite macOS having these power user tools, their uptake in modern times seems more limited compared to the olden times (System 7-9) and when compared to other platforms. I know I was excited when Automator came out in OS X Tiger but I don’t know anyone who’s really used it outside of folks who publish their workflows.
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.
If MS would add something like VS Code's command palette to Word, it would blow Latex outta the water. I've tried Latex (in VS Code) and I was able to write my own snippets using Regex and "prettify" the code. I miss those things in Word.
Plus, Word must have something like settings.json where I can see the list of all custom shortcuts that I've set. And I also wish Word Find would use the typical Regex to find things in text.
I never thought one day I like Word, but this software has been a life saver (can't say that so much about PowerPoint and the rest of the office suite though).
The problem with word is that it doesn't guide the user to use it well, and few users are trained properly. I wish there was some kind of strict mode where only styles can be used (and maybe even locked), and nobody could tweak formatting manually all over the place. Templates also aren't widely used well, so most company documents end up containing all kids of styles and formatting built up from years of copy-pasting. I've encountered many documents where some of the heading styles or even "normal" is gone.
Powerpoint is often abused but it works well, and if you learn the shortcut keys for moving objects around it's actually very capable for making sketches and diagrams. Much easier to make a poster in powerpoint than word, actually because each slide is strictly one page and you don't have to fight margins.
Yeah I make many diagrams and graphs using PowerPoint and often people think it's made by some professional illustration software. And I use PowerPoint for my presentations too. Still, I wish it were possible to have some features of Beamer in PP. Also, it's a shame that drawing a simple x-axis with ticks on it is still very time consuming on PP.
Word is not my cup of tea, but I've seen people doing CD covers, with multiple folding, the art on the back of box, on the CD itself, all in Word. They exported a PDF, sent to the printer and it worked. I've learned to respect this beast, thankfully, from a safe distance.
Microsoft Word is powerful enough to do anything you want it to… so long as it stays on one computer, and you don't reconfigure your fonts, or your monitor, or change Word version. Hence the PDF export, I presume.
I remember as a young IT technician, getting chewed out by a CEO because his assistant sent a PowerPoint at the very last minute that used a font only she had on her computer, and it was played at a quarterly meeting and looked odd.
That sounds like a lot more trouble. And then again, you could build the same templates, styles, and macros over Latex for even more performance. Not to mention that Latex files are just text files, so you can apply any sort of text processing to them.
There is the Shortcuts app for iOS and macOS now that replaces the old Automator app and provides a friendly GUI for some basic to more advanced automation and allows for AppleScript for more complex requirements. I don't know really how widespread its use is, but there are some passionate communities of people making and sharing shortcuts that does seem to extend beyond the "terminal ubergeeks" into more typical (albeit efficiency obsessed) consumers.
Not many people seem to use it, but it sure is handy. I use it to convert or resize images when sending to people all the time. Any app that uses the native "share" screen can use these macros.
Software engineering is better understood and commoditized. The dangers of poor no-code solutions is also now well recognized. If you have the budget for an in-house IT team, then having custom glue software is perfectly viable. Or you can pay for Airtable/Zapier or RPA tools. Ad-hoc solutions provided by the OS to automate desktop software just doesn't make sense in a world dominated by cloud services with APIs readily available and cross-platform desktop GUIs that don't follow platform conventions. For niche software like CAD and EDA, vendor lock-in and deplatforming certainly should be bigger concerns for users but there simply are not enough suppliers. It is difficult for small players to break the inertia of vendors that predate the modern internet and who had established customer relationships before the SaaS model was even a glimmer in
the Salesforce founder's eye.
I'd agree with this, over the years it's felt like the answer to giving more power or customisation has gone backwards to "we have an API" and "you need to learn a python / whatever language for this".
I would say that we're continuing to move away from interfacing with computers as humans (with near natural language scripting, power TUI/UIs etc...) - to interfacing with computer as computers (writing code, digesting APIs etc....).
I'm not saying it's a bad thing - but it's certainly something I've noticed and it does seem to cause a lot of NIH and reinventing the wheel.
Killed by design. Companies that build products or services hate power users because they limit the ability to sell customizations or pro service engagements. Software is now designed to be hard to manipulate outside of the expected workflows unless you are willing to pay for a software engineer or three (either internally or via aforementioned PS) to figure out.
> ...hate power users because they limit the ability to sell customizations or pro service engagements.
Never ascribe to malice... Having sat on the product side before with some of my clients, I can describe it from their point of view. Power users typically consume a disproportionate share of support engineering and development engineering hours per account compared to their normal user calls from an accounting perspective. The holistic, value-adding way to approach this is to work more closely with the individual power users to find out what they are doing in detail for each of their industries, find commonalities, and push product capabilities in those directions.
The reflexive accounting response is invariably "make the power users stop using support services so much". Engineering then gets asked, "how do we stop these kinds of questions?", and the holistic response is shut down because "that costs too much, I want another option". You can see where this is leading...the features power users leverage get sunset, and finance/accounting is happy when they become responsible for a KPI improvement.
...while ignoring that any of them would give their eye teeth for the kind of profit lock-in Excel delivers, and under their KPI regime, Excel power users would have been stillborn.
Never ascribe to malice, that which is adequately explained by incentive structuring.
BTW, I usually clarify with leadership what they envision in these situations in a behind-closed-doors meeting that doesn't challenge them. Most of them honestly do not want Excel-like lock-in via power users. They feel it is too fraught a road and that they can achieve lock-in in other ways. Fair enough, and my due diligence advising them is discharged (I might not agree, but there comes a time to help the organization put all its wood behind a single arrow).
> Never ascribe to malice, that which is adequately explained by incentive structuring.
Incentives sounds exactly like what the person you're responding to described. Malice, on the other hand, doesn't show up at all in what they wrote.
It seems weird to introduce some element to the discussion yourself, and then work so hard to explain why an explanation that depends on that element is the wrong answer. It amounts to a sort of elaborate and roundabout strawman.
I'm a "power user" who can eek into the terminal and light programming as needed.
We're not disappearing, per se, just being utterly ignored. Mass market is moving towards methods of turning all computing into a phone, with vendor lock in and the user as nothing but a consumer who needs to pay to do things with their own devices.
I am unprofitable as I do not need to pay for an app/macro/SAAS to do things but also don't do those things as a business and therefore will not be paying to outsource the costs of doing those things.
In truth, I am in this area in many areas, from computing to kitchen appliances and grills. It feels that global capitalism is highly antagonistic to products and services that empower users to do things themselves.
> Something I've been noticing lately is the disappearance of the “power user”.
What gives you this impression? I thought different software at art university (Unity game engine, Blender) during the last years. The spread between people who alt tab their way between programs and people who move the mouse as if it was some foreign object didn't change much since 15 years ago in my experience.
What might have changed is that people have different expectations in how easy/hard software should be to learn.
I think this is right. To me, there are a few reasons:
- there are more formal solutions available. I don’t need a macro for automated responses because Freshdesk does that for me.
- culture has moved toward seeing apps as smaller on average (except for MSFT) and not extensible. I think our attitudes toward mobile have had a big effect.
- a lot of people get as much utility as they expect out of their machines unmodified.
I have the impression that programming has become easier. It used to be that you needed a compiler, editor and so on to build desktop apps. Now, many products support scripting in some form, so people jump to that. Or, they support data export, so people write a python script which can read that data. Etc.
Perhaps it is a learning curve problem? In a world where user manuals and UIs are friendlier than man pages, the increase in "smartphone tap-only users" will definitely be faster than the increase in "vim/terminal ubergeeks."
This is sad because terminals are powerful tools that are fast, composable, and programmable.
What we need is for terminals to provide easier hooks to help people become "vim/terminal ubergeeks". Use a command repeatedly? Help the user set up their first alias. Need to use an advanced sed command? Help the user form their first sed and then slowly take off the training wheels. Programmers really do want to learn to become power users. Terminal UI needs to evolve to help them.
> It seems like there's now a much wider gap between the smartphone tap-only user and the Vim/Terminal ubergeek with almost nothing in between.
Smartphones are truly impressive tech devices. There are people around the globe running businesses/houses/hobbies with nothing but a smartphone. On the other hand, “code” has never been more accessible and powerful.
I feel like the disappearance of the “power user” is not like this of the middle class in our western society. Maybe they turned into “power doers”.
I don’t think that’s true at all – consider the surge in popularity of no-code tools these days. What would you call somebody using Zapier to hook two completely different systems up to talk to one another, if not a power user?
Maybe it's just a symptom of everything moving to the cloud over the last decade. You're definitely right about power user tools like Zapier, but desktop-based software has become less amenable to power users.
I think that the fraction of users who are power users has gone down as the people who own a computing device has gone from "those willing to shell out the price of a used car" to "everybody"
They have continually sucked people in with promises then shut the door behind them, replacing those promises with restrictions and entrenching in to “the one true ecosystem”
The article paints command palettes as a return to terminal inputs. However there are two massive differences. Firstly, the use of fuzzy search and natural language makes the commands discoverable. Secondly, there is a feedback mechanism that shows what the command will do before it's run. Together, these massively lower the learning curve.
While I agree that adding fuzzy searching and natural language discoverability are great, there are some other pretty important differences.
I thought a lot about this line:
> you had the best of the terminal paired with the best of graphical interfaces
Maybe there are many parts of a terminal that are “the best” for different people or use cases, but to me the key feature of the terminal is the ability to compose, extend, and abstract. Use a command with certain options a lot? Turn it into an alias or one-liner script. Use a pattern of commands a lot? Turn it into a script. Use a particular command really a lot? Add it as a custom keybinding. And it's pretty easy -- once you've paid the price of learning to use the shell at all, you are ready to start writing basic scripts. Granted, the price of entry to learn the shell is high compared to command palettes. But there is so much there that command palettes are still missing.
It also possibly increases discoverability even compared to a traditional GUI, because you can scroll through the list and see things you otherwise might not have known about.
This is absolutely my favorite thing about command pallets. Any time I need to do anything in vscode I just type something close to what I'm trying to do and scroll until I see something that looks right. Way easier than just about anything else.
macOS has a similar feature for the menu bar- every app has a Help item that allows you to search all menus at the same time. It doesn't work as well as a command pallet but it is incredibly useful for menu-heavy apps.
Menus are great for discoverability because they show you all the options in an organized way, but they're slow. They're excellent for rarely used commands.
Keyboard shortcuts are fast but they require memorization. They're great for something you do many times a day.
Command pallets fit in the middle. They're most perfect for the niche where you use the command often enough to remember that it exists and at least roughly know the name, but nowhere near often enough to warrant memorizing a keyboard shortcut. Especially for text editors where you're already in typing position, they're much faster than menus and not that much slower than shortcuts, and you can give access to much more commands than you can define reasonable shortcuts for.
And as you said, CLI with the precise syntax requirements is simply the worst.
I think the differences are not fundamental, but that the terminal inputs / shells did not evolve as much as they could or should have. There have been discussions all over the world on the merits of command-line vs. GUI, but too little of how tomorrow's command-line can be better than today's command-line.
Things DID improve, e.g. tab-autocomplete evolved very well. But that's not enough, and editor's command palettes show that. I actually thought I'll give some more quick examples than discoverability, but then I realized that you could fill a whole document with them...
Tomorrow's shells would require changes to various command-line tools and possibly even the kernel. Just changing the shell executable is fundamentally limited, so it cannot be more than the first step. But thanks for the links anyway!
> Tomorrow's shells would require changes to various command-line tools and possibly even the kernel.
Hi, author of _murex_ here. I don't believe that to be true. I mean, I do agree that it would be great to replace the 50 years of legacy of TTYs, byte streams, in-lined control sequences (eg ANSI escape sequences), etc but you can still achieve what you're after. And murex does aim to do this because it is as much inspired by IDEs as it is by scripting languages.
To give an example of these feature:
+ Murex does "fuzzy" search against all possible completions (so does Bash et al with addons, but murex does it out of the box). Do this by pressing ctrl+f
+ Murex does in-line spell checking
+ Murex supports typed pipelines (inc complex formats like JSON, YAML and CSV) and will autocomplete commands that support that data type by default. But it will also work seamlessly with existing POSIX / CLI tools too. It does this by passing the type information in a separate channel to the byte stream. So POSIX pipes work the same but processes that support murex can do richer things with the pipes
+ in expansion of the above, structured data is handled intelligently within murex. eg if doing a regex match against a JSON array you don't need to escape out the JSON formatting. Your tools will automatically only work against the values inside the array. And you can use the same commands against JSON, YAML, TOML, CSV, C-Expressions and others -- the commands understand what the file format is and natively adapt to it. Meaning you don't need to learn different tools for working with JSON than you would for CSV, YAML nor any other format.
+ Murex will display descriptions against each command suggestion (Fish does this too)
+ Murex parses man pages to help build up autocompletions if no autocompletion are defined (Fish also does this)
+ If you're running tmux, you can press F1 against any command in murex and it will open a pane alongside your interactive terminal with the man page (if an external command), a cheat sheet, or the code (if a murex function) so you don't have to remove yourself from the terminal to double check a commands usage
+ Murex has a hint line that acts like a status bar. In there you'll see descriptions of each command (also parsed from man pages if external executable) and also details about the type of command (alias, function, external executable), where is sits in your file system (even showing the path of symlinks) -- so you know exactly what command you're calling and what it is supposed to do.
+ syntax highlighting (this is an increasingly common feature in shells these days)
+ syntax completion (eg quotation marks will smart close)
+ multiline pipelines are handled much better (eg you can up array to the line above and murex wouldn't erase the current pipeline to show the previous one)
+ smarter support for pasting multiple lines (murex will detect if you're pasting multiple lines and allow you to preview it before it then runs those lines. Saving potential mistakes where you're pasting the wrong thing from clipboard)
+ murex can in-line images. It supports client specific ANSI escape sequences for iTerm2's, Kitty, Terminology (Enlightenment) as well as Sixel and ANSI blocks; and will auto-detect what mode will work best with your terminal emulator.
+ colours errors in red (inc STDERR)
+ displays stack traces of errors (inc STDERR)
These features are configurable (can be turned off if you wish) too so if any one of them is not to your tastes you can change the default behaviour.
To be clear, it is still beta software but I've been using it as my primary shell for ~5 years and there are other shells that exist that support some of the same feature sets too. So there definitely are other shells out there that are striving to achieve what you're after, and I'd like to think are having some success at it too.
- output less noise that drowns the signal. The toolchain used to build a program from source is particularly problematic here.
- if the output has to be huge, make it structured / collapsible
- output messages that are both human-readable (so humans don't have to read cryptic data that is meant for the computer) and computer-readable (so the computer does not have to parse human-readable messages, which is fragile). Yes, that's hard.
- Provides tools that each solves one problem, and solves it well.
Some things that could have been changes to tools are implemented by tool-specific extensions (IIRC, bash autocomplete of tool parameters works like this). Discoverability can to some extent be implemented like that, including inconsistent naming of command-line options for different tools.
Might require changes to the kernel (details depend on the OS, and on whether the terminal runs inside a GUI window):
- proper handling of color. Right now, color is encoded as in-band information (ANSI escape sequences) that confuse various tools, e.g. grep cannot find a substring if there is a color change in the middle of a substring. The workaround is to have all tools detect if they write to the terminal or a pipe and not output color at all, which means that I can't grep without losing color. This might require changing the kernel because the terminal driver that defines how color is encoded sits there (again, might be different in a terminal window in the GUI).
Dropping the idea of plain text output and input.
In reality such text does not exist. It's always structured text: log files, CSV, configuration file formats, markup formats, source code, ...
Language servers for almost any of these already exist, let's use them in the tools.
Although I don't use it, I see plenty of positive feedback about fzf [0] and I'm sure I've seen palette-style tools built with it that enable command and options discovery.
Hi! Michelle, an engineer from Warp here. Thanks for mentioning us. We've been building a Rust-based terminal.
Currently, we're currently building a feature called "Tasks Not Commands".that allows users to interact with the terminal via a task instead of an obtuse command or series of commands. See the mock here [1]. For example, be able to type "undo last git commit" instead of needing to memorize `git reset --hard SOFT`. We envision users being able to create and share their own custom tasks as well. What do you think? Join our discord to stay updated. [2]
I'd like to add a third, pro-terminal point, that cli tools are inherently ready to be scripted, piped, executed in batch and in parallel, none of which are common in gui apps with or without command palattes.
This is a great observation. In the end, the goal of a terminal usable by people and machines was folly. Machines can use the shell, humans can use the command prompt.
Ironically, Zsh has a huge amount of thorough documentation, which is badly undiscoverable due to the "conversational" writing style as well as the utter lack of "semantic" search ability in man pages.
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 "drivers" for some technical hardware. The instructions for Windows computers was a series of color glossy screen shots, with circles and arrows, and a paragraph under each one. Of course they were particularly hard to follow because they hadn't been updated to the last revision of the OS.
In contrast, the Linux instructions were:
sudo apt install foo bar blah ...
sudo add a line to this file ...
And even instructions for Windows computers are adopting this strategy:
Press Windows-R+cmd, enter these commands
I love the crude palette consisting of pressing the Windows key and typing some gibberish into the search bar, like "device manager" or "bluetooth settings." Much better than trying to remember where those things are located. And incrementally improving the search function will keep making it better. I hope. This could be the backdoor route into natural language computing.
This have been discussed here but there was a time (Windows 9x/XP area) where GUIs were « intuitive but with some learning curve ».
Of course it was a little harder (but not that much) to master the tools of this era but once you understood the basic paradigms (files, folders, windows, menus, toolbars, common discoverability, common keyboard shortcuts, F1 for help…) you could become proficient in any unknown software way more faster than today.
Now, there is nearly no transferable knowledge between 2 softwares. For me this looks like « knowledge lock-in » (which adds to the vendor and data lock-in, btw).
Well, we still have Linux if we want to learn something useful. But even there if you use it professionally, you’re probably going to be stuck with all those « I’m unique » Electron apps.
tbf, I think what we are missing is a truly high quality multi platform GUI toolkit able to work with modern language. Most are still only officially supporting C++ and nobody wants to write a complex application in C++ anymore.
I think that there will always be a dynamic balance between GUI interactions and command line interactions.
Command line is efficient and good for applications and function that you use on a regular basis, but can be difficult with apps that you are new to or only use occasionally.
A proper UI should be able to accommodate both the efficiency of familiarity and the discoverability for a novice.
Conversational interfaces, i.e., chat bots including Google Assistant, take this approach but eliminate the pre-submit feedback that is so handy if you're at a keyboard.
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 do this on Mac? Why? I found this really jarring. I know on Mac you can press CTRL + F2 (add Fn key if you have one) to change the keyboard focus to the menus but it doesn't underline the letters that will work and you have to hit enter to open things so it's clunky.
The command palette is nice for discovery of lesser used commands and when there's lots of them but it's less predictable what keys you need to press to fuzzy search to the command you know is there and it doesn't teach your fingers the shortest key combo to trigger it.
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 configured to register ⌘? whenever I press and release the left control alone without using it as a modifier of any other key. The `to_if_alone` condition in Karabiner-Elements is one of my favorite ways to re-use all of the modifier keys to invoke special commands. It would be great if I could figure out how to do that in Windows.
This was a nightmare to deal with together with i18N. What if there were no available letters for doing something in a language for a particular command?
The solution was in the switch to Ribbons: the underlines were replaced with keytips that are displayed when you hit Alt and as such aren’t required to be a character in the command’s name.
Emacs always has an embryonic version of that with M-x, but with a simple autocomplete. That’s is, until Helm arrived in 2011: it made everything that is a list something to be dynamically filtered (commands, shortcuts, buffers, files, etc).
IntelliJ has a command palette too (Ctrl-Shift-a), but it’s horribly slow and has many items with the same name doing different things (try looking for “settings” for example). But it does allow you to add a shortcut to a command you find on the fly, which is great.
Right? I've been emacsing for a couple of years now but I haven't reached the critical mass yet; where I can sit down and just code something up like this.
Anyway, M-x-helm is pretty critical to my workflow; half forgotten (or guessed) commands work pretty dang well when you can complete them.
Worth pointing out that Helm was a fork of anything.el, and I’m pretty sure stuff like Icicles predates even that by as much as a decade, so 2011 is underselling Emacs a bit here.
According to emacswiki anything.el (which was the predecessor of Helm) started in 2007. Compared to that Sublime v2 which had the command palette according to the article, came out in 2013.
Helm is a huge package. If you want something that stays closer to a vanilla experience, check out Daniel Mendler’s Vertico package: https://github.com/minad/vertico
> The convention of being able to search Settings menus feels like one of the only things that's got unambiguously Better about software UX in about a decade.
I could have sworn I saw a dropdown command/search dialog designed by Jeff Raskin as part of The Humane Interface, and demonstrated in PyTHE a Python imeplementation of it.
Can't find any evidence of it, but I can find a 2003 Guido van Rossum review of Jeff Raskin's book "The Humane Interface" in which Raskin mentions LEAP(r) a design for adding search-backwards and search-forwards keys below the spacebar to save people from arrow keys and mouse use, which is demonstrated on the CanonCat computer from 1987 in this[2] video on YouTube.
Right, The Humane Environment, following on his work with the Canon Cat and the Macintosh, before Steve Jobs took over the project and made it into a better Lisa. Later they renamed THE to the more googlable "Archy", a pun on RCHI, the Raskin Center for the Humane Interface, shortly before Jef's surprising death from pancreatic cancer. Jef's son Aza unfortunately hasn't kept Jef's stuff online, and he also invented infinite scroll websites. Nice guy though.
LEAP was Emacs incremental-search, but on the Cat the idea was to use it to replace all cursor movement except "creep" left and right arrows.
Every macOS application has a command palette in the help menu: command-shift-/ will bring it up and you can incrementally search all the commands in the menus.
As an infrequent Mac user, how is this stuff discoverable? The OS seems willfully obfuscated to cater for some notional lowest common denominator user. Whenever I find myself using someone else's Mac, they never know any keyboard shortcuts or keyboard-plus-mouse-button context menus. It's bewildering and wildly frustrating. I find myself asking "surely this isn't how you always do this, there must be a better way?" but I only ever get shrugs in reply.
Admittedly, these are non-techy folks. But they are daily Mac users. It's weird, like the OS discourages curiosity and experimentation.
And then there are those times when I stupidly assume things, like how it will surely be trivial to remote desktop from my laptop into a Mac while someone else is logged into a different account on the Mac. What a shit-show. My reaction: "are you f*cking kidding with how horrendous this is?" Mac owner: shrug.
Most of the keyboard shortcuts for a particular application are right next to the menu item. The command palette I’m talking about is clearly visible in the help menu: my theory is that people no longer browse the menus of a new application the way I would back in the NT 4.0 days.
The system-wide shortcuts are a bit less discoverable but, they’re there if you know where to look: either search “keyboard shortcuts” in the os help system or go to system preferences > keyboard > shortcuts.
Thanks for this, I'll be sure to check out the keyboard preferences next time. I was referring to the "command-shift-/" key combo you mentioned when asking how to discover things in Mac OS, since it really feels that power-user functionality is hidden.
I'm not exactly a Windows fan, but (generally speaking) in a standard windowed program, just hitting alt focuses the menu. Windows is almost entirely navigable by keyboard by default, without a mouse. It's much more discoverable and efficient.... although that's been tanking since Win 95 :)
That command-shift-/ shortcut is listed in System Preferences > Keyboard > Shortcuts > App Shortcuts.
Also, if I use the Finder help menu to search "keyboard shortcuts", it gives me a local help article "Use macOS keyboard shortcuts". This article talks about a bunch of ways to find keyboard shortcuts and also links to this knowledge base article: https://support.apple.com/en-us/HT201236 (This is actually a sort of step backwards, from when I did exactly this around '07: at that point, the Mac Help system actually listed a bunch of handy keyboard shortcuts and didn't rely on online resources for them).
Perhaps I'm biased, but I find navigating application menus on MacOS infinitely easier due to the fact that it's location is constant and dictated by Apple. On Windows (or even Linux) I have to go searching for the menu items for each new application I'm using, and some feature (like quitting) seems to often be purposefully hidden away. Infuriating if you ask me.
I’d guess that most people don’t use keyboard shortcuts at all, and only very few use anything besides copy, paste, and maybe save. People are shocked when I “command+l, c, t, v, enter” to duplicate the current tab.
The ability to search menus is pretty discoverable. The search field is the first thing in the menu when you click the Help menu bar in any app.
But of course the shortcut to jump to the search area is completely undiscoverable, as are many macOS features. You can see it if you go to preferences -> keyboard -> shortcuts -> app shortcuts. (And you can also reconfigure the shortcut key, or reconfigure any shortcut in any app. That feature I love)
Back in the day I used Alfred on OS X... basically a system-wide command palette. Lots of its features now exist in Spotlight natively- not just file/folder search- it can do math equations, dictionary lookups, email search with date/keyword matching, currency and unit conversions, language translation, it also supports boolean operators.
I have yet to find a similar functionality from any other OS.
And even better, you can just go into system preferences and turn off what you don't want!
At one point I had a newish version of OS X spotlight pared down to be about as functional as the Windows 7 start menu Search. If I had wanted command-space to be closer in feature parity to a Windows 10 start menu, it's approximately five reasonably intuitive mouse clicks to get to the settings prefpane with those checkboxes. I too have yet to find similarly well made functionality from any other major-ish desktop OS.
I still use Alfred daily! Its development is going strong.
I love Alfreds custom workflows. Half the time I’m using it the same way I’d use Spotlight, but I’m also using it to trigger custom workflows constantly. (Which often just call out to CLI utils or run zsh/Apple/Swift scripts, integrations that Alfred makes easy)
I also appreciate its global hot key support. For example, I’ve setup the F14/F15 keys to adjust brightness on an external monitor. (Just by having a workflow call out to `ddctl`)
Alfred was really cool. I replaced what I liked about Spotlight in Xubuntu by using combination of Guake, XFCE Whisker Menu Search Actions, and DE keyboard shortcuts bound to various scripts. Then I added some more stuff that I never knew I wanted from Spotlight.
I couldn't go back now, TBH, without using some kind of Mac OS native scripting components.
Yeah, this is a great feature! I would like to have an option to move the menu into the into the window under the toolbar or floating like the spotlight window since it's a little less eye travel, but nonetheless it's very handy to have the ability to activate menu items without having a dedicated keyboard shortcut.
Raycast has this neat feature called Navigation → Search Menu Items which is essentially the Help → Search feature of macOS.
However, you can bind it to any shortcut, so binding it to Cmd+P would give you a command palette in any app (and then you can exclude e.g. Sublime Text/Merge who already have their own palettes).
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
Rhino 3D allows you to type in anything you can do with the mouse. You just start typing, no shortcut first. It's feels like a beautiful marriage of powerful command line app and equally powerful and pretty UI.
I've been using it regularly since around 2002 and this functionality has always been core to its being. It makes discoverability hugely simple, just start typing what I want to do.
I've always wondered why more tools haven't had similar functionality. I'm glad to see the growing population of command palletes some 20 years later.
Rhino 3D is my favorite piece of software. I used to use it for hours a day, and it felt like a natural extension of my mind. It was truly a perfect merger of UI and command line.
People keep on telling me how amazing Blender or SketchUp is, and they just can't understand that the perfect 3D modeling program with the perfect UI already exists, and has existed for over 20 years now.
There really is something to be said about the Command Pallete and UX design as a whole. I started out using Sublime Text as that was the easiest out-of-the-gate editor. I then spent several years in a fully customized tmux + vim configuration. A lot of fun! But it got stale, and then I spent several years in Emacs. And then VSCode came along with a lot of conveniences, and thus I used that for a year or two. Now, almost a decade after teaching myself how to program and making a career out of it, I’m back to using a pretty bare bones Sublime environment. It does what I need and it does it fast. My inner quest to become The Poweruser has been replaced by a quaint appreciation of simplicity. Thanks Sublime! (though it should be said: I’ve always used Vim-bindings, the pinnacle, in all these apps)
I went through a series of phases just like you're describing, but I eventually settled on vim + COC as my "home" editor. The COC plugin has been a game changer for me; all of the conveniences of a language server without the bloat of a full-featured editor like VS Code.
> "People need to feel that they can try things without damaging the system," recommended Apple’s Human Interface Guidelines.
well, for what it's worth, many modern apps aren't following that guideline. for a long time i have questioned the disappearance of tooltips in user interfaces. especially when everybody seems to come up with their own iconography nowadays.
the answer i got from UX people is that "you can't hover or have tooltips on mobile". they are trying to achieve uniformity between mobile and desktop.
they will probably confine that useful command palette to particular apps too. because you can't have a command palette on mobile either.
> the answer i got from UX people is that "you can't hover or have tooltips on mobile". they are trying to achieve uniformity between mobile and desktop.
Achieving uniformity by reducing the user experience to the platforms' lowest common denominator. Not the best solution!
It actually doesn’t seem like that bad of an idea to me, at least under the assumption that you’re not going to maintain an entirely separate UI for the mobile and desktop apps (which would be ideal, but is incredibly expensive and tends to result in broken and missing features on one or both platforms even for companies with enormous budgets). I would argue that “reducing to the lowest common denominator” actually is one of the more reasonable solutions among the feasible options. It certainly isn’t a great solution to create a UI that is impossible to understand without tooltips and ship that UI to mobile devices without the tooltips!
> It certainly isn’t a great solution to create a UI that is impossible to understand without tooltips and ship that UI to mobile devices without the tooltips!
Right, so don't do that. But, desktop and mobile are different platforms with different input devices, and designers should make use of both to create the best experience for users. There are certainly tradeoffs in terms of cost to implement versus value for users, and if the argument is "it will simply cost us too much money to implement tooltips" then I suppose that's up to the product manager or equivalent. But, "we can't have tooltips on desktop because the mobile version doesn't support them" is a non sequitor. If a UX person gave that as a reason, I'd have some questions for them.
Best option is to provide choice. Icons with Labels by default, show keyboard shortcut on hover. Want just icons? There’s a config option for that. Want just labels? Also an option. Want no toolbar at all, and only use shortcuts? Also an option.
I clicked your profile to see exactly who would come up with such an odd take, and then it made sense.
I actually agree with you that this type of deep customisation is great for a "productivity tool" like VS Code.
For something that people don't spend hours of every day in, though (say, a weather app), you don't need or want this level of customisation.
Though I was actually thinking of SketchUp when writing that. VS Code does not provide always-visible labels for icons (tooltip only), though it’s something we’ve discussed and I’m in favor of. I believe Teams recently adopted them.
It ebbs and flows but I feel like we're coming to the end of a long period of "convention over configuration" that prioritized consistent, predictable behaviour across systems at the cost of powerful options & custom configurations. I understand what you're saying but there's also cost to implement and maintain all those options you want, plus a huge set of testing combinations for QA
As the siblings mention it doesn't really apply here because the choices aren't one-shot, you aren't stuck with one, you have time to consider, choices can differ a lot, etc.
But really any supposed psychological phenomenon should be looked at skeptically absent overwhelming evidence like IQ or the Big 5 personality traits. Here are three links on "choice overload":
https://ieeexplore.ieee.org/document/8426193 2018, "...where they could compare them one another anytime with relatively low cognitive load, the choice overload did not occur (Experiment 1). ... where participants had to compare them based on memory representations with relatively high cognitive load, the choice overload did occur (Experiment 2). These results suggest that the choice overload is actually replicable when cognitive load is sufficiently boosted."
http://psychbrief.com/choice-paradox/ Nice overview of some actual studies and the underlying experiments, as well as common flaws in the mathematical methods used for analysis that apply to many psychology studies.
That applies to when a choice must be made before the user can proceed, or when making once choice has an associated opportunity cost that prevents/discourages the user from making other choices. If the user is presented with sane defaults from the start and can also try toggling a checkbox in a settings UI to instantly test alternatives, the study does not apply.
Rule of the lowest common denominator, whether it be by way of trying to accommodate multiple form factors or multiple operating systems is certainly one of the biggest drivers of the decline of truly excellent software. One size fits all is never going to fit anybody even half as well as something more tailored to a specific subset.
I would like to see someone try the opposite, where when possible gaps in functionality on one platform or form factor are filled in, so all users’ experiences are elevated by the most capable target rather than dragged down by the least capable. That will probably never happen though.
> the answer i got from UX people is that "you can't hover or have tooltips on mobile". they are trying to achieve uniformity between mobile and desktop.
Yes you can. The generally agreed upon way to do this is by long pressing whatever you want to see a tooltip over.
I think it's kind of funny how Google is using this as an example when their own Gmail app in iOS has the "Write a new email" action as a floating action button with a pencil and the word "Compose".
I wish they labeled all the major FABs. It took me ages to figure out how to make a new spreadsheet in Google Sheets on the desktop after they switched to a mobile-first UI. That Google-logo-colored "+" button in the lower right is not easy to see. If it had text next to it I'm sure it would have been harder to overlook.
The problem with this is how you indicate to users that tooltips exist via the long press action. I personally never knew that long press to show a tooltip was the "generally agreed upon way" to show tooltips, and it would be a lot simpler to just have a button label.
How do you indicate to users that they can right-click on a computer mouse? You don't; they just know it. If they don't, their friends and family will teach them.
You put a line of text in the mobile UI that says "To see tooltips, press and hold on a button."
You can stop showing that line of text once they've shown a tooltip (or two, if you're worried about them triggering it accidentally and not knowing how they did it).
A gui combined with tooltips is one the easiest to learn interfaces. I have a very bad memory and GUIs show me what my options are. It's like typing a command with --help except it's always there
Either you have a tooltip explaining the function or you have to test it to understand what it does. But to test something you want to know it doesn't cause problems.
I feel like this is some fundamental UX dimension here. Cost and risk of learning. How much time do I have to use to learn all the commands or find the right command and if I have to try it what is the risk of breaking something?
Another thing that helps is a predictable, reliable undo function. If the user believes that any action is easy to undo, unknown actions won't be so scary. Of course, this is sort of a chicken-and-egg problem, because other than ctrl-z in certain desktop environments (in which environments undo is not always either predictable or reliable), there is no well-known idiom for undo.
Judging from old reviews of the phone, it looks like a positional proximity sensor. The screen had a blue hover glow where your finger approached the screen.
The whole screen was mounted on a big button, so touching it was hovering and you'd press the screen with a satisfying click to execute something. It wasn't the most reliable if you weren't careful, but why not do that with a pressure sensor nowdays?
I've not used an iPhone for a while, but according to Google search:
> The iPhone 11 and iPhone 11 Pro will ditch 3D Touch in favor of "Haptic Touch," according to Apple's website. ... The new iPhones' Haptic Touch will be responsive to how long users hold down, but not the force of the tap.
I would love that feature, but I think it has to be very integrated into the software and the APIs of the phone OS or no one will actually use it.
I loved force touch but it's gone now. On MacOS the touchpad still has force touch, and hard pressing on a word anywhere in the OS brings up dictionary definitions. It's amazing for language learners.
These paradigms can be complementary. Menus and toolbars for when the user is browsing and they don't know what they want, command bars for when the user knows what they want but not how to get there, and shortcut keys for when they know what they want and how to get there.
I like a good command line, but the whole search box thing is annoying me to no end because it not predictable.
If I type three characters and press enter, it shouldn't matter if I wait 0.5 or 1.8 seconds before I press enter. But with this mechanic, it typically does. What is "set _rem_inder" one time is "_rem_ove all files" the next time.
> I hate this trend. Give me back menus and toolbars.
Everyone has their own preferences; personally, every time I open Word, I am confused and disoriented and have no idea where to look for what I want. I think it's best for no-one to try to impose their UI preference on everyone, and for all of us just to use the software with which we find it easiest to interact.
I know UI is subjective, but when the Ribbon was introduced I thought it was the best UI idea I had ever seen. It made the Office apps interface much more discoverable and easy to use than without it. It's a shame that the Ribbon paradigm is patented.
counterpoint: I'm an Excel power-user and I really like the ribbon UI. when you use the alt mode you can fly through it and opportunistically/incrementally learn the keyboard shortcuts.
Something that irks me a bit is that the UI (with it's animations) can't keep up with pressing keyboard shortcuts. For example in word to change font size you could just do Alt+h+fs+<number> but you can't just press it as a single chord, you kinda need to wait for the UI to focus on the correct fields to make sure you're at the correct place
One of the best features of OSX is that programs have menu bars. I didn't even know they had removed the menus from VS Code on other platforms. I still can't find anything in word, except on mac, where there is an actual menu.
Anyway, the removing of menus was not caused by the addition of command palettes. I think the history is that microsoft believed icons was easier than text, so they made the ribbons, and then for a while other removed menus in favor of ribbons, but then they realized ribbons sucks, so they removed those, and then there was nothing, maybe a hamburger menu if one of the UX's had done webdesign before.
Cod(e/ium) requires Ctrl+Shift+P to actively engage its command palette.
AutoCAD strikes me as a fundamentally different paradigm in that its command interface is "always active" so to speak, whereas menus/toolbars feel mostly like an optional overlay, at least to an experienced user.
Although AutoCAD is my preferred tool when drafting electrical architectures and wiring diagrams, the mouse as primary human interface is simply unavoidable in any sensible CAD, which makes constantly having to release the mouse to type the next command, or F3/F9 to toggle object/grid snaps (especially with shit modern keyboards without standard F-key separation e.g. MX Keys) admittedly annoying. I contrast this UX to SolidWorks which is overwhelmingly mouse+toolbar in a way that's comparatively trivial to navigate, or Altium which is driven by single hotkey sequencing that allows the other hand to stay fixed on mouse.
I use Solidworks like you use Altium. Any key can act as a shortcut, with or without modifiers. For me, ctrl-s is save, ctrl-shift-s is save as pdf, ctrl-d is save as a STEP file. Pretty normal so far. But, c is for circle, u is for horizontal constraint, i is for vertical constraint. I have at least 40 1 or 2 key shortcuts and usually I never need my left hand to move from the keyboard or my right hand to move from the mouse. The exception is for types of modeling which I rarely do, like sheet metal.
I've found AutoCAD can operate similar to how you describe Altium, in that pressing 'l' and enter gives you a line, typing 'str' gets you stretch, 'tr' gets you trim, shift-clicking with trim gets you the opposite of trim - extend. The command line has autocomplete. In this fashion, one hand operates the keyboard, and your other stays on the mouse.
I quickly fell in love with this interface and immediately switched to using the command line for the vast majority of functions.
AutoCAD is not like Altium in that the former requires either hitting Enter when the minimum command is entered, or more annoyingly, selecting from a slow-to-render autocomplete context menu with the mouse.
Some common commands can also be annoying when the required minimum characters don't cleanly map to a single hand, e.g. [E][X][P][L][Enter] to explode; or when they map to the other hand, e.g. [P][L][Enter] for polyline.
Altium's approach is literally single hotkey sequencing (i.e. no [Enter] after every command) which map directly to menus that underline each hotkey as a reminder, e.g. to [P]lace a [W]ire or [P]art in schematic capture, it's [P][W] or [P][P], respectively, while the menus change with ever key press. Yeah, your left hand is all over the keyboard, but every key press is a meaningful context switch.
The other day I used the Command Palette to symlink `code` as a command to open `vscode` without having to type `ln -s /path/to/vscode /usr/bin/vscode` which was quite nice because trying the symlink version gave me confusing errors.
I am unsure the UX is there to help make that discoverable in a menu; you'd be so deep that it'd be behind multiple sub-nests at a minimum. Seems much better to have a flat search for this.
Toolbars for the stuff you don't use frequently and therefore don't know the keyboard shortcuts, but still need those functions now and than.
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".
It's easier to type commands when you have to do it alot. It uses muscle memory rather than deplete your attention span. Might be difficult at first, but it's easier once you get used to it.
For the use cases you’re talking about, I prefer keyboard shortcuts.
No need to click search bar, or look at the search result list. One only needs to memorize, or setup, a keyboard shortcut like Ctrl+Shift+M, and with muscle memory it will consistently take well under 1 second. Search UX is slower, needs more clicks or key presses.
In vscode I press one set of keys and get fuzzy search access to every feature. I'd rather barely memorize the phrases to search with (several phrasing find the same settings for me) than to to memorize dozens of barely used hotkeys. Most of my day is scrolling through code and editing it occasionally, not doing actual commands from the menu or whatever.
To each their own, however I can see how it would be annoying when they don't include a menu for anything for folks who prefer that.
That is an interesting perspective. May I ask you what is you professional use of a computer and if it is programming - what kind of programming? I’m asking because I’m curious if environment drives habits/preferences.
I expected something like that. Don't get me wrong, not in a bad way in "I know where you're coming from way". I personally don't care for icons, I like "the Apple way" - a menu with a search. A perfect Windows UI for me would be no icon panels, just a menu in a window and some shortcut to search through it and also each menu item would've a keyboard shortcut typed next to it.
These command palettes are fantastic *if you know what you are looking for*. The reason is that the results page is ephemeral. I see many websites copying this type of design but using it for searching documents where it is far less clear which I want just based on the title. I end up having to redo my search, scroll to where I was, and try the next candidate over and over again.
The same idea applies to Keypirinha [1], a small tool to open Apps etc. on Windows by typing. E.g. hit ALT+Space, type F.. and it'll immediately suggest Firefox, based on your previous use patterns. No menus, no clicking, no mouse. Just awesome.
Nice, thanks! So far I use chocolatey [1]. It is good, although some apps tend to be outdated (I can live with that, for the moment, it is not that worse yet). Will definitely keep in my Package Control.
I can't remember the last time I browse through the menu bar / tool bar / start menu in windows / apps list in apple.
In vs code, i do command pallette, in iTerm i use fzf, in mac i use spotlight, in iphone i use spotlight to find apps, in windows i press start then start typing to search..
It is true, it is the norm! It's just super convenient
Something I'm not seeing in this discussion is that commands entered via keyboard are typically in English or an English mnemonic. That excludes most of the world's population. Are there command line style interfaces that are commonly used but not English based?
I don't think it excludes anyone. My native language has nothing to do with English, but I was pretty comfortable with an English-based set of keyboard shortcuts. It's just something to memorize, and that's it.
Why do people use a separate search bar, when typing the search query into the address bar works the same? Unless you're often searching for strings that look like URLs?
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 the Vim/Terminal ubergeek with almost nothing in between.
I remember being floored by bureau in the 90s that completely automated their Photoshop and QuarkXPress workflow with AppleScript just by hitting the record button (not a single line of code written), folder actions, smart file placement and similar tricks.