Category: Design

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.

I just finished reading an oddly named book by someone you’ve probably never heard of – I loved it so much I’m writing this site’s first book review.

Ken Kocienda is a talented developer. He’s also a lucky one: he worked at Apple during the years when the Mac was reborn and the iPhone was created.

If you’ve ever opened the web browser in your pocket or typed a text message on a piece of glass, you’ve used his seminal work. Ken was directly responsible for two important parts of the original iPhone: a fast and efficient web framework and a keyboard that was both virtual and predictive.

Ken is also a great storyteller. His experiences during these formative years provide great material for this narrative. But more importantly, he extracts lessons from these tales that can be applied to our own efforts.

In short, Creative Selection is a study on how great products evolve that inspires the reader.

I first learned of Ken’s work during a presentation at WWDC 2014. A Strategy for Great Work showed that in addition to doing interesting things, he also took the time for introspection and learning from the work. I immediately followed him on Twitter and eventually discovered our mutual admiration! (That, in turn, led to the advanced copy I’m reviewing today.)

This talk, along with the ones that preceded it, feel like a formative process for the chapters of the book. The video linked above will give you a very good idea for the tone of his latest work, but there’s also an important difference.

Ken no longer works at Apple.

The end of presentation in 2014 alludes to this situation: not being able to talk about certain things is a fact of life in Cupertino.

I found Ken’s new freedom most intriguing when he focused on other people’s contributions to the secret projects. Every developer knows that a success involves many different talents and personalities. And with Apple’s penchant for secrecy, we never hear about these team interactions.

The collaboration between Steve Jobs and Jony Ive is not only well known, it’s well understood. I think this is because industrial design is much more concrete and easier to interpret in the formative stages.

Steve had another important collaborator, but that relationship isn’t as well understood. Creating software requires abstract decisions and a more opaque process. How do you make a button on a piece of glass?

When you look at the Wallabies from Ken’s desk, you can see where the hardware is headed:

When you think about what was on those screens, things get more complicated.

This book changed my view of Scott Forstall because it gave context to his work. Ken’s account breaks down the approach and shows how important Scott’s leadership was to Apple’s success.

Having Steve Jobs as a boss for your entire professional career would not be easy, but Scott handled it with great success. Even when that powerful mentor was asking for skeuomorphism.

The hardware would be lesser without Jony, and Ken shows that the software would be lesser without Scott.

If you’re a developer, you’ll find some passages a little slow going. That’s because you know too much :-)

As a great storyteller, Ken endeavors to make the topic as widely understood as possible. To achieve this he turns to analogies in cooking, sports, and the movies while describing the process of creating software.

While we may not need this high-level view, there is an important group that will benefit: our families. If you’re like me, you’ve struggled to explain what you do at that keyboard all day.

We all love our iPads and Kindles for reading, but I’m really glad I have a printed copy of the book to share with the people I love.

I’ve avoided spoilers in this review, but I’ll end with one story that touched me. When asked about the most important thing in development, I always answer with one word: empathy.

Ken links this concept, along with the combination of good taste, the philosophy of Immanuel Kant, and a discussion of atoms by Richard Feynman, all while explaining the choice of a QWERTY keyboard layout.

These complex factors enable a personal connection between people. Imagine being the developer whose choices led to the ability to send a quick message saying “Just landed.” Informing a loved one of your safe arrival transcends the importance of any line of code.

That is work to be proud of and we’re lucky Ken has taken the time to share it with us all.

Today’s a big day for app developers.

In the lead-up to today’s event, I spent some time digging through my old purchases. After launching the App Store app, tap on your profile in the upper-right corner, then tap on the Purchased menu of your account page. After spending a few hours scrolling down, you’ll see your first apps!

One of the apps was something called “Carling Tap” – and I had no recollection of anything by that name. A little bit of research helped me remember that the app was formerly named “iBeer”. This hiccup with the name not only paused my scrolling: it also got me thinking about the importance of this early app.

Many of the apps on that first day, including my work with Twitterrific, were adaptations of desktop apps. Things like AIM, NetNewsWire, and Solitaire had many advantages on mobile, but in retrospect, they weren’t a sign of what lay ahead.

Even though it was a gag, iBeer gave us a real glimpse of our future. It was the first app that was spatial. The function of the app was determined by where it was in your world. It could not exist without you.

Since then we’ve seen many other apps take advantage of this unique characteristic of mobile devices. Ocarina made it beautiful. Ride sharing leveraged it for efficiency. Pokémon GO made it fun and communal.

Now we’re heading towards a future where all apps will be spatial. One can only imagine how that will turn out, but it’s likely that the accessories will be fun.