Web Interfaces - What's Really Missing. Pt. 1

Many web developers are hearing that the Web interface is quite popular and growing in impact and pervasiveness, but... It's this latter and persistent "but" that we would like to address here. First, we need to be clear on what we mean by Web interface. A Web interface is Dynamic HTML based, using HTML, CSS, DOM, JavaScript and the immediate technologies callable from these base players. On the client side, a browser is presumed; but not just a PC as tablets, PDAs, and other smart devices proliferate. The OS probably is Windows based but could also be Mac, Linux, Symbian or other varieties. This is the reality.

At a discussion group, the complaints of C/C++, .NET developers and desktop veterans (on switching to the Web GUI) sounded rather strange at first. They complained about the lack of a menu system, poor data/database connectivity with display issues, and poor support when keeping track of state and session status. JScript/JavaScript is considered underpowered for two reasons: lack of complete object-oriented capabilities and server-side support. Finally, the desktop coders complained that rich media such as video, audio, 3D, animation, voice interaction, P2P collaboration, etc., carried over to many technologies, including plug-ins, APIs from Flash, Viewstream, Windows Media Player, Cult 3D through Java/J2EE and .NET, to XML-based SMIL and SVG. Additionally, many of these rich media technologies have their own development environs and scripting language(s). Finally, the schedules were deemed "brutal" and had only the tiniest provisions for planning and design. Welcome to Web development 'mein Freund.'

Missing Links

The desktop coders mixed fact with misconception. Take menuing, for example. Many desktop developers use IDEs such as Microsoft Visual Studio or Borland JBuilder with drag-and-drop GUI functionality. Adobe GoLive, Macromedia Dreamweaver, and Microsoft Front Page all have strong drag-and-drop visual layout tools for DHTML; but curiously their support for menuing is mixed - a template here, a wizard there, but no reusable menu designer. However, third party menuing tools such as NavSurf's AceMenu, Selteco Menumaker, and Xtreme SiteExpert all offer visual menu designers that can produce vertical, horizontal, and icon-press popup menus of varying sophistication, colors, and icon/image support. With JavaScript and CSS it's easy to place a menu anywhere on the screen, in any orientation and responding to many different mouse events (a feat much harder to code in Windows or on the Macintosh OS). In short, the Web interface may be a bit "richer" for menuing than the desktop.

But the same cannot be said for database access and display. Dreamweaver, GoLive (and Front Page through Yes Software's CodeCharge Studio add-in), have database connectivity experts with additional builders/wizards similar to Visual Studio or JBuilder counterparts. But the desktop IDEs have a wider selection of GUI components for displaying the data. As an example, visit ComponentSource.com or ProgrammersHeaven.com to see dozens of JavaBeans or .NET/OCX components in the form of data grid, pivot table, charting and reporting controls. Also, desktop developers are less likely to need to switch development languages on the Server, unlike JavaScript. And support for sophisticated middleware, data integration, P2P and Web Service APIs are more likely to be available in C/C++, Java or .NET languages than in JavaScript.

Given the relative paucity of DHTML database display capabilities, one could hardly expect better from forms and data input (since HTML forms controls are getting pretty long in the tooth…). Still, the DHTML situation is not as dire as one might expect. First, popup windows, frames and iFrames approximate Windows popups, panels, and MDI windows respectively. Second, the more uniform implementation of CSS and DOM across all of the latest browsers has unleashed a flood of CSS inspired components: tabbed windows, scrolling panes for text and/or images.

If you visit sites such as Hotscripts.com or JavaScript.com, there are many free components available for development with DHTML. Calendars, scrollers, graphs/charting, tree menus, grids, slideshows, panels and windows are just a few of the DHTML input components available. Some are proprietary (most often IE or ActiveX dependent), but the trend is towards cross- platform implementation using DOM and CSS. With new CSS support features and third party add-in components for Dreamweaver, GoLive, etc., DHTML developers should expect these components to grow in number, sophistication and price. i.e. Expect to see more developers charging for their DHTML wares just like JavaBeans and .NET components.

But desktop developers raised another concern - lack of speed and/or herky-jerky performance with the browser interface. Given the nature of external Internet network delays; page refreshes, if used too often, can mar a Web interface and its performance. Finally, the desktop developers applied their "coup de grace" arguments - desktop interfaces appear to be very polished and well designed and have better ease-of-use. Citing the new Panther and Longhorn interfaces that were released and revealed this Fall (due out in 2006 in the case of Longhorn), by Apple and Microsoft, one desktop developer challenged the Webbies to match that same polished look and feel.