Visual Interfaces:  SVG

by Kurt Cagle

Designing Interfaces

On Changing the World

Be Forewarned!

The Internet is changing the way that we think about applications -- and XML and XSLT are the key. With XML, you can represent any information in a common data grammar. With XSLT, you can convert that information into any other form that can consume XML. The next generation of Internet tools will actually use XML to drive the appearance and behavior of applications, and will punch the two dimensional desktop world into a multidimensional multimedia universe.

Problems with the PARC GUI

The interface that forms the foundations for Macintosh, Windows, Gnome, and practically every other "desktop" metaphor was originally developed thirty years ago at Xerox Palo Alto Research Center (PARC), and while it has proven a powerful (and almost universally recognized) way of organizing resources, the Internet is raising the question about whether this interface does in fact address the future of computing. Specifically,
• Uniform Interfaces Promote Monopolies - Uniform interfaces are useful at providing commonality of applications, so that people can generally assume that certain features will be consistent between applications. However, this also encourages a one size fits all approach to creating interfaces, dictated largely by the OS manufacturers.
• Application-Centric, Not Document-Centric - The PARC interface places the emphasis on applications rather than documents, and while designs in recent years have changed this somewhat, for the most part PARC interfaces are still geared toward applications working against proprietary (non-interchangeable) document formats.
• State Oriented - PARC interfaces tend to encourage stateful designs, which, while easier to write, also place more demands upon the environment. As a consequence, applications become more memory intensive, create large libraries of seldom used DLLs and other extensions, and take up more storage space.
• Upgrade Spiral - the desktop metaphor encourages a cycle of incremental upgrades to improve performance of a product, to increase its responsiveness to the consumer, but most of all to make money for the producer. Yet this only works in am immature market. In most categories, software has become mature, and the costs of upgrading (purchase costs, hardware upgrades, retraining, deployment) is giving diminishing returns.
• Monolithic - PARC type applications are monolithic -- while there is some code reuse, most applications are designed to be stand-alone; this makes interoperability a difficult proposition to build, and requires complex plumbing infrastructure to make it happen.

The Web Paradigm 1: HTML

The 1990s saw the rise of the Internet and the first phase of the Web Paradigm. While seemingly simple, the concept of most web browsers is fairly profound -- rather than using a static interface to work with dynamic information, you let the information define the interface for you. The web browser program is of secondary importance to what happens within it. The hallmarks of this paradigm are quite pronounced:
• Hyperlinked Content - The simple link turns the bounded space of most applications into unbounded interconnections. This makes it possible to build applications be proxy, making the manipulation of information more readily oriented around content than medium.
• Simplicity - My seven year old daughter can create a web page that does "something". She would be unable to create even the simplest useful Visual Basic application. Is the fault here my daughter's understanding, or is it that most programming languages are still too complex?
• Universality - Despite the intentions of browser manufacturers to the contrary, you can still put together a decent web page that works well in any browser, on any platform.
• Statelessness - Retaining state information in a web environment is more complex, which provides an incentive to avoid maintaining state information whenever possible. While most applications need some state management, by raising the cost of integrating state you reduce the amount of state that is maintained gratuitously.

So What Is the Problem?

If the Web Paradigm mode is so superior, then why is it so expensive and difficult to build good web applications?
• Server Side Procedural Code - Procedural code tends to freeze in place -- because the mechanism for server side code reuse is limited (and tends to be shallow) most server side code is written once (hastily) then patched, making for ever more fragile applications.
• Maintainability - It is far more difficult to update HTML code on a consistent basis than it is to write it in the first place, and most of the tools that are extant don't facilitate this dynamic need terribly well.
• Overtight Coupling - HTML output is often embedded in server code, making it more difficult to separate the design and implementation of web pages. This means that often times it is your programmer who is designing the visual look and feel of your website, with the graphic designer serving less effectively as an visual editor.
• Inflexibility - Variations exist in different browsers (and different users). JavaScript and CSS, originally designed to provide vendor neutral interactivity on the web pages, often locks a user into a given proprietary version of HTML and Document Object Model on a specific browser.
• Limited Reusability - HTML itself is a formatting language, and as such contains very little context about the information being presented. This translates into the limited ability to reuse this code, especially in different formats.

The Web Paradigm 2: XML/XSLT

