taking for granted: URL bars and spellcheck

Just a random thought- if I were timeshifted back a decade or two and had to use the browsers of the time: one thing is how much people got used to one input box that is both the URL as well as a search box. Also, it's kind of cool that spellcheck is now near ubiquitous - I guess that extends beyond the browser and into the OS.

vs code extensions i like

I'm realizing that I really need to get my mojo of making small things in React from scratch (just for practice), I went back to my old Hello, World in Parcel - I was frustrated that my home laptop's version of VS Code wasn't trivial to set up so that it was prettifying like my work machine, and a few guesses at what extensions I might want were R O N G wrong.

So fwiw, at work I've been using:

• Babel JavaScript
• ES7 React/Redux/GraphQL/React-Native snippets
• Prettier - Code formatter
• GitLens - Git supercharged

And I've grown to love that editor.formatOnSave setting...

css gradients, fun and easy

PorchfestMV, Martha's Vineyard, is the latest addition to my small legion of porchfest websites.

They used one of those "Free Logo" sites (honstly, more like $30-50 if you want to actually use it) and came up with:

Not setting the design world on fire, but serviceable. And the use of color gradients provides an easy visual hook for the website:

To make that bar, I made sure the wrapper div has a style position:relative, and then something like
.colorbar {
    height:100%;
    width:10px;
    position: absolute;
    left:-20px;
    background-image: linear-gradient(green, yellow, purple, red, blue);
}
I avoided ROYGBIV order for now, and might go back to color pick the actual colors the logo uses, but for now it's pretty sharp looking, and easy to code.

aesthetic airline art array

I really liked Regan Ray's Airline Logos collection...

weird flex but ok

Guess 'cause I'm still getting over this fever, but it took a few stabs for making a sponsors display like:

(Looking at it now I realized it would have been a decent candidate for grid or even table, though it's nice that flexbox means you don't have to think about lining up with a row-like object)

I admit I'm falling into bad habit of "px" and non-semantic markup, but Oh Well...

(it is sad that it's 2019 and centering vertically isn't an instant no-brainer)

Anyway: markup like this, with "texty" for a sponsor that has no img:

<div class="sponsors">

<div class="texty"><div>Barry's Village Deli</div></div>
<div><img src="/img/sponsors2019/fastsigns.png"></div>
<div><img src="/img/sponsors2019/Justnextdoor.jpg"><div>Just Next Door</div></div>
//...
</div>
And then CSS like


.sponsors {
    display: flex;
    flex-wrap: wrap;
    width: 845px;
    margin: auto;
}
.sponsors > div {
    margin:20px 2px;
    width:270px;
    height:270px;

    display:flex;
    justify-content:center;
    align-items:center;
    flex-direction:column;
    
}
.sponsors > div > div {
    text-align: center;
    width:100%;
}
.sponsors .texty {
    color:white;
    background-color:#2b809e;
    font-size:1.5em;
}
.sponsors img {
    max-width:250px;
    max-height:250px;
}

Spacewar!, exclamation point and all

I am fortunate to be Facebook Friends with Matt McIrvin - as you can see on his blog we share interests in old video games and he has lots of interesting things to say on the topic, not all of which makes to his blog.

He recently posted this video on the PDP-1. The PDP-1 was a computer system of a lot of firsts, including the first programmed video game, "Spacewar!" (in the 1980s, may aspiring geeks learned the story of its development in Steven Levy's book "Hackers: Heroes of the Computer Revolution" - I'm also lucky enough to share a Science + Spirituality reading group with Jack Dennis, one of the characters in it.)

I cued up this video to the Spacewar! section:


The game had a huge influence; you see it's sense of space motion and blasting in the early 80s hit Asteroids and then its 1;1 combat explored deeply in the 1990 game "Star Control", to name the two most obvious examples.

I found some interesting blog posts by Owen Macindoe on the MIT Game Lab site, back in its heyday as Gambit, as they go on a deep dive of the old MIT code:
Investigating the Spacewar! Source
The Night Sky in Spacewar!
Reconstructing the Vector Graphics in Spacewar!

In the video, we see bullets colliding and cancelling each other out - that's a detail that cheap duplicates of the game often miss (possibly being computationally expensive!) but that adds an important defensive aspect. It's also related to something that's always bugged me about the game: if one rocket ship is short stubby and the other long and sleek, isn't that unfair to one player? The answer is probably related to this explanation given by undergraduate Kaivan Wadia in a final blog entry on their work to reconstruct the game on Arduino, The Peculiar Spacewar!:

We finally decided to implement the collision algorithm used in the original game. The original algorithm considered imaginary circles around the spaceship and detected whether any object capable of blowing it up was within that circle. This resulted in a slightly mysterious effect where torpedoes could pass through the spaceship occasionally. Sometimes two spaceships could pass through each other at certain angles. A spaceship could also be blown up by a passing torpedo that was not going to hit it, but was simply within the circle. 

That jives well with this line in the commented source:

 000016 006000 6000  / collision "radius"

from my experience handcoding a lot of games, that's usually a telltale of some fast to calculate but rarely distractingly inaccurate math to know when things hit.

don normalization of user friendly design

Don Norman on user friendly design for the elderly - previously I responded to his "How Apple is Giving Design a Bad Name". I have less to say about this, but I'm glad he's giving more attention to how things look, how superficially it's good when things seem sculptural and not like medical devices.

