Robot Loves Kitten

IMDB is my kids favorite iPad app. He loves exploring movie trailers, and I love seeing how he learns to negotiate a tablet UI. It took him months to really get it down (I don’t let him play much), but this morning I watched him blast through a perfect sequence of button & menu clicks to get to the Cars 2 page. At this point though, he now gets irrevocably stuck. Why? Because a recent IMDB update completely broke the app.

The app is now riddled with featuritis. You can see evidence throughout, but go to a movie page, and find the “Watch Trailer” button. The one with the “play” icon. What might you expect that button to do?

It used to display a popup to select the quality of clip to play, which was confusing, but at least the options all led to the same place. You could click any of them, and you’d always end up watching the trailer.

Now? The popup includes an option for adding the trailer to a playlist, which adds the clip to a list (accessible at the bottom corner of the screen). Clicking effectively does nothing. As an adult, I’ve adapted to this garbage, but watching my kid continually get sucked into this trap is starting to piss me off.

A button that specifies quite clearly with icon and text that it will play a clip should not be adulterated to do anything else. Period. Any objection you have is misplaced. It either needs to be placed ahead of playing a clip, or moved to a parallel flow. Once you arrive at the context of playing a clip, you are done. Get out of the way, and play the damn clip.

Is this why “simple” is so hard to execute?

An interesting experiment would be to try user testing your app with all the menu and button text scrambled. Does the app still make intuitive sense to users? To you?

Yesterday I prepared my Nintendo Wii, which I never use anymore, for sale on Craigslist. I had to wipe it first, and for the first time, felt the sting of “digital rights management”. Obviously, I can’t give my Wii to someone else with my passwords and shopping account still on it, so I needed to remove those.

The only way Nintendo would let me do that was to completely nuke my account. Everything I’ve bought, my unused balance, my saved game files, everything … gone. My history and relationship with Nintendo as a Wii customer (and I’ve been a customer for many years and consoles) is completely erased.

I’m honestly shocked Nintendo would toss a customer relationship away so easily. Every console sold from now on will be connected to the Internet and will include an online shop. Customer accounts, history and purchases should always be retained unless the customer explicitly asks otherwise.

The RIAA is claiming that you don’t own your digital music, in order to squelch a new service designed to create a market for “used mp3s”. Since I always buy unencrypted mp3s, I never gave this much thought. But today, I was summarily stripped of my games, my gameplay and account history, and even my account balance, simply because I wanted to sell a collection of metal and plastic hardware.

I wasn’t breaking up with you, Nintendo. I just needed to take a break.

But now, I need you to know that we are done. I won’t be coming back. I can’t trust you to treat me like a person.

I just recently spent some time hacking up a simple Phonegap app, which proved a useful exercise in exposing the limitations of HTML5-based apps, and the naiveté of journos who parrot the “HTML5 or native apps” meme. There is a clear and simple answer behind “it depends on your app”.

In my Phonegap app, I needed to access the camera, but had strikingly limited options therein. The simplicity of the API made it easy, but decisions made either by the Phonegap team or Apple made the interaction with the camera clunkier than I would have liked. In Phonegap, accessing the camera is different than accessing the photo library, and upon taking a photo, you are presented with a preview screen you need to approve in order to return to the app. This was way too clunky (too many steps) for my app, which made the interaction, and thus the experience, pretty much unacceptable.

This exposed a major issue with HTML5 apps: whatever gains you make by leveraging HTML5/CSS/JS can easily be offset by the limitations and choices your app framework makes. Phonegap made decisions about how their framework would behave that were unsuitable for my particular app. Maybe this isn’t surprising, but it’s a subtle point, I think, that’s worth making. You are beholden to the framework for not only the features it supports, but the way in which it supports them.

So I would qualify my “it depends” answer to the “HTML or Native app?” question with this:

If you are accessing any device features, like the camera, that you need to customize, then you must go native if you want to control the experience.

If, however, your experience relies only on the features that the browser offers, then HTML5 will do.

All that being said, apps are about creating compelling experiences, and the “magic” your app generates. If your framework destroys that illusion, then it’s not the right choice.

I’ve been noticing what I’d consider UI mistakes in a few iPad apps of late. This is probably natural, given how new everyone is to the medium (yes, I think tablets are more than just a platform). But no time like the present for learning lessons, no?

Clear Magazine & Adobe

First up, Clear magazine. This app was done in conjunction with Adobe and shares features with the Wired magazine app. Adobe clearly seems to be building a magazine framework, which is great, but I have some questions.

First, why two tables of contents? In the app menu, there is a drop-down list-style index on the left, and a horizontal article preview explorer on the left, which contains much more info (title, excerpt, and preview thumbnail). The UX to have only one.

The first TOC is a simple list

The second table of contents is more appropriate at conveying the app's UX, IMO

Within articles, a bigger problem arises. Often, the enhanced media content breaks the navigation. To get to the following article, you swipe left-right to navigate between articles. But once you’ve clicked to enter zoomable mode, the swipe navigation is broken as is clicking to reveal the top nav bar. There’s no clear way to exit the article. Closing and reopening the app is no help either, since the app remembers your place.

