Introducing a set of concepts, principles, goals, and ideas that have dramatically improved my ability to write production-quality user interfaces from scratch. Base knowledge for later parts.
"The more common, and still better, equivalent is for the user to position their mouse over the representation of the checkbox on the screen (which encodes which one is selected), and for them to both press and release their mouse after that.
...
It achieves a better bits sent to useful bits received ratio, and it achieves this in less time."
This doesn't seem true to me. A user doesn't directly specify mouse coordinates, they have to express mouse position as a delta from the current position. This is many more bits sent on average than the keybind equivalent.
For new users, graphical widgets are certainly more intuitive. But as an experienced user, ctrl-L is definitely faster and less error prone than having to click the URL box.
The "still better" part refers to the typing-a-sentence equivalent, not the keybinding. Ultimately it's just an example and it's more complicated than something being "better" or "worse" - you might waste the user's time if they aren't aware of a keybinding (and there are no other options), so you've got to consider how often that case might be, and how steep of a learning curve you want. Stalling the user's ability of sending information at all is also a factor when considering the quality of the general information cycle (between programmer and user, through the user interface).
In the case of ctrl-L, you can provide both the fast-path and a slow-path (for learners, or people who don't care, or someone just using a mouse) for free, so it's almost a given that you should provide both (considering how often the user has to focus the address bar).
The first half of this article should be a must read for cognitive science and cognitive semiotics students!
"The more common, and still better, equivalent is for the user to position their mouse over the representation of the checkbox on the screen (which encodes which one is selected), and for them to both press and release their mouse after that.
...
It achieves a better bits sent to useful bits received ratio, and it achieves this in less time."
This doesn't seem true to me. A user doesn't directly specify mouse coordinates, they have to express mouse position as a delta from the current position. This is many more bits sent on average than the keybind equivalent.
For new users, graphical widgets are certainly more intuitive. But as an experienced user, ctrl-L is definitely faster and less error prone than having to click the URL box.
The "still better" part refers to the typing-a-sentence equivalent, not the keybinding. Ultimately it's just an example and it's more complicated than something being "better" or "worse" - you might waste the user's time if they aren't aware of a keybinding (and there are no other options), so you've got to consider how often that case might be, and how steep of a learning curve you want. Stalling the user's ability of sending information at all is also a factor when considering the quality of the general information cycle (between programmer and user, through the user interface).
In the case of ctrl-L, you can provide both the fast-path and a slow-path (for learners, or people who don't care, or someone just using a mouse) for free, so it's almost a given that you should provide both (considering how often the user has to focus the address bar).