Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The laws of shitty dashboards

attackwithnumbers.com

Post reply on HN
Print view View original

41–50 of 126 posts

Re: The laws of shitty dashboards

#41

Post by dkarapetyan »

error54 wrote: post #30
saosebastiao wrote: post #17

Earlier quoted context omitted.

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.

Re: The laws of shitty dashboards

#42

Post by dredmorbius »

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.

Re: The laws of shitty dashboards

#43

Post by dredmorbius »

skybrian wrote: post #5

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.

Re: The laws of shitty dashboards

#44

Post by userbinator »

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...

Re: The laws of shitty dashboards

#45

Post by nsmartt »

mehh wrote: post #25
nsmartt wrote: post #12

Earlier quoted context omitted.

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 entire…

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.

Re: The laws of shitty dashboards

#47

Post by ams6110 »

cvburgess wrote: post #26
aunty_helen wrote: post #19

>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 somethi…

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.

Re: The laws of shitty dashboards

#48

Post by ams6110 »

dkarapetyan wrote: post #41
error54 wrote: post #30

Earlier quoted context omitted.

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/

Re: The laws of shitty dashboards

#49

Post by paulojreis »

rdtsc wrote: post #23

> 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…

> 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).

Post reply on HN