The emerging web paradigm takes advantage of the capabilities of XML and XSLT to develop richer, stream based systems.
• XML As Intermediation Language. XML was originally seen as a client side solution for building contextually rich web pages, but its use as a server side data intermediation language has shifted the balance toward a lighter client and more robust server implementation.
• Use of XSLT and XML formats. XSLT in particular has the potential to shift the momentum from HTML to XML by providing a language to transform XML into any other XML format, including XHTML, 3DML, SVG, WML, or any other XML based language.
• Rich Server/Healthy Client. Both because of XSLT deployment issues and a historical trend toward lighter clients, most of this development in the short term will be server based.

XSLT and the New Web

The number of people working with the Extensible Stylesheet Language (XSLT) is still relatively small, but already the language is making a difference. XSLT is a declarative, recursive, pattern-oriented language designed to specifically work with XML. This in turn has some significant implications for interface design:
• Stateless. An XSLT transformation acts upon an entire XML document at one time to produce a resulting stream of data. If the XML is thought of as being a representation of state, then the transformation acting on the document is effectively stateless.
• Dynamically Configurable. XSLT transformations are driven by data, and as such can configure the output dynamically based upon the content of the data.
• Targetable. Because the output of XSLT is most likely XML, the output can be targeted to specific browers and other user agents. This means that the client can be anything, running on any platform -- by maintaining the state through the transmission of XML, the reliance on complex capabilities in the client is minimized.
• Non-Proprietary Media. There are XML representations of different types of media formats, and XSLT can also generate links into "non-proprietary" media. This in turn dramatically diminishes the need for expensive compilers, installation programs, or nightmarish deployments.

XML Media Formats

There are a number of different media formats that can be represented in XML.
• XHTML. An XML restatement of the HTML language, XHTML is a very well known media substrate, and will likely be the foundation of GUI interfaces for quite some time to come.
• CSS. Though not an XML language per se, CSS can be used with XML to produce very sophisticated output on most fifth generation browsers.
• SVG. The Scalable Vector Graphics Language is useful for generating 2D graphics using XML. It is becoming more widely deployed, though it is not supported yet by Internet Explorer. SVG also formalizes CSS as a media description language in XML.
• VML. The Vector Markup Language was one of two antecedents to SVG. It is currently deployed on the IE5.x browsers only.
• SMIL. The Synchronized Multimedia Interface Language provides a timing mechanism for animation.
• XSL-FO. The XSL Formatting Objects specification will let you handle precise page layout of contents, and will likely be significant in the paper publishing industry in the future.
• VoxML. This set of XML recommendations control voice telephony and the production of synthesized speech.
• RDF. The Resource Description Format is an XML language for describing the content of other media content, and is used principle to manage such media.

How Solid is XML/XSLT for Interfaces?

The XML world has evolved considerably in the last few years, and already developers are beginning to employ XSLT regularly as a tool for generating content. However, there are still significant roadblocks (or opportunities) before an XSLT based interface system can be truly universal.
• Lack of Browser Support. Most browsers are currently about a year or more behind implementing XHTML and the other standards, although 95% of XHTML can parse safely in a traditional HTML browser.
• XSLT deployment on the Client. IE currently ships the older XSL implementation on the client, although you can download the beta MSXML parser that incorporates XSLT support.
• Slow SVG Acceptance. SVG is supported currently only in the Mozilla 6.0 beta, although Adobe has an SVG plug-in that can display content from a dedicated SVG file (though not yet as part of an HTML output).
• Non-conformant CSS. There are several serious discrepancies between the version of CSS implemented by Microsoft and by other companies that make using CSS difficult. Few browsers support CSS 2.0 and above.
• Evolving Standards. Many standards, such as XSL-FO or VoxML, are still very much in flux, and user agent manufacturers are loathe to implement browsers that support a moving standard.

SVG

The Problem with Bitmaps

Almost all of the graphics that exist on the Internet are raster based bitmaps -- they use pixels that are either assigned specific colors from a lookup table or each pixel assumes a value based upon the intensity of three color guns (Red, Green, Blue). While such graphics are useful for photographic representations, they have a number of drawbacks:
• Bandwidth Intensive. Even with optimization and compression, graphic files are typically bandwidth intensive, making them less than ideal for more sophisticated interfaces.
• Non-Scalable. Bitmap graphics have only one optimal set of dimensions. Increasing or decreasing the graphics reduces the fidelity of the initial image. Moreover, artifacts may be introduced due to resizing algorithms.
• Context Poor. You cannot tell from most graphic file the content of that file without some explicit helper document.
• Irreducible. While you can retrieve a rectangular bounded subset of a bitmap graphic, you can't grab contextual pieces of the image.

