BUI_SpecialRpt

december 2008 a supplement of SyStem inewS 1

Browser User Interfaces: A State of the Union

by Don Denoncourt

TML is now two-decades old, and in that time, things have changed quite a bit. HTML is still at the center of web page development, but now a host of other available technologies improve the user

experience. Here, we look at some of those technologies and how they affect the browser user interface (BUI). But first, let’s consider the evolution of browser user interfaces.

In the BeginningWhen it debuted in 1990, HTML contained a mere 22 elements. A few years later, greater formatting capabilities and support for images and external format specifications (CSS) were added to HTML. In the mid-1990s, the abil-ity to build HTML dynamically, on the web server, was enabled with the Common Gateway Interface (CGI). CGI allowed developers using popular languages such as RPG and Perl to construct business applications for the web.

Netscape introduced JavaScript in 1995, and Microsoft hast-ily made it available in Internet Explorer in 1996. JavaScript source is embedded within HTML and executes from the browser. JavaScript’s initial use was to manipulate HTML within the browser to provide such features as animation, input validation, and dynamically constructed pop-up windows.

In 1997, three important server-side web platforms emerged: PHP, Microsoft Active Server Pages (ASP), and the Java Servlet API. PHP, ASP, and server-side Java provided web development and deployment capabilities that were substantial improvements over CGI. Many other web development platforms are available, but these three are the most dominant.

XML made its appearance in the late 1990s. XML and HTML are similar in that both are tag-based languages. But whereas HTML describes how to display data in a browser, XML describes the content of the data it contains. XML quickly became the ubiquitous data exchange format of the Internet. In early 2000, the XML-supporting technologies of Extensible Stylesheet Language (XSL) and XSL Transformations (XSLT) surfaced. XSLT converts XML into HTML (or other XML). In fact, it is a common service-oriented architecture

Check out these technologies that can improve the user experience

H (SOA) strategy in which business modules are devel-oped to return entities as XML. Then, any client prepared to deal with XML, including XSLT, can consume that XML.

We can’t talk about the web without mentioning web services, which became all the rage around 2004. Web services were not designed with BUIs in mind, but instead to provide application-to-application interaction over a network. However, a relatively unexpected side effect of web services was their use by interactive browser-based web applications. But note that as a direct response to the complexity of web services, Representational State Transfer (REST) is quickly gaining acceptance as a simple alterna-tive to web services (more about REST in a moment).

The web was arguably transformed in 2005 when the use of Asynchronous JavaScript and XML (Ajax) became widespread. The features Ajax provides ramped up user expectations with the advent of sophisticated pages like Google Maps. Besides offering such features as auto-com-pletion (see the From Airport input field in Figure 1) and dynamic validation, Ajax developers also began to create

A System iNEWS Special Report

FIgure 1 The Kayak website

For helpful resources and additional figures, see the online version of this article at SystemiNetwork.com.

more on the web

2 a supplement of SyStem inewS december 2008

mashups—web applications that use other web applica-tions and web services to provide application hybrids. The Kayak website in Figure 1 is a fine example of a mashup. It uses web services and APIs from a variety of sources to seamlessly provide aggregate travel services.

Today the browser user interface is said to be at Web 2.0. Tim O’Reilly, founder of O’Reilly Media and a leader in the free-software and open-source movement, coined the phrase Web 2.0 saying, “Web 2.0 is the business revolution in the computer industry caused by the move to the Internet as plat-form, and an attempt to understand the rules for success on that new platform.” Now let’s dive into the technologies you need to make your next web application take advantage of Web 2.0.

Putting the X in HTMLWeb browsers are very lenient with HTML syntax. Like XML, HTML is a tag-based language. But unlike XML, HTML must fol-low the rules of XML—specifically, XML tags must have a matching close tag, and tags must begin and end in the same parent element. It’s typical, for example, for HTML to have tables and forms with no closing tags. But browsers are very forgiving, and they guess where tags ought to be closed. The problem is that this tag speculation is different between browser implementations, resulting in inconsistent page rendering.

The solution is to force HTML to follow the rules of XML by using XHTML, which became a World Wide Web Consortium (W3C) recommendation in 2000. Because it’s an XML language, XHTML must conform to XML standards as well as follow a prescribed set of HTML coding rules:

• XMLandXHTMLdeclarationstatementsarerequiredat the top of every XHTML page.

