Given my experience that creating good UIs is really hard (I am no exception, I suck at it), I’d actually take familiarity with a suboptimal UI over a horribly designed creatively new one every day. :)
The first problem with many GUIs created by programmers is that they’re not actually “designed”, they’re just a randomized heap of controls to tweak all the internals of the program with little to no thought on how to best present them to the user. Simple things such as grouping controls and putting useful labels on them goes a long way, but even that seems to be difficult for many.
Also thinking about what the entities are in the user’s mental model of the app and what their relational hierarchy is. These are often very different from how they’re “actually” structured in the programmer’s view of the world.
If you want a really good user interface then give it modes like how Vim has them.
This is the first thing they told me NOT to do when doing GUIs at university. In fact, it is said that Ctrl-C/Ctrl-V is so popular, because it’s modeless. I think there’s actual research that shows that modes in GUIs are bad, for various reasons but it’s been a while since I studied HCI.
That’s what I’ve read, too, especially in Jef Raskin’s The Human Interface. I suspect the copy/paste work was from Larry Tesler, who reportedly had “NOMODES” on his license plate?
That all said, I definitely see that all the software I use actually has quite a few modes…and, when trying to make software for people, people tend to like having modes (at some level) to “guide” them around a process. Is that because they don’t want to spend the time learning a new interface as compared to something that is familiar? Or because of a different valuations between long-term efficiency as compared to the initial learning curve? I don’t know. :-)
Out of curiosity, from when you did study HCI, do you have any recommended texts or resources?
Maybe the disrepancy here is due to how a broad concept a mode is. I believe the problems are there. Wikipedia has a section about mode errors in user interfaces.
There’s certain kind of behavior that is terrible, but it’s not entirely captured by vilifying modes (well, if we’re precise then it is though).
Notification pops up when you’re trying to do something and you click the notification away accidentally, while also messing up whatever you were doing.
Something steals the focus while you’re writing a command.
A prompt grays off everything else in front of you, the answer causes an irreversible change, but to answer it you’d have to look up something first.
I’d be quite furious if Vim abruptly shifted --INSERT-- to --VISUAL-- when I’m typing text. That has never happened though.
So maybe the rules of good modes can be captured in this way:
The mode changes immediately upon an user request of mode change.
The mode never changes due to an external action.
The mode always displays itself properly.
The mode change is an irreversible action in itself.
The volatile internal state that is destroyed on exit from the mode is identifiable for the user.
I’d think this may be good enough to be added there into the post. What do you think?
If you want a really good user interface then give it modes like how Vim has them.
Steinberg’s Dorico actually uses this. Though it doesn’t really look like tabs, there are different modes that you have to be in in order to perform different operations (like Write for note input, Engrave for setting up engraving and layout rules, and Play for playback of your composition). The problem here is that modal interfaces are clunky to use if operations that are commonly done together are split between different modes. In Dorico’s case, you can change the horizontal position of a pin in Write mode since that counts as writing a composition, but if you want to change its vertical position, you need to context switch to Engrave mode since that is a layout modification.
Also, check out Tantacrul’s video on Dorico if you haven’t already. His interface design videos for notation applications are some of the best content on the subject out there.
Given my experience that creating good UIs is really hard (I am no exception, I suck at it), I’d actually take familiarity with a suboptimal UI over a horribly designed creatively new one every day. :)
The first problem with many GUIs created by programmers is that they’re not actually “designed”, they’re just a randomized heap of controls to tweak all the internals of the program with little to no thought on how to best present them to the user. Simple things such as grouping controls and putting useful labels on them goes a long way, but even that seems to be difficult for many.
Also thinking about what the entities are in the user’s mental model of the app and what their relational hierarchy is. These are often very different from how they’re “actually” structured in the programmer’s view of the world.
This is the first thing they told me NOT to do when doing GUIs at university. In fact, it is said that Ctrl-C/Ctrl-V is so popular, because it’s modeless. I think there’s actual research that shows that modes in GUIs are bad, for various reasons but it’s been a while since I studied HCI.
That’s what I’ve read, too, especially in Jef Raskin’s The Human Interface. I suspect the copy/paste work was from Larry Tesler, who reportedly had “NOMODES” on his license plate?
That all said, I definitely see that all the software I use actually has quite a few modes…and, when trying to make software for people, people tend to like having modes (at some level) to “guide” them around a process. Is that because they don’t want to spend the time learning a new interface as compared to something that is familiar? Or because of a different valuations between long-term efficiency as compared to the initial learning curve? I don’t know. :-)
Out of curiosity, from when you did study HCI, do you have any recommended texts or resources?
Maybe the disrepancy here is due to how a broad concept a mode is. I believe the problems are there. Wikipedia has a section about mode errors in user interfaces.
There’s certain kind of behavior that is terrible, but it’s not entirely captured by vilifying modes (well, if we’re precise then it is though).
I’d be quite furious if Vim abruptly shifted
--INSERT--to--VISUAL--when I’m typing text. That has never happened though.So maybe the rules of good modes can be captured in this way:
I’d think this may be good enough to be added there into the post. What do you think?
heh, you used affordances in the way don norman says not to, that’s interesting
re: the design of everyday things and https://uxdesign.cc/you-have-been-using-affordances-wrong-ac8ae92b9942?gi=c257a0f75b80
Steinberg’s Dorico actually uses this. Though it doesn’t really look like tabs, there are different modes that you have to be in in order to perform different operations (like Write for note input, Engrave for setting up engraving and layout rules, and Play for playback of your composition). The problem here is that modal interfaces are clunky to use if operations that are commonly done together are split between different modes. In Dorico’s case, you can change the horizontal position of a pin in Write mode since that counts as writing a composition, but if you want to change its vertical position, you need to context switch to Engrave mode since that is a layout modification.
Also, check out Tantacrul’s video on Dorico if you haven’t already. His interface design videos for notation applications are some of the best content on the subject out there.
I was going to ask what modern applications implements modes like vi/vim does, thanks for giving an example!
This reminds me of Gimpshop, a sort of photoshop layout version of gimp.