stanlemon

So after writing my diddy on Appification and reacting to RIM's CEO's remarks at the Web 2.0 Summit I saw come across Twitter a link to an exchange between John Resig (of jQuery fame) and Thomas Zuchs. The argument is over Zepto which attempts to be a very platform-specific replacement for jQuery. Zepto is specifically focussed on Webkit mobile, ie. iPhone, iPod Touch and iPad though it seems Android gets a little love too.

The reason this is relevant to my Appification diddy is because I essentially argued that developing specifically for iOS was a good thing. I still believe that, but I think there is an important distinction that needs to be made. If you are developing a web site that delivers content you have a responsibility to make that as portable as possible. If you are developing a web application, I believe, you get a little more license to get platform specific and even dare I say neglect other platforms.

Content needs to be accessible, and so a progressively degrading user experience becomes important. If I am posting material I want disseminated everyone from Kindle users to iPhone users to Windows users need to be able to get at that content. As an app developer though, I may be developing some exclusively to run in an environment because that environment caters the functionality I am trying to deliver.

Consider the changes in iOS 4.2 that bring the Accelerometer to Webkit. To the best of my knowledge there is no other web platform that adds this functionality, so if you want to develop a cool web app with roll, pitch and yaw you're out of luck if you want to being universally run. If you're developing a web app experience for Webkit you're in luck though, because iOS can do that!

I think this is an important and helpful distinction to make, and I want to be clear that I am absolutely a proponent of cross-platform compatibility when it comes to content. If you don't believe me, check out the Higher Things website in Internet Exploder 6!

TechCrunch recently posted an article discussing RIM CEO Jim Balsille's comments at the Web 2.0 Summit. If you google around you can find some details from Balsille's remarks, specifically where he refers to "Appficiation" and where he says that "you don't need an app for the web."

Balsille is referring to the need to take a website and transform it into an app, like for example the Wall Street Journal or the FOX News apps, or even for that matter the ESPN, Sportacular and SportTap apps. You can go even further, and include the Weather Channel, Weather Bug, any of the Twitter apps, Facebook, Google Reader apps, Amazon.com, and the list goes on and on.

Balsille seems to be saying that the concept of transforming service-driven web sites into apps will die over time and people will return to the web. I'm skeptical of his certainty but I think he makes a valid point that needs to be discussed in web development circles.

First though, let's clarify something. The Appification of the web is not Apple's invention. When the iPhone first came out Apple's appeal was to develop mobile web based apps for users. They pushed HTML5 technology and worked hard to sup-up Safari to make it a truly powerful web browser. Appification has come primarily from third parties who have translated their own services into apps completely independent of Apple's beckoning.

Now what's wrong with Appification? First, Apple. Every Appified website has to go through Apple's ringer. For some sites this has not proved to be a big problem. For other though, it's completely halted development and release. More importantly, cross platform development. If every site builds an app they're going to find themselves developing individual apps for every platform available. What's worse is the end user will ultimately suffer. I'm still waiting for some apps to roll out an iPad version!

Now I'm not totally opposed to Appifying. In many ways I think it's a great idea. But we need to remember that the capabilities of HTML5 combined with Apple's windowless mode for Safari could be a better option.

Consider the fact that Safari supports HTML5's local storage and caching mechanisms, as well location based services and you've got access to some powerful tools. Combine this with OpenGL rendering of gradients, shadows and other UI elements and Safari web development is really a piece of cake. Plus, Safari's javascript engine is really fast. In principal the difference between fetching a news article from an App or from a web browser is really non-existent. Both are ultimately making requests to a news service website to grab that data and then display it.

So where do things get held up? The answer is in the initial load of a website. Most mobile websites re-render the bulk of the UI and navigation on each page requests. They also load way more then is necessary hiding a bunch of things with CSS. This is easier then developing a stand alone mobile website, but the disadvantage is to the end user who has to wait for all that stuff to load. Furthermore, very few websites take advantage of caching the interface they develop in the web browser. If more websites did this load times would be dramatically reduced and web apps could focus on fetching data to display in an already cached interface.

I think part of the reason this has not been pursued with greater intensity is lack of knowledge. There just aren't a lot of great working examples of web apps that really draw on the power of Mobile Safari. This is as much Apple's fault as it is the HTML5 community which hasn't stepped up to the plate in this area. Better examples to aid in development would go a long way for people embarking down this road. Another reason is because its taboo to develop browser-specific sites. The mantra is that a mobile site should be generic enough to run on every mobile platform and gracefully degrading is an important feature. The reality is, gracefully degrading can produce more expensive coding and Mobile Safari is a heck of a lot more powerful then the Kindle's onboard web browser and we just shouldn't compromise a greater user experience on Mobile Safari for an eReader or Sprint's latest and greatest antiquated phone.