• Headandbodytagsaremandatory.• Everytagmustbeclosed.• Emptytagsgetaterminatingslash.• Alltagsmustbelowercase.• Attributequotesaremandatory.• Youmaynothaveformsinsideforms.

For a simple example, let’s see how the HTML in Figure 2 (which does render in a browser despite its sloppy syntax) is converted to XHTML. The first step is to add the two standard XHTML declarations to the top of the HTML (see lines 1–3 in Figure 3). Next, use one of the many XHTML tools available to assist in the conversion of the HTML. The three tools I want to mention are HTML Tidy, TagSoup, and IBM’s WDSc 7.0. That’s right—System i shops already have an XHTML utility available with WDSc.YoucaninvokeWDSc’sXHTMLtoolfromtheHTML

editor by right-clicking anywhere in the editor and selecting

“Clean up document.” When you run WDSc’s XHTML utility over the HTML in Figure 2 (after manually adding the XML and XHTML declarations) and take the default options, the tool automatically inserts required attributes and missing tags, quotes attribute values, formats the source, and lists the remaining issues in the Problems view. To remove those issues, you will still have to manually code a few other changes, such as wrapping the input tags within a div tag and moving the paragraph and list block out of the form. Figure 3 shows the resulting XHTML.

Take a look at the XML declaration and the document type declarations at the top of the XHTML in Figure 3. The first line tells editors and browsers that the content is XML. The document type statement in the second and third lines provides the specification of XML syntax required by the document— in this case, xhtml1-transi tional.dtd. The xhtml1-transitional.dtd file is a document type definition (DTD) that is basically a schema for the XHTML XML language. In other words, DTDs are essentially the DDS for XML.

There are hundreds of industry-standard DTDs, and three of them are specifically for XHMTL: Strict, Frameset, and Transitional. Most shops start with Transitional and then move to Strict after working with XHTML for a while. An XML file is considered well formed when it conforms to the standard XML syntax specifications and valid when it conforms to the specified DTD.

Why go to all this trouble when browsers are so lenient

<form name=myForm> <input type=text name=”firstName” value=fred > <br> <input type=checkbox name=male checked ><ul> <li>One <li>Two <p> paragraph text</ul>

FIgure 2 Sample HTML

<?xml version=”1.0” encoding=”UTF-8”?><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”><html xmlns=”http://www.w3.org/1999/xhtml”><head><title></title></head><body> <form name=”myForm” action=”nameOfServerProcess”> <div id=”myFormDiv”> <input type=”text” name=”firstName” value=”fred” /> <br /> <input type=”checkbox” name=”male” value=”M” checked=”checked” /> </div> </form><ul> <li>One</li> <li>Two</li></ul><p>paragraph text</p></body></html>

FIgure 3 Sample XHTML


with HTML? Perhaps the most straightforward reason to use XHTML is that it ensures greater cross-browser compat-ibility. But ultimately, the biggest advantage is preparation for the latest and future technologies. XHTML is more easily generated and parsed by languages and XML utilities, including JavaScript and XSLT. And XHTML is often used as the XML language—even though the XHTML may not be intended for direct rendering by a browser. That’s because XHTML cleanly defines display data and input forms so devices such as PDAs and cell phones can convert the XML to an optimal rendering format. In fact, because XHTML is

XML, it can be in the payload response data of SOAP-based web services. REST, the lightweight alternative to web ser-vices, can return any data format, but XML is one of REST’s most common payload formats.

Adding Style to Your PageLegacy HTML pages were written completely with rudi-mentary HTML without the benefit of supporting tech-nologies such as Cascading Style Sheets (CSS), XML, and JavaScript. Pages were stylized with tags for bold (<b>), italics (<i>), font (<font>), and nested tables. But putting look-and-feel code in your HTML creates two problems. First, rede-signing the look and feel of your website becomes so difficult that it probably won’t ever be done. Second, the HTML ends up with so much look-and-feel code that the true content is obfuscated, making maintenance unwieldy. A fundamental user-interface design principle is to separate presentation

from content. HTML should contain con-tent, and CSS should contain as much of the presentation as possible. YoucanembedCSSspecificationswithin

HTML, but it is more appropriate to place the specs in external files and reference them from the HTML. CSS is referenced in HTML with a link tag:

<link rel="stylesheet" href="acmeords.css" type="text/css" />

