The One Platform Is Dead

I used to strongly believe the future of apps would be rooted in web-technologies such as HTML5. Born cross-platform, they’d be really easy to build, and bold new possiblities were just around the corner. I still believe webapps will be part of the future, but recently I’ve started to think it’s going to be a bit more muddled than that. If you’ll indulge me the explanation will be somewhat roundabout.

The mobile era in computing, more than anything, helped propel interface design patterns ahead much faster than decades of desktop operating systems did. We used to discuss whether your app should use native interface widgets or if it was okay to style them. While keeping them unstyled is often still a good idea, dwelling on it would be navelgazing, as it’s no longer the day and night indicator whether an app is good or not. In fact we’re starting to see per-app design languages that cross not only platforms, but codebases too. Most interestingly, these apps don’t suck! You see it with Google rolling out Material Design across Android and web-apps. Microsoft under Satya Nadella is rolling out their flatter-than-flat visual language across not only their own Windows platforms, but iOS and Android as well. Apple just redesigned OSX to look like iOS.

It feels like we’re at a point where traditional usability guidelines should be digested and analyzed for their intent, rather than taken at dogmatic face value. If it looks like a button, acts like a button, or both, it’s probably a button. What we’re left with is a far simpler arbiter for success: there are good designs and there are bad designs. It’s as liberatingly simple as not wearing pants.

dogma (noun)
a principle or set of principles laid down by an authority as incontrovertibly true

The dogma of interface design has been left by the wayside. Hired to take its place is a sense of good taste. Build what works for you and keep testing, iterating and responding to feedback. Remembering good design patterns will help you take shortcuts, but once in a while we have to invent something. It either works or it doesn’t, and then you can fix it.

It’s a bold new frontier, and we already have multiple tools to build amazing things. No one single technology or platform will ever “win”, because there is no winning the platform game. The operating system is increasingly taking a back seat to the success of ecosystems that live in the cloud. Platform install numbers will soon become a mostly useless metric for divining who’s #winning this made-up war of black vs. white. The ecosystem is the new platform, and because of it it’s easier than ever to switch from Android to iOS.

It’s a good time to build apps. Come up with a great idea, then pick an ecosystem. You’ll be better equipped to decide what type of code you’ll want to write: does your app only need one platform, multiple, or should it be crossplatform? It’s only going to become easier: in a war of ecosystems, the one that’s the most open and spans the most platforms will be the most successful. It’ll be in the interest of platform vendors to run as many apps as possible, whether through multiple runtimes or just simplified porting. It won’t matter if you wrote your app in HTML5, Java, or C#: on a good platform it’ll just work. Walled gardens will stick around, of course, but it’ll be a strategy that fewer and fewer companies can support.

No, dear reader, I have not forgotten about Jobs’ Thoughts on Flash. Jobs was right: apps built on Flash were bad. That’s why today is such an exciting time. People don’t care about the code behind the curtain.

If it’s good, it’s good.

Erase and Sync

eraseandsync

I don’t even want to try to explain what’s going on here. I mean, I understand it, but I don’t understand it. I don’t see how it’s in anyones interest for it to be flaming-hoops difficult to sync a device to a new Mac. Seriously, Apple, how did this pass your “it just works” razor?

Sync

For years my lunatic Apple friends have asked me: “when are you going to get a Mac?”. When I finally did, they started asking me: “when are you going to get an iPhone?”. As iOS is growing increasingly more useful with good notifications and over-the-air updates, my answer has been trimmed down to when it has a Gmail app that’s as good as the Android one. “Gmail with IMAP works great” is the usual knee-jerk reaction and “what’s so special about the Gmail app?” the followup question. I’m thinking perhaps it’s time I change my stock answer. I think my new response will be: sync.

This morning on my way to work I was listening to Macbreak Weekly. A bunch of my heroes, including John Gruber, were talking about iCloud sync and the problems some of them were experiencing. Tonya had factory reset her iPhone several times trying to get contacts to sync properly. Andy jokingly suggested the merging of contacts was painful and would sometimes merge 17 different versions of the same contact into a lean 12. Chris suggested it was a good idea to make sure you had a backup of the contacts, calendar and email setup you considered “canonical”, before embarking on your iCloud adventure. When the team started talking about the supposed iOS 5 battery drain, iCloud was almost universally assumed responsible for this.

