on hashchange, on jQuery, on donner, on blitzen

Some coders take on large frameworks because they like some of the features provided - but some of those features can be easily duplicated in systems that have less conceptual overhead, such as jQuery.

One of those features is hash anchor driven navigation, which is pretty decent way of making a one-page-app with back button support, so long as you start with hash page control from the outset and not try to glom it on after.

All you need to do is set up a listener on the window hashchange event:
$(function() {
    $(window).bind('hashchange', hashChanged);
});
(remember that's the short hand for $(document).ready()... I'm not sure that it's not too concise for its own good, frankly.)

Then, your hashChanged function can do whatever it wants with the new value:
function hashChanged(){
    var hash = window.location.hash.slice(1);
    console.log(hash);
}

You can set that hash value programmatically:
window.location.hash = 'someValue';
or you can do it in the DOM, like in a link:
<a href="#someOtherValue">let's go</a>

This is the kind of high-transparency, low-conceptual-and-code overhead coding style I tend to go to for small applications, and maybe even medium-sized ones. Obviously, the actual guts of your hashChanged function can get complex and tangled if you let it, but this is a good building block to know- if you'd rather just install a nice kitchen than buy the whole house.

graph paper days and in-browser transparent png via p5.js

My personal blog ( http://kirk.is ) has been long overdue for a makeover.

For posterity, you can see it's pre-makeover look on the Internet Archive Wayback Machine. I can always tell old HTML of mine when the tags are in all-caps. (<A HREF="http://kirk.is">like this</A>) I've switched, of course, but I still secretly think all caps tags were a bit more readable, standing out more from mixed-case content than the modern xhtml-influenced style.

So I wanted my (15 year old!) daily blog to look like the modern web, which also included simplifying it and making Alien Bill Productions my main "creative works" repository. For what it's worth, I've decided on the simplicity of kottke.org as my main layout influence... but I thought I'd like to make a nice logotype for the header, one influenced by the graphpaper font doodling of my highschool years. (And more recently: graph paper moleskine notebooks are kinda hipster awesome, carrying and using one makes me feel like a more creative person.)

I made a p5.js program to generate some experimental layouts -

The bottom two are the same as the first two, but with a shaded background effect. Ultimately, I'm going to run with the third on the list.

The code is hacky. I switched to p5.js after starting in processing because JSON is so much easier to tool around with than Java HashMap static initializers... The shading is a bit handcoded, because I wanted to let the "graph paper" background show through, so the hidden line removal was trickier than if I draw lines at every vertex and then made the letter fronts opaque polygons.

When I decided to make a version to use on the site, at first I thought I'd just do a screen grab of the webpage, but that meant the transparency info was lost. I was surprised and delighted to see the p5.js has support for generating transparent pngs, that can then be automatically downloaded as a file. The trick is to use clear() instead of the usual background(255) and then do something like saveCanvas("MyImage","png") - and of course, you don't want to put that in a draw() routine being called 60 times a second!

(Oh, and for what it's worth, I updated this blog's p5.js boilerplate to have two examples: one (quick-hack-friendly and more "Processing" like) that pollutes the global namespace and slaps its own canvas on the webpage, and then one that's my original sample code that plays more nicely with a more complicated webpage - everything is properly namespaced, and you can control the canvas tag CSS etc, but you have to prefix API references.)

Anyway. Making a jpeg or transparent .jpg is one of those "oh, I didn't realize a browser could do that" kind of things, like the copy and paste in image right into chrome trick.

UPDATE: Here's one I made just now (October 2016) for this site:

layout matters so very, very much

Steve Harvey misread the final card for the Miss Universe pageant and Miss Colombia had to relinquish her crown to Miss Phillipines... a humiliation for all concerned, but especially for whoever put this piece of crap card together:

Humans make assumptions when they take in information visually: they subconsciously expect things to fall in patterns and rhythms, and making text big and bold doesn't always emphasize: in fact the opposite - it can cause things to be mentally labeled as unimportant background context.

(My friend Josh brought my attention to something I had missed: ELMININATION ?? Man, what a lousy job all around.)

Of course, one of the most infamous examples is the Florida 2000 Election "Butterfly Ballot":

People made assumptions about alignment and spacing and correlation, and so we got Elderly Jewish Reitirees for Buchanan, aka "Pitchfork Pat" - an absolute statistical and demographic anomaly. Because of this terrible layout Florida's electoral votes went to Bush and the popular vote was over-ridden. It is not too much of a stretch to say that the Middle East would look very, very, very different today if someone if someone had been better at their job.

compute's gazette menus and the UX of 5 1/4" floppies: the historic review

My blog of COMPUTE's Gazette games is reaching the end of its run. COMPUTE's Gazette was a magazine for the Commodore 8-bit computers in the 1980s and early '90s, and I've been reviewing every "type-in" game they offered - over 300 items. I think my nostalgia for the magazine is largely driven by the fact I didn't have to type every game in - as a kid I was lucky enough to inherit a pile of the accompanying floppy disks with programs preloaded, and binary copies of those disks are what I've been using for my reviews.

Besides the reviews, I fill out up the blog by writing about what was going on in the industry (and bearing witness to the sad withering away of the Commodore community as PCs came to take over everything) as well as the UI of the disk itself. In some ways, it seems a little obtuse to be critiquing 30 year old UI, but I find it of historical interest to see what they did and of intellectual interest to think about how they could have done it better.

For the earliest issues, they didn't always get the loading quite right; the most canonical way of loading the "main thing" on disk (first in the directory listing) was
LOAD "*",8,1
But sometimes if it was a BASIC program, the ",1" would throw things off (the "8" was just the usual device number of the disk drive, and the "1" referred to loading it in memory like a binary program rather than as BASIC source.)

Still, the menu system was pretty decent, even from the earliest disks (Spring 1984):

They used the "function keys" - on Commodore computers, these were 4 big buttons on the right side of the keyboard. Oddly, you had to get to the even-numbered keys via hitting shift: F2 was "shift-F1", etc. That might explain why eventually they switched to to using numbers instead at the start of 1986:

A minor change, to be sure, but you appreciate it on modern Macs when you have to hold down the "fn" key to get the function keys back to their primeval jobs- I find it intriguing that function keys live on, but they've been repurposed and, on MacBooks at least, taken on specific specialty tasks (screen brightness, volume, multimedia controls - the multimedia controls seem a little odd and context-dependent to me, but hey.)

The deprecation of generic function keys represents progress in UX: we now prefer top level menu items, context menus, or keyboard accelerators. (Interesting that none of these are predominant features for modern touchscreen computing). It seems a lot smarter than the MS-DOS days of Word Perfect 5.1, where you might just slap this handy piece of plastic above your keyboard:

In a form of Stockholm Syndrome, regular users would grow to like these (and the program's "reveal codes" feature, kind of like looking at the HTML source of a webpage, was very useful, but again not great for new users) but clearly we live in a friendlier time.

So, back to Gazette... the menu was all well and good until February 1991 when they unleashed this upon their audience:

This was an era where GEOS, a GUI system, was gaining some popularity, and let the Commodore act more like the Mac/Windows machines, and so they probably tried to take a cue from that. It's an odd choice though: you could use the joystick or the arrow keys (or the mouse if you had one - I think, they were never a big part of the culture) to shove the cursor key around, but it never felt like a natural thing for the system.

Making it worse, to get to the main function of the menu program (i.e. loading the other programs) you had to go to "Monitor" and then "Directory". The next month they improved things a smidge in that the directory listing would automatically load:

Still the whole "Gazette Operating System" is of dubious value. The C64 had a notoriously slow disk drive, and waiting for all this extra crap to load was surely a frustration. (The only thing I can think of with any value are some of the options in the Disk menu, like formatting.) Plus, there just isn't the sophistication of design for employing any keyboard shortcuts: the arrow keys are too busy shoving the pointer around to allow easier navigation from the listing.

This unfortunate era lasted 2 years, and in March of 1993 they were back to text-based, numeric menus.

The last change to their menu system happened when they switched to being a disk-only proposition (they had already lost their standing as an independent publication and were merely a cheap-paper supplement in their parent magazine COMPUTE) For three months, the menu lead off with this return to function keys:

There's an air of pathos in leading with "Advertising"; on the other hand this was an era where Commodore stuff was probably almost impossible to find in retail stores, so there might have been a bit more value to the reader than it first appears, but not much. Anyway, each of those top menus lead to the old reliable numeric menus.

By March they replace this (possibly slower loading? And I wonder if they crafted the large month and year graphic by hand, or had an automated system...) with a humbler version of their old standby:

And that's pretty much where it would stay for the remaining year of publication.

("Press X to Return to BASIC"... I have said before that this era of computers was special to me, in part because using an accessible programming language as a bootloader was so empowering, an invitation for kids and adults alike to make something...)

So a final note before wrapping up. With the switch to disk only (actually before, when they started including bonus programs on disk that they didn't have the page space to print as type-in listings) they were reliant on a text reader program for providing program details or for article content. So for a program you would get through this screen:

and invariably to this reminder of how to use the reader:

It seems to me that that's poor UX, even for the era. I think putting a permanent menu bar on inverse text at the top, with a reminder of the cursor keys and then "O" or something for a menu of options (like changing colors or printing) would have been a lot cleaner. Also, I'm a little surprised they didn't provide a simple "page down" key, like space or return. Cursor keys are the only option, and while they happen to scroll text at a reasonably human rate, it seems like an odd lack, given that the "more" command had been around for over a decade and a half at that point.

The other final thing: I give them kudos that the text reader is pretty well integrated to the menu program, in that when you hit M to go back to the menu, you don't have to wait for disk access, it has stayed in memory. But then to get back to the main menu from the submenu, you hit X instead (and usually there is disk access) - just an odd bit of asymmetry, probably reflecting a programmer's shortut.

So there it is, a decade of Commodore menu UI. It was a fun time... and reviewing these games is some of the most pleasant video game activity I've had all year.

es6 bullet points

A bulletproof view of ES6, the new flavor of JavaScript...

on the internet of things

Last month I attended the Boston 2015 instance of "The Future of Webapps" conference.

It was pretty decent over all. A big theme was "The Internet of Things", making all these appliances and gadgets 'smart'. Josh Clark's Magical UX and the Internet of Things Keynote stood out as an exemplar of the thinking that goes "Lets make the screen disappear by making all the individual things smart". In general, I'm kind of skeptical about this stuff, and if it ever gains a lot of traction I can see a backlash, when people will long for good old light switches and fridges that didn't try to keep themselves stocked on our behalf...

At around 33:00 in that video, he shows a demo of Frog Design's Room-E, where you have a whole area wired up so you can do context-sensitive tricks like point and say "turn on THAT light". It made me think of how prescient Douglas Adams was, writing in the late 70s:

A loud clatter of gunk music flooded through the Heart of Gold cabin as Zaphod searched the sub-etha radio wavebands for news of himself. The machine was rather difficult to operate. For years radios had been operated by means of pressing buttons and turning dials; then as the technology became more sophisticated the controls were made touch-sensitive - you merely had to brush the panels with your fingers; now all you had to do was wave your hand in the general direction of the components and hope. It saved a lot of muscular expenditure of course, but meant that you had to sit infuriatingly still if you wanted to keep listening to the same programme.

When I watch the guy in the video wave his arms to turn on the lights, it makes me wonder... how hard is it to turn on a light, really? But of course the answer to that is "kind of difficult, sometimes" - depending on how well you remember where the switch is, if it's placed up the step near the bulb or on the side or on one of those floor mounted switches of if you're supposed to use the wallswitch, or if you have to make sure both the wallswitch and the lamp switch are aligned get the power flowing. But I think the answer for that problem can be better, consistent design before it will be magic room-watching helpers.

There was another "dialog" section:"Lets order take out" [Projected table display updates] "What did I order last time?" [Shows previous order] "Order that."

I know it's a dumbed-down demo, but the fakeness of it reminds me of how until AI gets really smart, it's generally going to be more annoying to interact with than traditional interfaces. (Except of course in ginned up proof-of-concept videos where people order the same anonymous take out dish time and time again.) I don't know first hand how Cortana and Google Now are doing, but Siri can be maddening with her limitations. You really see the strings and the glue and sticks that hold its form of "intelligence" together. And voice transcription? A mess. It just doesn't use enough of the context to really figure out what you're trying to say. And efforts to let one correct a bad transcription via voice (vs just sighing and pulling up the keyboard) are nascent to the point of non-existance.

But of course, if the AI improves, and these helpers can be really smart... it's like the everyperson can have their own little butler. Great! I'd love a little parrot-like shoulder mounted helper, giving me clues about people's faces and generally interacting with systems on my behalf. Except... man, what a privacy nightmare these things will be.

People's response to Google Glass showed me things I never thought of as a kid daydreaming about glasses with a camera embedded (thinking of how it would be so awesome to ALWAYS be able to take a picture of what I was seeing, instantly) -- in a connected world, everyone around wonders where those pictures might end up, and wants to know when you're taking them.

Whether a robot is helping me out in the world, or sitting around embedded in my house, I have to trust it to a huge degree. (In the USA, having household staff is a luxury of the rich, though I'm led to understand it's more of a middle class thing in, say, India, so maybe folks from there have smarter ideas about how such domestic employers deal with trust and their employees than I do.) Take the case of a butler... even if it's not imminently at risk for being hacked, it's likely to be connected in weird ways to its corporate originators. (And even with today's dumb smart systems like  Siri-- big parts of the AI are offloaded to heavier servers elsewhere, so some kind of connectivity seems mandatory.) These AIs are watching you all the time. (Maybe there will be some protocol for that, like the little greenlight that goes on some webcams when they're active? But even that isn't fully trustworthy...

I dunno. I hate to be that old cranky guy, but I'm a skeptic about this brave new world. When I see stuff like "Amazon Dash Button", a brand-specific unitasker that gives you a physical button in your house to press to re-order your favorite product...  I mean, what's the point? You still have to confirm the order on your phone (and thank goodness, right? Like you wouldn't want your toddler going clicky-clicky-clicky and three days later you get a year's supply of Tide all at once.) I mean, I get why companies would like to us to think that way, but is it any better than just a good UX where you can review and repeat your  previous orders?

(Come to think of it, Amazon Dash is fun to think about as an example of not adhering to "loose coupling" programming ideas. You have a button that connects virtually across space to a store. It can't do anything else, and its operations are super-opaque.)

Products like Dash, and concepts like the connected umbrella that flashes "take me take me!" when you're about to leave the house on a day that will turn rainy, or the magic cup that knows what's in it... so much of this stuff are answers looking for problems. Of course in 2006 I sketched out the robot helper I really long for:

All it does is hang out near my closet and wardrobe and hangup or neatly fold the clothing I hand to it...

my minigames advent calendar

For the past 5 or 6 years I've been doing annual "advent calendars": 25 digital toys or games, each one unlocked every day in December up until Christmas.

While 2014's Ed Emberley is still my favorite, I think this years is a ton of fun... I went over all the games I've made in Processing over the years, picked 25 of the most interesting, made sure each was playable in a modern browser (meaning in processing.js vs Java applets, or in p5.js when I needed to use a javascript-based port of Box2D), and added sounds when it seemed useful,.

In 2012 I started using processing.js for these (and called it "html5 advent" to be buzzword compliant.) In 2013 and for the Emberley I made sure everything was touch friendly- that presented some tough UX issues. This year I didn't worry about that so much, I figure my limited audience will mostly be enjoying these in a browser, and so a few games make use of the keyboard or have similar mechanics that make more sense with the mouse (and its ability to "hover" without clicking). But most of them work ok on phones and tablets as well.

slashdot interviews stack overflow founder

This interview with Jeff Atwood (founder of Stack Overflow) is worth at least a quick skim. It's amazing how that site has become the default to answer so many questions.

As far as I can tell, searches for technical questions often don't start at Stack Overflow, but they often end up there from Google.