It  represents data freshness (time since update) per bar using an opacity decay so a bar fades away if it doesn’t receive fresh data.

The examples I found elsewhere represent static data, so my model of implementation is different in that I don’t use data binding or d3.layout.stack() because I couldn’t figure out how to make those work with dynamic data (if someone can show me a better way, I’ll gladly accept the guidance). Thus, my implementation directly adds/removes the bars and determines the bar widths and x-position itself.

The use case I intend to apply this prototype for is to visualize a stream of realtime data.

Functionality not implemented in this prototype include things such as hover and click actions to show details of the data a bar represents.

Here are links to the code and working example:

http://bl.ocks.org/1488375
https://gist.github.com/1488375

Here are basic examples of circles with varying sizes and colors and animating them to dynamically change that I used as building blocks.

Here are links to the code and working example:

http://bl.ocks.org/1473535
https://gist.github.com/1473535

As a starting point this is a simple line chart used as a sparkline. The HTML and Javascript provide a boiler plate from which more complex visualizations and charts can be built.

Here are links to the code and working example:

http://bl.ocks.org/1133472
https://gist.github.com/1133472

To make the size more applicable to inline use as a sparkline decrease the ranges:

var x = d3.scale.linear().domain([0, 10]).range([0, 20]);
var y = d3.scale.linear().domain([0, 10]).range([0, 10]);


UPDATE: I added another version that shows animations with transformations and transitions.

http://bl.ocks.org/1148374
https://gist.github.com/1148374

Good introductory quote to the external links and images shown below:

There’s no longer any debate. There’s reliable, reproducible evidence that web page latency is directly tied to the bottom line. At Velocity, Microsoft, Google and Shopzilla made this abundantly clear in a series of awesome presentations: detailed, controlled testing proves that slower pages hurt the bottom line. In Google’s case, adding delay reduces the average number of searches a visitor does each day even after the delay is removed.

Regarding “smaller scale” sites more typical than Google and Bing:

The results of their analysis show how significant a reduction in page latency can be. In addition to reducing bounce rates, and increasing pages per visit & time on site, they found a 16.07% increase in conversion rates and a 5.50% increase in average order value. – http://radar.oreilly.com/2009/10/watching-websites.html

External Links:

http://radar.oreilly.com/2009/10/watching-websites.html
http://radar.oreilly.com/2009/07/velocity-making-your-site-fast.html
http://www.watchingwebsites.com/archives/proof-that-speeding-up-websites-improves-online-business

Good summary PDF showing metrics of performance impact.

I have read comments from companies such as Google and Amazon how the performance of an application can dramatically affect how much people use it. I agree. The slightest friction in searching makes me search less, or shop less, etc.

This past week I’ve been using the new iPhone 3GS which is at least 2x faster than the previous iPhone 2G I had. In some cases it’s 4x and 6x faster.

I already used the iPhone a lot. The increase in speed has further reduced the “friction” of use to the point that if I even have a thought of quickly looking something up or performing some other action, I am much more likely to do it.

On my last iPhone, I consciously chose to not bother at certain times because of the time it would take. Yes, I’m talking in seconds and even milliseconds here — but when it’s a “thought”, if the tool doesn’t work at the same speed, then it’s friction. Same goes for another application I use which involves looking up reference materials and documents. Before I kind of had to avoid “flipping around’ while someone was referring to things. It was actually faster to use the paper documents. Now, I can keep up or be faster with my iPhone than the paper version ‘users’. Therefore it encourages use.

The new user experience of using the iPhone 3GS, so significantly improved just by the performance improvement, has reminded me as a developer and architect how critical it is to design, plan for and develop to achieve high performance. Functionality isn’t enough — we should be aiming for the “speed of thought”.

Interestingly, Google has just launched a new site just for “speeding up the web“.

The following video shows “the experts” talking about how the human mind perceives changes of 100ms (one tenth of a second).

It’s my belief that this isn’t just a “nice to have” feature. If a product, service or application wants to be adopted and deemed “necessary” by its users, its performance must reduce friction as much as technically feasible to the point where it approaches or achieves “speed of thought”.

http://www.liquidx.net/plotkit/

http://media.liquidx.net/js/plotkit-tests/dynamic.html

- combining multiple Javascript files into a single file
- using a JSMin servlet filter to minimize and cache in memory the Javascript file to return
- adding a filter to add HTTP Header caching to static files
- reducing file sizes for product images

Use this to minimize file size: http://alex.dojotoolkit.org/shrinksafe/

Then enabled mod_deflate rather than mod_gzip

… make sure Apache is doing compression in memory, and not on the filesystem.

Then, actually change JS and CSS filenames each time they change so we can forcefully set very long cache refresh times so they never expire.

http://yuiblog.com/blog/2006/10/16/pageweight-yui0114/

http://www.crockford.com/javascript/jsmin.html

http://dojotoolkit.org/docs/compressor_system.html

http://www.thinkvitamin.com/features/webapps/serving-javascript-fast

http://www.die.net/musings/page_load_time/