Our previous posts have looked at licensing and asset management issues. We thought it appropriate to take a couple of steps back and look at some technologies that helped create the conditions for Software as a Service (SaaS). We won’t cover physical technologies like computing engines or RAM, but instead will focus on software or process-related components, like the World Wide Web (now internet) and browsers. Here’s a toast to Marc Andreesen and Eric Bina, who co-developed the first successful browser, Mosaic.
Browsers can serve a number of functions, the most important of which are to navigate Universal Resource Locators (URLs ), which take the user to the specific web pages in which the URL is embedded. One unexpected side benefit, and the one we’ll focus on here, is that the browser created a consistent user interface. Initially, the browsers rendered plain text pages, and over time more and more complex graphics, pictures and streaming content. Some early application developers saw the potential productivity benefits of browsers, because they didn’t have to create a user interface to visualize their application, and their customers saved considerable costs because of the reduced training requirements.
Users, in turn, benefited from the consistency of the browser because they didn’t have to learn a new navigation paradigm with every new application they were exposed to. Can you imagine every time you bought a new car having to literally be trained for days on how to use it? This “embedded” cost not only made downloaded or client-server applications more expensive, but also ensured built- in user resistance to adoption. While application providers created shortcuts to improve productivity, users had to make individual decisions as to whether the time invested in learning shortcuts was worth the time savings using the application itself.
The earliest browsers were significantly simpler to use than our current browsers, and this lack of complexity, when compared to the rich functionality of “fat clients” applications, also restricted early SaaS application functionality. This was a significant issue for vendors, as they had to rethink how to deliver functionality to meet the browser’s limitations. What was significant was that everyone who used a browser was trained. If you could use a browser, you could essentially use the browser-based application.
Give the average person the option of a week in a class to learn to use an application along with a thick printed user’s guide, or provide a log-in for an application with Help buttons consistently in the upper right hand corner of the browser or next to data fields, and browser-based applications win hands-down. I once worked for Information Advantage, the first company to deliver browser-based business intelligence. The first interfaces felt clumsy and we struggled to replicate the sophisticated capabilities of a locally hosted application. But we were also able to deliver interactive reporting to hundreds of users in organizations who otherwise would have had to rely on emailed static reports. The training courses consisted of a 1-2 hour session, and most of the training was about the data being manipulated, not the application itself. Brower-based applications dramatically increased the potential numbers of users of an application because training and acceptance was almost eliminated as a business cost.
Again, hat’s off to Marc, Eric, and the others who developed the browser. A simple way to find documents on other computers became a foundational step to upending an entire industry.
Next week we’ll look at how the internet changed the economics of software delivery.