The laws of shitty dashboards | Hacker News Reader

The laws of shitty dashboards

attackwithnumbers.com

231 pointspaulcothenet124 comments

>They also employ UX techniques that dates from a time where the only UI component you can use was a light bulb. If that red thing is critical, can’t you tell me right away what it means?

This annoyed me a little bit. A check engine light is the perfect component for what it does. If it's on it means that something may be seriously wrong and that you're probably too stupid or ill-equipped to fix it.

If it was something simple, easily detectable and fixable it would have its own light, ie the door is open, you're running out of gas.

This is not true. The check engine light can come on in some cars if the gas cap is not screwed on tight enough - easily fixed yet treated as serious as a major engine malfunction.

It can also come on for no apparent reason. Mine is on right now. Gas cap is tight, car is running fine. Starts right up, runs smooth, power is good, fuel economy normal. So I'm not going to take it into the shop.

In this day and age we can have something more informative than a check engine light. Tell me what's wrong, or at least have a "verbose" option I can enable that will let me see WTF it thinks the problem is.

I think the check engine light is a giant scam to get people to take their car in for service when there is nothing wrong with it.

My OBD-I truck had a pair of pins that, when shorted together with a paperclip, would read out the exact trouble code through the check engine light.

As far as a verbose option, if you pull into an O'Reilly's or other auto parts store they will lend you, for free, an OBD-II scan tool with which you can read out the exact error plus any corresponding sensor data(freeze frame).

If your check engine light isn't flashing, it's actually because your vehicle has detected an issue with your emissions equipment that means that the engine control module is not able to regulate emissions to within EPA requirements. There are various reasons why this could be the case, but it usually indicates an imminent failure.

For example, mine is currently on because it's detecting a lean fuel condition in the cylinder bank when under high load, which means either that my fuel injection system is not able to keep up or that my throttle is letting too much air into the intake manifold. My car is still drive-able, but I definitely need to have it looked at because my fuel pump or injectors could be going out or my throttle could be faulty.

The point is that it's not a scam, it's providing you useful, predictive information. You just need to know how to retrieve it.

Not exactly a scam. It means your car is not running optimally; generally it means it is polluting more than it should due to O2 sensor failure or backpressure from tailpipe.

You can buy an OBD-II reader for $8. It's cheap enough that the first time it tells you your gas cap was loose, it's paid for itself.

So, for a trivial cost you can get your verbose option. Most people are not going to have any knowledge or desire to have this information, so it's a silly feature to include.

I purchased a Bluetooth one from Amazon ($10.99) and an Android app (Torque Pro, $5). Great tool for $16 all in. Plus the ODB-II adapter can be used to configure some "quality of life" stuff in newer cars (e.g. the constant cabin backup beep sound on the 2014 Prius).

You will need an Android phone already, but these days that is pretty common (particularly for technical people). Just get the error code and Google it, it becomes pretty obvious what it is.

What tool do you use to change configurations?

I know my 2007 Lexus has those programmable options like beep durations and such, but I have only found two solutions - paying the dealership $60 to change them, or buying a $15 android app that changes them. I could do it myself, but the codes (Lexus Personalized Settings) are secret. Did you find a free alternative to modify your Prius settings?

It is super easy on the Prius, this post goes through the steps:

http://priuschat.com/threads/geniii-prius-custom-pids-for-to...

But the short is someone else has done the hard work so you don't have to.

Never ignore check engine lights even if everything is seemingly ok. It could be a lot of different things, some harmless but some not so much. If it's something with a sensor or other intake part, it could also be taking away your gas mileage.

Pro tip: As the others stated, they make good obd-2 readers for cheap and you can also go to many auto parts stores and they'll use theirs to give you the code print out for free.

Not sure about your make/model/year, but my Check Engine light most likely means that I need an oil change.

