Websites, Web applications and Mobile apps

Origins of the WWW

The very first web browser, named Nexus (renamed from WorldWideWeb to avoid confusion), was written by Sir Tim Berners-Lee and completed development on Christmas day 1990. The source code was released to the public domain the following year – and the World Wide Web was born. Unlike the majority of today’s web browsers, the application was devised as much for creating content (web authoring) as presenting it; the primary aim being to provide a mechanism for scientists as CERN (and other research establishments around the world) to report their findings, articulate hypotheses and reference the work of other colleagues in a spirit of collaboration.

It may come something of a surprise to discover that Nexus was graphical with its editing capability adopting a WYSIWYG (What You See Is What You Get) approach. The first text mode web browser LMB (Line Mode Browser) had one distinct advantage over Nexus – it was cross-platform and would run on a variety of computers: Nexus would only work on the NeXTSTEP platform.

Many web browsers have come and gone since them; ViolaWWW, Mozaic, NetScape, Cello and AOL Explorer to name just a few. There remain many products out there today but (in the western world) the most well known being Google Chrome, Microsoft Internet Explorer (largely through its links with corporate systems), Mozilla (Mosaic-Killer) FireFox, Apple Safari and Opera. All of them present HTML and communicate over HTTP in much the same way as did Nexus (although the language and protocol have moved on a pace).

Client-Server at two levels

Nearly 30 years before the WWW, the Client-Server (CS) pattern was devised and is the architecture underpinning the Web Server/Browser model. The fundamental difference between traditional CS and the software behind the web is that browsers can connect (through a standardised protocol) to any server and vice versa.

Until relatively recently (15 years ago), most CS applications employed a dedicated front-end component, developed in something like Visual Basic, proprietary communications software (middleware) and a direct connection to a database. The see-change came with the adoption of the web browser as a generic front-end and the HTTP/S protocol through web server as middleware. At the same time there was a move to ‘n-tier’ architecture separating business logic from database access.

This is the foundation of the Web Application.

Where websites end and web applications start

When applications started to grow beyond manageability, components like Content Management Systems (CMS) came to the rescue. CMS’s regularly retain content in a database and make it available through a web server. Web sites, especially through supporting e-Commerce capability, have become mission-critical systems for many businesses. Such sites have become very sophisticated, just look at the Amazon market place. It is difficult to determine where websites are replaced by web applications; but I have some criterion to offer.

Over more than 18 years I have developed many applications, the majority of them CS and, over the last 10 years, the majority have been web applications. So, I would assert there is a distinction between websites and web applications, and the size of the development is no indication. There are some very large e-commerce websites, larger than many of the applications I have developed. I have also developed web applications that represent a greater business consideration than the company’s website – so how to delineate?

My first criterion is; if you remove the web browser from the system you can insert a replacement technology for web applications, but this is not an option for websites. Some mobile apps server a similar purpose to e-commerce sites but I will discuss this later (please keep reading). Likewise, web applications are often developed to operate entirely over an organisation’s intranet and may support an extranet facility, but an Internet presentation is less common (but not unknown). However, the three user portals (intranet, extranet, Internet) represent very different security considerations.

Second criterion: Web applications are developed to serve a user community, usually with a variety of roles and access permissions; Internet websites are designed to serve visitors all with the same access rights. Visitors might be ‘registered users’ but this is usually just a mechanism for capturing the customer-specific details. Websites targeted at a specific community are more often internal to an organisation and better known as Intranet/Extranet (rather than Internet) sites.

  • Intranet Users: are trusted and authenticated members of the organisation.
  • Extranet Users: are authenticated members of an external organisation, registered as legitimate users.
  • Internet Users: may or may not be known to the application (anonymous) – visitors.

Third – Sites and Applications have different priorities. It could be argued that both websites and web applications support a business function, especially when the site supports the company’s e-commerce proposition. However, all websites adopt the mantra “Content is King” and without content a website is pointless. Content can be important to web applications but more often the most important consideration is the functionality it provides “Functionality is Fundamental” – if the web application does not do, it will not do, however pretty it might look.

Finally – consider the role of “Cookie Policies” and Search Engine Optimisation (SEO). For those unfamiliar with the issue behind cookies and do not understand cookies, I will give a brief explanation. A Cookie is a file on the client computer that is associated with a specific website. It is used to enhance the visitor’s experience by storing visitor-specific information. The ‘Policy’ informs the visitor of what information will be stored and gives the visitor the option to access the site without using a Cookie, or advises the visitor that their experience will be degraded without a Cookie.

