Category: Design

We’re all thinking a lot different today.

Designers and developers alike are coming to terms with Apple’s latest iteration of iOS. As I tweeted just before the announcement, there is only one way to describe it:

shock |SHäk| noun
• a sudden upsetting or surprising event or experience.

Those of us who’ve been around awhile had a similar experience 13 years ago. Apple switched from the Classic interface in Mac OS to a new Aqua interface. As fate would have it, I was in the room with some of my colleagues when Steve Jobs introduced a UI “that you wanted to lick.” We all left that keynote in the same state of shock as we experienced yesterday.

I think it’s useful to look at the history of Aqua while thinking about the future of iOS 7.

Some designers are saying that the new look is “over the top.” The same thing was said about Aqua over a decade ago. And in succeeding years, that original UI has continuously been refined to what we see today.

We’ve become accustomed to Apple’s incremental approach which continuously refines their products. This is typically an additive process where new features are included or existing ones are improved.

But with major user interface changes such as Aqua or iOS 7, Apple has another tendency: they overshoot the mark. Their incremental approach then becomes one where unnecessary items are removed (such as Aqua’s stripes) or improved (excessive shadows and transparency are toned down.)

There’s a good reason for this: it’s much easier to take away elements from a design than it is to add them. Simplicity is achieved by removing that which is not really needed.

One parallel with iOS 7 and Aqua that I don’t expect to see: an evolution that takes over a decade. There are a couple of reasons for this.

The first is that the pace of development for iOS is much faster than we’ve ever seen for OS X. Ask any developer and you’ll hear the same thing: it’s a constant struggle to keep up with Apple’s improvements on iOS. Shit happens, and it happens quickly.

Another is the amount of time Apple’s designers have had to work on this project. The decision to put Jony Ive in charge of the interface design happened in October: a mere eight months ago. A major overhaul of a system-wide interface takes much longer than that.

It would not surprise me to learn that the developers had a very short time with the graphical assets we saw yesterday (think in terms of weeks.) This would also explain why the first beta is only available for smaller screens. The development work to support larger screens is relatively easy, but specifying the layouts and generating the assets is much harder.

Another important aspect to consider is the conditions where this new user interface was being evaluated. Every iOS developer who was using iOS 7 prior to yesterday’s announcement was using a security screen. These screens distort the colors and other elements on screen. Try looking at your laptop screen with polarized sunglasses and you’ll see what I mean.

Apple’s “doubling down on secrecy” also played a part. No friends or family were able to see an engineer’s work-in-progress. It’s likely that no one outside the engineering organization was able to give feedback on what they saw. I can think of a few types of users where this kind of criticism is essential: kids that can’t read, friends with vision impairment and parents with failing eyesight.

The good news, and reason I think that we’ll see many improvements before the fall, is because these kinds of surface changes are relatively easy to implement.

Which leads me to my final points: what are the most exciting parts about what happened yesterday?

It’s hard to tell from the keynote, but all of the interactions that surround the app you’re using are vastly superior. Unlike the visual redesign, the work on Springboard feels more mature. It’s likely that work has been underway for a much longer period of time (probably before last year’s WWDC.) Moving around in iOS is so much more fluid and natural.

Like with Aqua, these fundamental changes in how things work will stick around for a long time. We may complain about how things look in the short term, but improvements in usability will be something that we value much more in the long term.

But more importantly, and more subtly, is the change of focus within the apps themselves. In the design of Twitterrific 5, we went through the process of figuring out what content was most important and then designing controls around that information. Previous designs focused on the control structure first and then filled it with content.

(It’s also interesting to note that apps like Twitterrific and Vesper, which take this content-centric approach, also immediately feel at home on iOS 7.)

It’s clear that Apple’s designers have done the same thing: their focus has shifted towards content. I can’t wait to see what happens to the iOS ecosystem when other designers and developers follow their lead. That path forward won’t be easy, but it will take the platform to a whole new level. Yet another example of “can’t innovate any more, my ass”.

A tweet this morning by James Duncan Davidson got me thinking about the future of Retina images on the web. Before I start talking about the future, let’s take a quick look at the past.

