Category: Design

This past summer we narrowly avoided a major user interface regression on Apple devices. The story ended well, but I think it’s important to look back on the situation and ask a simple question:

Why did this happen in the first place?

My answer is something I call “consistency sin”. Understanding the cause lets us avoid similar situations in the future.

Your first reaction to this nomenclature may be, “Isn’t consistency a good thing in user interfaces?”

Absolutely! Colors, fonts, and other assets should be similar within an app. Combined they help give the user a sense of place and act as a guide through an interface. And in many, cases these similarities should be maintained across platforms. There’s no sin there.

But you can get into trouble when this consistency starts to affect the user experience.

Design is not how it looks, it’s how it works.

Steve Jobs said a lot of smart things, but I use this advice most often.

The roots of consistency sin take hold when folks disregard the inherent differences between platforms. A greater importance is placed on making sure things match visually: how a person uses that design takes a back seat.

Platform controls and interface elements can differ at a fundamental level. The mouse is optimized for indirect interaction while a screen is optimized for direct interaction.

For the most part, developers are shielded from these details through the use of standard components that conform to the Human Interface Guidelines.

Enter Safari

Higher level interactions are driven by the type and quantity of information the user is working with.

To use Safari as an example, I can have hundreds of tabs open while I work on my Mac; on iOS it’s usually less than a dozen. Safari on iOS is also a full screen experience, while multiple windows and interactions with other applications are common on macOS.

Safari’s new tab design on iOS works great for me: swiping between tabs of fullscreen content is a better interaction for a limited number of pages. The grid of pages as a fallback for selection also works well for managing what I want to keep around.

The consistency sin in Safari was to come up with a good design for iOS and assume that it would also work well on iPadOS and macOS. It practice, these new tabs were difficult to use in a different work environment.

Luckily the folks working on Safari did the smartest thing possible: they listened to feedback and fixed the issues before shipping. That’s an important thing for a product that every Apple customer uses every day on every device.

It’s one thing to make a mistake, it’s a wholly different thing to deny that anything’s wrong. So let’s take a look at another example.

Notifications, Too

Notifications also suffer from consistency sin.

I look at my iPhone Lock Screen dozens of times each day, and sometimes just to just view a reminder or some other short notification. It’s quick, simple, and minimizes distractions.

On my Mac I see the Lock Screen only once or twice per day for just a few seconds as I enter a password. That means notifications occur while I’m actively working.

Again, consistency sin looks for a single solution that ignores my needs. On macOS I don’t want a minimal solution that is suitable for a mobile device. I want options that let me quickly dismiss or defer an item that’s interrupting my work. (And I certainly don’t want to hunt around in the window for a hidden control that lets me access a function.)

Placement is also an issue: on iOS controls tend toward the bottom of the screen (for reachability). The opposite is true on macOS where they tend  toward the top of the screen so they’re closer to the menu bar and window controls. Consistency sin says that notifications should always be at the top of the screen.

With iOS, there’s a nice visual and functional separation between app interactions in the lower half of the screen and notifications in the upper half. On the Mac, notifications are just another thing fighting for real estate at the top of the screen.

We’ve Only Just Begun

The bad news is that we’re likely to have more consistency sin in our future, thanks to Electron and other cross platform frameworks.

While development teams try to attain feature parity, experience parity will suffer. Everyone who’s used an iOS app and immediately thought “this is a web page” will know what that means.

There is a long history of user interface frameworks that make work easier for a product team. Every time, these solutions end up being a least common denominator that makes it more difficult for customers. Don’t be surprised when they complain: as they did for Safari, and as they do for Notifications.

If you’re a designer or developer, it’s your job to push back on the notion of consistency when it begins to affect a user’s experience. Remember design is how it works, and work is not the same on every device. 

Today, the Iconfactory is happy to introduce a product that’s made with three different apps: Triode. Simply put, it’s the best way to enjoy all of your favorite Internet radio stations, wherever you go.

So why did I make these apps?

A Brief History of Internet Radio

Before I can answer this question, it helps to know a bit about where I live. Laguna Beach is surrounded on three sides by a coastal range that blocks any broadcast from the Los Angeles and San Diego metro areas. A signal’s only clear shot is from the Pacific Ocean, where there are no radio towers.

I moved to Laguna in the mid-1990’s — as you probably know, that was a time when the Internet was starting to take off.

Progressive and independent radio stations immediately saw the Internet as way to extend their reach: WXYC was the first station to broadcast a stream in 1994. Many others soon followed.

I saw it as a way to overcome the physical limitations of where I lived. And in the process, I discovered a lot of interesting sounds from all over the world.

In short, Internet radio is nothing new and I’ve been listening to it since the late 1990’s.

Old Meets New

What is new are the array of devices we can use to listen to radio streams. In the beginning, my only option was a desktop computer, but now I also carry a powerful device in my pocket and have another one attached to my TV.

These devices also have advanced capabilities like multi-room audio with AirPlay 2, a CarPlay interface while driving, automation with Siri shortcuts, and iCloud data syncing. They’re also highly accessible thanks to VoiceOver.

Yet many radio stations provide free apps that are cross-platform and can’t take advantage of the features that Apple provides its developers. In fact, many of these apps are basically a view that use the same JavaScript-based player on the station’s website.

I saw an opportunity to do something better.

Always With Me

Early in 2018, Triode got its start on tvOS as a way to listen to music while relaxing on the couch. I loved that so much, I then wanted it while working on my Mac. Then, while out and about with my iPhone and AirPods. A simple idea was blossoming.

The challenge quickly became creating a unified experience across three different devices and input mechanisms. Building a user interface that worked natively with a TV remote, a mouse, and your finger was a challenge!

