Category: HTML

Smart Clients Versus Web Clients – What’s the Answer?

cvjepsenLeave a comment

For a long period of time every ISV jumped on the browser bandwagon, meaning creating web versions of their existing fat clients. This transition was driven by Google’s everything web mantra, together with the emerging cloud technologies. The transition was moreover an answer to requirements from CIOs all over the world for an easier deployment when upgrading software internally. With a browser based app, you only need to update the server – and all of your users would automatically get upgraded. This approach would allow companies to purchase inexpensive computer equipment as the hardware literally only need to be capable of running a browser. Which is the whole idea being Google’s ChromeOS.

Initially moving away from fat clients to browser based app was painful. Mostly due to the limited capabilities of the web browsers, causing limitations to how advanced one could make the browser based apps. Over time the browser and standards behind the web (HTML, CSS and JS) became more and more sophisticated, allowing developers to create more rich web applications – Rich Internet Applications. With RIA developers could offer near desktop like experiences to their users, everything still within the framework of the browser. The browser became a platform for application execution, instead of a render of web information – which was the original purpose.

Alongside the continuously enhancement of web technologies to provide richer user experiences, or experiences close to what could be offered with native developed and deployed applications, technologies like MS NoTouch and Java WebStart emerged. These technologies solved the deployment headaches organizations had with traditional fat clients, by automatically downloading the app to your computer and execute it. If there was an update, you simply updated the server version – and the clients would automatically download the updated version. No need for IT personnel to physical be present to install software on individual computers. This was essentially the birth of the smart client. A desktop client that gave you all the benefits, like tight integration with the underlying OS and other components on the computer, offering features like drag’n drop.

An advantage of web clients is that you can access your data from any device, as the data or documents doesn’t reside locally. However, on the flip side that means that you can’t access your data UNLESS your connected to the internet. Smart clients allow you to store data locally, BUT then you can’t access your data unless you’re on the same device. With HTML5 and recent new specifications this is somewhat resolved. In HTML5 there’s the notion of local storage, the ability to store data locally in your browsers cache. Either as sessions data or actually local data. The latter allows you to store data locally and have that data available even if you’re disconnected. Drawback is that if users clears their cache all local data is gone. There’s another specification (http://dev.w3.org/html5/webdatabase/) defining an API for accessing a local SQL database.

Overall the HTML5 specification itself and the adjunct specification all serves the same purpose, trying to narrow the gap between web apps and clients executed on the device. Both in terms of User Experience and capabilities in terms of storing data locally. One of the key features of a traditional as well as smart client.

At WWDC 2011 Apple showed the way for allowing Smart Clients to seamlessly store any data in the cloud, so that you’ll be able to get to your data regardless of what device you’re using. They took NoTouch and WebStart further. With Apple’s new technologies you can develop applications that’s downloadable from the Mac or iOS AppStores, and they’ll get updated automatically when new versions are made available – same as NoTouch and WebStart. These applications can use the iCloud for storing data in the cloud so that the same data will be available on other devices, allowing you to seamlessly move between different devices, like a Mac, iPad, iPhone or iPod. The users don’t need to think about where their data is, “it just works” as Steve Jobs put it.

Will others adopt this approach? Personally, I wouldn’t be surprised if Microsoft does. That’ll allow them to keep their products as is, and at the same time get users to use Azure. They could of course go all web, as they partly have done with offering Office as a web offering, but honestly, Microsoft isn’t a web company. Just like Apple aren’t a web company. Only web company in this game is Google.

So looking at the recent development among web technologies, and recent announcements from Apple you’re moving to a point where the gap between web clients and smart clients are narrowing. This being said, then the smart clients with the close integration with the underlying OS still offers superior User Experience than a browser hosted application.

So what will the application of the future be? Browser based application or a Smart Client. Where the latter uses all the services available on the internet, and at the same time offers native capabilities. Personally I believe that we’ll see more native applications in the Apple world, as there’s a lot of developers that previous worked on iOS using Apple’s tools – that now can start thinking about building integrated applications across multiple devices, without the maintenance nightmare of having to update computers by manually installing the updated. If Microsoft follows suit and start adopting the Apple approach in Windows 8 and later on tablets – my take is that the road it paved towards more Smart Clients and less browser based clients.

Is HTML5/JS really the Silver Bullet for Mobile Applications?

cvjepsenLeave a comment

HTML5 and JavaScript seems to be getting a lot of attention and being pushed as the next great set of technologies for write-once-deploy-many for mobile devices. If that crystallizes it would be great – wouldn’t it – like a nirvana for software developers. Imagine only have to develop once, and by sheer miracle you support n number of platforms. Brings back memories from similar pitches and discussions when Java was invented.

I’m not concerned with HTML5/JS as technologies, but more the perception that those specific technologies (could be any technology) are THE silver bullet that’ll allow you build build once-and-deploy-many without additional work. Similar pitch and hype that surrounded Java initially – and that didn’t really crystalize. Even if HTML5 becomes the predomination approach for rendering UI on a variety of devices, none of the devices will share equal characteristics, literally meaning that there’ll still be work – and sometimes significant work – to do for each specific device you want to render against, e.g. there’s a huge difference between the UX/UI on an iPad and an iPhone, that won’t be automatically resolved by using HTML5 – nor will it be automatically resolved using native tooling. A very good example of this, was that initially everybody believed that users would accept viewing web pages designed for desktop browsers on their mobile devices. It quickly turned out, that companies not offering a special tailored mobile version of their web lost viewers, and HTML got extended with features to determine whether or not you were on a mobile browser, and would then redirect you to a special mobile web page.

Take the above into consideration when vendors argues that you can support a number of different devices with same code base. It’s partly a true statement, as long as the screen doesn’t change too much. As soon as you change the screen you’re HTML based application will either sit nailed in the top-left corner or scale all elements to fit the new physical screen dimensions. Either way, there’s a huge risk that your app ends up looking skewed. To avoid that you’ll have to implement logic to accommodate that. In the event that you aren’t too concerned with the look, then this is a non-issue. But you may lose users or people will rate your app as unattractive.

There’s also the challenge of using the native capabilities of the devices. Vendors of platforms offers different levels of API that maps to the underlying OS, and recently they’re starting to push the notion of plugins – like PhoneGap. These plugins allow you to develop native code that you can call from JavaScript, which is nice, but it does raise the question why this is needed. My take is that it’s needed simply because the API offered aren’t always extensive enough to support all possible permutations of usage of the underlying OS. But seriously, if you have to do that – what’s the whole point using HTML5/JS then, as you end up having plugin code for each device that you need to maintain.

Almost every vendor of cross-platform tooling based on HTML5/JS web pages states that the key driver for using these tools are the ability to repurpose skill sets that your web developers already got – HTML and JS. Instead of having to learn new technologies. Simply because that’s cheaper than having to hire iOS developers, which are hard to get by and notoriously expensive. The funny thing is that on Android and RIM the language is Java, something that most HTML/JS developers knows as well – or C# for WP7, which all .NET developers knows (Visual Basic will be added).

On the native side, an idea could be to encapsulate anything that concerns business logic in a device agnostic language like JavaScript or Lua scripting, embed that in the native application and only focus on UI/UX when writing native code. It’ll give you total access to the underlying OS, all it’s capabilities and ability to build whatever you want without the additional abstraction of HTML5/JS and wrappers. The abstracted code can be maintained centrally and extended without impacting the native code, e.g. if there’s changes to validation rules you can update the library without having to change one single line of code in the native applications.

Long story short, my reluctance isn’t about the technologies, but about the perception that we all of a sudden can support all possible permutation of devices and OSes just by using HTML5/JS. Which won’t be the case.

Native Tooling versus Non-native Tooling

cvjepsenLeave a comment

Recently I’ve been following some interesting discussions on the subject whether to develop native apps for mobile or using cross platform technologies. Let me elaborate what I mean by native apps. A native app is an app that is built using the tooling provided by the vendor. So for iOS devices that would be Objective-C and cocoa touch, for Android and RIM that would be Java.

Mostly the discussions seems to be concentrating on two underlying subjects: 1) how to utilize existing skills and framework knowledge and 2) how to support multiple mobile platforms with one code base. You can argue that these two subjects are intertwined and cross platform solutions tries to solve both areas simultaneously. Which is somewhat correct; however, #2 actually got another level as well, as there’s a whole range of MEAP vendors trying to push “code free” solutions, requiring none or limited coding.

