Tagged: standards

Somewhere in between presenting static information graphics and complex, interactive data dashboards there’s a need for a way to visualize moderately dynamic data on the web. Oftentimes the solutions you see implemented are clunky, for example, manually creating multiple frames of various data points and uploading them by hand. These methods scale poorly and try even the most patient.

Traditionally the task of combatting the challenge has fallen to Flash. To be sure, it is a fine choice. I am not here to rail against Flash and contend that absolutely all things on the web should be done with HTML, CSS, and JavaScript. Flash is tailor-made for creating dynamic web experiences. However, using Flash in some cases might be the technological equivalent of hitting a fly with a sledgehammer.

By using a standardized set of web technologies, it is possible to produce interesting data visualizations that degrade gracefully in the face of browser inferiority. Through careful semantic crafting of our XHTML containers, clever use of CSS, and a splash JavaScript, we can build data visualizations that enhance our message and communicate better to our users. As a frame for this technique, I have created a fake site for a university fundraising event. The data visualization we’re going to be working with here is a temperature gauge that will display progress towards a monetary goal. Go ahead and take a sneak peek at the final result.

Building the XHTML

As with most techniques, the foundational XHTML is the most important piece, enabling us to progressively enhance the visual presentation. The structure of our XHTML will be in three parts:

1. The container of the data visualization
2. The progress indicator to be animated
3. A textual representation of the data

The structure for this is alarmingly simple, so I won’t drag it out over multiple steps for you.

50%

It may seem as though we have an extra div element here. In many other CSS articles, authors go to great lengths to reduce the number of div elements needed to construct a page, oftentimes relying on readily-available block-level elements. While this methodology has great merit, I will always use an extra div instead of using a p when it comes to the visual composition of a key page element. More often than not my work is handed off to a different design/content team and I have no idea if they are going to realize the p tag has a purpose beyond simple content formatting. Using an extra div here protects the integrity of the visual structure moving forward.

Jiggering the CSS

The visualization component will be handled through a clever combination of background images and property manipulation. When I first started developing this technique my instinct was to use absolute positioning to slide the inner element in and out as necessary, essentially “filling” the container with the inner element and hiding the unnecessary parts.

This method worked fine when I was only working with simple blocks. As soon as I started working with non-square shapes it fell completely flat. The points between 0 and 100 never lined up correctly. Searching for a new solution, I struck on the idea to align the inner element with the edge of its parent and alter its width/height depending upon the value being displayed. By doing so we gradually reveal the background image of the inner element, allowing it to line up perfectly with the background element of its parent.

What we will do is create two images. The first image will represent the empty state of our visualization and the second will be the completely full state. The empty state will be applied as the background of the gauge element and the full state as the background of the progress indicator element. Technically speaking, I’m only going to create one image with both states in it. For more information on why I’ve chosen to do this, you can refer to CSS Sprites: Image Slicing’s Kiss of Death, an excellent article by David Shea. You can view the image here.

The CSS for the container is as follows:

.gauge{
	width: 77px;
	height: 442px;
	position:relative;
	background: #333 url(gauge.gif) top left no-repeat;
}

The CSS here is pretty trivial, but do notice that we specify a hex color value in the background property. This hex color increases the technique’s accessibility and will provide a solid reference color to those who have disabled images.

For the inner element:

.gauge .current-value {
	position:absolute;
	left: 0px;
	bottom: 0px;
	height: 50%;
	text-align:center;
	width: 100%;
	background: red url(gauge.gif) bottom right no-repeat;
}

Because this animation is vertical I have positioned the inner element at the bottom of the container and positioned the background element at the bottom of the inner element. This technique works just fine as a horizontal animation as well, with the primary difference being where the internal element is anchored to its parent. As before, we specify a color in the event that images are disabled in the user’s browser.

From here, the only property we care about is height. In our example it is set to 50%. The entire visualization hinges on this value being accurate. You may be tempted to scrape the value from the XHTML p element with JavaScript and set the height from there, but that alienates your users with JavaScript disabled. Therefore, your options are to set this dynamically with a backend script or update it by hand. Either way is exponentially favorable to creating 100 distinct images for the intermittent states.

The last step is to hide the textual value.

.gauge .current-value * {
	display:none;
}

Note: I am not here to get into a debate on the best way to hide text.

This step is optional, you may wish to leave the textual equivalent of your data displayed over the top of the visualization. I have chosen to hide it, but users who come along with CSS disabled will still be able to view the progress of the fundraiser.

At this point, you can stop. You have created a compelling visual representation that is highly reusable and degrades gracefully in the face of antiquated technology, all using skills already at your disposal. Take a look at the example page to see the results. However, if you want to add a finishing touch you can sprinkle in some JavaScript animation.