Grubers level-headed approach was that, while he apparently had no problems himself, he did believe Apples iCloud transition was going to be monumentally difficult and compared it to stepping from solid ground on to a boat while carrying valuable trinkets. Transitioning MobileMe customers to a new free setup, making sure not only calendars, email and contacts sync, but also documents, was bound to generate some headaches, but they’ll pass in time, he suggested. I agree, I’m sure things’ll improve once Apple is on the boat.

Perhaps there is something to be said about Apples approach to sync. As much as they tout that “the truth is in the cloud” — as Yogi Berra would say: that’s only true when it’s true. It’s no secret Apple loves native apps. Native apps run faster, smoother, nicer than web-apps. You’ll hear many chant this, they might even use allegories such as “being closer to the metal” when describing why a web-app can never be as good as a native app. Let me tell you this: Yogi Berra doesn’t care. If it works, it works. If the app is good, it’s good. If things sync, things sync. And if they don’t sync properly, they don’t sync properly.

Googles overarching approach to sync is to not sync. Push the changes immediately. When you add a bookmark to your Chrome browser, a teensy signal is immediately sent to Googles bookmark sync server pushing the change. When you finish typing a word in Google Docs, changes are saved. There is no sync, because there are not copies of files anywhere. There is only one file. There is only one email. There is only one contact. You’ll never have to worry about whether your Android phone, tablet, or Macbook has the most recently edited version of your document, or which one has the most complete contact, or which calendar you added an event to. Because everything is always in sync. It just works.

You’d think it would get muddy if you scratched the surface and peeked underneath. If you do, you’ll find that Android sync is actually asynchronous, and that if you use Google Docs’ offline editing capabilities, you’ll actually end up with some of the same sync challenges that Apple is facing: which version is the right version? Somehow I’ve never once had a problem with this, though. I don’t know if it’s because Google started with the web-apps and built native apps and offline sync at a later time, but I have no trust issues with Google getting my sync right. I know that if I visit google.com/contacts and edit a contact, my changes will propogate to all my devices seamlessly. I never have to worry about losing contacts, losing appointments, losing emails, getting corrupt data, or even backing up. While these words may smell like famous last words, I wouldn’t even think of backing things up. I expect it to work, I trust that it will work, and has done so far.

Compared to the flaming hoops I had to jump through to get just calendars, contacts and Gmail to sync on my wifes iPhone, using an Android device is just a relief.

Prior Art

Do the tablets in Kubricks 2001 movie constitute “prior art” to the iPad?

This question recently incited much heated discussion on Twitter1. What made this spike my interest in such a fashion is my love for science fiction, and in particular the works of Arthur C. Clarke. Many of his ideas specifically, came to fruition decades later. For example, in 1945 Arthur C. Clarke inadvertently invented satellites. He didn’t patent them; as he put it:

I’m often asked why I didn’t try to patent the idea of communications satellites. My answer is always, “A patent is really a license to be sued”.

Now Clarke merely described what would later become satellites. He didn’t build one, nor did he design how such a thing looks. And indeed satellites today come in all manner of configurations and designs, yet they are still, clearly, satellites.

These days Apple is busy suing Samsung for infringing on Apples look and feel patents with their Galaxy line of phones and tablets. Put simply, Galaxy S phones are too like the iPhone, and the Galaxy Tab 10.1 is too like the iPad. While the comparison photos in the suit filing appear to have been doctored2, I’m not going to argue that Samsung TouchWiz is inspired by Apples iOS (which it clearly is)3.

Focusing on what sparked this discussion — could the tablet devices seen in the 2001 movie constitute prior art for the iPad — I do think that’s fair to say and I’ll get to why I think that is. Whether or not they’re merely portable televisions, they are electronic devices and their form factor is certainly strikingly similar to that of the iPad. But is it prior art?

Prior art:

Prior art […], in most systems of patent law, constitutes all information that has been made available to the public in any form before a given date that might be relevant to a patent’s claims of originality. If an invention has been described in prior art, a patent on that invention is not valid.

To be specific, Apple is suing Samsung over 4 patents. Two of those are related to the iPhone form factor. One is related to how iOS works. The fourth patent is over the tablet form factor; here’s the illustration from the patent application:

