elections and bad graphs

 

Many people are deeply curious about the demographics of yesterday's rather startling voting results.

I think back to Edward Tufte and "The Visual Display of Quantitative Information", and the importance of making intuitive visual charts I'd say this CNN piece ,while providing some critical insight, fails in terms of clarity - for example:

It took me some pondering to figure out what I was looking at: each rectangular block is an *overlay* of the two voting patterns (D/R). So the height of the "roof" is where you see the winner-in-that-demographic sticking up above the votes for the less popular side.

I was pondering how to improve that. One obvious choice would be a stacked graph. Admittedly with so many totals hovering around 50 it might be harder to see who actually won (and the top of the stack, where it failed to hit 100%, would be "who voted for one of the two major parties"). Or possibly glue one candidate to the "ceiling" - though choosing which partyis over the other might look like bias.

Another helpful tweak might be to change the key floating above, so that the sample blue w/ top outline, red with top outline bars were both in middle, and *partially* overlapping. That would make it more clear that each graph leaned on overlap, and so the purple blend was the point where the candidates were neck and neck, so to speak.

Here's another misleading graph:

I saw this posted with the sardonic caption "Thanks Dads!". But Trump voters were just 58% of only 13% of the voters, or about 7.5% - Men without children were "only" 53%, but at 34% of the voting population they were 18%. A good chart would provide a feel both the size of each demographic as well as showing the breakdown.

the joy of simple custom handcrafted webapps

For a long time my partner and I used a shared Google Doc for a grocery list - it was great that it was real time and all, but kind of fiddly - hard to click the little checkboxes, and Google Docs is slow on a phone. So I made up a simple grocery list webapp. 

 

I'm sure there's a billion of these out there, but I had some particular preferences:
* very easy to check off things on phone
* works on this ANCIENT iPad I now have set up as a permanent screen in the kitchen
* no chance someone is going to start trying to charge me a subscription
* items to get are sorted by the section of the store they're in
* you can add a comment to an item
* recently checked off items (in the last 60 minutes - arbitrary but effective) show up as crossed off items below
* checked off and older items are sorted alphabetically

In the interest of UI simplicity there are a few weirdnesses: no actual "checkboxes", you can only edit the section or note for an active item, and only delete an archived item, but honestly I think got the UI just right for our needs.

keeping an eye on those logs

 With ChatGPT's help I came up with 

#!/bin/bash

tail -f LOGLINK/error.log &

TAIL_PID=$!

while true; do

read -n 1 key

if [[ $key == "c" ]]; then

clear

fi

done

ctrl-l wasn't working to clear the screen, so I could get a fresher view of new errors, but now I can just press c.

good at making ui, bad at using it

I always joke that one reason I’m good at making UIs is I’m pretty poor at using them.

Case in point: I was always wanting a system-wide easy to use “audio output selector, independent of any app.

The closest was under that bluetooth thing, but even once this control panel was open, it was another tap to open the top left panel, then a long tap to open the bluetooth list.

Somehow I never saw the AirPlay icon I was hoping for, up there in the top right.

(it was drawn to my attention by a “how to get a damn Sonos speaker working” video, but the frustration with Sonos is another story)

today's css weirdness: display:contents

display:contents is a little weird... basically it kinda sorta just removes the object - like assuming it's some kind of parent, its just showing the kids kinda raw.

intuitive-ish

I prefer a 3 screen layout when at a desk with my Mac, but couldn't figure out what determined which screen got the Dock - sometimes it would jump for no apparent reason, and other times I wish I could make it go to another screen because it was interfering with a full screen display.

Turns out it's dead simple: pushing the mouse to the bottom of the screen (and a little beyond, I guess) puts the Dock on that screen. I think there's a good chance that having learned it I will remember it - so something can have that "semi-intuitive" flavor but discoverability can still be weak.

(I guess I should say I also like to have the Dock visible and not auto-hiding (I suspect auto-hiding may be the source of "move cursor to where you expect the Dock to be to make it show up there.) I suppose I like being able to see which Dock icon I'm aiming for as the pointer moves there, rather than waiting til the Dock shows up...)

frank m taylor on front-end development

Spoilers from the ending of Frank M Taylor's spirited, foul-mouth  Rant about Front-end Development:

• Think and care about the content first. Because that’s what the users care about. Assume the users’ interests are more important than your own.
• Quit acting like CSS is some giant-ass mistake that needs fixing. A group of people who were collectively smarter than us wrote those specs. They didn’t make mistakes. Assume you are making the mistake, not them.
• Server-side rendering was not invented with JavaScript and it doesn’t have to be implemented with JavaScript. There are many ways to render content on a server. Assume non-JavaScript solutions existed first.
• JavaScript either is neither the God-send nor the hell-spawn for your project. It is a tool which you can choose to use incorrectly. Learn when JavaScript is the right tool for the job.
• Quit doing hard things for simple problems. Quit doing things that are degrees of difficulty harder than the problem. When a problem presents itself, look for multiple solutions, and then choose the simplest one. Assume the simplest solution is the best one.
• Quit chasing the new and shiny in your day job. I, too, am excited about the new and shiny. But I put a 2-year buffer between me and prod because I don’t want to be the person to have to discover browser bugs, framework bugs, or even compiler bugs. 

 I think my main point of disagreement comes earlier in the article: "The new and shiny is fun for side projects. It is not for production." I think the new and shiny is for self-education only - at least if your side project is something you want to maintain over the years. Writing something in a toolkit you barely understood and then never used again is not a recipe for something you can fix and grow later.