CSS contains curly braced code blocks with names (called selectors) that match an HTML tag, ID, or class name. For example, the CSS in Figure 4 is used by the HTML in Figure 5 to provide external styling for the page.

A huge benefit of external CSS is that developers can combine the style markup for an entire application and put that markup into several files—thus ensuring a consistent look and feel as well as drastically reducing page size. The smaller page size makes the HTML much easier to develop and maintain and reduces download times.

For example, when ESPN switched to CSS, the company saved about two terabytes

of download time a day. Another benefit of CSS is that you can identify CSS styles to use for alternative devices such as printers and PDAs. Furthermore, the CSS style of page authoring lets users set their own preferences for fonts and colors. That way, you aren’t inadvertently cutting color-blind 85-year-olds out of your target audience.

AccessibilityAnd speaking of visual impairment, one big, often overlooked consideration when designing a corporate BUI is accessibility. Consider that some users may have some degree of vision and/or

#content { width: 800px; background-color: blue; text-align: center;}h1 { color: white; font-weight: bold;}table { border: 0px; width: 100%; background-color: lightblue; }.prompt { text-align: right;}.input { text-align: left;}

FIgure 4 acmeords.css

<html><head> <title>ACME Widgets Order Entry</title> <link rel=”stylesheet” href=”acmeords.css” type=”text/css” /></head><body> <div id=”content”> <h1>Acme Widgets Order Entry</h1> <form method=”post” action=”mailto:[email protected]”> <table> <tr> <td class=”prompt”>Customer Number:</td> <td class=”input”> <input type=”text” name=”custno” maxlength=”6” width=”6” /> </td> </tr> <tr> <td class=”prompt”>-- OR --</td> </tr> <tr> <td class=”prompt”>Order number to change:</td> <td class=”input”> <input type=”text” name=”orderno” maxlength=”10” width=”10” /> </td> </tr> <tr> <td class=”prompt”> <input type=”submit” value=” Ok “ class=”submit”/> </td> </tr> </table> </form> </div></body></html>

FIgure 5 acmeords1.html


hearing impairment or be unable to use a keyboard and mouse. Also, even if your target audience consists of thirtysomethings, consider that someone with 20/20 vision may be attempting to listen to your page during his or her daily commute.

To spot accessibility issues, you can hire a person with a disability to test your site. It’s also worthwhile to actually watch a blind person navigate through your web applica-tion. Alternatively, you can use the completely text-based Lynx browser to test your app. Because Lynx will not render images, you should see text descriptions of all graphical elements of a page that would be read out loud by screen readers for the visually impaired. Youcanalsoturnoffthekeyboard and mouse and navigate solely with voice recogni-tion.Youmighthaveusersfromvariousagegroupstestyoursite as well. And be sure to take advantage of the web acces-sibility evaluation tools listed at W3C’s Web Accessibility site (see the links in Find Out More in the online version of this article at SystemiNetwork.com). Making your web pages accessible is not overly difficult. Here are some simple standards you can follow:

• Specifylabeltagsforallforminputfields.• Usestandardfieldnames(asidentifiedbyECML’sRFC

3106 at faqs.org/rfcs/rfc3106.html) so auto-complete canfillincommonlyoccurringfieldssuchasaddresses,company names, phone numbers, and email addresses.

• Addtabindexestoformstosimplifykeyboardnavigation.• Introduceskipnavigation(place“invisible”linksatthe

top of the page to jump straight to the main content) and add internal headings with judicious use of the h1–h9 headers. Assistive software enables both visually and physically impaired readers to jump through headlines.

• Inlinksandheadlines,putthemostdescriptivewordsfirstinphrases.Screenreadersallowuserstojumpfromlink to link without listening to the entire link text.

• Usethetabletag’ssummaryattributetoprovidedescrip-tions. Visually impaired users will be unable to grasp the context of a table at a glance.

•Wrapabbrandacronymtagsaroundallabbreviationsand acronyms so screen readers know when to pronounce words, or simply spell out the acronym or abbreviation.

• Convertimagesthatdisplaytext(e.g.,buttons,corporatelogos) to text. Then use CSS to specify the size, color, font, and optionally a background image. Screen readers can then pronounce the logos and buttons.

• UseCSStothefurthestextentpossible.CSSallowsusersto set personal preferences such as font size and colors that assist visual impairments.