ipad_patent

If you explore the patent application itself (beware, TIFF file), you’ll note that no specific size is noted in the patent application. The tablet illustrated doesn’t necessarily have a 10 inch screen.

Samsung is in a tight spot. While I find it surprising (and disappointing) that these four patents were granted in the first place, they clearly appear to have been infringed upon. Were I in Samsungs shoes, (and if I were I’d never have released TouchWiz in the first place) I’d be doing everything I could to defend against this suit. Certainly if I was able to find prior art that invalidated any of the four patents in question, I’d look wherever I could, even in my old sci-fi DVD collection. In the case of that one patent Apple has on the tablet form factor, I do see why Samsung would try and invoke prior art on that (though I’m surprised they didn’t pick Picards tablet instead). You see, if Samsung can convince the judge that patent #4 is invalid — that the slabs shown in 2001 are reminiscent of the pencil sketch shown above — it would cut their woes by a fourth.

Samsung is not my favorite Android vendor. They’re not even my favorite hardware vendor. Perhaps it would be good for them to suffer a defeat at the hands of Apple.

But I do consider Arthur C. Clarkes description of a satellite to be prior art. I consider Larry Nivens description of a ring-world to be prior art to the ring shown in the Halo video game. And so, hearing Samsung cite Kubricks tablets as prior art to the iPad is not the dumbest thing I ever heard. Apples tablet is a wonderful combination of a well-designed user-experience and durable, delicious hardware. Even so, the form factor described in their tablet patent is not a unique snowflake, as countless sci-fi authors would have you know.

  1. I feel I should apologize to those of you who happen to follow both me and Heilemann on Twitter for having polluted your streams.  
  2. For example, scaling down the Tab and opening the App drawer for the photo op instead of comparing the homescreen to the homescreen.  
  3. In fact I loathe Android skins in general and would like nothing more than Apple forcing Samsung to improve, or better yet rid the world of TouchWiz  

Apples App store demo policy: does “Lite” count?

Timed to perfectly disrupt CES, Apple opened their App Store yesterday.

appstore

The App store is software for Macs which makes it easy to find, download and buy new apps. It’s generally acknowledged that it’s going to be a huge success, though there’s been some controversy, mostly from developers:

  • Apple takes their usual 30%
  • Buy once, download as many times as you like (the Steam model)
  • There are no demos

The demo aspect is what’s interesting to me. Supposedly this mimics the Apple iOS App Store, where demos apparently arent’ available either. Which confuses me, because I’m sure I’ve tried free demo versions of full games on a number of occasions. Oh right, they were called “Lite” versions. So what’s the deal here? Are demos actually fully welcome in the App Store, as long as they’re simply named “Lite” or “Express”? Is it simply an issue of silly semantics?

Here’s the Apple law of the land:

2.6 Apps that are “beta”, “demo”, “trial”, or “test” versions will be rejected.

7.4 Apps containing “rental” content or services that expire after a limited time will be rejected.

I don’t particularly object to these rules, though I do like to try a demo version before I shell out the dough. If Apple had gone the Android route, however, this problem could probably have been solved with a refund window. As it stands, however, we have Lite and Express versions, but no demos. So what’s the difference between a Lite version and a demo version? Particularly in the context of games, this is what I was able to come up with:

  1. Some game demos expire after a set amount of time. I’m pretty sure this is a rejection reason.
  2. Some game demos have, say, 10 levels of a game and require you to purchase the full version to get the remaining levels.
  3. A few game demos, say space shooters, provide all the levels but don’t allow you to upgrade your weapons or try better ships.

Barring #1, would #2 and #3 reject you from the App Store if you called your demo “lite”? And how about circumventing these rules by simply linking to a downloadable demo from the App Store product page? I don’t have any answers, only a confused look on my face. Are we looking at an App Store that for all intents and purposes still have demo versions, just a different kind of demo version?

The peculiarly bad situation with web-fonts on Apples iPad

I’ve thrown a lot of love in the general direction of Apples open source WebKit lately. It looks like WebKit, moreso than Firefox, has ousted every other browser as the rendering engine of choice for a richer web. Unfortunately, I’m about to throw something other than love at WebKits little-sister, Mobile Safari. Why? Because it’s useless at web-fonts.

Typekit’s talked about it:

