I only think about my iPhone Air being, well, an Air when I pick up someone else’s phone. Like picking up a glass of water that you expect to be half-empty but is actually full and it, momentarily, feels like the laws of gravity broke (or, more often, turns out to be nearly empty and you nearly propel the remaining liquid into your face), our brains estimate what force an object requires and very quickly reset to our new normal.
The iPhone Air, very quickly, just becomes normal, the way a phone should feel.
Then you go pick up an iPhone Pro and it feels surprisingly heavy. An iPhone Pro Max doesn’t feel like it should be a phone at all. The thickness, the density, the weight distribution all feel odd, at first.
The iPhone Air feels like the future, in the same way the iPhone X did. And maybe it’s an aberration, a mistaken fork in the road that’ll quietly die off, just as the iPhone X rounded edges gave way to blockier iPhone designs that felt thicker even while they were technically thinner.
But I’d bet the iPhone Air’s feel is here to stay, regardless if the Air sticks around as a category. It’s what the folding iPhone will feel like unfurled. And it feels rather incredible on its own, too.
The accidental budget iPhone
I didn’t intend to upgrade to the iPhone Air.
But it was tempting. You pick it up in the store and it feels different, nicer, a clear evolution over the iPhone style we’ve learned to recognize by touch. There were downsides, sure—a single camera, worse battery life—yet maybe that was the excuse I needed to use my real camera more.
The list pricing at $999, exactly what the iPhone X retailed for, made that a stretch, though, as did local market pricing of around $1,200 for the iPhone Air with tax and duties included.
The market seemed to agree, as it was discounted quicker than I ever recall seeing for a new iPhone. Official resellers in my market had the iPhone Air listed for $875, tax included, by December 2025 (and a cursory look around resellers globally shows prices in that range today). That pricing felt like a sweet spot to me; a reasonable bump over the standard iPhone pricing (what with its two cameras and better battery proves a better in specs phone, if not in look and feel) and a significant savings over the iPhone Pro.
Goodbye to my well-used iPhone 13 Pro with its somehow-blued patina, and an eSim swap later I was in business with a phone that, for the first time in several iPhone upgrades, felt like a good value to me (and perhaps increasingly so, if the ram shortage hits base iPhone prices).
The iPhone Air feels nice, and is durable.
For the first time in a while, I had an iPhone that felt like it disappeared in my pocket. It feels at first impossibly thin, a smooth piece of nicely balanced glass and titanium. It feels like the future, before your brain rewires and it feels normal and everything else feels heavy and dated in comparison.
iOS 26 and its transparency somehow, to me, felt designed for this phone. The design struck me as somewhat cramped on the iPhone 13; here, it feels natural. Perhaps that was the new device magic speaking at first, but I’ve long had a feeling that Apple both designs in public ahead of time (with hints of future features showing up in niche products first) and designs new operating systems with a specific device in mind, and iOS 26 felt designed for the iPhone Air. Perhaps.
The action and camera buttons were new to me, coming from the iPhone 13. The latter I use for opening the camera, but rarely as a shutter; it’s too easy to shake the phone when doing so, more so than when using volume buttons as a shutter. The former I quickly mapped to open the flashlight, and unreasonably love that. We taught sand how to think, so we could have a flashlight in our pockets activated by a clicky titanium button.
The iPhone Air also feels best without a case. Yes, that’s living dangerously, but you get a thin phone for its thinness, and I’ve already gone caseless for years.
My iPhone Air has taken at least three falls: Once when I was disembarking a ferry, a couple others when it slipped out of my hand. The black titanium frame now has two scuffs on the paint as a result, something I bet it wouldn’t have if the edge was brushed raw titanium. The screen has a few micro scratches, fewer than my iPhone 13 but difficult to directly compare.
One odd thing has surprised me the most: Dust gets stuck in the top speaker where I never had that problem with previous iPhones. It’s tough to get out, too, and when I used the edge of a piece of paper to nudge it out, it got stuck in the gap between the frame and screen. I’ve found that using a piece of tape to lift dust out of the speaker works the best. And speaking of the speaker: It’s fine. I don’t listen to audio through my iPhone speaker all that much, but on the rare occasion I stream a documentary before falling to sleep, it’s fine—not at all enough worse to notice, as no phone’s speaker sounds that great.
The iPhone Air’s single camera is fine, but I do miss the wide lens.
My Apple Photos library shows 17,007 photos taken on my iPhone 13 Pro over 4 years.
Of those, 9% were taken with the zoom lens, 17% with the wide lens, 22% with the the front-facing camera (nearly all group selfies, I promise), and 51% with the standard lens.
You can always zoom with your feet, and back up to get more of the subject in the frame. The iPhone Air’s single rear camera wouldn’t be that much of a downgrade, I reasoned. And that’s as someone who unreasonably loves wide lenses, enough that I had a 10-22mm lens for my Canon DSLR, then a decade later replaced it with a 14mm lens on a Sony mirrorless camera. That would cover my love of wide photography; the iPhone Air’s standard lens would suffice.
And it does. It’s good enough. But not great.
The iPhone wide lens focuses closer than the standard lens. Which is annoying, at times, when your photo comes out darker or grainier than expected. Then you switch to the iPhone Air and find yourself pulling your phone back to scan QR codes and receipts that, previously, felt more natural to snap. That, and the wide lens adds extra data to your camera app, so you can see around what you’re framing, even if you’re snapping the final photo with the standard lens.
To me, as someone who was willing to pay extra to buy a wide lens, I’d often wondered why Apple would put the wide lens in the cheaper iPhones. I thought the zoom would be something most people would want, and the wide lens a more sensible premium upgrade. Turns out, the wide lens has more practical uses, and the zoom is what would tempt most people to upgrade, and that plays better into Apple’s goals.
Expect the foldable iPhone—and the next iPhone Air, if there is one—to ship with a wide lens if there’s space for two.
The iPhone Air’s battery life is ok. Just ok.
The iPhone Air’s battery life is ok for me on most work days. I set it to charge to 90% every night, and typically run it down to 20% or so by night.
On heavy usage days, though, it does require a top-up charge. That, or low-power mode which conserves battery more than I’d expected. On a recent trip, with heavy Maps, Translate, and camera usage, I was using a power bank by lunch. So the next day I let it charge full and turn on low power mode before setting out for the day. Lo and behold, I got through a whole day of travel with moderate phone usage without a problem. I was shooting most photos on my real camera, which helps, but still was impressed at how much the low power mode stretches battery life.
You do feel the phone’s bump get warm if you’re shooting video or doing anything more computationally intensive.
If you’re shooting video all day, are regularly gaming, or otherwise are a heavy phone user, the iPhone Air’s battery is likely not sufficient. But for someone with (checks stats) around 3.5 hr of average phone usage a day, it’s perfect—you’ll just want a power bank if you’re traveling.
Would I buy the iPhone Air again? Absolutely.
Everything requires tradeoffs, and the iPhone Air puts those tradeoffs in stark relief. The just-an-iPhone iPhone is the affordable option, with the expected tradeoffs in build quality, cameras, and processing power. The iPhone Pro is the premium option, with better processing, cameras, and battery life at the expense of weight and money (though, with the iPhone 18 series, with not as much of a design upgrade as usual with the switch back to aluminum).
The iPhone Air sits in an uneasy middle. It’s nicer in some ways than the iPhone Pro: Thinner, lighter, titanium. It’s the quintessential iPhone, an aspirational device of sorts. Yet thinness requires tradeoffs of a smaller battery, fewer cameras, and a device that runs hot.
The iPhone Air is great if your iPhone is a phone, not the only device you’re using throughout the day. It’s a phone that’ll make every other phone feel heavy and dated.
And I suspect that, a decade from now, the iPhone will look more like the iPhone Air than the current iPhone Pro.
What goes into a newsletter? What makes them stick?
The newspaper process—or at least the glamorized, twentieth-century version of it, with words scribbled in notebooks, punched out on keyboards, presses stopped and headlines swapped—has been immortalized on the silver screen enough that most can recognize its broad structures, its clichés. Same for the book publishing process, with agents, publishers, and advances, book tours and paperbacks, translations if you're lucky and options if you're exceptionally so.
Newsletters, not so much.
And so, my Pith & Pip partner Ryan Farley and I set out to tell the story of newsletters, for Buttondown. What gets people started writing them, and keeps them going? Why newsletters, of all things one could create? Where do they find inspiration, and what insights did they have after writing millions of words over dozens of years?
After hours of interview calls, of refining quotes and pulling together a narrative, we wrote a book that I’m pretty proud of. It’s a short book, just four chapters long, but packed with details about newsletters from so many great writers including Clive Thompson, Cassidy Williams, Jane Friedman, Allen Pike, Chatwan Mongkol, Mark Hurst, and Dave Pell.
Because we found out, there's no secret to newsletters other than starting. Start. Keep sending. Everything else will fall into place along the way.
Here’s The Newsletter Book, free to read online or download in PDF and ePub formats. Happy reading!
The company behind the Centurion Club and the Black Card, best known for a concierge service and charge cards without limits, and for turning the card in your wallet into a lifestyle choice, that company started out without a product or almost any capital to speak of.
It started, instead, with an idea.
It was the 1840’s, the railroad was shrinking the travel time between cities from days to hours, and suddenly it was possible to send stuff from one place to another, fast. That is, if you had time to take the train yourself and hand-deliver the parcel, or enough trust to hand it to a stranger on the platform heading to the same destination.
Therein lay an idea, the idea that turned into American Express...
One of the things I enjoy most about storytelling for startups is digging into the history of how their sector of tech came to be. Case in point: Email, with Buttondown. The more I dig into email with the Buttondown team, the more interesting bits of history I found about how email came to be.
This time, I stumbled in bits and pieces into an alternate history of email, one dictated by postal services and telecommunications companies, one that promised to be far better than the email we ended up with. X.400, it was called, and it stumbled before it ever left the gate. Instead, the simpler email went global, and left us with one of the last few remaining decentralized communications tools that has survived longer than the web itself.
And yet X.400 itself found a niche, and is still used today by air traffic controllers among others.
Here's the X.400 story, and how a complicated idea lost to the simple email transfer protocol.
For the first time in 54 years, humans are flying by the moon. And perhaps for the first time ever, email may be sent that far into space, as Artemis II rounds the dark side of the moon and starts heading back home—as email itself is only 55 years old.
But email has been sent to space before, starting with a Space Shuttle flight in 1991 that sent the first email from space on a Macintosh Portable.
Here's the story of the first email in space, and how data still works in space today, on the Buttondown blog.
“Software is dead,” declared Salesforce’s original marketing at the turn of the century. It was “the end of software,” software as we knew it anyhow, as the hopes and dreams of a generation went up in dot com bubble smoke. Maybe they were right; maybe software was dead.
Not that we’d quit telling computers how to work, as Wikipedia defines software. The death of software was the death of “the concept that you buy the software, that you own it, that you manage it,” Marc Benioff told tech reporter Steven Levy five years after Salesforce’s launch. Along with that, Salesforce heralded the death of files. All your business data was entries in a database table, presented through Salesforce’s UI. Files and backups were a thing of the past, along with boxed software and service pack upgrades.
A thousand kilometers away in Redmond, Microsoft near-monopoly was built on the opposite bet. To them, software—and especially software running on Windows PCs—reigned supreme. Web apps weren’t foreign to Microsoft; Hotmail’s acquisition in 1997 brought one of the earliest web apps into their fold. But their Office cash cow was built around files, around desktop software installed on PCs, with Exchange and Active Directory installed on internal servers, a web of Microsoft software holding your business together. The web, the information superhighway Bill Gates envisioned, tied your PCs together. It was the connective tissue, not the backend that powered software.
Computing was left with two models. You could buy software for hundreds of dollars, install it on individual PCs, and save data to files to share between PCs and bring your work with you. Or, you could subscribe to software in your browser for often dozens of dollars a month, share access to collaborate with others, and have your work available anywhere you could login from a browser.
The Salesforce model won. The vast majority of today’s software is subscription SaaS that runs in the browser. Where desktop apps are available, they’re an extra, a way to use the app offline and keep it in your dock. The primary app is a web-powered database. Even Microsoft adapted, building web app versions of Word, Excel, and PowerPoint, and bundling Office into a subscription.
Then along came something that actually could obsoletize software: Slack.
Slack: A modern terminal.
At first glance, Slack is just team chat, IRC with style, iMessage for teams, chat from the ‘90’s reinvented in purple. HipChat and Campfire had been around for years, as had Microsoft’s Skype and Lync. We’d seen this thing before.
But something was different this time. Slack wasn’t simply a bet on remote work and teams needing a virtual water cooler. It was yet another bet on the death of traditional software, and on the explosion of API-powered SaaS that needed a hub.
Slack’s chats are, in a way, atomized communications, conversations turned into an API. You type out a sentence or two and hit enter. Colleagues can reply—or, they can react with an emoji for a quick vote of confidence.
Then came the apps. The same way a colleague could send you a message, an app could send you data inside Slack. Someone just placed a new order, a Shopify integration might post in a sales channel, while a Gmail Zap or Help Scout integration might post Bob (bob@google.com) just emailed: "Help with password" in a support channel. It turned out, you didn’t have to keep all your software open all day. Apps could send you messages in Slack and let you know when new stuff was ready for action. And with smart integrations, you didn’t need to open the app then—you could react with an emoji to take action or send a message to the app from Slack to followup.
Slack, in many ways, became a modern Terminal.
Software started out text-driven, where you’d type mail -s "Hello world" bob@google.com to send Bob an email message. Slack brought things full circle, as a text-driven interface to your team and all of the software your team uses. When the majority of software you use is database-powered software that runs online, Slack can be the new interface to your data, a smarter notifications system for teams.
From the earliest days of Slack, their team was using it to manage help tickets and tweets, a hub of work around both the actual data and the conversations about it.
“Slack makes other software better,” their homepage says today. It’s where work happens, between people and software. You might still share files, but the work happens around individual bits of data, around pull requests and support tickets and tasks and new contacts.
That’s where Slack shines, and that’s what the CRM company that declared software dead paid $27.7 billion to acquire it two decades later.
Microsoft Teams: A modern file explorer.
Microsoft adapted to the always-on, subscription-powered world where desktop software is an afterthought. It built web app versions of Word, Excel, and PowerPoint, transitioned Office to a subscription, and even de-emphasized Windows while bringing Office to iOS and Android. It’d built MSN Messenger into one of the most popular early chat apps, had Lync chat in Office for years, and had acquired chat tools inside LinkedIn and Skype.
So when Slack came on the scene, Microsoft in many ways already had chat covered.
What it didn’t have covered was a modern take on work, something that would pull everything together the way Slack did.
Thus Microsoft Teams, launched 4 years after Slack. In many ways, it was a clean start for the software giant, a new take on team communications.
But here, Microsoft had an ace up their sleeves: Office. The work they’d put into building Office for the web meant they could put Office inside anything. So in Teams, your communications would be organized by team with two primary tabs: Posts and Files.
You could chat about an idea, create a new Word document, and get your team to edit it all inside Teams. It became a new File Explore built for teams, a browser built around web apps. And that’s how many Teams integrations would work, too. You could push Slack-style bits of text into Teams, but the standard was set by Microsoft’s Office web apps, and most integrations would put their entire app into another Teams tab.
You could imagine a future where Teams was the interface to Microsoft’s software. Rather than Windows and a start menu, you’d have a conversation and tabs of apps, centered around files.
Files versus Data.
There are other takes on team chat. Basecamp centers chat around projects and tasks. Twist centers them around people, focusing more on conversations than the fleeting ideas and app chatter. Zoom centers on calls, with chat to fill in the gaps that speaking can’t cover. Google Chat centers on email, in a play closer to Microsoft Teams but built around Google’s web-first apps.
But for now, at least, it’s Microsoft versus Salesforce’s vision of the future that’s at stake.
Will the future of work continue to be centered around files, around documents and spreadsheets and work that is finished or nearly so, around full-screen apps and tabs?
Or will the future of work revolve one step up the stack, on the bits of data and info from apps before they’re pulled together into polished reports, on the notifications about changes and new customers and events and more that are the heartbeat behind data-driven apps?
Are files dead—or at least, is work around files dead, leaving files as the store of record, the finished output and not the way works’ done?
Salesforce and Slack and every other SaaS application in today’s business stack vote yes. And that determines the future of work.
Originally published on the now-defunct Capiche blog on December 7, 2020.
“It’s a feature, not a product,” said Steve Jobs of Dropbox, after approaching founder Drew Houston about acquiring the file sync software.
Everything could be a feature, to Jobs. Cameras, alarm clocks, calculators—all features in the iPhone. Even Apple’s other products weren’t immune. The iPod was a $9 billion business in 2008, before the Music app on iPhone and Apple Watch replaced it. Specialized devices gave way to a blank glass slate that could be turned into anything with software.
Thus the fears of Sherlocking, of Apple turning your product into yet another built-in feature. Dropbox, meet iCloud. Wacom, the iPad. Swype might want a word with the iOS keyboard (and Google’s Gboard, for that matter). Skype saw the entire tech industry take them on, making their video calls just another feature in everything from FaceTime to Slack.
And then the cycle restarts, and Zoom makes video chat just enough better to build a billion-dollar market cap, while every tech giant offers a competing free video chat app.
I think I’ve seen this thing before.
Take spellcheck as an example.
First came SPELL, a dedicated bit of software to correct spelling on mainframe computers in the 1970’s. Then came personal computers, and software like WordCheck to check your spelling for $200 in the early 1980’s (over $570 in today’s dollars). Then came word processors like WordPerfect and Microsoft Word, bundling spellcheck along with dozens of other features into one program. Apple took it further, building spellcheck into macOS so every program could check spelling for free.
Then Grammarly in 2009 went back to the basics, made spellcheck a product again that can charge $12/month to double-check your writing. A decade later, Microsoft followed suit, building Microsoft Editor as a standalone spelling and grammar tool—one it bundled with its Microsoft 365 suite. And history repeats itself again.
Product Features or Features as Products.
“Profitable product strategies are built around giving customers the exact mix of attributes they want but no more,” wrote Harvard Business Review’s Ian MacMillan and Rita Gunther McGrath in 1996. “Companies that underinvest in attributes that customers value will lose customers; companies that overinvest in attributes that customers don’t value will lose money.”
That’s the logic behind the fabled MVP, a minimum viable product with “just those features … to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback,” as Lean Startup author Eric Ries described.
The focus, then, is on product features, the core features that make what you’ve built stand out, “discrete areas of new and upgraded functionality that deliver value to your customers,” according to the Aha team. “Features represent outputs,” said the Productboard team; they’re things that help “realize a specific outcome.”
That’s photo editing for Photoshop, document layout for Word, team chat for Slack, email for Gmail. Those products each do far more than their product feature—but you buy the software, download the app for their product features. Everything else is extra (but there are so many extras, you’ll only need one tool for a whole workflow, or so it seems).
Today’s best software, positional software, often takes the other route, building out their product feature to be the very best it can be, and leaving everything else to integrations, add-ons, and complimentary software. It’s the UNIX philosophy, in today’s fancier UIs. Each product doesn’t need to do everything, it only has to do one thing great.
And at first, that’s enough. At a certain level, every piece of software is just a feature, something that couldn’t run without the underlying silicon, operating system, web stack, and more. A good enough feature can win the day.
What surprises and delights customers today, though, might be commonplace tomorrow. Your new smartphone won’t win any awards with a 4G network or a retina display today, even if those were cutting-edge features a decade ago. Neither would basic spellcheck sell for $200 when every app includes it already.
“Products who launch on platforms aren’t wrong to fear the platform,” wrote Abe Winter. They’re in a continuous race to ship better features, features that can still stand alone even the platform clones their core functionality.
How to not get Sherlocked.
So what makes a feature enough to be a product, something that can stand alone as software people will buy even when it’s just a built-in feature in other larger platforms? What makes a feature into a product that can hold its own?
1. Build the best possible version of that feature, for experts.
It starts with focus. Dropbox syncs files. Superhuman speeds up email. One task, done very well.
Platform owners like Apple and Microsoft can build a basic version of everything into their platforms and software suites. The built-in calculator on macOS and Windows is plenty to add 3+5; TextEdit or Notepad are both fine to type several lines of text.
Focused takes on those features, though, can be far better. PCalc adds RPN mode and customizable shortcuts to the basic calculator. Sublime Text and Visual Studio Code can search through far larger text files than you’d ever open in Notepad.
If a feature is the core thing a product offers, it’d better be the best possible version of that feature.
Cameras are a tough market after smartphones put a camera in everyone’s pocket. But you can never get the same focus on the shooting experience and raw photo quality from cameras-as-a-feature in a phone. So Sony and Canon focus on the highest quality images, Fujifilm and Leica on the traditional photographer shooting experience, and can continue to carve out a profitable niche that serves the most demanding photographers.
2. Cover a specific part of a workflow.
Products fit into specific steps of a workflow. Features help those steps along.
If a feature-as-a-product is to survive, it needs to own one specific stage of a workflow. People won’t want to switch programs mid-task, but they’re likely willing to switch software when switching tasks or moving to the next phase of a project.
ImageOptim, for example, does one thing: It optimizes photos, shrinking their file size as much as possible without compromising image quality. You’ll edit a photo in Photoshop, say, save it, then run it through ImageOptim before uploading it to your website. ImageOptim fits at the end of the photo processing workflow, right when you’re changing focus from editing to publishing the photo.
That’s the perfect spot for a tiny, focused tool, where perhaps a standalone image cropping tool wouldn’t be as useful since you’d need to switch from Photoshop to the cropping tool back to Photoshop again. You’d be far more likely to use the built-in tool instead.
iA Writer founder Oliver Reichenstein mentioned something similar in a recent conversation, where he talked about the benefit of Markdown letting you copy text from one app to another, and how that enables workflows of writing one place, editing another, and published somewhere else. iA Writer includes a WordPress and Ghost integration, but few use it, preferring to switch apps entirely when switching workflow stages.
3. Provide enough extra value that it’s worth adding a step.
If a product’s to own a stage of the workflow, it needs to be worth the switching costs of moving to another app every time you do that step.
Grammarly doesn’t need tools for focused writing, or tools for publishing. It’s built for the editing stage—and here, it needs everything one would want to find grammar and spelling mistakes and polish the text. And it needs to provide enough extra value that you’d want to copy text from your writing app, paste it into Grammarly to edit, then copy the finished text into its final destination.
Dropbox was that, especially when it first came out. Syncing files was hard; sending files to others often meant attaching them to an email or copying them to a flash drive. So when Dropbox asked you to add an extra step to your workflow and save new files in the Dropbox folder, it was worth the extra clicks.
4. Focus where the competition won’t.
The jury’s still out on Dropbox; its stock is near all-time lows. “To do what we all want it to do, syncing has to be baked in to all the gadgets we use today,” wrote Farhad Manjoo in 2012, several months after Apple launched iCloud. That continues to be the bear case for Dropbox, as Windows, Android, and Apple’s platforms alike come with built-in cloud sync that works everywhere, no extra Dropbox folder step required.
But Dropbox has a leg up on the competition, versus iCloud at least: It works everywhere. It might not be as tightly integrated into an OS as iCloud, may not have collaborative web apps like Google Drive and OneDrive. What it has instead is that it works on every platform equally well.
Dropbox’ combination of best-in-class file sync features and a broad focus on every platform give it a fighting chance. “Cross-platform networks in particular are tricky to sherlock and a good defense,” wrote Abe Winter, where he called Dropbox the “Anti-Sherlock.”
Platforms can be a great differentiator, as can integrations (where Docusign can sell signatures-as-a-feature, and rely on integrations to push those signatures where they’re needed), file compatibility (how a player like VLC or an export tool like Marked can stand out), and more. Features-as-products need all the help they can get, and a broader or more narrow focus than the competition can make the difference between getting Sherlocked or not.
A better mousetrap.
Sherlocking isn’t quite as straightforward as the headlines seem, though. First there was Sherlock, a built-in search tool on Macs. Then came Watson, a web search tool that its dev team said was “openly inspired by Sherlock.” Then came a new version of Sherlock that included its own web search along with native Mac search, limiting Watson’s market appeal. And so it goes, the wheels of innovation turning today’s product into another feature in a new product.
There’s always space for better standalone tools, for software that’s laser-focused on solving one specific problem. Zoom proved that, as did Grammarly, as do every single-purpose tool that survives in the market.
Then the platforms and bundles catch up, and it’s the focused tools’ chance to innovate again.
And that’s how software evolves.
Originally published on the now-defunct Capiche blog on November 25, 2020.
The craziest app came out a month after the App Store opened to the public, charging $999 for a digital red gem and the text “I am rich.” It sold six copies and shut down the next day.
The next craziest app came out April 1, 2014. You’d tap a button to send your friend a one-word message: “Yo.” 500,000 people rushed to try it over the first three months; investors quickly poured in $1.2 million.
“Yo is mobile messaging taken to its logical – if ridiculous – conclusion,” decided Financial Times’ Tim Bradshaw. “Yo feels like The Onion’s take on pointless apps,” tech writer and investor Om Malik remarked to Fast Company.
When Steve Jobs hailed the crazy ones, surely this wasn’t what he had in mind.
But then you have alarm clocks, turn signals, and check engine lights, the hard drive light blinking on original desktop PCs. Maybe Yo wasn’t crazy. Sometimes the bit of data, the on and off, is all we need to know; the details are simply extra.
I am rich conveyed a single thing. Yo conveyed anything you wanted. You just had to assign meaning to the pings.
Atomized communication.
The original Yo was unanswered phone calls.
Say you were waiting to pick someone up. They could call you, and after a dozen words back and forth they could let you know they’re ready. Or, they could just call you. The ring’s everything you need to know.
So we built a homegrown push notification system, in the days when everyone had a phone but no one had a smartphone. You’d tell someone to call when they’re ready, when the task was finished, when whatever was agreed upon had transpired. When the call came in, you’d hang up, and do the next agreed upon task and pick them up (or whatever you’d discussed previously).
We’d reinvented pagers, the original addictive communication device of the ’80. Someone would call your number, the pager would buzz, and you’d know you were needed. They got the job done enough that the UK’s National Health Service still relies on them to tell doctors when they’re needed. Your favorite restaurant might use a simplified version to let you know when your table’s ready, or when to pick up your takeaway.
A blip, a beep, and we knew all there is to know.
Data + Information = Knowledge.
On its own, a vibrating puck tells us little. Like an inscription in a tree, it’s a single data point. But spot another inscription, and another, and suddenly your data makes a bit more sense. If you’d been sent into the forest, told to follow the marked trees, those data points would be all you’d need to know.
The instruction was information—incomplete without extra data, as you didn’t know exactly the path to follow, but you knew how to found it. The trees were data. And together, the path came together as knowledge. Once you’d walked the path, you might be able to retrace your steps while looking only at the forest. You’d pick up your food instinctively when the puck buzzed.
That, to a degree, is the DIKW pyramid, where data, information, knowledge, and wisdom are a continuum, each leading to the next.
A surgeon knew when the pager buzzed, they were needed in the operating room. The single buzz gave all the knowledge they needed.
Drum towers and smoke signals filled the same need in antiquity. One drumbeat told the next drummer to beat their drum, which signaled the next person, until you had an extended wireless tripwire sending a single data point across the country.
They got more sophisticated. You could assign meaning to repetitive beats, build patterns from sets of beats. Increasingly detailed information, matched with additional data. You could electrify it, build the telegraph, turn your system of beats into Morse Code. Then you’re only a step away from binary and the computing age, where everything we touch today is encoded somewhere in 1’s and 0’s.
At some level of abstraction, it’s Yo all the way down.
Mingle mangle.
One beat’s clear enough. Hard to mistake the meaning when you’ve only assigned one message to the drum. Same as a phone call you’re expecting to come in; one ring and you know what’s up.
The more beats you add, the more sophisticated your system gets, the more you increase the risk of error, of turning the message into a game of Telephone where the final message gets twisted as small errors snowball.
“Every natural language has redundancy built in,” explains James Gleick in The Information, an exploration of the history of information theory. “This is why people can understand text riddled with errors and why they can understand conversation in a noisy room.” We can decipher meaning from the chaos—what Gleick called “a confused heap of mingle-mangle”—as long as it’s repetitive enough.
So we add more data. We don’t just send emails, we add a subject so recipients get the core message twice. We don’t say yes, we say “roger that.” We add app icons and descriptions to notifications, so you’ll know your friend Bob sent you an iMessage inviting you to lunch.
We solve everything with more data. What’s blurry and hard to make out on a downscaled YouTube video might be unmistakably clear on a 4K video. The same information, now with more detail.
And maybe we overdo it. You might not need to know the precise time your friend sent a message, the app they sent it from, and if they read your previous message. You might not need to know you’re on the fastest route despite heaver than usual traffic. But data’s cheap, and so we push it all through for you to decipher.
Everything’s an API.
Then it all gets to be too much.
“Email chains were burdensome,” wrote Alyson Shontell in Business Insider’s profile of Yo’s co-founder Moshe Hogeg. “Even texting encouraged longer conversations than Hogeg had time for.” All the detail was too much; he wanted just data.
“He envisioned a simple app with large buttons that, when pressed, would send a one-word notification to another person: ‘Yo.’ The ‘Yo’ would let the person know they were needed or being thought of.”
One data point was all he wanted.
Those individual data points are all around us. Facebook’s Poke was a similar idea, a ping to let someone know they were on your mind. The Like button—at least before it gained additional emotions—was the same, a single point to show affirmation. The email flag and read receipt, the red dot on Slack’s icon, the line beside edited text in Sublime. We need affirmation, assurance, reminders and signs to give us place, things we can glance at and glean all the information we need.
“When information is cheap, attention becomes expensive,” wrote Gleick. We might not need all the detail, all the time. A bit may be enough.
Sometimes we want a conversation. Other times we just need to check in, like a server pinging another to ensure it’s still online.
That’s what makes many of the best software integrations work. Sometimes you want everything, to archive your customer data from Shopify to Google Sheets or to move your contacts from Salesforce into your Mailchimp list. The more data there, the better.
But you don’t need all of that data, all the time, an endless stream of contact info and orders pouring into your Slack feed. There, you might just want a notice that someone bought something, that your mailing list got another subscriber. That’s where so many popular Zapier and IFTTT integrations are helpful, as a filter against the data overload.
You don’t need to know everything; that’s for the computers. You just need a ping that something happened, that your business is ticking along.
As Gleick quoted philosopher Jean-Pierre Dupuy: “Ours is a world about which we pretend to have more and more information but which seems to us increasingly devoid of meaning.” The clearest meaning might come from more precise information.
Just enough data.
So you scale back. Video calls are now as common as phone calls, if not more so—but that doesn’t mean you always have to use them.
Mike wasn’t alone; several others in the conversation mentioned keeping the camera off on Zoom calls. The call was what mattered, the video quality was if anything a distraction.
So it is with so many of the apps we check every day. You need to know how much traffic your site got, or perhaps just a ping if your site went over your goal. You don’t need to weed through pages of data every time. Perhaps the solution to information overload is to scale back, and build notifications that fit what you need, a bit of info instead of all the details.
Somehow, Yo’s seemingly meaningless pings might have been a solution to the information overload we face every time we open our phones. You just need to define the information, and wait for the beep. That might be all you needed to know.
Originally published on the now-defunct Capiche blog on November 6, 2020.
Flat-pack Ikea furniture can hardly rival the permanence of an oversized mahogany desk. But the mind’s a fickle thing, and you might value a deck you spent an afternoon assembling a desk more than it’s worth.
That’s what a Harvard Business School team dubbed the Ikea effect, finding that “labor leads to love” and love to irrationality.
They gave one group a storage box to assemble, handed another group the box pre-assembled, then asked both to bid on it. “Builders bid significantly more for their boxes than non-builders,” wrote researchers Michael Norton, Daniel Mochon, and Dan Ariely. “Those who assembled their own box valued it more.”
The same applied to paper origami frogs (where creators bid nearly 5x what non-folders did) and LEGO sets (where people bid nearly double for a set they built versus one someone else built). That paralleled an earlier study that found people preferred making cake mixes when they had to add an egg, versus ones where you only had to add water.
We like feeling useful, like making stuff, feel that our unique contributions add something special to even a standard kit.
So when software tells us to spend hours setting it up, we jump at the opportunity to build our own apps without code. Once we’ve put in the effort, we’ll be happier using it, less likely to churn, and might even pay more, even if we’re more locked in than we were with older software. We may have complained for decades when software locked us in; now, we’re happy to stay.
Sometimes we’d rather break an egg.
When software locks us in.
Feature lock-in.
We start using new software to solve a problem, fill a need, turn our bicycles for the mind into flying cars.
So software lock-in starts with our blessing. We choose a new and better tool. VisiCalc in 1979 or Photoshop in 1990 didn’t have to do everything. Their core features were innovative enough, people gladly picked them.
That first-mover advantage gives a wide feature gulf versus the competition. You started using Excel because it came with your computer; you continue using it for one of its 447 unique functions.
Gmail’s tags. Superhuman’s command palette. Evernote’s web clipper. Some of the software that commands the most loyalty does so thanks to feature lock-in. You stick with software longer than you would otherwise when it does that one thing you need better than anything else. And you stay by choice.
File Format lock-in
But what if you strayed? What if you looked across the fence, though the grass was greener on Google Sheets’ side?
What if your data was already in Excel’s format, and that alone convinced you to stay?
That’s what made file formats the original tech menace. You’d find a nice new writing app and want to switch, but no. The powers that be demanded everything in Word .doc format, 12pt Times New Roman. It wasn’t worth risking things looking odd. You’d use Word and like it.
New file formats weren’t all bad. Microsoft’s Office formats let you include more formatting and detail in your spreadsheets than a .csv alone would allow. They sometimes enabled the feature lock-in that made us love software. But they also felt like tech giant’s way to keep us using their software forever. You’d stick with the same software, buy every upgrade, just to ensure you could always open your files.
Database lock-in
Then files died, replaced by databases. What started with tools like Microsoft Access and Outlook, with everything saved in one massive database file, became the default in web apps and SaaS.
You didn’t save Google Docs files; they along with your Gmail and more were stored in Google’s cloud in some unknown format. You didn’t backup your Salesforce databases; it was a collection of data you viewed in Salesforce’s web apps, something we trusted them to manage. You could still export your Mailchimp contacts, Todoist tasks, Evernote notes, and more—but something would be lost along the way. A .csv with your data would never have everything your SaaS application contained.
Media apps took it a step further; you can’t export your iTunes movies and Kindle eBooks. But even in business SaaS with export tools, the death of files kept us locked-in to databases, even as it freed us from the tyranny of file formats.
Subscription lock-in
A parallel trend made you feel even more stuck: Subscriptions.
Word’s file formats kept you upgrading, but you could always opt out if you wanted. At worst your files might not look perfect if you stuck with the version you owned. Then came subscriptions and the death of upgrades. Subscribe to Adobe Creative Cloud today, and if you go to cancel, you’ll first need to pay 50% of your remaining contract. Subscribe to Salesforce, and you’ll pay for the year in advance, where the sunk cost might keep you from switching.
Tie subscription lock-in with database lock-in, and it’s no surprise that SaaS pricing can breed resentment. It’s all too easy to feel trapped.
Network lock-in
But sometimes, we’re happy to be stuck, as long as everyone else is.
It’s not like we love Facebook and Twitter’s software that much, that Slack or Zoom couldn’t be improved. But they’re our digital neighborhoods and offices, the places filled with people we care about. We stay for the network effects, where each contribution and new person who joins makes us that much less likely to leave.
Google Docs brought that idea to productivity software, with comments and feedback from your team that made documents more than just files. It’s what makes Figma more sticky than Sketch and Illustrator—the latter keep you around with features and file formats, the former keeps you around with friends. The network effects are reason enough for many to switch and stick.
Or we could just build our own software.
There was always other route: Build your own software, make things that fit exactly what you need, and never worry about file format and subscription lock-ins.
You’d waste time reinventing the wheel, but would avoid not invented here syndrome, the feeling where as Dr. Ariely phrased it, “If I (or we) didn’t invent it, then it’s not worth much.”
It’s been a problem for ages. As @RusHeywood a contributor to the early C2 wiki, found as their company built their own software in the pursuit of perfection. “Our stated reason for doing so is that But then we go and write our own thing that has different bugs and different limitations.”
Then came no-code. You could have pre-built apps and tweak them, too.
Creation lock-in
Microsoft Access introduced me to building apps without coding in the ’90’s. Suddenly I recognized it everywhere: It powered a Point of Sell system at a small shop I frequented, and the library database at school. I’d go back years later, and that old Access database was still the backbone of those local institutions.
HyperCard had been that for an earlier generation of computing, letting people build wikis and games and apps in 1987. Airtable did that for the 2010’s, reinventing what Access could have been on the web.
Notion, with notes and databases and kanban boards and more in one. Zapier and IFTTT, letting apps do more together than they ever could alone. Roam, letting you connect notes in unique ways, something a plain text file alone could never do.
So many of today’s positional software thrive on being what you want them to be. Even Salesforce at the turn of the century won in part for its flexibility. You don’t simply use Salesforce, you customize it to fit your team’s needs, and that’s what makes it stick.
You could always export your Salesforce or Airtable data in a .csv file, copy your Notion notes to another app. But you could never recreate what you’d built. You aren’t just outlining thoughts in Roam Research or writing reports in Coda—you’re using the unique thing you’ve built in those apps, something that’s not quite your own app, but also not quite a generic, off-the-shelf tool.
It’s your thing. We’re happy staying, locked into using a tool where there’s perhaps no other direct equivalent because we’ve shaped it into the app we want.
Feature-in-your-product lock-in
Then come the APIs, the Amazon AWS and Twilio and Stripe’s of the world, the tools that let you build out features in actual apps instead of coding everything yourself. You can accept payments, send SMS messages, encode and stream video, add chat and push notifications, and so much more today with off-the-shelf APIs.
“The big decision in companies was ‘Build versus buy’, the classic IT decision,” explained Twilio CEO Jeff Lawson in a recent Stratechery interview, something that’s morphed into “Build versus die” as he describes it. Off-the-shelf products really may not cut it, and if your competition is building their own tools, you need to, too. APIs for features let you do that without fully reinventing the wheel every time.
Here, at an even deeper level, you’re locked in. You’ve built your product around another bit of software; odds are you’re not going to go to the trouble of re-writing to remove it.
The joy of creation.
You’d almost think we’d find Trello less valuable than Todoist, since we both pay for the app and invest time into setting it up. Yet the Ikea effect suggests we may be happier with our kanban board. The time invested makes us all the more motivated to get the most out of it.
Thus churn, “a fact of life for a subscription company - like death and taxes,” as ProfitWell CEO Patrick Cambell put it, may not be quite as sure of a thing anymore. Typeform and Zapier found that people who used the tools together were more likely to stick with them. “We suspect that Typeform users seeking to integrate with other apps are also likely to be those that find the most value in Typeform,” wrote Zapier data scientist Chris Peters. Clearbit found something similar: “When customers integrate Clearbit with their other tools … they are less likely to churn.”
We’ve made the software our own, customized it just enough for the Ikea effect to keep us hooked. We invented it here, or so it seems, and the traditional objections to using pre-made software or the arguments to upgrade to the next shiny thing melt away.
“It’s often effort that ultimately creates long-term satisfaction,” wrote Dan Ariely wrote in his book The Upside of Irrationality, after co-authoring the Ikea effect paper. “Greater labor leads to greater love.”
So it seems with software. Rather than resenting the time we put into building Airtable databases and Notion notebooks, rather than worrying if we can take our data elsewhere tomorrow, we’ve finally learned to quit worrying.
It’s why we look back on our Geocities sites so fondly, why HyperCard lives on in the popular imagination, why Minecraft and Roblox stay popular where other games come and go.
We’ve built something. We fell in love with our handiwork.
Originally published on the now-defunct Capiche blog on October 30, 2020.
It all started when Charlie Brown let out a *sigh* at the state of things.
Good grief, he'd say when the going got tough. But words alone couldn't express the full human experience. So Charles Swartz reached for the asterisk, wrapping it around things that weren't quite words, things like whew, ahem, and sniff.
Decades later, we'd call that Markdown, use it to format text without clicking buttons, to write for the web without HTML. Swartz sketched the perfect antidote for our typing times.
On formatting.
Formatting lets you emphasize words and raise your voice on occasion, organize ideas with headings and lists. It's critical for the web, where linking references is half the point.
You could live without it; the alphabet, numerals, and punctuation are enough. But why not.
And so, humans innovate, as they do. Give them a clay tablet, and they'll press the stylus a bit harder to emphasize words. Give them a typewriter, and they'll type over text again to make it a bit stronger. Give them a handful of punctuation characters, and they'll turn them into formatting and emoticons.
The arts led the way, in comic strips of the 1900s. As linguist Ben Zimmer found, parenthesis then asterisks showed up to emphasize words like sniff and sigh mid-sentence for added effect. Charles Swartz' Peanuts used them more liberally, and they stuck.
Decades later, Peanuts-style formatting would show up in email.
"Email was plain ASCII," recalled Low End Mac's Dan Knight in a 2000 article on email formatting. "No bold face. No italic. No fonts. No color. Just text."
So early email senders got creative. They borrowed from the world of typewriting, with two dashes for an em dash, lines of asterisks to indicate line breaks, and underlined text for headers. They added comic strip-style asterisks and underscores around words to add emphasis. Lists came with both dashes and asterisks; quotes and links came with new tech-influenced greater-than symbols and square brackets.
"I love writing email," wrote Markdown creator John Gruber shorter after launching the email-inspired standard. And thus the ad hoc symbols became a standard.
atx: Structured text
Computers, though, would complicate things before we'd rediscover the art of formatting with characters.
First came rich text editing, with button-filled toolbars and keyboard shortcuts that put a print shop's toolkit on your desk. Then came HTML, with its formatting syntax where you'd wrap everything in <something></something> or other.
Copy rich text from one app to another, and your formatting might stay the same, or it might look vastly different. HTML always looked the same—but it was never easy to read or write.
"I'm sick of bringing my writing down to the level of the computer," wrote Aaron Swartz, the programmer who influenced so much of the publishing web including the RSS format and Creative Commons' license. "Why should I have to cover everything in annoying pointy brackets just so it knows what I mean?"
So in 2002, he codified a simpler way in atx. "I'm not really interested in writing another <p> or </blockquote>. I'll have my computer do it for me," remarked Swartz in an email list.
So in atx, a new line meant a new paragraph, no <p> needed. You could add em and en dashes (with 2 or 3 hyphens, respectively), single and double quotes (with single or double backticks), underscore for italics, asterisks for bold, hash symbols for headings, pipes for code. Lists started with numbers or asterisks.
atx was similar enough to Markdown. But it wasn't quite enough. "I need to figure out some way of doing links," wrote Swartz, before describing wrapping text in square brackets then including the actual links at the end of the page.
But it was a start. "I want something good enough to replace HTML and XML for writers," said Swartz, and he was halfway there.
Textile: Bulletproof plaintext-to-HTML
For all the trouble of writing HTML, it still didn't give the style of true typeset text.
"For years I’ve been trying to imagine a bulletproof web-based plaintext-to-HTML system," wrote designer and writer Dean Allen, someone Gruber would later eulogize as one who "strove for perfection and often achieved it."
Allen wanted an easier way to format text "without the writer having to think very much about it," along with ways to make HTML a better typographic citizen "that respects typographic standards and the correct presentation of non-standard characters."
Thus came Textile in 2002, as what seemed for years as the primary rival to Markdown.
Textile was interested in real typography: Single underscores for emphasis, double underscores for italics. Single asterisks gave strong; double gave bold.
You could add footnotes, superscripts, and subscripts, add classes to paragraphs and right, left, center, or justify. It was the typographic parts of HTML, simplified, “automatic conversions from plain text conventions left over from the manual typewriter to their typographic equivalents,” as Allen explained.
Allen was under no illusions Textile would change your life. He wanted to “offer shortcuts to style text (bold, italic) that may save minutes over the course of a lifetime,” his launch post said.
But minutes add up, and Textile soon would be the way you'd format text in Basecamp. Even today it influences Slack's plain-text formatting. "It was very well received, one of those ideas that people looked at and instantly liked," remarked Gruber.
Markdown: Email formatting, formalized.
Gruber wanted something simpler, something closer to the way he’d originally described Textile as a way to "write using email-ish plain text."
“Email is my favorite writing medium,” wrote Gruber. “The conventions of plain text email allow me to express myself clearly and precisely, without ever getting in my way.”
Gruber looked back at the earlier emails he'd loved and saw inspiration for a better way to write. "If you look at any transcripts of Internet email from the 90s, using *this* and _this_ were extremely common," Gruber told me in an email conversation. Where Allen saw typewritten text as the inspiration, email spoke to Gruber.
So two years after Textile launched with the smart quote algorithm he'd help code, Gruber followed up with his own thing—with Textile creator Dean Allen’s blessing.
"I was badgering Dean with a series of 'Why don’t you change the syntax of Textile to be more like this and this?' requests," remembered Gruber years later. "Dean’s response was, more or less, 'These are great ideas, but why don’t you just put them in your own thing?'"
So he dug in, along with Aaron Swartz. "Together we pored over the syntax details from top to bottom, trying to develop the perfect format," wrote Swartz. "It was like finding my way through a maze," recalled Gruber. "I went down many wrong paths, tried out numerous ideas that struck me as good until I actually tried using them."
Markdown didn't cover everything HTML did; if you needed more, you can add HTML inline. What it did cover were the things you’d use to write and blog, borrowing from plain text email formatting where possible. One underscore or asterisk for italics (matching the convention in emails in the ‘90's and comic strips from the ‘60’s and earlier), two asterisks or underscores for bold, greater-than symbols for quotes (as email apps show quoted sections of previous emails in replies), and hashes for headers (something ATX, email, and typewritten documents all used).
And it worked. "I think we’ve got something pretty darn great," wrote Swartz. "If you’re not interested," wrote Gruber, "I’ll try to change your mind in a bit.
The plain text formatting standard.
That wasn't necessary. Markdown was everywhere soon enough.
That first year saw Movable Text and WordPress gain Markdown support. Basecamp co-creator David Hansson built a Markdown-powered wiki. Productivity blogger Merlin Mann caught himself "writing—in longhand, mind you—using Markdown," as the syntax had become second-nature.
An entire category of focused writing apps grew up around Markdown's popularity. The iPhone was years away when Markdown launched, but it too benefited from the character-driven formatting when early apps often lacked formatting tools.
Markdown even showed up in newsprint—though, perhaps more inspired by the comics of yore—when a 2013 New York Times article included *cough*, asterisks and all.
People loved it. "Not to pat myself on the back, but I think it's because everything was very thoughtfully considered," Gruber told me. "Markdown's conventions for the basics are a very nice combination of being easy to type, natural to read, and just plain look good."
And it became the basis for newer formats. MultiMarkdown added tables, footnotes, math, and some of the smart typography Textile sought to simplify. GitHub Flavored Markdown took the original Markdown ideas and the CommonMark spec, and tweaked them to fit the needs of their product (which, in GitHub’s case, needed better code escape tools in Markdown).
"Make up your own thing and see if it catches on," advised Gruber on The Talk Show, echoing earlier advice Allen gave him.
The markup that works the way you want
That spirit is what's made Markdown endure. It can be whatever you want it to be. There's no one way to use it; pick the way that's easiest for you.
Markdown gives two ways to write bold and italics, two ways to add code blocks, three ways to add bullet lists. There was no default file format; txt worked, Gruber used .markdown, and .md became common over the years as well.
"More or less: why not? Better to let people choose the character that feels most natural to them," explained Gruber in a post about Markdown unordered lists, where a Twitter poll showed 54% of people using hyphens and 42% using asterisks for unordered lists.
"I believe Markdown’s success is due to, not in spite of, its lack of standardization," Tweeted Gruber in 2004, as the web debated whether Markdown should be more standardized. "Different sites (and people) have different needs," he explained further down. "No one syntax would make all happy."
What did make all happy was writing, editing, and publishing without thinking much about formatting.
“When you write and read text that’s marked-up with HTML tags, it’s forcing you to concentrate on the think of it," wrote Gruber. "It’s the feel of it that I want Markdown-formatted text to convey.”
And then it became a legend
"New technology seldom eliminates old technology," wrote Mark Kurlansky in his history of Paper. "It only creates another alternative."
And so it was with rich text.
Textile still lingers in parts of the web, and Markdown, for all its popularity, will never replace rich text.
"When you make a product used by millions, you quickly see how confusing anything is that revolves around text editing," said Basecamp founder Jason Fried when asked why Basecamp switched to a rich text editor instead of the plain text Textile formatting it supported before.
But the spirit lives on. Even in today's rich text editors, toolbars are shrinking, or hiding away until you select text to format it. Markdown taught us we could write without distraction, putting ideas into words without reaching for the mouse all the time. Markdown even became a generic term for plain text formatting; Slack's markup is closer to Textile, with asterisks for bold and underscores for italics, but they referred to it as markdown formatting.
And like email, Markdown has become one of the most enduring parts of tech.
