What More Do You Want

You know what would suck? If Flickr just shut down one day, without warning, and suddenly you lost all your photos you had posted. You typed Flickr.com in your browser and what came up was a “Thanks for the good times!” message and an explanation that Flickr was no more. That would be terrible. But it probably wouldn’t be so bad if Flickr told you they were going to shut down months ahead of time, and then let you export your photos in several standards-based formats, right? And then what if a bunch of Flickr replacements popped up and offered one-click migration of all your photos to their platform? That would be pretty nice, right? And what if some of these new sites seemed to be better designed and have some unique features that were pretty cool, and now that you think about it, nothing new had really come out at Flickr in years.

You might see where I’m going with this. The good scenario is what just happened with Google Reader. And yet many are claiming that Google has done wrong.

Outside of some “companies should never drop products or features or make other long-term strategic choices even though long-term strategic choices are at least a third of what any company that wants to survive in a competitive environment must do” completely impractical view of the world, I don’t know how you can argue that there’s anything problematic about Google Reader’s shutdown outside of it being personally upsetting or annoying to you.

Let’s review what Google did:

  • Warned both users and developers months in advance of the shutdown.
  • Provided multiple export formats, including standards-based formats.
  • Provided an API for programmatic export/import by competing platforms.

What more do you want here? Seriously, outside of Google basing their long-term product decisions off of your personal whims what are you looking for?

We should be celebrating the way Google handled this. We should hold this up as a model for all other tech companies to look to when “sunsetting” their products. Let’s not get it backwards: with the Reader shutdown, Google has done right.

A better podcast app

Apple just updated their podcasts app to a state that seems actually usable so I gave it another shot. After messing around with it a bit I ended up abandoning it and going back to Instacast, my podcast app of choice.

The reason that I abandoned it wasn’t that it was bad, actually, or at least no worse than any other podcast app out there. It just didn’t do anything any better and I had already put the work in with Instacast.

In the course of trying to set Apple’s Podcasts up with the podcasts I like, and then thinking about my rationale for going back to Instacast, I realized that at a fundamental level none of the podcast apps work the way I’d like. They’re all too much work. What I really want is a podcast app that works like Netflix.

Let me explain. I love Netflix. Part of what I love about it is that it removes so many layers of management. With Netflix, there is a library of content. Some of it you have marked as interesting to you (your queue). It keeps track of what you have watched. That’s it.

I want a podcast app that works like Netflix. Instead, every podcast app that I have used adds additional layers of management. Yes, there is a catalog or store of podcasts. But instead of just playing those directly I have to subscribe. Subscribing adds the podcast into a separate area that I then have to manage. After subscribing, rather than just showing me all the episodes, it shows me the most recent five or ten (often controlled by a setting – more management). And rather than just mark what I’ve played, it marks what I haven’t played. It treats podcasts episodes like emails. More management. And then in addition to all that, there is often another layer of download management. All these layers leads to a lot if UI, a lot of settings, a lot of “helpful” extras (like the Podcasts app that stops updating your subscriptions if you don’t listen often enough). You might think this is hyperbole, but to me this is so. much. work.

Here’s what I propose: throw that all in the trash. When you launch my dream podcast app you would have three tabs: favorites, browse, and search.

(Favorites could be called starred or queue or whatever. It’s just Podcasts I’m Interested In.)

Viewing a podcast listing would show some details (name, description, etc.) and all the episodes. Tap on an episode to play it. If you had already watched or listened to an episode that would be indicated (just like Hulu and Netflix track viewing). Pressing play on a podcast (rather than an individual episode) would by default start playing the first episode that you hadn’t watched (just like how Netflix handles TV shows). Star/favorite/queue a podcast to put it in your starred/favorites/queue list.

The key is to simplify. Here is content. Press play to watch or listen to said content. We’ll keep track of what you’ve played. No subscribing, no little blue dots, no app badges, no download management, no syncing.

Finishing the iPhone

It’s more accurate to consider the iPhone a computer than a phone. Perhaps even more so for the iPad.

Clearly Apple sees this as well, as the evolution of iOS makes clear. From its no apps, iTunes-required beginnings to the 700,000+ apps, no-iTunes-required current state iOS has been steadily marching towards becoming a full-fledged computer. But it isn’t there yet. So what remains? Here’s my list.


