Definition of Terms
This article uses the following terms with specific meanings defined here:
- A web UI is a user interface designed to be rendered in a web browser. As such, all components of this type of user interface use only those display and input technologies supported by the browser -- such as HTML, CSS and JavaScript. This type of user interface is usually the presentation tier of a multi-tier web application.
- A graphical user interface or GUI is a user interface designed to be rendered on the graphics system of a given device. As such, this type of user interface may use any component supported by the graphics system or a standard abstraction layer, such as that supplied by Microsoft's .NET framework or Java Swing.
- The term sovereign stance applies to a user interface that typically occupies the entire client area of the presentation environment and organizes content into fixed regions within this space. Any given region is dedicated to a single application function and only one set of content is displayed within that region at any given time. Microsoft Outlook's user interface takes a sovereign stance.
- The term transient stance describes a user interface that typically presents content in regions that can be independently sized and moved anywhere within the presentation environment. Each separate application function or set of content within an application function is typically displayed in a new independent region. Microsoft Excel's user interface takes a transient stance.
Off-line Use
Web UI: Not useful for off-line applications
By definition, a web UI is delivered over a network, whether the Internet or a private intranet. To be useful, a web UI must have a continuous network connection to an application server.
GUI: Fully supports off-line applications
Since a GUI runs directly on the user's device, it can support connected, disconnected or occasionally-connected modes of operation.
Mitigation: Web UI workarounds are available, but unattractive
It is possible for a web UI to use a lightweight application server and database installed on the local device for off-line operation. However, this undercuts the "zero client footprint" installation that is the greatest single advantage of a multi-tier web application.
Some AJAX frameworks provide off-line support for web UIs, but these facilities are not standardized and are far from production-ready.
Native Integration
Web UI: Integration is problematic and inconsistent with the native user experience
The web browser limits a web UI's access to native applications and facilities -- for example, to send output directly to a spreadsheet or to a printer. Standard mechanisms exist to provide this access, but increasingly these are disabled in the browser's default security model. The remaining reliable mechanisms provide only indirect access, which typically requires several steps to accomplish a given task.
GUI: Supports integration to the full extent provided by native interfaces
Because it can run directly on the user's device as a trusted application, a GUI will typically have full access to any interfaces presented by the operating system or other applications. A GUI may typically use any component available to the graphic environment.
Mitigation: Web UI access to native interfaces is possible, but has been increasingly curtailed
It has long been possible for a web page to present embedded native objects, such as ActiveX controls. However, abuse of this capability has lead to ever-tightening restrictions on embedded objects in all major browsers. As a result, it is impractical for a legitimate application to use embedded objects except under controlled environments that would generally also permit use of a native GUI.
Advanced Interactivity
Web UI: Interactivity such as drag-and-drop is expensive to implement and inconsistent with the native user experience
Web browsers were originally intended to display relatively static content, not application user interfaces. HTML, the core presentation standard used in web UIs, has evolved very little from these origins. Advanced user interactivity features, particularly direct manipulation metaphors, are possible only through ancillary standards such as CSS and JavaScript. Inconsistent implementations of these standards and a lack of meaningful support for object-oriented programming in current web browsers makes it difficult and expensive to include complex interactions such as drag-and-drop in a web UI.
GUI: Default component behaviors provide for most needs. The component set can be extended for more complex interactions
A GUI typically has full access to the graphical environment's interfaces through an object-oriented programming model. Complex interactions are still difficult to implement, but the default behaviors provided by a given GUI component set provide for most needs. Object-oriented programming models allow expert developers to extend the component set for use by less-skilled developers.
Mitigation: Advanced interactions possible in web UIs using AJAX -- with significant complexity and risks inherent to lack of standardization
The rise of AJAX frameworks has made advanced user interactivity accessible to more web UI developers than before. However, these frameworks are not yet standardized or integrated with web UI frameworks in a way that could compensate for the lack of object-oriented component sets.
UI Stance
Web UI: Generally limited to a sovereign stance
Because it runs in a web browser, a web UI is necessarily framed by the browser's user interface. This means that web browser UI elements such as the menu, the forward and back buttons and the address line are continually available to the user, whether or not this is desirable. Although the web UI can open a new browser window to display content, these windows do not share the application context of the original. These factors make it difficult for a web UI to maintain a transient stance.
GUI: May take either sovereign or transient stance
Most GUI frameworks allow the application to create and manage windows that can share a common application context. A GUI can also use components that divide its client area into regions and will present only those elements the designer chooses to include. This allows a GUI to take either a sovereign or a transient stance with equal facility.
Mitigation: Transient stance is possible for a web UI on a do-it-yourself basis that may not work across browsers or application servers
Through the use of JavaScript and proprietary browser extensions, it is possible for a web UI to create windows that share an application context and do not present the browser's menus or controls. However, these techniques are browser-specific and will not work with most current web UI frameworks.
Performance
Web UI: Response time may be excellent for a simple UI, but degrades rapidly with complexity
For each significant interaction, a web UI must retrieve both application data and presentation components over the network to be rendered in the web browser. This overhead is trivial for simple web UIs, but increases rapidly as designers use ancillary standards such as CSS and JavaScript to improve interactivity and appeal. This is especially apparent when the web UI runs over the Internet, where network latency across the dozens of requests necessary to render a complex page can seriously degrade response time even if ample bandwidth is available.
GUI: Generally provides best response times assuming investment in design and tuning
Because its presentation elements are already installed on the user's device, a GUI need only retrieve data across the network. This results in significantly better response times for multi-tier GUI applications -- provided that component initialization is not excessively time-consuming in the chosen graphical environment. Response time can be even better if the user interface retrieves some or all of the data from a local source.
Mitigation: Prevalence of web delivery model guarantees continual improvements in performance over time
AJAX techniques can be used to improve the apparent response time of a web UI, at the expense of longer initialization times and increased development complexity. Browser and edge network caching strategies can improve the response time even of non-AJAX web applications.
Both web UIs and GUIs will generally exhibit longer screen-to-screen response times than the sub-second response times possible with a well-tuned character display terminal UI. However, the greater information density and optimized navigation possible with web UIs and GUIs means that well-designed user interfaces using these presentation architectures enable much greater end-user productivity in actual workflow scenarios.
Client Installation Footprint
Web UI: Often the only practical choice for application delivery to the general Internet population. UI complexity undercuts this advantage.
The single most significant advantage of a web UI is its capability for a "zero client footprint" install. A simple web UI can run in even the most limited client profiles without requiring any software on the device other than the web browser, which is practically always present already. This advantage breaks down as the UI becomes more complex. To the extent a web UI uses ancillary standards and, worse, proprietary extensions to improve interactivity, it becomes subject to considerations of platform support and client configuration.
GUI: Only practical if the end-user is supported by an IT organization or is self-supporting with respect to installation and configuration
By its nature, a GUI will always have a significant installation footprint. Features of the chosen GUI framework can lighten the administrative and platform support issues that arise from this, but cannot eliminate them.
Mitigation: Web application frameworks can reduce the cost of supporting complex, cross-browser web UIs. Framework features can reduce the installation footprint of GUIs
Current web application frameworks such as JSF provide some abstraction of the presentation logic from the specific standards used to render the web UI in the web browser. This reduces the costs of developing and maintaining the web UI across device platforms -- at the cost of limiting the UI components to the set supported by the framework and its extensions.
Conclusions
The weight carried by each of these decision factors will vary according to product business requirements. However, the reach and support profile advantages of a web UI are so significant for most applications that, as a rule, a web UI should be used unless there is a truly compelling reason to choose a GUI. When such compelling considerations exist, a hybrid design should be considered to preserve the advantages of a web UI for all but those functions where a GUI is truly necessary.
Both web UIs and GUIs should always be developed under a standards-based application framework that is extensible. The application architecture should be layered and decoupled using standard design patterns and technologies so as to permit re-use of components if the UI must be re-implemented or moved to a hybrid design.
The organization should avoid a simplistic approach to defining performance and interactivity requirements. Emphasis should be placed on user productivity in likely work flow scenarios, rather than on isolated measures of page response-times. Likewise, advanced interactivity should be specified only when it is truly necessary to user acceptance. A good rule of thumb is, "A user interface can be fast, rich or cost-effective -- pick two."
Can you briefly describe how a proprietary corporate web framework constrains the use of HTML and CSS code. I am working on an application development project. The application must the company's standard web framework. Thank you. Jeff.
ReplyDeleteThat depends, of course, on the framework. A proprietary web application framework designed on a Model 2 MVC pattern with comprehensive support for data binding, component and event abstractions wouldn't necessarily impose significant constraints on the use of HTML and CSS. It would also be fun to ride a unicorn. Unfortunately, they don't exist in nature either.
ReplyDeleteIn my experience, in-house web frameworks generally lack one or more of these critical features because the resources, the design patterns, or both were not available at the time the framework was designed and built. (I include here the frameworks I myself designed in the days before Struts.) The impact of this will depend on which of these features is missing.
No MVC? Then the navigation, presentation and data-handling logic is probably embedded in the pages or the server-side components that generate the pages. This means that if you want to present a different view, say for mobile devices, you will need to duplicate or refactor this logic.
No data binding? Then the code for input validation and data conversion is probably scattered and is most likely directly dependent on server-side APIs and/or DOM scripting. You'll have to untangle and replace this if you ever want to use AJAX or HTML5 techniques for advanced interactivity.
No UI component abstraction? This can make even simple changes such as adding styling laborious unless someone was prescient enough to create structural HTML, got the semantics right when they did, and was somehow able to enforce consistency across the markup over time. You may be able to make a single change in a common CSS style sheet, but might have to put the target markup for the selectors on hundreds of elements across dozens of pages. This effect is greatly multiplied for more complex UI metaphors that require DOM scripting, the ubiquitous date-picker for example.
No event abstraction? Then web applications using the framework must either limit interactivity to the server dispatch cycle or cope with the significant differences between the client-side event models of the major browsers.
Hope this helps.