Vector Graphics

Vector graphics represent graphical information as a series of mathematical entities that either build paths, fill the interior regions of those paths or describe some characteristic of either paths or fills. Proprietary vector graphic programs and formats include Adobe Illustrator (Postscript), Macromedia Freehand (Postscript) and Flash (Proprietary, though released last year as an open format), Microsoft Windows Metafile Format (WMF), and True Type Fonts. The principle advantages of vector graphics include:
• Compact. Graphical images (as opposed to photographic ones) can usually be expressed far more concisely using vector graphics than they can with raster formats.
• Scalable. You can scale a vector graphic to any magnification and not lose resolution. One benefit to this is that a vector graphic representation can be scaled into a map or similar resource and "zoomed" into or out of.
• Context Rich. Because vector graphics are typically text based, it is possible to not only place descriptive information about specific sections but also to uniquely identify subcomponents of an image.
• Reducible. In light of this, it is usually possible to decompose a vector graphic into component pieces of the image without pixel by pixel whiting out of the image.

Why Not Shockwave Flash?

For the most part, nothing. Macromedia Shockwave Flash is a very good product, and has added a significant amount of cross browser interactivity onto the Internet. However, from the standpoint of XML, Shockwave does have some limitations as a vector presentation medium?
• Not XML Based. An XML parser can't work with the contents of a Shockwave document, and even a browser must work through a fairly narrow interface.
• Proprietary. The format is owned by Macromedia, although it should be noted that the specifications for Flash were made public a year ago.
• Context Poor. Shockwave content is all too frequently invisible to search engines, making it less than ideal for the presentation of indexable content. Note: This is not meant to be critical of Macromedia. They have been very much involved with the W3C graphics standards group, and were a major architect of VML, one of the two SVG predecessors.

So What Is SVG?

This is: 

(Austin Map courtesy of IBM)

So What Is SVG (2)?

So is this:

(Chart courtesy of IBM)

So What Is SVG (3)?

And this:

(Source courtesy of IBM)

The Elements of SVG

The Structure of SVG

All SVG documents are contained in an <svg>, which acts as the document root. This root in turn contains one or more elements which provide specific graphical contexts -- default characteristics for all other elements contained within the group. For example, the <descr> and <g> elements provide description for the <svg> element and group subordinate elements respectively.
<svg width="4in" height="3in">
<desc>Two groups, each of two rectangles </desc>
<g style="fill:red">
<rect x="100" y="100" width="100" height="100" />
<rect x="300" y="100" width="100" height="100" />
</g>
<g style="fill:blue">
<rect x="100" y="300" width="100" height="100" />
<rect x="300" y="300" width="100" height="100" />
</g>
</svg>

The Structure of SVG (output)

The output for this is straightforward, if not terribly exciting:

Coordinates

Coordinates are given relative to the upper left hand corner, which unless explicitly changed is assumed to be at 0,0. SVG uses the same coordinate systems as CSS does, so you can specify coordinates in pixels (the default), inches (in), centiments (cm), points (pt), ems (em), and so forth. It also recognizes the same attributes for most elements:
• x. The horizontal origin location, which defaults to 0.
• y. The vertical origin location, which defaults to 0.
• width. The width of the item in question (from left to right on the screen or page).
• height. The height of the item in question (from top to bottom on the screen or page).Note that when an explicit coordinate change is made, that change remains in force within the scope of the change.

SVG and CSS

Cascading Stylesheets are an integral part of CSS. You can use CSS attributes that are common to HTML to style the characteristics of text, paths, fills, and other SVG resources. Beyond the HTML characteristics, you also have a few other CSS styles that are added to SVG:
• fill. This sets the fill color, either as a named color (such as 'blue') or as a hexadecimal color representation of the form #RRGGBB.
• fill-opacity. Sets the opacity of the fill, from 0 (completely transparent) to 1 (completely opaque).
• stroke. Sets the stroke color, either as a named color or as a hexadecimal color representation.
• stroke-width. Sets the width of the stroke of a given path or shape.Stroke, in particular, has a number of other options to control everything from the dash patter for broken lines to the miter length.

