iPad Web Applications

So you might have heard about this... This Saturday, April 3, there's a new computer coming out from Apple. You might have heard about it. Anyways, lots of iPhone developers have been scrambling to port their iPhone apps or write new iPad apps. A lot of folks have been predicting that developers would start to shun Apple after all of the controversies surrounding iPhone app submissions and the "walled garden" approach that Apple has taken. On the other hand, Microsoft has decided that a controversial walled gardens are once again the way to go, and is diligently copying Apple. Well if the iPad is any indicator, developers continue to agree with Apple and Microsoft. There is a lot of interest in developing native applications for the iPad.

Still, if you're like me and a big part of your job is to figure out how to build web applications for all kinds of devices, you have probably been spending a lot of time trying to figure out what to do about the iPad. On one hand, it's a big enough device that most websites will look just fine on it.

I think you must agree that the above looks a heck of a lot better than a "mobile optimized" site like this:

This seems great at first -- no work! Just make sure that if you are using any browser sniffing/redirecting code that it does not redirect for the iPad. However, there are some disadvantages to this. First, there are some issues with 'normal' sites that will not translate well to the iPad. There is the obvious thing with Flash... There are more subtle things like, "hovers", i.e. mouse-overs. That is when you toss up a UI layer when a user hovers their mouse over a link, or an image, or whatever. These are pretty popular, and they are not going to work on the iPad. Apple has quite figured out how to detect a finger hover... There are other events that are different on the iPad as well. There is also the question of how to best use the real-estate on the device, and the related question of dealing with landscape mode.

I think a lot of sites will look great in landscape mode, but that doesn't mean that they couldn't look better. It might be more optimal to go to a multi-column layout. That could let a site place useful content "above the fold", i.e. visible so the user does not have to scroll to get to it.

There's also the possibility of "embracing the native" on the web. There are a lot of iPhone-optimized websites that do a good job of making their website look and feel like a native iPhone application. Joe Hewitt's excellent iUi JS/CSS framework is an easy way to do this. The iPad has some of its own metaphors not found in the iPhone. Take a look at this native iPad app:


Notice all of those columns? We've kind of touched on that already. Did you notice the pop-over menus? These are likely to be ubiquitous on the iPad. Here is a picture of them from one of Apple's iPad apps, Numbers:

Obviously there is nothing in HTML-land that is quite like that. However, it is certainly possible to craft something similar. In a way, it's kind of like the mouse-over menus that are popular on the web, only the interaction model is slightly different and the UI is definitely more rich than the average mouse-over menu.

So what to do? Just stick with your "normal" site? Develop an iPad optimized site? Tweak your iPhone-optimized site to suck less on the iPad? Tweak your normal site to suck less on the iPad?

Programming and fallacies

Today I read a blog post by @joestump where he attempted to refute claims that Digg had been "doing it wrong" when they could not scale their database and went with a NoSQL attack instead. I'm not going to get into that flame war. I will say that folks at Digg should have expected exactly this kind of scrutiny when they decided to start bragging about their technology decisions. If a company has a technology blog, that is all they are trying to do -- brag. Anyways, back to the blog post... I was immediately disappointed to see that it was riddled with logical fallacies. I see logical fallacies all the time, and sometimes I forget that many folks are actually not very familiar with them. In particular, I would say that programmers are not very familiar with the "formal" concept, despite the fact that programmers tend to have very strong logical reasoning. Here is my attempt to do something about that.

First off, I am not going to answer what is a logical fallacy. You can follow that link, or find many other descriptions and enumerations of fallacies. Instead I want to talk about why programmers may not be aware of fallacies, and why it is important for them to learn about them. I think the reason that programmers may not know much about fallacies is that they are generally taught in classes on writing, public speaking, or debating. In other words, even though these are concepts tied to logical reasoning, including induction and deduction, they are not included in classes on mathematical logic. You cannot generally express a fallacy using symbols and computational expressions. This might lead some to believe that the fallacies are subjective, but this is not really true.