Ok perhaps the example was a little off due to design abuse from some manufacturers. For example (I think) Alfa Romeo put the gas light on if the fuel cap is loose/missing. This is more of an appropriate design. (Unless it's a diesel then it really is a problem)

The point that I was trying to address is that if there is a critical warning that you can't do anything about, there's no more info needed than 'stop and seek help' which is perfectly served by a simple light. Or do you want a 1 page problem statement to flash up on the dash and explain why you really need to pull over. The only reason you would do such a thing is if you wanted the user to make the evaluation of whether or not it is important or something that can be ignored.

Manufacturers do not abuse the Malfunction Indicator Lamp. Its _legislated_ purpose is to alert the driver to issues which could compromise the emissions control systems of a vehicle. A loose gas cap causes a pressure leak in the EVAP system which captures fuel vapors from the gas tank.

It's also a great design because it needs to be highly reliable, and lights are probably the simplest things you can apply power to to generate a notification.

Also the note about the tachometer struck me as a little odd. The tachometer can tell you if your vehicle is running at a high idle, if the bumps you're feeling are misfires or the road, and it can also tell you whether you've accidentally left your vehicle in 3rd instead of drive after coasting to a stop. Finally, the tach can be used as a raw assessment of the load you're putting on an engine and you can optimize your driving habits according to that. It's not useless information and I much prefer it to an extra cluster of dummy lamps for all that stuff.

Finally, the tach can be used as a raw assessment of the load you're putting on an engine and you can optimize your driving habits according to that.

Perfect example of this are the people who drive with an automatic and somehow manage to stay just below a shift point much of the time, meaning that the engine is at a higher RPM than it needs to be and could be consuming more fuel and wearing faster as a result.

...this doesn't really tally, especially in modern automatics with electronic gearboxes. Most engines are optimally efficient at some key number of revs, and the gearbox strives to keep the car in that range.

Yes, but your web app is probably not as mature as a modern automatic transmission.

>It's also a great design because it needs to be highly reliable, and lights are probably the simplest things you can apply power to to generate a notification.

Only that's a BS reason, because you could always have the "simple reliable" light AND a more detailed explanation in a panel next to it.

Sure, but you'd still have the light for reliability.

I used to own a 2001 Hyundai Accent, with a 5 speed manual. It didn't have a tachometer. You learned what the car sounded like, and learned the shift points based upon the engine noise.

I could tell when it was idling high (for example on cold days) simply because I had driven it a lot. I didn't need a tachometer for that.

If your car is misfiring the check engine light should come on. These days a car misfiring can have serious consequences...

That is not the purpose of the check engine light (official name "Malfunction Indicator Light"). At least in the US the light only comes on when there is a problem that affects emissions, and it is usually nothing that would cause a breakdown. It usually does not mean anything serious is wrong and the most common cause is a loose gas cap, which is easily fixed.

A check engine light most definitely can tell you that you are about to have a breakdown. It's original and most common purpose is emissions control, but it has been extended. An overheating engine will cause the check engine light to come on (happened to me last week in an 88 4Runner) and this has nothing directly to do with emissions. Blow a head gasket, and there could be a long list of repairs besides a new gasket. And even if it is a problem that primarily affects emissions, it might still have a bigger problem. A bad O2 sensor can cause your engine to enter open loop and run rich, meaning that you're blowing gasoline out your tail pipe, costing you money. A misfire can cause the light to come on (bad spark plugs, compression leak, bad fuel injector, bad timing, bad lots of things) and can cause reduced power (which might not be noticeable in city driving), burnt valves, and again blowing gasoline out your tail pipe. Blowing gasoline out your tailpipe will ruin your catalytic converter, which you might not care about right now, but will matter if you try to smog your vehicle to sell it. I've had the check engine come on in a number of vehicles I've worked on, and it has always been a more serious problem than a loose gas cap.

The previous owner of the above mentioned 4Runner ignored her check engine light. By the time I got to it, the engine, 02 sensor, and catalytic converter were destroyed. If your check engine light is on, scan the codes and make sure that it isn't anything serious.

Yeah to second what the other poster said, it can indeed mean a lot of different things. Sometimes it is as simple as an emissions error but sometimes, especially if you ever see it flashing, that means there's something bad wrong going on with the engine itself. It could be anything from a knock or misfire in the engine to sensor failure. It's always wise to get it checked (a lot of auto parts stores do it for free) or just buy a cheap but good obd-2 tool and that will tell you the code and you can go Google and research from there.

This is obviously wrong. The check engine light, even on US cars, can indicate a variety of problems unrelated to emissions, some serious.

The engine warning light is actually the shittiest thing on the dashboard. It can mean anywhere from 10 to 500 things, and nobody knows.

Result? Manufacturer manuals ALL OF THEM will tell you: "Just keep on driving, if it doesn't go off after a few days/a few drives bring the car to a mechanic."

Seriously, go get your manual and check what it says.

I mean, what the fuck? How the hell is that good in ANY way, shape or form?

Manuals instruct you to to wait for the light to appear on multiple driving cycles because the light can trip during a particular drive due to spurious sensor readings or malfunctions. That does not make the light useless.

actually.. thats exactly why it makes it useless.. its not reliable. so people ignore it.

The light is ridiculous. It should read the code in models that have a text display, instead of needing to go to Autozone and rent an OBD code reader. It's bullshit. Tell me the error up front so I can Google it.

The problem is that the OBD codes aren't always specific. Sometimes they're specific enough to diagnose the problem, sometimes they're not, which is why you still need someone with auto expertise to correctly identify the problem. Most shops will warranty against unneeded repairs as a result of reading the code by virtue of buying their $99 "Check Engine Light Service" (whereas Autozone's reader is free to borrow). I've been in the situation where a shop made a check engine light repair that didn't fix the problem, so they made another $500 repair to actually remedy the problem.

