Brandon Werner

Rick Ross points to some amazingly bad conclusions from Nokia on their supposed “iPhone killer”, the Tube, and then throws his own in for good measure,

Speaking at a recent conference, Forum Nokia VP Tom Libretto, confirmed that the Finnish telecom giant has a new touchscreen device in the pipeline, tentatively called “Tube” (details and pics at symbian-freak.com.) In marked contrast to Apple, it appears that Nokia is embracing standards, and the Nokia Tube will likely have Java inside from the start!

Speaking about the Apple competition, Libretto had this to say about 6 million iPhones having been shipped so far, “We’ve done that [volume] since we’ve had dinner on Friday.”

The problem with all of this is that it shows Ross, Nokia and the mobile device industry in general still haven’t managed to figure out what makes Apple and it’s new mobile touch platform (which includes the iPhone, the iPod Touch and we can only assume more to come) so compelling. It’s difficult to watch an industry that is slow to learn from a game changing competitor, as I experienced in the insurance industry when Progressive came on the scene in 2000 with it’s direct to consumer model. For that topic though there is a massive amount of business literature, just Google “Moved” and “Cheese”

I will also let slide Nokia’s attempts to compare iPhone numbers to Nokia numbers in the article, without even mentioning that those numbers would have to be all shipping Nokia phones, not just smart phones and certainly not just the “Tube” prototype as it has yet to be released. I doubt we’ll see this new Java experience, if they even follow through with it, on the cheap plastic candy bar phones Nokia still sells in the millions.

For this entry, I’ll go Daring Fireball on Ross’ allegation summed up politely in his sentence: “In marked contrast to Apple, it appears that Nokia is embracing standards, and the Nokia Tube will likely have Java inside from the start!”

The False Java Test

First of all, why do people still believe Java on a mobile platform, or any consumer facing platform for that matter, is essential? Not only could you point to the numerous failures of the “write once, run anywhere” approach from both a technical and historical perspective, this litmus test - shouted whenever a distributed platform emerges on the market - is never a predictor of a device or business’s success to both the consumer and the developer. In fact, it sometimes hurts it. More on that later.

The False Standards Argument

Second, Ross indicates that Nokia will be a better platform versus iPhone because of it’s acceptance of the current Java standards. However, its obvious application code executing in a runtime through a mobile phone currently cannot scale visually. Can you imagine a MIPS or JME Jar that has 8-bit graphics designed for a non-touch postage stamp sized screen running on an iPhone? This is an important argument, because Ross indicates that with “standards” and “Java” we’ve won something here. We haven’t. All those “standards” compliant mobile apps currently out there wouldn’t even be worth the download to the Nokia “iPhone killer”.

Think on this: we’re talking about a new GUI layer that a developer would have to write against to even begin to approach the smoothness of the iPhone. This would be about as “new” as writing to the iPhone SDK for a developer. The benefits of these supposed standards would win us - ease of development and using existing developer knowledge of the code and runtime - wouldn’t work.

You could counter with JavaFX, which Sun took great pains in 2007 to show off with a UI that looks dead on the iPhone in it’s own attempt at an iPhone killer. Yet have you seen this running anywhere besides on that JavaOne stage in 2007? Sun released an API for JavaPhone, but it seems to have went nowhere - as embarrassingly indicated by the fact that the graphics on the Overview page don’t even load.

You may also counter with Google’s Android. However Android is JINO (Java In Name Only) and can’t claim the use of any standards from the mobile industry or Java. It has it’s own runtime and compiler. You could argue you did get the Java developer base here, but that just feeds in to my third argument below. I agree with Google/Danger’s approach though, since I believe that to program in the mobile space you need, to borrow a buzz word, a Domain Specific Language with constraints and customizations to the device that you are targeting.

The False Write Once Run Anywhere Argument - Now Context Is Key