Working The JavaScript

Now that we have our gauge built, we will add an unobtrusive layer of JavaScript to animate the mercury of our gauge from zero to its current state. Those users who do not have JavaScript enabled will not see this, but those who do will be presented with a nice animation to complete the temperature gauge visualization.The first thing we will do is setup an object literal to contain our gauge animation. This will help us maintain scope and increase portability if we need to extend our JavaScript.

var gauge = {}

We are going to need to keep track of two things: the document node we’re animating and the height at which we will need to stop animating. We don’t know either of these things at the time of creation, so we’ll create variable place holders for now.

var gauge = {
	targetHeight : 0,
	progressMeter : new Object(),
}

My own preference when working with JavaScript object literals is to create an init() method to kick start whatever it is I will be using them for. In this case, init() will need to do three things:

1. Verify the user’s browser supports the Document Object Model (DOM) specific methods we will be using
2. Reset the value of the gauge to 0
3. Animate the gauge to its final value

As such, our init() method will look like:

init : function(){
		if(!document.getElementByID) return false;
		this.resetValue();
		this.animateGauge();
}

The first line checks to see if we can use document.getElementById and aborts if we cannot. This will exclude all browsers that do not support the standard DOM. The next two lines are for methods we have not written yet, which is something we will do now.

resetValue : function(){
		this.progressMeter = document.getElementById("campaign-progress-current");
		this.targetHeight = this.progressMeter.offsetHeight;
		this.progressMeter.style.height = "0px";
	}

This method grabs the node we wish to animate and stores it in the progressMeter variable we set above. It then grabs the current height of the node and saves it as the target height we will be animating to. Finally, it sets the height of the node to 0. Once we have done all of this, we are ready to animate the mercury to its current value.

animateGauge : function(){
		var currHeight = this.progressMeter.offsetHeight;
		if(currHeight == this.targetHeight){}
		else{
			var interval = Math.ceil((this.targetHeight - currHeight) / 10);
			this.progressMeter.style.height = currHeight   interval   "px";
			setTimeout("gauge.animateGauge()",30);
		}
	}

This function is where the magic happens. It first grabs the current height of the node and compares it to the target height and halts the animation if they are equal. If they are not equal, it runs a very simple formula to calculate an animation interval which is appended to the node’s current height. The formula we use creates a very simple illusion of easing, which is more natural to the eye than a simple linear animation. Once it’s done that, it waits 30 milliseconds and calls the animateGuage() again. This process, known as recursion, will repeat until the gauge has reached its target value. Now all we need to do is call the init() function once the window has loaded.

window.onload = function(){
		gauge.init();
	}

Note: I fully acknowledge that this is a very primitive onload function and should not be used in production. However, that debate is long and not appropriate to this article. Because I have used this technique you may notice some initial flickering.

Putting it all together, the final code looks like this:

window.onload = function(){
		gauge.init();
	}

var gauge = {

	targetHeight : 0,
	progressMeter : new Object(),

	init : function(){
		if(!document.getElementById) return false;
		this.resetValue();
		this.animateGauge();
	},

	resetValue : function(){
		this.progressMeter = document.getElementById("campaign-progress-current");
		this.targetHeight = this.progressMeter.offsetHeight;
		this.progressMeter.style.height = "0px";
	},

	animateGauge : function(){
		var currHeight = this.progressMeter.offsetHeight;

		if(currHeight == this.targetHeight){
		}

		else{
			var interval = Math.ceil((this.targetHeight - currHeight) / 10);
			this.progressMeter.style.height = currHeight   interval   "px";
			setTimeout("gauge.animateGauge()",30);
		}
	}
}

That’s it. Take a look at the final example to see this at work. This particular data visualization example is very simple, but it is easily extendable and limited only by your ability to create graphical representations of data. With slightly more complicated JavaScript, you can create very dynamic animations on top of this basic XHTML/CSS. As I stated in the introduction, this technique should probably not be used for large data visualization dashboards or situations requiring extensive animation. However, it is excellent at providing progressive enhancement for situations calling for low-to-moderate levels of data visualization.

Like this article? Digg it!

Throughout my Web design and development career I have found incredible amounts of valuable help and fantastic resources while searching for solutions to various problems. In the last few years I have found most of this helpful information on Web standards and accessibility-oriented blogs and forums. It’s amazing that so many people are willing to spend so much time to share their knowledge with others and help make the Web a better place.

However, and that gets me to the subject of this article, occasionally I hear mutterings from some people who seem to think enough has been said about best practices and that we should find something else to write about. Some say that Web standards aren’t important anymore, because most Web developers are already using them. Others say that it’s boring to read yet another article, blog post, or book about CSS, HTML, accessibility, or usability. They don’t see the point in writing articles or books on those subjects since there are so few left to learn anything from them.