Yes, I'm suggesting we replace Appification with browser-specific development. This may seem like the same problem, but reality check: Android and iOS both use Webkit to make their web magic. For that matter, PalmOS is webkit based and the latest from RIM on the Blackberry platform is also Webkit based. That means that a well-written standardized web app focussed on Webkit and it's mobile technologies should have a pretty seamless existence across modern mobile phones.

Last summer for Higher Things I developed a couple of web apps for the iPad and iPhone. One of our staffers is an Android-lover and decided to give one of our iPhone apps a spin on his HTC phone. To his surprise (not mine) the app ran just fine. In fact, the user experience between his phone and mine was almost identical (my fonts were better). Had I tried testing the app on Android before we used it? No. The underlying technologies were close enough that the web app just worked.

As long as all of the major phone providers continue to use Webkit to power their browsers we can develop web apps that take advantage of modern technologies without worry about a debacle of cross-system development. I don't see the landscape changing in terms of Webkits usage. The reality is that Chrome is Webkit based, the Chrome OS is web based and with as much of an investment as Google has made into using Webkit they would have to scrap a huge chunk of their infrastructure to move away from it. Apple as the godfather of Webkit has also made huge investments in the technology and would need to make a dramatic side step in order to get away from it. It would make for some seriously flawed business decisions, and those just aren't going to happen.

So back to Appification. Have we gone too far? Probably. The truth is that Facebook stinks on the iPad, the approach of the Wall Street Journal app leaves much to be desired and the update time for the Fox News app is way too slow. Balsille is correct, we need to focus on the web and not apps for the web. This means developers, like myself need to step up the plate and focus on true web development for mobile versions of Webkit. We can supplement this with apps when needed, but we can't neglect the bread and butter of the internet on the mobile platform.

I have released updates for jGrowl and jQuery Autosave. The jGrowl updates have been on BitBucket for awhile and represent minor bug fixes and improvements. The jQuery Autosave update is a huge overhaul and rewrite to improve performance. Rather than interval the form over and over for a dirty state, the form intervals only for autosave purposes. This reduces total browser memory usage and performance dramatically and makes the plugin more usable. I am also now hosting jQuery Autosave work on BitBucket and I've thrown in a working example/demo of the plugin into the release bundle. You can find the update on the project page, over at BitBucket and at the jQuery Plugin page.

I ordered a DODOCase back in July right before they increased their prices. I had seen some photos on their website and had heard a lot of great reviews. I had tried out the Apple de-facto case for the iPad and was sorely disappointed, so I passed it on to a colleague. I had moved onto a Hard Candy Bubble Sleeve, which I used throughout the summer while I traveled. I really like that case, and it was perfect when I wasn't tossing my iPad into another bag, but inside of my laptop bag or elsewhere it had a larger profile then was really necessary and thus consumed too much space.

There were some other disadvantages to the Hard Candy case that kept me searching, one of which was that it didn't really lend itself to being used in the case. The Hard Candy case was great for moving from point A to point B, but once I got to where I was going the iPad seemed to spend most of it's time out of the case. I also struggled with the casual look of the case. Granted, it fits my personality... I am a stay-at-home dad/software engineer who wears khaki shorts and Teva Sandals until it gets cold enough to upgrade to Jeans and Teva Shoes. At any given time I'm wearing one of seventeen different polyester collared short sleeve shirts that sports eight different patterns in an assortment of earth-tone colors. Casual, that's me… But there are times when I want to be taken seriously and whipping the iPad out in a serious case makes a serious statement. Take for instance the 8am coffee at Starbucks, there amidst my peers I want to pull out my iPad and look like I am ready to do business.

So back to the DODOCase. It's a classy looking case, modeled after a Moleskine notebook. You know what a Moleskine notebook looks like, the leather covers and binding with a hard wood trim around the edges to protect the paper. Serious writers sport these bad boys to protect their pride and joy and they look pretty slick too. The beauty of the DODOCase is a glorious marriage of the old-world of books and the new-world of personal tablets. It's really spectacular to look at, and it meets my criteria of a small form factor, usable in the case and it has a professional look. So I ordered one. When I ordered my case there was a serious backlog at the nest and it didn't arrive until a month and a half later. When it came I noticed a serious problem, the wood edge were bowed and prevented my iPad from resting inside of the case flat. In my opinion, this made the product virtually useless. I e-mailed DODOCase and they explained to me how bamboo can warp and has a natural desire to go anywhere but straight, and so they suggested using a process to gently crack the wood to make it straight. That was terrifying! So I asked for a video. The support gurus over at DODOCase thought this was a great idea, but they weren't going to do it so I was left to fly solo. I gave it a shot and it well, sort of worked. I used my DODOCase on and off from that point not entirely satisfied with it, but also realizing I had just been seriously dissed by the support gurus and was not simply out of luck and out $60.00.

