When it comes to navigating (except public transit), hiking, and route building, Organic Maps[1] is very good. OSM data and offline-first is the way forward for detailed and _fast_ map experience.
For cycling route building I have to mention BRouter[2], which allows you to write a custom cost function that is used to tweak your route preferences.
A good WYSIWYG editor will run circles around the fastest text editor. Even if WYSIWYG is a bit slower to open.
It would be preferable for software to be more focused and faster over time, but that doesn't attract people to it.
How is that even possible, especially with modern hardware? Like you'd almost have to build the file explorer around like a sqlite-based message queue with a 1500ms poll interval to get performance characteristics like this. Absolutely insane feats of architecture astronautism are no doubt required for this to happen.
I wonder what OP's thinks of IDEs like VSCode. Would they see it as heavy and not great because it's Electron-based? But I find IDEs convenient.
Well, with the encumbrance of it living in a terminal window, but I also live in the terminal window even on MacOS, so its a feature not a bug.
Point is, I wouldn't have this to say about it if iStatMenu had just been a little more discrete about its loading times ..
Esp. known from Microsoft, Adobe, Google. Should be added to the Antipatterns repo
If it is fast because it is optimized, then that does not align with correctness, because optimizing something that works only adds risk.
The interface without animations feels snappier even if sometimes it takes a second to load. I disable any and all animations in software that I can - particularly in Android (via developer settings) and Linux (i3+vim vs something like KDE+VScode).
I was wondering how bad a sign it was when the decline in performance between Windows 95 and Windows 98 was detectable in many ways, but nobody was complaining because it was not always noticeable on PCs that were 3 years newer. You had to figure Microsoft developers had way better PCs than that, and didn't have any clue at all.
Turns out my suspicions were correct, it was the insidiously ignored ramp-up to exponential amounts of sluggishness as time marches on.
You know, like a snail without a shell :(
In that sense, when a terminal (running on a desktop environment) in Linux is faster than Windows Explorer, it's a shame. When a big file explorer like Dolphin drives circles around native file explorer of Windows, that's a big ole embarrassment.
If you want to do foo. You don't need framework bar to load baz or call home to qux.
That's all added complexity that isn't inherent to the task.
So we aren't talking about not doing bar. We are talking about not doing all the other things that aren't for the benefit of the user.
The fun part is that when your employer _does_ care about software optimization, few people are actually good at it and your skills are more exclusive :-)
I regularly use a website in which a submit button does not change state in any way. It is indistinguishable from the click having gone to /dev/null. And the completion of the action takes a copule of seconds.
It's literally, "no response ... few seconds ... oh, done!"
If the button simply responded in the usual way, like 3d poppin in and out effect, it would be better. The UI can change state also to show some "wait ..." text.
These are examples of animations, just not progressive/persistent.
It felt like I was racing. Type the whole message before the screen updates? Check.
I miss AOL sometimes.
Even when that software is widely used so the few milliseconds add up to thousands of hours in collective time savings. 'We don't pay for user's time, only your's', is the attitude. Again 'irrational'.
"The data is better than Google maps, it just needs a better routing algorithm" should be catnip to a certain class of OS dev. If it's really true, I'll take a crack at it myself!
I love fast software. That is, software speedy both in function and interface. Software with minimal to no lag between wanting to activate or manipulate something and the thing happening. Lightness.
Software that’s speedy usually means it’s focused. Like a good tool, it often means that it’s simple, but that’s not necessarily true. Speed in software is probably the most valuable, least valued asset. To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance. Fastness in software is like great margins in a book — makes you smile without necessarily knowing why.
One of my most used, most speedy pieces of software is nvALT.1 It’s an oddly named, very bland application. Just a database of plain text files with a plain text editor bolted on. But it’s fast. The fastest piece of text cataloging software I’ve used. It opens instantly and produces results instantly. My nvALT database is full of ten years of notes. Open it and your cursor is already in the search field. It is keyboard friendly software: If you’re ever not in the search field, just hit ESC, and you’ll land there. Type a few letters and all the notes with those letters appear. It is the best instantiation of an off-board brain I have. Any piece of text with value in my life gets dumped into nvALT.
nvALT syncs with Simplenote. This is handy because nvALT is macOS only. So you can use the Simplenote iOS app to keep your extra brain nearby on the go. Simplenote also has a macOS app. You may think: Why not use the Simplenote desktop application? Because — it’s not quite as fast. We’re talking milliseconds, but it’s enough that you feel the difference. It’s the difference between the $1000 Japanese garden shears and the $150 garden shears. They both cut just fine, but if you work in the garden all day, you will (probably?) feel the difference.
I write mainly in Ulysses. Even now, I’m writing this in Ulysses. Ulysses works well for organizing large-ish bodies of writing. The organization is mostly of why I use it.2 But it can slow down. Ulysses has slowed down on a number of occasions. If I have a 5,000 word article and type towards the top of it, it sometimes can’t keep up with my typing. It re-renders the whole thing with each keystroke. This drives me bonkers. But the organization and simplicity of the application outweigh this sometimes-slowness. Still, the slowness feels indicative of unseen rot on the inside of the machine. The slowness is like an off smell. I don’t trust the application as much as I would if it didn’t slow down on such a small text file. 5,000 words is nothing. Faith is tested: It makes me wonder how good the sync capabilities are. It makes me wonder if the application will lose data.3
Speed and reliability are often intuited hand-in-hand. Speed can be a good proxy for general engineering quality. If an application slows down on simple tasks, then it can mean the engineers aren’t obsessive detail sticklers. Not always, but it can mean disastrous other issues lurk. I want all my craftspeople to stickle. I don’t think Ulysses is badly made, but I am less confident in it than if it handled input and interface speed with more grace. Speed would make me trust it more.
As a counter example, Sublime Text never slows down for me. I can throw a 50,000 line file at it and it zips along. You may wonder why I don’t write in Sublime Text (as I sometimes wonder). And the answer is: It’s just not quite nice enough for full composition. Sublime’s typography, spell check, file organization (no keywords, inability to organize order willy-nilly, etc) — just not as refined. Sublime Text is optimized for code, not words. Whereas Ulysses is word-focused. The difference is subtle but meaningful. That said, Sublime Text has — in my experience — only gotten faster. I love software that does this: Software that unbloats over time. This should be the goal of all software. The longer it’s around, the more elegant it should become. Smooth over like a river stone. I have full trust in the engineering of Sublime Text because I’ve used it for over a decade, but also because it always feels like a fast, focused tool (even though it’s actually very complicated) and has only become faster the longer I’ve used it.
Adobe Lightroom does not feel like a fast, focused tool. Nor does Photoshop. At one point, they did. It’s why I chose them. Photoshop in the 90s was very fast. I don’t think I’m invoking some halcyon fantasy. It was truly a sparky piece of code. Similarly, I started using Lightroom around 2007 because it was so much faster than Apple’s Aperture. But Aperture is gone and Lightroom has not smoothed out over the years. Lightroom is a gangly blob, with lots of dull, slow edges. Why can’t it get faster? This is a mystery for the ages, but I suspect it’s because of a) feature bloat, and b) core engineering sub-optimized for so much feature bloat. Is this why Adobe released Lightroom CC? Probably. It’s sometimes easier to make a new program than to fix the old one.
Photoshop is now a turkey. Just opening the new file dialog in Photoshop takes seconds. Seconds to create a new, blank file. In 2019. If you press Cmd-Opt-Shift-W to export an image, it takes 3-5 seconds to load that screen. (And if you accidentally press Cmd-Opt-w, it closes all your windows.) Slower and slower with each release. It’s why I spent money on Affinity Photo. Simply for speed. That’s it. I still pay for a Creative Cloud license (for Lightroom Classic and InDesign mainly), but I happily paid for Affinity — a vote with dollars — because it’s so fast, and especially fast at exporting files for web consumption. I sigh — actually sigh — whenever I have to open Photoshop.
One could argue that design apps like Sketch have grown in popularity because of speed. Sketch was so much faster, simpler, and more UX design focused than most anything Adobe offered when it was released. It had reliability issues, but we were willing to overlook them because it was, once again, just fun to use. In this way, speed can be tremendous commercial asset. When it comes to software that people live in all day long, a 3% increase in fun should not be dismissed.
Figma is another design tool in the vein of Sketch or Illustrator. In spite of being browser based, Figma is so fast that I laugh from delight whenever I use it. It feels precisely as fast as everything should be on a contemporary computer — which is, extremely. It feels loved. I know the engineering and design teams behind it and I know it is loved. It is built from a position of craft. Close-to-the-metal craft. And you feel it. Not only in speed as speed, but speed as intuitiveness. That is: The tools work more sensibly than the same tools in, say, Illustrator. The pen tool for example. In Figma the pen tool operates from a position of rationality. In this sense, “speed” manifests not only in work per computer cycle, but work per user cycle.
Google Maps is dying a tragic, public death by a thousand cuts of slowness. Google has added animations all over Google Maps. They are nice individually, but in aggregate they are very slow. Google Maps used to be a fast, focused tool. It’s now quite bovine. If you push the wrong button, it moos. Clunky, you could say. Overly complex. Unnecessarily layered. Perhaps it’s trying to do too much? To back out of certain modes — directions, for example — a user may have to tap four or five different areas and endure as many slow animations.
We endure because Google Maps, otherwise, is a treasure trove of data about the world around us. It’s a downright marvel of information, and a marvel of an application. More and more, however, that information is being hidden behind multi-UI variants,4 and a UI that seems to vary week-by-week. My outside intuition is that this is a management issue perhaps endemic to Google itself, not an engineering issue.
Google Maps has gotten so slow, that I did the unthinkable: I reinstalled Apple Maps on my iPhone. Apple Maps in contrast, today, is downright zippy and responsive. The data still isn’t as good as Google Maps, but this a good example of where slowness pushed me to reinstall an app I had all but written off. I’ll give Apple Maps more of a chance going forward.
For the absolute nadir of software clunkery, see exhibit a) iTunes. So slow, so laden, so burdened with being more than it ever was supposed to be that Apple decided to just throw it in the toilet, reconstitute it as a series of individual applications. Which is most certainly the best choice.
It should be said, though, that Apple makes lots of fine software. Keynote is perhaps one of the finest pieces of software on macOS. It is a paragon of power wrapped in a simple interface. You may raise issue that it was simpler in a previous iteration, but this current version feels like it strikes a nice balance between modes, power, and general simplicity. It is fast and intuitive. One of my favorite sub-tools? The Instant Alpha tool. Pure joy. Works well for 90% of the intended use cases, and is precisely the kind of tool you wouldn’t know you want, and wouldn’t expect to exist, but appears right when you need it. Generally though: Keynote is fast and feels well-made.
But why is slow bad? Fast software is not always good software, but slow software is rarely able to rise to greatness. Fast software gives the user a chance to “meld” with its toolset. That is, not break flow. When the nerds upon Nerd Hill fight to the death over Vi and Emacs, it’s partly because they have such a strong affinity for the flow of the application and its meldiness. They have invested. The Tool Is Good, so they feel. Not breaking flow is an axiom of great tools.
A typewriter is an excellent tool because, even though it’s slow in a relative sense, every aspect of the machine itself operates as quickly as the user can move. It is focused. There are no delays when making a new line or slamming a key into the paper. Yes, you have to put a new sheet of paper into the machine at the end of a page, but that action becomes part of the flow of using the machine, and the accumulation of paper a visual indication of work completed. It is not wasted work. There are no fundamental mechanical delays in using the machine. The best software inches ever closer to the physical directness of something like a typewriter. (The machine may break down, of course, ribbons need to be changed — but this is maintenance and separate from the use of the tool. I’d be delighted to “maintain” Photoshop if it would lighten it up.)
Speed manifests in the language — the literal words — of software, too. In recent years, macOS dialogs for closing an unsaved file have shifted from “Don’t Save, Cancel, Save” to “Delete, Cancel, Save.” This is only my opinion, but “Delete, Cancel, Save” makes less sense than “Don’t Save, Cancel, Save.” The option to “delete” implies something as having once been saved. Did I save this and forget I saved it? Or did it auto-save? I don’t know. Shake it any which way you like, I am still tripped up seeing this dialog when I close an unsaved file. It slows me down. Pressing delete feels violent. Delete. So final. I second guess — maybe I don’t want to delete? Maybe I do want to save. When, no, I just wanted to “Don’t Save.”
I am using the iPadOS 13 beta on my iPad. It has one new interface component in particular that is extremely fast and delightful: the so-called “Slide Over.” Just swipe from the right and — sloop — an app float-over appears. The floating app is a mini-version of a big app and appears as quickly as you swipe. It feels satisfying. You move your finger and — instantly — there is the tiny app under your finger. Swipe back and it is gone. No “redrawing” of the screen. At the bottom of the tiny app is a small bar. Swipe the bar and the mini apps cycle. They cycle with a fast, beautiful animation that indicates where you’ve been and where you’re going. It’s an animation with purpose and that purpose is context iteration. It feels tactile. Excellent touch interfaces feel tactile. The best “touch interfaces,” in my opinion, are actual buttons, things with physicality, haptics. But on a screen, to feel tactile is to move without latency.
From a speed and user experience point of view, I believe this Slide Over to be vastly superior to the screen-split on the iPad. The screen-split is slow. You have tap, hold, drag, wait for the screen to “redraw” itself, for the apps to shimmy-blink into their new sizes. The screen-split feels like it controverts the code under the hood. Contrast this with the Slide Over. The Slide Over feels like a natural extension of the iPad environment. It is quickly and reliably invokable. It is predictable. It feels like its code is moving in natural synchronicity with the disposition of the device. And with a speed commensurate to the power lurking under the glass. The screen-split could work, but the foundation code probably needs to be rewritten. Ideally it would be as smooth and fast as the Slide Over. It would be like cutting a wayward branch on your plum tree with $1,000 shears.
I can go on and on. But let’s end with an example of a piece of iOS software that is pure craft: Things. Things on iPad and iPhone is one of the most tactile, fast-as-you-can-move apps around. Each animation is purposeful. Mainly, it is fun. It’s a fun app to be in. To put stuff into, to rearrange. It is old. Things has been around for over ten years. I was glad to open it ten years ago, and I am glad to open it today.5
It feels — intuitively — that software (beyond core functionality) should aim for speed. Speed as a proxy for efficiency. If a piece of software is becoming taurine-esque, unwieldy, then perhaps it shouldn’t be a single piece of software. Ultimately, to be fast is to be light. And to be light is to lessen the burden on someone or some task. This is the ultimate goal: For our pocket supercomputers to lessen burdens, not increase them. For our mega-powered laptops to enable a kind of fluency — not battle, or struggle — of creation.
All that said: It’s easy to write an essay about fast software. It’s difficult to make fast software. But when it’s made, we’re all grateful.
It looks like nvALT is finally being updated! nv … ULTRA? ↩︎
When dealing with large bodies of text across many files, organization is everything. I love that Ulysses uses normal folders but keeps track of how you want the files ordered. Unlike, say. Scrivener, which turns your writing project into a giant, proprietary database. So 90% of why I use Ulysses is for this organizational freedom. 5% is for the editor’s simplicity. 5% for the syncing between devices. ↩︎
Ulysses responded on Twitter: “Yes, the adaptive background color in macOS causes a severe performance drop in longer sheets. We already filed a bug report with Apple and hope they fix it in a future OS update. Workarounds are: Use Light Mode or another theme than D14 or split your sheets.” ↩︎
Ex: If you tapped on a station in Tokyo, the button to get directions to that station was, at one point, in the top right corner of the screen, a place the directions buttons never otherwise appears ↩︎
The only other app I’ve found to achieve this same level of tactility and craft was Facebook’s bizarre but delightful Paper experiment, spearheaded by craftsman extraordinaire, Mike Matas. And before paper, Our Choice, also from Mike and co. ↩︎