I think you've still missed the point. He's not saying that keyboards should be used most of the time, he's saying that keyboards are better for structured interfaces while mice are better for unstructured interfaces and a lot of what we consider to be unstructured interfaces are actually structured (e.g. twitter).
While I don't think he's 100% correct, I do think he raises a lot of interesting points if you can look past his rather unhelpful delivery.
One of the things I got from this was that maybe we should do more to design structured interfaces instead of counting the number of clicks needed to transition to the page you're looking for.
Many enterprise applications (especially web based ones) are horrible to navigate, and some people spend most of their working days in them. It's terrible.
The app was modal and took up the entire screen. Except is was clear that the developers had larger displays than the workers because in order to view and use the entire page the workers had to scroll around both X and Y using the scroll bars. Well, that and the fact that tabbing around didn't go around in a logical order.
I walked out and returned with a slightly LCD display that I bought in a local big box store and nearly started a riot. They had all been using that crappy app for years like that and the worst pain point for it was due to the fact that the devs had assumed that everyone in the company had the same size displays while their employer had refused to buy those larger displays for the 45 people that had to use it.
To get around this load time restriction the developer simply put less information and features into window. So rather than spending 10 seconds loading one large form and fill it out, users would have to click though X number of windows, filling out part of the form in window.
I'm not sure where I'm going with this, but your comment reminded me of this case.
One of our meetings probably cost ten times the cost of 200 monitors!
Back of the envelope:
$400 * 200 = $80000 for the monitors.
You need to have $80000 / ($100000/12/21/8) = 1600 person/hour of meeting time to equal the cost. 100 people can meet for two days!
I feel like something is off with that calculation, but I cannot find it...
I remember seeing the bill for breakfast for one set of meetings - was nearly $5000.
Yeah - I was off with the "ten times"... but not by a huge amount ;-)
'look at what the iphone does with just one button' is a useless thing to say in an enterprise app.
etc.
it just shows that enterprise app developers don't use the software they make.
The power users know all the special shortcuts. Keyboard mappings, tab order, and also app-specific shortcuts (forcing look-ups to behave certain ways, quick key combos to access forms, etc). They value speed of data entry above almost everything.
The casual users know none of these things, don't care, won't remember them if we try to teach them, and place a much higher value on easy navigation and discovery via visual cues and mouse.
A very good touchscreen interface would probably be as good or better for cases in which typing isn't required, except that most touchscreen interfaces are terrible (janky, frequent missed presses, laggy enough that it's often unclear whether a press has been missed or it's just being slow, confusing navigation—see those new McDonalds ordering kiosks for all of the above) so that doesn't seem to be a realistic option unless you put some kind of UX dictator with great taste in charge of the project.
All app developers should be required to sit and watch an expert user interact with a mainframe interface for at least 30 minutes before they're allowed to make arch decisions.
A commercial came on the TV in the waiting room for SAP, and this lady started cursing about what a piece of trash it was. I was really shocked. She was not someone I expected to even know what SAP was, but I guess she was an unfortunate user stuck with having to use it in an office somewhere.
But only IF you know the structure otherwise it's effectively unstructured. The issue with structured interfaces is that the barrier to entry is high and the discoverability of how to do things is low. That works if you are able to force people to use it but fails when you depend on people organically wanting to join.
Particularly when he clarified that keyboard-only doesn't just mean text-based, and it can be graphical and keyboard-only. I'm trying to imagine UI that are graphical and beautiful but works with keyboard only, and it actually could be a very interesting world if that were popular. It's not unlike games from older days where ways of input is limited and input is purpose-driven.
For sure, as you said, there's the discovery/exploratory aspect of using a software where GUI helps a lot. But there's definitely merit in what the author is saying.
Turns out that an interface like that is really hard to learn but also really fast once you do. Extruding a face along the normal is as easy as getting it selected somehow (which I do with the mouse, but there's plenty of keyboard based selection tools too) and hitting e, followed by z twice, and then either entering a distance on the keyboard or moving the mouse to move it a bit. Personally I love the interplay between keyboard and mouse: you can pick whichever method is most effective. For selecting specific things or moving stuff until it looks right you use the mouse, for selecting in bulk or moving stuff specific distances you use the keyboard. Or a combination. Whichever is convenient.
So I think if you can solve the discoverability problem of keyboard shortcuts it'd be a real productivity boost for power users.
Additionally I don't think it allows you to substitute a period for the numpad period key which is a rather important button in day-to-day blender usage. Of course you can re-map any key you like, but it'd be nice to have it set up right by default.
EDIT: and of course under a recent blender version (2.5+) there's the search box if you really don't want to use your mouse ;)
Also, I bought a separate mechanical 10key years ago and never looked back. It's a fantastic addition to any 40-60%.
https://blender.stackexchange.com/questions/124/how-to-emula...
My laptop has no number pad. I use it when I want a portable keyboard device, so an external keyboard would be irrelevant and unnecessary. Buying a device with a numpad built in would be a compromise that makes the built in keyboard even less useful, due to its non-centred location - in the unlikely event that everything else was identical.
My external keyboards have no numpad. They're ergonomic keyboards. One built for size, the other built uncompromisingly ergonomically. Ergonomic design actually speaks against number pads, since it means you have to extend you arm further to reach the mouse, and an uncompromised ergonomic design are wider than a regular keyboard since you want more separation between the two hands - so the number pad becomes an even bigger issue.
I've sometimes thought about buying an external numpad. But so far I neevr have.
Either move the mouse or the number pad to your left hand. I've left moused in the office for years (Yahoo! ergo team preached it when I joined), and it took a bit of getting used to, and limits your mouse choices, but it's actually pretty nice sometimes to be able to have one hand on the mouse and the other on the number pad. Mousing with one hand in the office and the other hand at home can help with overuse injuries too (although, using good techniques is much better for that). Of course, that still doesn't get you a numberpad on a reasonably sized laptops, but laptop keyboards are an ergo nightmare anyway, reaching over today's enormous touchpads is awful.
I don’t have this problem with my Kinesis Advantage, since the numpad is embedded in the main keyboard (using a mode shift/switch to access, which I have mapped to a foot pedal)
You can start in blender ploddingly wandering though the gui as you discover features and then streamline your workflow with the keyboard shortcuts as you go. As you do so, it feels a lot like leveling up in a particularly good game.
Very few pieces of software currently do this well these days. Its a breath of fresh air. Especially v2.8.
Imagine playing piano while having to take a hand off the keys and find a mouse during the song. It would be impossible to keep up. Keyboard only is speedy when learned.
This jives quite well for me. When I’m working keyboard is almost always better, but when I’m messing around with software I’m unfamiliar with and I haven't yet familiarised myself with the keys for it, I’ll poke around with a mouse. Once I figure out my workflow then I’ll probably use the keys more.
Unlike with a mouse, the keyboard never "fell off" the active menu tree requiring me to start over.
Unlike with a mouse, the keyboard couldn't hide things until I moused-over them. Recently I spent quite a while trying to find the zoom controls on a PDF because they were transparent until I randomly waved the mouse in a corner of the screen where there were no controls.
Mouse-driven discovery sucks, IMHO/IME.
You have to know that this is possible as a user, and app developers have to support it, and/or not override the default operating system handling.
This is, without a doubt, an area that we have regressed on. I remember very clearly that when I was first learning to program VB6, UI conventions were pretty standardized on Windows, and so you just did a lot of this stuff by default - you had a &File menu, and &New, &Load, &Save, and E&xit commands on it.
Some software still does this, but it is increasingly rare; in Chrome right now, the Alt key doesn't do anything, and I find that Electron apps have to go out of their way to mimic native conventions, as VS Code does.
So there's less software that follows keyboard-driven conventions, so fewer users know about those conventions, creating a vicious circle. Not to mention that the bulk of your average person's "computer" usage is poking at a touchscreen phone or tablet that has no physical keys at all, just godawful on-screen keyboards.
The user-hostile pattern of nested levels of mouse-maze menu, which collapse if you stray one pixel out of the required path, absolutely infuriates me. I can't imagine who thought this was a good idea or what sort of pointing device they used.
It's absolutely bad UI design, but I think it's become the rule rather than the exception. It's just "prettier", according to some jerk who never used a hotkey in his life.
> It's just "prettier", according to some jerk
Some would say "brave" and with jerk I think you're being too kind :-)
The key take-away was they spent a lot of money on a research project specifically about mouse vs. keyboard and found the precise opposite to be true! Surprising to say the least.
* Test subjects consistently report that keyboarding is faster than mousing. * The stopwatch consistently proves mousing is faster than keyboarding.
Without specifying how it was tested that's meaningless. For example I've read of a test where keyboard users were slower because they had to do a find/replace operation on a file manually, moving the cursor only with arrow keys. That's like saying using the mouse is slower after forcing mouse users to type text on a virtual keyboard.
I think in most scenarios both can be fast enough that the difference doesn't matter, provided there's proper support for both.
Supplying actual data is always useful.
Especially when it contradicts a common opinion ;)
Sometimes, articles that contradict a common opinion do so because they're simply dead wrong. This is one of those cases.
Did Apple do a study? Did it come to the conclusion that the mouse was faster? If so, why is it dead wrong?
(The study perhaps had a more narrow set of conclusions than presented in the article. Wouldn't surprise me.)
As a result, I'm very fast at navigating menus and switching tools in my program of choice (GIMP), because those are rapid keypresses rather than forced mouse clicks. It's just so much faster to click Alt+I > S, type a few numbers, hit Tab a couple times, and enter (well, Space usually), than it is to navigate with the mouse to the Scale Image drop-down, put my hands back on the keys to type numbers in, and then switch back to the mouse to hit OK. Ctrl+Q is much easier and faster than clicking the Selection Editor button. Alt+L > T > 9 is the quickest and simplest way of rotating the current layer - a more mouse-based UI might even refuse to give me a 90-degree option and instead force me into manual control. And of course, keeping a hand on the keyboard so it can quickly type a key or shift-key is much faster and more accurate than having to mouse over to the Toolbox to select a tool.
The non-graphical tablets with pens are really a different type of interaction, and one that supersedes keyboard + mouse for light graphics. Using one hand with the pen for pointer input + another hand for touch input is really powerful. Moving around, zooming, or rotating things on the screen is easier done with a hand. And a wheel menu (context or otherwise) really starts to shine with a pen.
I wish more software actually supported this. I currently own such a device (a Dell), and I'm searching for software that can utilize touch+pen input to full extent, but there aren't many programs that can.
I'm a Pom (British/Australian) living in Germany, so most keyboards in shared locations are unusable for me. Using other people's computers is a massive pain as my carefully-learned muscle memory is now actively stopping me from pushing the right keys.
I keep looking at Dvorak or a chord input device, but I know that if I get used to that then I'll have to carry one around with me always so that I can plug it in to whatever computer I'm using at that point. This doesn't seem practical.
I'd love another input option. One that was actually designed for humans to communicate fast with.
No, this is a myth that doesn't become more true just because many people perpetuate it without question.
QWERTY was designed to be as fast as possible for the first data entry jobs at the first companies that adopted typewriters and went through a couple iterations based on feedback of these first customers.
Is QWERTY optimal? No. But it's good enough that learning an alternative layout like Dvorak for months may cost you more of your lifetime than you'll ever get back by typing minimally faster(not to mention such a switch would be more costly with every single keyboard shortcut you've memorised so far).
Either way if you are waiting for a better alternative to become the standard so you don't need to carry your own keyboard you're going to need a lot of patience.
Hasn't that origin story been debunked?
e.g. https://www.smithsonianmag.com/arts-culture/fact-of-fiction-...
I don't want to know what my muscle memory would do if it got used to a Dvorak keyboard.
While not designed for best human use, it's not completely terrible.
Azerty vs Qwerty verus Qwertz is a different issue entirely.
The problems I have with keyboard are usually discoverability.
Windows is mostly mouse optional. You very rarely need a mouse, it's just way more common to use one. My memory is a bit off, but I know Win 95 was fine, I think it got a bit worse in XP (a lot more things that were hard to tab to), and 10 is ok, but not great.
I would like to murder the group of fools that managed to make a GUI for a touchscreen service program that was unusable without mouse and disabled the touch unit for some functionality, but that's neither here nor there.
I remember it was much more accurate to use than a mouse, and better interface than having toolbars all over the display.
http://www.brisk.org.uk/gt1212b/index.html
Crazy high res and absolute rather than relative which makes them very useful for some applications.
I have used the digitiser a few times and it seemed much more efficient than the mouse.
Also autocad has (or at least had, last time I looked at it years ago) a very prominent prompt where to input keyboard commands (in autolisp, no less!).
I have early signs. I often wonder if I will eventually be pushed into the grey disability area parent mentioned moreso from UI "progression" than from ET progression
I heavily use the keyboard, and for certain things (mostly apps I use daily) I'm highly proficient with it, barely touching the mouse at all. But once in a while I have to work with a spreadsheet, or edit an icon, or use some other piece of software I only use maybe a couple times per year. I simply don't remember shortcuts and I certainly can't justify spending the time to (re)learn enough to be more efficient keyboard-only that with a mouse, so I just rely on the mouse.
It's hard to imagine any keyboard-only (G)UI doing a better job at making usage discoverable than what can be done with a mouse-enabled one.
He doesn't. He has a whole section where he points out types of software that mice are great for, even with a picture. He then describes types of software where he thinks keyboard is better (i.e. linear stuff).
Touch screens at least will be better.
A touch screen and a keyboard based interface is the fastest generic UI. I've been using touch laptops only for years. The mouse dies hard though. It's closer to the keyboard and I'm already proficient with it. I wonder if this will be true for kids growing up now.
Touch it's ok with laptops, but when working on a desktop computer, with real monitors, some need another interface. I can't reach my screens from where I'm sitting comfortably, and if I could I'd place them further away.
When my beta testers learn about keyboard navigation in PhotoStructure, it's so much faster than a mouse, and it's mostly just cursor keys, so it's not hard to remember.
Scrolling, click to view replies, click to reply, click to retweet, click to like, click to view hashtag feed, click to view persons profile.
All of these things could be done efficiently with the keyboard (theres also no real reason to not still support mouse for the people who prefer it). I use the online checklist tool Checkvist.com and checklists are surprisingly similar to a linear feed like twitter. I use it almost exclusively with the keyboard, including editing, reordering, creating new items, tagging, colouring... Its super efficient and comfortable. There is no reason why you couldn’t have similar navigation and interactions on twitter. Personally, I find your outright dismissiveness of a keyboard-centric UI for twitter to be laughable shrug
Besides, you can create a keyboard centric UI without removing mouse support if you really want. It’s just that keyboard should be treated as a first class interaction method, instead of an almost tacked on accessibility feature.
It's no longer practical because of the initial learning curve. So I'm not arguing for going back. But it did have advantages beyond just being faster.
I contend my chief complaint with software, in any context, is that it makes me wait while it responds to my input, regardless of how I provided that input.
Modern software:
* Often cannot keep up with typing.
* Often cannot keep up with mouse actions to, e.g., show highlights on hover or indicate interactive elements because there are too many third-party scripts executing (or whatever).
* Takes too long to display results, again because of being too busy executing software components (trackers, ads, bloated client-side frameworks, whatever) that is not expressly related to my action. Also because server software tends to be written using inefficient languages, platforms, and frameworks that theoretically optimize for developer efficiency (arguable) at the expense of user experience. Every time I interact with a web site that is slow to respond to network requests, I am usually right to guess the server is PHP, Ruby, or similar.
* Infantilizes the user by providing a too-narrow set of actions (the curse of "mobile first"), narrowing the functionality and in many cases causing things that should be relatively easy to require lots of steps. This may be where he was going with the remainder of his thread, but I think it went off the rails, as you said.
I use the keyboars a lot, but I keep my mouse. Why ? Cognitive load, that's why. I can remember all the shortcuts for all the apps. But I don't want to. Remembering things has a cost. Switching context has a cost. I have a limited brain budget and want to balance it between execution efficienty and solving the problem I'm working on.
Mice work for a lot of us in a lot of circumstances, but there are UI options beside keyboard only vs. mouse
If you use the same digital pointer with a drawing tablet that maps its surface to the screen, then you can set its absolute position on the screen. You now have physical feedback about your pointer's position, as well as visual
I've done a lot of programming where my productivity was input-constrained, so I know that that such jobs do exist.
I much prefer jobs where my productivity is idea-constrained. The final code tends to be a lot more interesting, the process of creating it a lot more joyful, and the final software artifact a lot more useful.
As a bonus, I tend to be paid at least an order of magnitude more for idea-constrained code.
Tip for more productive mousing: Disable "mouse acceleration" or "enhance pointer precision", it makes it harder for your body to adapt to the mouse. I can move it to where I look at the screen in an instant with almost no adjustment needed at the end since when that if off world space and screen space aligns. Of course I learned that skill to select and order units quickly in RTS games, but it works just as well for selecting and manipulating code.
I haven't used a mouse to drive coding since a C++ course in high school almost 20 years ago. The only thing I use it for is selecting and copying code.
For navigating and writing code it's all emacs, tmux, terminals and unix tools.
A touchscreen is a nightmare for manipulating small text.
> For navigating and writing code it's all emacs, tmux, terminals and unix tools.
Well, if you never leave emacs/vim and related workflows, you never know anything else.
For writing code, yes, keyboard is best. For navigating, debugging and other things a TUI does not cut it. And I spend a lot more time reading and thinking about code than actually writing it.
A particular example that stands out in the Linux world is GDB's CLI interface. It sucks. Its TUI is better, but still bad compared to a good GUI.
as an emacs user, I find it extremely painful watching my colleagues clicking around in eclipse to navigate the code base[1]. It feels just so inefficient and slow.
[1] I assume eclipse actually has keyboard shortcuts, but they do not seem to be used by my eclipse-using colleagues.
Otherwise we would be playing RTS games with the keyboard. (I am a competitive RTS player, so I can almost instantly hit any point in the screen, which helps; a good mouse also helps a lot).
Pure TUI is not optimal, but it still beats available mouse-based interface. At the very least, moving around the code is much faster with incremental search than with scrolling and spotting.
I'm still waiting for a code reading program that supports drawing on top of the code and that would otherwise behave like an infinite desk with (searchable, linkable, annotateable) code printouts on it.
A GUI does not necessarily imply scrolling to find something.
The only real advantage to a keyboard only interface is the ability to automate steps, but I feel if you feel a need to automate your code writing then it would be better to refactor the code to require less boilerplate.
https://en.wikipedia.org/wiki/LabVIEW
addendum: It also allows you to create visual spaghetti code with the data pipes, which is much closer to real spaghetti than the text-based version.
Do you happen to have any insight as to what kinds of specialties allow for these kinds of lucrative short term opportunities?
My biggest problem with my erstwhile career was that the only good opportunities I've ever heard of were only full time.
Typically the lucrative work I'm talking about happens when I just negotiate a flat fee and it doesn't take me that long. Companies often like that because it limits their risk compared to my hourly rate.
But honestly most consulting in most fields should have this type of negotiating opportunity. As long as it's not a field with some sort of existing convention of hiring lots of "independent contractors" that probably should be employees.
As for time in... It takes a lot for maybe a year or so to get enough reputation that you aren't hustling for clients. But now they call me and I decide whether or not I can take them. I get a lot of last minute rush gigs which are usually the best money if I want to take them. Often I don't, and I throw out a "fuck you go away" number and then they jump at it anyway.
Of course I realize the mouse has its uses.
Since I recently started using Linux for some things, I've noticed a difference in online commentary about how to use it. In Windows, the instructions for installing a software app are many pages of pictures, with circles and arrows, and a paragraph of text for each one. When the OS changes some of its menus, the documentation is obsolete and you have to guess what you're actually supposed to do.
Instructions for Linux are a few lines of text that you copy into your terminal. Now more and more instructions for Windows are going that way: Press Windows-cmd, enter some text, press return, done.
All smartphones are touchscreen now, which is a terrible form of input for the vast majority of use cases. The blind can't feel it, a sighted person can't type without looking, it doesn't work with gloves, repairs are difficult and expensive, and typing requires complex software for it to not be slow and painful. Touch screens are not meant for 100% of user input, yet that's what we're left with.
The mouse is just a poor form of touchscreen. Hopefully we can convince industry that the user's ease of use is more important than an inconvenient "standard".
It always confounds me when people assert that the number-one desirable feature in all user experience is velocity of input. As if there's nothing to be thought about, much less discovered. Just data to be entered. That may be true in certain narrow segments of interfaces, like POS software and development environments, but to pretend that all human/computer interaction fits that mold is to be willfully ignorant of the reality of personal computing.
Edit: It's been pointed out that towards the end he does acknowledge some valid use-cases for mice, but he still drastically oversimplifies the space of GUI use-cases and ignores some of the key benefits of mouse-based interaction.