Building Graphical Displays for the Desktop and Web

• View ILOG JViews On-demand Presentations
• Download a trial version of ILOG JViews visual components: Diagrams, Charts and Map

Introduction

We often hear contradictory opinions from CIOs. Some say it’s all about middleware, meaning integration, business logic and Web services. Others insist that functionality is dead, meaning that end users care less about how a program works than about its ease of use, productivity and reliability. Rich graphical user interface (GUI) techniques fall squarely within the second category. They allow developers to create user-friendly interfaces and implement complex operations in a highly visual and interactive way. The underlying message to software engineers is that they should concentrate on how features are presented to the end user and not on creating complex and cumbersome programs that nobody wants to use.

However, it is well known in the engineering community that interfaces always take much longer to develop than initially planned. Furthermore, problems become even more prevalent when an application has to be delivered on different platforms. A common example is the application that has to run on both desktop computers and the Web. How should the problem be addressed? Should developers write two different applications, using completely different tools and techniques? Is there anything that can be shared between the versions of the application to save time on both development and maintenance? This article presents approaches for quickly creating and delivering the right rich interface for any given platform.

When we look at user interfaces, we generally make a clear distinction between interactive forms and graphical displays. Forms are well covered by all development environments, mainly because menus, buttons, text fields and other GUI gadgets are natively supported by the platform. It is definitely not the case for rich graphical displays simply because platforms only offer low level application programming interfaces (APIs) with drawing routines and basic event handling. This is why Open Source and commercial packages have been created to give developers concrete services and the right level of abstraction for delivering visual services to their users.

The Right Type of Display

User interfaces are used to display information or enter data. With the help of human-factor experts or a study of similar applications on the market, a team of developers can determine which type of visual representation best suits their application. They can also decide to create a new way to interact with data by making a different innovative interface. No matter the case, the application needs to include well-defined displays. The following sections describe some of the commonly used graphical representations.

• Specific visual standard – A dedicated look and feel is important for helping the user feel comfortable with manipulating data. For example, diagrams need to comply with unified modeling language (UML) or business process modeling notation (BPMN) standards, and include very precise entities, icons, links and annotations. This is especially important with network displays, which require standard icons, decorations and color schemes to help managers understand and operate their infrastructures.
• Editing capabilities – Diagrams are used for visualization and modeling purposes. Both require different services, and editors and modelers should offer palettes, creation tools, connection services and ways to synchronize visual information with the application’s underlying business objects.
• Ability to create diagrams automatically – In most cases, the diagram’s structure is pulled from a repository that delivers purely symbolic information. The interface needs to create the graphical entities and perform automatic placement to make the information readable, understandable and relevant for the end user. This part requires complex layout algorithms for displaying the entities and connections.
• Dynamic behavior – Diagrams are not static. They are used to browse a system and need to be dynamically synchronized with the underlying objects they represent. When they are used to display the state of a system, changes in the business objects should be reflected by the graphical interface.

Figure 1: A network topology with specialized elements and automatic hierarchical layout

Charts

Charts are very popular for monitoring operations and analyzing data in every type of business. Whenever we have a list of static or live data, a chart is the obvious way to visualize the information. The following services are needed for charting:

• Display relevant information with minimal data conversion – Charts range from the very simple X/Y versions to complex tree maps, timetables, Gantts, polar and radar, and 2D and 3D charts. This broad range is needed to accurately represent data with minimal conversion.
• Performance – When displaying large series, long-term historical values or fast events, performance becomes an important issue.
• Customizability – End users typically want to tweak chart parameters at runtime. These parameters can include the axes, type of chart, color scheme and legend. In addition, their preferences should be saved for future use.

Figure 2: Typical examples of charts: stock charts, 2D/3D bars and pies, and tree maps

Dashboard and Monitoring Panels

Dashboard and monitoring panels are important in business situations that require realistic or symbolic displays for detecting and solving problems. These displays are often referred to as business dashboards in the business intelligence domain. They help operational people oversee the key performance indicators (KPIs) of business processes. KPIs are often displayed in simple graphic objects, such as gauges and charts, to make it easier for the end user to understand them. At the back end, the business dashboard can be connected to a variety of systems that provide metrics for throughput, quality and performance. Ideally, managers interact with the dashboard to get more information or adjust resources on the fly.

Figure 3: Realistic dashboard

