Canvas Gauges(canvas-gauges.com)
canvas-gauges.com
Canvas Gauges
https://canvas-gauges.com/
61 comments
Thank you, it is simply one of the most useful comments I (as developer) have for the moment. I will look forward to get a clue how to provide accessibility features in the next releases. Shame on me but this was exactly that feature I completely missed off.
One of the properties of governments is tending to take things seriously, whether or not this is a good thing is a discussion that someone else can have. Anyway, the US Federal web guidelines are the sort of thing that a serious organization can produce:
https://standards.usa.gov/getting-started/developers/
and so are the UK's:
https://www.gov.uk/service-manual/helping-people-to-use-your...
On the flip side, because Google penalizes sites for not looking pretty on mobile but not for inaccessibility, day to day we can tend to get caught up in its priorities rather than thinking about accessibility.
Good luck.
https://standards.usa.gov/getting-started/developers/
and so are the UK's:
https://www.gov.uk/service-manual/helping-people-to-use-your...
On the flip side, because Google penalizes sites for not looking pretty on mobile but not for inaccessibility, day to day we can tend to get caught up in its priorities rather than thinking about accessibility.
Good luck.
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!
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!
I tried it on an earlier Chrome (37, well over the v26 they advertise)
javascript.min.js:558 Uncaught TypeError: undefined is not a function
Also see what you see, lots of blankness.
javascript.min.js:558 Uncaught TypeError: undefined is not a function
Also see what you see, lots of blankness.
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.
A. Allow the refresh rate of your gauges to be set, or disabled entirely and only refreshed manually, perhaps with a button (so your user's screen reader can finish at its own pace).
B. Use SVG, and something like D3 to build your graphs with a textual representation. I have no idea if ARIA works in SVG, but I know there are plenty of ways to label your data textually, even without aria-label, etc.
Unfortunately, there's probably no good way to convey information in the same way that visualization does for sighted users (being able to intuit trends from lines, for example), but even just having access to the aggregate numbers in a time series is better than nothing.
B. Use SVG, and something like D3 to build your graphs with a textual representation. I have no idea if ARIA works in SVG, but I know there are plenty of ways to label your data textually, even without aria-label, etc.
Unfortunately, there's probably no good way to convey information in the same way that visualization does for sighted users (being able to intuit trends from lines, for example), but even just having access to the aggregate numbers in a time series is better than nothing.
[deleted]
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?
This is the actual underlying problem, and don't think I'm not aware of it.
Everything is inaccessible by default, and takes special code and knowledge to make it accessible, specialized knowledge that a majority of devs don't have.
Heck, I'm swimming in this every day and I wouldn't consider myself an expert/not sure if my idea for making this particular component accessible would even be the right way (tm) though I'm pretty certain it would at least work.
Probably the long term answer is to just cure blindness. ¯\_(ツ)_/¯
Probably the long term answer is to just cure blindness. ¯\_(ツ)_/¯
> Everything is inaccessible by default
In the early days of the web, when web pages were mostly text, and people weren't using tables for layout, things were a heck of a lot more accessible by default than they are now.
In the early days of the web, when web pages were mostly text, and people weren't using tables for layout, things were a heck of a lot more accessible by default than they are now.
It might be as simple as adding the important info in an alt or title attribute that gets updated when the visual does.
When the "guage" is selected, you could play a series of audio ticks faster or slower as the measure changes?
I'm not sure whether it is all that useful for a generic gauge display component to be accessible - rather, when using them an application author could probably make the overall application far more accessible than the gauge could itself ever be. The application using it has much more context with which to provide an alternative text based representation of the data, right?
In general, its better to bake accessibility in to a thing than to have a separate accessible version. If the gauge is the component for presenting this information, then it should present the information to all users.
My first thought is for the data to be in the HTML as a input type="range," with the readonly attribute and the value updated as needed by JavaScript. An additional ARIA live region attribute to offer guidance on when (or if) changes to the value should be announced would help. The canvas object could either get the range and current value from the input element or whatever JavaScript updates the input value also updates the canvas gauge. As someone else suggested though, SVG is probably a better choice than canvas.
My first thought is for the data to be in the HTML as a input type="range," with the readonly attribute and the value updated as needed by JavaScript. An additional ARIA live region attribute to offer guidance on when (or if) changes to the value should be announced would help. The canvas object could either get the range and current value from the input element or whatever JavaScript updates the input value also updates the canvas gauge. As someone else suggested though, SVG is probably a better choice than canvas.
What is your software setup? How do we test something from your perspective?
If you have an iPhone or Mac, check out VoiceOver, it comes as part of the platform.
http://webaim.org/articles/voiceover/ has a pretty good intro to VoiceOver on the Mac.
I'm on windows, and personally use the free and open source NVDA screen reader http://nvaccess.org Once again it looks like WebAIM have some good instructions to get you started: http://webaim.org/articles/nvda/
I'm on windows, and personally use the free and open source NVDA screen reader http://nvaccess.org Once again it looks like WebAIM have some good instructions to get you started: http://webaim.org/articles/nvda/
A dev can simply have a few divs updated in real time to match these canvas elements.
I think the best way to provide accessibility ... would be a alternative accessibility mode, triggered by the browser, where you get only the plain text-info with no fancy stuff.
(I would love that for surfing with mobile browsers on bad connection, too)
(I would love that for surfing with mobile browsers on bad connection, too)
Some reasons why this is a bad idea:
Who implements it? Every individual website? then we're back where we started, not to mention that everybody's responsible means nobody's responsible, and consequently it won't happen.
The web, for better or worse, is transitioning to an app delivery platform. While a text-only mode of some type makes sense for a document-oriented web, it holds little appeal for app developers or consumers.
Formatting is important. On well marked up sites, I can navigate by heading, flick through form fields, and generally interact both efficiently and pleasantly with the content. Throwing all this out hardly seems like a good path forward.
Who implements it? Every individual website? then we're back where we started, not to mention that everybody's responsible means nobody's responsible, and consequently it won't happen.
The web, for better or worse, is transitioning to an app delivery platform. While a text-only mode of some type makes sense for a document-oriented web, it holds little appeal for app developers or consumers.
Formatting is important. On well marked up sites, I can navigate by heading, flick through form fields, and generally interact both efficiently and pleasantly with the content. Throwing all this out hardly seems like a good path forward.
We have the ADA in America. It's part of the building code that you would have wheelchair ramps, wider stalls, hand rails at certain heights, and other accessibility features and every one of these rules must be implemented by anyone building or maintaining an open to the public/business space.
Of course it should be on the individual implementer to make it work. I wouldn't want someone else taking my concept and running it through an accessibility grinder without my input. It should also be on the individual company/team to decide if it not being accessible is something they're legally or morally okay with. I'd say that if you're building an in browser FPS, maybe there are some accessibility features you don't need because the group has been partially self selected by the fact their vision is good enough to want to play an FPS.
I did a lot of technical work for Target not that long after their big ADA lawsuit so EVERYTHING public facing was reviewed for accessibility. I'll be honest, it's typically not that hard to deliver a great 100% experience to people that do and don't need the accessibility features, you just have to learn what goes into it. And no, aria-hidden, isn't enough.
EDIT: I wanted to add that if you think accessibility means it can't look good, then you really don't know what's available today. You often don't have to make any trade offs to design if you don't want to.
Of course it should be on the individual implementer to make it work. I wouldn't want someone else taking my concept and running it through an accessibility grinder without my input. It should also be on the individual company/team to decide if it not being accessible is something they're legally or morally okay with. I'd say that if you're building an in browser FPS, maybe there are some accessibility features you don't need because the group has been partially self selected by the fact their vision is good enough to want to play an FPS.
I did a lot of technical work for Target not that long after their big ADA lawsuit so EVERYTHING public facing was reviewed for accessibility. I'll be honest, it's typically not that hard to deliver a great 100% experience to people that do and don't need the accessibility features, you just have to learn what goes into it. And no, aria-hidden, isn't enough.
EDIT: I wanted to add that if you think accessibility means it can't look good, then you really don't know what's available today. You often don't have to make any trade offs to design if you don't want to.
That's a great idea, if there were such a thing as overseas homebuilders and small shops like the internet. But the reality is that the internet exists outside of the US, and the ADA cannot tackle every website.
> Who implements it? Every individual website? then we're back where we started, not to mention that everybody's responsible means nobody's responsible, and consequently it won't happen.
Erm, as far as I know, that's the way the web is designed. The person who runs a site is responsible for it. And if this person does not care about accessibility , than that's the way it is.
But usually the owner want as much people as possible to be able to have access.
> While a text-only mode of some type makes sense for a document-oriented web, it holds little appeal for app developers or consumers.
And yes, of course I was refering to document-oriented web.
But apparently you got me totally wrong: I did not mean, "Text only" as in only text. I meant a proper formated html page. Just without fancy javascript and css-animations and so on. And while I actually like those, if they are well designed, I don't like them if I they are in the way of the content I want.
So I'd like a alternative mode. Easy to read on mobile as well on screen-readers etc. ...
Erm, as far as I know, that's the way the web is designed. The person who runs a site is responsible for it. And if this person does not care about accessibility , than that's the way it is.
But usually the owner want as much people as possible to be able to have access.
> While a text-only mode of some type makes sense for a document-oriented web, it holds little appeal for app developers or consumers.
And yes, of course I was refering to document-oriented web.
But apparently you got me totally wrong: I did not mean, "Text only" as in only text. I meant a proper formated html page. Just without fancy javascript and css-animations and so on. And while I actually like those, if they are well designed, I don't like them if I they are in the way of the content I want.
So I'd like a alternative mode. Easy to read on mobile as well on screen-readers etc. ...
It's pretty standard to provide visually-hidden elements in HTML which provide an accessible version of the data. Remember, screen readers are typically directly working with the DOM -- maybe through an abstraction layer provided by the browser and OS -- and can therefore see everything. You don't need to toggle what is visibly shown for screen readers to do their thing properly.
Radial gauges are an example of bad skeuomorphism.
They don't convey any history and more importantly they don't have useful meaning unless you have a measurable first differential (i.e. no step change).
They're useful for literal physical speed, because the movement of the needle helps give a sense of acceleration as well as speed. But if you don't care about acceleration (or more generally the delta of the primary variable) then it's not helpful to have a needle wobble about.
And if that wobble is just artificially added (such as the bouncing thermometer) because it's responding to a step change in a discrete sequence, then it's now removed any sense of reality.
And I've seen even worse of gauges, for example for things which can't even reduce. There's no point having a speedometer type gauge for "percent complete" or other monotonic variable!
Sorry for the rant, you're just responding to a demand. It's a demand I'd rather see met through educating better data visualisation than through prettier gauges.
They don't convey any history and more importantly they don't have useful meaning unless you have a measurable first differential (i.e. no step change).
They're useful for literal physical speed, because the movement of the needle helps give a sense of acceleration as well as speed. But if you don't care about acceleration (or more generally the delta of the primary variable) then it's not helpful to have a needle wobble about.
And if that wobble is just artificially added (such as the bouncing thermometer) because it's responding to a step change in a discrete sequence, then it's now removed any sense of reality.
And I've seen even worse of gauges, for example for things which can't even reduce. There's no point having a speedometer type gauge for "percent complete" or other monotonic variable!
Sorry for the rant, you're just responding to a demand. It's a demand I'd rather see met through educating better data visualisation than through prettier gauges.
I disagree. Radial gauges immediately convey accepted boundaries and where your real time measurement is within those.
For example, I've done a fair bit of racing in my day- we take the tach and any other various gauges and rotate them so that when the needle is pointing straight up, it's where you expect the reading to be.
Say you have a CPU monitor where under a certain threshold reduces nodes in the cluster and over adds. This can vary from application to application and you're monitoring 5. Sure is nice to get the high, low, and current in one glance.
Now, there certainly could be equal as or better ways of displaying it. You could do away with a skeumorphic face for sure. But a radial gauge itself I would argue is very useful.
For example, I've done a fair bit of racing in my day- we take the tach and any other various gauges and rotate them so that when the needle is pointing straight up, it's where you expect the reading to be.
Say you have a CPU monitor where under a certain threshold reduces nodes in the cluster and over adds. This can vary from application to application and you're monitoring 5. Sure is nice to get the high, low, and current in one glance.
Now, there certainly could be equal as or better ways of displaying it. You could do away with a skeumorphic face for sure. But a radial gauge itself I would argue is very useful.
+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, Body} of a webpage. Look at flat design for that matter! Look at iWatch interface with hands of a clock/watch. Look at the dialpad on your mobile phone.
Tell me which one isn't skeuomorphic? Zilch! Yawns… at these skeuomorphism police.
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, Body} of a webpage. Look at flat design for that matter! Look at iWatch interface with hands of a clock/watch. Look at the dialpad on your mobile phone.
Tell me which one isn't skeuomorphic? Zilch! Yawns… at these skeuomorphism police.
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. 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.
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.
I agree with you mostly.
Not with the anti-skeuomorphism tirade however. That is pure propaganda.
Anti-skeuomorphism picked up momentum only after Apple's iOS7 update -- around the time when Tim Cook took over and Apple (and its fanboys) moved away from purpose-inspired design to selling 'flat and clean' (supposedly purpose-oriented) design.
Whether it was good or bad move for them eventually is another subject altogether.
Not with the anti-skeuomorphism tirade however. That is pure propaganda.
Anti-skeuomorphism picked up momentum only after Apple's iOS7 update -- around the time when Tim Cook took over and Apple (and its fanboys) moved away from purpose-inspired design to selling 'flat and clean' (supposedly purpose-oriented) design.
Whether it was good or bad move for them eventually is another subject altogether.
>Not with the anti-skeuomorphism tirade however. That is pure propaganda.
Maybe let's put it this way: a lot of it is misguided and/or throwing the baby with the bathwater.
But it does have some merit in some cases: when the skeuomorphic design dictates the use according to non-existing in the digital world constrains.
For example the dreadful DVD player apps of yore, that mimicked physical DVD players, making us push the same inconvenient buttons we hated on the physical devices too, but without any reason like the physical objects had.
Maybe let's put it this way: a lot of it is misguided and/or throwing the baby with the bathwater.
But it does have some merit in some cases: when the skeuomorphic design dictates the use according to non-existing in the digital world constrains.
For example the dreadful DVD player apps of yore, that mimicked physical DVD players, making us push the same inconvenient buttons we hated on the physical devices too, but without any reason like the physical objects had.
> dreadful DVD player apps of yore, that mimicked physical DVD players, making us push the same inconvenient buttons we hated on the physical devices too.
Yes! But you see those were "bad designs" even in physical world and those were copied over to apps. It's isn't a fault with skeuomorphism per se, but in the design that were referred from.
Yes! But you see those were "bad designs" even in physical world and those were copied over to apps. It's isn't a fault with skeuomorphism per se, but in the design that were referred from.
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)
(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.
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.
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.
> 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.
Since this thread is already on the topic of accessibility, I feel compelled to point out that this is the single worst option when considering colorblindness unless you mean shades of one color.
Since this thread is already on the topic of accessibility, I feel compelled to point out that this is the single worst option when considering colorblindness unless you mean shades of one color.
Many automobiles actually have started using numbers instead of a radial gauge. It has even been suggested it actually prompts drivers to speed less when they can see they are doing 74 in digital rather than convincing themselves the needle is resting on 70.
> Sorry for the rant, you're just responding to a demand. It's a demand I'd rather see met through educating better data visualisation than through prettier gauges.
If there is demand it's probably good to respond to it as it is. There is no need to fucking educate propaganda like you said about skeumorphism or no-skeuomorphism.
Besides can you give one example of any software product that is not skeuomorphic? There is none to begin with. So please stop using this bullshit cultural kool-aid to troll and exclude designs that probably don't suit your elitism.
If there is demand it's probably good to respond to it as it is. There is no need to fucking educate propaganda like you said about skeumorphism or no-skeuomorphism.
Besides can you give one example of any software product that is not skeuomorphic? There is none to begin with. So please stop using this bullshit cultural kool-aid to troll and exclude designs that probably don't suit your elitism.
Please don't comment like this here.
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
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
I've done quite a bit of reading about digital dashboards, and agree. The first example in "Information Dashboard Design" is filled with gauges - and an explanation of why it's a bad design.
Edward Tufte's books are absolutely amazing, and filled with beautiful visualizations: https://www.edwardtufte.com/tufte/books_vdqi.
Stephen Few has several books on dashboards/charting that are really practical. See http://www.perceptualedge.com/examples.php for a taste.
Edward Tufte's books are absolutely amazing, and filled with beautiful visualizations: https://www.edwardtufte.com/tufte/books_vdqi.
Stephen Few has several books on dashboards/charting that are really practical. See http://www.perceptualedge.com/examples.php for a taste.
Why are gauges bad design? Or was it just that the screen was filled with gauges - too much information to be absorbed?
I design power plant control systems and part of that is an HMI using one of wonderware, citect, factory talk, etc.
In general where a number is primarily presented, on the screen where the controls are that will change that number, I try to use a gauge (mostly vertical bar gauges) to show the context for the number. The gauge shows what values are high and low by the scale and I put the low alarm, low trip, high alarm, high trip points on the gauge as yellow and red bands so the operator knows when the value is approaching one of those thresholds. If the alarm or trip is raised the bar colour changes to amber or red if it is alarm/trip so that when the alarm or trip appears in the sequence of event log and they go to the screen where they know what system is displayed it is immediately obvious which variables are over their limits and by how much.
I also usually put a line chart so the operator can see how the variables have changed with time.
I based much of the design on "Alarm Management for Process Control" by Rothenberg and "The High Performance HMI Handbook" by Hollifield and Habibi.
Edit: my vertical bar gauges look pretty similar to the bullet graphs linked by the parent. I generally call the circular car dashboard gauges "wiper gauges" because of the action of the needle I suppose
I design power plant control systems and part of that is an HMI using one of wonderware, citect, factory talk, etc.
In general where a number is primarily presented, on the screen where the controls are that will change that number, I try to use a gauge (mostly vertical bar gauges) to show the context for the number. The gauge shows what values are high and low by the scale and I put the low alarm, low trip, high alarm, high trip points on the gauge as yellow and red bands so the operator knows when the value is approaching one of those thresholds. If the alarm or trip is raised the bar colour changes to amber or red if it is alarm/trip so that when the alarm or trip appears in the sequence of event log and they go to the screen where they know what system is displayed it is immediately obvious which variables are over their limits and by how much.
I also usually put a line chart so the operator can see how the variables have changed with time.
I based much of the design on "Alarm Management for Process Control" by Rothenberg and "The High Performance HMI Handbook" by Hollifield and Habibi.
Edit: my vertical bar gauges look pretty similar to the bullet graphs linked by the parent. I generally call the circular car dashboard gauges "wiper gauges" because of the action of the needle I suppose
TIL "bullet graph", which makes this whole HN submission worthwhile
Looks nice, I may use them.
I noticed in the docs you said they are great for desktop, mobile, or (emphasized) "IoT devices with limited resources". These run on the client side which means they won't typically run on IoT devices unless I'm missing something. What does it have to do with IoT?
I noticed in the docs you said they are great for desktop, mobile, or (emphasized) "IoT devices with limited resources". These run on the client side which means they won't typically run on IoT devices unless I'm missing something. What does it have to do with IoT?
I guess the author is talking about the small codebase, which means every IoT device that has some kind of webinterface has to store and serve less data (library is 10kb gzipped, while a high level chart library like d3 is 77kb). At least in the case where you don't serve libraries from a CDN..
Exactly, that was I meant :)
Maybe that client-rendering doesn't put load on the IoT device serving the page (vs. e.g. rendering an image on it and serving that)
They might mean for use in something that's built on Electron or another cross platform desktop library built with js.
These are totally useless for people relying on assistive technologies, right? Tried VoiceOver and got absolutely nothing.
Thank you for contribution. This definitely a good idea which I will take into account for next releases.
About all this meta-discussion about gauges: What if an application requires constant real-time updates of a lot of little values? Say, a music sequencer? What if you have bars for things where the resolution matters, and then little gauges where you just need a rough ballpark estimate that doesn't take up a lot of screen space? Yes, you can make an accessible music sequencer, and good headphones and hearing are probably more useful than look at a spectrograph or level meters. But still.
What about games? There should be more accessible games. But there will always be inaccessible ones and that's fine, too. Let them have gauges, too, why not.
These gauges can be used irresponsibly, yeah. You know what that reminds me of? Every other web thing. Imagine every time any program or article relating to images on the web is published discussion of it devolved into how images without alt tags are bad, and that images should just be a bonus on top of an accessible description. I'm exaggerating, but to make a point.
I think these gauges look really neat, and while I can't think of a use for them for myself right now either, well, let's come up with some, or don't. Let's look at the code and iterate on it if we want and post our findings. But all this "oh, thing X! all the best practices related to X, let me tell you them" should be a thing on the side, not the predictable main event.
What about games? There should be more accessible games. But there will always be inaccessible ones and that's fine, too. Let them have gauges, too, why not.
These gauges can be used irresponsibly, yeah. You know what that reminds me of? Every other web thing. Imagine every time any program or article relating to images on the web is published discussion of it devolved into how images without alt tags are bad, and that images should just be a bonus on top of an accessible description. I'm exaggerating, but to make a point.
I think these gauges look really neat, and while I can't think of a use for them for myself right now either, well, let's come up with some, or don't. Let's look at the code and iterate on it if we want and post our findings. But all this "oh, thing X! all the best practices related to X, let me tell you them" should be a thing on the side, not the predictable main event.
I heard somebody say "it's a dashboard application, not the dashboard of a car" when discussing gauge components.
For as long as I have worked in products, I have heard customers request and praise round gauge displays in applications.
I think they are amongst the worst data display widgets you can possibly use. They have terrible visual SNR, since most of the visual representation is just borders, backgrounds and other visual gimmicks.
I think they are amongst the worst data display widgets you can possibly use. They have terrible visual SNR, since most of the visual representation is just borders, backgrounds and other visual gimmicks.
I made something similar, but a bit more accessible using SVG, that works in ractive (but would be happy to change it to vanilla js or react, if there is a demand) https://www.npmjs.com/package/ractive-gauge it can be styled, or the SVG can be swapped out fairly easily.
I prefer http://justgage.com/ less skeuomorphic and more modern looking.
Used by https://freeboard.io/ which is a decent dashboard I have forked for some personal IoT stuff.
Used by https://freeboard.io/ which is a decent dashboard I have forked for some personal IoT stuff.
Doesn't work on Ubuntu 12.04's Chromium. (Chromium 37.0.2062.120 (Developer Build 281580) Ubuntu 12.04)
Please update (perhaps by switching to getting Chromium from a PPA). Chromium 37 is nearly 2 years old, and is missing many features and many security fixes.
[deleted]
I don't have a good answer here, just a plea to consider accessibility when designing stuff that's meant to be some variety of reusable widget.