If the iPad is to become the computer of the future you’re going to need to be able to install fonts on it. What I’d really love to see is fonts synced via iCloud between my Mac and all my devices. I have to believe that Apple eventually wants at least their own apps, like Pages, to have complete parity between the Mac and iOS versions. No more “Some formatting is not supported. Would you like to create a copy?” messages when opening a Pages document on iOS that was created on the Mac. To get there they will have to let you install and manage your fonts.

System Defaults

The utility of third-party browsers, email clients, and (now especially) mapping apps is dramatically reduced by iOS’s total ignorance of them. If you click a link that opens in a browser, that browser is going to be Safari, even if you have Chrome or Dolphin in your dock. Clicking an email address is going to launch Mail, even if you have Sparrow installed. As the offerings in the App Store grow in sophistication this situation is going to become more and more untenable, especially when competing platforms (*cough* Android *cough*) have no such limitations.

Inter-app Communication

Both Android and Windows 8 have implemented models for inter-app communication that are far superior to iOS. That is to say, they actually have a model. Apple has seemingly laid the groundwork for a solution to this with XPC, but we’ll have to wait and see. This is another one that will become more and more problematic (unless Apple solves it, of course) as the third-party app market matures and the needs of iOS users multiply and diversify.

File Management

This could be the one that Apple doesn’t budge on. I continue to believe that without a central document store, accessible by any and all apps on the device, the long-term potential of iOS is crippled. However Apple may continue to push and tweak their total sandbox approach until either it becomes clear it’s good enough, or competition forces them to shift strategies.

Multi-User Capabilities

Here’s another feature that Apple may never bring to iOS: the ability to have more than one user on a device, each with their own apps and accounts. It certainly seems a little premature given the current storage sizes (two users sharing 16 GB? No thanks.), but as the capacities move into the 100+ GB range this starts to make sense.

Market Maturity

One of the biggest reasons iOS devices aren’t full-fledged computers yet is because the market still says they aren’t. Yes, the lack of the features I’ve listed here (and many others, I’m sure) make it more difficult to bring traditional desktop applications to iOS. But it’s not impossible. For example, as far as I can tell, there isn’t a single app on the app store for managing SVN or Git repositories akin to Cornerstone or Versions on the Mac. Why? Probably because the assumption is that no one wants to manage those things on their phone. That’s what you’ve got a computer for! Well, I’m holding a tiny computer in my hands right now, typing out this blog post. Everyone might not see it that way now, but in five years? Ten years? The direction is clear; our arrival certain. The only question is how fast we get there.


Many software developers have a pet peeve about customers calling their software “useless” (see here and here). It’s absolutely true that it can be infuriating to have all of your work declared “useless” because you didn’t implement some fringe feature. The uncomfortable truth, however, is that sometimes it’s true. The absence of a single feature really can render your software useless.

An alternate rendering of “useless” is “without use”. Or, in the semantics of software, “without a use case”. In software, a use case is a way of mapping out user interaction with software. It is generally a list of steps required to achieve a goal. When we start to understand “useless” in this way it becomes easier to see circumstances that would indict supposedly capable software as useless.

Imagine a microwave that didn’t let you set the time. You could no longer start it and walk away, trusting it to stop on its own. Thinking back to use cases, we can’t claim to meet a use case if a step is missing. The lack of a timer means that a whole class of use cases is eliminated. If one of those is the only use case of the owner, it really is useless to them. And importantly, it doesn’t matter what else the microwave can do.

I was reminded of this lesson with a recent Google Docs near-disaster1. I used Google Docs with a class project as I thought it would be a great answer to the need for collaboration and shared editing of the assignment. I had used Google Docs in the past for similar purposes but normally I would copy and paste into some other program (like Apple’s Pages) to do final formatting and printing. As my group’s document got larger, I decided I would use Google Docs the whole way through, saving myself the time it would take to copy, paste, and reformat. I did all my formatting in Google Docs and had a pretty nice looking document. When it came to getting the document out of Google Docs, however, the formatting would mess up in some significant way. It didn’t matter if I downloaded it as a PDF, Word doc, or other format the resulting document would be incorrectly formatted2.