The most unspecific OBD code, IMO, is any EVAP code. Seriously could be 100 things, from as simple as a gas cap not being screwed on, to a tiny leak in a gas line, to a bad 02 sensor, to a dead spark plug, leak or rot in the fuel line, bad fuel pump, dirty fuel filter.... ect ect ect....

> This annoyed me a little bit. A check engine light is the perfect component for what it does. If it's on it means that something may be seriously wrong and that you're probably too stupid or ill-equipped to fix it.

> If it was something simple, easily detectable and fixable it would have its own light, ie the door is open, you're running out of gas.

I've been in new vehicles with a single light for "low tire pressure". But it wouldn't tell you which tire. Sure, I can discover this by manually reading the pressure on all the tires, but the system has to already know this information. It's just incapable of displaying it.

I wouldn't say 'incapable' because you can use an OBD device (less than $20 like http://www.amazon.com/dp/B001LHVOVK/ ) to access that information. It's pretty much plug and play for those who care about that kind of thing.

The average consumer can just take it to a tire shop and let them figure out which tire has an issue.

Most articles are shitty, this is an example of one.

Most technical articles are written by someone blinkered by their specific experience which they feel is so wonderful that they should share with the world.

Save the internet from such dross and write it on a piece of paper, roll it up and shove it up the ares your talking out of.

Writing bad articles is a great way to move toward writing good articles.

Writing in the public view is a great way to get feedback on your writing and the subjects you discuss—e.g. corrections, further education, etc. For some people, it also increase the pressure to improve.

Vanity is only one possible reason for writing in the public view, and it's an exercise with large potential gains. Your perspective is entirely off, and you've decided to take an opportunity to attack someone who was either brave enough or indifferent enough to risk being attacked in the first place.

Well perhaps slagging off the work done by others in a domain he is not an expert in isn't a sensible approach to writing articles.

People don't need to be experts to recognize flaws in tools aimed at consumers.

Sure, you don't need to be an expert to have an opinion.

However I didn't come to Hacker News to read a stream of consciousness consisting of the word "shitty" and random screenshots.

That's a good reason to downvote or stop reading, but I question whether attacking the author for having the audacity to publish the post is a good move.

Such a useful, insightful comment. And how BRAVE you are to post it on an account you created just for the purpose. There does seem to be a fair amount of talking-out-the-"ares" (sic) around here, but it isn't coming from the article.

By the way, the correct word in this situation is "you're"

The author deliberately wrote in a inflammatory style, I thought a response in a similar style was useful feedback for this 'brave' author.

I don't have a HN account and bored on a train, its a comment not an published and promoted article I've written, trying to dismiss my opinion based on grammar and typos, hmmm okay you've secured the moral high ground here really well,