Entering this article breaks the UI you used to get here

Getting out is a game?

Google’s catalog app

Inside Google’s new catalog app, we have a more subtle problem of context. When viewing a spread of products, you see clickable tag icons across the page. What happens when you click on one is slightly unexpected, IMO.

A catalog page with clickable product tags

Product detail view slides in as a pane

When clicking on a product — in the above case, I wasn’t even sure which product the tag was for — a full-screen pane slides in, obscuring the current page. I would have expected a smaller preview dialog with brief product details that I could easily toggle on/off using that same tag icon. This would have been a much smoother way to explore the page. The paned view might be appropriate if I’m looking for complete product information or if I’m ready to purchase, but I still find it a bit odd.

I have to blame Twitter, of course. :) The Twitter iPad app brilliantly pioneered sliding content panes, but in a much more straightforward way. Twitter panes follow a natural “drill-down” information architecture, and more importantly, they don’t completely obscure the way back out.

I think panes make sense for straightforward IA cases, or to show different facets of an app — a shopping cart, for example. Though I would not mix both. The iPad works best with natural UIs, and you have to keep those simple.

In May, just after the April 2011 Amazon Cloudpocalypse, Heroku experienced a DDoS attack on its service. In the aftermath, Heroku posted revised DNS guidelines, suggesting that root domains (example.com) not be used, in favor of subdomains (www.example.com).

Now this was pretty strange, since it ran counter to a trend that preferred root domains since they simplify URLs and branding. Most sites are configured so that example.com and www.example.com go to the same place, making the subdomain redundant. Given the choice, it is much more straightforward to just use the root.

In DNS, however, the two operate under very different rules. Subdomains are configured using a CNAME record, which can point to another domain (somewhere.com) or IP address (127.0.0.1, for example). But root domains have to use A records, which are only supposed to point to IP addresses, representing a particular physical computer server.

In cloud computing however, there is no concept of physical servers. Everything is virtual, which allows you to easily add, remove servers and other resources. Resources just appear, ready to be used.

What Heroku found was that during the attack, it needed to shift resources around to dodge the attacks. Because they’re on a cloud platform and they’re smart guys, they accomplished this feat easily. But many applications on their system weren’t able to mimic the dodge because they had their root domains chained to three immovable IP addresses.

If you tried to access your website at example.com, it wouldn’t respond, because your browser was trying to get info from one of the IP addresses, which were suffering the attack. However, if you tried www.example.com, you were talking to proxy.heroku.com (via CNAME record), which had already dodged the attack and was functioning normally.

I don’t pretend to understand the full implications of this, but it seems clear that ideas about how DNS should work aren’t relevant, or even compatible, with cloud computing. This, I imagine, gets some hardcore engineers pretty excited, since it means there is a growing need and opportunity to rewrite some of the rules about how the Internet works, and who wouldn’t want to be involved in that?

It makes me wonder about what other standard assumptions are also beginning to fray, and I find myself taking more time to consider well-established details, looking for loose threads to pull.

There’s been continual jockeying about whether HTML5-based web apps will eclipse native apps, ever since Apple announced its app platform for the iPhone.

In the article linked above, Mims touts several web app advantages: audience size, cross-platform compatibility, and a lower Google app store fee. None of these are necessarily true for your app. Apple’s customers buy more apps than any other, making them an extremely target-rich environment. Cross-platform compatibility is a myth; to do anything interesting you will need to dive into device-specific drivers. And the app store fee is irrelevant; all that matters are profits. Apple delivers a proven, end-to-end environment for developers.

But what makes the best native apps special and successful is what Web apps could have more difficulty with — the magic of a natural user interface (NUI).

NUIs power Angry Birds (drag the slingshot), Tiny Wings (touch to dive), Solipskier (draw the ramps) and countless other apps. It’s the natural user interface of GarageBand that allows it to effortlessly combine a recorder with a full orchestra of instruments that a 2-year-old can start playing with immediately (mine has).

Web apps are (critically) limited in the responsiveness of their UIs, relying on javascript frameworks running inside a browser. No doubt they will get better, for now, it’s unlikely that they will ever match a native app.

It may seem a minor issue, but that’s the thing with magic — the slightest crack in the illusion will shatter it. Smart developers invest in their illusions, and use tools that enhance them.

The NYT announced its paywall plans, and the mediasphere is aflutter about what it might mean. To summarize, the Times will start paid subscriber plans (that most feel are expensive), but allow Web visitors 20 free articles per month, and will allow unlimited access to articles linked to from Twitter or Facebook.

This is the new classic: the hybrid business model combining advertising and subscriber fees. Same as it ever was. But will it work? I don’t think so.

Online advertising works in two extreme modes: CPM and CPC. CPM is cheap so you have to serve up millions to make money. CPC is expensive, but you have to accurately target your users (like those about to buy a camera) to make any money. Print media historically enjoyed the luxury of both, without having to deliver on either, simply because advertisers didn’t know any better. Now that the Internet exists, they do.

