One of the fantastic parts of my job at Webtrends is having the opportunity to work with our partners via the Webtrends Open Exchange .  We want to combine the strength of our platform with the strength of our partner’s to provide real solutions.

Many of you saw our press release about integrating with WebSphere Portal earlier this year. Webtrends services a significant portion of the WebSphere Portal install base and have for many years.  I would credit the flexibility of both solutions for making that so.  Ever since the initial release in 2001, WebSphere Portal has become one of the main enterprise web portal software platforms of choice.  The Java platform is easy to deploy and maintain for all types of organizations. My team has worked with WebSphere Portal customers to implement JavaScript based data collection and log file based methods.

When we first began the integration project, we did a review of challenges that portal users might face when trying to implement analytics reporting.  The items that bubbled to the top were:

• Uncertainty regarding best practices for deploying code.
• Inability to deploy code quickly, with low development costs
• Difficultly creating business ready, actionable reporting, without long design cycles
• Ability to analyze the log files that WSP produces

In short, people need a repeatable solution that is easy to implement, creating immediate business value.  Based on this feedback, we worked with IBM to create a better way to implement both solutions together using the SmartSource Data Collector JavaScript methodology and another for just reporting on log files.

Let’s talk about the JavaScript version first:

• So exactly how much development is required? Very little.  The solution requires JSP and JavaScript code that is plug and play.  The code required is contained in the solution.  All your developer needs to do is apply it to your WebSphere Portal themes.
• How rich is the data? Using this methodology we can collect data on pages, portlets, site navigation (using the site breadcrumbs), users by name, document tracking and all of the standard reports you expect out of Webtrends Analytics.  This also includes creating user readable versions of URLs for customer not using site mappings to simply the URL strings.  An example of this might be changing a URL like: http://www.ibm.com/wps/portal/!ut/p/kcxml/04_Sj9SPykssy to http://www.ibm.com/My Website/The Main Area/News and Views/, which is much easier to read and analyze.

Now, the Site Analyzer log file solution (Webtrends Software customer only):

• So exactly how much development is required? None.  You simply need to analyze the Site Analyzer log files WebSphere Portal creates.
• How rich is the data? The log files offer different but powerful data.  You can report on authenticated users, pages, portlets, administrative commands, page customizer and user management.

When can I get this and how much does it cost? The solution is available now.  You can take the white paper and start your implementation right away.  Best of all, this solution is completely free to use.  However, if you’d like assistance or need custom work Webtrends Solution Services can help you to find the right fit for you.

Download the Implementation Whitepaper

All of these reports, they are available using the classic Webtrends interface, the sleek new Analytics 9 interface or can be pulled directly using our REST API.  The API supports JSON, XML, Excel, etc.  This data can be pulled directly into a WebSphere Portlet in a matter of minutes.

Webtrends will be at the IBM Portal Excellence Conference 2009 October 12 -15 2009 held this year in San Diego, California.  I’m happy to say I’ll be discussing this solution in more depth October 13^th.  The Webtrends team will be at Booth #18 during the event providing demos, discussing the WebSphere Portal platform and our partnership with IBM.  Come by and say hi.  I’d love to meet every one of you.

Keep in mind this white paper is just one step in this integration.  Webtrends continues to work with the WebSphere Portal team to optimize ease of deployment and reporting.  If you’re excited about the project now, just wait.

See you in San Diego!

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.

I am very pleased to announce the launch of a market-leading data collection capability for Webtrends. The addition of this API to our capabilities is another example of why Webtrends is the most powerful, open and elegant solution in the industry.

Keeping with our commitment to gather your feedback and deliver the most relevant of tools, we are making this new capability available in Beta for all of our customers and partners to use now.  Please help us help you by getting involved today. Push the limits! Get creative! Then let us know where we can improve on the capabilities. We will continue to evolve the API. Anything that connects to the internet is fair game.

As you, our customers, continue to expand your online presence beyond your web sites, it is our responsibility to grow our own measurement capabilities ahead of your evolving needs. Our data collection API is a critical addition to your arsenal of tools for collecting new data. The primary purpose for the API is to track behavior across various media that access the internet where traditional site tagging isn’t possible or an optimal fit.