Users in industrial domains refer to these displays as industrial schematics and process control or supervisory control and data acquisition (SCADA) applications. These applications are used to show the current status of physical equipment such as machines, tanks, production processes and transport pipelines. For example, a background drawing can be made with either a floor plan or a drawing imported from a CAD tool. Graphic objects – gauges, dials, meters, state objects, etc. – are laid over the background to display information from physical equipment. This type of display requires a connection between a real-time data repository and the graphic objects on the dashboard.

These displays need services that include:

• Ability to mimic reality – Panel and dashboards should be capable of showing information in appropriate and aesthetic ways. For business users, graphical quality is a must, while industrial users need the ability to correctly mimic a factory, plant or process.
• Extensibility – The system should be extendible and generic enough to accommodate new panels or dashboards that are designed, stored and deployed without modifying the application.
• Flexible data binding – In this scenario, there is a clean separation between the system being monitored and the way the information is shown to the user. The link between both parts has to rely on a flexible data connection that is generic enough to make the system extendible.

Map Displays

Map displays are becoming increasingly pervasive, thanks to GPS systems and the popularity of Google Maps, Google Earth and Microsoft VirtualEarth. In business, maps are very useful for showing and managing all kinds of georeferenced assets in logistics, road and air traffic systems, defense applications and network management. Common to all of these is the placement of symbols over a custom map and their synchronization with domain-specific data or information computed by the system. Map displays must:

• Show maps – Free online tools give the impression that maps are widely available, cheap and easy to integrate. This is completely wrong. Good maps are expensive and redistribution rights are very restrictive. Decent cheap maps are only available for low-precision data and a few countries, such as the United States.
• Handle map size – Map viewers allow users to view large areas and zoom in for greater detail. But for satellite images and road maps, which are typically extremely large, a way must be provided to manage their size without sacrificing detail.
• Science and industry behind digital maps – There are standard practices for digital mapping, including coordinate systems, projections, map formats, labeling and geocodiing (converting a street address to longitude and latitude coordinates). Developers must apply these standards, and at the same time, hide the complexity behind digital mapping from the end users, so they only see the information they need.

Figure 4: Examples of maps for network management (left) and synchronized 2D and 3D maps (right)

Targeting the Right Platforms

Once the combination of visual displays has been determined, the second step is to think about development techniques and deployment options. Some applications only have to operate on a single type of client, such as a desktop computer or Web environment. But it is becoming increasingly common to deliver the same application as a rich client for power users and over the Web for remote users. Another common occurrence is for a desktop application to become so popular that a Web version has to be created to support a wider group of users. In both cases, it is important to anticipate and consider an environment covering multiple platforms and deployment options. If the Java platform is today’s best candidate for portable rich and Web applications, dual support requires deeper analysis. For example, the Eclipse Rich Client Platform (RCP) offers a very good framework for writing rich desktop applications using SWT, GEF and other graphical layers, and there are tools, such as Eclipse ATF, for building Web/Ajax clients. But dual desktop and Web deployment still requires two different code bases, and applets are hardly possible and definitely not recommended.

Other factors putting pressure on developers are Ajax, the Rich Internet Application (RIA), and Web 2.0, the next generation of the Internet. Demand is growing fast for them, as they enable popular websites to deliver desktop-like performance.

Figure 5: The same application manipulating the same business process diagram; deployed as a rich client (left) and a Web/Ajax interface (right)

More Design Tools, Less Coding

There are two interesting options for delivering rich visual applications that can be deployed to multiple targets. The first consists of minimizing the amount of code written. For example, if the interface is primarily based on descriptive reusable content, the task to finalize the application for a given platform is drastically reduced. The other option is to use a model-driven architecture to automate the creation of user interfaces directly from data models. This very systematic approach is particularly suitable for data-centric applications. These techniques require a set of portable visual components that can deliver graphical content on multiple platform targets, and design tools that create reusable visual entities and the specifications for displays driven by underlying data. The importance of design tools goes beyond the need to reduce the coding part of an application, and offers an opportunity to provide different tools for the different roles in the development chain, and eventually create new ones. For example, a graphics designer can provide attractive content for a user interface without necessarily being involved in technical development. Also, an application administrator can enrich the application without modifying the core of the system.

For the Java platform, the ILOG JViews 8.1 product suite offers dedicated portable components for diagrams, dashboards, charts and maps. The components include a set of design tools that simplify the development process and minimize the amount of code to write. Development time is spent primarily on creating descriptive content, and the coding part is limited to final integration and data management. At runtime, different families of components, including Swing and Eclipse, support the rich clients, but particular focus has been placed on the Web aspects. There are dedicated JavaServer Faces (JSP/JSF [1]) components that can reside on a Web server and generate an interface for a browser. By mixing images and JavaScript/DHTML code, the components deliver content for either traditional Web pages or portals that implement the JSR 168 standard (cf [2] and [3]). They are also able to deal with asynchronous requests that manage Ajax behavior and minimize page refreshes.