There seems to be an attitude throughout the article of "users are too stupid to understand dashboards", and maybe this is true to some extent, but that's really not a good reason to dumb-down interfaces (which seems to be what it's calling for.) E.g.

You have no idea what your users will decide based on the data you are showing them. But you somehow assume your users will know.

My eternal gratitude to anyone who can tell me what to do with session duration at the hourly level. “People at 4:53AM on Monday stayed longer on the site than at 11:36AM”? So what?

Just because you don't know what to do with the data doesn't mean the same applies to everyone else...

My understanding is, that the attitude was "throwing numbers together and calling it a dashboard is bad, ask the users what they actually want".

I'd go quite a bit further. Most users have no idea what they actually want. I think the key to building a dashboard is to ask three questions:

1. How do you measure success? -- or -- How will you know that life is good? How do you know that the sky is falling? 2. If you see this number (something specified in #1) go above or below a certain value, what are you going to do? Anything? 3. When and where do you need to have the info from #'s 1 and 2 to actually take action? i.e.-Do you need to be inside the warehouse? On your phone? At your desk? Daily? Monthly? By the minute? Push?!

1 tells you what to put on the dashboard, 2 tells you how to prioritize the information (something that's important but not actionable will be something that can be found, but isn't prominent or on display above-the-fold), and 3 tells you the form factor/latency that's needed.

I've built a lot of dashboards over the years. Some have completely changed businesses. Some have languished in obscurity. Most are used fairly regularly (at least monthly), but don't actually add much value beyond time savings of having the numbers automated. The ones that really changed businesses and provided some benefit beyond just time savings have had clear answers to those three questions.

I would add a 4th also based on extensive experience, can the users do anything at all about the situation? Being able to order someone to generate numbers doesn't mean the recipients are permitted or capable of doing anything at all. It shows they "care" but a random number generator is more effective WRT dev time than trying to generate meaningful numbers.

I've seen dashboards get tied up in internal politics. The list of recipients of "quality" dashboard is a line in the sand vs the "quantity" dashboard political group. The recipient list and who controls it is far more important than the data contained in the report. Whats important is who reports to who, and why.

A fifth question is does anyone in the chain of command even remotely understand basic statistics like error bars and standard deviations? If the only purpose of the report is to loudly trumpet when pet division B beats divisions A and C thru G, then a very high std deviation / error rate makes stack ranking give the predetermined "correct" result more often. I've seen this personally in "metrics as a teambuilding exercise" where whats actually produced is a weekly report that every division will get to stack ranking win at least once a quarter to meet the Morale Improvement goal on some exec's goal list. Again a PRNG gives better data than real data, if the goal is to give everyone a participation trophy.

Heh. I built a dashboard and included everything my coworkers asked for.

Oddly enough, I'm the only one that uses it and I've dropped everything they've asked for from it to declutter.

The point is that numbers in themselves means nothing to most people and are actually not actionable.

The purpose of a dashboard is to give instant feedback on something that requires it. (Driving a car, airplane, nuclear reactor, space station, server load) i.e. if something is wrong you should be able to see it right away so you can take action.

The dashboards we see today are more like vanity boards which feed our need for new information but doesn't really serve any other purpose.

A really good read on the subject is this one

http://www.kaushik.net/avinash/smart-analytics-dashboard-mod...

I recommend two resources on creating dashboards, both from very experienced practitioners:

1) http://www.kaushik.net/avinash/digital-dashboards-strategic-...

2) Information Dashboard Design by Stephen Few - http://www.amazon.ca/Information-Dashboard-Design-Effective-...

I can second the recommendation for the Information Dashboard Design book. It provides some extremely clear guidance and recommendations. Thanks for the pointer to the first resource, I'll definitely check that out.

Am I the only one that doesn't get the joke about what's wrong with "Last 14 days" and "Last 12 months"?

No.

I can't figure out if he doesn't like the phrasing (instead of "last year," maybe) or thinks the time period is not useful.

Generally speaking, especially near the beginning of the year, I often find "last 12 months" to be far more useful than "this year," which he didn't call out.

Maybe "Fortnight" instead of 14 days would look better. :)

No you're not. I don't get it either.

the option right below it mentions "This year.."