This carries me in to my third point that both Nokia and Ross miss - you do have to think differently when writing an application for a mobile platform. Carrying over Java developers from the desktop environment (or more likely and worse - the server environment) to the mobile platform with the same paradigms is a recepie for disaster, if just because they will demand and create the same experience on the mobile platform. (Think Windows CE circa 2000 when it had the Start button in the same place as the desktop operating system).

This is evidenced by the predictable cries from these very same developers when it came out that the iPhone SDK allowed for no access to background threads. The need for this paradigm change is real and was expressed very elegantly by Craig Hockenberry of IconFactory fame in his blog entry Brain Surgeons,

Twitterrific on the iPhone could definitely make use of a background process to gather new tweets. In fact, a prototype version of the software did just that. And it was a huge design failure: after doing XML queries every 5 minutes, the phone’s battery was almost dead after 4 hours. In fact, the first thing I said after giving Gruber this test version was “don’t use auto-refresh.”

The heart of the problem are the radios. Both the EDGE and Wi-Fi transceivers have significant power requirements. Whenever that hardware is on, your battery life is going to suck. My 5 minute refresh kept the hardware on and used up a lot of precious power…

…It takes several months of actual iPhone development before you eventually realize that the iPhone requires a completely different mindset. Until that happens, you’ll make assumptions based on desktop experience, and that in turn will lead to a lot of bad designs.

Java - even in runtime philosophy - looking out over the horizon - is poorly matched for the new environment in which we find ourselves. You can even extend this argument to any software not written to a platform’s context, as Gartner recently wrote in regards to Windows Vista and the problems of it’s monolithic OS approach. They want Windows kernels targeted to what is essentially contexts. Add to this argument the activity going on in the mobile/UMPC space and this argument against both Sun’s Java and Microsoft’s Windows/.Net approach becomes even more compelling. No one can play with a Sony UMPC running Windows Vista at your local Best Buy and come away arguing that it fits in to the user experience and context.

I don’t hold out a lot of hope of a iPhone-esque compelling experience from any developer writing in the JSE or JME space on this “iPhone killer”. I highly doubt anyone would look at low level API access of UIKit and Foundation that allows for incredible visual control over an application, and then look at what history would tell us Java would come up with, and not pick Apple’s approach.

I came to the Mac in 2003, shortly after getting my first iPod. It was my first visit to an Apple retail store and having a small business at the time geared toward urban planning and technology it was easy to migrate over. If I had to nail down one thing that made me a Mac fanatic it was the integration of what I had assumed from years of Windows and Linux use were technologies impossible to orchestrate and manage in an effective way. There was the graphical tools over the core UNIX/BSD tools that made administration a breeze. There was the bluetooth management done right, with the ability to SMS text message and display incoming calls through Address Book. There was PIM synchronization done right through iSync, where all your various synchronization efforts no matter if it were an iPod, .Mac or Motorola phone were gathered in one place. It was how PDF and other display technologies were not some API installed on the side and slow to load but first class citizens sitting on top of the OS. It was a revelation.

Later, I would discover the Mac community, with Daring Fireball and TUAW that provided a unique and demanding view of technology that made me better at my job and my profession.

Apple technology inspired me to push harder for better solutions and to demand better solutions and experiences from other vendors and software developers, including myself. You could no longer use the status quo excuse with me anymore. I didn’t care if other applications were ugly or information dense or laid out incorrectly. You could do it right. People would care, not just Grandmas and kids. It made my life better, the programmer-geek who always clicked the Advanced tab on all my applications, to have this beauty and thought in applications. I don’t think I’m alone, as almost all the most unforgiving and critical users of any online or personal application are Mac users.

The Apple Last Mile

In almost all of these examples, one thing stands out. The concept of the Last Mile. In technology it is often used to refer to the final last hurtle in integration, no matter if it’s bringing faster internet speeds to your home, better security to the corporate network or even a better web experience to the end user. The understanding is that it’s relatively easy to build an incredible infrastructure and technology within the confines of your control and influence, but as soon as you need to build that bridge to the end of the experience things usually get complicated, unpredictable and constrained.