Be sure to consider how search engine robots inter-pret your site as well. Keep in mind that robots will fol-low links and forms (with GET identified as the HTTP method) with impunity. Understand that HTML form tags have an attribute called METHOD that lets you specify that the form data is to be passed as an HTTP GET or POST. Use HTTP GET only for requests that

have no side effects. That is, the request should not cause the server to add, update, or delete an item. It’s all too easy to forget to specify forms with side effects to use the GET method. The problem is that a web robot can wreak havoc on your site if it starts chasing down destructive GET requests.

Web 2.0 and AjaxJavaScript has been used in web development since the mid-1990s. But until Ajax invigorated interest in this powerful, browser-based, client-side language, JavaScript was coded to do basic tasks such as form validation and maybe the dynamic construction of menus. Ajax sounds grandiose, but technically it’s nothing more than a simple API, called XMLHttpRequest, that allows a JavaScript function to make a request to the server. This simple API, however, lets developers build web pages that behave the same as desktop applications. Nearly everyone has heard of, and probably used, the heavily hyped Ajax application Google Maps. But I want to point out one of Google’s latest tool that was built with the benefit of Ajax—Google Docs.

Google Docs uses Ajax so that it can look and behave much like Microsoft Word, complete with spell check and formatting. Furthermore, Google Docs uses Ajax so that multiple users can work on the same document at the same time. Figure 6 shows a document in Firefox, and Figure 7 displays that same document viewed in Internet Explorer. What’s amazing is that the IE version of the document was dynamically updated with text that was typed in Firefox. I recently used Google Docs, with several other remote devel-opers, to refine a proposal as we collaboratively worked on the same document. My point is, Ajax lets you add amazing and creative features to your web application and provide what have become standard Ajax use cases.

A common Ajax use case for business is to validate input data on the fly on a field-by-field basis, without requiring the user to pass the complete page to the server and be presented with a potentially large list of validation

FIgure 6 Google Docs displaying a document typed in Firefox


errors. Because Ajax can call any web application or web service, developers can take advantage of other web appli-cations and web services to provide data such as weather information and driving directions. Although Ajax gives developers lots and lots of cool capabilities, it all boils down to a simple JavaScript call to a web application or web service.

But there’s an ugly problem in JavaScript development: the extreme complexity of managing browser incompat-ibility issues. The solution? Use one of the many JavaScript and Ajax libraries. The most popular libraries are Prototype, DojoToolkit,Yahoo!UILibrary(YUI),jQuery,andGoogleWeb Toolkit (GWT).

Prototype—a fairly small, lightweight framework—is cur-rently the most heavily used of these libraries. Essentially, Prototype extends the JavaScript language with some core Ajax utilities and features found in languages such as Ruby, Groovy, and Python. Some of the other JavaScript libraries use Prototype internally. Prototype also has a partner library, called Script.aculo.us, that provides fancy UI visual effects. Prototype is a good choice if you intend to do either some basic Ajax or some advanced JavaScript and want to use Prototype’s language extensions.ThelightweightlibraryjQueryiscomparabletoacombi-

nationofPrototypeandScript.aculo.us.However,jQueryiseasier to learn and use than Prototype and Script.aculo.us.

Dojo Toolkit is a modular, open-source library that pro-vides a comprehensive suite of JavaScript and Ajax tools. Dojo’s Dijit library, for example, is useful when you’re doing web development with languages (such as RPG and Cobol) that lack web tooling. The Dijit library includes JavaScript-based widgets comparable to those in sophisticated server-side technologies such as Grails, Ruby on Rails, and Java Server Faces. Dojo’s Java-like modular approach lets you use only those components that your application requires. Recently, the Dojo Foundation acquired some strong corporate spon-sorship from large companies like IBM.LiketheDojoToolkit,YUIisanextensiveandwell-

regarded JavaScript library. It contains libraries that handle Document Object Model (DOM) extensions, event inter-actions, animations, a host of prebuilt widgets, and more.

JavaScript development environments are not as available or fully featured as those for most other modern languages. Editors are available for WDSc and Eclipse but, as yet, the debuggers are weak. For that reason, many JavaScript devel-opers tend to test and debug from Firefox—taking advantage of the strong tooling available for Firefox with plug-ins such as Firebug and Web Developer—and then test in Internet Explorer after everything is working in Firefox.