This year should only mean this calendar year, last 12 months is a full 12 month overview. Both are useful for various reasons.

That said i've seen "this year" used to mean last 12 months as well...

One is calendar (or financial) year, the other is a rolling 12 months from today.

Had meant to point at "Last 6 months". (Last 12 months is often useful)

IHMO, it clutters the options with options that are not useful (do you often look at your 14 days spending?) and already included in other options that are close.

Looking at 14 days history can tell you if something is recurring weekly or not. Looking at a month too, but then you lose resolution.

Same thing about 3/6/12 months. Looking for seasonal trends is not stupid.

14 days = 2 weeks

3 months = a quarter

12 months = a year

"2 weeks" may mean the last two calendar weeks, the last and the current calendar week, or the last 14 days. Without even going in to the ambiguity of what a calendar week is (a calender week starts on a Monday, and I will take no opposition), 14 days is less ambiguous (and therefor better) than two weeks. The same goes for the other ones.

Not all dashboards are shitty or useless.

New Relic comes to mind, and it's a tool I've found hugely useful.

While it doesn't instrument full system monitoring (though it's getting there), it provides numerous system and site metrics, monitoring, and a useful degree of logging, that's hugely useful.

One of the biggest gains for us came when it implemented JVM heap monitoring. This is possible through jconsole, but jconsole is a steaming heap which if it were actually made of sht would be useful as it might provide fertilizer. It's a Java app itself, has no persistence, must be running to tell you what you need to know, presents its own security vulnerabilities (if you can attach jconsole to your JVMs other JDK hacks can as well), and more. Given the critical nature of heap and GC operations to site performance, having the insight through NR, and not having to rely on desktop jconsole sessions (for each member of the admin team individually, oh yeah, forgot that one) was a huge boost.

And the NR team both understands the tech they're monitoring and works with clients. So many of the stats provided are* actionable.

Interesting, because we use New Relic extensively, and I was just thinking of it as the prime example of, "what the hell is the purpose of all these dashboards and what do they mean?"

I was wondering about that too. At my work they extensively use Wily Introscope performance monitoring. It's my first job, so I don't know what other options there are, but Wily seems pretty useful in providing real time and historical data about JVM based applications, as well as other components we use like message queues, time taken by SQL statements, as well as other configurable metrics like process/thread counts, CPU useage, etc.

Wily has dashboards about overall application stats that you can configure, as well as dashboards (?) on a per application level. So I can take a look and see the threads on one JVM are getting stuck and also some SQL statements/service calls are taking longer then expected on that same JVM/overall application. Also useful in dashboards on a per datacenter level to help figure out what's going on.

I'm genuinely curious, because I don't know any better, how do other companies monitor their applications? Anyone else have any comments about Wily monitoring?

Yep! As much as I love New Relic's logging I find that its interface is clunky, things never go to the places I believe they will take me, and there is an extensive amount of information clutter.

It is a one-size-fits-all interface. And I've definitely created my own tools to augment it. But as a first cut, I've found it a hugely useful tool.

Some of the presentations don't do much. The ability to drill in (varies by your platform) and find hot threads and methods is really useful in tuning.

Other data are more useful for the marketing folks (e.g., geocoded data), though they can also point out abuse or other issues.

Srsly, this article seems littered with so many assumptions it's hard to decipher the actual point.

Tachometer has no use? Tell that to professional drivers.

Real time stats are worthless? Not unless you expect a spike in your server load (?) and need to react to it immediately.

If you can't find a use for some number, others may. That's what controls are for. You take the set of data your app (or whatever) has to offer, then you toss in some controls (your job is to make them intuitive so user does actually use them without tears) that can operate on and present the data and then everyone gets to choose what they see.

Bottom line is that the only way you can figure out that something is right for each individual is to give them a choice. The whole no one needs X seems far-fetched (to say the least). Sure you need to talk to users, but they most likely will express different opinions.

Also, don't build more dashboards. What? So we shouldn't improve on our mistakes, right? The concept is so bad that we shouldn't even try because no one (again, assumptions) can build good dashboard. C'mon..

I was hoping for an article that would explain how to design a good dashboard. This isn't it.

