Are there good solutions for creating (pie) charts that aren't completely opaque to people with color vision deficiencies? This article is especially egregious because I feel like they actually add to the point being made, but for the life of me I can't distinguish some of these colours. Who uses yellow (or orange, idk) for four separate labels?
Perhaps related, does anyone know of an overlay-type application that allows me to colorpick part of the screen (on linux)? My current solution is usually to screenshot and open the image in the GIMP or similar, but it's very cumbersome and especially if there are multiple pictures usually not worth it.
I don't know about any resources for accessible colour picking, but if you're looking for a colour picker to work around badly designed charts, there's Pick[1], which is easy to work with. It also displays you the closest colour name, so you don't need to manually parse hex codes to see the difference.
I'm not aware of any colour disabilities that I have but I found it difficult to parse the colours as well, specifically in the second pie chart (areas). The colours in the chart only work to distinguish one slice from its neighbours, it's near impossible to map them to the categories listed in the legend. Perhaps the author is working on a super-colour-accurate computer screen where this problem isn't as noticeable, but on my older screens these colour profiles are near useless.
If you're in Firefox, you can find a colour picker in the dev tools (top left of the "inspect element" tab). That mostly focuses on devs though, so all you get is HTML colour hex.
I usually find that JS heavy approaches can shine here, like with Chart.js. Here on the donut pie [1] you can hover with your mouse and see the name of the labels and the amount.
Where I like this approach is with big line charts like this one [2] (here it's D3 that's used). I am colorblind, and also not good at following things in general (I can have a hard time counting sequences of similar numbers), and I find charts made this way easier to read.
It seems that to handle this you should have lines between the label and the slice instead of a legend. Google Sheets seems to do this by default but it seems to sort colours from dark to light which may make the boundaries of some colours hard to see for colourblind people. I would assume that putting the slices light-dark-light... would be optimal for the contrast between them, even for people who are not colour vision deficient.
I don’t understand. If you can’t differentiate the colors, you can’t see the boundaries between segments. I think it would have been good to include tables, as well.
EDIT: I see what you’re saying now. You can just read the legend, which lists things in order. But that just gives the ordering, not the sizes of the categories.
What really stood out in the article: It took a lot less time for C mistakes to be fixed vs non C mistakes. That's not saying C is great. More significantly most of the mistake based vulnerabilities took over over half a decade to be identified.
That strikes me as a bad thing. A bug that is easy to fix is a bug that could have been fixed sooner. That's exactly the kind of bug that causes the worst issues. Bugs that are hard to fix but readily identified are at least possible to work around.
I love using Rust for new development but curl is _everywhere_ and a port would need to spend a lot of time copying old quirks. Given how clunky C APIs are, I’d think it’d be better to migrate more of the callers to a higher-level interface anyway.
> A rewrite would introduce new bugs, even if they aren't memory issues.
OTOH, a rewrite could be useful in splitting up the problem-space as well as reducing errors. This is where Ada excels, and one nice way of splitting the problem-space could be in providing types (perhaps with provable properties via SPARK) that properly decompose the problem-space.
-- Small, quick/dirty "back-of-napkin" design.
Package Uniform_Resource_Locator is
Type Protocol is (HTTP, HTTPS, FTP, SFTP, ETC );
Type URL is private;
Function Get_Protocol(Object : URL) return Protocol;
-- other operations.
Function Parse(Text : String) return URL; -- Text to URL.
Function "+"(Object : URL) return String; -- URL to Text.
Private
Type URL is record
--...
end record;
End Uniform_Resource_Locator;
> The rewrite could end up buggier than the original.
Given the properties of a language like Ada, you could decompose the problem-space into types (like above) and leverage the language properties to ensure the correctness of the program. For example, Ada mandates full-coverage on cases can so when you say `case Get_Protocol(The_URL) is ...` you have to provide for every value in the enumeration (Protocol here), and the compiler enforces this. So, every place you have a case-statement operating on a Protocol value, absent the `others` option, the compiler will error-out and point you to the location you're missing a value.
...meaning that you can update the Protocol enumeration and have the compiler complain at every location you need to fix/implement the new protocol.
So is making the UNSAFE FOR ALL, instead of unsafe for few?
Defaults matter.
P.D: Think if web browser were not fixed or improved because maybe somebody is using Win95. Its the same. The path to better is stop using what is proven to be bad (C/C++ is proven to be very bad!). The path to make sure niche platforms are covered is turn what is better in something more popular until it replace the old... and niche platforms use it...
Having worked with him at Mozilla I can assure you that he is familiar with Rust. I'm as much of a Rust fanboy as anyone, but "rewrite it in Rust" is not a simple process, and there are many tradeoffs involved. That being said, I think Rust will continue to improve on this front. Things like the GCC Rust frontend work are promising avenues to expand Rust's reach in terms of supported platforms, and tooling like c2rust will make rewrites simpler. There are also techniques like `RLBox` now that allow compiling C code to WebAssembly and running it in a sandbox which offer mitigation strategies without a full rewrite.
Perhaps related, does anyone know of an overlay-type application that allows me to colorpick part of the screen (on linux)? My current solution is usually to screenshot and open the image in the GIMP or similar, but it's very cumbersome and especially if there are multiple pictures usually not worth it.