Google Web Toolkit gets around the thorny problem of JavaScript testing and debugging by implementing the JavaScriptcodeinJava.YoucodeandtestyourAjaxroutinesin Java, but GWT generates the required JavaScript code at runtime. GWT is a good choice for shops with plenty of Java expertise.

One last point I want to make about Ajax: Don’t use it just so you can paste a label on your app saying, “Now with Ajax!”UseAjaxtoenhancetheuserexperience,improveresponsiveness, and decrease download times.

Web Services and RESTWhich server-side process is your Ajax requesting a response from? It could be a simple service that returns a text string or a snippet of HTML. Or maybe that pro-cess returns information as XML, comma delimited data, or JavaScript Object Notation (JSON, which I cover in a moment). Or it could use today’s hottest SOA strategy where business processes can be invoked across the net-work using SOAP-based web services. Because of the avail-ability of existing web services, web developers have been taking advantage of those web services with Ajax requests (see “Simplifying Web Apps with Ajax, RPG, and XSL” in Find Out More). SOAP-based web services always return payload data in XML. That XML can be either manu-ally parsed using JavaScript’s DOM API or converted into HTML using XSLT. Not a bad strategy, especially if the web service is already available. But dealing with web ser-vices quickly gets complex. Fortunately, there’s a far sim-pler approach—Representational State Transfer.

Web services use a complex protocol called SOAP to send and receive requests, but REST uses good old reliable HTTP. Web services return payload information as XML that is itself inside a more complex XML called the SOAP envelop; however, REST can return any data type, includ-ing XML, text, images, and PDFs. (Note that SOAP-based web services actually can contain any type format, but it has to be encoded as base64 and placed in XML.) And although web services require a Web Service Description Language (WSDL), REST APIs are, for the most part, self-defining. Let me explain.

Creating a REST-based web service is like forming a simplesentence.Youneedonlyaverbandanoun.InREST,nouns are resources pointed to by URLs. An example of a resource might be an order or a customer. The verbs are

FIgure 7 Viewing the document typed in Firefox in Internet Explorer


the HTTP methods to perform on a resource. The standard HTTP verbs are GET, PUT, POST, and DELETE. The fol-lowing URL would be processed differently based on whether the HTTP method was GET, PUT, POST, or DELETE:

http://widgets.com/order/123

GET responds with information about order number 123. PUT and POST create or update order number 123 (with values passed as standard HTTP request parameters), and DELETE cancels order number 123.

Implementing REST APIs, especially GET requests, can be trivial. For that reason, REST has been heavily adopted for use in web applications. In practice, REST APIs return four types of payload data: text, HTML, XML, and JSON. The text and HTML response is typically put directly into the HTML of the existing page. The XML is either parsed with DOM or converted to HTML with XSLT, but DOM and XSLTs can become complex. An elegantly simple alter-native is JSON.

JSON is a simple mechanism for retrieving complex objects from the server. A JSON response is essentially a string that contains name/value pairs. But what is interest-ing is that a JSON string is really a mini-program. Those name/value pairs are JavaScript syntax for defining objects. Consider the following JSON string:

{'no': 123, 'customer':'Big Lots', 'lineItems': [ {'line':1, 'item': 'ABC', 'quantity':2}, {'line':2, 'item': 'XYZ', 'quantity':1} ]}

When the above string is returned as the result of an Ajax request, it can be parsed with one line:

var order = eval('('+xhr.responseText+')')

The order variable is then a complex JavaScript object containing information about a specific order. The simple HTML example in the online version of this article illus-trates how information from a hard-coded JSON string (which would normally come from an Ajax request) is turned into dynamic HTML.

External forces often determine the selection of REST or SOAP-based web services. Business partners may require you do business with them via SOAP-based web services. Or your industry may have standardized WSDL documents that simplify the development and consumption of SOAP-based web services. But, without those external forces, if you want simple, fast, and easy-to-write-and-maintain web services, use REST—especially if your intended audience uses BUIs.

The Life Cycle of a Web Request It is important to understand the difference between the behavior of a web application and that of a traditional

midrange or PC-based application. When a user logs in to a green-screen or PC-based desktop application, that application maintains application context for that user. The app remembers things like items added to a queue or subfile that the user may or may not later confirm to be placed into an order. But with a BUI application, the server by default completely forgets about a user after process-ing a request. That’s because the web’s HTTP is a stateless protocol. HTTP is not like FTP or Telnet where, after you log on, user context is retained between requests. With HTTP, each browser request starts a new job on the server and, once the server delivers a response back to the brows-er, the job is terminated. To maintain application context for a user, web applications must do some extra work.

