Thursday, January 28, 2016

artsy css animations

A friend of a friend made a cyberPunkGenerator, sprouting slogans and doing it's best to look like an old crappy VHS playback. It's an intriguing use of some css animations such as blur, flick, and jump.

Wednesday, January 27, 2016

quotes from "Dreaming in Code"

"The realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs."
--Maurice Wilkes, in 1949, at the dawn of the age of debugging computer programs.

"The hard thing about building software is deciding what to say, not saying it."
--Frederick Brooks

"Is it possible to do great work without great pressure, or is pressure an indispensable part of genius?"
--Michael Toy

"Joy is an asset. It may well turn out that one of the most important effects of open source’s success will be to teach us that play is the most economically efficient mode of creative work."
--Eric Raymond

"All programmers are optimists. Perhaps the hundreds of nitty frustrations drive away all but those who habitually focus on the end goal. Perhaps it is merely that computers are young, programmers are younger, and the young are always optimists."
--Frederick Brooks

"Front ends are supposed to be elegant, intuitive, versatile; back ends are supposed to be invisible, efficient, rock-solid. The front end talks to people; the back end talks to bits. In Star Wars terms, the front end is the butlerish C3PO; the back end is the unintelligible R2D2."
--Scott Rosenberg

We are still building our software cottage-industry-style today.
--Brad Cox

"There's a difference between transparency aimed at giving visibility and transparency that is aimed at producing collaboration.”
--Ted Leung

"If it takes the typical programmer more than two minutes and twenty-seven seconds to find something, they will conclude it does not exist and therefore will reinvent it."
--Larry Constantine.

My thought on that last one... Yes, but: The price of learning and configuring and tweaking a large system that almost does the required job - and could be similarly battered into shape of handling lots of other tasks- is often larger than the cost of making an original, smaller bit of code that just handles the matter at hand. and, that is also more fun. Or as Rosenberg puts it later in the book: "There is almost always something you can pull off the shelf that will satisfy many of your needs. But usually the parts of what you need done that your off-the-shelf code won’t handle are the very parts that make your new project different, unique, innovative--and they’re why you’re building it in the first place."

Or as he even later refines it:

"Rosenberg’s Law: Software is easy to make, except when you want it to do something new. And then, of course, there is a corollary: The only software that’s worth making is software that does something new."
--Scott Rosenberg, "Dreaming in Code"

Tuesday, January 26, 2016

unit tests vs integration tests

I admit my understanding of unit tests is still a work in progress... I still don't get:

  • how they don't just test implementation
  • how you expect developers to hunt for something they really don't want to find (i.e. problems with their implementation... I mean if they could think of it, they would have solved it in the code, right?)
  • how they work in a world dependent on side effects: if it's a function, inputs in, output out, that's pretty straightforward. But so much of UI, say, is the evil of "side effects", changing something else in the environment that the user will see...
Anyway, a coworker said the following tweet made him think of me...

Thursday, January 21, 2016

the bees' ease

Bees & Bombs is Dave Whyte's site where he posts what has become a garden of beautiful hypnotic looping animations.

Once upon a time, he mentioned his secret was this equation:
3x2 - 2x3
This is an easing he frequently relied on.... as x varies from 0 to 1, it also varies from 0 to 1, but at various rates. (One of my first posts on this blog was about various easings, the equations you can add to transitions and animations in order to make less boring and linear and more organic.)