Google Docs had gotten me 90 percent of the way there. Without that last 10 percent, however, the software was effectively useless for me. It didn’t matter what else it could do. It didn’t matter that I could collaboratively edit, or browse past versions, or view the document on my iPhone. It couldn’t finish the job.

As a result I’ll never use Google Docs except as a “roughing out” tool again (at least not for a few years).

This is part of the reason focus is so important in software. If you try to do too many things, and you do them all 80 or even 90 percent of the way, for many users you have created something that is no more valuable than if you had done nothing. Think about that. Even worse, you can actually create negative value, because you have convinced them to trap their data in your system that now can’t complete the job. It’s better to pick only those things you can do 100 percent and know that, at least in that area, you have created value for your customers.

I say near-disaster because printing directly to a printer did have the correct formatting, or correct enough that I felt okay turning it in. Return

This is all through the “Download As…” function of Google Docs, rather than some non-supported browser print-to-PDF functionality. Return


Loren Brichter on XPC, one of the new APIs in OS X and iOS:

I can’t fathom the extent of the innovation we’ll see, but even simple things that are impossible now like third-party apps sharing bits of themselves with other apps will be possible. I can also envision faceless apps, doing neat things for you in the background without presenting any UI and using minimal hardware resources. It can make third-party apps peers to the system-level Twitter and Facebook integration of today. We may also see much more ambitious apps, as Apple may relax some of their rules regarding arbitrary code execution, as long as you run the code in a super-sandboxed XPC process. That’s the one that has me really excited.

A Conversation with Loren Brichter

Decisions All the Way Down

A common complaint about Apple is that they think they know what’s best. Here’s a (poorly titled) example:

The general philosophy of [OS X Lion] seems to be “We know better”. A computer company that thinks it knows better than me how I should use my own computer?

This common complaint frustrates me, because it evinces a lack of understanding of what software is. Developing software is making decisions for the user. When you buy software you are paying the developer not only for their execution of their decisions (how well it works), but for the decisions themselves.

“Well,” you say, “they should at least give me some preferences.” Okay, what preferences should they have? Oops, looks like those arrogant bastards are making decisions for you again.

“I’ll code my own solution so I can decide what my preferences are,” you say. But dammit, those jerks have gone and decided what functions to include in the language you’re using to code! The nerve. Looks like you’ll have to move down to a lower-level language to code the functions that Apple so condescendingly excluded.

But what’s this? The Apple disease has spread! You’re now working in Assembly and the designers of that language have imposed all sorts of requirements on code structure and format! This is worse than you thought.

Turns out, it’s decisions all the way down.

You’re not going to solve this problem by using Windows, or Linux, or any other OS. They all make decisions. It may take longer for you to reach the edge of the software where those decisions become clear, but it’s there, and no matter the OS one day you’ll reach that far off horizon and possibly wish they had decided something different. And in the meantime how much time will you have wasted making decisions that could have been made for you?

I don’t begrudge anyone their right to complain about software decisions. I just wish they would frame it correctly. You’re not mad that Apple, or Microsoft, or whoever, is making decisions for you. You’re mad that they aren’t the decisions you would make.

It’s not possible to make software without “making decisions for the user”. That’s what software is. The success of software is largely dependent on the quality of those decisions. I choose Apple products because, at least right now, they make better decisions than anyone else.

The Web Isn’t Forever

It’s accepted wisdom that “the web doesn’t forget”. Unfortunately (or perhaps fortunately), it isn’t true.

Here’s just one small example. I saw Forrest Gump on TV last night. I often like to read reviews of movies I have seen as a kind of substitute for those pleasant after-movie chats with friends, so I looked it up on Metacritic. The movie was listed, and excerpts of reviews were there, but almost every link to a full review was broken. And these were big sites – Variety, Entertainment Weekly, and Rolling Stone, among others.

Forrest Gump came out in 1994, so perhaps that isn’t the most compelling example. But here’s another one. Recently I was reviewing some old emails and found several that I’d written to myself as notes for future blog posts. Each email had one or two links. Most of the links were dead. The oldest of these emails was from June 2008. That’s just four years ago. Hardly forever.

Some of these dead links can still be found via services like the internet archive, but not all.