Are you kidding me?

The clued-in are a small minority

If you really think that the majority of people in the Web business have fully embraced Web standards, accessibility, and usability, and strive to follow best practices in general in their work, I’d like to know what planet you’re living on. On Planet Earth, standards-aware Web designers and developers are still a tiny minority of the people working in the Web business. Tiny. We may be vocal, and we may be the ones writing articles and books, but we are seriously outnumbered.

I encourage anyone who thinks we do not need yet another article or book on Web standards, CSS, accessibility, graceful degradation, progressive enhancement, or anything else related to best practices, to take a quick look around you.

Go on, examine some of the work produced by Web agencies and IT consultancies in your town, city, or country. Look at the work of your colleagues and competitors. Would you say that the people working there have nothing left to learn? That they would not benefit from reading an article that explains how to replace their old school Web design techniques with modern, accessible, and search engine friendly methods? Did the sites you just examined really use valid, semantic markup and have no accessibility problems? Really? Wow. You must live in a very small place, with your place of employment being the only company in the Web business.

What those saying they don’t want to read more articles on best practices do not seem to realize is that only a fraction of all people who design and build websites for a living read blogs. Even fewer read blogs related to Web development, frequent sites such as this, or read books on modern Web development. Most (as in “more than fifty percent of”) people who build websites do it first and foremost to make a living, not because they are passionate about the Web or get a kick out of the idea of giving everybody equal access to information. As long as they get paid, that’s good enough for them. If the techniques they learned several years ago still seem to work and nobody complains, that too is good enough for them.

Many articles and a whole bunch of books have been written about Web standards, CSS, accessibility, and semantic markup. But I can assure you that not even those of us who spend most of our time working with and advocating best practices in front-end Web development have heard it all before. And the things we have heard about can almost always bear repeating. Web standards and accessibility are not “dead”, “boring”, or subjects that everybody knows everything about. Actually, I don’t think anybody knows all there is to know about them. But if you find the subjects boring or think you know all you need to know, fine. Nobody is forcing you to read everything that gets published.

It is my firm belief that Web standards are just as important to talk about now as five years ago or last week. The message needs to be repeated over and over again as long as the vast majority of Web workers continue to produce sub-standard websites.

The problem is how to deliver that message to more people than those who already know.

Reaching those who need to be reached

Like I said, most of the people we need to reach do not read our blogs. They have never heard of A List Apart, Zeldman or the css Zen Garden. So we have to find ways of spreading information outside our small group of standardista blogs. Here are a few suggestions for where we can find these people:

• Discussion forums and mailing lists. Perhaps you frequent a forum where the main focus is on PHP, ASP.Net, graphic design, Flash, or some other subject not directly related to Web standards or accessibility. Do what you can to plant seeds of information when you see an opportunity to do so.
• Local meet-ups. Organize a simple Web design get-together at a pub. Don’t mention anything about a special theme for the meet-up. Your first goal is to get a bunch of people together and start talking about Web design and development. You will likely be able to find at least a few people who are interested in talking about best practices. Then they talk to their friends in the business, spreading the information.
• Printed magazines. In my experience many Web workers prefer reading offline magazines instead of online publications. Contact your local (national) Web design and Internet related magazines and offer to write articles. It doesn’t have to be long feature articles. Start by sending them short tidbits to publish in their Tips and Tricks section, if they have one. You may even get paid to do this.
• Education. This is a big one. So many schools still teach students outdated ways of designing and building websites. If you can somehow influence teachers and instructors to update and improve what they teach students, much will be won. The WaSP Education Task Force is doing a lot of work in this area, but if you get the chance to affect what gets taught, take it.

Reaching those who don’t want to be reached

Reading an article or listening to a presentation does not necessarily mean that you will change the way you work, however. Many will be interested in learning how they can improve the quality of the work they do, but there are two groups of people that I find really hard to influence (please forgive me for generalizing):

• Purely visually oriented designers and Flash developers who do not want the Web to follow any logical rules at all. They want the Web to be a purely visual medium, and approach it as if it was a printed brochure, a computer game, or television.
• Back-end programmers who don’t really want to touch client side programming, and let their IDE create the HTML, CSS and JavaScript for them.

I don’t really have any good suggestions for reaching these groups. Maybe you know what it would take to make them interested?

We still have a long way to go

If you consider yourself a Web standards and best practice advocate, please continue helping, explaining, and making it easier for the vast masses of Web workers out there to adopt modern ways of designing and constructing websites.

Let’s not stop fighting too early. The battle, if you choose to see it as a battle, has not been won. I would say that it has only just begun.