Canvas Gauges
canvas-gauges.com
canvas-gauges.com
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.
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.
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.
(I would love that for surfing with mobile browsers on bad connection, too)
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.
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.
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. ...
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/
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!
javascript.min.js:558 Uncaught TypeError: undefined is not a function
Also see what you see, lots of blankness.
Probably the long term answer is to just cure blindness. ¯\_(ツ)_/¯
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.
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.
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.
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.
(The wobble is dumb, though)
There are practical uses for steam gauges, but I would argue that monitoring complex IT systems is not one of them.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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
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.
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 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?
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 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.
Used by https://freeboard.io/ which is a decent dashboard I have forked for some personal IoT stuff.