Let’s look at #1 and what seems to be the key driver behind wanting to use existing tooling or similar tooling and technologies. Well, should be obvious, mostly seems to stem from a wish either to save money or reuse skills. The former is primarily driven by organizations whereas the latter is developers wanting to develop apps, but don’t want to go through the hassle of learning and new set of tools and technologies (see my blog on this, choosing the right tools). Also, there’s the latest SDK problem. If you’re using native you’ll always have the latest and greatest SDKs at your disposal; whereas if your going with non-native you’ll have to wait until the vendor gets his version ready. The time the vendor uses to do that, your competitors that uses native SDKs exploit new features and leaves you behind.

#2 is a repeat of previous attempts to find a silver bullet for supporting a number of platforms, build-once-deploy-many. So far nobody have succeeded in this field, at least not that I’m aware of. Back in the early nineties a substantial number of companies tried to build CASE tooling in an attempt to abstract the development away from code and hence be able to design once deploy many. Nobody uses CASE tools today. There was also a number of attempt trying to build cross platforms for Wintel and Macintosh. None of these are around. Personally I wouldn’t hold my breath or bet my business on the MEAP vendors, they’ll be gone as soon as the mobile OS market starts congregating towards 2 maybe 3 platforms.

Another thing about MEAP is that in trying to target many platforms they end up having to go with the least common denominator. And frameworks typically gives you 80% of what you need, the last 20% you can’t do and have to go into native code anyway. And guess what, it’s the last 20% of finalizing the project that takes 80% of the time. So no real gain (only a lot of pain).

Another important and often forgotten subject is the user base of certain technologies. The more users using specific technologies the easier it is to get help, find solutions and sample code. With lesser user adoption you’ll be more left on your own and can only rely on the vendor, who will most likely charge you for anything and everything possible.

If you haven’t already guessed then my stand is native everything, you get better apps, they look cooler, they feel like native apps, you don’t risk having to wait for a vendor to implement latest and greatest features, you don’t risk a vendor suddenly going out of business, you got huge user communities that can help and you won’t end up being charged unreasonable amounts of money for simple questions.