There are heuristics in the piece which are useful.

The most critical piece though is: is the data being presented actionable?

Can I do something with it, do I need to do something with it, does it tell me when I need to do something?

Think of the most common dashboard: a car.

It tells you how fast you're going (speedometer), how much fuel you've got, how far you've gone (trip/odometer). Indicators for services or features enabled (lights, hi-beams, turn indicators, hazards). Problems (engine temp, problem lights). Maybe a tach. Automatic transmission indicator, if applicable.

Other chrome is possible: outside temps, compass, and comfort/environment controls (heat/AC, sound system).

But essentially it's a few crucial indicators which either give you current status or tell you there's a problem.

It's not a bad model to start with.

Stephen Few's book, Information Dashboard Design, is about the design industry bible on the subject. (His other books are supposedly good, too.)

As many of the other comments in here have noted, the design of a good dashboard is often "don't design one, you need something else."

>"Corollary: No one needs real-time"

If you've ever run service where you're anticipating a large traffic spike and you need to monitor server stats, real-time statistics are invaluable.

precisely. try running a network of any appreciable throughput (10G+) with 5-minute averages.

Or you release a new version of a game and you notice your arpdau tanks. ;)

Or try to instrument any analytics - and wait to verify they show up in the dashboard correctly.

Or you are a small business owner who just likes to watch what the users are doing in realtime, for fun. Like my mom :)

The heuristic whether to use real-time information is the following and I am paraphrasing Avinash Kaushik:

"Will a decision be made in real-time based on this information?"

If you know exactly what you are waiting for and you know exactly what you will do when it happens, then you should probably automate and optimize that process instead of spending your time building some fancy graphics. And if you don't know what you are waiting for nor what you will do about it, you don't need real time metrics.

What if it's an event that happens infrequently, say 2 times year? In such cases, it wouldn't be worthwhile to spend the time automating when it's easier/cheaper to take manual action.

No, automation is always the answer. When you are forced to formalize processes with code you invariably find all sorts of hidden assumptions. This has happened to me every single time I've tried to automate legacy manual processes. There are always hidden assumptions that are unearthed. Unearthing hidden assumptions is always worth the effort.

http://xkcd.com/1319/

Or maybe http://xkcd.com/1205/

Total time spent on automating plus executing is not a very useful metric, because preparation time and reaction time are not interchangeable.

A hidden assumption behind what you wrote is that all automation is like the scripts you've written to automate your processes.

There are things which automating them would take lots of man-months and tens of thousands of dollars, so much that the effort is not worth it from the savings -- or from any "hidden assumptions" you discover.

You should also consider how much it costs you to miss a part of a process that is manually carried out but that could be automated. If it really expensive to miss something then automation might be a good idea even for simple tasks.

If it truly is not worth the automation, you still don't need real time dashboards, you just need an alarm.

He should have differentiated operational metrics from product (or business) metrics. He seems to be talking about the latter categories.

On this note, is it possible to set up real-time alerts with Google analytics? I'd like to set up an alert like "If the number of real-time simultaneous users rises above n, send an email to this address."

I don't believe it is possible, but it seems like an extremely useful feature.

>"Most KPIs (traffic, revenue) are too volatile on a daily basis to be useful. Yet “last 30 days daily” is more or less the default option."

YES! If you're building a dashboard, don't answer the question "what data do I have?" or "what does the brass say this should be?" But instead, get out and talk to users, find out what data is most important to them, think outside the box, throw some different ideas out there and see what sticks with users.

I can only agree. Especially real-time data. There are only a few cases where real-time might be usefull

If you have a site delivering real time content, such as news, its pretty important.

Not really. Humans are more or less incapable of filtering noise and avoiding making premature choices in realtime. "OMFG, this story blipped upward in a statistically insignificant way. Hype it!" Myself and a colleage ran this experiment several times at a large news organization. Realtime is useful for algorithms, useless for humans.

Of course if you are marketing an analytics product, give the customer a realtime dashboard. It's useless but it makes them feel powerful and in control. The news writers would certainly have thrown a fit if we tried to take away their useless chartbeat.