The idea that the web doesn’t forget is generally talked about in the context of exercising caution with the images and words you choose to put on the web. That’s sage advice. But don’t take it too far. Don’t think that just because you posted something on the web you no longer need to concern yourself with keeping your own copy.

When you get down to the truth of it the web isn’t made up of anything new. It’s still humans and the elements – copper and oxygen and silicon, which we’ve just happened to combine and layer with such complexity that we can almost believe it is self-sustaining. It’s created by people that sometimes forget to do backups who work for companies that change business models (or go out of business completely) which use software that has bugs that runs on hardware that deteriorates and eventually dies.

Most of the time, unless there is money in it, everything eventually goes away.

The Carriers are Winning

If Verizon (or any carrier) wants to take this seriously, it’s very simple: let customers add unlimited devices to an existing data bucket for a reasonable monthly fee. $5, for instance. I could even understand $10, perhaps. But $40 for an extra smartphone?

Chris Ziegler, The Verge

That’s the carriers winning. Why should there be any charge at all for additional devices? If I get 10 GB a month, I get 10 GB a month. It shouldn’t matter what devices (or how many) I use.

By charging so much for each device, they successfully frame the debate around how much they should charge, rather than whether they should charge at all. If there was real competition in the cell phone service market this wouldn’t matter, but unfortunately there’s not.

The Mac App Store Needs Loyalty Pricing, not Paid Upgrades

The Mac App Store doesn’t support paid upgrades. Neither does the iOS App Store. This is a problem.

I’d certainly like to see paid upgrades in Apple’s app stores, but it would be even better if Apple took this opportunity to implement a solution that’s smarter than the “upgrade” process that most software has been using for years.

Traditionally, most paid upgrade processes deceive the customer. The process is designed to make the customer feel like they have literally “upgraded” their application, when it actually has been replaced. When you buy Adobe CS6, the installation process will “upgrade” CS5. In reality, it will throw it in the trash and put CS6 in its place.

For many customers this deceptive upgrade song-and-dance fits with what they think is happening – that some parts of the application, but not other parts, are being replaced. And this then fits in with the idea of reduced pricing for owners of the current software: “I’ve already paid for 100 percent of the current application, so if this upgrade is only replacing 50 percent of it, then I should only pay for the 50 percent being replaced.”

This, however, is often not accurate. If you get down to the actual code level who knows how much of the code is new. It could be all new. It could be half new. Or it could be that only 5 or 10 percent is new. Ultimately the relationship between the old and new application on the code level is immaterial to the pricing.

So what is upgrade pricing really? It’s a loyalty discount. So why not acknowledge it for what it is and make it work like a loyalty program?

The Mac App Store already has everything in place to create “loyalty pricing”, namely, a complete history of your purchases. Apple could create an API whereby developers define the criteria for discounts, and Apple merely executes them. Developers would not need to have any access to customer purchase data for this to work.

This solution would actually solve more than just the bland version 1 to version 2 upgrade scenario. It would also address pricing “suites” of apps. With the right API hooks, Adobe, for example, could charge less for Illustrator if you already bought Photoshop. This would approximate the bundle pricing that larger software makers often offer. It could even cut across the iOS/Mac divide, letting the customer purchase, for example, Byword on the Mac App Store at a reduced price if Byword on the iOS store was already purchased, and vice versa. This approach would dovetail nicely with Apple’s iCloud push, which encourages buying different versions (iPhone, iPad, and Mac) of the same application.

Loyalty pricing would keep the simplicity of Apple’s model of buying whole applications, but would allow software makers to reward their loyal customers through reduced pricing. It would also have the benefit of allowing customers to continue using their old applications while they tried out the new one because the old version would be removed at the customer’s discretion.

For this to work well there is one more tweak Apple should make to their stores. Currently there is no way for developers to provide updates to an application without it also being listed on the store (and therefore shown in search results and elsewhere). Apple should allow developers to “delist” applications while still being able to provide updates to them. This would remove the confusion of having multiple versions of the same product listed in the store.

Part of the appeal of the Mac App Store, and part of the reason developers are willing to give Apple a 30 percent cut of their revenue, is that Apple does a lot of the hard work of running a store for them. A loyalty pricing mechanism would be one more way for Apple to make that 30 percent cut make sense.