Software isn't designed for power users
Yesterday a friend asked me to help her with a bug. She wasn't a programmer, she was using someone else's software. Helping her made me think a little on user interfaces, and now I'm dumping those thoughts on you.
The software was Sibelius, a "music notation software". It has a feature called "import lyrics from text", where you give it a plain text file and will automatically syllabify the text and match it with the music beats. The problem was that it wasn't doing it quite right: it would, for example, syllabize "love" as "lo ve". Not only that, it wouldn't syllabize consistently: only one "love" was made into two beats! The rest were one beat, as you would expect. She wanted help figuring out why it was doing this.
(I don't know anything about music, so making prolly some mistakes here.)
I took some notes on the process of debugging it:
- There was no feedback on why there was an error, or where the error was. All we got was "the text was too short" or "the text was too long". Both errors would appear in the exact same modal dialogue with a paragraph of text, only differing by one word. It was very easy to miss which happened.
- At one point I figured out it was using a constraint solver. One consequence of this is that the error was potentially nonlocal, and the actual problem area of the sheet was nowhere near the broken lyric. I had to explain the concept of constraint solving and how that affected finding the issue. Without that I don't think she would have considered nonlocality. The software certainly didn't suggest that would be an issue.
- To locate the issue we had to use a divide-and-conquer strategy. I had to explain this debugging technique to her, too. In general, she hadn't heard of most debugging strategies, because of course she's not a programmer.
- To actually apply divide and conquer, we needed to split the text file up into multiple different chunks. For me that's a couple minutes of python, for her that's manually copying every few lines into a separate text file.
- Feedback loop: take a text file, manually figure out which notes it's supposed to belong to, select those notes, click "import text file". This was a tedious, error-prone process.
- Importing the text file involved clicking through 2-3 pages of configuration and options. We never changed the options on one of those pages. Another we always changed, in the exact same way (selecting a specific dropdown).
- One of the errors ended up being a weird state delocalization issue. We could reproduce it in other places with a specific sequence of steps on the music sheet. The buggy note looked exactly the same to all the other notes, and all instrumentation available to us as users showed it was the same.
Okay, so what's my point here? The program was written in a way that made it hard to debug. It did not provide useful information about the error. It didn't give you any tools to help you find the bug. If there was an error, you needed to have some knowledge of programming to know what the next steps were. It was written in a way that made it impossible to automate things that should be automated.
This all seems like a deep UI problem. We have a program written for domain specialists, but in a way that makes it harder for the domain specialist to actually use her domain knowledge. To some extent, she needs to understand programming, an unrelated domain, to deal with an edge case in the software. The user can't bring it to sync up with her needs.
Most apps are like this. I can tell Twitter to mute words, but not mute words by a certain account. I can't reconfigure the hotkeys in Firefox. Being able to script our own functionality into something isn't just important for programmer, it's important for power users. And almost nothing gives us that.
(We don't even have it as much as I want for programming: I want to be able to take a snippet of code and say "I don't know whether operator A should be >, <, >=, or <= and whether function call B should be foo or bar, so run my test suite against all eight possible versions and tell me which combinations pass the test suite.)
There's a couple of technical reasons for this (like security and implementation difficulties), but two subtler reasons most people might miss are A) we don't have a good sense of how to design programming languages/interfaces for non-programmers, and B) we don't recognize that "power users" need this kind of flexibility.
This is why I love AutoHotKey so much. You can slap an API on top anything with it. It's gonna be a crude API, but at least you have it! But it's really not enough. Also it's Windows only. There are similar things for Mac and Linux, but they aren't anywhere near as good as AHK.
Computers are bad y'all
If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.
My new book, Logic for Programmers, is now in early access! Get it here.