Almost everything on computers is perceptually slower than it was in 1983 (2017)

Certainly, a lot of people use Google Maps for turn-by-turn directions. This means that they interact with the actual UI and visible map tiles once, at the beginning of the trip; and then from there on are given timely voice directions every few minutes, which they can maybe contextualize by looking at the map on the screen. Even if you count the time they spend hearing those directions as time spent “interacting with the UI” of Google Maps, it adds up to fewer man-hours than you’d think.

Meanwhile, I believe that there are a much larger number of collective man-hours spent staring at the Google Maps UI—actually poking and prodding at it—by pedestrians navigating unfamiliar cities, or unfamiliar places in their city. Tourists, people with new jobs, people told to meet their friends for dinner somewhere; etc.

And the Google Maps UI (especially the map tiles themselves) is horrible for pedestrians. Half the time you can’t even figure out the name of the road/street you’re standing on; names of arterial roads (like main streets that happen to also be technically highways) only show up at low zoom levels, while names of small streets barely show up at the highest zoom level. And asking Maps to give you a pedestrian or public-transit route to a particular place doesn’t fix this, because GMaps just doesn’t understand what can or cannot be walked through. It thinks public parks are solid obstacles (no roads!) while happily routing you along maintenance paths for subway systems, rail lines, and even airfields. (One time it guided me to walk down the side of an above-grade freeway, outside the concrete side-barriers, squeezing between the barriers and a forest.) And, of course, it still assumes the “entrances” to an address are the car entrances—so, for example, it routes pedestrians to the back alleys behind apartment buildings (because that’s more often where the parking-garage entrance is) rather than the front, where the door is. I don’t live here, Google; I can’t even get into the garage!

The thing is, these are such distinct workflows that there’s no reason for Google Maps to be optimizing for one use-case over the other in the first place. It’s immediately apparent which one you’re attempting by your actions upon opening the app; so why not just offer one experience (and set of map tiles) for people attempting car navigation, and a different experience (and set of map tiles) for people attempting pedestrian wayfinding?

Or, someone could just come out with a wayfinding app for pedestrians that does its own map rendering. There’s already a Transit app with a UI (and map tiles) optimized for transit-takers; why not a Walkthere app with a UI (and map tiles) optimized for pedestrians? :)

(And all the comments about how much faster computers are today: I interpreted the article to be talking about the ease of UI, in other words how fast the interface lets you do things, not how fast the computer does things.)

I have a private Rails app I've used as a freelancer for 7-8 years for time tracking, invoicing, expenses, and financial reports, and I've tried to make it very keyboard-focused, so that I can enter info without clicking around. I've always wanted to polish it enough to share and charge money for, and I've thought a nice niche would be to double down on the "keyboard productivity" theme. But making that work well in a browser is tricky.

Do you mostly rely on browser-native functionality for keyboard nav/input? That's how it is today. It's fine for me, but it's not really "enough" I think. There are lots of other navigation moves I wish had keyboard shortcuts. But a lot of taste is required here. Usually when people override browser behavior it makes things worse (e.g. scrolling). But there are still things that would be actual improvements.

So a couple years ago I rewrote the Invoices section in React+Redux, hoping that would make it easier to do some custom UI behavior. It made a couple small things better, but it's a lot more code, and it breaks some things the browser used to give me for free. For example if you add a new invoice and see it at the bottom of the list, then you click to a non-React part of the site, then click Back, the new invoice disappears from the list! I'm not even sure how to fix that, unless I want to add a spinner and Ajax call on page load. (Right now I pass the initial state as JSON in the rendered HTML.) Maybe I could use local storage, but then somehow when you click Back I have to decide whether to trust local storage or make an Ajax call. . . .

Anyway, rather than complaining about the article, I'd be more interested in a conversation about how to build webapps with a keyboard focus, so that you can complete entire tasks without touching the mouse. What native browser features would you leverage? What frontend tech would help you? Can you imagine "standard" patterns you could encode in a JS lib, both for DRY code and for a more predictable UI? A "Bootstrap for keyboard-first webapps" would be really cool. In fact Bootstrap already does a lot for accessibility.