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

Canvas Gauges

canvas-gauges.com

Post reply on HN
Print view View original

31–40 of 62 posts

Re: Canvas Gauges

#31

Post by Senji »

ctoth wrote: post #8

These do not appear to be accessible at all. If you use this on your site, I will not be able to read whatever you're trying to tell me, other than by making me look at source. Please don't do that. I know accessibility is hard, and the developers of this were just trying to make something that looks nice and gets the job done. Every time an inaccessible reusable {component, library, toolkit\, framework} is released,…

A dev can simply have a few divs updated in real time to match these canvas elements.

Re: Canvas Gauges

#32

Post by gavinpc »

ctoth wrote: post #8

These do not appear to be accessible at all. If you use this on your site, I will not be able to read whatever you're trying to tell me, other than by making me look at source. Please don't do that. I know accessibility is hard, and the developers of this were just trying to make something that looks nice and gets the job done. Every time an inaccessible reusable {component, library, toolkit\, framework} is released,…

As long as we're on the subject, the gauges don't appear at all if cookies are blocked. Console says "The operation is insecure." This is the case on almost every demo, period, even if they claim to have tested on 8 different platforms.

Just wrap your feature test for localStorage (or sessionStorage) in a try/catch. An `if/then` block is an insufficiently powerful construct for feature testing the storage API. So many times but it's not getting to me. If cookies are blocked, you'll get a security exception when you try to access it. Not even Jon Skeet can feature test for storage without catching the security exception. Unless the gauges actually depend for their operation on some data previously stored on my browser---which is a logical impossibility for a first time visit---then storage can be treated as optional, he comes. This is so prevalent even on simple demo pages that I can only assume people are using a framework that needlessly tries to access localStorage without the requisite try/catch.

TL;DR: Test with cookies blocked!

Re: Canvas Gauges

#33

Post by throwawayIndian »

throwawayReply wrote: post #27
throwawayIndian wrote: post #26

Earlier quoted context omitted.

+1. Totally agree! I hate this bullshit propaganda that goes like "this is skeuomorphic and the other thing is not". There is nothing in the world of software that isn't a skeuomorphic equivalent of some thing or some process that has already existed in this world. Look at Object Oriented Programming, for example. Look at 'Code is poetry' for a comparison. Look at button design. Look at page design {Header, Footer, B…

I didn't say all skeuomorphism is bad, I said that gauges are an example of bad skeuomorphism. Buttons are an example of good skeuomorphism.

So you don't like the "default skin" of the application. That should be pretty easy to replace with something that suits your taste.

Consideration of "good" vs. "bad" of anything is essentially a trait of use vs. them propaganda. Better to skip it.

Yes, buttons are good form of actionable design!

Re: Canvas Gauges

#34

Post by white-flame »

coredog64 wrote: post #28
white-flame wrote: post #24

Earlier quoted context omitted.

There's a reason that automobiles continue using radial gauges: They're the quickest way to convey a scalar value at a glance. It has little to do with acceleration. If you're going to have a monitoring dashboard, radial gauges make immediate sense. (The wobble is dumb, though)

They take up a lot of real estate on a display and aren't particularly easy to read unless you get up close. If you already know what thresholds are it is far better to display a number and use the color to indicate where that is within the continuum of states. There are practical uses for steam gauges, but I would argue that monitoring complex IT systems is not one of them.

Taking up lots of real estate on a display is kind of the point of high-visibility indicators.

Regarding "aren't particularly easy to read", are you talking about reading numbers on the ticks? That's not the point of those indicators; the point is to be familiar with the low/expected/high ranges of the needle for various situations and be able to see with clarity the current state of expected/unexpected range of an indicator. Which then can be further inspected if necessary to focus in and see an exact number.

Re: Canvas Gauges

#35

Post by tamana »

samsolomon wrote: post #19

Gauges generally make for a poor UI. Unless you need real time information to help grasp a change in value, please consider another way to showcase information. Consider showing either a single number, or perhaps a bullet graph if targets, averages or historical values are important. https://en.wikipedia.org/wiki/Bullet_graph

TIL "bullet graph", which makes this whole HN submission worthwhile

Re: Canvas Gauges

#37

Post by strictnein »

ctoth wrote: post #8

These do not appear to be accessible at all. If you use this on your site, I will not be able to read whatever you're trying to tell me, other than by making me look at source. Please don't do that. I know accessibility is hard, and the developers of this were just trying to make something that looks nice and gets the job done. Every time an inaccessible reusable {component, library, toolkit\, framework} is released,…

I'm the defacto accessibility guy at work, and I'm trying to think of a good way to present this type of data in an accessible way, but I'm having trouble. When the gauges are fixed, it would be pretty straight forward, but as the gauges change, I'm not sure of a good way to present that, especially when the gauges are moving quickly.

Re: Canvas Gauges

#38

Post by coldtea »

throwawayIndian wrote: post #33
throwawayReply wrote: post #27

Earlier quoted context omitted.

I didn't say all skeuomorphism is bad, I said that gauges are an example of bad skeuomorphism. Buttons are an example of good skeuomorphism.

So you don't like the "default skin" of the application. That should be pretty easy to replace with something that suits your taste. Consideration of "good" vs. "bad" of anything is essentially a trait of use vs. them propaganda. Better to skip it. Yes, buttons are good form of actionable design!

>Consideration of "good" vs. "bad" of anything is essentially a trait of use vs. them propaganda.

Value judgements are both very, well, valuable AND not "propaganda".

Some things ARE plainly worse than others for some uses or in general too.

Nothing "propagandish" about aknowledging that. Even if you are wrong in your evaluation it's simply a mistake, not propaganda.

Propaganda is a method you employ to convey things (not necessarily judgements even, could be calls to action, warnings, etc) in order to brainwash people to accept them.

As such, it is orthogonal to judging things as good vs bad.

Thus, I deem this argument "bad". And not in a Michael Jackson way.

Re: Canvas Gauges

#39

Post by ctoth »

strictnein wrote: post #37
ctoth wrote: post #8

These do not appear to be accessible at all. If you use this on your site, I will not be able to read whatever you're trying to tell me, other than by making me look at source. Please don't do that. I know accessibility is hard, and the developers of this were just trying to make something that looks nice and gets the job done. Every time an inaccessible reusable {component, library, toolkit\, framework} is released,…

I'm the defacto accessibility guy at work, and I'm trying to think of a good way to present this type of data in an accessible way, but I'm having trouble. When the gauges are fixed, it would be pretty straight forward, but as the gauges change, I'm not sure of a good way to present that, especially when the gauges are moving quickly.

I would probably use an invisible aria-live region coupled with some logic to not spew messages to it too frequently or a minimum change to actually autoread. Could also do something like providing checkboxes only visible to the screen reader to subscribe/unsubscribe from gauge updates. I wonder if any actual web access experts could chime in?

Re: Canvas Gauges

#40

Post by bluetwo »

ctoth wrote: post #39
strictnein wrote: post #37

Earlier quoted context omitted.

I'm the defacto accessibility guy at work, and I'm trying to think of a good way to present this type of data in an accessible way, but I'm having trouble. When the gauges are fixed, it would be pretty straight forward, but as the gauges change, I'm not sure of a good way to present that, especially when the gauges are moving quickly.

I would probably use an invisible aria-live region coupled with some logic to not spew messages to it too frequently or a minimum change to actually autoread. Could also do something like providing checkboxes only visible to the screen reader to subscribe/unsubscribe from gauge updates. I wonder if any actual web access experts could chime in?

It might be as simple as adding the important info in an alt or title attribute that gets updated when the visual does.
Post reply on HN