There was a time, not too long ago, where many of us were trapped behind 56kbps modems with 256 color displays. Much time and effort was spent on hacks that made images work well within those constraints. High compression settings and dithering with limited color palettes all combined to get the best quality from the hardware of the day.

Thankfully, as hardware became more capable, these hacks have become a distant memory. Our “solutions” completely ignored the effect of increased bandwidth and didn’t age gracefully.

Now, let’s look at the present. We’re at another tipping point with network speeds and display resolutions. Mobile networks are getting a lot faster and displays have reached a point where we can’t see individual pixels. And attempts to work around current limitations feel dangerously close to those of the past.

There is a movement to improve HTML so it’s more responsive to a wide range of devices. There’s also Javascript that replaces images dynamically. To me, there are a lot of similarities between these techniques and the hacks we had in the late 90’s.

The main problem is that it’s very difficult to determine what type of image is best for the viewer. Screen size is no longer a good metric: my iPad 3 has more pixels than my desktop computer. Similarly, my iPhone’s LTE is nearly an order of magnitude faster than the wired DSL connection in my office. As the device and network ecosystems become more diverse, this problem will continue to get harder to solve. (Remember how much fun sniffing User Agent strings was?)

The only sensible way to move forward is to use a “one size fits all” approach.

Of course, your visitors with the most capable hardware and network won’t be served the most optimal image. Nor will those who have older screens on slower connections.

Your job is to figure out what aggregate size works best for your audience, not to try and outguess what kind of device or network I’m using. Use image compression to create a payload that keeps everyone happy and as needs change adjust that size accordingly.

I’ve always loved shows that take you behind the scenes of creative efforts: Project Runway and Classic Albums being two of my favorites. Here’s one about the development of Twitterrific 5.

Since a lot of the people reading this aren’t developers, I’m going to keep the jargon to a minimum. You’ll be able to enjoy this piece even if you don’t know what an Xcode is.

Statistics

To get an idea of the scope of the project, and see who worked on it, let’s look at a few numbers.

The first source code file was created on February 15th, 2012. Since that first check-in, there have been 2032 changes resulting in 824 files. Of those files, 73% are source code, 25% are images, and 2% are other assets such as fonts and sounds.

Sean Heber was responsible for 976 changes, while I came in second with roughly half as many (557). Tyler Anderson made 397 commits and David Lanham followed that with 95. Anthony Piraino and Gedeon Maheux picked up the rest.

We did weekly beta releases between October 26th and November 19th. The following day, we submitted the build to Apple for approval, which happened one week later. The app was released today, which is actually yesterday in Japan. :-)

Twitter Changes

If you’re at all interested in Twitter’s development ecosystem, you know that approximately six months into our product development there were some major changes announced.

In August, a posting on Twitter’s developer blog announced that changes were coming. In spite of the new requirements and limitations, we were happy to know that our API access wasn’t going to be revoked. Since the early days of the project, we had been worried that third-party development might be eliminated completely.

As more details about API 1.1 became available in September, we became even more upbeat about the changes. There were a lot of improvements in the API and the new infrastructure was extremely robust. Adapting our existing code to the new API took very little time and allowed us to simplify a lot of our internal code. It’s good to know that management’s decision to control the core Twitter experience hasn’t affected their great API engineering.

At this point in time, we also learned that we had plenty of user tokens for the upcoming version. We agreed with our friends at Tapbots, there is no reason to panic.

One downside to the limit of user tokens is that we can’t afford the “cost” of a free app. If someone downloads a free version of Twitterrific and then uses it once, we can never reclaim that token. Tokens are a scarce resource that developers have to manage carefully in order to recoup their development costs. If you’re holding out for a price drop with our app, you’ll be disappointed. The price of Twitter apps is going to rise from now on.

Development Approach

So when you have five people working on a piece of software, how do you go about it?

This time around, we took a much more design-centric approach. When you have a large project, be it a movie or a piece of software, you have to have someone calling the creative shots. For Twitterrific 5, that person was David Lanham.

We’d done Twitter clients before and honestly weren’t that enthused about doing another one. That was until we saw a complete and clickable prototype that David had created. That “wow!” moment you have when you launch and start to use Twitterrific 5 is something we experienced last February. We all knew we had to make this real, even if it was a bit crazy. Our foreman, Gedeon Maheux, made the call and the project began.