Overcoming this hurdle had a real benefit: it’s pretty awesome to find a great station on your Mac while you work, and have it automatically show up on your iPhone during a commute, or on your TV as you relax in the evening.

Early in the development process it became apparent that great artwork was an important part of the experience. Seeing a beautiful new album cover has always been essential part of discovering an artist or track. It became a central element of our unification effort.

This effort also helped refine my thoughts on the future of interaction on Apple’s platforms. And, as it turns out, SwiftUI.

A Place of Discovery

With the help of my colleagues, the user interface and interaction started shaping up. The task then became how to introduce folks to Internet radio.

Most existing players have another flaw: they promote quantity over quality. It sounds impressive to tout tens of thousands of stations — until you realize that a lot of them aren’t very good. Clearly, some curation was needed.

Over the years, I had accumulated a collection of favorite stations. This formed the core of the “Our Picks” in Triode.

While thinking about how to extend this group of stations, it became clear that they all had one thing in common: they were independent and listener-supported.

These stations have have long been a place to discover new music. They’re often associated with a college or university that has a student body looking for the latest and greatest. The lack of commercial pressures also provides an environment where new acts can get their first bread and established artists can do something unexpected.

Every major artist used to be someone you had never heard of, and Internet radio played a major part in that transformation.

That spirit guided our curation of “Our Picks”, while “Find a Station” provides quick access to thousands of stations from around the world. Both will become “Your Favorites” and automatically get synced to all your devices.

Privacy First Design

Last, but certainly not least, Triode was designed with your privacy in mind.

Unfortunately, today’s Internet is full of trackers. If you’re using a web-based stream or app, its likely that your listening habits and other metrics are being collected.

In Triode, the only information provided to broadcasters is your IP address. And since we don’t display any ads in the app, that’s one less thing for marketeers to know about you.

And More

The Triode website has more details and this review at MacStories goes into great detail about how the app looks and works on the different platforms.

It’s been a blast making these apps — I hope you enjoy them!

I am so fucking excited about SwiftUI.

I had strong suspicions that Apple was working on something like this, but what we’ve seen this week goes way beyond any of my expectations. My thoughts have now turned to how important this development will be for the future of all user interaction.

It all started while sitting at this year’s edition of The Talk Show and hearing about one of its sponsors: OmniFocus for the Web.

I’ve been good friends with the mad scientists at the Omni Group for a long time: we all have the gray hairs to prove it.

When you hear that they made a server with a macOS app that renders content for web, it sounds strange at first, but then makes a lot of sense when you consider how much code sharing you get. They’re not fools.

Then, while watching the SwiftUI Essentials talk, it occurred to me that the new domain specific language (DSL) looked like a HTML, CSS, and JavaScript hierarchy.

When you connect these two dots, you see a pretty exciting future for your code.

Abstraction

Apple has talked a lot about SwiftUI this week, but one thing has been conspicuous in its absence: implementation details. Some folks have discovered that there is some underlying UIKit code, but looking at this is a distraction.

The most important part of this announcement is the abstraction they’re working with, not the view surface being used for rendering.

This view abstraction is important for our apps: you don’t need to care how a button is rendered on tvOS, or macOS, or iOS. You don’t need to worry about which interactions are available on each platform, other than to provide alternatives when things like a digital crown aren’t available.

Interactions Above All

Earlier this week, I was talking to my friend Soroush Khanlou about the announcements. He expressed surprise that so many long-time developers who were vocal about Swift’s deficiencies were suddenly excited about SwiftUI.

There’s a simple explanation for this: we value great interaction, both at the user level and API level.

To me, it always felt like there was a parity mismatch between Swift and the existing UI frameworks. Sure, you can put a Ferrari engine in a Ford pickup and get it to move, but it’s not going to be a great experience. Awkward to build, awkward to drive around in.

The Web, Too

So my observation about the SwiftUI DSL and OmniFocus show us something important: a web browser is just another surface to render your views and respond to user actions or external events.

And it will be a way where interactions can be adapted for the platform being targeted.

Think about all the work that Apple has put into making iWork apps run in a web browser. Would they be looking for ways to make this easier? Yep.

I also think we’ll see the Swift community pick up on this DSL. Initially, it rubbed me the wrong way that Apple was using “Swift” in a framework that targeted platforms using proprietary features like Core Animation.

But again, when you look at the abstraction, you see the greatest value in how the DSL is processed, not in how it makes it into a CALayer. Could some enterprising group of developers take the SwiftUI DSL and produce something that worked on Android or Playdate? Certainly.

And what about compiling Swift code and running it directly in a web browser? You can do it right now.

The Most Capable Environment

While commenting about this on Twitter, Steve Streza made an important observation: SwiftUI is like a “reverse React”.

But I think there’s something important to add to his note: the SwiftUI DSL describes the most capable environment. It’s the maximum interaction surface: platforms will render and react to a subset of what’s declared.

Some devices, like a watch, will be capable of handling a physical rotation from a dial. Your only concern on other platforms, like iOS, are alternate interactions. When you target Playdate with your app’s SwiftUI DSL, you won’t be surprised to see the crank do the right thing.

I didn’t realize it at the time, but John Gruber’s quip at the beginning of The Talk Show hinted at our future:

For all of the consternation we have for developers who have web apps and put it in a shell and call it their Mac app, [laughter] the Omni Group has done the right thing and took their Mac app, and now it’s on the web.

It was certainly a funny moment, but it also gets directly to the point of working from a more-capable to a less-capable environment. And also how we’re at a point where our apps will head in directions that we can’t even begin to predict. I find that tremendously exciting.

In summary, I think that SwiftUI is an absolutely fundamental change that we’ll be living with for decades. You can certainly dismiss it, but doing so will be at your own peril.