In the 1981 documentary “Vernon, Florida” by Errol Morris, there is the following joke…

Two sailors are looking out at the ocean. First sailor says, “That’s a lot of water out there.” The second sailor responds, “Yeah, and that’s just the top of it.”

That is how I feel about web standards. What you see in the browser, is just the final rendering that is a combination of html, css, and javascript. So much care and detail can go into these elements to produce the final result. Often, as I browse the web and stumble across a nicely designed site, I will turn off styles and/or javascript to enjoy the simplicity of the plain html and then scan the css and javascript to see how it was constructed.

In the previous article in this series, I walked through some of the more significant design changes we made to Tag Builder. In this article, I will walk through the changes we made just below the surface, to the client-side architecture (html, css, and javascript) to create a new user experience.

1. Web Standards

Web standards is nothing new. It is usually the term used to describe a web application or web site that uses basic HTML elements for marking up content, css for presentation and layout, and javascript for interactivity and dynamic content updates. Web standards typically avoids using unnecessary browser plugins to do the heavy lifting. With advances in javascript libraries and browser performance boosts, web standards based web applications are approaching native OS level quality. To build a world class user experience with our web applications, building in web standards is key.

Tag Builder

Our goal for this revision of Tag Builder was to strip down the HTML to its bare essentials. Divs, classes, lists, paragraphs, headlines, and form elements are the basic building blocks we rebuilt it with. All of the layout, styling, and behavior is achieved using CSS and javascript. You can see it for yourself by turning off styles in your browser (use these instructions to turn off styles in Firefox, IE, and/or Safari). By taking the time to separate these layers and let the rendered html, css, and javascript to do the heavy lifting, it frees up the server side code to be much simpler. This dramatically improves performance and reduces server side complexity.

Tag Builder with styles turned off

2. Accessibility

One of the major benefits of working with web standards is accessibility. In my previous experiences with developing web applications, accessibility is often thought of as an additional task like multilanguage support. By staying true to web standards, many accessibility considerations come automatically. Our attention to detail created one of the most unusual challenges we have experienced with web standards. We wanted to ensure that the Tag Builder form could be navigated by keyboard. When the elements tabbed down into the Additional Options, we found that the browser would jump the view to each field as it was highlighted. This seems normal, but what was surprising was that the javascript or CSS was unaware that the page had moved and so we saw that fields would just show up in odd parts of the interface and destroy the multi-slide effect of moving from one section to another. We eventually found a way to trigger a call to javascript just before the field was in focus so that all things were ready when the tab action occurred. We were able to keep the javascript sliding effect and the ability to navigate the form by keyboard.

3. Javascript for Helpful Behavior

There are many javascript libraries available today to add a bit of slickness to web interfaces. These can often be overdone and to the detriment of the user experience. For Tag Builder, we had a few areas in which javascript behavior was considered to be beneficial and we used it sparingly.

Tag Builder is one long form with many options. We wanted to make sure that users could access the many options but not be overwhelmed by them nor did we want to split the form into many separate forms as many users like to hop around the options when configuring their tracking code. The solution we came up with was to collapse the options using javascript and then as the user clicks on the options they are interested in, those options slide into view. As a user fills out the form fields, light gray dots turn dark indicating how much of the form is filled out.

Indicator Dots

Another way in which we leveraged javascript for behavior was to use it to surface help topics.

4. Integrated Help System

In the previous version of Tag Builder, each form field had companion help that explained what the option entailed and exposed the details associated with each option. This was met with praise from users but left the form littered with little question marks and reduced the readability. To solve this challenge, we used javascript and css. If you turn off styles, you’ll see that the quick help is part of the html. When you turn styles and css on, you’ll see that only when you rollover a form field, will the quick help appear. This quick help provides enough information to address the basic implication of each form field. We also added a link at the end of each quick help for more info. When a user clicks that, a simple modal window pops up with the related content, explaining the option in further detail.

Rollover Help

With the focus on web standards, the redesigned Tag Builder is much cleaner, simpler, accessible, friendlier, and ready for future expansion. With the launch of the Webtrends API, we also developed a simple web standards based interface for developers to generate and test various web services.

REST URL Generator

I hope you’ve enjoyed this series but you are probably thinking, “How much can this guy write about a simple one page form web application?” This is the last article. For the 5th and final part in this series, I have something much bigger than Tag Builder or the REST URL Generator to detail. Our team has been very busy over the last couple of months. I’ve been trying to pace myself with this series on our new user experience as we wrapped up development so that I could end it with some exciting news. I’m happy to say that next week is it! Follow us on Twitter to find out as soon as we announce and stay tuned to this blog to learn more following the announcement.

In the previous two articles*, I introduced the newly redesigned Webtrends custom tracking-code creation tool called Tag Builder and then provided some background into the user centered design methodology, Paper Prototyping, used to construct the flow of the application. In this post, I will highlight the most significant design improvements that defined the new look of Tag Builder and influence products to come.

1. Palette

The most noticeable change with the new Tag Builder is the monochromatic color palette. It is sparse, simple, and gets right to the point. As we push the design of Webtrends applications forward, we are intent on establishing a professional, concise, and highly engineered look and feel. Think German automobile. Think professional photography equipment. Webtrends products are professional products. The palette of charcoal, magnesium, and white dominate the design while hints of litho blue and stop sign red reveal themselves on hover states and error messaging. Color is still there, just reserved for when it is effective.

Color palettes (before and after)