It’s also generally understood that the Last Mile is where experiences and projects are won and lost. It has broken the hearts of many entrepreneurs and business executives alike, particularly in technology. Many people have laid their pipe right up to the beginning of another pipe and stood there scratching their heads perplexed. Many are even forced to give up having come that close.

In all the experiences Apple software gives us, the idea of the Apple Last Mile is what makes the Apple experience a good one. You can find the example in the Google Maps application on the iPhone, the SMS interface on the iPhone and in the iTunes Music Store and iPod integration among many others. How many companies simply leave the experience of the music purchase and sync to someone else while they control the device? How many companies just provide J2ME on their mobile device and leave Google or others to write the application? It is always these very places, where one pipe faces the other, that defines the user experience.

It’s not a small thing. When you spend hours trying to configure your wireless router, when you spend 30 minutes getting your bank statement to download to your financial software, when you have to spend time telling the phone representative your account information you just entered on your phone over again for the third time, when you get a sync error message on your MP3 player minutes before your bus arrives to take you to work, you get the reason why this is important.

If you take the time to analyze what creates such trust in those that use Apple products, and why other products fail to generate the same trust, it is the Apple Last Mile that holds the secret. It may seem easy on the surface, but the Last Mile is the hardest thing to get right.

Sadly, however, the experience that Apple got so right, and that users trusted and assumed Apple always would, has begun to erode. They have, through the break-neck rate of development of products and software, lost the Last Mile focus.

Example: The ExchangeConduit and iSync

One example is the state of synchronization in OS X. In Leopard, Apple introduced a few new interesting synchronization options in to their operating system. Showing a curiously growing closer relationship to Yahoo!, they added Yahoo! sync to the Address Book as well as Exchange address book synchronization. These were introduced by means of iSync conduits. Conduits are amazing pieces of engineering from Apple. They are plug-ins to the synchronization engine that powers any and all data synchronization across devices and platforms. It has been used by many device manufacturers and software developers to add syncing of personal information across diverse platforms, and has proven to be an extremely flexible framework.

Sounds cool, huh? How do you do it?

Good iSync Hunting

The first question is where do you go? There are currently three places where you have to look to interface with iSync. The first is the old standard, the iSync application itself. Previously, this was the hub of all synchronizing activity and confusingly still is, it just doesn’t tell you. In fact, it is probably one of the most important applications in Mac OS X, and it wins the prize for the most understated application interface in history. All of your Address Book, .Mac, Yahoo! and Exchange synchronization runs through the iSync framework, including your iPhone. Pretty busy application, right?

Although previously the place where you could see your iPod, your mobile phone and even .Mac listed along with settings and management features, now iSync sits there with a blank stare. Worse, although there is absolutely no applications or devices on the iSync application, clicking the sync button will actually sync your devices and your applications universally. As we’ll see below, Apple even directs you to this application when there’s no indication how to sync your data any other way.

It would seem Apple has decided this iSync application is only for non-apple phones (even though the iPhone is there, just hidden). It’s not being neglected; Leopard has even included a new iSync plug-in maker so you can make your own phone plug-in.

As mentioned, although it was once the hub of all things sync, there doesn’t seem to be any sync options for Exchange or Yahoo! here. I would say we are safe leaving this interface as it has nothing to do with Exchange synchronization except that, in very un-apple fashion, it does. We are actually going to have to return to this interface when we eventually do synchronize with Exchange, even though Exchange Address Book synchronization has nothing to do with third party mobile phones at all.

The second place one might look is the iTunes/iPhone/iPod sync interface. You can sync your address book to Yahoo! from there, so it could make sense they would also add the same functionality for Exchange:

Here we do find the Yahoo! sync, and it would make sense that this not only means iPhone to Yahoo! but to Yahoo! and your personal Address Book as well, although this is not nearly as clearly indicated as it was when all of these various sync points were in the iSync application. Someone might pause extra long, as it seems this is where you would setup Exchange Address Book synchronization since the Yahoo! conduit for your address book is represented here. Some might even assume if it’s not listed here, the feature isn’t available to them.

