In the last decade, we saw the rapidly expanding world of Web 2.0. With it came the advent of Web apps – Web pages designed with more fun, colorful interfaces, integration with social networks and sharing sites, and most notably, AJAX. This gives the slow and stale Web page a much needed boost in usability and, more importantly, speed.
Balancing app. Mobile Web versus mobile app? And what are the differences between a Web page, a Web app and an application?
AJAX makes it possible to communicate with a server without leaving the page – something that has always been the case in desktop applications. Users no longer need to wait dreaded seconds for the page to redraw – even if 95 percent of the content on that page stayed the same.
On June 29 2007, the game was changed once again with the introduction of the iPhone. It ushered in the usable touchscreen as an input device and turned the user interface world on its head. Many Web developers rushed to update their sites and Web apps to mimic the UI put forth by iOS. Aside from the look, the sites now needed to work with the touchscreen. This presented certain challenges when it came to sites that wanted to look more like native applications.
We are now on the cusp of the next leap. The Web has turned into an operating system. Google is capitalizing on this with their Chrome OS. Countless other companies are selling everything in “the Cloud.” I believe this drive is the natural progression towards a decentralized computing platform. We are no longer tied to our computers for our information. We can check our Gmail, work on our Dropbox-stored documents and share pictures on Flickr from any computer or smartphone in the world. This new operating system now needs proper applications.
Even though there is tremendous progress in this area, many people and businesses still fail to realize what makes an application different from a Web app and different from a Web page. I have heard many clients from many different industries ask for a new smartphone or tablet app, but when it comes time to design it, they come back with something like this:
“Make it look like this current CRM we are now using. Our users don’t want to learn a new thing – it’ll be confusing – they’re already used to what we have.”
I find this to be both ignorant of the technology and offensive towards their user-base. It essentially says, “My users are morons who can’t be trusted with learning something new and I believe that this fancy new iPad offers nothing beyond a way for our sales force to look cool.”
Let’s tackle the first point first:
“Make it look like my current…” (Fill in the blank: CRM, Web-based tool, expense report, database, etc.)
Most of these systems tend to be rather antiquated. Think Siebel, Oracle and the rest. These are Web pages with tons of data, tiny text and more times than not, fairly slow performance. This is true because they store enormous amounts of data and allow you to query that data in any number of ways.
The idea of taking something like a Siebel “Contact” screen and just moving it to an iPad or a smartphone terrifies me. When clients ask for this kind of work, I just wonder: “Why don’t they just load their Web page on the browser of the particular device and keep using it?”
The correct approach here is to design for the device. A smartphone cannot hold the same power (yet) as an enterprise server. It will not store the tons of data that your data center does and access it as quickly. The smartphone is a portal into that server. If you need to store data locally, store the most useful subset of it and allow the user to get what they need easily from the server. If, after all, you do desire a huge amount of data, there are still ways to make it more presentable.
FIRST
Display the most relevant data first. Anything that’s secondary should initially be hidden. The purpose here is to drive the user as quickly as possible to the most valuable information. Second, just because your CRM back end gives you 200 ways to query the data, doesn’t mean your smartphone app should be able to do the same. Evaluate the top five ways in which 90 percent of your user-base do their daily jobs and use that as a basis for the functionality offered. Your users will thank you.
SECOND
“We don’t want our users to learn something new.”
I certainly understand the downtime associated with learning a new platform/application or Web site. There is a learning curve. I’ll bet I can convince you that users can learn a new thing in one word: iPhone. As I said before, its release saw people not only accepting a new UI paradigm, but they flocked to the technology because of its simplicity and beauty. They made Apple the #1 company in the world. Apple did not assume that their user-base didn’t want to learn a new thing. They said, “Here’s the right way to do it,” and everyone agreed.
This is a point I cannot get across enough: design it right, and users won’t just want to learn it, but they’ll ask you why you didn’t do it sooner!
THIRD
I’d like to address the difference between an Web page, a Web app and an application.
With the advent of HTML5, CSS3 and various supporting technologies, such as Antenna’s Volt platform, it is perfectly feasible to build a proper application using Web technology. A lot of people get confused here. They ask, “If it’s built in HTML, isn’t it a Web page?”
Yes and no. While the underlying technology is the same, there are key differences in the perception of the final product:
WEB PAGE
A Web page is typically static in its content. It will allow you to perform some basic actions, but those actions will require a page reload. This is how most of the Web pages you see operate, and just a couple of years ago, was how all Web pages operated.
WEB APP
You can think of a Web app as a Web page that’s trying really hard to behave like an application. These will typically allow more interaction (think of a ticket reservation system), and, in the case of a good one, will use AJAX calls to make it nearly transparent that you are performing refreshes. As soon as you enter data, the page is updated before your eyes and you never have to leave it or reload it. Google took AJAX to an extreme in the past year with the introduction of “instant search.” If you have it enabled, search results appear as you’re still typing your query. This is one of those features that few people would’ve asked for.
The usual argument is, “I don’t care if it takes an extra second for me to click a button.” Just like with Apple seemingly forcing its will on the people with the iPhone, this feature is one of those things that you can’t live without once you start using it.
APPLICATION
Up until very recently, this has been something that runs on a (potentially disconnected) computer. Word, Outlook, iMovie, Firefox and countless others are all applications.
They are written and compiled for the device they run on – what we call a “native application.” We are now at a point where the line between native and Web-based has blurred beyond recognition. Google’s whole suite of applications is only Web-based and Microsoft has released a Web-based Office suite.
Like a Web app, the application uses AJAX for data transmission, but that’s where a lot of the similarity ends. A true application always has these inherent capabilities:
*A great user interface (UI)
*Fast performance
*Local data storage
*Offline capability and persistence.
*Integration with the device it’s running on
Let’s look at how native and Web apps compare with regard to each of these:
UI
This feature is perhaps the trickiest. There are several mobile operating systems out there that each have a unique look. These are iOS, Android, Blackberry and a few others. While a native application will inherit the look and feel of these operating systems, a Web-based application needs to have the proper “skin” in order to feel right. More importantly, the behavior needs to mimic that of a native application very closely. If you look at something like the Android browser, for instance, you’ll see that every time you click on a link, it’s highlighted with an orange outline. This is something that a native application would never have when clicking on a button.
Similarly, on iOS, when in a browser, the click event has a delay of approximately half a second before it’s processed. This is not the case with native apps. These minor differences often add up to a less-than-perfect user experience. Even if your application has an iPhone-looking “skin” on it, someone using it will be able to tell something is off unless you also account for these minor differences.
LOCAL DATA STORAGE, OFFLINE CAPABILITY AND PERSISTENCE.
Typically, a Web app relies on server requests for its data. This breaks down when your connection goes down. While nearly unthinkable on a desktop PC, a mobile device will often lose connectivity, be interrupted by phone calls and be out of coverage areas. Luckily, HTML5 has given us a database spec with which we can now store data locally. This allows us to cache often-used information, store large amounts of data and allows a user to work offline.
DEVICE INTEGRATION
When running a native application, you expect it to be able to use your devices’ capabilities. This includes camera access, accelerometer, GPS, and anything else that your device may include (such as the “can’t wait for it already” NFC). While the HTML5 spec is making some strides in this area, it is up to a container to expose such functionality. For example, the Volt container allows our HTML5 applications to utilize such device capability.
So, which approach to take? There are, of course, some downsides to Web applications. Most notably – performance. While this gap is getting shorter every day, a side-by-side comparison with a native app will always show a Web-based application lagging. However, when you compare the effort required to develop either application and how much of a quantifiable difference there is in the performance, this gap becomes almost non-existent. In some internal metrics at Antenna, we see that an application built on Volt can be as much as 80 percent faster to build. This is on top of the fact that it is much easier to find one developer with Web development background than finding one per platform with native development background. The costs associated with the engineering cycle of building a Web-based application are significantly lower (given a powerful platform such as Antenna’s Volt).
Does your application rely heavily on features available only for native development? Heavy CPU or GPU use, 3D rendering, time-consuming calculations or massive data stores? In this case, a native app is probably right for you. However, for the majority of applications out there, a Web-based approach will not only be faster and cheaper to deploy, but will be able to serve people on multiple platforms, from smartphones to desktop computers. I firmly believe this is the future of applications development. It’s time to make the next leap.
Tags: AJAX, Michael Drob, Mobile Application, Web Page
