I once wanted to invent an exercise machine that plugs into a standard video game port. The idea was to transform the fundamentally boring process of working out into utter absorption: When Pacman won’t move unless you’re pedal, it’s exercycle or be eaten.

Sadly, the Patent Office has already awarded a patent for this idea. Meanwhile, the intranet has recently rendered the only other invention I’ve ever wanted to build … the PrinterShredder! … obsolete.

The PrinterShredder!, like most brilliant concepts, is obvious once stated: Since most printouts are recycled without anyone ever looking at them, businesses could save a lot of money by eliminating the wasted steps, immediately recycling the output as soon as it is created. (Not to mention the PrinterShredder!’s impact on security — valuable company secrets would never leave the data center.)

But now we have the ability to publish print jobs as HTML directly onto our intranets, where everyone can ignore them at the speed of electricity (about 33% of the speed of light … but I digress).

It has been common practice for budget-driven data center managers to turn off suspect print jobs periodically, turning them back on only if someone complains. Often, this is the only way to find out if a job is needed. But as storage drops below a penny per megabyte, it is now less trouble to just dump everything out there.

This is the same thinking that lead to the Lincoln Navigator. When any resource is overly plentiful, we get sloppy in how we use it, whether it’s gasoline leading to over-sized, inefficient cars, the immensity of the sky leading to atmospheric pollution, or cheap processor cycles and storage leading to “kitchen sink” intranets and Web sites.

When we get sloppy we face unintended consequences. Fuel-inefficient cars increase demand for fuel so gas prices rise … but we still own the Navigator. Atmospheric pollution leads to global warming, ozone depletion, and pulmonary disorders … but our whole economy rests on the processes that generate pollution. And when you just dump reports onto your intranet, you make it that much harder to find anything useful, because you’ve made the signal-to-noise ratio worse … and you probably create new jobs for analysts to sort through the muck.

The problem is that cheap storage is the wrong focal point for our attention. We should be taking advantage of our intranets’ real-time processing and highly visual nature to create “dashboard reports”.

As with so many user-interface issues, your daily driving experience tells you most of what you need to know to understand dashboard reporting. What, after all, does your dashboard display? Exactly what you need to know to drive safely without damaging your car. It isn’t just exceptions, nor is it only summary data. It’s neither entirely graphical nor entirely textual. Nor is it uniform: Some dashboards are designed for more sophisticated drivers than others, presenting both more and more detailed information.

But it’s always what the driver needs to know, while driving, designed for easy interpretation at a glance.

Which leads us to the tough part. Over a span of nearly a century we’ve learned what drivers need to know at a glance, filtered by what we can build into automotive dashboard displays. No such consensus exists for a business dashboard, so you get to figure it out.

Next week’s column will give you some help.