Shapes

SVG includes a number of standard shapes that can be set or manipulated as need be.
• rect. Specify the origin and the width and height attributes to define the rectangle. You can also create rounded rectangles with the rx and ry attributes.
• circle. Specify the center of the circle and the radius. to define the circle.
• ellipse. Specify the center of the ellipse and the lengths of the radial half axes.

Polygons

While these few shape primitives can handle basic graphics, in many cases you will need to define your own paths. SVG includes three shape elements, path, polyline and polygon, for defining custom shapes and paths.
• polyline. Creates a shape made up of connected points. Such a line is considered open (it has no associated fill). The values
• polygon. Creates a shape made up of connected points. Such a shape is considered closed (it can be filled).

Polygons (2)

Polygon paths are specified by giving the coordinates of the polygon in space separated pairs of comma-separated x,y coordinates. Example stars1 - star and hexagon

Polygons (3)

This produces the following output: 

Paths

The <path> element lets you define a specific path that can be stored for other operations or rendered directly. The path element is a primitive that defines all of the system shapes and polyline/polygon elements. The path element in turn is made up of a number of single letter operations.
• Move To (M). This moves the drawing cursor to the position indicated without drawing any path. If given as upper case, the move is absolute, lower case is relative to the current position.
• Line To (L). This moves the drawing cursor to the position indicated, drawing a line in between. If given as upper case, the move is absolute, lower case is relative to the current position.
• Terminate (z). This terminates the path and draws a line to the most recent starting point.
• Cubic Bezier (C). This takes three points and draws the cubic bezier between those points.
• Smooth Curve (S). Draws a cubic bezier that takes into account the curvature of the previous point in the path, giving a smoother result than a traditional cubic bezier.
• Quadratic Bezier (Q). This takes four points and draws the quadratic bezier between those points.
• Quadratic Smooth Curve (T). Draws a quadratic bezier that takes into account the curvature of the previous point in the path, giving a smoother result than a traditional quadratic bezier.
• Arc Curve (A). Draws an elliptical arc between the indicated control points.

Paths (2)

The use of cubic and quadratic curves can make for very complex and sophisticated paths in your SVG document. For instance, the following is a quadratic path that loops back upon itself.

Paths (3)

This produces the following:

Text

Perhaps one of the most important aspects of SVG is its ability to work with XML-based text. You can display SVG text using the same attributes and characteristics that you use for displaying text in HTML.
• Text is Graphics. Text elements are treated as being the same as graphic elements -- the boundaries of a text element is a path, and a text element can serve as a mask for fills or graphics.
• Not HTML. The content of an SVG text element cannot be HTML. This means that you need to make sure when passing information into SVG that is made up of structured content that it gets flattened prior to rendering.
• Unicode. Because the text is XML based, it is implicitly Unicode, making it possible to draw any kind of text in SVG, not just ASCII characters.
• tspan Use the <tspan> tag to break up individual elements of text as separate units. Note that text is positional, and doesn't contain any explicit line wraps.

Animation and Interactivity

Animation

There are essentially two types of animation within SVG. Non-interactive animation (covered here) uses XML elements exclusively to create the elements, and such animations are essentially part of the state of the SVG document. There are a number of different types of animations.
• CSS Animation. You can animate CSS properties of the containing element by using <animate attributeName="css_attribute" from="a" to="b" dur="time"/>. This can be used to do such things as change the values of specific attributes over the given time. As an example, you can cause the opacity of a fill element to increase and decrease over time.
• Transformational Animation. You can perform a transformation (translation, rotation, scaling) on a container element using the <animateTransform> method.
• Motion (Path) Animation. The tag <animateMotion> moves a specific pre-defined shape along a path over a given period of time. You can also define keypoints for movements that actions that move through various keyframes over time.
• Color Animation. The tag <animateColor> lets you cahnge the color of an element over time.
• Scheduled Animation. The tag <set> lets you set a SVG attribute to a specific value at a certain time for a given duration.

Scripting and Interactivity