In an addition to Tag Builder, you may have also noticed that the brand identity for Webtrends received a facelift. The webtrends.com website reflects this and is being rolled out across all of our marketing materials. The new wordmark is modern. The new palette, is complimentary to Tag Builder. Both are heavily monochromatic but the modern blue and warm grays have a much stronger presence with the outbound marketing while the product reserves its use of color for important indicators and highlights. This sophistication in coordination is like the outfits of a well dressed Hollywood couple attending the Oscars. Tag Builder was released before the branding update was revealed and so you will see future refinements to product design to reflect alignment.

2. Grid

The grid has received a lot of attention in the web design community in the past couple of years (thanks to pioneers like Khoi Vinh at the New York Times). The grid has been used for decades to organize typographical information in print so that blocks of type define the geometry and patterns of the design. This allows for the elimination of ornamental design clutter and reduces design to its essential elements. The new Tag Builder uses a 960 based grid and this allowed us to simplify the design dramatically. It may seem a bit open at first with excess whitespace, but as soon as you interact with Tag Builder, you’ll notice that the whitespace gives way to hover help text that no longer requires a click just to get the basic concept of each fieldset.

Tag Builder and the grid

3. Language

Because the previous Tag Builder required this additional click to access any help, the field labels ended up being sentence like in places and overly descriptive. This created a wordy design that left the user with a lack of confidence and uncertainty as it required more comprehension even for basic fields. The new labels are short and conversational in tone. This is easier to comprehend and it leads to a more confident user. For instance, a certain label read, “Single first-party cookie (use one first-party cookie across the primary and each subdomain: Cookie domain attribute.” In the new interface it now reads, “The site domain you want to track,” followed by the entry field. When the user hovers over the field, hover help appears and provides the user with an opportunity to confirm their assumptions as well as providing a link if the user wishes to explore the topic in depth. In addition to improving the readability of the labels and hover help, we also improved the error messaging for improperly filled out fields. The language short, concise, and straight to the point.

4. Indicator Dots

One of the most troublesome design challenges we faced with the new Tag Builder was how to clearly communicate completed fields when only one tab was visible at a time. We solved this challenge with a unique solution that we named, “indicator dots.” We noticed in the prototyping tests that users would click through the tabs a few times just as a driver in a car trying to make a left hand turn onto a busy street swings their head back and forth. With the indicator dots, now they at least knew which tabs that had completed some information in. This challenge grew as we realized that there was no clear way to message the user if they had improperly filled out a field on one tab when clicking the “Build Tag” button. So, we also leveraged the indicator dots to turn red when there is a field error on a tab. In the end, the indicator dots communicate to the user three things; how many choices are there on a tab, how many were filled out, and which fields contain errors when submitting the form.

Indicator dots

5. Confirmation

A related challenge to the indicator dots was the lack of any confirmation before the user clicked the “Build Tag” submit button. The previous version of Tag Builder directly triggered the “download” function of the browser when this was clicked. This worked ok in Internet Explorer but in Firefox and Safari, the download function didn’t allow the user to name the file. We realized we needed a confirmation page that condensed the information related to that particular tag setup on one screen paired with the option to name the zip package.

Confirmation page

Summary

We made many additional improvements with Tag Builder and I hope if you are a user, you have noticed an improved workflow. In the next article, I’ll walk through the changes we made regarding the web standards architecture.

I’d love to hear your feedback (thoughts, comments, questions, or critiques) on this new design direction.

*When I set out to write this five part series, I didn’t intend for it to be as drawn out. A new baby and product design improvements beyond Tag Builder are keeping me quite busy.

A power user of WebTrends recently told me that, “With WebTrends, you are only limited by your imagination.”  For our advanced users, this is true.  They see the power of the platform, get in there, and access all sorts of custom controls and configurations made available to them. However, exposing these power features to our power users has come at a cost, the overall user experience.  When I joined the WebTrends team, my mandate was to dramatically improve the user experience of our products for all users. I am proud to announce the first manifestation of this initiative.

Previous Tag Builder - Version 2.2

Enter Tag Builder – the starting point for our User Experience (UX) transformation.  Tag Builder is a great power user mini-app.  It allows a user to quickly put together a powerful custom javascript tag for visitor/behavior tracking.  These tags work for both the Analytics and Warehouse platforms and even includes options for Ad Director and Quantcast tracking (2.2 release feature) all within one custom javascript file. Tag Builder, because of its small size, allowed us to do a complete overhaul on the user interface while keeping the engine that builds the actual tag on the backend the same.  We even included a link to the 2.2 version of TagBuilder so users who rely on Tag Builder can access the previous version during the transition so they can compare the javascript files for their own curiosity and quality assurance.

New Tag Builder - Version 3.0

The next four articles will walk through the detailed changes manifested in the new Tag Builder, the methodologies that led up to them, and what this means for the larger WebTrends product line.

Try out the new WebTrends Tag Builder yourself. And let us know what you think.

Years ago, when my wife and I were new parents, we decided to go out on a date one evening and leave the care of our son to a babysitter for the first time.  We were nervous parents and our heads were filled with visions of everything that could go wrong, nearly convincing ourselves to abandon the plans and stay home.

We had to go out and decided we had to get over our fears.  We started by writing down all of the emergency information we could think of on a single page for the babysitter.  This included phone numbers for our cell phones, doctors, the hospital, poison control, grandparents, friends in the area, and anything else we could think of.  We listed our son’s favorite foods, when he should be put down for bed, and what his favorite bedtime stories and lullabies were.  We prepared, packaged, and labeled food and placed it in the refrigerator, made up a bottle of milk, laid out his pajamas, as well as many other preparations.  Again, we were nervous.

When the babysitter arrived, we walked her through the house, showed her all the preparations, and went over and over the emergency information a few times.  This all took less than ten minutes.  She seemed to understand it all and her let us know that she had done this before and everything would be OK.

(more…)