Rendering multiple weights from a font family can cause Mobile Safari to crash, even when the individual font file sizes are small (<5k). In our testing, using two weights from a family caused Mobile Safari to crash on up to 50% of attempted page loads, and the crash rate seemed to increase as we increased the number of weights we added.

So that means you can use ONE weight of a web font. “Regular”, for instance. But you can’t use that fonts “Bold”, “Italic” or “Bold Italic” versions.

Just recently I wanted to use the glorious DejaWeb font for a project, and now that all the major browsers support web-fonts, I quickly fed the fonts to FontSquirrels excellent multi-platform font-converter and was output something that was supposed to work in all the browsers. EOT for Internet Explorer, WOFF for Firefox, TrueType for WebKit and SVG for Mobile Safari. Everything seemed to work just perfectly. Except of course for the intermittent crashes on the iPad.

A Temporary Solution

Now since the bug has been filed and Apple will probably fix this in some unannounced not-soon-enough future (maybe the iPad will get multitasking and font-face support at the same time?), I’m not going to waste any more tears. Instead I’m going to let you know what I did to deal with this issue.

At first, I worried that I wouldn’t be able to use DejaWeb at all, since this project had to be at least compatible with the iPad. I didn’t want to look into CSS hacks or JavaScript to detect user agents to then serve web-fonts to only capable browsers, carefully omitting the fonts for the iPad. Then it dawned upon me, a realization that in retrospect is embarrassingly simple (pointing and laughing for a little while is okay). Since MobileSafari can only render fonts converted to SVG, the solution to the crashes was to simply not serve an SVG font. Or in my solution, serve it only one SVG file: DejaWeb Regular.

@font-face {
	font-family: 'DejaWeb';
	src: url('fonts/DejaWeb.eot');
	src: local('DejaWeb'), local('DejaWeb'), url('fonts/DejaWeb.woff') format('woff'), url('fonts/DejaWeb.ttf') format('truetype'), url('fonts/DejaWeb.svg#DejaWeb') format('svg');
}

@font-face {
	font-family: 'DejaWeb';
	font-weight: bold;
	src: url('fonts/DejaWeb-Bold.eot');
	src: local('DejaWeb Bold'), local('DejaWeb-Bold'), url('fonts/DejaWeb-Bold.woff') format('woff'), url('fonts/DejaWeb-Bold.ttf') format('truetype'), url('fonts/DejaWeb-Bold.svg#DejaWeb-Bold') format('svgFIXME');
}

@font-face {
	font-family: 'DejaWeb';
	font-style: italic;
	src: url('fonts/DejaWeb-Italic.eot');
	src: local('DejaWeb Italic'), local('DejaWeb-Italic'), url('fonts/DejaWeb-Italic.woff') format('woff'), url('fonts/DejaWeb-Italic.ttf') format('truetype'), url('fonts/DejaWeb-Italic.svg#DejaWeb-Italic') format('svgFIXME');
}

@font-face {
	font-family: 'DejaWeb';
	font-weight: bold;
	font-style: italic;
	src: url('fonts/DejaWeb-BoldItalic.eot');
	src: local('DejaWeb Bold Italic'), local('DejaWeb-BoldItalic'), url('fonts/DejaWeb-BoldItalic.woff') format('woff'), url('fonts/DejaWeb-BoldItalic.ttf') format('truetype'), url('fonts/DejaWeb-BoldItalic.svg#DejaWeb-BoldItalic') format('svgFIXME');
}

Notice how I’ve invented a new font format called “svgFIXME”? Yep, that stays until the iPad can render SVG fonts in more than one weight. Until then, plain old regular it is. Even for bold-face text. It’s better than a crash, right?

The Windows iTunes Install Process, Archived For Posterity

This is a series of screenshots chronicling the install of iTunes on Windows. Behold:

iTunes_Setup_01 iTunes_Setup_02 iTunes_Setup_03 iTunes_Setup_04 iTunes_Setup_05 iTunes_Setup_06 iTunes_Setup_07

At this point, I’d like to remind viewers that in step 4, I unchecked the “Use iTunes as the default player for audio files” and “Automatically update iTunes and other Apple software” options, so you’d think you wouldn’t get all sorts of services and update apps installed. Not so:

iTunes_Apps iTunes_Services