So why are fallacies important if they are not easily expressed mathematically, and thus difficult to represent programmatically? I suppose that if all you do is program on your own, then perhaps they are not relevant to you. If instead you work on a team with other programmers (or non-programmers for that matter,) then you will have ideas that are argued/debated. In this case, you need to understand fallacies -- so that you can express your arguments without committing a fallacy and so that you can recognize when people arguing against you are committing fallacies.

If you have an argument, and you find yourself committing a fallacy, then of course you will want to "fix" your argument to remove the error. This will inevitably draw out the assumptions in your argument, and strip out that which is not essential and true. Sometimes this will leave you with nothing, and you will be forced to question your own argument. Perhaps it was false or more likely mostly based on subjective statements, not fact. That can be a bummer, but wouldn't you rather realize that you are wrong than have somebody else point it out? Or worse, have nobody point it out...

You need to recognize when others are committing fallacies. At the very least you need to strike this from your own mental record of their argument. Does their argument make sense without the fallacy, or is it essential? Of course if you start noticing these kind of fallacies, then you may be tempted to point them out and use that to assert that their argument is false and thus your argument must be right. Oops, you just poisoned the well and committed a false dilemma.

Once you start noticing fallacies, you might notice that people commit them a lot. Sometimes this may seem to be true irrespective of the perceived intelligence of the committers. It is easy to make these mistakes when you are unaware of them. They are also much more common when people are "thinking on their feet." In fact, I had a professor who once joked that those who were good at thinking on their feet, were simply good at synthesizing fallacies. I'm not sure if that is a fair generalization, but you get the point. I think people are also much more likely to make these kind of errors when emotion has entered into the argument. I think that was the most likely case in the blog post that inspired this post.

MIXation Sensation

This past week was Microsoft's MIX conference. I almost went to it, and I would have gone if it was not the same week as my oldest son's birthday. You gotta have priorities. Anyways, the reason I almost went was not because I have suddenly embraced ASP.NET development (even though I must admit my admiration for Scott Gu). No, my interest is all browser related and MIX was browser heavy this year.

On the browser front, the big news was the early preview of IE9. For web enthusiasts, it's fun to wax poetic about the mind blowing speed of V8 or the brilliance of TraceMonkey, but these technologies will always be secondary at best. If you are a web developer the most important browsers are the ones from Microsoft, because they dominate the market. They form the baseline that you develop against. If you want to do something that these browser do not support, you have got to get creative or be willing to live with your work simply being a toy. Simply put, IE9 news is more important than all of the Firefox, Safari, Chrome, and Opera news combined.

Luckily, Microsoft did not disappoint with IE9. It is obviously a far from finished product, and Microsoft was a little too dodgy on sharing its roadmap for my taste, but I can empathize with their position. Still they showed a browser with significant speed improvements and with support for a lot of standards based, visual eye candy. I'm talking about a lot of CSS3 features and most surprisingly, an amazing SVG implementation. They whipped out some classic Microsoft tricks, i.e. using their intimate relationship with their operating system to tap into GPU acceleration. You might think it's not a fair trick for them to do, but who cares? The boys at Mozilla, Apple, and Google have to accept this challenge, even if it will be super painful to pull of across platforms -- and Linux will surely suffer here once again.

I was a little disappointed in some of the other JavaScript features. In particular, I was really hoping that Web Workers would be included with IE9, and I was cautiously optimistic that geolocation would also be included. Neither is included in the IE9 preview that Microsoft made available to developers.

Of course that definitely does not mean that these features are out of IE9. I think there is a lot more to come. Microsoft has done some amazing work to give IE9 a lot of graphics features, but they have left out Canvas. Further intense graphics programming would benefit from the multi-threaded programming model supplied by Web Workers. So it would make a lot of sense for both of these to be added. I'm even optimistic that Microsoft will implement these standards directly, and not offer some proprietary alternative.

All of this makes you wonder about IE9 as a compelling graphics/gaming platform. I think that some serious tooling will be needed to make this viable. That's an area that Microsoft excels at. However, would this not put Microsoft in conflict with their own efforts around Silverlight? It's like the HTML 5 vs. Flash war could be played out in miniature within Microsoft's walls, only it would be IE9 vs. Silveright. Speaking of Silverlight...

