|White Papers Home |  White Papers | Message Board |  Search |  Products |  Purchase | News |  |
The Diminishing Importance of HTML
by Rick Strahl
West Wind Technologies
HTML based Web development has dominated application development for the last 6 or so years and at the moment there are no signs of letting up. But things may be changing as the .NET platform with the advent of the .NET platform. Although Microsoft has put a tremendous effort into its Web based interfaces which includes the new powerful new ASP.NET Web Forms framework, I'm venturing to guess that there will actually be a push back to desktop driven forms based applications once .NET takes hold.
What? I must be kidding, right? I don't think so. Let's start by looking at some of the issues facing HTML development as an application front end.
What's wrong with HTML as a front end?
Although .NET makes it somewhat easier to build HTML based Web applications, it still is far from straight forward there are just too many limitations in HTML's markup definition, that no matter how much fancy wrapping is done around the basic controls, it still makes for a much inferior interface to desktop applications.
Lack of visual tools
The release of Visual Studio.NET also has not made great inroads into HTML design itself with its visual editor, which is not exactly a milestone above the one found in Visual Interdev. Yes CSS/DHTML based positional interfaces are easier to work with visually, and some major 'issues' have been fixed. But for standard, page flow based HTML (read table based layouts) the designer leaves a lot to be desired when compared to full visual tools like MacroMedia's Dreamweaver or even Microsoft's own FrontPage editor. The HTML code editor in VS.NET on the other hand has seen many very welcome improvements, which pays tribute to the fact that most developers still use code editors rather than visual designers to build HTML by hand. While it's not difficult to hand write HTML code, it's very tedious and time consuming and for most Web apps HTML creation takes more time and resources than writing the application logic. Web forms help with some of the tedium as the controls generate much of the tedious HTML, but you still need to get those controls into the HTML page and positioned correctly which puts us back at the original point of the lackluster visual support for layout. The point here is that for broad market HTML applications it continues to be a lot of work to create workable HTML interfaces.
Limited HTML form interface
On a broader level there's the issue of HTML as a form interface for serious applications. I had an interesting experience a few days ago when I got a call from a telemarketing company that wanted to know how the local cable company was doing. Slow that I was that day - *never ever* acccept a call from anybody calling you Mr. Strahl - I accepted the 'invitation' and was treated to a long winded survey which went on for almost 20 minutes. The person on the other end kept fumbling and complaining about moving the mouse around her application, with fields not flowing properly from one control to the next in the new system they had just switched to. When asked, it turns out that the application was an Extranet application running in a browser so that the various telemarketers can run from home and still be able to run these surveys in a centralized format for immediate availability and rating. Good idea bad execution apparently (either that or a severe case of operator error <g>).
While this is a specific instance, I've seen this in many business locations where companies have gone overboard slapping a Web HTML interface onto everything that needs to be centralized. This is especially true for complex applications that require lots of data entry, which is notoriously the worst feature in HTML the lack of complete control over data entry controls. Take things like the simple concept of a Treeview control, drag and drop or even multi-column list boxes and you can get a good idea just how limited HTML really is for even basic User Interface tasks. I've built a number of applications in the past that have both a Web and a distributed model desktop interface and if it comes down to a choice of which is easier to use on a day to day basis the desktop version wins hands down for usability and sheer speed of accomplishing the same tasks.
ASP.NET is specifically geared towards rich, form based applications as the Web Forms framework tries to focus on an interface that essentially mimics a desktop interface of forms on the desktop. But it too is limited when it comes to providing HTML with some 'simulations' of rich interface controls. Not only are most of these simulations clumsy and slow they also end up sending a lot of HTML text around unnecessarily wasting network bandwidth. ASP.NET accomplishes much of its form based metaphor through a state saving mechanism that pushes most of the UI changes through standard form variables which can greatly affect the size of the data travelling over the wire.
I'm not talking about online shopping carts or a simple query application that displays a few numbers from a database where this sort of overhead is probably minimal, but about applications that corporations run on a daily basis for data entry and management of their data. There's been a big push to get many of these types of applications running over Intranet or Extranet connections because of the universal accessibility of these applications from any network connection. I've seen a number of these applications fail, mainly because of the HTML user interface issues users simply didn't want to put up with a huge step down and managers didn't realize the extra effort it would take to build a highly usable interface using HTML.
Remember that there's more to applications than text! There's the often overlooked issue of alternate technologies that are used today to handle content that a browser can't deal with directly. Do you ever try to print from a Web application? There's no native way to get controlled printing out of a Web page. Printing HTML from a browser is hardly a solution for anything but a single page. To use serious printing of any sort you like resort to generating a PDF document and sending that down from a Web server, which is also problematic since there are so many problems with the PDF viewers in Internet Explorer from dynamic content.
There's still a slew of Java applets out there (although there's much less hype about that these days), running applications that can't be easily written using even advanced DHTML code, because of performance or lack of access to the necessary services. Java applets and Macromedia's Flash technology are the rule in this area and Microsoft was never really able to make a dent in this arena either with Internet Explorer's DHTML implementation or the browser based ActiveX platform (ActiveX controls, Active Documents). The former has been limited by the browser dependency on IE, the latter is simply to scary due to the security implications of the control having full access to the underlying OS. However, there's demand for these types of services that need to run on the client machine for performance reasons that script can't touch and specifically for a richer platform that provides the network IO and these days XML services that client side applications require in order to be functional. If you take a look at the various online gaming interfaces available you can actually get a good example of applications that actually require this kind of functionality to provide fancy graphic interfaces and network access to communicate quickly with the server. And you'll find that most don't use Microsoft technologies because the tools to build them are missing or not supported by Microsoft. But this may change with .NET.
Distributed architecture gives new options
I don't think any software developer will argue with the point that HTML or browser interfaces in general are very limited. Unfortunately corporate managers often can't see the distinction between a desktop app and one running in the browser, except that a browser based app can be accessed over the Internet.
One of the big reasons the push to HTML occurred originally was the fact that HTML applications were distributed many clients could access content simultaneously over easily accessed connections and data would be immediately available to all. Well, things have changed a bit since those early days and today we have the ability to access content without requiring an HTML interface. With the distributed architecture we can now build Web Services or even plain XML based content that can be consumed by any type of application over the Web. With the right tools integration of this type of functionality on the client is very straightforward and doesn't require much code at all.
This also means we're no longer tied to a complete application running on a Web Server, but can have a server on the Web acting as a data service providing information that can be consumed by a wide variety of different clients from other Web Sites, to desktop applications, to hand held PDAs with small applets running on them. We can have the User Interface and some basic validation business logic running on the client to provide the user with instant feedback without going back to the server each time to check a business rule that requires some data.
With the distributed architecture of XML and/or Web Services HTML interfaces are becoming much less important as you can now build applications that get all their data of the Web, but don't require an HTML front end to do it. You can have a rich UI that is customized to the needs of the end user. Existing applications can integrate Web functionality now without requiring a full re-write. This is especially important for many vertical applications that have an established market. In many cases there's no need to throw away an existing interface implementation just because the need arises to share data in a more central location. With a Web Service interface you can now access data over the Web and bring it down into the client side application relatively painlessly for easy manipulation and even if you don't buy into the Web Services hype, retrieval of any kind of Web content whether it's binary data or XML is relatively easy to accomplish from a desktop app.
.NET's release has been hyped extensively and if nothing else has really pushed the awareness of distributed computing and Web Services to a whole new level in the developer community. While there still is a dearth of publicly available, really useful Web Services, Web Services really will show their true potential on the internal side of things as data services for in house or vertical applications with private non-published interfaces used only by internal developers.
To take advantage of distributed application development, rich client applications have a variety of ways to spread out and retrieve data. Here are a just a few common scenarios:
Pulling data updates from a server
Many applications require frequent updates of critical data which can be pulled over the Web as needed. This is especially useful for vertical applications that basically run standalone except for occasional data updates. Version updates can be handled in the same manner.
Running with remote data
It's easy to build a Web Service that acts as a data server and can provide a client application with all the data it needs locally. This involves treating the Web Service as a data source and requires an always-on connection to the Internet.
Running with offline data
Another mechanism is to pull data down from time to time and run in offline mode. .NET DataSets are one technology that makes this type of operation very easy by providing a local data engine that can easily synchronize with the full data backend using a Web Service for communication. In this scenario, an Internet connection is only required on demand when posting and retrieving updates.
The downside to a non-HTML application is that there are installation requirements on the client and this has been a problem in the past. However, .NET may also change this aspect of deployment considerably.
Windows Forms the most understated .NET feature?
The .NET framework hype has mostly focused on the Web and Web Service features, but the framework also includes a complete GUI object model for building rich client desktop interfaces. The new set of classes exposes the Windows GUI in a rich and consistent model that provides the power of C++ programming with the ease of development of 4G languages like Visual FoxPro and Visual Basic. The .NET framework also exposes a very large chunk of the underlying operating system with a largely platform independent class framework. While this type of Windows application may not serve all types of application (primarily shrink wrapped big name vendor commercial apps) it certainly addresses corporate and small business development and vertical market needs.
Windows Forms are not presenting a revolutionary new concept the features are combining some of the best features of various GUI development environments including Visual Basic, Visual FoxPro and Delphi/BC++ Builder. However what's different is that this environment is language independent (at least for .NET languages), consistent, and runs on a unified runtime that is installed and controlled by the operating system. As we move forward .NET runtimes will be available on all Windows platforms.
Rich Framework keeps code size down
This has several implications. First off these form based applications generate modules that are relatively small, because they just include the actual application code and no system components.
Because the .NET framework is so rich and accessible completely from within applications the amount of custom code will be comparitively small no more linking in of all sorts of different libraries to get basic features which will result in smaller distributions that can easily download from the Web. The framework functionality exposed by the .NET runtime provides so much functionality that formerly required third party tools will no longer be required reducing the size and number of files that need to be installed.
Installation also is getting much easier with .NET's XCOPY installation paradigm, which refers to registrationless installs. The registry is no longer required to specify locations for application components and the associated DLL hell that goes with it. This greatly simplifies installation and in most cases means simply copying files and creating a shortcut. The result is that an application won't impact system configuration in any way other than the disk spaced used and uninstalling is as simple as removing the files or directory tree. You can also easily install an application from the Web both with small footprints and no installations hassles. .NET includes hooks to directly invoke Windows Forms based applications from the browser (IE 6.0 only) which makes it possible to mix Web and GUI content very closely. This mechanism is still somewhat rough, but you can bet that we'll hear more about this.
A big issue with running 'external' applications is security. .NET intrinsicly supports security settings in executable files and modules so that the application can not rely on taking over the operating system and invade the user's machine and privacy. This has been the biggest stumbling block for Microsoft in the past with its binary interfaces being 'native' code that can wreak all sort of damage on user systems. Now it's possible to lock out functionality or unlock certain features via security policies assigned to specific providers of software. This means you can block access for certain software while giving others full access to the system. There's a big tradeoff here it's now potentially difficult to configure applications to use features they might need (like file access), and there are no tools available yet to provide this type of security setting as part of the installation process. Security configuration and the entire security model is not for the faint of heart.
However, for the purpose of distributed applications that communicate with a single Web Server via Web Services (or other Internet protocol) to retrieve data into a rich client GUI application utilizing all the bells and whistles of a GUI interface; that type of functionality is available even in the most limited security model. I predict that much of the focus of 'distributed' development is likely to head in this direction.
Where are we?
All of this functionality mentioned above adds up to addressing the limitations of the HTML model by providing the same interoperability model with a much more rich user experience. Many of the issues that have driven people to use HTML based applications have been addressed to a large degree in the .NET desktop + Web Services model. If you are a vendor that is selling packaged software and worried about the Web's impact, you have the tools in .NET to integrate the Web into those applications easily without a complete redesign into HTML interfaces. And even if you are a vendor who's been playing around with the Application Service Provider (ASP) model it applies to rich distributed applications just the same using Web content from your Web service as you could with an HTML based interface.
Is all of this going to be the end of HTML? Nah, not a chance. There are still lots of applications that will require the full broad reach access that HTML brings store fronts and most public Web sites that must run on every conceivable platform and browser. These types of applications continue to do well with HTML primarily because they are not heavy on data entry. Many corporate applications however have different requirements as we're moving forward to ever more complex applications that must utilize Internet technology. HTML is not the way to move forward both from a UI perspective and also from a developer perspective as complex HTML based user interfaces tend to be much more time-consuming to build than equivalent GUI interfaces.
The promise of .NET for the desktop is very strong, and Microsoft surely has a vested interest in keeping the Windows brand in strong use and pushing the desktop forms engine can only help that cause. I think it's a good match for developers and end users alike and you'll see much more of this as the .NET framework becomes more ubiquous on end user computers. We're not quite there yet it will take some time to get .NET ingrained in the Windows desktop, but you can bet that it is coming
For comments on this topic, you can post a message at:
For comments, you can post a message at:
Rick Strahl is president of West Wind Technologies on Maui, Hawaii. The company specializes in Web and distributed application development and tools with focus on Windows Server, .Net and Visual Studio. Rick is author of West Wind Web Connection, a powerful and widely used Web application framework for Visual FoxPro and West Wind HTML Help Builder. He's also a Microsoft Most Valuable Professional, and a frequent contributor to magazines and books. He is co-publisher and co-editor of CoDe magazine, and his book, "Internet Applications with Visual FoxPro 6.0", is published by Hentzenwerke Publishing. For more information please visit: http://www.west-wind.com/ or email Rick at email@example.com.
|White Papers Home |  White Papers | Message Board |  Search |  Products |  Purchase | News |  |