Interested in more details? A full overview is available on our Developer Network. Please feel free to reach out to me with any questions, comments, or to explore opportunities to leverage this exciting new capability.

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.

Silverlight and JavaScript play nice together, so making manual requests for each interaction you want to track via DCSMultiTrack should not be a problem, though it will be time consuming to go through and add all these calls yourself.

The interaction between Silverlight 2.0 and WebTrends logging has been simplified by using a custom class developed by WebTrends. All you need do is simply add the class to your project by either including it in your current file, or by adding a new Silverlight class library.

The class is called “DcsMultiTrack” and lives in the namespace “WebTrends”. This code is essentially a tunnel between the Silverlight and the JavaScript function “dcsMultiTrack”. The “Send” method is used with the same name / value pairs as you would if making a standard JavaScript call to dcsMultiTrack. Here is an example:

DcsMultiTrack multitrack = new DcsMultiTrack();
multitrack.Send(”WT.ti”, “PageTitle”, “dcsuri”, “/silverlightapp/search_button”);

The Send call will not fail if the application is embedded on a page where WebTrends tags are not available. And… here is the class code:

namespace WebTrends
{
using System;
using System.Net;
using System.Windows;
using System.Windows.Browser;

///
/// WebTrends Tracking function for Silverlight
///
public class DcsMultiTrack
{
///
/// Private value
///
private static bool hasDcsMultiTrack = false;

///
/// Initializes a new instance of the DcsMultiTrack class
///
public DcsMultiTrack()
{
if (!hasDcsMultiTrack)
{
try
{
string typeOfFunction = (string)HtmlPage.Window.Eval(”typeof(dcsMultiTrack)”);
hasDcsMultiTrack = (typeOfFunction == “function”);
}
catch (Exception e)
{
System.Diagnostics.Debug.WriteLine(e.Message);
}
}
}

///
/// Gets or sets a value indicating whether or not dcsMultiTrack exists in JavaScript
///
public bool LoggingEnabled
{
get { return hasDcsMultiTrack; }
set { }
}

///
/// Issue log request to WebTrends
///
///
Name/value pairs eg:(”WT.ti”, “title”, “dcsuri”, “/silverlight_app/button1″) /// multiTrack.call(”WT.ti”, “title”, “dcsuri”, “/silverlight_app/button1″)
public void Send(params object[] args)
{
if (HtmlPage.IsEnabled && hasDcsMultiTrack && (args.Length % 2 == 0))
{
try
{
HtmlPage.Window.Invoke(”dcsMultiTrack”, args);
}
catch (Exception e)
{
System.Diagnostics.Debug.WriteLine(e.Message);
}
}
}
}
}

Simple right? Any questions? Well there is one blringly obvious question; When do I make my Send call? In call these Rich Media Technologys yes we can make logging requests but when? And what do we put in them? What constitutes as a page view in an interface with no pages. This is a question we will focus on in our Workgroup.

Accessing the logging script and making calls to DCSMultiTrack from AJAX should be very simple since you are likely using JavaScript already to handle user interactions, build your XHTML controls, and utilize XMLHttpRequest. Even if you are using a different scripting language such as VBScript you can still make a call to a JavaScript function in much the same way you would from within JavaScript.

If you wanted to make the deployment of your AJAX ‘tagging’ more efficient rather than add a call to every object action you want to track you may consider adding it into your event handler function to your AJAX application that will automatically make calls to DCSMultiTrack when triggered:

Button1.onclick = updateData()
…
function updateData(event, param) {
var myurl = www.domain.com/service/ajax.aspx

http.open(”GET”, myurl + “?id=” + escape(param), true);
http.onreadystatechange = useHttpResponse();
DCSMultiTrack(”DCSURI”,”/ajax/menu/”+event.target+”/”event.type,”DCSext.param”,”param”)
http.send(null);

}

Here I have used the example of on click event handler but it could just add the call within a wrapped up function and attach this to a rootElement event handler. The issue there then becomes that you will be tracking all user interactions so what do you start passing as page URL’s and other parameters just to say represent a mouse drag.

Should the handler be attached to all events enabling you to collect information on any and every interaction? Or prehaps limited only to duistinct content loads/views within the applet? And what should you be passing as parameters? Why not join us to discuss this at Engage 2009 in our Workgroup.