And often, the end user has no idea what information is useful to them until it is presented. In that way dashboards are great: they help the end user figure out what data is important to them.

> Or because the exec team somehow thinks “we need a dashboard”.

I think many have recognized the demand for dashboards and sprung a cottage industry around it. That is demands often are perverted and sometimes it just comes from an exec wanting to see some "action" or gaining "visibility". They have VC money to spend and will spend money for moving "realtime" colors on the screen.

For the dashboard creators, that is all they need. If someone buys is it. They will keep making it.

On other hand, to disagree with the author. "So what?" People want shitty realtime moving colors because they look cool. Heck, have you seen the crap people pay for in app stores, farmville type games on Facebook and so on. One can criticize the providers and consumer of that crap. Yet they are happily transferring money and product between each other.

> That is demands often are perverted and sometimes it just comes from an exec wanting to see some "action" or gaining "visibility".

Yup. I can't even begin to imagine the amount of time lost on executive or PM useless whims (and how much good could have been achieved with that time and resources).

>People want shitty realtime moving colors because they look cool.

Sometimes we just want a moving graph that looks important, so the boss knows we're working on something.

From a product perspective, dashboards are pretty much expected and required. If you're building something in the 21st century, people expect a central thing that tells people what's going on. If your answer is 'hey dashboards are shitty', customers can use your competitors shitty dashboards and at least feel like they have more insight into whats going on in your product.

Or better yet since dashboards are so terrible, let's all go download 10 million line CSV files. While I've seen my fair share of terrible/useless dashboards, many do provide some sort of insight into the data that previously would have only been gained by aggregating log files or running complex sql queries.

Dashboards are a visualization and interactive tool and like any tool have better and worse uses.

While the OP hits lots of points squarely, I strongly disagree about the "no one needs real time". In particular, any service that does onboarding or signups would be really well served to track new users through the getting started process.

I live in the custom dashboard that I built for my startup.

Screenshot: https://www.evernote.com/shard/s16/sh/c8cdeadc-643d-4028-b58...

It tracks every single signup from provisioning through to successful setup. It lets me easily see if people are flailing trying to get things working and if it looks like they are I send them a personal email like: "It looks like you might be having some issues with picking an email approver address, can I help?"

Having this real-time insight into customer issues lets me provide much better support and from an ROI basis is incredibly worthwhile.

The actual service: https://addons.herokuapp.com/expeditedssl

> Yes, back-end applications need ways to show their users that they’re working

This is probably the only reason many dashboards exist. They're not there to be useful, but to provide proof that the gears are turning behind the system.

> My eternal gratitude to anyone who can tell me what to do with session duration at the hourly level. “People at 4:53AM on Monday stayed longer on the site than at 11:36AM”? So what?

This is so arrogant. If your customers are not interested in target demographics then ok. Generalising this to everyone is not ok.

I agree 99% of the time.

That said, I have an amazing PM who has customized the living heck out of our TFS Dashboard such that it is useful.

Most fun of all is seeing our "daily bug resolved as fix rate" and "daily bug incoming rate". Seeing them as flat numbers in boxes is, IMHO, more useful than seeing them as on a graph.

But yeah, the dashboards I see other teams using? The worst is a bug tracking dash that is updated once every 4 hours. During crunch week, it serves to do not but spread chaos and confusion.

"Take care dashboards for example. They use vast amount of real estate to display information that is useless 99% of the time. How often do you need to know the RPM on an automatic car? Can’t you just take that stupid dial out and put something useful instead?."

Assuming the author meant car, this would be very dangerous (i.e. irreversible engine damage): http://en.wikipedia.org/wiki/Redline

Typo corrected. I'm not saying you should let the users go in the red without knowing. But does it have to be a big dial that takes a 1/3 of the dashboard?

What engine-critical information would you replace the extra real-estate with?

Nothing is always an option. Including anything that is unhelpful dilutes focus on the things that are.

We're talking about an automatic car - make the ECU take over so you can't redline it.

Nobody mentioned astrology or dilution of responsibility?

Dashboards are an astrological tool. Here is an elaborate and complicated process you don't understand to generate numbers that are devoid of meaning, to dilute responsibility when you make a decision that turns out to be wrong.