The last place someone might look would be the .Mac synconization screen.

This interface, while showing no un-checked Exchange option, does show us yet another Address Book conduit, this one for .Mac accounts. Many users are surprised to find applications that have registered themselves with this screen that may have long been deleted or did not give indication they were adding themselves to the list. On mine is a Transmit Favorites that I don’t use and a “Entourage Notes” from Office Beta 2008 that has been un-installed. You can’t remove them, and you can’t inspect them to find out what data they actually synchronize if the title isn’t descriptive.

We finally find Exchange Synchronization

At this point, I’ll assume we get lucky and go to the Address Book itself, an application designed so simply and elegantly that we might not think it has Preferences at all. After all, we haven’t had to go in to the Address Book’s Preferences at all to synchronize with our iPhone, iPod, other mobile phone, or even Yahoo!. Why would we even be tempted to look there? Turns out, it’s sitting there with other duplicate interfaces for both .Mac and Yahoo! address book synchronization.

Configuring the options is slightly complicated, but nothing that a poor soul use to typing in Exchange servers and authentication information would have trouble with. Using this feature depends on WebDav being enabled on your Exchange server and that your administrator has Outlook Web Access (OWA) enabled. Apple is smart enough to append the /exchange/username to the mail server you enter. So, if you go to mail.mycompany.com to get your email on the web from Exchange, that’s all you need to type in the server field. After you are finished, just click OK.

Then nothing happens.

It’s at this point someone, even a technically savy user like myself, has to do what they would never admit doing to their geek friends: go to the Apple Support website. It’s here that it gets really ugly.

From the Apple support document on Exchange Address Book synchronization:

To manually synchronize Address Book and Exchange, open iSync (located in the Applications folder), choose iSync > Preferences, select “Show status in menu bar,” and choose Sync Now from the iSync status menu.

In case your wondering if there is any indication that you have enabled Exchange Syncronization in the iSync application you are told to open, there isn’t. To make matters worse, if you do click “Show status in menu bar” as indicated, and you click on that icon, you are greeted with the text “Open .Mac Sync Preferences”, even though it has nothing to do with .Mac synchronization. Someone might assume you need a .Mac account.

In fact, it has nothing to do with iSync the application as far as the end user is concerned, as there is no visual indication that the iSync application actually does have the power of setting every enabled conduit in to action. And just in case you need another interface snafu, the iSync application icon still says “Never Synchronized” even after synchronizing your Exchange Address Book with your Mac Address Book.

Even when you do click Sync Now from the iSync status menu as the Apple document suggests, there is absolutely no progress bar or indication what is being synchronized and where you are in the process (synchronizing Exchange Address Books can be a very long process). All you have is the swirling iSync button that is… according to the application itself, synchronizing nothing.

Last Mile Missed By A Mile

Once a feather in the cap of OSX, especially in the world of Microsoft’s ActiveSync, iSync and it’s pluggable architecture and trustworthy synchronization has now turned in to something that is much worse. Yet, returning to the idea of the Last Mile, it is usually this area that Apple gets right. It certainly did when it needed to sync with mobile phones and iPods in the past, and it even took the time to write an API that allowed others to expand and add functionality that Apple hadn’t. Just see MarkSpace’s Missing Sync products. Just as a comparison, look at the old iSync interface from Mac OS X 10.3, when iSync still had a duplicate interface in iTunes but managed to keep everything registered with the iSync interface in one location as seen in this shot from Terrie Miller on MacDevCenter:

iPhone Island: They’ve Even Built The Pipes!

