Craig Mod reports in Roden o28:
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.
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 cmod-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 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.
2 comments:
Choosing the appropriate goal: How do I start a crypto exchange business? The first stage is to develop a plan for where you want to go in life. This is crucial to ensure that your bitcoin exchange is set up and operates properly. The general license and registration approval process may be finished.
Post a Comment