Gizmodo Reviews Opera Mini 4.2 Beta for Android
Doesn’t sound fully baked. And using the Android hardware Back button this way sounds like it’s completely against the Android interface guidelines. Something like this wouldn’t fly on the iPhone. (Opera Mini is the cross-platform mobile-optimized version of Opera that I wrote about a few weeks ago.) â
-
â Regarding Opera Mini and the App Store
I’ve done some digging on this “Opera Mini was rejected from the App Store” story, and the truth appears to be very different than what has been reported and assumed. It all started with this paragraph from Saul Hansell on the NY Times Bits weblog, regarding Opera CEO Jon Stephenson von Tetzchner: Mr. von Tetzchner said that Operaâs engineers have developed a version of Opera Mini that can run on an Apple iPhone, but Apple wonât let the company release it because it competes with Appleâs own Safari browser. Note, though, that this is not a quote from von Tetzchner — he’s being paraphrased by Hansell. My understanding, based on information from informed sources who do not wish to be identified because they were not authorized by their employers, is that Opera has developed an iPhone version of Opera Mini — but they haven’t even submitted it to Apple, let alone had it be rejected. One thing I hadn’t realized before is that Opera has two different mobile browsers: Opera Mini and Opera Mobile. Opera Mobile is pretty much a traditional, regular web browser. It’s Opera, but stripped down and optimized for mobile platforms. Opera Mini, though, is something else. Rather than a web browser that interacts with web sites directly, Opera Mini goes through proxy servers run by Opera. In a nut, it works like this: You request a URL in Opera Mini. Opera Mini makes the request to a proxy server run by Opera. Opera’s proxy server connects to the web server hosting the requested URL, and renders the page into an image. This image is then transmitted (in a proprietary format called OBML — Opera Binary Markup Language) to the Opera Mini client. Opera Mini displays the rendered image on screen. This may sound convoluted, but apparently the result is very effective — it’s faster to transmit, because only OBML (a compressed binary format) is transmitted to the mobile device over the phone network, and far faster to render on slow mobile processors. It is Opera Mini, not Opera Mobile, that Hansell indicated that Apple rejected. So, my speculation that it was rejected from the App Store for running its own JavaScript interpreter was wrong — Opera Mini is really only a thin client that knows how to display OBML. It doesn’t even render HTML, let alone contain a full JavaScript interpreter. (Chris Mills wrote a piece on the Opera developer weblog last year regarding Opera Mini and JavaScript.) OBML is more like PDF than HTML. So in theory, I think a version of Opera Mini that complies with the iPhone SDK Agreement could be developed. However, the version that Opera has developed for the iPhone is problematic in other ways. The cross-platform code base for the Opera Mini client software is written in Java. The assumption being that it should run on any mobile phone with a Java ME virtual machine. The iPhone, of course, doesn’t support Java in any form. On the Opera Labs web site in April, Chris Mills described how they ported Opera Mini to Android. Android uses the Java programming language for development, but doesn’t use a standard Java virtual machine; instead, for Android, Google has developed their own virtual machine called Dalvik. Here’s Mills’s description of how Opera ported it for Android: We decided to use the existing Opera Mini code base (even the binary package) instead of creating a separate port, to save on resources. We created a special wrapper that translates Java ME (mostly MIDP) API calls into Android API calls. The tool used was MicroEmulator — this is an open source (LGPL) implementation of Java ME that runs on top of Java SE. The lead Opera Mini Android developer is also the lead developer of MicroEmulator, so it was an inspired choice! The Android platform is similar to Java SE, with the exception of several libraries normally included in Java SE (like AWT/Swing — these are excluded because they would likely be too heavy to fit into the embedded environment.) It is therefore fairly simple to port MicroEmulator to run inside Android environment. The only major task was to replace the AWT/Swing graphics backend of MicroEmulator with Android specific APIs. So in short, they’ve written their own bridge to run Java ME bytecode on Android. If what they’ve done for the iPhone is along the same lines — that they’ve gotten a Java ME runtime running on the iPhone — it’s clearly outside the bounds of the iPhone SDK Agreement. The guideline in question is rule 3.3.2, which reads: 3.3.2 — An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s). My somewhat informed hunch is that the iPhone version of Opera Mini that von Tetzchner alluded to in his interview with Hansell is running only on jailbroken iPhones. If it’s using APIs only available on jailbroken iPhones, it might not even run as it stands today on a standard iPhone using only the official APIs. What Opera would need to do to have a version of Opera Mini they could submit to the App Store would be to port the entire client software to the C and Objective-C APIs officially supported on the iPhone. It could well be that even then, Apple would reject it from the App Store on anti-competitive grounds — but contrary to this week’s speculation, that has not happened. And I hope it wouldn’t, because Opera Mini sounds like a very cool app.
-
In Case You Missed It: Apr. 11 - Apr. 18
Well, we've had time to calm down after the big iPad release and the announcement of iPhone OS 4.0 quickly followed by the release of the new MacBooks. So it's been a pretty heady last few weeks. Let's all take a couple deep breaths, relax, and gird our loins for the upcoming iPad 3G release. As we're girding, however, what better way to relax with than a roundup of the best of the best â you know what we're talking about: the greatest show on earth, as put on by the staff of Mac|Life.Features:- Think Your Mac is Secure? Think Again - We all like to brag about how secure our Macs are, how we don't have to worry about virus infection, how we don't have to buy and format some kind of internet security software, all that. Well, yeah. We all know it's because hackers don't really worry about the Mac platform due to its size. But how does the Mac stand up to a concerted effort? Well...- How To--And How Not To--Keep Your iPad Clean - There's all kinds of advice out there right now for taking care of your brand spanking new iPad. Don't listen to a bunch of bozos who are just trying to sell you stuff. Listen to the people who know, like us. For instance, who else has got the tip to not put your iPad in the dishwasher? Yeah, that's right, we went there.How-Tos: - Seven Amazing Uses for Hazel - Back when we were very young Mac|Lifers in the old Apple IIe days, there was a show on during the day about an invaluable house keeper named Hazel. No matter the problem, she solved it. Noodlesoft's program is just about as invaluable, and if you've had your Mac very long or you use it for everything, by this point, you've got a bit of digital clutter. Our favorite feature? Hazel can be set to automatically sort downloads, so .mp3s end up in iTunes and you don't have to drag them there.- How-To: Fix Crashing Apps on Your iPhone and iPad - By now you've found out that apps crash. You start them up, get them running, perform one specific task, and boom â back to the home screen. Lather, rinse, repeat a few times and you're just about to throw your beloved iPhone or iPad through a window. It's not their fault! Easy does it, kids, calm down, and let the Mac|Lifers show you how to take care of it. Reviews:- First Look: Adobe Photoshop CS5 - It's the 20th anniversary, and you just know Adobe's been cranking it extra hard to make CS5 one of the sweetest updates to everyone's favorite digital publishing, photo editing, website creation software. Content aware fill is probably the best example of how cool this is, but they didn't stop there. Have a look at some of the goodies we uncovered.- Bento for iPad - You knew it was coming. For lovers of Bento for the Mac, the big screen of the iPad just makes sense. It may miss a few features, as do other software we've come to love on our desktops, but as a mobile extension, it really can't be beat.News:From our perspective, one of the biggest non-iPad related news was the release of Opera Mini at the App Store. It's breezy fast, though it renders pages weird, and none of your secure pages go through Opera's servers; what's not to love? Now where's our mobile Firefox?...the folks at Lifehacker share our love of Opera mini; can we say it again? Why not Mozilla's Fennec now?...what is coming to the App Store hopefully, is Boxee, as long as they can get some developers to join them; somehow we don't think this is going to be a problem...after all, ABC's app for watching their shows on the iPad has proved a bona fide hit; can Hulu NOT be working on something? please....of course, still king of the apps is none other than Doodle Jump which is crazy addictive.So it looks like Google's firing right back in the big Apple/Google war as they struggle to put together an Android based tablet....(not that this stopped them from getting their Google app to the iPad PDQ)... but Google willll have to move fast on their tablet because Apple stores are struggling to keep the iPad in stock as demand has exceeded expectations pretty hard....so hard in fact, that the poor international market gets their release date pushed back....but don't waste your money on an Apple branded iPad sleeve, when you could just as easily make something sweet from a bubble envelope and some duct tape....missing from the iPad lately? that file sharing we all saw in the keynote. Maybe that'll turn up in OS 4.0...we'll definitely want to see mobile traffic stats after that 4.0 release; the stats for iPad release day had that handy device accounting for a full 5% of all mobile traffic...because everyone loves their iPad and will love it more and more if this analyst's predictions of 7 million sold in the next 12 months comes true...and you know who else loves the iPad? Yeah, sweet little old ladies like Betty White and who doesn't love Betty White?Hardware news was all the rage with the new MacBooks out there on the market and they are flying off the shelves...which will definitely continue the trend of Apple's PC market share growing and growing and growing...and the new update for MacBook Pros' software is either a good thing (getting some tweaks) or a bad thing (demonstrating that Apple may be rushing releases timed to marketing more than quality); you be the judge....at the very least we can say that these babies are turbo-fast, especially the 15 inch core i7...although the the core i3 didn't make it to the machines for the usual speed and battery power configuration issues Apple usually cites in these cases...and finally Steve Jobs himself comes out to reassure us that Mac OS X hasn't been forgotten in all the mobile development that's been super important lately.
-
â The iPad
Back in December, here’s how I concluded my piece on what I expected from Apple’s then-still-unannounced tablet: If youâre thinking The Tablet is just a big iPhone, or just Appleâs take on the e-reader, or just a media player, or just anything, I say youâre thinking too small â the equivalent of thinking that the iPhone was going to be just a click wheel iPod that made phone calls. I think The Tablet is nothing short of Appleâs reconception of personal computing. After the iPad was announced, I got two types of emails from readers. The first group saying they were disappointed, because they had been hoping I was right that The Tablet would be Apple’s reconception of personal computing. The second group wrote to tell me how excited they were because I was right that The Tablet would be Apple’s reconception of personal computing. Count me in with the second group. Apple hasn’t thought of everything with iPad, but what they’ve thought about, they’ve thought about very deeply. I got mine Saturday morning, and I’ve been using it since — or at least as often as I could get it away from my son. Here are my thoughts. The Big Picture The whole thing feels fast fast fast. The only thing that feels slow overall, so far, is web page rendering. Not because it’s slower than the iPhone — it’s not, it’s definitely much faster — but because it’s so much slower than my MacBook Pro. It’s easy to forget on modern PC-class hardware just how computationally expensive HTML rendering is. The funny thing is, the iPad, in raw CPU terms, is a far slower machine than a modern Mac. But the iPad is running a lightweight OS and lightweight apps. It’s like a slower runner with a lighter backpack who can win a race against a faster runner wearing a heavier backpack. Thus, many of the things you do are faster, or at least feel faster (which is what matters), on the iPad than the Mac. Like, for example, launching applications. The built-in apps, and many of the third-party apps I’ve been using the most, are ready to use within a moment of launching them. (Games tend not to load instantly, but that’s true on high-power consoles like Xbox and PS3, too.) There’s something fundamentally strange about how fast the iPad feels considering how underpowered it is versus a modern PC or Mac. How can a computer with so much less CPU speed feel faster? What Apple has done is re-think several fundamental aspects. The iPad was designed from the ground up with a different set of priorities. I think Tim Bray summarizes it well: For a 1Ghz device with limited memory, the iPad is unreasonably fast. I suspect this accounts for a whole bunch of the âWow!â reaction the iPad obviously provokes. Since thereâs no free lunch, I think itâs really important that we understand what they sacrificed to get that performance. My bet would be on some combination of windowing and virtual memory. I tend to work on lots of things at once, but in fact I look at things in rapid succession, my eyes can really only focus on one thing at one time. Given sufficiently fast switching, maybe we all ought to be getting less WIMPy. The iPad (and iPhone OS across all devices) does indeed lack virtual memory. The only memory is honest-to-god RAM. RAM is fast, virtual memory is slow. The tradeoff is that without virtual memory, the iPad can do far less at once, but what it does do is never going to require hitting virtual memory. Without a windowing system, drawing is simpler and faster. Apple has made other significantly different tradeoffs as well. Battery life on the iPad is simply stunning. Reviewers across the board are getting real-life results that beat Apple’s promise of 10 hours of battery life. This is a function both of software (which does less and works hard to keep the CPU from drawing power while the iPad is being used) and hardware — iFixit’s teardown shows that, internally, the iPad looks more like a battery with a computer than a computer with a battery. The iPad, so far, never gets warm. Browse a bunch of web sites. Play some video. Play a game. It still feels as cool to the touch as when it’s turned off. It is also dead quiet — no fan, no humming, nada. This is the future of computing. The iPad was designed with an entirely different set of priorities than Macs or PCs. Someone may well produce a worthy iPad rival in the next year, but it’s not going to be something like HP’s Slate that runs Windows 7, an operating system that epitomizes the traditional set of computer design priorities. The iPad is also eminently affordable. $500 for this thing seems hard to believe. I wouldn’t hesitate to recommend it at double the price. But clearly there were tradeoffs involved to hit this price point. Build quality is not one — the thing feels perfect in hand. But it only has 256 MB of RAM — perhaps the single biggest hardware weakness of the device (see the section on Safari below). It is super high-quality, but clearly designed for the mass market. Anyone who thinks Apple only makes high-priced products has completely lost sense of reality. “Affordable luxury” is the sweet spot for mass market success today, and Apple keeps shooting bulls eyes. In fact, the only thing that makes my heart ache regarding the iPad is when I start imagining a hypothetical Pro model — imagine what Apple could put in an iPad that cost as much as a MacBook Pro. (My dream iPad Pro: double the display’s pixel resolution and include a gigabyte or two of RAM.) Affordability presents itself in other ways, too. Nothing is included in the box other than the power adaptor. The dock and case are separate SKUs, and it doesn’t even come with headphones. It’s like buying a Honda, not an Acura — the base model is not “well-equipped”. $500 is affordable but not cheap, and the iPad does not feel cheap in any regard. The build quality is outstanding. The brushed aluminum back makes my plastic iPhone 3GS feel cheap. The iPad takes more cues from the current iMacs than it does from the iPhone. The seam between the glass and the aluminum is nearly perfect. It’s just one piece of aluminum and a piece of glass — there is no superfluous chrome bezel between the glass and the backing as there is on all iPhones and iPod Touches to date. Even without turning it on it looks and feels a step beyond the iPhones and iPod Touches we’ve seen to date. The Killer App One thing that’s making it hard for some people to grasp the purpose of the iPad is that no one has an answer to what precisely it is for. This was not so for the iPhone. The answer to the question of what the original 2007 iPhone was meant for was right there at the bottom of the iPhone home screen, in the “dock”: phone, email, web, music and video. The other apps were icing on the cake. The four apps in the dock were what Apple designed the iPhone to do. The iPad also has a “dock” on the home screen, and the default apps in that dock are clearly important: Safari, Mail, Photos, iPod (which, on the iPad, is only for audio). But some are treating the iPad as, fundamentally, an e-reader. Others as a gaming device. Others as a movie player. None of those things are represented in the iPad’s default dock apps. The truth is that the App Store is the killer app. The iPad is meant for anything that can be represented on a 10-inch color touchscreen. Back in January when we were playing the “What’s Apple going to name the tablet?” game, my favorite, by far, was “Canvas”. I’m not saying here that Canvas would have been a better name than iPad, but the word conveys perfectly what the iPad is. Adam Engst captured this: The iPad becomes the app you’re using. That’s part of the magic. The hardware is so understated - it’s just a screen, really - and because you manipulate objects and interface elements so smoothly and directly on the screen, the fact that you’re using an iPad falls away. You’re using the app, whatever it may be, and while you’re doing so, the iPad is that app. Switch to another app and the iPad becomes that app. If that’s not magic, I don’t know what is. As did Cultured Code’s JĂźrgen Schweizer: Steve Jobs said about the iPod that âit is all about the musicâ. With the iPad, Apple has done the same for personal computing as it has done before with the iPod: it made technology go away. But if the device is gone, and the operating system is gone, what is left? The iPad is an empty canvas that invites us to imagine what is possible. It inspires our imagination and it makes us want to create, because never before were we able to create software that was so close to the user. The iPad hardware and OS are profoundly humble — they put all the focus on whatever app it is that is open. Out of Box Experience One thing that is very iPhone-like about iPad is that when you first take it out of the box, it wants to be plugged into your Mac or PC via USB and sync with iTunes. In some ways, that’s understandable. USB syncing is how you load your iPad with music and videos and transfer over stuff like your email accounts, and, if you’re not using MobileMe, your contacts and calendars. But, on the whole, it feels retrograde. It’s creates an impression that the iPad does not stand on its own. It’s a child that still needs a parent. But it’s not a young child. It’s more like a teenager. It’s close. So close that it feels like it ought to be able to stand on its own. Android devices do not have this problem. You can sync an Android device with a desktop computer via USB, for transferring things like music and videos, but you don’t have to. Out of the box, a Nexus One is ready to go. Google’s big advantage here is that they’re using online services as primary data stores. The Google Way is to use Gmail for email and contacts, and Google Calendar for events. You just tell your Android device your Google ID and password, and your email, contacts, and calendars start syncing over the air. Apple has MobileMe, but because it’s a paid service, they can’t (or at least won’t) assume that all iPad owners are going to use it. But then even those of us who do use MobileMe get stuck with a first-run iPad experience that involves a tethered USB connection to a computer. The Apple Way is to assume that your primary data stores for these things are locally stored on your Mac or PC — Address Book, iCal. At the very least, these things ought to be able to sync between iTunes (on your Mac or PC) and your iPad over your Wi-Fi network. Third-party iPhone OS apps like Things do a great job with this — there’s no reason iTunes and the iPhone OS shouldn’t too. Those Heart-Stopping ‘Scratches’ On the iPhone (and iPod Touch; assume from here out that when I say “iPhone” I’m referring to both), app icons on the home screen sit atop a plain black background. On the iPad, they’re spaced further apart, which is why I think Apple has added wallpaper — making the iPad home screen look a lot more like a Mac or Windows desktop. The default wallpaper shows a sunset skyline of a mountain range in front of a like. There’s a meteor shower in the sky. And the streaking meteors look, at a glance, like a series of severe scratches on the display. It’s a curious choice. The Touchscreen Keyboard It’s a lot like the iPhone’s, but, it’s different. Because it’s bigger, there are no pop-up indicators showing which key you hit as you type. They’re not necessary. The feel, overall, is pretty much like typing on a really big iPhone. If you’re in a position where you can set the iPad down on your lap or a table top, it’s not too hard at all to type with all your fingers when the iPad is in landscape (horizontal) orientation. Now, to me, it’s nowhere near as good as even the worst full- or nearly-full-size hardware keyboard I’ve ever used. You can’t just rest all eight of your fingers on the home row keys, and you can’t feel where the key cap edges are. You have to look at the keyboard a fair amount as you type. On a hardware keyboard, I hardly ever look at the keys. But for a touchscreen, it’s good. In portrait (vertical) orientation, I can type on the iPad using just my two thumbs, as I do on my iPhone. I have relatively large hands, though — I don’t think most people can do it. The keyboard in this layout is way too small for me to type with all of my fingers, though. In portrait orientation most people will type using one finger, I expect. Now, the funny thing is, in general, bigger keyboards are easier to type on than smaller ones. That’s why big laptops are easier to type on than compact ones, and, indeed, that’s why the landscape iPad keyboard on the iPad is easier to type on than the portrait one. But at a certain point, the curve flips around and smaller becomes faster. I type much faster on my iPhone using the smaller portrait orientation keyboard than the wider landscape keyboard. In both modes, I use just my two thumbs. With the smaller iPhone keyboard, my thumbs have to travel less from one key to the next. People who aren’t very proficient at the iPhone keyboard, or who have very large thumbs and therefore have trouble precisely tapping the smaller keys, may well prefer the iPhone’s wider landscape keyboard. But for me it’s not even close. I never type in landscape on my iPhone. And in fact (and this is the aforereferenced “funny part”), I type faster on my iPhone than I do on the iPad. That’s especially true for when the iPad is in portrait mode, which puts the keyboard size in a no-man’s land — too small to eight-finger-type, too big to thumb-type. But it’s also true for when the iPad is in landscape mode. I’m hopeful that this is just a factor of experience and muscle memory — I have nearly three years of experience typing on the iPhone, and only two days experience with the iPad. Last Friday I watched Andy Ihnatko eight-finger-type on his iPad — which he’d been using for over a week — and he was typing pretty goddamn fast. One problem I’ve run into is that Apple has subtly changed the layout of the keyboard from the iPhone’s. On the iPhone, the Delete key is on the lower right, above the Return key. On the iPad, it’s in the upper right corner, and the Return key is next to the L key. The iPad adds a right-side Shift key. The iPad layout makes perfect sense — both these keys are now where they reside on traditional hardware keyboards. Their weird positions on the iPhone are a compromise forced by the extreme lack of space on the iPhone display. Apple has also added a new key to the iPad keyboard’s numeric/punctuation mode: Undo. It’s a good idea — I have the feeling most iPhone users don’t know about the system-wide shake-to-undo gesture, and even for users who do, the iPad is harder to shake (and, when docked, downright silly to shake). But this new Undo key moves the period and comma keys over to the right by two positions. The iPhone keyboard layout is so firmly ingrained in my mind that these changes are problems for me — I keep hitting the (new to the iPad) right-side Shift key when I mean to hit Delete, and I keep hitting Undo when I mean to type a period. I’ll get used to it soon, I’m sure, but I find it interesting that my iPad typing muscle memory is based on the iPhone keyboard, not regular keyboards. I think this is because, overall, it really does feel like a big iPhone keyboard. Hardware Keyboard Support I don’t have (and did not order) the iPad keyboard dock, but I have been using an Apple Bluetooth keyboard. In fact, I’m using it to type this entire review. It works great. Pairing (via the iPad Settings app) is easy and quick. And it works great. Several essential text-editing shortcuts from the Mac OS work system-wide on the iPad: Command-Z, -X, -C, and -V work for Undo, Cut, Copy, and Paste. Command-A works for Select All. You can use the arrow keys to move the insertion point. Option-Arrow keys work to move the insertion point one word at a time. Command-Left/Right moves the insertion point the beginning/end of the current line; Command-Up/Down moves the insertion point the start/end of the current text field — which, in the case of something like Pages, is the beginning/end of the entire document. Holding down Shift extends the selection range, and works in conjunction with the Option and Command keys as expected. (Certain of Cocoa’s long-standing Emacs-style text editing shortcuts work too: like Control-K (kill) and Control-H (backspace).) Certain of the function keys on the Bluetooth keyboard are useful on the iPad. The brightness keys control the iPad’s display brightness. The volume (and mute) keys work. The playback buttons — play/pause, next, previous — all work to control the iPod app. By default, once you’ve started using a hardware keyboard, the on-screen keyboard no longer appears, which is great, because the full display is now available for displaying content. But if you want to use the on-screen keyboard while a hardware keyboard is active, you can toggle it using the hardware keyboard’s Eject key. The Esc key dismisses the auto-complete suggestion — it’s like tapping the little “x” next to the suggestion under the current word you’re typing. While a keyboard is connected, you can wake up the iPad by hitting any key — completely bypassing the iPad’s slide-to-unlock screen. Very nice. The iPad is fundamentally a touchscreen device. You absolutely do not need a hardware keyboard for it. But if you’re hoping to do any amount of serious writing with it (and, for obvious vocational reasons, I plan to), you’re going to want one. There are a few places in the iPad UI where I really wish the keyboard was useful but it isn’t. For example, Safari location field suggestions. On the Mac, you can use the up and down arrow keys to move through the list of suggestions. On the iPad, you must use touch to select from the list. Since you’re already typing if you’re entering a URL, this is just begging for arrow key support. (Ditto for suggested results from the Google search field in Safari.) The Esc key does not dismiss popovers, but that’s probably OK. It’s only possible to invoke popovers via touch, so it seems OK that you must dismiss them via touch as well. The Tab key can be used to switch between text fields; Shift-Tab goes in reverse order. (When using the hardware keyboard, I do find myself hitting Command-Tab, without thinking about it, when I want to switch to another app; it does nothing on the iPad.) Display The iPad display is, overall, wonderful. Colors are bright and (unlike the Nexus One’s OLED display) accurate. Photos and videos looks great. Touches seem precisely accurate. The glass feels good. Viewing angles are shockingly good. You can lay the iPad flat on a table while you eat or drink and it looks just fine at a decidedly skew angle — far more so than with the iPhone. This IPS stuff is the real deal; here’s to hoping for an IPS display in this year’s new iPhones. The only complaint I have about the display is that the pixel resolution isn’t all that dense. The iPad’s 1024 × 768 display has a resolution of 132 pixels per inch. The iPhone’s 640 × 320 display has a resolution of 163 pixels per inch. The difference isn’t huge, but it’s definitely noticeable. Type looks crisper on the iPhone than the iPad, and type rendering falls far short of even newspaper-caliber resolution, let alone glossy-magazine caliber. (Those of you who doubt that the pixels-per-inch resolution isn’t high enough, just wait until you see the type rendering on this summer’s new iPhones.) Safari The iPad is so good as a web reader, that, if you’re a web junkie, everything else the iPad does is just gravy. It’s good. I’m so used to Safari on the iPhone, though, where the toolbar is at the bottom, that I’m having a hard time getting adjusted to the toolbar at the top. I’m not saying it’s a bad decision on Apple’s part. In fact, the iPad HIG is quite explicit that iPad toolbars should go at the top, not bottom — which makes me think Apple thought about and tested this and has concluded that the top works better for the iPad form factor. It’s just that I use Safari on my iPhone a lot, and I am really used to the button placement. When you create a new page in Safari on iPad, text focus goes to the Google search field by default, rather than the URL location field. That’s a change from both desktop and iPhone Safari. I’m finding this hard to get used to, but I can see how this might be a better design for typical users. It makes the default search engine all the more essential to the web browsing experience, though. Zooming and flicking are essential to the experience, just like on the iPhone. Flicking is how you scroll, no surprise. The zooming, though, may come as a surprise. It wasn’t too long ago when 1024 × 768 was considered a large display for full-size web browsing. But: what matters on the iPad (and iPhone) is not the pixel count of the display, but the physical size. 9.7 inches diagonally is a bit small for non-zoomed web browser. But the action of zooming — whether through double-tapping or pinching — is so smooth, fast, and natural that it feels better, not worse, than old-school desktop web browsing. There’s one severe problem in Safari for iPad, though: memory crapping out. MobileSafari for iPhone has always allowed you to open up to eight pages at a time. It tries to keep them all truly open, in RAM, so that you can quickly switch between them. But when it runs out of memory it starts flushing some of the pages. It doesn’t forget the URL for those pages, and, in recent versions, it saves a static thumbnail image of the rendered page, but when you switch back to those purged pages, MobileSafari must reload the page — thus, you must wait both for the contents of the page to download and for the page to actually render (which — the rendering — often takes longer than the downloading). It’s very noticeable. Switching between unpurged Safari pages is instantaneous. Switching to a purged page takes as long as opening it from scratch. Wolf Rentzsch, linking to this complaint from Peter-Paul Koch, wrote a brief technical overview of why Apple might have designed MobileSafari this way. (Keep in mind that iPhone OS does not use virtual memory; thus RAM is severely constrained.) This purging problem got a lot better with the iPhone 3GS. The original iPhone and iPhone 3G only had 128 MB of RAM. The 3GS has 256. MobileSafari’s ability to keep more pages in memory is probably my single favorite aspect of the 3GS. The iPad also has 256 MB of RAM. But, in my use, iPad’s Safari isn’t able to keep nearly as many pages open as I can on my 3GS. In fact, sometimes it seems I can only have one, and every page I switch to gets completely reloaded. This is more than just annoying — it can lead to data loss if you have unsubmitted form data sitting in an “open” iPad Safari page. I’ve run into this posting items to DF from the iPad — my posting interface is a web page form. When I want to link to the current page, I invoke a bookmarklet which opens a new page with the title and URL fields of the posting form set to the title and URL of the page from which I invoked the bookmarklet. Often, though, I want to switch back to the page I’m linking to copy another URL or a bit of text to quote. Twice so far, when going back to the posting form, it’s been purged and must reload from scratch — in which case I lose anything I’ve already written. I never run into this problem on my iPhone 3GS when switching between just two open Safari pages. The problem is also severe for AJAX web apps, which tend not to be designed with full page refreshes in mind. I hope this can be improved significantly in an iPad software update, but I worry that it’s endemic — that because the iPad screen is so much larger than the iPhone’s, that MobileSafari must allocate significantly more memory per page for the framebuffers. 256 MB of RAM simply may not be enough for MobileSafari to keep more than two or three pages in memory. If so, Apple really needs to consider some sort of caching or serialization scheme rather than completely flushing away purged pages. Pages I wrote the entire 4,828-word first draft of this piece on my iPad using Pages.1 I didn’t use any of the formatting or layout tools — I used it as a text editor rather than a word processor. It’s quite serviceable. What I like best is that it opens very quickly. Switching between, say, Pages and Safari and back to copy-and-paste a URL feels more like switching than quitting, launching, quitting, relaunching. You don’t need to (and can’t) save manually. Whatever you do in a document simply persists automatically. When you go back to the list of documents, they’re presented as big thumbnails — very much like the list of open web pages in Safari. Pages’s toolbar and ruler are only visible when in portrait mode. In landscape mode, all of the chrome disappears. It’s just a full-screen editing view, a la WriteRoom. I’m writing this piece in this full-screen (landscape) mode, with my iPad propped up on a table in Apple’s iPad case. It’s a nice setup, and I can genuinely imagine leaving my MacBook at home for trips in the future, with the addition of few missing iPad apps (like, say, a good SFTP client). But when I say there’s no chrome in the landscape mode, I mean none. Pages has a decent simple little find and replace feature, but it’s only possible to invoke it in portrait mode. (I must have hit Command-F a dozen times so far, to no avail.) There are already complaints piling up that the iWork apps don’t support the complete feature set of their current Mac counterparts — open a file created in a Mac version of Pages/Numbers/Keynote on your iPad and certain document features may be removed. (The iPad apps prompt you with an alert telling you which aspects of the document have been changed or removed.) Another way of looking at it though, is that the iPad iWork apps are to their Mac counterparts what the iPad as a whole is to the Mac — simpler, more focused, but in some ways faster. Pages launches and is ready for input far quicker on my iPad than on my MacBook Pro. Writing this review, I’ve been switching back and forth between Pages and Safari. It doesn’t feel like quitting Pages, launching Safari, copying a URL, quitting Safari, and re-launching Pages. It feels more like switching — it only takes a moment after tapping the Pages icon on the home screen to be back where I was in my open document. (My only complaint is that you lose the insertion point when leaving and coming back to Pages — the document re-opens to where you left off, but you must tap the screen to place the insertion point. When switching several times, that becomes slightly tedious.) This is obviously not even close to a full review of Pages, but I can say without hesitation that it’s easily worth $10. Syncing There is, however, a severe shortcoming inherent to the iWork suite of iPad apps: document syncing between Mac and iPad. It’s a convoluted mess. In short, the only way to edit a document on your iPad that was created on your Mac, or vice versa, is to go through a convoluted multi-step process of exporting, copying, syncing or downloading, and importing. Ted Landau has copiously documented the entire situation in this article at The Mac Observer. Read it and weep. What it boils down to is that there is no syncing really. Real syncing is something like IMAP for email, or the way MobileMe handles calendars and contacts. When I read a bunch of new email messages using my iPad or iPhone, when I next sit down at my Mac, those messages are marked as read in my inbox. I don’t have to do anything on the Mac for that to happen. That’s just how IMAP works. I can add a new calendar event on my Mac, then walk away from my computer, take my iPhone out of my pocket, and the event is there. I can add a note to that event using my iPhone and a few moments later the note will be synced to the event on my Mac. Certain of my favorite iPad and iPhone apps sync like this too. When I read a bunch of RSS items using NetNewsWire on my iPad, they’re marked as read on my Mac. Sitting at my Mac in my office, I can send a long article to Instapaper. I go downstairs, pick up my iPad, sit on the couch, launch the Instapaper iPad app, and a few seconds later, there’s the article I just added to my Instapaper queue. This is the sort of data flow that makes me feel like I’m living in the future — using multiple hardware devices to view, edit, and modify the same data. I don’t worry about where separate copies of my data exist. Conceptually it’s just there in the apps, and the apps do all the hard work of pushing and pulling changes made on other clients. The data flow with these iWork apps isn’t like that at all, and needs to be for them to be truly useful. It doesn’t matter how good the user interface for viewing and editing spreadsheets is in Numbers for iPad if my spreadsheets aren’t there. Here’s an example. I keep the schedule for Daring Fireball RSS sponsorships in a Numbers document. What I’d like to be able to do on my iPad is launch Numbers and access the current version of that spreadsheet. But the only way I could possibly do that today would be if I went through the following steps every single time I made a change to the document on my Mac: Before opening the current version of the file on my Mac, check to make sure there isn’t a more recent version of it on my iPad. Open the file on my Mac and make changes. Save. Dock my iPad to my Mac via USB. Switch to iTunes and go to the Apps tab for my iPad. Add the newly-saved revision of the document to the file sharing list for the iPad’s Numbers app. Sync. Even after going through all of this, when I do want to open this file on my iPad, I have to remember not to open the last revision of it listed in the iPad Numbers app’s “My Documents” list, but instead remember first to import the latest revision from Numbers’s file sharing list to Numbers’ “My Documents”. And, again, it’s effectively up to me to keep track of which machine, Mac or iPad, has the most recent revision of the file. To say the least, this is a recipe for disaster, and even if you don’t make a mistake and inadvertantly make significant changes to an out-of-date version of the document on one of the two machines, you’re stuck with a preposterously, mind-bogglingly convoluted workflow each and every time you make a change to the document. The bottom line, obviously, is that there is no way that anyone is going to use these iPad apps in the way I describe above. As-is they’re only useful to me in two ways. First, I can imagine using Pages on the iPad to compose original new documents — posts for Daring Fireball — while I’m using my iPad. I’ll either finish them there and then copy-and-paste the result into the web-based posting interface for DF, or, I’ll send the draft to my Mac for further editing (which is what I did for the piece you’re reading right now). I can also imagine creating finished Keynote decks on my Mac and then moving them, once, to my iPad, and taking only my iPad with me to the presentation — i.e. using Keynote, Numbers, and Pages on the iPad as viewers for finished documents. (And, conveniently, they’re viewers that can make edits if you notice a mistake or want to make a last-minute change or addition.) But there’s no possible way to use these apps as clients alongside their Mac counterparts on an ongoing basis. The sort of over-the-air syncing I’m imagining for iWork is, admittedly, a difficult problem to solve. But the bad news for Apple is that their top competitor in this space has a solution: Google Documents. With Google Documents, there’s no making copies, importing/exporting, manually invoked syncing, or USB tethering involved if you want to edit a single instance of a spreadsheet from multiple machines. You just make changes on one machine, and when you next look at that document from another machine the changes are there. The workflow for iWork is downright antediluvian. It’s not just pre-Cloud, it’s pre-network. It’s effectively the “Who’s got the latest revision of this file?” workflow of the days when we moved files from one machine to another via floppy disks. What in the world is iWork.com for if not for solving this problem? At least iWork.com lets you avoid having to physically tether the two machines via USB to get a document from the Mac to the iPad (or vice versa), but it’s no better than file sharing through iTunes conceptually. When you send a file to iWork.com (from either Mac or iPad) you’re pushing a copy, a snapshot of the document from that moment. After making subsequent changes, you’ve got to push those changes to iWork.com all over again. And to get them on the other device, you must manually import — making just another copy. What you ought to be able to do is specify iWork.com as the canonical shared storage location for an iWork document. iWork.com doesn’t serve as any such purpose today. iPhone Apps I predicted it’d be crummy to run non-iPad-optimized iPhone apps on the iPad — like Classic apps running on Mac OS X — and I was right. It’s OK for games — they look jaggy, but jaggy games aren’t that uncommon. But regular (non-game) apps just look and feel weird. When you run them pixel-doubled text doesn’t scale dynamically — everything is pixel doubled. It’s a good way of proving that the iPad is not “just a big iPhone”, though. The only iPhone app I find myself using on my iPad is Simplenote, for copying and pasting bits of text to and from my Mac and iPhone. Needless to say, I’d love an iPad-optimized version of Simplenote. iBooks and Kindle The iBooks app is free, but doesn’t ship with the iPad by default — you have to download it from the App Store. Apple hasn’t explained why this is so, but there are several reasons I can think of. For one thing, e-book rights are managed on a country-by-country basis — it seems likely that the iBooks store won’t be available in every country where the iPad will soon be sold. Making it an App Store app will also allow Apple to update the app on its own schedule — built-in system apps only get updates along with the entire system. So in some ways, the iBooks app is on equal footing with other e-book readers available in the App Store, particularly Amazon’s Kindle app. But iBooks does get some special treatment — the first time I launched the App Store app on my iPad, it prompted me with a dialog box asking if I’d like to down the free iBooks app. It’s impossible to miss. The iBooks app also has display brightness controls that are not availble through public APIs. Winnie the Pooh is included as a free sample, and the choice is genius — it’s a beloved story, a good read, and best of all (from Apple’s perspective) it can’t be read properly on the Kindle because the color illustrations are a big part of the experience. No book on the Kindle will ever look this good. The Kindle has its own advantages — its books are generally cheaper, its selection bigger, and e-ink works better in bright sunlight — but Winnie the Pooh epitomizes the iPad’s advantages. iBooks’s page-turning animation is delightful — it doesn’t just track your finger-swipe precisely, but even renders the type faintly in reverse on the other side of the “sheet”. The practical minded can simply tap the right and left edges of the screen to turn pages. Amazon’s iPad-native Kindle app is good, too. Oddly, to my mind, it is superior to their recent Mac app in every way. It looks better, feels better, renders text better, and has more features. I say this is odd because the iPad was announced just two months ago; Mac OS X was announced over a decade ago. I suspect part of the reason the Mac version is so crippled is that they were more worried about keeping Mac users from un-DRMing Kindle content than they were about making the Mac app an actual good-to-use app. The Kindle doesn’t do animated page-turning, but that’s not a big deal. Reading is great. And the Kindle’s ace-in-the-hole, of course, is the far larger selection of e-books in its store — hundreds of thousands versus Apple’s tens of thousands. I bought When the Game Was Ours, a new book by Larry Bird and Magic Johnson. It is not available in the iBooks store. So Kindle’s advantage is library size (and, secondarily, price per title). iBooks’s advantage is the color display. I’d be shocked if every single piece of advertising Apple produces for iBooks doesn’t focus entirely on screenshots of books with color illustrations, photos, and video. I think it’s going to be easier for Apple to improve the iBooks store library than it will be for Amazon to create a Kindle hardware model with a color display. I think Amazon would do well to add color support to Kindle e-books for use on iPads and iPhones. Kindle has a better chance of long-term success as a software platform than a hardware one. Third-Party Apps in General Given that most iPad-native apps in the store right now were developed using only the simulator by developers without access to actual iPads, you might expect apps to be buggy and UIs to be awkward. I’ve found the bugginess to be true, but the UIs are actually good. I think the physical prototypes developers jury-rigged for themselves paid off, design-wise. There’s no question that UIs are going change rapidly in the coming weeks now that developers have the real deal to measure the feel of their apps against, but for the apps I’ve been using the most, they’re pretty damn good already. As for the bugginess, I’m not saying it’s inexcusable or even surprising — the SDK simulator is not a perfect simulation. Several of the bugs I’ve reported are only present when the apps are running on actual iPad hardware. On the whole, though, the quality of iPad apps on day one is better, by far, than I had expected considering that developers had to build them in the dark, as it were. Prices, so far, are significantly higher than for iPhone apps — but still far cheaper than category equivalent Mac apps. For example, NetNewsWire is $10 (and going to $15 in May); Things is $20; and OmniGraffle is $50. No doubt there are going to be wildly popular 99-cent iPad apps, but it’s also shaping up as serious platform for serious tools. Games are a bit more expensive, too, but, to me, reasonably so. The final word count is just short of 7,300, so admittedly I wound up writing quite a good chunk of it in BBEdit on my Mac. ↩
-
â This Apple-HTC Patent Thing
There are two aspects surrounding Apple’s patent litigation against HTC that demand further consideration. First, the severe problems with the U.S. patent system as a whole, particularly with regard to software patents. Second, the strategic implications of Apple’s decision to file suit. Smart writers with first-hand experience with software patents have written much over the past few years on the system itself. Tim Bray, in particular, has written extensively on them, including his own experience obtaining them. I’ll quote here from one of his early pieces on the subject: Are Software Patents a Broken Idea? — I really donât know. One of my brothers, an Industrial Designer, has his name on a patent for a device for mixing gases thatâs used in chromatographs. When he showed me the filing, with the drawings and schematics and so on, I was impressed; these guys had cooked up a new arrangement of valves and geometries that did a practical task in an elegant and new way. It felt much more rigorous than the way we go about inventing new technology in the software space; but maybe thatâs just because Iâm way too close to the software world and can see all the warts on its underbelly. Iâm inclined to think thereâs a spectrum of reasonability in software patents. âOne-click orderingâ seems like a grievous error, simply because if you said those three words to any web-savvy ecommerce-savvy programmer, theyâd say âOKâ and build it for you and it would work; which doesnât seem to meet a high enough bar to qualify as an invention. But consider the basic PGP setup by Phil Zimmerman, itâs just immensely clever and elegant. I have the feeling that that really does qualify as an invention in totally the same sense as my brotherâs gas-mixing apparatus. Obviously I think the things I filed are closer to PGP than one-click ordering. In a later follow-up, Bray wrote: Does this mean that Iâve concluded that software patents are just fine, thank you, and the current ratâs-nest of litigation is good business practice? No; while I generally agree with Jonathan that the software-patent idea is not inherently broken (and thus disagree with Richard Stallman), the fact is that itâs almost impossible for rational people to have a rational discussion about software patents. The reason is the insanely-dysfunctional behavior of the US Patent and Trademark Office, whose idiotic willingness to grant patents on anything without regard for prior art or the obviousness test has totally poisoned the waters of this discussion. The result, as Iâve argued before, is that the net effect of the software-patent system is to serve as a parasitic tax by lawyers on businesspeople. Where I disagree with Jonathan is on whatâs known as âbusiness-methodâ patents: one-click ordering, per-employee pricing. Iâm having trouble seeing the benefit to society in granting patents on something that could never possibly be done secretly. I also think that to get a patent, an invention should include innovation both in conception and implementation. The emphasis in the last sentence quoted above is mine. I’ve quoted extensively here from Bray because, having re-read his patent-related essays, I find myself in nearly complete agreement with him. I’m not opposed to idea of the patent system on general principal (as Stallman, and many others, are). And I think in many fields, the system has and continues to work well. But for software the system, in practice, is undeniably broken. There’s an argument to be made that software is inherently different than other field of invention, different in such a way that patents should not apply — or, should apply for a significantly shorter period of time before expiring. You can’t (or at least shouldn’t) be able to patent mathematics, and there are good arguments that programming is a branch of mathematics. But because software patents are granted, concede at least for the moment that certain kinds of software innovations ought to be patentable. Even with that in mind, clearly the U.S. Patent Office is and has granted patents for things which ought not be patentable. Not just silly frivolous things, but patents that have been granted for concepts alone, rather than specific innovative implementations of said concepts. Ideas in the abstract, rather than implementations of ideas. Paul Graham, who has also been awarded software patents, has written well on the subject, too: We, as hackers, know the USPTO is letting people patent the knives and forks of our world. The problem is, the USPTO are not hackers. They’re probably good at judging new inventions for casting steel or grinding lenses, but they don’t understand software yet. And: Thereâs nothing special about physical embodiments of control systems that should make them patentable, and the software equivalent not. Unfortunately, patent law is inconsistent on this point. Patent law in most countries says that algorithms arenât patentable. This rule is left over from a time when âalgorithmâ meant something like the Sieve of Eratosthenes. In 1800, people could not see as readily as we can that a great many patents on mechanical objects were really patents on the algorithms they embodied. Patent lawyers still have to pretend thatâs what theyâre doing when they patent algorithms. You must not use the word âalgorithmâ in the title of a patent application, just as you must not use the word âessaysâ in the title of a book. If you want to patent an algorithm, you have to frame it as a computer system executing that algorithm. Then itâs mechanical; phew. The default euphemism for algorithm is âsystem and method.â Try a patent search for that phrase and see how many results you get. These arcane rules lead to patents being described in an obfuscated manner. That they are patenting algorithms but must pretend they’re patenting something else is the definition of a broken system. To me, “user interface” patents are hand-in-hand with “business method patents” as examples of things which, no matter how innovative or original, ought not be patentable. They’re idea patents. Adobe, to take one example, has a patent on tabbed palettes. If you’ve used Adobe apps like Photoshop, InDesign, or Illustrator in the past decade, you know what they are. Design applications have been using floating on-screen palettes all the way back to the original MacPaint in 1984. Unlike dialog boxes, they weren’t modal and “floated” over the document window. Unlike menus, they remained visible. They’re ubiquitous in design apps. One shortcoming, however, was that if you opened too many of them, you cluttered your screen — the more palettes you have open, the less room you have for displaying the document itself. Adobe came up with a great feature: they allowed you to dock multiple palettes together as tabs within a single palette window, and you could drag individual tabs between windows or drag them out into their own window. (Similar, at the palette level, to tabbed web browser windows.) Adobe patented the idea, and when Macromedia implemented a version of it, Adobe sued (and won — a measly $2.8 million). To me, that’s exactly the sort of patent litigation that is aimed at stifling innovation rather than rewarding it. Building on the ideas of others is fundamental to competition. No one company can or should be expected to change the entire U.S. patent system. Like any entrenched system with powerful entities who seek to maintain the status quo, we’re likely stuck with it. And so the way the computer industry has dealt with it is detente. Companies obtain as many patents as they can, written as broadly as they can get away with. And since everyone (where by “everyone” I mean all large tech corporations) has a large patent portfolio, and nearly every idea under the sun has been patented by someone to some degree, most of them are inert. Company A doesn’t sue Company B for infringing upon patents held by A because A’s own products almost certainly infringe upon some patents held by B. This why pure patent troll companies such as Nathan Myhrvold’s Intellectual Ventures are so despised. They’re immune from the threat of counter-suit because they have no products or services. Their only business is extorting patent licensing fees. The analogy to nuclear weapons is overwrought when considered literally, but in terms of strategy it’s quite apt. Paul Graham, on Amazon’s notorious “one-click” patent: Where Amazon went over to the dark side was not in applying for the patent, but in enforcing it. A lot of companies (Microsoft, for example) have been granted large numbers of preposterously over-broad patents, but they keep them mainly for defensive purposes. Like nuclear weapons, the main role of big companies’ patent portfolios is to threaten anyone who attacks them with a counter-suit. Amazon’s suit against Barnes & Noble was thus the equivalent of a nuclear first strike. That suit probably hurt Amazon more than it helped them. Barnes & Noble was a lame site; Amazon would have crushed them anyway. To attack a rival they could have ignored, Amazon put a lasting black mark on their own reputation. Even now I think if you asked hackers to free-associate about Amazon, the one-click patent would turn up in the first ten topics. Which brings us to Apple and HTC. Regardless of the merits of all 20 of the patents Apple accuses HTC of violating, strategy-wise the comparison to Amazon and Barnes and Noble seems apt: Apple has the clearly superior product and is winning handily in the marketplace. Whatever benefit in the market Apple hopes to achieve by this suit to me seems likely to be worth far less than the loss of good will and prestige Apple will suffer if they vigorously pursue this case (let alone if they initiate more such suits). Wil Shipley, in an open letter to Steve Jobs regarding the HTC litigation: Youâve famously taken and built on ideas from your competitors, as have I, as we should, as great artists do. Why is what HTC has done worse? Whether an idea was patented doesnât change the morality of copying it, it only changes the ability to sue. […] If Apple becomes a company that uses its might to quash competition instead of using its brains, it’s going to find the brainiest people will slowly stop working there. You know this, you watched it happen at Microsoft. Copying ideas is how progress is made. It’s copying implementations that is wrong (and illegal). Admittedly there are gray areas, and reasonable people can disagree about whether some specific instances cross that line. But HTC’s phones are not copies of the iPhone. The Nexus One is without question highly influenced by the iPhone, both in terms of physical form factor and the Android software from Google. But it is also without question not a clone. My favorite theory thus far regarding why Apple is suing HTC is expressed entirely in this tweet from John Siracusa: To me, the Apple patent suit smells like nothing more than a manifestation of Jobs’s own sense of injustice. I.e., Jobs is offended by HTC’s products, not worried about them. I can understand the indignation, or at least imagine that I can. Apple’s press releases tend to be remarkably terse and plainspoken, at least by the standards of modern corporate communication. And when Jobs is quoted in them, the words are carefully chosen and meaningful, worthy of being carefully parsed1 — not at all like the bromides attributed to CEOs from most companies in most PRs. The PR announcing these suits against HTC is no exception: âWe can sit by and watch competitors steal our patented inventions, or we can do something about it. Weâve decided to do something about it,â said Steve Jobs, Appleâs CEO. âWe think competition is healthy, but competitors should create their own original technology, not steal ours.â That’s not the language of a licensing dispute or the beginning of a polite negotiation. That’s the language of a man aggrieved. During Jobs’s iPhone introduction keynote address in January 2007, before showing what the iPhone looked like, Jobs put up this slide showing four of the then-leading smartphones on the market: the Motorola Q, a BlackBerry, a Palm Treo, and the Nokia E62. Those pre-iPhone smartphones Jobs displayed all shared the same fundamental design: half-screen, half keyboard, and an up/down/left/right navigation controller. Now look at this prototype Android phone Gizmodo spotted in December 2007 — 11 months after the iPhone introduction. Android was conceived of that same old model — the prototype Gizmodo found in December 2007 would have fit perfectly alongside the other four phones in Jobs’s keynote slide. The gaping chasm between that Treo-ish/BlackBerry-ish prototype Android device and the HTC G1 that went on sale a year later (let alone the Nexus One today) was bridged by ideas from the iPhone. The iPhone introduced a new model. A true great leap forward in the state of the art. Not a small screen that shows you things which you manipulate indirectly using buttons and trackballs occupying half the device’s surface area, but instead a touchscreen that occupies almost the entirety of the surface area, showing things you manipulate directly. Android is a far better platform today than it would have been if Apple had never created the iPhone. That, in some sense, is not fair. I think Siracusa is exactly right that Jobs has a particularly acute sensitivity to this sort of unfairness. This litigation, perhaps then, isn’t about particular specific patented components, but rather is about the big idea, the general gist and grand ambition of the iPhone as the basic model for how modern mobile devices should be designed and work. No doubt some of you are nodding your heads and see this as justification for Apple’s suit. But life isn’t fair. Great ideas make the world better. Apple can rightly expect to benefit greatly from the ideas embodied by the iPhone, but they can’t expect to reap all of the benefits from those ideas. That’s the nature of implementing insanely great ideas. The bar has been raised, and, yes, Apple did most of the lifting. That’s how it goes. Paul Graham, yesterday: If this had happened a day earlier I don’t think I would have posted that RFS. Apple is inching ever closer to evil, and I worry that there’s no one within the company who can stand up to Jobs and tell him so. “That RFS” is the request for iPad software startups from Graham’s Y Combinator, and lest you think “evil” is too overwrought a word, Graham clarified later in the same thread: Historically the word “evil” has had a pretty broad meaning. Among tech companies the word has a new and fairly specific sense that follows from Paul Buchheit’s slogan “Don’t be evil.” That’s the sense I was using. It has a pretty low bar. It means, roughly, winning by taking advantage of people instead of by doing good work. I wouldn’t use the word evil this way, but I’m right there with Graham on this sentiment. And I say this not in any sort of hippy-dippy sense of expecting or even hoping for Apple to behave selflessly, holding them to a separate idealistic standard, or expecting them to fight with one arm tied behind their corporate back. And only a fool would argue that a company should never seek redress through litigation. But I believe that it’s good business, in the long run, for a company’s acts of aggression to take place in the market, not in the courts. My concern regarding this litigation against HTC is that it looks like an act of competitive aggression, not defense. I can think of only a few optimistic angles for this suit. One is that perhaps it’s a by-product of the suit Apple is engaged in against (and initiated by) Nokia. Apple’s counter-suit against Nokia involves some of the same patents at play here, and perhaps Apple’s lawyers have concluded that they need to enforce them against someone like HTC in order to use them in their counter-suit against Nokia. Or, perhaps one or more of the truly technical patents Apple has cited against HTC are genuine instances of intellectual property theft, the specific nature of which is unclear from the opaque language of the patent filings, and the rest of the cited patent violations were tacked on as part of a legal strategy along the lines of “If you’re going to punch them, punch them as hard as you can”. I.e. that they’ve filed suit as widely as they can, but have specific narrow violations in mind. What worries me is that idea that Apple, or even just Steve Jobs, believes that phones like the Nexus One have no right to exist, period, and that patent litigation to keep them off the market is in the company’s interests. I say it’s worrisome not because I think it’s evil, or foolish, or unreasonable, but because it is unwise, shortsighted, and unnecessary. For example, consider the timing of this PR Apple released early in the morning on January 5, announcing the three-billionth download from the App Store. Jobs is quoted thus: âThe revolutionary App Store offers iPhone and iPod touch users an experience unlike anything else available on other mobile devices, and we see no signs of the competition catching up anytime soon.â January 5 was the day Google held its event to unveil the Nexus One. ↩
-
â The Fear
The NDA is dead, yes, and good riddance, but there remain serious problems with the way Apple is managing the App Store. It boggles my mind that there remain so many people who don’t see this. This piece by Dan Kimerling at TechCrunch is one example; various of the reader comments on Jason Snell’s piece for Macworld last week are another.1 One factor, perhaps, is the tendency to see everything in terms of extremes. Black or white, good or bad. But this debate is not about wanting Apple to make radical changes, such as, say, changing the iPhone from a closed platform to a more open platform a la Android. There are reasonable arguments to be made that a more open iPhone platform would be good not just for iPhone developers, but for Apple and its shareholders. But those arguments aren’t what this debate is about. This debate is about wanting Apple to make minor changes — a slight but very significant course correction. Put another way, this is not about the big picture scope of what kind of hypothetical App Store (or Stores, plural) Apple should have created. That train left the station long ago. This is about the specific details of the App Store that actually exists, and the rules that govern it. I believe that a closed, controlled App Store can work, but by definition that requires developers to place trust in Apple. The problem is that Apple is managing the App Store in certain untrustworthy ways. And I mean trust more in the sense of stability than honesty — like in the way you need to trust a ladder before you’ll climb it. Here is a complete list of what Apple must do to increase developers’ trust in the App Store system: State the rules. Follow the rules. That’s it. This is so clear that even those who are arguing the other side — that Apple’s App Store stewardship is just fine as it stands today — have jumped through hoops in an attempt to argue that Apple’s exclusion of Podcaster was in fact in accordance with the iPhone SDK Guidelines. Kimerling, in his “Stop Complaining About Apple and the App Store” piece, writes: When you create the platform, you set the rules. If Apple wants to restrict iPhone applications to those that do not compete with features built into the iPhone, well, they can go right ahead and do so. It is right in the SDKâs user agreement. That’s just not true. The iPhone SDK Agreement, at least by the standards of legal contracts, is written in clear, straightforward English. (Apple’s lawyers, in the opinion of yours truly at least, are good writers.) The rules it lays down are clear. And Podcaster doesn’t break any of them. Given any set of rules, there will always be edge cases. Judgment must be rendered, and, inevitably, some will feel edge cases were judged the wrong way. But the reason iPhone developers (and prospective iPhone developers) are appalled by Apple’s rejection of Podcaster and MailWrangler is that neither app was near any edge defined in the SDK guidelines. Podcaster was rejected for duplicating the podcast features in iTunes and the iPhone “iPod” app. MailWrangler was rejected on the following grounds: Your application duplicates the functionality of the built-in iPhone application Mail without providing sufficient differentiation or added functionality, which will lead to user confusion. The word “duplicate”, in any conjugation, does not appear in the iPhone SDK Agreement. Not a word about it. And there is clearly no general rule about third-party apps duplicating the functionality of the iPhone’s built-in apps. PCalc, along with a handful of other calculator apps, duplicates every single feature of the built-in Calculator app. There are dozens of note-taking apps that compete with Notes; MagicPad goes so far as to use the same icon as Apple’s Notes app, just with different colors. There is an entirely category in the App Store — an entire category — for weather apps, several of which “duplicate” the entire functionality of the built-in Weather app. So, not only judging by the rules set forth in the iPhone SDK Agreement, but also by the existence proof of hundreds of apps currently published in the App Store that duplicate (which is really to say compete with) built-in iPhone apps, no reasonable person would have expected Podcaster or MailWrangler to be rejected. So their rejection is problematic on three fronts. First, the submission process is such that an app rejected at the conceptual level — one that cannot be tweaked or fixed to gain entry upon resubmission, but whose fundamental premise is rejected by Apple — such an app is only rejected after it has been written. The developer does all of the work to produce the app and only then finds out it was all for naught. Second, there are clearly rules which are not listed in the SDK guidelines. Third, in its explanations for the rejections, Apple is not stating what these actual unpublished rules are, and is instead offering as the reason this “it duplicates a built-in app” rule which, given all the aforementioned counterexamples that have been accepted into the App Store, isn’t actually a rule at all. The explanation is clearly false. Taken together, these three factors lead to The Fear, which is that developers cannot trust the App Store process. You can spend all of the time and effort it takes to build an app, follow every known rule, and still get rejected. From Apple’s perspective, especially, say, in upper management, it may be all too easy to look at what’s going on with the store — thousands of published apps, a ton of money changing hands — and not see the problem. In the big picture, from both a technical and marketing perspective, the App Store is a grand success. The problem is that the apps that are the most interesting, the most important, are the ones that take the most work to create. And the apps that take the most work to create are the ones that are most likely not even to be made in this environment, because the risk is greater. The more work it takes to create an app, the more you lose if Apple rejects it. Going back to the ladder analogy, the higher you’re trying to climb, the more you need to trust the ladder before you start. It’s not about a handful of developers who’ve had their apps rejected. It’s about all the other developers who are now spooked, and that the ones who are the most spooked are the ones who harbor the grandest, boldest, most innovative ideas. Interpolation Regarding a Theory on Which Apps Apple Won’t Allow Developers to Compete With In the absence of revised iPhone SDK Agreement from Apple, we can attempt to guess what the unpublished rules are. With Podcaster, for example, the “follow the money” rule of thumb leads to the conclusion that Apple will not allow any competition with iTunes, because iTunes is a profit source. This is why MailWrangler’s rejection is the one that puts The Fear in my heart. As unjust as the Podcaster rejection appears, if Apple really wants to prohibit competition with iTunes, even anti-competitively, you can at least see the thinking behind the decision. It’s foolish and unnecessary — the fact that iTunes is wide open to total competition on both Mac OS X and Windows hasn’t hurt it at all — and it also quite possibly invites some sort of legal challenge, but at least there is a logical idea behind it. But Mail? Why on earth should Apple care if some third-party email client for the iPhone becomes wildly popular? It makes no sense. iPhone users who use the built-in Mail app don’t pay extra to do so. Mail doesn’t tie users to Apple’s own MobileMe service. In fact, Mail offers specific setup help to work with Gmail, the service MailWrangler is optimized for. If you can make a replacement for Notes and Weather and Calendar, why not Mail? I have a theory. It is more, well, emotional than logical. But it’s the only theory I can think of that makes any sense at all and fits the available evidence. The theory is that there is an unpublished rule that Apple — and in this case, where by “Apple” I really mean “Steven P. Jobs” — will not publish third-party apps that compete with or replace any of the four apps in the iPhone’s default “dock”: Phone, Mail, Safari, and iPod. Go back to Jobs’s original iPhone introduction at Macworld Expo 2007. It was a masterful presentation. Carmine Gallo, writing for BusinessWeek, calls it Jobs’s greatest presentation; I agree. Gallo describes the moment it was unveiled: After laying the groundwork, Jobs builds up to the new device by teasing the audience: “Today, we are introducing three revolutionary products. The first is a wide-screen iPod with touch controls. The second is a revolutionary new mobile phone. And the third is a breakthrough Internet communications device.” Jobs continues to build tension. He repeats the three devices several times then says, “Are you getting it? These are not three separate devices. This is one device ⌠today Apple is going to reinvent the phone!” The crowd goes wild. This “three revolutionary products” pitch was inordinately effective. For one thing, live, in the hall, Jobs completely fooled the crowd, yours truly included. But then as he repeated the three product ideas over and over, while icons representing the three products rotated behind him on screen, faster and faster, it started dawning on us how we’d been tricked. By the time Jobs came out and said that it was just one device that encompassed all three products, everyone in Moscone West had come to that conclusion on their own — a nifty little way of making the crowd feel clever, as though we’d figured out a riddle. But this pitch also worked because it was true. All three of those products sound good on their own. All three in one device sounds insanely great. Jobs was introducing the iPhone simply by describing precisely what it was. A phone, a widescreen video iPod, and a breakthrough Internet communicator. The icons in the iPhone’s default dock represent the core functionality of the device. Phone, Email, Web, iPod. With nothing other than those four apps, the iPhone still would have been a hit. Not as great, but, still, great. Everything else the iPhone’s built-in apps do could be done, to some extent, through Safari: notes, calendars, weather, maps, stocks. There are a few minor exceptions. SMS is one example, but that’s really just an adjunct to the Phone app. Anything that relates to the phone network — voice or SMS — is unavailable through the third-party iPhone SDK anyway. You couldn’t write your own SMS app even if you wanted to. (Apple clearly has no problem with competing chat apps — there are several IM clients available in the App Store. That’s the same basic concept as SMS, but using IP networking.) And so my guess is that while there may not be any logic, there’s at least a notion, if only in Jobs’s mind, that these four apps are sacrosanct because they define the iPhone. Everything else, both from Apple and from App Store developers, is piffle, secondary to those four apps. Harry McCracken’s recent iPhone user survey indicates that iPhone users agree that those four apps comprise the most-used features of the iPhone. But the least essential of the four is Mail. You cannot place phone calls or play music and video from your personal iTunes library using a web browser, but can read and send email through it.2 Millions of people do just that every day, including, I’m sure, many of you reading this essay. And Google’s iPhone-optimized version of Gmail shows just how well it can be done. It’s not just good for web-based mail, it’s just good, period. And so this idea that Apple seems to have that Mail is particularly special is misguided. The Phone and iPod apps are special, because at a fundamental level they perform tasks that cannot be duplicated in a web app. But there’s nothing any more special about Mail than there is about, say, Calendar. Calendar, if anything, is more closely tied to Apple’s proprietary and commercial MobileMe service — Mail works great with any IMAP server, including Gmail, but Calendar only works for online syncing with MobileMe or Exchange. But Apple doesn’t seem to have any problem allowing Calendar competitors into the App Store. Notes Calendar is a $3 Lotus Notes calendaring client. Exchange Remote Calendar is a $10 is a $10 calendaring client for Exchange. If these are OK, why not a dedicated Gmail email client? The only explanation is that Mail is deemed untouchable and Calendar is not. The real test would be for someone to write a dedicated Google Calendar iPhone app — but given what happened to MailWrangler, it might be hard to find someone willing to try it. In short, my theory is that Mail is on the do-not-compete list not because there’s any strategic reason for Apple to do so, but simply because of a vague notion that Mail is one of the iPhone’s defining apps. This notion is wrong. Mail is important, but there’s nothing about it that needs to be protected from competition. End of Interpolation, Back to the Three Problems, Which, Due to the Grotesque Length of the Above Interpolation, I Will Remind You Are: (1) App Ideas Are Rejected Only After the Apps Are Actually Built; (2) There Exist Secret Unpublished Rules Regarding What Is Allowed; and (3) When Apps Are Rejected for Violating the Unpublished Rules, Apple Refuses to State Just What These Rules Are One thing that would make a difference would be a submission process whereby developers could submit their application ideas to Apple in advance, to find out if they’re OK. That’s how it works on game platforms from Nintendo, Sony, and Microsoft — developers submit a detailed proposal and wait until they get the green light before actually building the game. That sounds good, but there are problems with the idea. For developers, it would require an additional level of trust in Apple. Ideas are less valuable than actual implementations, but the more original an idea is, the less comfortable you are to share it. And for Apple, it would require significantly more work. They’d still need to examine and approve the actual shipping applications, but now they’d also have to examine and consider application proposals. The world’s hard drives are littered with abandoned unfinished software projects — there would surely be far more proposals submitted for consideration than there are actual iPhone applications. As it stands today, Apple is already struggling mightily to keep up with the work of approving new and updated application submissions — the typical turnaround time is between one to two weeks. Perhaps Apple could offer this as a service limited to ADC Select ($499) or even Premier ($3,499) members. The service is needed most by the developers who are considering the biggest apps, most of whom either are already paid ADC members or wouldn’t bat an eyelash at the cost of joining. It wouldn’t be democratic, but it might make it feasible. Platforms like Wii and Xbox ship maybe a few dozen titles a month, tops. The App Store has published 3,500 titles in just three months. (And it costs far more to join the developer programs for gaming consoles than the $100 iPhone SDK fee.) More important, though, is for Apple to address problems 2 and 3, by publishing in the iPhone SDK Agreement all of the rules they’re using to evaluate applications. If we’re not allowed to write email or podcast clients, say so. If something unforeseen comes up, Apple should make a decision, and then publish the new rule. Rules you disagree with are frustrating. Rules you don’t know about are scary. I will also note that, to my knowledge, not a single published iPhone developer has spoken out in favor of the App Store’s current rejection policies. Those developers who have spoken are against it. Those who see no problem are not themselves iPhone developers. ↩ Even if Apple were to come to its senses and allow third-party developers to write competing email clients, the built-in Mail app would hold one significant technical advantage, which is that it runs in the background. In fact, background processing is the one factor that unites the four dock apps. Phone, Mail, Safari, and iPod all continue running the background; no other apps, including those from Apple, do. ↩
-
Will Google's Android Play DOS to Apple's iPhone?
Daniel Eran Dilger Today's broad array of smartphone operating system contenders are offering lots of potential answers to a problem that only requires one. It appears the market has two options ahead: either pool generic hardware makers behind a single operating system and deliver a smartphone marketplace that resembles the Windows PC market, or watch them fall to a dominant leader and have a smartphone market that resembles Apple's iPod ecosystem. This decision isn't going to be made by a class of intellectual elite, or by government mandate. it's going to be made by the market itself. Here are the factors that will influence the outcome, either marginalizing Apple's iPhone into a niche as the company has twice experienced previously at the hands of DOS in 1981 and Windows in 1991, or positioning it as the dominant leader as Apple has achieved for itself with the iPod since 2001. The third segment in this series looks at Google's Android and the Open Handset Alliance as a possible âDOS-attackâ against Apple's iPhone. Subsequent segments will look at Nokia's newly opened Symbian and other mobile contenders challenging the iPhone. Will the iPhone Meet its Match from a Modern Day DOS? Will Windows Mobile Play DOS to Appleâs iPhone? Will Google's Android Play DOS to Apple's iPhone? Will Symbian Play DOS to Apple's iPhone? Google Acquires Android. In 2005, Google purchased a startup named Android, which had been in business for nearly two years. The secretive startup was known only to be working on software for mobile phones. It was being run by a who's who of mobile industry veterans, including Andy Rubin, the founder of Danger. Rubin had earlier worked at WebTV along with Chris White and Andy McFadden, both of whom had also joined Android. Richard Miner of Orange and Nick Sears of Tmobile also brought their mobile provider experience to Android. At the time of the acquisition, Google didn't announce any plans for Android and instead only told BusinessWeek, âWe acquired Android because of the talented engineers and great technology. We're thrilled to have them here.â It appeared that Google was only going to be expanding its search services for mobile phone users, along the lines of the Google SMS answer system it had recently released. Google Buys Android for Its Mobile Arsenal - BusinessWeek Windows XP Media Center Edition vs Apple TV: The Fall of WebTV The GPhone Myth. As reports began to leak out about talks between Google and hardware makers throughout 2007, rumors began to fly about âthe GPhone,â a competitive offering that was supposed to take on the iPhone. Some phone enthusiasts hoped Google would jump in to rescue the struggling OpenMoko project and turn it into a viable project that could attack Apple's new smartphone. In October 2007, I printed the Great Google GPhone Myth, taking apart the idea that Google would be directly competing against the iPhone, and describing that Google was really working on a free alternative to Windows Mobile as a conduit for getting its search and related services on a broader variety of mobiles. Google's services were already on the iPhone. In November, Google played its hand: it had organized a consortium of companies called the Open Handset Alliance to develop open standards for mobiles. The first product from the group would be Android, a mobile operating system built on the Linux kernel. Google wasn't getting into the phone handset business at all; it was only making sure that its mobile search products would not risk being marginalized by the threat of Windows Mobile on phones in the same way Microsoft had been working to leverage its PC monopoly to push Google search off the Windows desktop. The Great Google gPhone Myth Introducing Android: Leader of Linux. Two weeks later, Google released an early version of the Android software. On top of a Linux kernel, Android uses a specialized version of a Java Virtual Machine that takes Java language code and turns it into what Google calls âDalvik bytecodeâ rather than Java bytecode as a standard JVM would. This allows Google to leverage existing and familiar Java language tools without paying Sun for a Java license. Like Mac OS X and its fraternal iPhone OS, Android includes a variety of open source libraries, including SQLite and WebKit. On top of that, Google developed a series of frameworks that handle the tasks Cocoa Touch does on the iPhone. Android also bundles a set of applications. While Apple adapted its existing Mac OS X to work in a mobile environment to create the iPhone OS, Android is more like a customized Java environment running on a specialized mobile Linux variant: elements of maturity in an otherwise experimental new platform. What is Android? -Google Android was by no means the first mobile OS using Linux. Both Palm and its amputated ACCESS software arm have Linux-based mobile platforms. Nokia has Maemo, which it uses in its Internet Tablets, and also recently acquired Trolltech and its Qtopia mobile Linux platform. Motorola has teamed up with MontaVista Software to use its Mobilinux. Intel created the Moblin project for mobile Linux, aimed at Internet devices. Google's OHA also isn't the first consortium to attempt to standardize a mobile Linux platform. The OSDL started the Mobile Linux Initiative to define requirements for hardware; the Consumer Electronics Linux Forum (CELF) then worked to define various phone profiles aimed at the Japanese market; the Linux Phone Standard (LiPS) Forum tried to do the same thing in Europe. In 2007, LiPS was folded into the new LiMo Foundation, along with the OSDL. All of these committees have had some overlap and some complementary features. Several of Google's OHA partners are also LiMo members, including NTT DoCoMo, Wind River, and Motorola. So why didn't Google just join LiMo? âLiMo, very candidly, wasn't moving fast enough,â OHA board member John Bruggeman told CNET. Google hopes to herd the Linux cats into a progressive, structured platform that can battle against Symbian and Windows Mobile to succeed as the new DOS of smartphones. Will Google fracture or unify mobile Linux? The Presumption of the Necessity of DOS. The previous segment examining Windows Mobile pointed out how the PC industry as a whole assumed that Microsoft's desktop Windows monopoly would easily take over dominance in the MP3 player market, pushing Apple into a niche position. This was expected because DOS had pushed Apple's early computers into a reduced role starting in 1981, and Microsoft had repeated this again in 1991 when the DOS world migrated to Windows, effectively pruning Apple's Macintosh into a Bonsai platform. The inability of one company to dominate any product category has been frequently repeated by PC industry pundits as a given, despite the fact that history is full of examples of this happening. Sony dominated personal music players for two decades under the Walkman brand even while equally large competitors tried to push it from this position; Nintendo has similarly owned handheld gaming despite ill-fated efforts to grab a piece of its pie by products running a generic platform such as Microsoft's WinCE (Gizmondo), Linux (GP32), and Symbian (N-Gage). In fact, outside of the Windows/DOS PC, there are actually few examples of a generic platform taking over an industry. Nearly every other consumer-facing product uses proprietary platforms: car makers, stereo equipment, appliances and so on typically all use designs custom to their maker. The paradox of the Windows PC market has been that Microsoft's broadly licensed software supposedly saves hardware makers from investing in software development while ensuring compatibility, when in reality it adds significant costs to PC makers while limiting their ability to differentiate themselves. That explains why PC makers have been perpetually merging together and going out of business while Microosft has rolled in money over the last two decades. Parallel efforts to copy Microsoft in broadly licensing an operating system have regularly failed: IBM's OS/2, Apple's Mac OS, Palm's PDA OS, even Microsoft's own efforts to duplicate Windows dominance in other markets, from copy machines to PDAs to smartphones to SPOT watches to music players. The closest copy may be Symbian, but its customers are partners, not simply consumers of a generic third party's operating system as Windows licensees are. That indicates it is not necessary to duplicate the dominance exercised by Microsoft over the PC industry in the smartphone market. Google's Android and Symbian exist more as technology sharing pacts among manufacturers, but both aspire to take Microsoft's DOS role among smartphones. However, the idea that Apple's iPhone must be dethroned by a modern-day DOS, whether Windows Mobile, Android, or Symbian, is not just debatable, but does not sync with the reality of more recent events. Apple's recent history of the iPod further refutes the idea that a software analog to Microsoft is needed. The iPod Emergence: Apple & Pixo vs IBM & Microsoft. Apple's iPod in 2001 made no effort to clone the DOS business model; it actually did the opposite. When Apple entered the market, there were a number of existing MP3 devices using custom software, hardware designs, and DRM codecs. The iPod used off the shelf components to deliver a custom MP3 player using third party software, but Apple also added its own technologies: easy to use sync with iTunes, a fast Firewire interface that made uploading music far faster than the prevailing USB 1.0, and an attractive industrial design. With the iPod, Apple played the role of IBM in 1981, using Pixo's embedded operating system to enter the market quickly, just as IBM had used DOS. The difference was that Apple didn't direct any market attention toward Pixo and added a lot of value on top of that core embedded OS. A modern day Compaq couldn't simply clone the hardware and license Pixo to run on it in order to compete against the iPod, because the iPod was much more than just generic hardware running Pixo software. As the iPod developed, Pixo's role diminished and was eventually displaced. Just like IBM, Apple jumped into a new market just as demand was beginning to explode. Apple made MP3 players far more attractive to a general audience by delivering greater playback capacity than most entry level devices offered, along with an ease of use that encouraged buyers to jump in at the higher end of the market. That left Apple with not only the lion's share of the market, but also by far the most profitable segments of the market. Two decades prior, IBM badly fumbled its play with the early PC and ended up irrelevant in the PC world by the late 80s, sideswiped by Microsoft's DOS and the cloners who were licensing it in parallel, notably Compaq and later HP and Dell. Steve Jobs had witnessed that happen, and was determined to not let it happen again to Apple. Rather than being manipulated by a software middleware vendor as IBM had, Apple worked to incrementally develop the iPod market itself. After consuming the hard drive-based player market, Apple took on the Flash RAM-based market with a tiny hard drive system used in the iPod Mini, and followed up with Flash-based devices of its own in the Nano and Shuffle. This allowed Apple to progressively serve an increasingly wider market, incrementally growing upon an established foundation. With the iPod, Apple became, in effect, an IBM with its own internal Microsoft. Microsoft's Failure Despite Features. In contrast, Microsoft entered the music player market by promoting music player hardware reference designs around WinCE. However, it was unable to ship a finished design until the iPod had become firmly established around 2005. Later branded as PlaysForSure, the devices were sold by various hardware makers and all purported to support the same DRM and the same music subscription services while also offering a broader array of hardware that presented video before the iPod did, supported wireless before the iPod, and so on. Despite these unique features, all of those PFS designs still failed. Microsoft blamed the failure of PFS upon its music store and hardware partners and decided to take Apple on itself in 2006. It relaunched a Toshiba PFS player as its own device under the Zune brand, adding WiFi music sharing features and a larger display than the current Pods had. It failed dramatically as well. Did Microsoft's attempts to float a new DOS among music players fail because of Apple's success, or due to Microsoft's own problems? The failure of the Zune, which followed the iPod model rather than the DOS model, seems to suggest that Microsoft itself was to blame. Consider too that Microsoft's Windows Mobile phones, which use the same underlying operating system as its failed PlaysForSure music players and the Zune, had similarly flopped even before Apple could release a charismatic phone equivalent to the iPod. Of course, when the iPhone was released, it hit Windows Mobile hardest. The iPhone made Windows Mobile Smartphones look ridiculous and underpowered, and made Windows Mobile Pocket PC phones look clumsy and awkward, despite the fact that they both supported a variety of features the iPhone didn't, including the ability to edit documents, capture video, send MMS, and so on. Simply adding on features did not enable Microsoft to compete against Apple. The only conclusion that can be drawn from all this is that competing against Apple requires more than just having a feature arsenal. Microsoft's failures in themselves do not necessarily mean that Google's Android will fail in its attempts to float its own smartphone platform. Why Microsoftâs Zune is Still Failing Microsoftâs Zune, Vista, and Windows Mobile 7 Strategy vs the iPhone Will Google Succeed where Microsoft Failed? Microsoft's demonstrated inability to successfully enter consumer markets for MP3 players and smartphones has given observers little faith that the company will somehow turn things around in late 2009 when its next generation of devices are expected to be released. However, prior to that the first fruits of Google's efforts to build its own smartphone operating environment will arrive. Will Google's Android take over Microsoft's crown as the âDOS vendorâ among smartphones? Supporters of Google's Android project point to some parallels between Android for smartphones and Windows on the PC: Android will allow hardware makers to differentiate in ways that can offer features Apple can't (or doesn't want to); it should allow software developers to offer features Apple does not allow on the iPhone; it embraces open, hobbyist experimentation in ways that Apple currently isn't; and it opens the potential for content providers that Apple is not interested in allowing. Openness is Android's key competitive feature. Will all this openness allow Google to unseat the iPhone to become the primary platform developers want to participate in, and subsequently soak up the market for third party hardware makers that Windows Mobile serves? While Google currently has no market share due to the fact that no Android phones have yet shipped, it does have broad vocal support from a variety of the same kinds of hardware manufacturers that supported DOS and Windows and helped to make those platforms successful in the desktop PC market. HTC and Android. The first Android phone is expected to be the HTC Dream; Taiwan's HTC (High Tech Computer) also manufactures Palm's Treo Pro phone as well as many of the most visible Windows Mobile devices. In addition to models produced under its own name, HTC also sells Windows Mobile devices under the Dopod brand, as well as no-name phones branded by providers, such as AT&T, Orange, Sprint, T-Mobile, Verizon Wireless, Vodafone, and others. HTC will also be building the XPERIA X1 Windows Mobile phone for Sony Ericsson. HTC was quick to throw its support behind Android despite its long term alliance with Windows Mobile. Why would it so enthusiastically support an unproven platform from a company that has no experience in consumer hardware platforms? One can only assume that HTC is not happy with the current state of Windows Mobile, and desperately wants another âDOSâ to succeed where Microsoft's has so spectacularly failed. As an Original Design Manufacturer for Palm, HTC watched as Palm adopted Windows Mobile in place of the Palm OS and subsequently fell even deeper into crisis. Palm's only successful phone since has been its Palm OS-based Centro. HTC undoubtedly sees Android as its ticket to becoming the next Dell, but without a similar dependance upon Microsoft. Android for mobile phones is essentially playing the role of Linux for PCs, except that it has the backing of a major company behind it. Can Android Take on the iPhone with Openness as its Feature? As great as this sounds, it's important to consider that Linux on the desktop has made no significant progress in eating into Windows dominance after a decade of trying. Being open, free, flexible, and decentralized hasn't been enough of an advantage to get consumers to migrate from Windows to Linux in any fraction of significance. Similarly, in the music business, Linux-based MP3 players have had no impact on the iPod, despite offering more features, flexibility, support for additional codecs, and so on. In the mobile phone area, Linux enjoys a sizable portion of the smartphone market, but this is almost entirely due to phones sold by Motorola in China, where the advantages of Linux' openness are void. Motorola's Linux phones offer nothing to users in terms of openness or flexibility, and are really no different in terms of features than other appliance 'feature phones' based upon closed operating systems. And again, a key problem with assaulting Apple in a feature war is that neither the iPod nor the iPhone became popular by being âhighly featured.â They both delivered perhaps 80% of the functionality found in all other devices in the market. Rather than trying to match every feature and cater to every niche as Microsoft had with Windows Mobile, Apple's devices did a few things very well at launch, and incrementally developed into full featured devices that still lack some of the more unique features of their competitors. Further, in terms of openness, the demographic that embraces Linux' characteristic freedoms is not the same as the demographic that buys smartphones in quantity and then pays for data service. This is a critical fact to consider because a big part of the iPhone's success stems from the fact that it is being pushed by mobile providers who want to capture the cream of the market willing to pay a premium for data services. The Frankenphone. Combining the fractured aesthetic of HTC's Windows Mobile phone hardware with Android's software, based upon Linux' perpetually unfinished DIY openness and Google's Java-like development platform, will not result in a product similar to the iPhone. Instead, it will look a lot like phones that have already failed in the market. Apple's advantage comes from slick hardware designs with a close attention to detail, combined with software that purposely does less so that it can do what it does better. Even Apple's own conservative attempts to broaden its software capabilities with iPhone 2.0 have resulted in instability problems that can be blamed upon both Apple's early releases of its phone operating system and software from inexperienced third party developers new to the platform. Would the current frustrations with iPhone 2.0 be somehow mitigated by additional openness that also embraced all kinds of variables from different hardware makers with less quality control than Apple, a loose committee of additional cooks working to serve up operating system features targeted at every possible conceived need, and a wider third party software group with fewer constraints on illegal behaviors? The Failure of Open. While it is politically unpopular to criticize the well meaning efforts of open source contributors, the failure of Linux on the desktop, the failure of the vaporware Indrema game console, and the failure of the OpenMoko project to deliver a workable phone within a year of its deadline all underline the serious problems open development faces in the world of consumer oriented devices. Open has simply failed to deliver on its promises in the world of consumer hardware. OpenMoko was supposed to release its first mobile phone to consumers for $250 several months in advance of the iPhone. When the iPhone shipped, the group then announced new plans to get its phone out by the end of 2007. Instead, this spring the group announced new plans to move to an entirely different development platform, and ship its phone mid year for $400 with limited functionality and incomplete software outside of basic GSM phone features. Linux's notable successes, from Motorola's Linux phones to the Tivo DVR to Linksys Routers, have often come without any associated openness or freedom, and were instead delivered simply to provide their manufacturer with a free kernel to build upon. This indicates that while Linux may find its way into an increasing number of smartphones, it will likely not be accompanied by the glorious freedom of an open development environment Google has said it would offer with Android. Apple iPhone vs the FIC Neo1973 OpenMoko Linux Smartphone Can Google Succeed Where Open Has Previously Failed? Despite âopennessâ being Android's strongest competitive feature compared to Apple's iPhone, Google recently revealed that its wide-open development model is intentionally gravitating towards a closed association of top tier partners due to practical considerations. In July, Google accidentally sent out a notice that revealed that it had been seeding private SDK updates to only a subset of its contributors, angering those who believed that Android would be as open as Linux on the desktop or the OpenMoko project. Further, Google has restricted initial development to higher level APIs just as Apple did, further indicating that Google itself realizes that being wildly open to impress a minority of hobbyists will not result in the commercial success of its new platform. That serves to neuter Android's primary advantage over the iPhone. Without delivering on the premise of being wide open, Android is really just a less mature set of Java libraries used to create a specialized binary that runs on a Linux foundation. Unlike Apple's iPhone, Android phones won't have a slick user interface developed by professional artists, nor the iPhone's legacy of mature software development frameworks crafted over the last thirty years, nor the iPhone's tightly integrated hardware with award winning industrial design, nor its marketing power tied into the iPod and Apple's retail stores. Android won't be an open iPhone, it will only be a Windows Mobile phone with a better kernel that runs specialized Java software instead of Win32 or .NET code. Don't expect consumers to be impressed by that. The Biggest Missing Feature. There is one remaining factor that strangles to death any last remaining hope that Android might assassinate the iPhone and assume the crown of the âDOS of smartphones.â That is: Android delivers zero price advantage to consumers. In 1981 and 1991, consumers who wanted Apple computers faced the sticker shock of a somewhat arrogant price tag. Apple sold its computers, as it still does, at the higher end of the market, but there was simply far more range in prices available. In 1981, that meant the Apple II was $2600 and the new Apple III was $3500, even before you added a monitor. On the low end, Commodore sold its far less powerful, but âstill a computerâ Vic-20 for $300, while IBM entered the market with the IBM PC at $3000. Over the next few years, Apple focused on delivering additional sophistication at the same price, releasing the $10,000 Lisa and then the $2,500 Macintosh. IBM continued selling PCs in the same $3,000 to $10,000 range, but other DOS PC vendors began selling machines at prices that ranged as low as $1500. That left Apple with a roughly $1000 price premium over low end PCs. The products weren't really comparable, but consumers only saw the huge price difference. In 1991, Apple was still selling moderate to high-end Macintoshes for $3,800 to $10,000; the crippled Mac LC was $2500, and obsolete-at-birth Mac Classic ranged from $999 to $1500. Windows allowed PC makers to ship a functional $1500 PC and claim a rough approximation to Apple's $2500 entry level system, maintaining that apparent $1000 price premium. Today, pundits are lucky to find a Dell or HP system that is even a couple hundred dollars less than a comparable Mac. However, in the smartphone business, the iPhone 3G is now the same price, if not less, than generic competing phones on the market. Even more significant is the fact that the price of the phone hardware is nearly nothing compared to the cost of the service plan. This fact simply eases any price premium that could cause buyers to flock to a smartphone running a generic operating system over buying the iPhone 3G, regardless of whether it runs Windows Mobile or Android. 1990-1995: Planting Software Seeds Android Partners Have Already Failed. That same pricing principle similarly prevented buyers from considering many of the alternatives to the iPod. While Apple's original iPod models were more expensive than many of the first MP3 players on the market, they were price competitive with models offering similar features. By 2004, it was Apple who was undercutting MP3 competitors on price. Microsoft offered zero price advantage when it began selling the Zune, a major factor in its failure, but Microsoft simply couldn't out-price the iPod; it was already losing money offering the Zune at the same price as the iPod. Apple now has tremendous market power in buying RAM and other components that will prevent any competitors from being able to offer a huge discount over the iPhone's $199 price tag. Even if competitors were to give their phones away, they would only offer a $200 discount to users who would then still need to pay the same mobile fees to use the phone. Android's other partners, including Samsung and LG, have already failed to capture any significant market share in the music player market. Are they going to maintain their position as smartphone makers now that they face similar competition from Apple, its iPod ecosystem, its iTunes Music and Apps Store, Apple's retail store experience, and other factors that are pushing the iPhone? If they can, it is not obvious how partnering with Android will help. Other Problems for Android. Android was announced in early November 2007 and was followed with an early preview SDK within a couple weeks, a month ahead of Apple's initial announcement of the iPhone 2.0 SDK. However, between March and July 2008, Apple delivered nine progressive releases of its SDK, opened its App Store, and sold 60 million apps, raising $30 million to support iPhone software development in just the first month. It has since released three more SDK updates to developers related to iPhone 2.1, which is expected next month. Android just published its first open SDK beta update earlier this week, warning developers that âapplications developed with it may not quite be compatible with devices running the final Android 1.0.â Additionally, Android still has no phones available. By the time the HTC Dream is expected to launch, Apple will have an installed base of around ten million iPhone (and iPod touch) users supporting software development through iTunes. The business model for selling Android apps is no better than that for selling jailbreak iPhone apps: there is no iTunes Apps Store to promote them, so users will have to track them down on their own. Android developers also have no real freedom that jailbreak iPhone developers lack. The only difference is that there are ten million iPhones to sell jailbreak apps to, and currently zero Android phones. If selling a jailbreak iPhone app sounds like more trouble than its worth, imagine trying to sell Android apps to a non-existant audience. Now add the official iPhone App Store into the mix, where publicity, promotion and profits are booming. What platform is going to have the most applications? How many users will flock to a smartphone platform with no apps? The wisdom of releasing a desirable phone and achieving a significant installed base before releasing an SDK makes a lot more sense in retrospect. Additionally, while Apple has a decade of experience in shipping regular updates to Mac OS X and its Xcode developer tools, Google has only shipped a random assortment of web-oriented SDKs (a number of which have been abandoned) as a tangent to its core business of selling advertisements. When the Android SDK 1.0 is finished later this year, developers will not only lack an installed base to sell their apps to, but will also have no high profile market for selling their apps in, and subsequently no financial incentive to develop applications that add value to the Android platform, just like Linux on the PC desktop. Around the same time, possibly within the next month, Apple will be shipping its second major OS release: iPhone 2.1. Apple will also be upgrading its entire user base to the new software so that developers will have a cohesive platform to target. This mirrors the efforts Apple has taken to upgrade its Mac OS X users to the same reference release. Mobile developers will be seeing money pouring in via iTunes while crickets chirp in the Android section of various mobile online stores. Appleâs iPhone Vs. Other Mobile Hardware Makers: 5 Revenue Engines Same Same, But Different: DOS Model Problems. Android developers will also have a series of other problems to manage. Like Windows Mobile, Android is intended to support everything, from BlackBerry-style keypad phones with a small touchscreen to the simple Windows Mobile Smartphone form factor lacking a touch screen to iPhone-like full size touch screens. Also like Windows Mobile, Android phone makers will have the option to leave off Bluetooth, WiFi, GPS location services, graphics hardware acceleration, and so on. Each Android phone will also have unique camera hardware, support for different video and audio codecs, and varied support for other differentiating proprietary services demanded by mobile operators. This will force developers to to make complex decisions regarding the lowest common denominator they choose to support. So while the iPhone will have a cohesive feature set, a managed software environment, and a functional market, Android will be a loose federation of hardware makers selling the same random features found on Windows Mobile today, with a chaotic development environment that lacks any central market for users or developers. And it will be run as an experiment by a company with no experience in consumer hardware or platform development. The Missing Tap. One specific example of the âDOS model problemâ is that Android currently does not support multitouch. It's not touched on in the API, and Google quietly tap dances around its omission. Why no multitouch? Because multitouch screens are expensive, and most OHA hardware members are more interested in making a profit in a competitive phone market rather than impressing consumers as Apple did with the iPhone. Most existing smartphones, even those trying to directly rival the iPhone, use a stylus driven, pressure sensitive tap screen or a simpler, cheaper touch technology that lacks support for sensing multitouch. The iPhone's screen can actually sense up to five fingers at once, but the primary feature multitouch offers on the iPhone is the two fingered tapping and the pinching effects everyone associates with it. Android could certainly support multitouch if there were a demand for it, but that's the point: Google knows that its hardware partners are cheap and unlikely to put out hardware that actually competes with the iPhone. Instead of using expensive technologies that deliver clever yet largely invisible functionality, OHA members, just like PC makers, are far more likely to add flashy, impractical gadgety fluff that's cheap to tack on, such as slide out keyboards, neon tubes, and scratch and sniff stickers. That's how you impress gullible nerds on the cheap. Google itself is blowing smoke and erecting mirrors to distract from the reality that it being a âDOS vendorâ means supporting bargain basement hardware from penny pinching duplicators. Android has been demonstrating some âwowâ features such as a Street Maps app that pans around based on an internal compass in the demonstration phone. The problem is that that kind of thing only makes for a fun demo. Nobody needs to twirl around their phone in the air to see a view of the other side of the street, but everyone who has used an iPhone will wonder why they can't pinch to zoom out. Even worse, most Android phones aren't going to have a compass built into them, so Google is demonstrating features most Android users won't be able to use. That Sounds Like Microsoft… Google's design decisions are beginning to look a lot like Windows Vista; rather than actually working to make laptops boot faster, Microsoft came up with the idea of adding a small screen to the back of Vista laptops so users could check their email without having to wake the system up. But this was a stupid idea for a number of reasons, the most obvious being that most users just want a laptop that boots up quickly. Few laptops got the mini screen, but every user who tries Vista on their laptop will wonder why it doesn't boot up as fast as Mac OS X Leopard. In the same way, Google is advertising features for Android that most users won't ever see in their actual phones while ignoring things people will expect based on their exposure to the iPhone. Android is simply selecting the wrong features. Android will offer the advantages of supporting MMS, recording video, and the list of other features Windows Mobile already supplies. Those features didn't stop Apple from firing past Microsoft in the smartphone arena however, just as the Zune's highly touted WiFi and screen didn't phase iPod buyers. Incidentally, just months after the Zune, Apple had not only demonstrated a larger display but a higher definition multitouch screen, and not only WiFi, but functional WiFi that could be used to browse the web or check email. This suggests that Apple, with its faster release schedule, won't stay behind any of the leading features potentially offered by Android for very long. Android partners, however, will find it as difficult to catch up with Apple's unique features, just as Microsoft has been stymied to keep up with Mac OS X, the iPod, and the iPhone. The underlying reason: both Google and Microosft are tasked with maintaing support for a huge variety of hardware options demanded by all their partners. Apple has the unique circumstances to do only what it needs to do itself. Android in Windows Mobile's Shoes. Like Windows Mobile, Android faces a difficult market. In the US, it competes against the popular BlackBerry in corporate markets and the iPhone among consumers. Worldwide, it competes against entrenched market leader Nokia. The difference is that Google, unlike Microsoft, has no in. Windows Mobile was adopted by Windows-bound IT shops despite its weaknesses. Nobody has any preexisting reason to try an Android phone apart from hobbyists and open software enthusiasts, a demographic that has done little to move Linux on the PC desktop. Google also lacks Microsoft's installed base; it's starting from zero. The smartphone industry initially doubted Apple's chances of making much progress with the iPhone, despite the company having the Mac platform, the iPod, retail stores, platform development experience, marketing savvy, industrial design prowess, and so on. Google doesn't have any of those things. Mobile Providers vs Android. Apple also started with an exclusive partnership with AT&T, a three legged race that demanded effort from both. Google is hoping that hardware makers handle the hardware details and that mobile providers will be excited to sell its Android phones. While hardware makers such as HTC clearly appreciate having found a free alternative to Windows Mobile, it's not obvious why providers would be excited about Android, as it promises an openness that most mobile providers strongly oppose. AT&T took a big risk in getting behind the iPhone, as the phone encouraged users to use email rather than fee-based SMS and MMS, it supported WiFi for data access, and it bypassed AT&T's MEdia Net services to plug into iTunes instead. Verizon refused to parter with Apple and grant it those kinds of concessions. Is AT&T going to take a similar risk to partner with a phone that is not exclusive to it, and is Verizon now going to open its arms to support phones that do not exclusively support BREW, VCast and its other proprietary services? While Android may well eat into Microsoft's Windows Mobile business by stealing away its hardware makers, it seems unlikely that Android will ever serve as more than free alternative to Windows Mobile in a market where Windows Mobile is increasingly irrelevant. Android may have the dubious distinction of swallowing Microsoft's mobile business the same way Microsoft ate up the Palm OS, but even if it accomplishes that goal, Google will likely find itself unsustainably hungry immediately afterward. It will also find itself swimming in a shark tank of hungry rivals, including Nokia's Symbian, RIM's BlackBerry, and Apple's iPhone. Symbian is the final generic platform vying for the opportunity to play DOS in the smartphone market. The next article will examine Nokia's chances in its bid to match Microsoft's PC dominance in the mobile market while setting out in a new venture to copy Android's open software model. Did you like this article? Let me know. Comment here, in the Forum, or email me with your ideas. Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast (oh wait, I have to fix that first). It's also cool to submit my articles to Digg, Reddit, or Slashdot where more people will see them. Consider making a small donation supporting this site. Thanks!
-
Demo of Opera Mini 5 on the iPhone
Just submitted to the App Store this week. Color me skeptical regarding their claims that it’s the “most used browser on mobile devices”, though. Most-installed, maybe, but more used than MobileSafari? I’ve tried the Android version (which seems extremely similar to the iPhone version) on the Nexus One, and it is indeed fast. But the speed advantage is most noticeable over EDGE; on Wi-Fi, it’s about the same, but the rendering is worse. Definitely interesting, though. â
-
â Mozilla, Video, and Mobile Computing
With Microsoft’s announcement this week that IE9 will support H.264 HTML5 video, three of the big four browsers — IE, Safari, and Chrome — will soon support H.264. The only major browser holdout is Firefox.1 Mozilla is couching their position in terms of ideals: H.264 is an open industry standard but patent-encumbered and has licensing fees; Ogg Theora is open, not patent-encumbered, and free of licensing fees. Brian Crescimanno has written a fine argument that this is a situation where pragmatism should win out over idealism, and that Mozilla should include support for H.264 (in addition to Ogg Theora) in Firefox. As he points out, it’s not as though Mozilla has never before supported proprietary formats (e.g. GIF). But Crescimanno’s best point is that Mozilla’s support for Ogg Theora is doomed because it’s technically inferior to H.264: People and businesses are willing to embrace free software when it provides an equal or better product than the proprietary alternatives (see the success of Linux on the server). However, when free software doesn’t keep up with the best non-free products, people stay away (see the lack of success of Linux on the desktop). Simply put, there just aren’t that many people who share the same moral imperative as the Free Software Foundation; most of just want it to work. Put another way, “open and better” is a recipe for success; “open but worse” is a recipe for obscurity. Popular video publishing sites aren’t going to use Ogg Theora instead of H.264, and I think they’re very unlikely to support it in addition to H.264, either. Encoding and storage are expensive; supporting both would at least double those costs. The practical effect of Mozilla’s current position will not be to drive adoption of Ogg Theora. What’s going to happen is that Safari, Chrome, and even IE9 users will be served HTML5 video, and Firefox users will get Flash. Publishers will support both HTML5 video (for Safari, Chrome, and IE9 users) alongside Flash (for browsers that don’t support HTML5 and H.264) because they already have the Flash video publishing infrastructure in place, and because Flash can be used to publish H.264-encoded video. Publishers don’t have to encode (and store) video twice; they can encode (and store) it once and serve it two different ways. The sites that are the most popular — YouTube being number one, obviously — would bear the most expense to support an additional encoding format. It isn’t going to happen. So, even those using the latest version of Firefox will be treated like they’re using a legacy browser. Mozilla’s intransigence in the name of “openness” will result in Firefox users being served video using the closed Flash Player plugin, and behind the scenes the video is likely to be encoded using H.264 anyway. There’s another factor that occurred to me recently: mobile computing. Apple, Google, and Microsoft all seem to view mobile computing as a top-level priority. H.264 video playback on mobile devices is aided by dedicated H.264 decoding hardware. That’s how the iPhone and iPods get such long battery life for video playback. I believe this is also true for Android devices, and will be true for Windows Phone 7 and Zunes. Relying on the CPU for video playback simply isn’t practical on mobile devices. There are no hardware decoding chips for Ogg Theora. If you want to send video to mobile devices, H.264 is the only practical encoding for the near future. (I think this explains why Microsoft is throwing its support behind H.264 rather than some proprietary video codec of its own — Microsoft knows a winning position when it sees one.) Ogg Theora may well be “good enough” for desktop computers, but it’s completely unacceptable for mobile devices. Mozilla, as an organization, doesn’t seem to value mobile computing as a top priority. Yes, they have mobile initiatives. But the only platform they have a mobile browser for is Nokia Maemo. All of you using a Nokia Maemo, please raise your hands. Crickets. Compare and contrast with WebKit, which I suspect will soon have more mobile than desktop users. The needs of mobile computing are driving the adoption of H.264 HTML5 video more than anything else, but Mozilla doesn’t feel that pressure because it isn’t a mobile company. And at this point, “not a mobile company” is getting hard to distinguish from “not a relevant company”.2 Opera is on Mozilla’s side, supporting Ogg Theora instead of H.264, but Opera isn’t a major browser in my book. Feel free to include it in your book, though. ↩ Opera, on the other hand, is a major player in the mobile market. I think it’s safe to say that Opera is far more relevant in mobile computing than on the desktop. So it strikes me as odd that they aren’t on board with H.264. Perhaps (unlike Mozilla) they truly can’t afford the licensing fees. ↩
-
â Putting What Little We Actually Know About Chrome OS Into Context
It has seemed obvious for some time that Google would someday release a PC OS. I became convinced after they released Android: if they’re creating and giving away a free OS for phones, why not PCs, too? But I expected that Google’s eventual PC OS was going to be an expanded meant-for-a-bigger-screen version of Android — sort of the inverse of what Apple did for the iPhone. Apple took a PC OS and whittled it down to a fundamental core, then built new handheld-specific UI libraries and APIs on top. The hypothetical PC version of Android I’m imagining would have entailed1 taking the core of the mobile Android OS and creating new meant-for-a-PC libraries and APIs on top. So it’s not weird that Chrome was announced. But what is weird is how it was announced. And, despite the title of the weblog post in which the announcement was made — “Introducing the Google Chrome OS” — nothing has actually been introduced. There aren’t even any screenshots, let alone a demo or any specific technical information. With an expected ship date of “the second half of 2010”, it’s a textbook example of vaporware. I don’t get the timing. Why announce it now, when it clearly isn’t close to ready? Why not at I/O, Google’s developer conference six weeks ago? Or why not wait until it’s ready to release to developers? I like facts, demos, and best of all, shipping products. I don’t like vague promises. Web Apps as Native Apps It’s certainly interesting and ambitious to state that the entire application platform will consist of web apps. If anyone was going to build such an OS, it’d be Google. Much of the initial commentary regarding Chrome OS has been wholly positive, but one common note of skepticism has been with regard to the “web apps are the only apps” aspect, with the frequent point of comparison being the the 1.0 release of the iPhone OS. E.g., Nick Mediati at PC World: Both users and app developers are still hungry for so-called “native” applications — that is, software designed for a particular operating system. A prime example? The iPhone. At the 2007 Worldwide Developers Conference, Apple discussed a “pretty sweet” way of developing apps for the iPhone: Web apps. While the Apple executives onstage spoke of the potential and power of Web apps, many developers and users groaned. They didn’t just want Web apps, they wanted real appsâapps that could take full advantage of the technology the iPhone offered. (As an aside, in the 2007 WWDC keynote, Steve Jobs didn’t describe writing web apps as a “pretty sweet” solution for developers who wanted to write software for the iPhone; he described it as a “very sweet solution”. I described it as a “shit sandwich”.) Mediati was right that not just developers but users wanted native third party apps for the iPhone. The difference from what Google is promising with Chrome, however, is that web apps will be the native apps on the system. Presumably all of the default applications from Google itself will themselves be the Google web apps we already know. It’s an eating-your-own-dog-food issue. What irked about Apple’s endorsement of iPhone-optimized web apps as a “really sweet solution” was that, of course, none of the iPhone’s built-in apps were web apps. They were all written in Objective-C with Cocoa Touch. Apple’s own iPhone apps set a high bar for user experience — a height that could not (and still can’t) be reached with web apps running in MobileSafari. Chrome OS sounds a lot more like Palm’s WebOS than it does the iPhone. Palm isn’t just telling third-party developers to write apps using HTML, CSS, and JavaScript, they’re doing it themselves with the WebOS’s built-in apps. In fact, considering how web-app centric Google is and always has been, Palm’s WebOS is fundamentally more Google-y than Android, a platform where native apps are written in Java. One thing to note regarding WebOS, too, is that while a WebOS app is written with HTML, CSS, and JavaScript and runs within a WebKit frame, it can do more than a regular “web app” running in a browser. The runtime exposes additional JavaScript APIs specific to the WebOS environment. Regular web apps — ones you “run” by telling a regular web browser to load via a URL — can’t do things like access the hardware camera or post one of those cool WebOS system-wide notifications at the bottom of the screen. Or, taking the flip side, you couldn’t just take a WebOS app and run it in a web browser on any other platform. There’s a big potential difference between “web apps” and “apps written using web technologies”. If you’re a programmer, I’m sure you understand that; if you’re not, I worry that it sounds like semantic hair-splitting. The best example I can think of are Mac OS X Dashboard widgets: they too are written using HTML, CSS, and JavaScipt, but they don’t work anywhere other than Mac OS X. I presume that there will be similar Chrome OS-specific APIs for web apps optimized to run on Chrome. But who knows? From the description in the announcement, it sounds like Chrome OS “apps” really could just be web pages. Will it support things like importing photos and videos from a camera? Again, I presume so. But then what gets stored locally and what gets stored remotely, on Google-managed servers in the quote-unquote “cloud”? Something would have to be stored locally, because uploading video (and even just full-size photos) over the Internet can be slow and expensive. The Driver Issue Microsoft has to deal with a veritable mountain of device drivers because Windows has to run on every “Windows PC”. But Microsoft made this problem for themselves. It is Microsoft that decided Windows would run everywhere on everything. No one says Chrome OS is going to run on all, or even most PCs. I wouldn’t be surprised if it’s only supported for use on new PCs that are specifically certified to work with it. Hence the hardware partner list in the otherwise almost information-less “Chrome OS FAQ” Google posted tonight. Chrome Will Not Be a ‘Linux Distribution’ Renai LeMay’s “No Thanks Google, We’ve Got Ubuntu” captures another common reaction to Chrome: In this context, Google’s decision to create its own Linux distribution and splinter the Linux community decisively once again can only be seen as foolhardy and self-obsessive. Instead of treading its own path, Google should have sought to leverage the stellar work already carried out by Mark Shuttleworth and his band of merry coders and tied its horse to the Ubuntu cart. “Linux” means different things to different people. At a precise technical level, Linux is not an operating system. It is a kernel that can serve as the core for an operating system. What most people mean by “Linux”, though, is an operating system built around the Linux kernel. For use as a desktop PC operating system, all the various “Linux distributions” are basically the same thing: variations of Gnome or KDE sitting atop the ancient X Window System. Ubuntu is almost certainly the pinnacle of these distributions, but they’re all conceptually the same thing, and the only significant difference is the choice between Gnome and KDE, and even there you’re just choosing between two different environments that are conceptually modeled after Microsoft Windows. The entire X Windows/Gnome/KDE “desktop Linux” racket has never caught any traction with real people. Almost no one wanted it, wants it, or will want it. My theory on this is rather simple. Early versions of Gnome and KDE were pretty much just clones of the Microsoft Windows UI. They’ve diverged since then, and I’d say Ubuntu’s default Gnome desktop is in most ways better from a design and usability standpoint than Windows Vista. But it’s still fundamentally a clone of Windows — menu bars within the window, minimize/maximize/close buttons at the top right of the window, the ugly single-character underlines in menu and button names. At a glance it looks like Windows with a different theme. The idea being that if you want Windows users to switch to Gnome or KDE, you’ve got to make it feel familiar. But that’s not how you get people to switch to a new product. People won’t switch to something that’s just a little bit better than what they’re used to. People switch when the see something that is way better, holy shit better, wow, this is like ten times better.2 So I think Gnome and KDE are stuck with a problem similar to the uncanny valley. By establishing a conceptual framework that mimicks Windows, they can never really be that much different than Windows, and if they’re not that much different, they can never be that much better. If you want to make something a lot better, you’ve got to make something a lot different. Whatever Chrome OS turns out to be, it isn’t going to be that kind of “Linux”. They’re using the Linux kernel, yes, but they’re building something new and original on top of that. Linux is to Chrome OS what BSD is to Apple’s iPhone OS — which is to say something that users will never see, smell, or notice. Everything from TiVo to Palm’s WebOS uses Linux as the kernel for their operating system — using the commodity underlying operating system (in the comp-sci sense of the term) and ignoring the commodity user interface systems. Here’s the telling line from Google’s announcement: The software architecture is simple — Google Chrome running within a new windowing system on top of a Linux kernel. From a user-level perspective, Chrome isn’t going to look, act, or work anything like Windows. And that’s why Google has a chance to make something that might actually prove popular in a way that Ubuntu hasn’t. An Odd Name I’m sure what I’m about to suggest is anathema to Google employees, but in addition to the sky high vapor-to-bits ratio, there’s another aspect of the Chrome OS announcement that reminds me of Microsoft: the name. In the same way that Microsoft has used “Windows” to describe very different things — both a computer operating system and an online suite of web apps — Google is now using “Chrome” to describe two very different things. A web browser is very different from an OS, even if the OS only runs the browser. Google themselves recently conducted a survey that suggests that most regular people do not understand at all what a “web browser” is. If regular people are confused about what a browser is, it’s a good bet they’re even more confused about what an “OS” is. Calling them both “Chrome” isn’t going to help clarify the matter. Install Chrome the browser on your PC and if you don’t like it, you can delete it and you’re right back where you were. Install Chrome the OS on your PC and if you don’t like it, you can delete it and you have a blank hard drive. I’m not predicting that people will mistakenly install one when they meant to install the other; I’m just saying that significantly different things should have significantly different names. Client-Services, Not Client-Server There have been numerous client-server systems throughout the history of the computer industry. Some popular; some not. The basic idea behind all of them is that you have many cheap client machines that users actually sit in front of, connected to a few expensive server machines that do most of the actual computing. The complexity is almost entirely on the server side, managed, presumably, by professional experts. A single client machine, unconnected to the network, is pretty much useless. Chrome OS is in many ways a return to that model. Web apps largely consist of server-side code, with a relatively thin layer of JavaScript that runs on the client. Data, too, mostly resides on the network, not the client machine. But there’s a big difference. The Chrome OS model isn’t about thin clients connecting to a server. It’s about thin clients connecting to many and any servers. One of the few sure things about Chrome OS is that it’s going to work well with Google’s own web apps, but the web is open, and Google is a strong proponent of open web standards. Everyone will have the opportunity to write web apps that run just as well in Chrome OS as Google’s own. At an abstract level, there is much appeal to this concept. With all of your data and all of the software you use online, you have nothing to back up. Nothing to migrate when you buy a new computer — just log in from a different Chrome OS machine and there’s all your stuff. But at a practical level, how well will this actually work? Is it feasible to use Chrome OS as your sole computer? If not, how big is the market for “secondary” computers, especially as (a) more and more people buy laptops to serve as their primary machine, and (b) more and more people buy iPhones and Pres and Android-based mobile phones? I say: not very big. In short, will Chrome OS pass the dog food test: is it something Google’s own engineers will want to use? I’m skeptical about the prospects of any new system or product that isn’t intended for use by the people creating it. Gmail, for example, is the best web mail system because it was designed to be used not just by “typical” users but by expert users, including the engineers at Google who made it. The iPhone is simple enough to appeal to almost anyone, but guess which phone the people who created it use? Make something intended not for your own use, but for use by dummies, and you’ll usually wind up creating something dumb. The future of computing probably is in the direction of thin clients connecting to network services for storage and software, but my hunch is that Chrome OS is too thin. Or, perhaps, it will entail rather than would have entailed, as I’m not convinced that the existence of Chrome OS precludes Google from also releasing a PC version of Android. It sure would be odd for Google to produce two competing netbook-optimized OSes, but what little we do know about Chrome OS so far is, well, a little odd. And because they’re both open source, it could be that Android continues evolving into a credible PC OS through community effort alone. ↩ The group that’s the most enthusiastic about Gnome and KDE desktop Linux systems consists of those who care the most about the political and licensing aspects. With regard to the freedoms that stem from the software being open source, something like Ubuntu isn’t just, say, ten times better than Windows or Mac OS X, it is infinitely better. ↩
-
Opera: Apple won't let us in the App Store
Filed under: Internet Tools, App Store, SDKOpera Software CEO Jon Stephenson von Tetzchner said in a New York Times interview yesterday that its engineers have developed a version of the Opera web browser that works on the iPhone, but Apple has rejected it for the App Store because it competes with Safari. This isn't unprecedented: Apple rejected an app called Podcaster possibly because it duplicates functionality in an upcoming version of the iPhone software. Podcaster was (for a time) available via ad-hoc distribution before that, too, was shut down. Daring Fireball's John Gruber suggests that Apple rejected Opera because the browser included its own JavaScript interpreter, something forbidden by the iPhone SDK developer agreement. Opera makes two flavors of its mobile web browser: Opera Mini for most mobile phones, BlackBerry, Palm, or Windows Mobile; and Opera Mobile, a more featured version for Symbian and Windows Mobile. A beta version of Opera Mini for Android is also in development. Update: Gruber used his massive Rolodex over the weekend to determine through an unnamed source that the app may not have even been submitted to the App Store. Huh. Read | Permalink | Email this | Comments