The tenacity of open

· Product · Patrick Smith

Ben Thompson is a writer who focuses on the strategy of technology businesses, and I’ve really enjoyed his stuff for a number of years. His business model is a subscription for three emails per week that form a narrative, with another article made free to everyone that is standalone.

The problem I’ve found is that it’s hard to catch up with these daily updates. They often refer to the last one, with clarifications and expansions, and so once you get off the train it can be difficult to get back on. He’s just launched a podcast version of the daily update, and it’s also subscriber-only.

The reason I find this fascinating is that he talks about ‘Aggregation Theory’, the way that internet-first companies such as Google, Facebook, Amazon, and Netflix, by owning the customer relationship directly are able to control suppliers. But then he calls out that his own business model purposefully avoids getting on these platforms, but instead relies on the open nature of two technologies: Email (with SMTP) and Podcasts (with RSS). He’s also not going through a platform like Patreon, which itself could dictate terms. He also considered making his own app, but then people have to explicitly come to the app every day.

Instead he’s going to where people are. The feeds they check every day. That are not controlled by any entity. It highlights the future and reliability of Email and Podcasts as things that will still be around in 20 years. Facebook, Instagram, Twitter — any of these might be dead or irrelevant by then. But there will be (hopefully) a plethora of email and podcast clients, any of which I can choose, and to which anyone can send me content.

The other thing I love about the Stratechery announcement is the podcast RSS feed has both the audio and written content in one. If I put the feed into my podcast player, I get the audio content, and cover art will be shown with say a chart or whatever that is being talked about. In the show notes is the entire written content.

Yet if I put the feed into a traditional RSS feed reader, then I get just the written content. Blew my mind that one URL serves both of those purposes.

Jeremy Keith on Architects, gardeners, and design systems

· Design, Teams, Workflow · Patrick Smith

Jeremy Keith:

It’s rare to find job titles like software gardener, or information librarian (even though they would be just as valid as other terms we’ve made up like software engineer or information architect). Outside of the context of open source projects, we don’t talk much about maintenance. We’re much more likely to talk about making.

Anyone who’s spent any time working on design systems can tell you there’s no shortage of enthusiasm for architecture and making—“let’s build a library of components!”

There’s less enthusiasm for gardening, care, communication and maintenance. But that’s where the really important work happens.

A well-written look at why the iPad is harder to use than an iPhone or Mac.

· Planning · Patrick Smith

John Gruber writes why the iPad’s multitasking UI mental model can be extremely confusing.

I believe the whole app launching & icons sitting on the home screen model should be rethought. If you were to design it from scratch today, I believe you would arrive at a more intuitive and simpler system. Rearranging icons is a chore. Drag and drop feels like balancing an egg on a fork. Most of it is undiscoverable.

The iPad has the chance to be an amazing device but the system software is frustrating.

People quickly accomplishing ambitious things together

· Concepts, Planning, Product, Teams · Patrick Smith

Patrick Collison of Stripe has started putting together a list of ‘examples of people quickly accomplishing ambitious things together.’ Sometimes an idea comes screaming into the world.

Xerox Alto. Work on the Xerox Alto, the first GUI-oriented computer, started in November 1972 because of a bet: “Chuck said that a futuristic computer could be done ‘in three months’ and a Xerox exec bet him a case of wine that it couldn’t be done”.

Git. Linus Torvalds started working on Git on April 3 2005. It was self-hosting 4 days later. On April 20 2005, 17 days after work commenced, Linux 2.6.12-rc3 was publicly released with Git.

BankAmericard. Dee Hock was given 90 days to launch the BankAmericard card (which became the Visa card), starting from scratch. He did. In that period, he signed up more than 100,000 customers.

Amazon Prime. Amazon started to implement the first version of Amazon Prime in late 2004 and announced it on February 2 2005, six weeks later.

Don’t make your developer experience improvement a tax the user pays

· Planning, Product, Teams, UX, Workflow · Patrick Smith

Sometimes it feels like we decide the developer experience is more front of mind than the user experience.

Or: DX > UX.

Why is that? Does web development today feel like such a beast that I must wield a powerful weapon with which to conquer it?

We need the latest browser features to build web apps. If they are not available in every user’s browser, we will write the code we prefer and transpile or package it up into to a common lingo.

The team really wants to use this new language or framework, so we should adopt it and be cutting edge! We’ll be more attractive in the industry so hiring will be easier.

It’s quicker for us to choose the same tech everyone else is using, because they have solved lots of problems that make it sometimes tricky and there’s a huge ecosystem of ready-to-go components and plugins. We’ll move so fast! 💨

While I think these considerations should be discussed, where is the user here?

Will it be easier for the user? Will they move quicker than they had before? Will they be provided something ready-to-go to solve the problem they have? Will they really want to use what you’ve made? What did they need anyway?

If you have failed here for the user, or if the developer experience is more satisfying to the developers than the user experience is to the users, what has been gained? If it’s fast for the team to see changes live but slow for the user to load, that’s a tax the user is paying for. Was it worth it? Why should they pay?

As developers our natural sense is to pick up on what makes a compelling and fresh developer experience that will lead us to learn interesting new concepts and be involved in the currents of the industry. But does the user care? Are you creating a large tax for them to swallow? Will your team get swept away from the user? What value does the user get for paying that tax?

Keep the user experience front of mind. Talk with the user and measure so that you know that your UX is at least as compelling as your DX. Keep the tax from your DX choice low.