Fast forward three months and pictures of DODOCase are emerging on the web and people are raving about how great they are. As I see these pictures I began to realize my case had problems beyond warped trim. The wood itself had never been put on correctly, and it actually hung over the bottom of the cover. Finally I decided to e-mail the nest again, this time with pictures and an explanation that I was fairly certain I had a defective product.

I have to admit that I had low expectations. I wasn't thrilled with my initial experience with DODOCase support and I really didn't expect them to improve the experience. I was wrong. I got a reply back in very short order saying that my case didn't hold up to the high standards of DODO and that they would replace it immediately. They asked for my order number and address and next thing I know a new DODOCase was on its way.

The new case arrived yesterday in the mail, and boy what a difference three months make! All of the materials in the new case look superior. The wood was flat and smooth and mounted correctly. The leather was noticeably softer. The corner rubber pieces were actually attached. The printing on the inside jacket was so much more crisp then the previous case. The entire device holds more snuggly inside of the case as well. This was a far superior product. I'm not honestly sure if I just got the ugly duckling from the nest or if the construction quality has just improved that dramatically, but needless to say I am very please with my DODOCase and the support I received from the nest.

If you're looking for a sharp looking classy case for your iPad, the DODOCase is a great fit. Despite my initially subpar product I really recommend this case, the new one is a testament to a great hand-crafted product.

For the time being on my blog listing I've got just Facebook's "like" button alongside the Twitter tweet button. I was hoping to actually embed the comments widget below each article but I haven't been able to figure out if that's possible. The "like" button allows you to set a URL for the widget, but as best I can tell the comments plugin does not. Maybe I'm missing something, or it's possible this is just a short-sighted implementation... If anyone knows how to get this working I'd sure love to know!

Dealing with comments on blogs has always been a nuisance to me. If you don't layer in security you wind up overwhelmed with spam, but if you do layer in security you find that no one posts comments. There are also issues of maintaining conversations, you need to provide some way of notifying users when followups occur. It's a real conundrum and even the best attempts from great blogging platforms like WordPress leave something to be desired. In my experience the best way to leverage comments on content is to use validated accounts, but who really wants to do that? You have to maintain the account system, provide lost password functionality and the whole thing hinges on validating e-mail addresses. It's a pain.

Today I added support to my site for Facebook comments. I really believe this is the best option for user feedback on websites. The bottom line is that with over 500 million users you can count on the majority of your web traffic having a Facebook account. Facebook has done a fairly decent job preventing spam and so with their comment integration you prevent having to maintain a larger user account system while also providing a level of security while not complicating the process. It's really a great idea. Even better is the fact that comments integrated into Facebook provide multiple ways to keep people updated in the conversation and allow for conversations to continue to build.

Adding support is a piece of cake too. You head over to the Facebook Developers page, sign up and the code is pretty much a drop-in and go. With the comments widget you also get the "like" widget, which is a great way to get a nod from visitors without requiring them to think of something to actually say.

Additionally I added Twitter's tweet widget to provide some integration on that front. Admittedly, this does not really help the comment dilemma, but it's cool nonetheless. Expect these things to pop up over on HT soon too.

CDN's can be a handy tool for web developers. However, not using a CDN should not be a penalty when testing your site against Google Page Speed and Yahoo's YSlow. While testing Higher Things' website the other day my overall scores kept getting penalized because I don't use a CDN anywhere.

Now, to be clear, I am not opposed to using a CDN. In the case of Higher Things' though, I have code that manages my JavaScript and ultimately munges a compressed form together and serves a single file of JavaScript per page. Included in this single file is jQuery (an oft-served library over a CDN), some jQuery plugins and my own code specific to the site. Delivering it this way minimizes HTTP requests (something I got all the points for), but it also means I can't use a CDN.

The question arises then, if my score would be better if I broke out the jQuery core and loaded that by CDN. Is doubling the number of HTTP requests to load JavaScript a better choice then failing the CDN requirement?

My opinion is that not using a CDN should not penalize my score. Maybe it would be better to have extra credit if you use one, I don't know. I realize there are limitations to the investigating these tools can do, but the bottom line is I'm irritated because I've got a pretty good score, minus that pesky requirement...