The Evolving Interface
As of December 2011, this topic has been archived. As a result, it is no longer actively maintained. For more information, see Archived Content. For information, recommendations, and guidance regarding the current version of Internet Explorer, see Internet Explorer Developer Center.
January 10, 2000
One of the core assumptions about the "graphical operating system" was that the operating system would supply a collection of graphical "widgets"—essentially solving two problems at once—by providing an easy-to-use interface that could be common between all applications, and by not requiring each application to carry along all of its own interface generation and management code.
Prior to such a system-supplied graphical user interface (GUI), any application that wanted to present users with a rich and robust interface (graphical or not) would have to include its own customized, built-in set of interfaces. Remember: Most computer operating systems of the time were primarily hosts to command-line programs. Not only were they just text-mode interfaces, but often the programs did their work by taking a complex command line set of arguments, which indicated all of the functionality the user was wanting. The program would do its processing, then return back to the operating systems command line when it was done.
An application programmer who wanted to develop an application that took over the screen and allowed dynamic interaction from the user was faced with the often-daunting task of both designing a tangible user interface and programming it. Often, the code required to manage such an interface required more lines than the actual solution it was supporting.
Another problem faced with these early programs was that—from a user's perspective—every single program looked and operated differently. A user might start with one program that put some sort of menu-selection system at the bottom of the screen; the next program might put menus at the top; and the next one could require some special key combination to switch to a menu/command mode. Not only was there a lack of commonality, but these early interfaces were often designed by geeky programmers—and it showed.
A More Uniform UI
Centralizing the user interface into the operating system itself gave application programmers access to some pretty cool code that they would no longer have to manage themselves. It also meant that all applications running on that operating system would be using the same core "widgets," or the same interface, to interact with users. Menus would all work pretty much the same. Windows would have the same basic look and functionality, and so any user training for running one program could easily apply that training to running another program.
While writing code that used these new interfaces required additional and often slightly complex code, it was still a lot less code than programmers would have had to write on their own to get the same level of functionality.
Running for Everyone
Unfortunately, an inherent problem with these different graphical operating systems was that code was usually difficult to effectively move from one system to another. Various third-party solutions would take different approaches at making it possible to develop code that could run across multiple operating systems, but such solutions usually had their own set of drawbacks.
This need for cross-platform compatibility became a constant undercurrent—which frankly means that it really isn't so surprising that this whole HTML/Web thing has moved so quickly. Many people thinking about this problem, and when a glimmer of an appropriate infrastructure started to take shape, it was inevitable that it would evolve at a breakneck pace.
Does the Web then provide us with the philosophers' stone that might allow us to unify all functionality into one grand scheme—one which can work on any operating system? Well, no. The key problem is that as long as there is an exploitable difference in the underlying hardware and/or operating system, applications will take advantage of this functionality to provide greater functionality to their users. While perhaps the mythical appliance computer might be able to provide a homogeneous systems platform, I expect the full-fledged computer will always flaunt its diversity as one of its primary benefits, and rightly so. In the meantime, application programmers need to choose carefully how they develop their applications, depending on the audiences that they want to address.
Three Ways to Go
From a user interface standpoint, there are three ways to approach the problem. Most applications, but definitely not all, will choose to use two or more of these ways in coding up their user solutions.
On one end of the spectrum is the traditional GUI application that relies on the underlying operating-system features for its graphical interfaces. You have free and consistent access to things such as pop-up menus, dialog boxes, scroll bars, and so forth. Such an application is closely tied to the operating system, but such strong ties also give it the deepest access to the features provided by both the operating system and the hardware connected to it.
On the other end of the spectrum, you have the platform-independent approach of using the most broadly common capabilities of HTML on the client, sometimes combined with special server-side features to give the appearance of a rich and expansive interface. The benefit of this approach is that your audience can be extremely spread out on a wide variety of operating systems as well as browser clients.
Then there is the area between these two extremes—the solution in which you are including dynamic user interface features and capabilities within your HTML-based applications. You can achieve this by either embedding actual application code within your page itself, which is accessing the GUI features supplied by the operating system, or you can take the more common approach and rely on tables, <DIV>s, layers, frames, scripting, and Java to craft your own menus and graphical interfaces from the barest of raw components supplied by the browsers. This means that such applications are again back to the point of rolling their own dynamic interface code—or at the very least, including classes and/or scripts that they need to carry around with them where ever they go.
The Next Step
It probably doesn't take too much imagination to realize that as various Web sites invent and reinvent the same sorts of interface "widgets" for their pages, these features will eventually be fine-tuned to the point that some of them will find their way into the browsers as well as into some form of standards. We are already seeing CSS and XML moving to fill the void of things that don't quite fall within the functionality HTML is supposed to provide, thus both enriching, as well as complicating, this environment. The more things change, the more they stay the same.
Robert Hess hosts the MSDN Show.