In order to move SVG beyond the scope of visual renderer and into playing an integral part in the development of interfaces, it is necessary that SVG incorporates some form of scripting and event handling. This has been built into the language from the beginning, and has a number of different components:
• Links. SVG lets you define a link using the A (anchor) tag in the same way that XHTML links. This provides a basic level of page to page interactivity that makes server side SVG development more possible.
• SVG Document Object Model. As with the HTML and XML document object models, SVG can express the elements of an SVG document as a set of concentric objects. This object model can be accessed via traditional programming languages.
• ECMAScript Binding. ECMAScript, the formal successor to Javascript, is specifically bound to SVG through the use of <script> blocks. This lets you create blocks of EcmaScript handlers and intermediate state code, extending a static representation into a dynamic, interactive one.
• Event Handling. Most user interfaces are intimately tied to event handling models. SVG recognizes both mouse and keyboard events as native event types, as well as loading and unloading states, and event handlers can be written either using EcmaScript binding or through the use of a language like Java.
• Extensibility. Because SVG is an XML format, you can integrate other namespaces into the language, effectively extending the language to handle such technologies as XHTML. Similarly, SVG can theoretically be embedded within XHTML, although that is predicated upon a user agent (browser) that can handle both formats.

Linked Interactivity

The most basic form of interactivity (and one that fits best with the pure XML model) is through the simple use of the <a>. This lets you establish links (either simple or more complex, depending upon the degree to which you use XLink) that can contain reference information back to the server to provide more SVG content. 

Example text1 - Text in user space SVG and XML¥

Linked Interactivity (2)

Scripting

Scripted output, on the other hand, is more complex, letting you modify the contents of elements dynamically within the frame on the client. The DOM, which basically extends the XML DOM to take into account the graphics characteristics of the document, lets you do such things as altering text on the basis of either animated elements or event handlers, changing CSS attributes, and even adding or deleting elements. Example text1 - Text in user space Move Over Me

Scripting (2)

SVG, XSLT, and the Real World

Integrated Applications

As mentioned earlier, SVG is still very much in its infancy, which affects what you can do with it. Before designing with SVG, you need to know the state of affairs with the language:
• Plugin Support. This presentation was done with the Adobe SVG plugin (a beta of which is available from http://www.adobe.com). While not 100% compliant, it supports enough of the SVG specification to be useful. The examples given here were done using the IFRAME element of Internet Explorer to display the SVG.
• Browser Support. Currently no web browsers explicitly support SVG, although the Mozilla 6.0 Browser is slated to do so.
• image/svg-xml. To generate SVG output from a server side application, the accepted mime-type is image/svg-xml.
• Server Support. While in many cases the SVG will already exist as a distinct document, SVG gains considerable flexibility when it is generated from an existing data stream.

SVG and XSLT

As with so much of XML, SVG blurs the distinction between defined content and dynamic content. You can use XSLT to generate SVG in a number of ways, as explored here:
• Integrative SVG. Here, the XSLT acts principally as a mechanism to join multiple pre-existing SVG primitives together into a generalized shell, probably through the document() function. This is most useful when attempting to create SVG pieces from components.
• Generated SVG. In this case, the SVG is created by a transformation from some existing data. Charts and graphs are the most obvious example of generated SVG, but in a sufficient complex SVG user interface one could envision whole Graphical User Interfaces.
• Embedded SVG. In this case, the SVG content is referenced as part of a document that is possibly in a different namespace, and the XSLT uses information in the document call to either build or retrieve the SVG data.
• SVG Applications. This uses distinct pages of SVG in conjunction with pages of other XML based page types (such as XHTML) through links and a server capable of producing the appropriate structured output.

Where will SVG be tomorrow?

While it still may be a year or more before SVG comes into its own, the applications for the language are profound.
• Graphical User Interfaces. XHTML has a number of serious limitations as the foundation for GUIs. SVG, especially once integrated into the XHTML fabric, could dramatically reduce the download requirements that would be needed to make net based GUIs viable.
• Data Visualization. Especially when coupled with an XML streaming mechanism on the client (such as XMLHTTP) SVG could be used for real time data visualization for everything from systems control panels to stock market analysers.
• Games. Game environments typically rely on a mixture between a two dimensional user interface and a two or three dimensional sprite engine. SVG could be used in conjunction with efforts like 3DML to create fully integrated game systems.
• Visual Tools and IDEs. Drag and drop integrated development environments, flow tools, schedulers, and similar interfaces could be created through more powerful browsers coupled with SVG.
• Animation. Vector graphics lend themselves to animation (as evidenced by Shockwave Flash), both because of their low bandwidth requirements and because clean-edged graphics are favored in animation media. As the tools develop you can expect to see SVG based entertainment.