MultiValue Applications and Web 2.0: Providing a Desktop-Like User Experience
Ever since the days of Windows 3.1, the appeal of a GUI interface has been plain. Customers (and, to be honest, developers as well) enjoy the ability to interact with rich desktop controls. They look nice, and they behave in interesting, responsive, and useful ways. While not necessarily more productive (it is hard to beat data entry performance on a green screen character application), the GUI "user experience" is certainly expected from modern applications.
Similarly, since the early days of the (consumer-accessible) Internet, the appeal of a browser interface has been apparent: easy software deployment (or none at all), a standardized user interface with which nearly everyone is familiar, and — perhaps most revolutionary — ubiquitous availability. The Internet, and the browser interface, allowed potential "anyone/anywhere" access to applications.
Note, though, that the attributes of the browser that make it appealing, and the attributes of the desktop that make it appealing, do not overlap. Until recently, the user experience on the desktop could not easily be brought to the browser, and many "first generation" web products in the MultiValue marketplace therefore lack the dynamic "look and feel" of a desktop GUI application. This has been changing with the advent of higher-speed internet connections and "smarter" browsers with more sophisticated communication abilities, allowing applications in the browser to provide a user experience that is comparable to desktop GUI applications. This new functionality is a hallmark of "Web 2.0."
Building Web 2.0 Applications
First generation web applications usually provided simple "page-at-a-time" data entry and display. After the browser user completed all the forms on a page, the Submit button sent the names of all the input controls (textboxes, listboxes, etc.) and their values to the host, where the data was then teased apart and processed. A new page, based on the user's entry, could then be generated. While some interactivity on a page could be created through the use of JavaScript functions, entry and response was generally done as though communicating in block mode with old-style mainframes.
Web 2.0 builds upon the ability to send and receive select parts of the web page to the host, and modern browsers to allow the display to be updated in pieces rather than all at once. In fact, just like in a desktop GUI, it is possible to capture and respond to various user-created events, like "lost focus," "got focus," "key down," etc. (though these events typically have different names than they would in the desktop GUI world). These events can then be processed locally in the browser (via JavaScript), or dispatched to the host. Responses can then update the currently displayed page with new information, or even with a change of layout.
Fig. 1 O4W page prior to click event
Fig. 2 O4W page after click event
Of course, this enhanced functionality implies that the host routine must be more sophisticated if it is to reply to these various events. Indeed, rather than a typical "green screen" application (which expects the user entry to happen in a more or less linear, predictable fashion), MultiValue Web 2.0 applications must look more like Windows programs, responding in an "event-driven" fashion.
Fig. 3 Event driven BASIC+ code for the Click event on the form
While it is possible to create an entire Web 2.0 application from scratch, it is certainly more efficient to take advantage of open-source libraries that already include huge amounts of functionality. OpenInsight's O4W web development environment relies on jQuery (www.jquery.com) to provide much of the back-end communication functionality and the associated jQuery UI (www.jqueryui.com) to implement many of the desktop-like GUI features, including tab controls, dialog boxes, resizable/draggable/dropable elements, etc. In addition, the use of an open-source, community-driven library means that new "plugins" are constantly being developed and released, allowing a niche market community (like the MultiValue developer's community) to leverage the development efforts of a great many more people — typically at no additional cost.
Fig. 4 jQuery date picker control
Of course, there must still be some kind of integration between the library and UI elements and the MultiValue programming environment. In O4W, this is accomplished by the O4W APIs, which encapsulate the jQuery (and other custom JavaScript functions) in MultiValue-friendly functions and stored procedures. By using the O4W APIs directly (in custom programs) or via the O4W Wizard tools, MultiValue developers need not learn the particulars of jQuery, AJAX, JavaScript, and HTML if they don't wish to. The calls to generate the Web 2.0 content are hidden to some extent behind a familiar face.
Fig. 5 O4W Form Wizard
With the advent of Web 2.0, it is now possible to have "rich" applications available to everyone, everywhere. The advantages of the desktop application, and the browser application, can now be combined. By properly building upon community efforts, ongoing developments and functionality can be more readily incorporated in MultiValue applications, keeping the application fresh and up-to-date. In fact, as more and more elements of the desktop "user experience" become available in the browser, it is easy to imagine a time when the line between "desktop" and "browser" application disappears entirely.