Defining the Symbology

The starting point for most interfaces is the symbology, a set of symbols that defines the look and feel of the graphical entities to be manipulated. A symbol is a self-contained graphic object that represents a physical or conceptual element in the underlying application. For example, symbols can represent trucks, factories, network elements, dials or gauges. They have built-in behavior and an exposed interface, such as a graphic JavaBean, widget or control. ILOG JViews 8.1 offers the Symbol Editor, an interactive editor that creates, edits and organizes the intelligent symbols that populate a user interface. It provides graphics editing capabilities, and is interoperable with authoring tools such as Adobe Illustrator and Inkscape to ensure the visual elements of the symbol are as appealing as possible. It then adds dynamics to these static graphics with rules describing how the elements of the symbol will react to data changes. For example, rules can define the alarm conditions that will cause part of a factory symbol to blink, or how far a needle on a rotary gauge will rotate. The newly created symbol can then be organized in palettes and reused by the other design tools.

Figure 6: Transforming a drawing created in SVG with Inkscape (left) into an active symbol (right)

A symbol and its behavior are not defined with code. Their definition is provided in a Cascading Style Sheet (CSS), which gives the JavaBeans to use, their settings and logic. The code fragment below illustrates a situation where Java code can be replaced with a CSS equivalent. Instead of creating a needle by code (the graphic object being a polyline), an interactive design tool can keep track of the configuration of a JavaBean and make it persistent in the following form:

Model-driven Interfaces

Designer for ILOG JViews Diagrammer is an interactive editor for specifying different aspects of a diagram. It is used to define the look and feel of applications that must automatically create a diagram, such as a business process, network typology, workflow, dataflow or entity-relational diagram, from a data source. It creates a display by binding the data source elements with the graphical symbols created by the Symbol Editor. For example, it is possible to specify that a given type of data instance should be represented by a given symbol, and that a particular value of a field should input some symbol parameters to alter its aspect. The specification of how the visual elements are controlled by the data model is done at a high level because the symbols already contain their particular visual logic. Other aspects of the display, such as automatic graph layout options, the appearance of links, background images, aspects of subgraphs and the zooming policy, can also be tuned.

As for symbol definition, the association between the data model and the visual entities can be described with CSS directives.

For example, below is the generic CSS definition of a node used by a diagram:

The example below illustrates a CSS directive that specifies the default node when the state field of the instance is equal to busy:

The end result is made of descriptive CSS and XML files that can be loaded into the application at runtime. The engine is then able to match the specified data source and apply the logic defined in CSS. The project’s individual elements can be accessed through dedicated Java classes, allowing the look or behavior of the display to be customized further. For rich desktop clients, the container is a Swing component; for Web clients, a JSP/JSF server-side component; and for Eclipse, a SWT component.

Building Monitoring Panels

The third design tool in ILOG JViews 8.1 is the Dashboard Editor, an interface for creating industrial panels, business dashboards and other generic human-machine interfaces. It allows users to manually place symbols created with the Symbol Editor on top of a static background. Symbol parameters can be associated with application data at design time through traditional loose coupling techniques. For example, it is possible to specify that the value of a gauge is linked to a variable of the application or a given field in a database. This association is resolved at runtime when connecting to the actual data source.

Figure 7: Editing different types of monitoring displays: business (left) and industrial monitoring (right)

The resulting dashboard or schematic is an XML file associated with palettes of symbols that can be loaded into one of the application's windows and then fed with real-time data. Here again, for integration with the final application, rich desktop clients use a Swing container; Web/Ajax clients, a JSP/JSF server-side component; and Eclipse, a SWT component.

Conclusion

By generalizing the usual software component approach and systematically adding design tools and descriptive content, the ILOG JViews 8.1 products address a large number of visual requirements and deployment to multiple targets. With more precise roles in the development chain, new perspectives are also drawn. For example, applications can be enriched by creating new content that is dynamically loaded without modifying the code base. Another interesting aspect is the ability to reuse graphical content, such as visual symbols or look and feel definitions, from one application to another independently from code. In the end, developers have more freedom to build and deliver interactive applications that end users will enjoy using.

References

• [1] JSF 1.2 Specification
• [2] Portlet Specification
• [3] JSF Portlet Bridge Reference Implementation