It would be fine if iSync was the only thing that was slipping away from Apple’s Last Mile philosophy. However, we can also see the same lack of connection between the Note functionality in Mail and that on the iPhone. Even though they both were obviously written to connect and be used in unison, the pipes don’t connect. The best you can do is synchronize with your IMAP account, a hack that makes your notes and ToDos appear as email messages with no special metadata attached. There has been complaints about ToDos lacking on the iPhone, and even the ability to synchronize widget data between the iPhone and your Mac. Doing any of this wirelessly through Bluetooth, something that Apple beat Windows PCs hands down with in 2003, is lacking as well. It was un-thinkable they wouldn’t have SMS messaging from Address Book integrated with their new iPhone, a feat even the Motorola Razr is capable of.

Beyond the iPhone, the iPod Touch shipped with no calendar editing, the dock on the side last minute fix, Time Machine on a remote AirPort disk being removed, iTunes allowing ringtones and then disabling them only to re-enable them again, and of course the iPhone price cut.

Apple Needs Some Time Off

All of this would be easily dismissed as nit-picking if it wasn’t for the fact that Apple had demonstrated the ability to execute so amazingly before. The almost shockingly smooth Intel transition and the steady iPod updates gave Apple the aura of a company so good at product line execution and strategic planning it seemed magical. It was almost Willy Wanka-ish in the public consciousness. It reached it’s height during the iPhone unveiling in the beginning of 2007, and from there on the year has been one of delays, back-peddling and many many hours of overtime.

This is simply signs of stress fractures on the part of Apple. Their level of quality and Last Mile ingenuity is being squeezed by their other efforts, and it’s showing through in all of their products. Now that Apple has released the Leopard OS and the iPhone, I hope the employees who’ve had one horrible stressful Steve inspired Macintosh-esque 2007 get a very cool t-shirt, have a long drunk New Years Eve, and in 2008 are given the time to stop and focus squarely on the Last Mile again.

Something that is hidden from most coverage of the Apple announcements today is that .Mac, beyond getting bumped to 10 GIGs of storage, now has server side email filtering for your .Mac account.

This is an answered prayer to those who are annoyed that their iPhone doesn’t do spam filtering unless their Mac is on and also checking mail. This should allow you to have your Mac off and only check mail from your .Mac account without all those Viagra adds popping up in your inbox.

Apple also posted a link to an information page entitled “.Mac: Keep Junk folder contents consistent by using the same Junk mail settings on each Mac used with .Mac mail” discussing how you should change your settings on your Apple Mail application to ensure that both your server side and local junk mail stay in sync.

.Mac mail is almost getting to be GMail useful now.

I am a stickler for web standards, and make a lot of effort to ensure this website stays XHTML 1.1 compliant, along with the JavaScript and other code that runs in it (often having to modify plug-in’s code out of recognition). However, until recently I conceded that because Microsoft decided in Internet Explorer 7 not to include an XML parser like every other modern web browser manages to do, I could not serve content as application/xhtml+xml as you should, but instead as text/html.

Being a mentally ill obsessive compulsive designer, it bothered me. Then I stumbled upon this plug-in for Wordpress from Joost de Valk that does the simple PHP code to see if the HTTP_ACCEPT of the browser can take application/xhtml+xml and serves it as such if it can. Otherwise, those with less-than-great browsers get text/html.

Imagine my surprise when, after having made this change and verified that it works on IE7 / Firefox / Safari that when I tried to load my website on Safari Mobile it would load the page but before showing any content promptly crash.

Keep in mind that Apple implies that if your site works on Safari 3.x Beta on either Mac or PC, it will work on SafariMobile as it shares much of the same code base before it forked in October. I am not sure if it’s something about the XHTML 1.1 that I’m using, or any modified Prototype.js or other JavaScript that I’m running while using XHTML 1.1 (using application/xhtml+xml changes how JavaScript code works when interacting with a DOM). However, I’ll repeat that it all parses and renders correctly in xhtml+xml on Safari 3.x and even Safari 2.x.

The bigger problem is that the browser in the iPhone obviously states that it can, in fact, take application/xhtml+xml as a content_type or else the code in the plug-in above would default to text/html. So, if you want your web application to work on the iPhone, best to keep it text/html for now.