Some natural pairings occurred between the three developers and single designer.

As senior developers, Sean Heber and I decided to split the workload between the front-end and the back-end. Sean had a part in everything you see on screen. I had a part in everything you see going over port 443 (for you non-developers who won’t get that joke, that’s the secure network connection that the Twitter API uses.)

This turned out to be a great decision. The user interface doesn’t depend on knowledge of how data is transported over the network, processed and then cached in a database. In fact, in the early stages of the project, much of our back-end existed as a separate project with no user interface. It used automated tests that exercised multi-threaded access to the Twitter API. This independence between the UI and the network services allows new APIs to be added quickly and easily.

(AND IT MAKES ME KING OF THE BACK END IF YOU KNOW WHAT I MEAN)

One of the benefits of writing your own version of UIKit is that you have a pretty complete understanding on how to use it effectively. All the sexy animations and views you see in the the app are Sean’s doing. As he continued to amaze us all, we came up for a word for what he does: juice. For example, just the other day, he closed an issue titled “Add JUICE™ to Photo view”. (You’ll see that change in the 5.0.1 release that’s in review now, and yeah, it’s great.)

Splitting the front and back-end work between Sean and myself had another benefit: we were constantly optimizing our code so that it would make the other guy’s code work better. A lot of people have commented on how fast Twitterrific feels: hundreds of iterations made that happen.

Another pairing was between David Lanham and Tyler Anderson. From the start, we knew that we wanted customers to have control over the appearance of their timelines. Since Sean had done of version of UIAppearance proxy in Chameleon, that was a natural choice to accomplish our goals.

What happened next though, surprised us in a very good way. David started using Xcode.

Since Tyler was writing code that allowed all the appearance modifications to be collected in a single file, it was easy for David to go into that file and tweak the settings to get things exactly as he wanted. Any coder who’s worked closely with a designer had heard these phrases: “Can you replace this image?” “Tweak this color please!” “Nudge that button to the right a few pixels.”

Instead, David was adding files to Xcode and modifying UIColor and UIEdgeInset definitions by himself. Letting the designer take control of his designs, do test builds, and refine the interface produced some amazing results. And it let our developers focus on what they do best: typing code.

As work progressed on the product, we realized we were making something special. When that happens, all sorts of crazy and wonderful things start to form without you really knowing how or why. The best example is when Sean and David added gestures. Twitterrific was already in beta at that point and we were completely happy with the action menus, but the two of them went quiet for a couple of days saying only they were working on “something cool”. And they were right: we can’t imagine using the app without gestures now.

A Clean Slate

So now that you’ve heard about what led up to today’s release, let’s finish with some thoughts about future directions.

As soon as you launch Twitterrific 5, you’ll realize that it’s a clean slate. The visual design is obviously a fresh start, but everything under the covers is as well. When presented with a clean slate, you’re very careful what goes on it. It’s best feature is simplicity. I wrote about Gruber’s First Law of iPhone Development four years ago:

Figure out the absolute least you need to do to implement the idea, do just that, and then polish the hell out of the experience.

That still holds true, and we feel like we’ve done the least and polished the most.

We are well aware that people are going to complain about missing features: push notifications and streaming are obvious examples. But so are trends, and video support, and in-line photos, and… well none of that matters. We believe in building opinionated software.

The product you have in your hands is what we wanted and needed it to be. As the tagline on the website says, “A simply beautiful way to tweet.” We achieved that goal.

Personally, I find myself actively disabling notifications in most of the apps I install these days. Notifications are great when used in moderation, but it’s very easy to use them to the point of distraction. Since I read Twitter as free time permits, I don’t need a reminder. Similarly, a constant flow of streaming tweets interrupting my day sounds more like a bug than a feature.

But guess what? That doesn’t matter either. I’m just one of the opinions that made this software.

And now we’re going to start listening to our customer’s opinions. We’re all excited to get feedback from a larger audience and see how that fits in with our new minimalist vision. If you think Twitterrific is good now, just wait until you see what happens with your collaboration.