The article misses this point entirely. A good dashboard from the end user perspective can be used as numerical backup for any arbitrary decision at any time. The author just doesn't get it. Thats why the author is confused by the "just keep adding stuff until I can always use it to justify whatever I want to do".

This is how dashboards are used in practice, this is their actual reason for existing. This is why money is spent on them.

The article is like a debunking of astrology, "well see here, based on the gravitational constant and the distance to this orange vs venus, the square results in ..." and the boss replys with "shut up I don't care about reasons I decided to go to war with eastasia and we've always been at war with eastasia and my astrologer always had my back, and apparently you don't, so lets discuss the effect of all this gravitational formula stuff on your career prospects vs backing me up which you're paid as a yes man to do..."

So, has anyone a constructive article/site/book for good dashboard design? e.g., how you should deal with the mix of daily and monthly data?

https://news.ycombinator.com/item?id=8316264

I've found that replacing a fancy dashboard of key stats with a simple daily email with 5-10 key numbers is far more valuable.

The dirty little secret of the business intelligence / dashboard industry is that no one logs into them.

A daily email helps with this problem, as people tend to read emails, even if its only a glance.

I've gotten a lot of mileage from Mint's dashboards when trying to identify where I'm wasting money. I appreciate their email, but the dashboard is actually tremendously useful.

What are people's favorite examples of good dashboards?

I rail at Google Analytics dashboards all the time. You'd think I would be interested in today's or this week's or this month's numbers, yet there are no options for this in the calendar widget. People who write these things not talking with people who use these things in a meaningful way is a classic type of fail.

My main gripe is with "static" dashboards, i.e. dashboards that don't let you drill down (e.g. to investigate an interesting spike), and has disconnected widgets (i.e. applying a filter to one widget doesn't affect the other widgets).

I completely agree. Most information is nice to know but not actionable at all. It's the reason why we don't have any dashboards. Just periodic updates (weekly and monthly) in static PDFs.

Nothing real time, no dashboards, static data, but customers love it.

I suspect the author is probably right but didn't glean much actionable from the post.

Perhaps you didn't read it enough?

1) Don't just throw all the numbers you have a page. 2) Talk to the users to find what they need measuring 3) Don't multiply controls and options, show fewer specific things 4) Consider what displays will lead to specific actionable insight 4) Don't use specific ranges just so data will change 5) Real time data are mostly gimmicky, don't add it unless it serves a specific purpose 6) Consider if you even need a dashboard in the first place ...

I like your summary much better. I tried reading the article and all I saw was "shitty", "shitty" and "shitty". The author needs to learn how to present information, ironically.

Data Scientist here. Can confirm, most dashboards are shitty. Usually you don't need a dashboard, you need a human who knows how to analyze data to get useful information out of it. A dashboard is not an end goal, an informed decision is.

Read Lean Analytics: http://leananalyticsbook.com/

It mentions the OMTM, One Metric That Matters. When you focus your effort to one number, things get much better.

Dashboard in 1950's GMC trucks is solid. Just two dials. One for speed, the other displays 4 types of engine data.

http://i.imgur.com/g9RUbiF.jpg

Important take-away I've found from building monitoring software: find a way to determine what data your users don't care about and de-emphasise or all-out hide it.

Any examples of great dashboards that people love?

Jira dashboard is actually useful. At least when you choose the right widgets.

Tableau is an awesome data aggregate and dashboard program.

This is something I can really agree about, even if in this context it sounds more like an ad. But I prefer Tableau over some premade dashboard, because Tableau is really incredibly flexible. As far as I know, I haven't seen any dashboard even distantly closing on Tableaus featuers. I just loved using it. Of course there are many tools which can be used to deliver same kind of end results. But the process of creating using Tableau is just wonderful.

The final key with Tableau is the possibility of endlessly refining the data. So you can star with basic dashboard view, but you can narrow it down to the things that really do matter. It's not a dashboard, it's a data discovery tool when used by experienced analyst and great fun for not so experienced guys too. If we compare it to other popular similar tools like QlikView.

Btw. Many of QlivView dashboards are just those top results of Google Dashboard search.

Reply on news.ycombinator.com