Thursday, June 27, 2024

humans and robots, working toget

 Interview with the CEO/President of CodaMetrix (my new company)

As a kid, thinking of the computer-y future (and literally wondering when Bill Gates was going to make a program that wrote other programs) I kept up what was mostly a romantic, sci-fi driven hope that the best results were going to be from humans cooperating with computers, rather than either acting alone.

In a lot of ways that's where we are at now. Anecdotally, a lot of programmers are finding ChatGPT and its ilk enormously helpful as a "second pair of eyes" and as a well read but distinctly junior level paired-programmer. Similarly, I'm happy to have a role here on UX/UI at CodaMetrix, enabling pulling humans back in the loop either for specific medical coding issues and for providing informed guidance and oversight on the overall process.


Wednesday, June 19, 2024


 I Will Fucking Piledrive You If You Mention AI Again - really very thoughtful piece:

The crux of my raging hatred is not that I *hate* LLMs or the generative AI craze. I had my fun with Copilot before I decided that it was making me stupider - it's impressive, but not actually *suitable* for anything more than churning out boilerplate. Nothing wrong with that, but it did not end up being the crazy productivity booster that I thought it would be, because *programming is designing* and these tools aren't good enough (yet) to assist me with this seriously
The thing is, in an age where frontend programming libraries and toolkits have just EXPLODED like mushrooms and we have more "flavors of the month" than a Baskin-Robins in a timelapse, "churning out [customized!] boilerplate" is an enormously helpful thing.

Tuesday, June 4, 2024

when usability misthinks and security nightmares go hand in hand


Why is Microsoft so hell bent on making this security nightmare?

Like, even putting the security dangers aside, it's such a weird usability misthink (IMO; I'm sure some segment of users would appreciate it.) Like, you sort of need to embrace the ephemeral nature of day-to-day digital, and take steps to recognize what you want to preserve, and come up with a mechanism and structure that works for you to preserve it. Leaning on the computer playing "Little Big Brother" as a convenience feature is no way to live.

I think of parallel examples from a simpler age: bookmark managers. Every browser would like to be your main bookmark repository, since that increase the browsers value (and "stickiness") to you. But early on, I took the HTML page that Netscape Navigator was using internally to store your bookmarks (yes I'm old) and put that on my rented webspace. (yes I'm an old geek) Then I could use any browser at work or home and do my own conscious curation of what bookmarks were worth keeping.

(As an old geek aside: I am appalled at the universality of linkrot. A Good URL can and should live forever, us old school geeks thought, and I try to live up to that with my personal sites - but this seems to be an increasingly rare approach, and maybe one in fifteen links I have on my old 90s bookmarks page still works)

Similarly, a lot of product lines try to lure users with being able to pick up on one device where another one leaves off - like handing off from a phone's browser to the laptop or vice versa. I'm not a purist against cross-device sharing - I rely on Apple's shared clipboard fairly often - but making a "seamless" handoff seems like a fool's errand to me, and as likely to startle the user as to be helpful - they are different devices with different use modes, and when the need to transfer does occur.... I mean that's what URLs have always been for.

This isn't a black and white issue. There are some kind of "ease of use" features I depend on - like I don't usually need my browser to record my bookmarks, but I DO lean on autocomplete for website URLs pretty heavily, and if i switch to a completely new machine it's a pain in the butt for a few days. But recording all my activity via screengrabs (and recording lots of stuff as plain text?) What a disastrous mixup of "can" and "should", one of the most idiotic paths in the current AI arms race.

css gives html new options for whitespace

Back in the day, one of the hardest things to get used to with HTML was how it treated white space; any linebreak in the source code wouldn't show up in the final page, and in fact its only concept of white space was "none" "a space" or "some linebreak caused by a <br> or <p> tag"

Different content systems aspiring for some flavor of WYSIWYG had to decide how treat carriage returns - the simplest, like what my homebrew CMS for my blog does, is replace "\n" with "<br>\n". More typographically elegant systems would use <p> tags - BUT - there was always some xhtml-days guilt about having to wrap paragraphs in "<p></p>", and then ambiguity about when you wanted a single line break vs a full on paragraph break.

(Also there was always the <pre></pre> tag for preserving ALL line breaks and other white space- but this was like the opposite of responsive design)

But these days CSS offers another good option:

white-space: pre-wrap;

This seems to do a great job of preserving both carriage returns as they are in the text, as well as preserving collections of spaces (where you used to have to use convert &nbsp; to get the same effect). You can use the mere "pre" setting to get back to full <pre>-tag like behavior without having to use non-semantic" tags

I probably can't retrofit my blog with this... too much of my old content was too free with the whitespace in general, but it's good to know about for future projects.