Typically, web applications use HTTP sessions to retain user context. An HTTP session is simply an indexed array whose entries contain yet another indexed array. The index to the first array is a unique key that distinctly identifies one user. The web server keeps the HTTP session in memory at all times. Each user’s session key is passed back and forth in the HTTP requests and response packets sent to and from a browser via an HTTP cookie or encoded as a request parameter. When a user request comes into the server, the session key retrieves the user-specific second-level array. Web devel-opers can store application objects in the user’s session array using a key that represents the object; typically, coders use a string that contains the name of the object (such as “order” or “cust”).

Most web application languages and technologies such as PHP, server-side Java, and Microsoft .Net provide standard mechanisms(e.g.,HTTPsession)formaintainingstate.Yetthose mechanisms still fail in a number of areas, such as the proper handling of users clicking the browser Back button, opening multiple browser sessions to the same application, and managing bookmarking. There certainly are workarounds for these issues, but it is important to look for potential side effects of using the stateless protocol of the web.

Enriching Web Applications Some amazingly creative and unique applications are rap-idly becoming available for the web. Some of these sites push the web to its extreme by using advanced graphics and interactive media. These upscale apps are referred to as Rich Internet Applications (RIA). If you want your application to push the Internet envelope, you can consider using some of the frameworks and development environments that pro-vide RIA, such as Adobe Flex, Microsoft Silverlight, Mozilla XML User Interface Language (XUL), and Sun’s JavaFX. But if you want to provide applications that make it easy for your users, customers, and clients to do business with your company, follow the standard practices for Web 2.0. ❏

Don Denoncourt ([email protected]) is a System iNEWS technical editor and a trainer, mentor, and consultant for Java, Ruby, and Grail.


Here are a few practical tips from looksoftware — i modernization specialists since 1995:

• BrowserUserInterfaces(BUI)areanimportantUIchannel, but don’t forget that modern applications need to support multiple channels such as:- rich UIs for transaction users who need features such

as “type ahead”- mobile devices, which need optimized UIs to deliver

the optimum UX (User Experience)- emerging channels such as voice, using VXML for example- Web services for SOA-based integration

• Beforeyoudiveintothelatesttechnology,considertheadvantages of a model-based approach that —- insulates you and your apps from changing technologies- can dynamically generate a great UX for multiple

channels- generates optimized code for leading browsers includ-

ing IE, Firefox, Safari, Chrome, Opera, and Mini Opera- requires no changes to your apps- allows you to continue using RPG or your language of

choice- creates new UIs for new applications

• EmergingtrendsandtechnologiessuchasRIA,AJAX,Silverlight,Google’sChrome,andWPFwillsignificantlyimpact the Browser User Experience. Understand the big picturebeforeyoucodeyourselfintoacorner!

• Don’tforgettheback-end!Creatingaserviceslayertoconnectyour i back-ends to multiple front-ends can have advantages:- Youcandeliveraccesstoyourback-endsforother

devices, applications, and platforms- Services and SOA mean minimum business disruption if

you need to change or replace your back-end applications- Creating a services layer does not require coding or

changes to your existing back-end RPG and COBOL applications

• ConnectingyourexistingRPGandCOBOLback-endstobrowserUIsisreallynotdifficult.DeliveringacompellingUX should be your goal if you are to satisfy today’s business users.

• Don’tforgetintegration!AwinningUXismorethanthe UI. Make sure your UX strategy includes support for easy integration with desktop, Web, and other back-end applications.

Tips from industry analysts

Need more information?Visit looksoftware.com to —

• Signupforlooksoftware’s free modernization newsletter• Viewvideosincluding“UImodernizationforgreen

screeners” and “Present your core i applications in Outlook, Notes and Google”

• Readwhitepapersincluding“Secretsofsuccessful modernization”

• Learnhowsnap’s connectors provide your i apps with plug ‘n’ play integration with browsers, mobile devices, Outlook, SharePoint, Notes, Google, SAP, and more

looksoftware’s UX products are used by hundreds of thou-sands of i users every day at organizations in 45 countries, includingABNAmro,adidas,Capgemini,YMCA,Merck,Volvo,Hummer,BritishAirways,QBE,LANSA,Kraft,Nestle, Toshiba, and thousands more.