At one point he mentioned he had switched to Paolo Ceric's easing equation which goes like this:
float ease(float p, float g){
  if (p < 0.5) 
    return 0.5 * pow(2*p, g);
    return 1 - 0.5 * pow(2*(1 - p), g);

It's pretty rad because you can change the value of g and get different results: 1 is linear, like you were doing no easing at all, while a value of 8 would be a long windup and slow down and a quick motion in between.

The link above has an animation that shows Paolo's equation in action for various values of g for linear motion... I decided to make a rotation based animation to see it work, and also to compare it to the Bees & Bombs original formula:

That's kind of a long transition, here it is with every other frame skipped:

Here's the Processing program I used to make the animation. I had some problems with the GifMaker library, so I ended up tweaking the final GIF by hand using, a new-to-me useful site for making and manipulating Animated GIFs.

Tuesday, January 19, 2016

the dawn of debugging

"The realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs."
--Maurice Wilkes, in 1949, at the dawn of the age of debugging computer programs.

git branch in shell prompt

It's probably reasonably well known, but adding something like

parse_git_branch() {
        git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'

export PS1="\u@\h \W\[\033[32m\]\$(parse_git_branch)\[\033[00m\] $ "

to your .bashrc will show you the git branch you're on, if any, for the current folder. 

That's actually wordier than I prefer my shell prompt to be: \u@\h gave me my current user and computer name... I use sudo etc sparingly enough that the former is pointless, and the hostname isn't neccesary because on this machine only I use an emoji instead of the traditional "$" at the end. (It was slightly tricky getting an entry from the emoji keyboard (on OSX, that's ctrl-cmd-space) into emacs where I happened to be editing the file... I had to jump out to the prompt, do a 
cat > ~/temp
type the emoji, then insert (ctrl-x i) that file into the .bashrc as I edited it in emacs.

I like having a goofy emoji in my prompt, it visually sets off where the current folder info stops and where the command begins. And it's fun.

Saturday, January 9, 2016

on "How Apple is Giving Design a Bad Name"

A collaborator of mine wrote me:

Not sure if you saw this.

My response was as follows:


There are some parts I agree with, and some I'd go even further with -- for instance, rumors are very strong that Apple will probably ditch the traditional headphone jack with this Autumn's new phone release, ticking off many, many people, mostly in the name of making a phone slimmer by, like, a millimeter or two. (Now, Apple has led the way in ditching things before people realized they didn't need them - see the iMac w/o floppy disk in 1998 - but this feels like one of the worst ones, because I was able to use that jack for a number of different scenarios that will now need some kind of dongle) I think the parallel with design leading the parade and minimalism above everything is pretty clear.

Of course, Apple is special because they are about the only ones who have really been doing hardware and software, though Microsoft has been getting back to that lately. There's an integration there that the other makers generally can't match.

One instance of Apple vs Android's design aesthetic: I heard one Android fan argue how much more sophisticated Android's home screens look, because the icons could be any shape, while Apple constrains icons to be little jewel-like rounded rectangles - while Apple fans might feel the opposite, that the constraints still allow artitic freedom of color and design while providing a sophisticated and consistent look. In some ways that's the Android vs Apple thing in a nutshell.

I've read Bruce Tognazzini and Don Norman, the authors for a while. Both are great, but I have issues with both of them.

Don Norman wrote the famous Design of Everyday Things... in it he chastises things that are overdesigned and "probably won lots of awards" when they don't think about the thing's use in the real world enough. Ironically, that's a cobbler's children have no shoes scenario, because originally his book - which won lots of awards - was called the PSYCHOLOGY of Everyday Things -- a title he loved because of the well-designed abbreviation "POET" but which didn't think enough about the actual use in the real world, like if booksellers would know what section to put it in!

Bruce Tognazzini... my main issue with him is that he is a "if you can't meter it, it doesn't matter" guy. Maybe his most well known advocacy is for Fitt's Law: "The time to acquire a target is a function of the distance to and size of the target." So he advocates making buttons big, and stuff them right in the corner of screens, so that a mouse can just be shoved there and thus cursor-targetting-in time minimized. He leads what I think of as the "stopwatch brigade" of interaction design; the faster you can click something (as often demonstrated in some arbitrary and not-real-world like testing mock up), the faster you're operating the machine, the happier you are, etc.

For instance, that Fitt's Law bit rips into Windows' tendency to give each window its own dropdown menu, vs the Mac habit of putting a single bar at the top of the window. I thought it was a wash: it might be easier to put a mouse right on a menu item, but it's also much easier to accidentally think you're dealing with one program's menu when actually context has been switched to another. Combined with modern tendencies to have multiple, and extremely large, monitors, and his advice seems increasingly out of date - sometimes on a Mac there's just too much screen geography between the window with the content and the menu items that apply to it. (And in general, I think you see more important stuff moved to toolbars anyway.)

What Tog doesn't talk about (as much) is: how easy or hard is it for a user to keep a mental model of the system in his or her head? That's a concept that resists easy measuring, and so it gets less play. I think it's critical though, and something that the minimalists get more right than he does. Actually, the Tog/Norman article does talk about "mental load" but again tries to oversimplify, implying that every gesture must be independently memorized (rather than making sense in a larger physical metaphor) and that every gesture is as needed as every other one. Many good UIs will allow for basic interaction with onscreen components, and reserve the gestures for "expert mode" stuff.

Discoverability is important, and I'm not a big fan of having a big library of gestures (mostly because I tend to trigger them accidentally all the time, and so find them violating The Tao of Programming: a program should always do that which startles the user the least.) I'd say it's nice if the road to learning those expert gestures is embedded in the program, but not necessary.

I also feel this article implies that all of the same use cases and patterns apply independent of the physical attributes of the device (and that all users are expert users) -- but laptops are used in very different ways than phones and tablets. There are some principles that apply to both, and while we might expect to see more drawing together so you can get more work-work done via a touchscreen device and a laptop might have more fun and simplicity, there's still a big divide.

Friday, January 8, 2016

textarea selection interaction

I've been running a blog with daily entires for 15 years. A while back i switched it to be mostly a Twitter/Tumbler like format, with quick quotes or links collated as a single day separated by little breaks.

The blog serves as my statement of record, so often I'm copying and pasting links entries I'd shared on FB (where my community of readers and friends has by and large moved...)

I've always prefered a raw HTML editor for this (vs WYSIWYG) but typing up endless<a href="">links</a> can be a bit fiddly, so a tool that would turn the highlighted text into a link would be sweet. I figured I had 3 main use cases:
  1. I have the text I want to turn into a link highlighted
  2. I have a link I went to make clickable highlighted
  3. If I'm copy from FB, I tend to lead with the link, and then maybe the next few words should be the clickable text.
Short story long, I used jquery-textrange and the following shows off three links and how they are treated:

Here is the heuristic code...

function linky_maintext_normal(){
  var jqo = jQuery("#maintext_normal");
  var selectedText = jqo.textrange('get').text;
  var url = ""; 
  var clickText = "";
  if(selectedText.indexOf('http') == 0) {
       var spaceLocation = selectedText.indexOf(' ');
       if(spaceLocation == -1) {
          url = selectedText; 
       } else {
          url = selectedText.substring(0, spaceLocation);
          clickText = selectedText.substring(spaceLocation+1);
  } else {
    clickText = selectedText;
  jqo.textrange('replace','<a href="'+url+'">'+clickText+'</a>')

The logic had to be a little clunky and special-case-y, but good enough.

I think textarea selected range manipulation is a very powerful tool, since it gives the poweruser the chance to see what was changed and make further modifications, vs custom modals or, worse, server round-trips.

(UPDATE: in 2021 I made up the vanilla JS version of this.... I don't cover the "with some descriptive text" case, I had forgotten I put that feature in so never use it, it's kind of cleaner to be all or nothing tbh)

Thursday, January 7, 2016

facebook's delayed notification and other unsound sounds

We're seeing more "gratuitous" sound effects here and there; there's a slightly overwrought chime when you select a clip in the "One Second Everyday" app, and they're all over the Facebook app. Overall I applaud this, as adding to the "juiciness" of sites, and giving immediate, somewhat visceral feedback to user actions.

One thing I don't agree with on the Facebook web version is "caching" notification sound effects until the window is brought to the front - an alert that's not cancelled even if you've read the notification that triggered the sound. I guess it's good to mute notifications if the window is hidden - so if you have multiple FB tabs open, you don't get 3 or 4 little dings in rapid succession. But then playing the pent up ding is weird, as it causes the user to go hunting for a non-existant new event.

On the other hand, Apple is sporting an example of what happens when you don't do enough sound suppression... if you don't disable it, the default is patching incoming cellphone calls to your Mac, your iPad, etc. Suffice it to say, suddenly having 3 different devices blaring at you is not exactly a soothing or top-notch user experience... I feel like they should use some heuristics to only allow one device to do audible notifications in a given proximity.

Tuesday, January 5, 2016

awesome year-end javascript and other fine newsletters

I recommend to Javascript Weekly to every front end developer; their recent Best of 2015 collection was fantastic. Specifically I liked a re-introduction to JavaScript (man, it's so funny how much productive work you can do while still getting rusty on some of the finer scoping details) and also A Baseline for Front-End/JS Developers. Other lesser links that week I liked: John Resig's annotated original jQuery source and The Problem with Angular that recapitulated many of my misgivings with the platform in a very adult-sounding way.

Email-based newsletters are intriguing; they seem to have great signal/noise ratios. Besides Javascript Weekly, I've been enjoying Dave Pell's NextDraft to be a great, smart view of the news. Recently, Shaun McGill (formerly of the nice Lost in Mobile blog) has thrown his hat into the ring with TiQ (timely. interesting. quick.) promising 5 tech items and 5 more general things every day.

(McGill's  How Did We Get to the iPhone essay (formerly on the web, now a cheap Kindle buy) is brilliant, and while I'll always look fondly back on the Palm, I now regret not having jumped on the Psion when it was around...)

cnet is a hot mess

Wow. Followed some clickbait from Facebook ("16 super-collectible 'Star Wars' toys your mom probably threw out") and got this usability disaster:
This is nearly maximized on my MacBook Air screen. Everything is fixed in place but half the screen real estate is take up ads and a ginormously padded navigation bar. The caption content is that piece on the lower right, and it actually starts with a big square-ish ad mirroring the LG banner ad above... I really had no idea where the content was at first. Once I figured out that I could scroll that part down to see the actual text (with weirdly wonky scrolling), I still couldn't read the right side of the text until I adjusted the browser to be less tall than the screen.

Oh wait, it gets worse: if you move the mouse over the right navigation arrow, a hovering social media bar pops up with an invisible background that blocks the clicking (and hover color change) for the top half of the arrow, even though all the visible content for the share this is way to the left:
What a joke.

Monday, January 4, 2016

walking pace

I'm amused that Google Maps for IOS clearly wasn't tested in a walking city such as Boston; even when on a walking route it gives you real time turn directions blocks ahead of time, as if you were zipping along in a car.

Sunday, January 3, 2016

website obesity and the downfall of the participatory web

Maciej Ceglowski on The Website Obesity Crisis. The emphasis starts on what's going on in the browser (and I could write multiple articles on how I feel it vindicates many of my views about a preference for bespoke, vanilla JS using libraries over coneptually-heavy, opaque monolithic frameworks) but hits on the server as well:
I don't want to harsh on the cloud. Some of my best friends are in the cloud.

Rather, I want to remind everyone there’s plenty of room at the bottom. Developers today work on top of too many layers to notice how powerful the technology has become. It’s a reverse princess-and-the-pea problem.

The same thing happens in the browser. The core technology is so fast and good that we’ve been able to pile crap on top of it and still have it work tolerably well.

One way to make your website shine is by having the courage to let the browser do what it's optimized to do. Don't assume that all your frameworks and tooling are saving you time or money.

Unfortunately, complexity has become a bit of a bragging point. People boast to one another about what's in their 'stack', and share tips about how to manage it.

"Stack" is the backend equivalent to the word "polyfill". Both of them are signs that you are radically overcomplicating your design.
Later he talks about how he pays $1000/month for his hosting, vs $9-$25K/month for a competitor's AWS usage. Here I'm going to put in a plug for a service I dig, phpwebhosting. I rent a Virtual Private Server from them for $25/month (even though frankly their shared server for $10/month may have just met my needs as well.) All my stuff is a bit petty ante, and if anything I made ever truly "made it" I might have a bit of a scramble for a new way of deploying my stuff; but I know my JP Porchfest Site survives thousands of users on the big day. And this is an example of where design matters; Somerville's Porchfest was definitely the area thought leader that inspired my crew, but every year their website crashes; they have somewhat more users pounding on their site but I'm sure it's because every request for bands hits their database, while I was foresightful enough to "bake" all our band information as static data, and do any processing in the browser.

At the risk of spoilering the ending, he wraps up his presentation with this idea:
The way to keep giant companies from sterilizing the Internet is to make their sites irrelevant. If all the cool stuff happens elsewhere, people will follow. We did this with AOL and Prodigy, and we can do it again.

For this to happen, it's vital that the web stay participatory. That means not just making sites small enough so the whole world can visit them, but small enough so that people can learn to build their own, by example.

I don't care about bloat because it's inefficient. I care about it because it makes the web inaccessible.
I love the sentiment, in some ways I've been its posterchild, but man... Facebook, Twitter, Instagram, Tumblr, all bank on the same idea: the aggregated feed. You have one stop shopping for a bunch of people you find interesting, either because you know them in real life, or because they write pithy bon mots, or make interesting images, or find cool stuff.  You don't have to click around a bunch of stuff, the good stuff comes to you. (And unlike RSS, each has developed its own flavor of content that doesn't get ripped out in a post-facto aggregation process.)

I keep up my personal blog as my statement of record, but I no longer expect people to follow me there. And I don't know what a return to the small, folksy web could look, especially if you don't have it dependent on yet another ad-driven, privacy-disdaining, bloat-tending entity like Google or Bing... maybe we could all go back to "Web Rings"?