Don Norman is famous for his book "The Design of Everyday Things". Ironically it didn't originally follow its own maxim of "function over form", since I knew it as its earlier title "The Psychology of Everyday Things" - a clever name that let him use its acronym "POET", but one that created much confusion for bookshelvers, many of whom weren't sure if it was going under psychology or design or what.

human physiology and the art of way too much bass

I needed some new headphones and when I was perusing the options at Best Buy I discovered Skullcandy Crusher Wireless Immersive Bass Headphones. These have powered built-in subwoofers and sport a physical lever that goes from "Not Quite Enough Bass" to "WAY WAY WAY TOO MUCH BASS" - like you're at the restroom at a dance club and the pile of dancefloor speakers is just on the other side of the cinderblock wall.

I'm a tuba player, and I don't know if my affection for bass springs from that, or if it's a special case of how I like things that are easy to "read" without paying attention to nuance. Research supports the idea that Bass makes you feel powerful, so I don't think it's too much of a stretch to say bass-y head phones (especially combined with my "Psyched" mix at work) is a form of self-therapy. (More on our love of and response to bass.)

ux grumble: force touch

For me, the decade's biggest, dumbest "what feature can we add in this year so our new phones seem worth the upgrade" is Apple's Force Touch / 3D Touch.

Who ever thought "man, what I really wish I could do is have to jam my finger HARDER into this flat piece of glass"?

The fact that it's not on all iOS devices sets up the problem - it's not on any iPads, and Apple was comfortable leaving it off the iPhone XR. That means the gesture is always going to be for bonus features and extra functionality - never for the central interaction. iOS (and Macs) famously shun "right clicks", so some apps try to use the Force Touch for context menus - "shortcuts" that actually take longer because they are based on an uncomfortable gesture.

It also raises the question of whether including hardware support for this "feature" interferes with Apple's incessant drive towards thinner and thinner devices - if the need to put in this legacy thing is stifling other technologies that might theoretically be added - like Apple Pencil support... (a long shot, but a boy can dream.)

The trouble is, having to press extra hard intuitively indicates extra urgency, semantically it carries the idea of doing more - not extra foo-foo stuff. There's a fundamental disconnect in the gesture and its use. In apps that don't have a context menu, a simple tap will open up the item (probably with options to edit) while a hard jab pulls up a weird, read-only zoomed in version of what you were already looking at. But like if you're rearranging your homescreen icons... the old "tap then hold" gesture way to easily gets highjacked when the frustrated user presses in just a bit too hard - so instead of the old icons trembling with anticipation of their new home on the screen, you get a useless menu with a single "Share this app" item - probably the least useful, most weirdly self-promoting menu item in all off iOS.

It's a mess. Gestures are a minefield of unintended consequences on part of the user, and this half-implemented extra avenue of input just isn't helping.

UPDATE: looks like the gesture is on the way out anyway. Good riddance!

burn it with fire: css hacks for a js-free messaging client

Oh dear. css-only-chat is a bizarre project that creates a crude, click-each-letter asynch chat client without JS - just CSS.

The README explains the trick - CSS won't load, say, an imag for the active state of a button until the button is active. So we have an easy way of alerting a server a button has been clicked. Combine that with old-school "comet"-like never-really-finish-loading-the-page, keep-the-connection-open tricks and then we can update the page as well- both to see the other person's chat and to reset the buttons since they would otherwise be one-click-only wonders.

Similar CSS-lazy-loading techniques can be used for a crude keylogger or to track mouse movements even when js is disabled.

programmatically making icons in p5

Last year for Porchfest, I made a little P5 to generate icons I could use in Google Maps.
https://editor.p5js.org/kirkjerk/sketches
Here is this years version of the code, that makes icons A-Z and P0-P9:
//maybe run at https://editor.p5js.org/ 

const targets = [];

function setup() {
  createCanvas(27, 43);
  
  //A...Z
  for(let i = 0; i < 26; i++){
    targets.push(String.fromCharCode(65 + i)); 
  }
  //P0 ... P9
  for(let i = 0; i <= 9; i++){
     targets.push('P' + i); 
  }  

  rectMode(CENTER);
frameRate(4);
}
let c = 0;
function draw() {
  clear();
if(c < targets.length) {
  icon(targets[c]);
  }
  c++;
}

function icon(t){

  stroke(255);
  strokeWeight(2);
  fill(128,128,255);
  
  
  beginShape();
  vertex(2,2);
  vertex(width-2,2);
  vertex(width-2,25);
  vertex(width/2,height-2);
  vertex(2,25);
  endShape(CLOSE);
  
  textAlign(CENTER);
  fill(255);
  noStroke();
  textSize(16);
  text(t,width/2,20); 
  let filename = "icon_"+t+".png";
  print(filename);
  saveCanvas(filename,"png");
}

the math behind hofstadter's law

Erik had a thought- or rather, a tweet:

I suspect devs are actually decent at estimating the *median* time to complete a task. Planning is hard because they suck at the *average*.

He then went on to explain Why software projects take longer than you think – a statistical model.

Very very roughly, it's the (almost predictable) outliers that will mess up your plan - easy stuff stays more or less easy, but the hard stuff gulps up all the time.