Web applications could have a sound technical reason for storing data on the local client system. The use of local storage (with HTML5 Cookies are not the only option) in an application is likely to provide significant support to functionality when the computer is disconnected from the network. Allowing (and refusing) Cookies must always be an option for websites but it could be essential for an application; without which the application might not be able to perform its purpose.

Notifying users of the release, update and temporary closure of a web application is essential because of its purpose in supporting the business. The user community are highly unlikely to be able to find an alternative, which is also a feature of a good mobile app – like a banking app. The process of notifying users is usually well defined within the user community so the ‘site’ (web presents) is unlikely to be registered with any search engines. Applications do not need to be discover-able, the complete opposite of a website.

Mobile apps – the good, bad and darn-right ugly

So “what don’t you like about apps?”, you might ask. Nothing. I use them on my Android phone, on my Apple iPad, and have been developing them on Windows for years. That’s right, on Windows. Indeed the second web application was involved in was far more like an App than a website, and the application continues to operate in the same model. This is a bit of a cheat on my part, read the details below on HTA for an explanation.

My standpoint on Apps is they should either be standalone or deliver more than their website equivalents. Otherwise all you have on your device is loads of re-badged, reduced capability web browsers, probably all using WebKit to show you a selected group of pages with content you could just as easily get directly – glorified bookmarks (bad apps).

“Good Apps” operate effectively without a network connection (unless it is essential to its purpose such as satnav, or just occasionally when connection is make available) and/or offer functionality that is not generally available to web browsers or those available of the target platforms/devices.

I also dislike those Apps that have been developed a device/platform specific “native” technology unnecessarily; when using web technologies to produce a portable self contained application would have sufficed. Unless performance is a major factor or the targeted platform is the only place the App makes sense, such as iWorks, making platform-specific non-portable Apps are just plan ugly.

Far too many customers, rather than asking for a mobile site, because “You get that free with the desktop site if you employ RWD, don’t you?”, are asking for Apps. Unable to come up with a justifiable business reason for distinct set of features, the App very often is just a self-contained edition of the mobile website. Let’s see how that behaves when there is not Internet access!

Am I wrong? If you think so I am ‘all ears’, post your opinion please. I would love to hear what others think on this matter and learn from different perspectives on the issues raised.

The original Microsoft Apps

Long before Windows 8, tablet computers and even before iOS, I wrote my first App (going by my definition above) on Microsoft XP. The easiest was is to take a working HTML file, located on the local machine, and change its extension from html/htm to hta (HTML Application). What you have is cut-down edition of the installed copy of Internet Explorer. It is actually a different executable (MSHTA.exe) that is installed as part of the operating system. Executing an HTA present the user with an application window containing an HTML Document Object Model (DOM), in much the same was as XAML and XUL. The HTA can execute JavaScript (actually JScript and VBScript) and render CSS in exactly the same was as regular HTML pages in IE. The application window does not have a toolbar or address (URL) field and, through the HTA:APPLICATION object, can be manipulated and made to look and feel like a regular windows application. It can even access command-line arguments.

A word of caution: HTA’s do not operate within the security of a sandbox like regular web browsers. This makes the computer running the HTA open to attack is accessing un-trusted sources. However, the main reason I use this approach it to access local and remote trusted content. HTA’s can access the local file system, creating files, directories and saving data without need for cookies or HTML5 local storage. HTA’s are used effectively as containers for MS Administration functions using VBS but don’t let that stop you from experimenting.

Here’s a couple of examples. Before you execute these example make sure you are content with their minimal functionality.

1) Store the below text as a file on your system – with the file name Hello.hta.

<!DOCTYPE html>
 <meta http-equiv="X-UA-Compatible" content="IE=Edge"/>
 <title>HTA - Hello World</title>
 <h2>HTA - Hello World</h2>
 <h3>Right click on the dialog to access the Context Menu - regular browser (IE) functions.</h3>

2) Here is an enhanced example.

<!DOCTYPE html>
 <title>HTA - Hello World</title>
 <h2>HTA - Hello World</h2>
 <h3>Right click on the dialog to access the Context Menu - disallowed.</h3>

 window.onload = function() {
 var objApp = document.getElementById("HelloExample");
 alert( objApp.commandLine);

Equivalent technologies to HTA include: Mozilla’s XULRunner and the Qt QML or WebKit. Indeed the web-based Operating Systems such as Chrome(ium)OS, FireFoxOS, Plam (now HP’s) WebOS, JoliOS (no-longer supported) and even Windows 8 (phone), all employ a similar technique.

Return to Articles

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s