If you want to deliver a compelling UX, leave the UI plumbing to looksoftware’s on-the-fly UX generators. ❏

Considering Browser User Interfaces?

[email protected]

vENdoR CoNTAC T INfoRMATIoN

“A great user experience is one of the most compelling and important characteristics of a modern business application.” Forrester Research, March 2008

“Future applications will be built with multiple UIs gen-erated from a common model.” Gartner, August 2007

“The User Experience (UX) will increasingly become a differentiator for organizations delivering service.” Gartner, August 2007

“Application vendors are under permanent pressure to offer new user interface (UI) technologies and introduce Rich Internet Applications (RIAs) instead of traditional Windows clients. Forrester Research, March 2008


“These days, most people who use a computer are accustomed to working in a Web- or Windows-type

environment,” says Carol Wright, senior programmer/analyst forinsuranceproviderUSHEALTHGroup.“Youshowthema green screen, and they perceive our technology as being less than state of the art.”

Many companies face this same problem. USHEALTH Group used Seagull Software Systems’ LegaSuite GUI (previ-ously called J Walk) to quickly and affordably modernize the look and feel of its applications without having to alter its host system. Since 1994, Seagull Software (seagullsoftware.com) has been one of the leaders in graphical user interface (GUI) modernization technology. Thousands of customers have used

LegaSuite GUI to modernize legacy business applications to be in line with today’s users and today’s business require-ments, all while preserving legacy investments.

LegaSuite GUI makes it easy for developers on all types of legacy systems, including System i (iSeries/AS400), System z and VME mainframes, and OpenVMS, to create Web- or browser-based applications. With LegaSuite GUI, companies can enhance the functionality of their green-screen business applications and improve training time and customer service by creating up-to-date, user-friendly applications based on the information in their underlying legacy systems. Since LegaSuite GUI is non-invasive and works without changing host applications or legacy code, a new user interface can be deployed in a fraction of the time versus other methods.

The solution includes LegaSuite GUI Builder, a power-ful visual development toolkit, and LegaSuite GUI Server and LegaSuite Client Access License (CAL), a runtime server engine and client software that offer multiple deployment methods to serve Windows, Java, and HTML-based end-user devices. One of LegaSuite’s most popular features is its “collector” technology, which automatically compiles a repository of underlying host screens. This automates and accelerates project time, development, and maintenance by automatically recognizing and synchroniz-

ing changes to the underlying green screen with the GUI application tied to it.

Companies can also enhance their GUI in a myriad of ways; they can combine information from multiple green screens, call Web services, add newer functionality such as pop-up calendars, and integrate with desktop applications such as Microsoft Office and Lotus Notes. USHEALTH was able to create a GUI complete with colors, push buttons, drop-down menus, and tabs that dramatically improved data entry and application workflow. “The GUI is the type of environment that [users are] used to. They just whiz through it,” Wright says. By deploying LegaSuite GUI, USHEALTH has simplified its applica-tions, reduced training requirements, and minimized net-work administration.

American General Finance, one of the largest consumer finance companies in the U.S., has been another satis-fied LegaSuite GUI customer for several years. American General Finance used LegaSuite to provide streamlined, integrated, graphical access to its business-critical loan processing applications. “Seagull Software has helped our frontline personnel to be more efficient and effective by creating an environment where people learn the applica-tion more quickly and can provide better service to our customers,” says Jerry Gilpin, senior vice president of information system for American General Finance. “With Seagull Software, our applications yield a lower total cost of ownership through operational efficiencies, central man-agement of software updates, and reduced training costs.” In addition, Seagull Software’s Professional Services orga-nization helped American General Finance achieve results quickly and has continued to support the company’s needs after deployment. “I’d give them an A+ rating for the cus-tomer experience,” Gilpin adds.

LegaSuite GUI is the tool your developers need to give your users the interface and ease of use they expect from your company’s applications while preserving the valuable business logic and reliability behind them. ❏

Modernize Your Legacy Systems

with Seagull Software’s LegaSuite GUI

Seagull Software Systems, [email protected]

vENdoR CoNTAC T INfoRMATIoN

LegaSuite GUI makes it easy for developers

on all types of legacy systems to create Web-

or browser-based applications.

Documents

BUI_SpecialRpt