The other big news, from my perspective at least, that came out of MIX was a lot more information about the Windows Phone platform. As a mobile developer, I have very mixed feelings about Windows Phone. On one hand, I really like the idea of using Silverlight as the application platform. This is a mature application platform, with fantastic tooling. You get to use a beautiful programming language -- C# (oh an maybe other .NET langs, like F#?) that has a decent runtime that includes garbage collection. However, Microsoft looks like they are copying Apple's approach. A lot of the restrictions being placed on non-Microsoft applications are very similar to the restrictions placed on iPhone applications.

Back to the browsers... Microsoft shipped a preview of tools for building Windows Phone applications. Again, major props to Microsoft for getting this software ready out at MIX, even if it is a little rough in places. I don't like companies using end users as a substitute for QA, but this is different. Getting tools into the hands of developers is critical. In this case, the tools include a Windows Phone emulator, which includes *drumroll please* the Windows Phone browser! As a mobile developer, this is the most important thing that can be included. I'll have to support your browser before I have to support your application platform.

However, the Windows Phone browser is not very promising. It seems to be based on IE7. It does not seem to support many HTML 5 features at all. No geolocation. No local storage. No application cache. No web workers.

Maybe some of these things will be added by this fall, but I'm not as optimistic about this. Even the documentation that is included emphasizes building web applications that are designed to work on legacy browsers. They seem to be saying, don't go looking for coolness in the browser!

Testing Geolocation for Mobile Web Apps

Using geolocation in a web application is really cool. The JavaScript API is quite simple. Testing it, can be a different story. Here are some useful tips:

If you only need to get the user's location once, testing is not too bad at all. First, you can actually use Firefox 3.5+. However, make sure that you are using wi-fi, or otherwise you will never get a location. Your app will just seem to hang. Anyways, being able to use Firefox for testing is great because it is a full desktop browser with awesome developers tools like Firebug. Often you will have some pretty complex JavaScript in a web application that uses geolocation, so being able to debug with Firefox/Firebug is invaluable.

Of course you will also want to test on mobile browsers. You can definitely use the iPhone simulator that is part of the iPhone SDK. Geolocation works great on this, but it gives you a bogus location -- the location of Apple's HQ in Cupertino, CA. If you actually live near Cupertino, this can be really misleading. Anyways, it will only give you this location, never anything else. So it is somewhat limited.

Testing on an Android emulator is another possibility. However, in my experience, it is currently broken. On an Android device, when a web page wants your location, the browser brings up a window to prompt you for permission. On the emulator's browser, I never see this permission window and the app just hangs and never returns a location. That's a bummer, since the Android SDK makes it possible to send mock GPS coordinates to an Android emulator. It would be great if web developers could take advantage of this.

Testing on an actual devices is of course a possibility. Your web application needs to be reachable by the device. This could mean using wi-fi on your device, so you are in the same intranet as your development sever, or it could mean deploying your app somewhere public. I like using the Google App Engine for the latter, and then test on the assortment of devices that I have laying around.

If you need to test location updates, i.e. when the user moves you want your web application to know about it and respond in some way, then things get trickier. The iPhone simulator is out of the question. An Android emulator still suffers from the same problems. So now you are down to devices. There is no way to send mock GPS to an iPhone, so to test on an iPhone, you need to actually change your physical location. Coding and driving FTW!

However, it should be possible to test on an Android device. The Android SDK theoretically allows you to send mock GPS to a real device. The command that should work is "adb -s XXX shell geo fix AAA BBB" where XXX is the serial number of your device (get it by doing "adb devices"), and AAA/BBB are the fake latitude/longitude. Sounds good, right? I tried this on my Nexus One, and got a big fat permission denied. Turns out you need to be root to do this on a real device. Ok, so I rooted my Nexus One. Then I tried it. Result? "gps: not found." Suddenly the gps command was not recognized. So ... coding and driving FTW!