Subscriber-based models work great online, but there’s one catch. You have to deliver a lot of value to your users. You do this by digging deep into a subject area: Cooks Illustrated works because they deliver a lot of value to home cooks. The Economist still works because they deliver value to the global-minded finance crew. ThinkVitamin works because they’re teaching you to be better at your job (or get a better one).

So, the Times continues to sit on the fence, enjoying the revenues banner advertising brings in, but worried enough about falling CPMs that they are erecting this subscribers plan. The big questions: will traffic fall, decimating their banner revenues? And will subscribers join, offsetting the loss (and begetting future growth)?

So will traffic fall? Yes, it probably will. But even if it remained flat, that would be a loss for the Times. Remember, CPMs are falling. That means traffic has to grow a lot if you expect to continue to pay for stuff like writers. Social media has established itself as the grease in the media wheels, as The Huffington Post so aptly proved, and any friction you add to that system (like a paywall) will effectively kill your momentum. Twitter works because its fast. Slow it down, and all you’re left with is Hotmail.

Will subscribers join? This is a bigger question. What the Times and most media organizations fail to realize (and when I say that, I mean institutionally) is that there is a big difference between the readership outside and inside the paywall. You have to be prepared to not care about those outside, and to fawn over the ones inside.

Because the company relies so heavily on advertising, it’s unlikely they will ignore their outside readers. And because it’s early in the game, and no one’s fully sure, and they’re journalists after all (who are committed to nothing like writing about whatever they feel like writing about), it’s doubtful that they will fully commit to changing their content to be more valuable to their paywall readers. And so it will go, tilting up and then down, and eventually, as renewals come along, the numbers will start to slide down and to the right, unendingly.

It comes down to this: Cooks Illustrated is a very different magazine than Cooking Light. The Huffington Post is a very different paper than the NYTimes. They all provide different value propositions and are held to different standards by readers. It remains to be seen if the Times is prepared to start serving the needs of a paying readership or the needs of its advertisers. Or it might just continue its old ways, pretending to serve both masters, while secretly serving itself.

To be fair, I haven’t downloaded the app yet. But this video shows the dangers about too much UI in an iPad app. This is what I was warning against when I introduced the idea of using Lazy UI in regards to a comfortable, magazine-like experience of one-handed interaction on the iPad. The Daily seems almost too interactive, frankly.

What media companies can’t seem to wrap their heads around is the single-serve nature of apps. Instapaper makes reading articles great — and that’s it. Marco would never add sudoku puzzles!

It pains me that I have yet to see a news app that really deep dives into the news — the stories behind the stories, the facts and figures, the personalities, the history. Granted, this is a challenge that requires linking up a lot of structured data, but if there isn’t a great app in that, then maybe it’s time to get out of the news business.

IMO, the NYTimes will build this app first and potentially own the space. To everyone else, good luck with those sudoku puzzles.

That’s a mouthful of a title! I have been trying to create new posts on a WordPress blog via XML-RPC and CodeIgniter, but couldn’t get the categories applied properly. Here’s how I got it working (no guarantees this will work in every situation, or that it will work in an hour).

I am using CodeIgniter’s XMLRPC library and the metaWeblog API. To get categories inserted with a post, you first need to know the names of the categories — you can do this via metaWeblog’s getCategories method — in this case, I hard-coded the values into my request for easier testing.

Put the category names into an array, and pass the categories array into the post data, appending ‘struct’ after the array (the ‘struct’ is the important part).

$categories = array("Uncategorized", "Blogroll", "Reviews");
$blogpass = $blogpass;
$blogid = 1;
$publishImmediately = TRUE;
$thePost = array(
array(
'title' => array($post['title'],'string'),
'description' => array($post['text'],'string'),
'categories' => array($categories,'struct'),
'post_type' => array('post','string'),
), 'struct');
$this->xmlrpc->server($blogurl, 80);
$this->xmlrpc->method('metaWeblog.newPost');
$request = array($blogid, $bloguser, $blogpass, $thePost, $publishImmediately);
$this->xmlrpc->request($request);
$result = $this->xmlrpc->send_request();

One of the dangers of moving from the small canvas of a mobile device to a larger tablet is the explosion of UI elements and controls one can expose in their application. We’re starting to see some backlash as some apps push the boundaries of usability, and will probably see much more as developers begin to add advertising and other common web site elements to their apps, confusing and cluttering the interface.

Taking a strong cue from spare, effective mobile apps would seem critical now that it’s easy to add this or that widget to please whomever is politicking for presence. Tablets are a new platform, and need to be treated carefully, lest users lose their way.

To help calm the seas, I’ve been thinking about the concept of “lazy UI”, in which UI elements are grouped by function and modes, creating the least user friction. For example, while reading, a user could page up/down and browse articles (right/left) using controls grouped together in one corner of the interface. The idea is not to spread reading controls across the screen (a common approach), but to keep them close to the active finger or thumb as possible, allowing the user to stay in a relaxed “reading” mode, and not have to struggle been the more passive experience of reading and the active experience of navigation.

There are a lot of good examples of this approach out in the wild, and I’ll try and collect a few to display here.