Kirk's UI Dev Blog

the pirate kart

2012-03-07T13:46:00.001-08:00

I do have a real post pending (need to figure something out with jsfiddle) but meanwhile I'd like to talk about the 2012-in-one Glorious Developers Konference Kollection Pirate Kart. It has its ultimate origin on a place called Glorious Trainwrecks, a site launched to praise terrible 90s homebrew shareware but now dedicated to the proposition that every can make games, and should.

The Pirate Kart of course shares that sensibility. The most recent Kart had been assembled for the Indie Games Festival Main Competition. Then there was a bit of a... political? motivation? It was meant as a playful argument against the "scenesterism" that sometimes haunts "Indie Games" as a movement.

The Glorious Trainwrecks has always had a spirit of openness, though originally there was an emphasis on use of a particularly peculiar no-programming game construction kit called "Klik and Play" (which is why Ks show up a lot on the site and its offshoots, a trend that as a guy named Kirk I kan only applaud) which let people whip together a game in the 2-hour Klik of the Month Klub events.

Personally, I tend to program in Processing (sometimes making Processing.js variants) which has the added benefit of keeping my Java skills from completely rusting. But more than that, making silly, 2-hour-game prototypes has given me a deeper sense of easy-to-code-but-juicy physics that really helps me make more intriguing and attractive UIs.

Anyway, here are my 5 games! Click to play them online and get some more details about the background story.

shave face race

robotish

dinobeeboxer

hit or missile

action figure fighter

Of all of these, "action figure fighter" is probably my favorite, "robotish" is the best from a game-playing standpoint, and "dinobeeboxer" is just weird and cool.

death of the mouse: film at 11

2012-02-21T11:06:00.000-08:00

"It's Time to Exterminate the Mouse" reads Mat Honan's Gizmodo headline, the lead feature for the site. And at the risk of sounding like a cranky old man, I think he has an extremely half-assed understanding of how people and computers interact. His whole tone is kinda provocative and juvenile, to the extent that the whole article feels like a troll. After a few potshots complaining about how 8-bit this hardware feels and how "anyone pushing them with new computers is selling crap" (NB: this point is stronger than it would be otherwise because he's tangentially talking about desktop systems, which are even more on the way out than mice..) he rhetorically asks:

When was the last time you really loved a mouse? When was the last time you were like, "damn, this is a great mouse and I enjoy using it?"

That's an easy one-- the last time I tried to do coding work on my laptop for a few hours. Going back to the mouse after a day on the touchpad is a blessed relief... stuck with just the touchpad for a day, an almost tangible pressure of annoyance builds and builds.

He then gives examples of a gesture I agree with the utility of: pinch to zoom is pretty decent and intutive. And I think inertial scrolling is probably a bit better than the scrollwheel, and definitely (usually) better than manipulating a page pointer by finger or mousepoint.

Then he says

Today at any given time we may be running 20 apps at once, with a dozen or more browser windows open, while trying to sort through more data in a few seconds than an early Cray supercomputer saw over the course of its lifetime. And yet we still use tools designed for a simpler time, with simpler needs.

Which is true, but how is that an argument for gestures etc over the mouse? The iPad and the iPhone are lovely because they do ONE thing at once. In fact, much of the physicality comes from the way your glass slab has temporarily been turned a unitasking device for that activity. You need a lot of real estate to pinch and slide and poke.

It goes on...

Gesture-based computing gives us far more precision and control over the interface. We can manipulate not just points but entire screens. We can perform complex actions that once required keyboard shortcuts, with just our fingertips.

Precision? Really? And keyboard shortcuts are nerdy but they are full of precision and control. Plus, you can see easily written descriptions of what keyboard shortcut goes with what command...

He then points to the Kinect as REALLY ahead of the curve with this stuff. Admittedly I was an early adopter, but using the Kinect to navigate the most simple menus is a nightmare. Each game invents its own paradigm for "select this option" (some use a swipe, some use a hold, etc) and for "back" and "pause". With the right game, using your body as the controller is fun as heck, but that's because you have a great mapping to a physical activity. (Ironically, the one place he admits to the superiority of the mouse is for FPS games. I was going to argue that the other way games have better interfaces is with the two stick controller and all those buttons, but then again each game has its own buttons to learn, and it only really works well because of the physicality of it.)

Other advantages of the mouse: has this guy ever heard of "gorilla arm"? That's what your arm feels like after a few hours of poke, poke, poke at the screen. For people who work long hours in front of a computer, you need something that's not going to tire you out. (Not to mention all the greasy fingerprints...)

Similarly, Mouse use on screen pointers. These pointers are nice because they keep state on the screen even when you put your hand down for typing. This allows bimodal systems that react to your projected interest (for example, hover states on buttons as you mouse around.) in a different way from your project intent (some form of clicking). Very few gesture systems carry that, and with the rise of touch devices, the hover state might be on its way out.

Also gestures tend to have poor discoverability. There are only a few universal moves (the zoom pinch, the swipe, the slide) and everything else varies greatly-- in fact, what a swipe "means" will vary from app to app. (Maybe if there was a universal "help I need the cheat sheet!" gesture?) So you get to a new app (or better yet to an old one you haven't used in a while) the answer to "how do I use this" might not be so clear.

Many gestures are residents of the universe of "moves the user can make unintentionally". Sometimes I mouse and shake a window on my Windows 7 machine, and suddenly all the other windows are minimized, including my chat windows and virtual post-its and things I like to keep around. And there's no real "Undo" for that, so I have to go and finds the things I wanted open. It's a clear violation of the Dao of UX, which is "a computer should always do that which surprises the user least."

So I might be sounding like that old "get off my lawn!" geezer. I might be underestimating the ability for gestures to standardize (they already are, like the "two finger scroll" on Macs) as well as having an exaggerated sense of the limitations of touchpads, since I often use these nasty tiny PC things that lack both the 2-finger-scrolling and the generous dimensions of Apple's Magic Touchpad... Still, I think this article is a overly provocative and insufficiently thought out or balanced. On the other hand, it lets me (and the majority of the Gizmodo commenters by the look of it) feel as if they're rather smarter than the author.

inputWrapper: default text and masks

2012-02-20T13:12:00.000-08:00

I'll start with my usual disclaimer: this blog is meant to be notes to my future self along with stuff other developers might find useful, with code snippets that suffer from a heap of my inexperience and the usual "Get It Done!"/"Worse is Better" rush of my employer, and so isn't always representative of js and jquery best practices. (That said, the stuff we come up with is well-QA'd and I always aim to make robust and readable code, so there is that.)

A common UI trick is to have a text entry field that has a prompt in the body of the input itself that goes away when the box is clicked on, and returns if the box is left without text. (A UX note is in many cases you don't want the box to be otherwise unlabled (no matter how slick your designer is trying to make the form) since that label goes away when text is entered, and depending on the context, the user might not know what the data he or she entered means.)

A while back we experimented with different techniques for making this effect, and came up with the following. It's a function that you call as follows:
makeInputDefault(".selectorForInputField",
"Prompt To Put There","some_unique_identifier");

It's a little wonky... possibly it should be wrapped in as a proper chainable jquery function, and having the developer pick a unique identifier is a bit odd.

What the code does is make a sibling span that actually covers the input box. The js for that is

function makeInputDefault(sel, def, classForSpan){
$(sel).blur(function(){inputDefault_inputBlur(this);});
$(sel).focus(function(){inputDefault_inputFocus(this);});
wrapperIdCounter = wrapperIdCounter + 1;

var inputWrapperID = "inputWrapperId_" + wrapperIdCounter;
$(sel).wrap("<div class='inputWrapper' id='" + inputWrapperID + "'>");
$(sel).parent("div").append('<span class="unpicked" onclick="inputDefault_spanClick(this);" style="display: inline;">'+def+'</span>');

if(classForSpan != undefined){
$(sel).siblings(".unpicked").addClass(classForSpan);
}

if($(sel).val() != ""){
$(sel).siblings(".unpicked").hide();
}
setTimeout(function() { inputDefault_inputLoad("#" + inputWrapperID) }, 500);
}

function inputDefault_spanClick(obj) {
ccdebug('spanClick');
var currentSpan = $(obj);
var currentInput = currentSpan.parent().find("input");
currentInput.focus();
}
function inputDefault_inputFocus(obj) {
ccdebug('inputFocus');
var currentInput = $(obj);
var currentSpan = currentInput.parent().find("span");
currentSpan.fadeOut(250);
}
function inputDefault_inputBlur(sel) {
ccdebug('inputBlur');
var currentInput = $(sel);
var currentSpan = currentInput.parent().find("span");
if(currentInput.val() == "") {
currentSpan.fadeIn(250);
}

}
//this next function makes sure we initialize to the right state,
//in terms of showing the overlay or not...
function inputDefault_inputLoad(obj) {
var currentWrapper = $(obj);
var currentInput = currentWrapper.find("input");
var currentSpan = currentWrapper.find("span.unpicked");
if(currentInput.val() == "") {
currentSpan.show();
} else {
currentSpan.hide();
}
}

(I think the timeout is a hack to cope with browsers auto-filling the field after the sibling tag had been rendered...)

This goes with a jot of CSS:

.inputWrapper {

padding: 2px;

position: relative;

}

.inputWrapper input, select {

border: 1px solid #D7D7D7;

color: #666666;

font-size: 16px;

width: 150px;

}

.inputWrapper span{

position: absolute;

top:3px;

left:6px;

display:none;

}

.inputWrapper .picked {

color:#666666;

}

.inputWrapper .unpicked {

color:#D7D7D7;

}

So that seems to work ok. But why is it so complex? this dailycoding article outlines a method that is much more straightforward, and keeps the default text with the HTML. Well, I found two reasons... one is we are also using this masked Input plugin to autofill the field with hyphens, and it kind of short circuits the simpler prompt method. Another is (and this is a guess) that the dailycoding technique means you have to check if the current input value is equal to the prompt, and ignore it accordingly, when the form data is actually used.

I guess my overall suggestion is to use the dailycoding technique first (nice site btw, I just subscribed to its feed) and then use something like this span technique if the straightforward way isn't up to par.

a bit of wisdom to my future self

2012-02-16T08:14:00.001-08:00

Future self, when having to resize elements based on some other elements' animation of size or position, you will get better results if you put a callback at the end of animate() rather than trying to read the size or position right there and then.

Cheers!

basalmiq's big blue arrow

2012-02-13T14:07:00.000-08:00

At my company, our product owners like to sketch things out in basalmiq, layout-mockup software that makes it easy to give a rough outline of what the various product screens should look like. What's nice about basalmiq is that everything has a clean but crude look, as if someone with a very clean style was sketching it on a whiteboard:

The deliberate crudeness lets people reviewing see the bigger picture, and not got tripped up on commenting on small details of the design. (As is the reviewer's wont, I know from personal experience.)

The program's "presentation mode" has a beautiful UX detail I simply adore. It features an oversized mouse pointer, so that people in the back of the room can see what you're pointing to. But MORE than that, they have the pointer rotate so that it's always directed at the center. It took me a second to realize that was the simple algorithm they were using, because in practice it does a terrific job of subtly grabbing the eye and really seeing what's being pointed at.

I used processing.js to mockup a replica of it in action, full of this that and the other... (my apologies, and sympathies, to users of older versions of IE)

It's such a great idea-- really thinking outside the box. Or rather, noticing that there was a box to think outside of. UX detail at its finest.

basic diy pubsub

2012-02-07T13:47:00.000-08:00

So to solve a problem at work I wrote a basic pubsub, a publish/subscribe model so parts of our page can notify other parts of events they care about... it's a powerful design pattern for decoupling various components on a page. There are other implementations we coulda used, but it's pretty fun and easy to roll our own, I think the resulting code is small and robust:
var localDataBreaker = new function(){
this.callbacks = {};
this.subscribe = function(event,id,funk){
if(this.callbacks[event] == undefined){
this.callbacks[event] = {};
}
this.callbacks[event][id] = funk;

}
this.unsubscribe = function(event,id){
if(this.callbacks[event] != undefined){
delete(this.callbacks[event][id]);
}
}

this.publish = function(event,args){
if(this.callbacks[event] != undefined){
for(key in this.callbacks[event]){
var funk = this.callbacks[event][key];
funk(args);
}
}
}

}

(I like the idea of functions subscribing with a string key for later unsubscriptions, that seemed safer than assuming there will be a reference to the same function handy when a function wants to stop listening.)

So here's a basic test of it... we subscribe to event "foo" with an anonymous function that we key with "bar", we practice firing "foo", then we also subscribe with an event tagged "baz", we see both fire when the event occurs, then we remove "bar" and see just "baz" fire when we fire the event a third time.

localDataBreaker.subscribe("foo","bar",function(o){alert('bar:'+o);});
localDataBreaker.publish("foo",'event 1 after just bar ');
localDataBreaker.subscribe("foo","baz",function(o){alert('baz:'+o);});
localDataBreaker.publish("foo",'event 2 after bar and baz ');
localDataBreaker.unsubscribe("foo",'bar');
localDataBreaker.publish("foo",'event 3 after bar removed ');

onerror and busted images

2012-02-02T12:05:00.000-08:00

My company's site alleyoop.com just had its big public launch! Hooray for us!

So we have a lot of Math "subtopics", each with its own representative image. Those image files live in the file system, but the subtopic names live in the database (with the front end getting the list of available subtopics from various endpoints.)

We use the subtopic name as the file name, which is of course asking for trouble a little bit, but in practice it works ok, and it's a lot easier for our design people to work with meaningful long file names than having to look up unique IDs.

To make sure all subtopics had correctly named art, I made a QA tool that polls the endpoints and slaps up the images. I found an easy way to get generate a list of the broken images, so that we don't have to carefully inspect the whole very long page by hand... I build the HTML with something like

buf += "<pre>"+showname+"</pre>"
+"<img src='"+path+name+".png' onerror='doerror(this)' >\n";

I know some people prefer to build objects with templates (though I'm sad that my favorite templating for jQuery isn't gonna make it outta beta) or with DOM objects... (which annoy me a little, because now I have two ways of making up parts of a page, by writing HTML, or the "language of DOM elements". I'd rather speak one language when possible!) but this is more than adequate for most purposes, especially quick and dirty QA purposes...

So that "onerror" nicely gets called when the image is indeed busted, and so I have a function doerror that takes the object and does this:

function doerror(o){
var parts = o.src.split("/");
var name = parts[parts.length-1];
name = name.substring(0,name.length-4);
name = replaceAll(name, "%20"," ");
$("#error").append(name+"<br>");
}

(I should probably have it replace escaped ^s not just spaces...)

So that works well, and is a powerful way of quickly detecting broken image references before they make it into production.

BONUS TIP:

Our work laptops all have encrypted harddrives, so sometimes when we transfer files straight to PC from Mac via IM, the files all show up with green filenames, and Apache Tomcat can't actually display the files! In that case I have to select all the files, right click to Properties, click "Advanced..." and then uncheck "Encrypt conctents to secure data".

bounding rectangles 101

2012-01-27T11:58:00.000-08:00

I'm very psyched to be doing the Global Game Jam for the fourth time-- all around the world people form small teams in order to make interesting games, all over one-48-hour weekend.

Something that comes up often in game programming is the question "did this thing hit this other thing?" Often, the easiest way of figuring that out is using "bounding rectangles", changing the question to the simpler-to-code "does the box corresponding to this thing's outline overlap the box corresponding to this other thing's outline?" (Even if you need to do a finer-grained collision detection, it's often more efficient to start with this question.)

But even with this simplification, it's not a trivial thing to code. If you code like I do, you'll be having two objects, each with an x,y coordinate for their top corner, and a width and a height (referred to now from w and h). My class in (processing/processing.js) to represent that is something like this:

class boxish{
    float w,h,x,y;
    color c;
    
    boxish(float px,float py,float pw,float ph,color pc){
            x = px;
            y = py;
            w = pw;
            h = ph;
            c = pc;
    }
    
    void draw(){
        fill(c);
        rect(x,y,w,h);        
    }    
}

that lets me create a box, give it a color, and then ask it do draw itself.

So now what?

The first simplification of "do these boxes overlap?" can be "do these boxes overlap horizontally AND vertically"? Because two boxes could be around the same x-coordinate, but if one is way higher than the other one, they won't overlap-- and vice versa for the y-coordinate. By breaking down the problem this way, we're turning our 2 dimensional issue into a 2 1 dimensional ones... much easier!

The trivial code for this is

boolean overlapBox(boxish b1, boxish b2){
    if(overlapHoriz(b1,b2) && overlapVert(b1,b2)){
        return true;
    } else {
        return false;    
    }
}

Ok. Lets start with the Horizontal 1D problem. We have 2 line segments, and we need to know if they touch each other. There are 6 possibilities, outline here in this crude diagram:

I don't know about you, but my takeaway was this: there are more ways for two lines to overlap than for them not to... therefore, we're going to just test for the two cases where they don't - namely where both of line1's points are to the left of line 2's left or both the points are to the right of line 2's right.

So my code was:

boolean overlapHoriz(boxish b1, boxish b2){

float b1left = b1.x;

float b1right = b1.x+b1.w;

float b2left = b2.x;

float b2right = b2.x+b2.w;

if(b1left < b2left && b1right < b2left) return false;

if(b1left > b2right && b1right > b2right) return false;

return true;

}

overlapVert() should be pretty obvious from that.

So that's it. I put together the following little test program that changes color when the moving box overlaps one of the static ones:

You can see the full psj sourcecode here.

a simple jquery slot machine effect

2012-01-18T13:21:00.000-08:00

For work they wanted a "juicy" (I've been promoting use of that term for pleasingly physical or generally pleasant animations) way of showing a randomly generated amount of virtual currency assigned to the user. I suggested a slot machine-effect, and it came out really nicely, a widget with a very high "coolness to code complexity" ratio.

Here's another version of what I quickly came up with, click to spin!

The final product for work was a bit different, a single little rotating slot with graphical icons and more polish, (including a nice fade in behind once the final amount was displayed). But for messing about purposes, I simplified the display, threw in a few extra windows, and made the results A B C D or F.

You can see the html, js, and css here.

There's very little too it, really: each slot consists of an outer class "slots" that provides the border and has a hidden overflow. Inside each slot is a (very tall) "wrapper", and then the js code adds a bunch of divs of class "slot", each as wide as the wrapper and each containing a random letter. When it's time to let things "spin", we just animate the wrapper's margin-top property to a multiple (7) of the negative height of a single slot. Some of the secret sauce is the easing, "easeOutElastic" from the jQuery easing module... I wrote about that easing stuff earlier.

If the user clicks again, we repeat the process, adding in extra divs of class slot, and moving an increased seven times the height from where it was before. There are some little tricks going on here: we add more divs than we actually need because the elastic animation overshoots a bit (and of course, it's not really circular like a real slot machine would be), it took a while to realize that you should just move a small # of slots, and I added some randomness to the length of time of the animation, so it didn't all move in lockstep. It would be easy to tweak the timing so slots 2 and 3 started after 1, for a kind of 1....2...3! effect. (Another thing I added for this demo was the use of the "stop()" command... otherwise repeated spin clicks would have to wait until the earlier spins were fully settled. stop() has some arguments I missed when I first learned about i~~t, they didn't come in handy here,~~ but let you control if the element/animation queue finishes the pending animation(s) or just stops cold to start the new one. (Actually it turns out I needed to stop() the animation, including the parameter to jump to the final position, before reading the old position to set the new goal.)

Stuff like this is a great argument for jQuery/CSS UI engineers to err on the side of building things from scratch rather than relying on gluing together pre-existing bits. If I had only used other people's slideshow modules, rather than realizing it was a simple matter of wrapper divs, overflow:hidden, and animating margins, I wouldn't know enough to put this together... but it's really quite simple when you treat jQuery and CSS as the empowering technologies that they are.

BONUS PROTIP: This animation read the old margin-top in order to set the new one
jqo.css("margin-top"); //jqo is the jQuery object
That returns a value like "100px". To get rid of the "px" and treat that as an integer, parseInt works very well, it's designed to read numbers at the start of a string and then stop when it encounters non-digits:
var marginTop = parseInt(jqo.css("margin-top"), 10);
(The 10 after makes sure that we keep things in base 10, if the number string started with, say, a "0", strange things might result.)
Of course after you've done your math you need to append the "px" again, but you know that already, right?

on smaller frameworks

2012-01-12T09:10:00.000-08:00

(This is a response to Gordon L Hempton's blogpost Javascript Frameworks Are Too Small)

Interesting article link you posted. Why don't we have as many layer of abstractions for web development? One answer might be, each of levels Queru describes is built on a REALLY reliable and well-engineered level beneath it, and there isn't that kind of solidity under JS/HTML5. But I think the other answer is: it's not necessary, at least for a certain kind of developer.

I can't even tell you how foreign I find your proclamation given the choice between two frameworks with equally well-written code, I would probably opt for the larger framework

There's a valid outlook that's the opposite of this: it says, I want to learn as little new as possible to get the job done, to minimize the mental load my tools are causing me. Toolkits with lots of abstraction often don't have good power/weight ratios; they're not much more expressive than more basic toolkits, but there's a lot more you new unique knowledge you have to keep in your head to use them properly (lest you become one of those Microsoft-y types, who can do decent stuff but have NO idea what's going on under the hood, or how to fix it when it goes wrong in a deep way.)

I think more abstract toolkits tend to program in nouns... "configure me correctly/learn which of my calls will do your bidding, and I'll do all the "tough work" and you can keep commanding on high rather than dirtying your hands in the trenches". But the cost of that comes in debugging, where suddenly the result of your bug is more likely to be farther away -- "physically" in the files, mentally in the abstraction -- than if you kept your toolbox nice and light and focused on the solving the problems that are actually a pain in the butt to keep resolving. (jQuery being one of the shining examples of awesomeness for the latter.)

I agree that "a larger amount of energy goes towards dealing with the frameworks involved, rather than the problem being solved" but not in the sense you mean: finding people who know the intricacies of a new stack, or training up people to get that knowledge, is the expense...

jquery animating background positions (and colors)

2012-01-06T10:33:00.000-08:00

Short but sweet: "background-position" tends to be a compound kind of setting, with a separate value for x and y, but the single key. This means jQuery's default animation function can't smooth animate it, like it can't animate color transitions. But just like how there's a plugin to let you animate colors there's one for backgroundPosition as well. There's not much to it besides what the page says. I stuck copies of both on my "just in case the links go away" jquery file archive at http://kirkjerk.com/m/files/.

juicy in 2012: bouncy topicgrid

2012-01-05T10:23:00.000-08:00

This is a work in progress for my day job, but I'm digging it so far: squares that jiggle on hover, then expand to twice the size when you "hold".

(Live demo from http://kirkjerk.com/m/files/kirkdev/topicgrid/) These are all divs positioned absolutely with a containing div. The "shove the small blocks out of the way" routine our UX guy Marco was looking for was hard to wrap my head around at first. Say we're growing 0-0, doubling its height and width so it takes 4 spaces instead of 1, a net change of 3 spaces. We start by shoving the columns topped by 0-1 and 1-1 straight down, freeing 2 of the squares. We then shove 1-0 to the right, freeing up the final square. And to make room for 1-0, the column topped by 2-0 has to be pushed down. (But if the block we're growing is on the right side of the layout we change its position so that it grows to the left, and that changes which side our single column down is on.) It seems pretty simple (to me, now) when I write it out (3 groups of blocks to move: the 2 cols. underneath, the singleton off to the side, the single col. down to make room for the singleton) but I kind of had to sleep on it to get the general case.

(The other UI guy Ben pointed out the cool flexible zooming grid at the Adidas homepage -- that looks like it was an even cooler challenge.)

The other fun and educational part was the "jiggle" when you hover the mouse over a block-- this creates a small juicy "toy" as you sweep your mouse across the whole area. My first idea was trying to use one of the bounce-y easings, but keep the block the same size. This did precisely nothing... I think the easings generally depend on multiples of the difference between two values like width/height or position so you can't "ease in place". I then tried the JQuery UI effect "bounce", but it assumes you have something that can be positioned "relative" on the page, and left the div stuck to the top left when it was done. So I rolled my own, using a series of animations (using the built-in linear easing instead of the default swing)- it animates to random x and y offsets, then animates to half the opposite of those values, then settles back to where it was.

This isn't perfected yet, but it's pretty good. I had to look into different techniques for restoring the squares... I thought always stop()ing the animation would help, but that just got blocks stuck. So now it just adds the move onto the animation queues, but it works out, in part because things are pretty briskly paced.

osx vs windows redux

2011-12-29T17:29:00.000-08:00

Ranting on obscure blogs is a bit like tossing nickels into the Grand Canyon, but... hey, a nickel!

I sometimes jump the gun in criticizing Apple and OSX. Too often that comes from inexperience with OSX. In many cases, a serious criticism of "you can't do this on a Mac" (for example, easily copying the path information from an open Finder window into a "Save As" dialog) runs head on into a "Mac just does it a different way, you Windows-muddled fool" (you can drag the little folder icon on top of the Finder window!) and gets diluted into vaguer criticisms about "UI emphasis" and "potential confusion" (the way that drag and dropping that icon feels too much like a file system manipulation... and darn it, using string-based paths is sensible, if a bit nerdy.)

So once more into the breach...

One thing holding me back from switching to OSX for my work machine is a feeling that the keyboard support isn't up to snuff... specifically on Windows, nearly every text editor I use maps ctrl-left arrow and ctrl-right arrow to jumping words. Now there is some inconsistency to it: some editors think an underscore is a word break, others don't, some jump to the start of the next word immediately, others jump to the end of the current word first. But at least the standard is there, and I don't have to interrupt my typing flow with mouse movements, or play "press and hold the arrow key 'til the cursor finally gets there".

I thought this problem sprung from Apple's pro-mouse, anti-keyboard stance. The original Mac keyboard didn't even have arrow keys! See for yourself:

But of course, I was wrong. I was expecting that all the keys I was looking for would be mapped to cmd-, which is (roughly) the Mac equivalent of "ctrl". On OSX however, the cmd-arrow keys jump either to the beginning/end of the line (left and right) or of the whole document (up and down). However, The "option" key WAS mapped to what I wanted, with the left and right jumping of words.

Arguably, Mac's use of these keys is more efficient and logical than the PC standards. There's an intuitive hook to how cmd-left/right goes to line endings, and cmd-up/down means the whole document. These keys can then play the role of home/end on PCs: home/end = line, ctrl-home,/ctrl-end=whole document. Furthermore home/end are two of the most wandering keys on laptop and compact PC keyboards, there has been no definitive consensus on where they should go, and sometimes they are mapped to special, laptop only "fn-" keys. So points to Apple for battening down the hatches on that.

So I was wrong. Mostly. But can I say Mac has too many of the wrong kind of keys? Look at this:

"fn" "control" "option" and "command"! 4 different keys that mean roughly the same thing, "make the other key I'm pressing do something else". To make things worse, the little used key "fn" gets the most prime real estate-- the place where Fitt's Law implies the most important key should go. (To be fair, IBM/Lenovo Thinkpads make the same mistake, and it's even worse because a PC's ctrl key is much more important than the Mac's.)

Here's the same image from a typical Windows keyboard:

It's the same number of keys, but I think handled much more gracefully, with better differentiation. "ctrl" and "alt" are far away from each other. Plus in Windows, there's a stronger convention for when which is used: ctrl- combinations tend to be "do something now": copy, paste, save, new, etc. Alt- combinations are mostly used to pull down menus. (Windows used to have greater discoverability of that feature by underlining the accelerator letter on the menubar, e.g. File and Edit, but now (by default) those underlines are hidden until the user holds the alt key.)

The windows-key is special, in most sense of the word: usually it means a quick hop to the start menu (and I love the way they put the cursor in a search box there... windows-key,"program name fragment", return is a very quick way to start a program that is not frequently used enough to merit a pin on the task bar.) The Windows key also has a few obscure key combos that are all OS-wide, like win-m or win-d for hiding all windows and showing the desktop. (Though weirdly, win-d is reversible by hitting again, and the older win-m is not.)

(And it still seems odd to me that Microsoft managed to get their logo on all that hardware by all those manufacturers...)

So wrapping up my arrow key rant, Mac feels a bit klutzy to me, and it's awkward to use and annoying to remember the distinction between "command" and "option" when going back and highlighting and copy words that I just typed. To make the whole scene worse, why isn't the Option (formerly Closed Apple Key) labeled with its icon, ?(And what kind of symbol is that anyway? To be fair I guess the Option Key has its uses, like for typing letters with accents and the like, but still there are aspects to it that seem half-baked.

Rant over! I'm still on the fence about making the "switch" (and in part because I worry about Apple being such a dominant monoculture of computing) but thinking about the UI/interface it provides makes the potential transition easier for me.

bonus: fireworks cheatsheet notes

2011-12-22T12:23:00.000-08:00

So the designers at my work use a lot of Adobe Fireworks. It's a cool program. Its raw format is .png, but a cranked up .png that holds lots of stuff like layers, alpha transparency, and even vector information. For enginerds like me who tend to think in terms of pixels only (and maybe diving into crazy complexities like "layers") it's a lot to wrap our heads around... and watching a skilled artisan use it, and its ability to treat text and lines and pieces part as objects, even when they're not explicitly set on a different layer... it's eye-opening.

So, as notes to my future self, I thought I'd write out just what I had to go through to make up the basic white-rectangle-with-drop-shadow images... in particular, how to use Fireworks to slice it into the top,middle, and bottom the final example used.

Here are those notes:

make a new image: ctrl-n, 500x500...
On toolbar stroke would be null (red line X, fill to white...), fill would be white
on the toolbar under vector, make the shape tool do rectangles not ellipse tool
draw the shape then handfix the W and H under Properties at the bottom (mostly the width)
Under Properties|Filters, Shadow and Glow | Drop Shadow
This pulls up some Filter properties. (By default the dropshadow is to the Southeast)

so Filters is a list of effects added to this selection, you have to be careful not to make extra ones...
the arrows is distance, how far away the center of the shadow is from the center of the item... I want this at zero, centered, not off to one side

(which means I can ignore the angle for which direction it should go)

I set the fuzziness bigger than 4, like 10 or so
you don't see changes applied 'til you close the filter mini-properties box

Make sure the canvas itself has the null background selected (indicated with the red line) and you can see the gray and white boxes
Here I could select the rectangle with the selection tool, ctrl-c copy, ctrl-n (which autodefaults to the size of the thing in the clipboard), paste, then save. But of course I wanted my 3 slices...
now we need to use the slicing tool. You draw bounding boxes (including the dropshadow) and rely on the AI thing to find the right edges for you... I draw one for the top, bottom, and middle. At my first attempt I tried to close-crop the top and bottom without interior padding, but that messed up the shading of the corners, and I had to redo it.
Then I go to Export... the settings are QUITE a bit fiddly, what the helpful designer helped me figure out I wanted was "Export:Images Only" "HTML: [None]" "Slices:Export Slices" "Pages:Curent Pages" and "Include Areas without Slices" left unchecked

And that was it!

Sometimes I dispair of ever deeply learning Adobe stuff. It seems like such a different, non-engineery, don't-try-to-understand-everything-we're-doing / intuitive system... or maybe the designers are just more used to. (GIMP. in contrast, is pure-Engineer, we-don't-give-you-any-convenient-defaults, no matter how logical it might be.)

ie dropshadows with scale9grid... or not

2011-12-22T11:26:00.000-08:00

(This is another one of those "see how the sausages get made", tales-from-the trenches post, vs a bright shining tale of victory and Zenlike CSS perfection.)

So, dropshadows. Designers love'em! And why not, they bring an illusion of depth to the page and help set things apart. But man, they are a pain the butt to code sometimes... at least they are if you want to support IE. (I guess IE9 is starting to support this as well.)

First, a note: the drop shadows I'm aiming for are kind of a fuzzy border all around the div, vs the kind hanging out on one corner (usually the lower-right.)

Anyway, the CSS is still in that funky "each browser uses a prefix" state, so the code is like this:

box-shadow: 0px 0px 15px rgba(0, 0, 0, 0.80);
-moz-box-shadow: 0px 0px 15px rgba(0, 0, 0, 0.80);
-webkit-box-shadow: 0px 0px 15px rgba(0, 0, 0, 0.80);
Not too bad, the result is like:

Hi there!

But of course that does nothing for IE <= 8. I fiddled around with some of IE's filters,

filter:progid:DXImageTransform.Microsoft.dropshadow(OffX=0, OffY=0, Color='gray', Positive='true');
filter: progid:DXImageTransform.Microsoft.Shadow(color='#969696', Direction=135, Strength=3);
but nothing was coming out right, either it made everyting blurry, or it was an old Win3.11 looking flat gray background, or the content of the div was rendering weirdly non-anti-aliased... we ended up going with a variation of this, and for a while letting IE users just hang with a thing gray 1px border.

But I remembered this past spring when one of my co-UI guys was really excited about a plugin called scale9grid. It's a pretty sweet of styling a div (as long as you don't mind depending on javascript and non-semantic CSS and images to do so) that can be any width or height, based on using an image as a model for the borders (an image that presumably has a flat-colored center section where the content actually goes.) So you can have arbitrarily weird corners and sides and this plugin takes care off all the busy work.

So in Fireworks (more on that in a bit) I styled up a nice alpha-channel (transparency) preserving PNG that is shadowboxer.png:

This can be used to make a box of any size.The code for this is pretty simple, in the CSS you need to set the background-image (something the page is a little slow to mention), the dimensions (I think), and some padding, so that your content isn't over the shadow itself:

background-image:url("/shadowboxer.png");
padding:12px;

Then in jQuery, probably in the $(document).ready() you tell it how much of the sides of the original image you want to respect and use as the border:
$('#element_id').scale9Grid({top:12,bottom:12,left:12,right:12});

Hi there again!

So, that's kinda nice. The trouble is, the panel we wanted it for was all animated. The width was fixed but the height was changing, and that goes beyond what scale9grid was designed for. It didn't change when the child content did, and you couldn't just reapply once the animation was done.

So to let IE users back in on the fun, I decided to go with the old, slightly-gruesome, tried-and-mostly-true technique for fixed width things with funky borders: a special graphic-only div on top, the main content div with a repeating background, and a graphic-only div on the bottom. Sigh.

The images I made up in Fireworks, and most of the other external files for this blog entry, are at http://kirkjerk.com/m/files/kirkdev/shadowbox/. I imaginatively called them "top" "mid" and "bot", and they can be used like this:

Are we having fun yet?

The CSS then is something like:

.top_box{
width:398px;
height:14px;
background-image:url("top.png");
}
.mid_box{
width:398px;
height:218px;
padding:10px;
background-image:url("mid.png");
background-repeat:repeat-y;
}
.bot_box{
width:398px;
height:13px;
background-image:url("bot.png");
}

What can I say, it works, and animates fine. One irritation was I first tried to cut the top and the bottom with no interior white padding, but that messed up the fading on the corners.

It's depressing to get back to such a mundane solution, but at least I've reawakened my awareness of the potential of scale9grid, one more weapon in my UI Engineer arsenal.

image magick and text macros

2011-12-15T10:36:00.000-08:00

After developing professionally for 15 years, I can appreciate when it's time to apply a quick and dirty solution.

Sometimes it's my only option, a way of covering gaps in my knowledge-- for instance, I've never really had the chance to learn any Adobe product deeply, whether it's Flash, Photoshop, or Fireworks. And I've stuck with my manipulating tab-delimited files in Perl where more normal people might cozy up to Excel.

So at http://alleyoop.com/ we had a widget that would display sample math problems for various subtopics. Each image was a 380x136 png, but most had plenty of whitespace:

We decided we didn't want to so much whitespace... but ideally we wouldn't have to have a design person resize all 204 images. What to do?

Enter ImageMagick. This software has been around for a long while I think. A while back I used its Perl module as part of my image upload feature for my personal blog, so I could crop out extra white space on doodles and resize images to be more web-friendly on the server, rather than doing it locally and then reloading. And there's a handy Windows client.

The syntax is a little strange, but for trimming the file "Volume.png" I'd just do

convert Volume.png -trim Volume.png

I chose the same file name for the output as the input (Weirdly, if I didn't specify the destination filename it would give me a file name "-trim".)

So far, so good. But what' the easiest way to apply this command to all 204 files?

I'm on Windows, and haven't bothered with CygWin, so I've learned a few coping tricks... like "dir /b" gives you a "bare" directory listing of just the filenames. I run the following command:

dir /b *.png > trim.bat

So now I have trim.bat, a flat file of filenames. Then I pull up trim.bat in an editor* and ran a macro that:

home to to the start of the line and started the macro recording
shift-select to the end of the line
ctrl-x to cut the filename
type 'convert "'
ctrl-v to paste the filename
type '" -trim "'
ctrl-v to paste the filename
type '"'
down arrow to the next line, then home to jump to the start of it
end macro

Then just hold down the macro replay key, and BAM, I have my ready to run batch file. Run it and my job here is done. (Macros are great, super fast to make with almost nothing to learn, just sometimes you have to think about the general case of what you're trying to do. Every developer should intimately know at least one editor with one button macro playback as well as a small set of text manipulation tools, like either Perl or awk and sed.)

* on editors... lately I've been using Komodo Edit, despite its surprisingly long loading times. I kept my ancient copy of TextPad handy though, in part because its macro recording and playback was rock-solid and I sometimes had issues in Komodo Edit. But now it looks like Notepad++ is what the cool kids are using, at least the ones not "cool" enough for developing on Mac. Can I say though, that given most Mac laptop's half-assed keyboard support (the lack of equivalents, or at least general obscurity, of simple keystrokes for Home, End, and ctrl-arrow to jump words) that I find this kind of thing much easier to do on Windows, and it's yet another reason I'm unlikely to switch, at least for my work stuff...

animation nation part 2: introduction to raphael.js

2011-12-12T14:20:00.000-08:00

So the other day I was talking about making an animation for my company's registration process.

I quickly put together an animation proof-of-concept in ProcessingJS. I didn't go too far with it in part because IE is still in our target browsers, and ProcessingJS relies on the canvas object, so we couldn't use the result on the site.

My thoughts turned to Raphaël in part because I knew it would work with IE. Superficially, Raphael is very similar to canvas-based APIs (in fact I thought it used a "shim" to let older versions of IE do canvas things) but really it's profoundly different... rather than a canvas of pixels, Raphael deals with SVG (Scalable Vector Graphics) vector objects. These objects are great because they deal with twisty lines and curves rather than squares, and you can scale them to any size without them getting pixel-y.

Vector graphics require a different mindset than "regular". Specifically, Raphael is object oriented and once you've created your "paper" you add shapes and lines to it. Those shapes and lines then have attributes, similar to CSS attributes, that you can modify. The examples on the Raphael homepage are impressive, and it's easy to make juicy effects, especially in terms of bouncy scaling and rotation.

I wasn't crazy about the homepage's boilerplate for two reasons: one is I prefer something I can copy and paste into a blank document and hit the ground running. Here's some code that let me do that (once I pulled down a local copy of raphael-min.js)

<head>

window.onload = function(){

var paper = Raphael("thepaper", 320, 200);

var circle = paper.circle(50, 40, 10);

circle.attr("fill", "#f00");

circle.attr("stroke", "#fff");

}

</script>

<body>

</body>

The second improvement I made was to use a name div as a canvas, rather than ask Raphael to provide the div and position it absolutely... I think it's more common that people will be embedding a bit of Raphael in a larger webpage, so an id'd div seems the way to go for that. However, that meant I couldn't let Raphael just run as commands directly in the script tags, I had to wrap it as a window.onload function (obviously, $(document).ready(); is even a better bet if you're already using jQuery, I just wanted to remove the dependency.)

The Raphael documentation is a reference, not a tutorial, so you have to poke around... it probably helps if you know some of the basics of SVG.

In processing, I had made up a sine wave as a serious of short line segments. In Raphael, I figure I'd want a Path: a path is a series of line and curve segments. Entertainingly, you define a path via a string, and a series of text commands. It reminded me of drawing with the language Logo and its turtle graphics in my youth.

So to see a Path in action, you can add this line to the boilerplate, which will draw a rotated chunky path.

var p = paper.path("M50,50 L100,50 L100,100 L150,100 L150,50").rotate(45,50,50);

Some things to note:

Raphael uses the same kind of command chaining as jQuery, so I added the rotate command to the end.
You can use commas or spaces as delimiters between commands and the arguments.
I used capital letters, so all the coordinates were absolute... if I had used lowercase, they would be relative to where we last drew.
By default angles are in degrees (i.e. 360 = circle).
If I didn't specify the coordinates to rotate around, the Path would have rotated around its own center.
Raphael uses "painter order" rather than Z-indexing... the last thing you add to the Paper is what appears at front.

Once I was here, it still wasn't clear how to go forward in terms of making the animation I wanted. There's a pretty extensive set of animation features, but I couldn't figure out if there was a way to make the minor adjustments to the Path. (In fact, it turns out I can't even rotate a Path as an animation! Hmm.) So while I thought it would be "more Raphaelish" to make the objects once and then animate their attributes, it turned out I was going to have to do it similarly to the Processing version, and constantly create and destroy my path objects each tick.

To cut to the chase, here's what I ended up with, click kick to see it with some inertia, or just spin for a constant rotation:

You can go to the webpage to view the source though it's a bit hacky and ugly...
So comparing that animation to the original graphic:

It's not 100%, but with the tweaking I did it's not bad. Our art guy was very pleased with the result.
As the animation works, you can see where I had to add in additional "crossbeams" - the 2D original didn't have to worry about that. Also I couldn't quite figure out how to duplicate the "over under" cheat in the original, where they put a break in the underlying squiggle, so working with our art guy we decided to color one of the squiggles a bit darker.

The thing is the animation flickered a bit on IE, and even on Firefox the constant motion was pushing the CPU to around 7-10%. I decided to punt-- I added a step button to move the animation one frame at a time, and then I laboriously constructed an animated GIF:

Neat! Not quite as 3D as the Processing version, alas. (And since I was "cheating" and making a GIF anyway, I could have stuck with Processing.... in fact I might go and try that, since it's more powerful, and easier to push out a series of TIFs (rather than relying on screenshots like I did))

Finally, we were looking for the animation to run for a bit, then stop, then restart. I made the GIF animate once, and then used jQuery like this when we wanted to see it spin:

//first set up an offscreen image with the animated GIF:
this.dnaImg = new Image();
this.dnaImg.src = '/components/onboarding/images/DNAIconAnimate.gif';

//later when we want it to animate, (re)set the

//src of the onscreen image to the offscreen one:

$('.dnago').attr('src',this.dnaImg.src);

Easy-peasy, and it added a lot of visual pizazz to that part of the site.

animation nation part 1: processing.js

2011-12-07T13:44:00.001-08:00

At work we thought it might be cool if we could jazz up the following bit of pseudo DNA (using Alleyoop's colors as the crossbars) that we are using during our signup process.

I wondered if we could get a nice little 3D-ish effect by treating the helix strands as sin curves and then animating them by increasing the angle (Hey remember the into to Superman II ? Around 9 seconds in, the awesome spinning prison rings are actually 2 rings permanently welded together and then rotated as single unit... an awesome economical visual effect.)

My goto language for this kind of thing is Processing. Processing is a little Java IDE and API that makes making applets really easy, and lets me leverage my 10-odd years of Java experience in a way that works on most any browsers to make gamejam games and my own toys. (With applet supporting waning over the years, I'm happy to see stuff like Minecraft exercising Java as a viable game platform.)

An applet would be overkill for the task (not to mention raising the spectre of Content-y and plugin warnings) so I turned to Processing's little brother Processing.js. It's an HTML5, javascript/canvas based version of Processing. It has 2 modes: one where it can (try to) run the exact same ".pde" files as the Java version, and another where it acts as a highpowered API to the canvas object for more traditional javascript code. I knew Processing.js might not be acceptable for use on our actual site, since it depends on the canvas object that is only now getting support by IE, but I decided to give it a whirl anyway.

The pde "run the java code" mode is in preferred, but for my money it's not ready for prime time. It is essentially using a preprocessor to translate Java code into javascript, and the results aren't always pretty, especially for stuff involving classes and collections of mixed object types. The error messages are often extremely opaque or absent altogether.

Despite the problems, Processing.js is still a lot of fun, especially with one of the inbrowser IDEs like sketchpad.cc. You can type code and almost instantly see results, part of the charm of both versions of Processing.

Nearly every Processing program has two main parts: setup(), where one time activities are performed, and draw() which is called every frame. Most Processing programs (at least the ones I've written) clear the background every frame and draw the entire frame from scratch, but some just keep drawing on the same canvas.

Here's what I came up with. Apologies for the code that follows -- it's mostly hacking around proof-of-concept stuff, and there are a lot of "magic numbers" there I tweaked to make it look good... not exactly like the model, but enough to see that a spinning 3D effect could emerge from a sine wave fragment place against the flipped version of itself and constantly having its starting angle increased. Essentially the variable x1 runs through the horizontal values, x2 is the next value (for drawing line segments) and we get the two y values by running the sin() function. And then at certain x1 values, we draw the cross pieces.

void setup() {
    size(200, 200); 
    smooth();
    frameRate(30);
    strokeWeight(10);
} 
float off = 0;
void draw() {  
background(255);
pushMatrix();
translate(120,0);
rotate(3.14 / 4);

off += .1;
for(float x1 = 0; x1 < 120; x1++){
    float x2 = x1 + 1;
    float a1 = off + x1 / 40;
    float a2 = off + x2 / 40;
    float y1 = 20 * sin(a1);    
    float y2 = 20 * sin(a2);    
 
    if((x1 +1) % 31 == 0){
       stroke(255,0,0);
       line(x1,100,x2,y2+100);
       line(x1,100,x2,-y2+100);
    }
    stroke(128);
    line(x1,y1+100,x2,y2+100);
    line(x1,-y1+100,x2,-y2+100);
}
popMatrix();
 
}

Here's the result (IE users are out of luck, in this way and in so many others...)

Not half bad if I do say so myself! The effect was very sensitive to little tweaks.

Next up: the same idea in Raphael.js... a very different tool that works on all the major browsers.

worthy read

2011-12-05T14:12:00.001-08:00

Ask Tog about Search vs Browser on iOS. I need to figure out how to push my self ever more firmly into the "HCI expert" camp.

I have an ancient copy of "Tog on Interface" on my bookshelf, I should dust it off and give it a browse. (Or a search.)

javadvent 2011 and processing

2011-12-02T09:17:00.001-08:00

So, some years I make an Advent Calendar, with a different unique miniature videogame or virtual toy for every day of December up 'til Christmas... for this year it's at http://kirkjerk.com/java/advent2011/

It's a fun exercise in UI design, trying to come up with 25 fun but fairly intuitive interactions. (I still provide instructions, but I kind of wish I didn't have to.) Also, the style of Advent Calendars, with a small distinct treat every day, makes a kind of delightful "interface". The calendar itself is basically a copy and paste of the 2009 Edition (except I made it so only one entry is visible at a time, multiple instances open tends to bog down machines.) It's HTML and CSS and Perl from when I didn't know any jQuery, and it kind of shows, though I think it gets the job done, and is fairly sophisticated at making it difficult to peek ahead.

They entries themselves are written in a Java IDE/library called processing. I love keeping my Java chops maintained a bit, and these little bite sized morels were perfect to code on the subway, to and from work. Unfortunately, Java applet support seems to get shakier and shakier as time goes on...

There is a javascript version called processing.js which in theory runs the same programs, is all HTML5-y, and works natively in browsers. It has some awesome things like in-browser IDEs (http://sketchpad.cc/ was my favorite) There are some drawbacks though: it doesn't support IE (at least before 9? Not sure) and it's far from 100% code compatible with the Java verison.

But Processing is a fun language especially for fun and impressive prototyping. I also use it for the 2 hour "Klik of the Month" game jams at Glorious Trainwrecks, and even for the longer 48 hour "Global Game Jams". You can see some of both at my portfolio site alienbill.com.

preload your images

2011-12-01T10:56:00.001-08:00

Sometimes when building a dynamic site, you might want to load some images after the page has loaded but before the images are shown so that when they do show the appear instantly.

I forget where I found this paradigm, probably somewhere on stackoverflow, but it seemed to work a treat:
function preload(sources, prefix)
{
var images = [];
for (var i = 0; i < sources.length; ++i) {
images[i] = new Image();
var src = sources[i];
if(prefix != undefined){
src = prefix + src;
}
images[i].src = src;
}
}

(Ha, I can tell it's not all my code, I never do "++i".) Sources is an array of image names, prefix is an optional parameter that might contain the URL for the directory where the images are located, so you don't have to include the path on each image name. Then when you actually show the image it should be ready to go, instantly.

windows kudos, osx phoodos

2011-11-30T13:58:00.001-08:00

So here's something from Windows that I think belongs in a UI Hall of Fame. It's the Location bar of the Windows 7 File Explorer:

It shows you the current folder location in a logical, breadcrumb manner. Hover over part of the current location:

BAM! It fades into a button, and you can click it and hop the folder's view to that location. That's brilliant! (Somewhat less brilliant because it's getting more obscure: (AKA I didn't realize it 'til just now:) click the arrow to the right to hop to siblings of that folder.)

(UPDATE: OSX has a "Show Path Bar" option that brings up a similar breadcrumb-y view. You can even hop up to any of the parents, but you have to double click, which seems unfriendly to me.)

But the really great part is clicking on the location bar just outside of the visible path:

DOUBLE BAM! That is a text version of the path, pre-select for your Ctrl-C copying convenience. Now, even if you're not using the dear old command line much, it's still hugely useful: in any standard file dialog, you can paste that into the filename, press return, and now you're ready to save your file in that location. (OSX sort of does something similar if you start typing with a slash, but it's heart isn't really in it.)

So I don't know if that is a "poweruser" usecase, but I find it hugely intuitive and fast, fast, fast. Now, there are imperfections in this system of text versions of the path-- if you click for a file path when you happen to be doing a search, the result is an unreadable mess that you can't really usefully paste anywhere. But there are other nice touches to the widget that I'm not even going into here.

Speaking of standard file dialogs, here's a bit of crapness from OSX. Here's a file save as dialog.

So that "Where" interaction, showing a small list of common spaces you might want to Save To, is something relatively new in UI land. Windows does it too, but the dropdown menu is used to control a larger folder view. So you can jump to one of the standard areas, and from there, say, create a new folder, or go up a level, or do the usual folder manipulations:

And so I figured that that functionality must be somewhere in the OSX file dialog, that I could save somewhere other than exactly one of the pre-ordained file locations... but where? How do I get to it?

Answer: that small triangle to the right of the filename. That changes the look of the dialog to this:

That's better... but why is it so hard to find and why is it like that in the first place? I like thinking through the challenges UI designers must have faced, because sometimes you realize there's a complicating detail... Why isn't the more flexible view part of the dialog to begin with? I guess to simplify things, stop people from getting overwhelmed with options, while satisfying an 80/20 (70/30?) rule about where a user wants to put something. So why is it arrow to the right of the filename, and not the "Where" dropdown? (It is functionality related to the location, not the filename...) I guess because the "Where" dropdown changes form enough in the new mode that the up arrow to put it back might get lost. But it seems unintuitive to me. (Meaning I had to go ask a more experienced OSX user where to go for it.) Combine it with the way I've lost my ability to copy and paste a path here, and I have to say, I find the Windows experience superior.

(I know Mac fans stuck working on Windows probably miss the 3 column view for its folder viewer, along with the too-cool-by-half "Cover Flow", but for me, I'd rather have the ability to easily transfer path information around. UPDATE: OSX has this functionality, by dragging the icon at the top of a Finder window onto a dialog. Even given my lack of experience with OSX, this seems a little fiddly to me, where I might think I was trying to move the folder to whatever location the dialog was open to.)

Another OSX-ism I find irksome: the default Preview program is great for quick viewing, except it has no concept of "go to the next file in this folder". What's weird is that the basic functionality is in place: it does the right thing if you ~~drag and drop a bunch of files onto it once, or~~ select the files and right click and hit "Open with Preview.app" (Sorry, I was wrong: Preview doesn't support drag and drop.) I have had friends who are bigger fans of OSX say I was expecting the wrong thing, that file systems are arbitrary ways of holding a bunch of files anyway, that a more realistic usecase is just using iPhoto for all this stuff, but, whatever man. It was a detail I think they could have done gotten better, and it makes my life on OSX less easy than my life with Windows.

why windows' taskbar beats osx' dock

2011-11-28T06:47:00.001-08:00

OS preference is, generally, a subjective thing. With the gradual ascendancy of Apple underway, I'd like to take a second and analyze how the two OSes relate, and where I think Windows has done a consistently better job. This will reflect some of my personal preferences (and, possibly, the way my mind has been warped by 15-odd years of Windows-isms-- any analysis like this has to recognize that we tend to like what we find familiar) but I will point to some objective differences between the systems.

First, a random note on the screenshots: I'm one of those quirky people who puts the app controller on the side of the screen. I wrote up why on my blog about 5 years ago: there are a few advantages, first and foremost is how it makes better use of the "widescreen" format laptops and monitors now sport (I mean, have you seen how short the screen is on a 11" MacBook Air?)

So to the left is the Windows taskbar and the right is the OSX dock... both have their graphical bells and whistles. Windows (at least as of 7) has some translucency going on - on my work machine it's really sophisticated, with an "active window" highlight color and some pretty light effects as the mouse passes over it. The Dock has that terrifically fun "magnify" effect, where the icons fluidly grow and shrink as you pass the mouse cursor over it.

The primary difference between these two bars is this: The Taskbar is Window based, the Dock is Application based. This is why I think the Windows approach is superior for a multitasking operating system: each window maps to a task, a bit of state I might want to return to, and the Taskbar offers a passive, unobtrusive reminder of each window and a way to get back to it. (Kind of a dynamic "todo list") With the Dock, each icon is an application. There is no direct jump to a given window, just that application. (OSX offers some other paradigms for getting back to where you were, more on that in a bit.)

Let's start with Windows. Every window gets its own place in the task bar... (before Windows 7, the "launch a new program" icons were either hidden behind the Start button, or later, on a little specialized "quick launch" piece of the taskbar. Nowadays you always have the option of "pinning" an application to the taskbar, which comingles the running and launching icons.) The difference between a Window of a running program and an icon to launch a new instance is obvious: the former is a button with a caption, the latter is just an icon. (The disadvantage is launching a new window of a running program from the taskbar is a bit awkward, it's the first option on the right click menu. It's not that big of an issue thought because browsers and most document editors use File|New or Ctrl-N to open a new workspace. UPDATE: WorldMaker points out you can middle click on a running task button to pop open a new window.)

With the Dock, the visual difference between a running and launchable program is minimized: a small white dot. Click on the icon and its windows move to the front. Again, to me there's a huge difference between a running program (carrying state I want to be reminded of or get back to) and a launchable program (which is a clean slate) and so I find Windows' approach to be superior.

This App-centric approach carries through to the quick switching. With Windows, I hit alt-Tab and I see a sorted list of my windows. OSX has a similar function, but again I'm looking at placeholders for whole apps, not a window at a time, once I switch to the right app I still have to find the window I'm thinking of. I know there are different apps to adjust the OSX environment, but I think getting the defaults right is crucially important-- having to relearn how to get around a friend's computer running the same OS because they don't have the same "fix" installed stinks.

It could be argued that I'm doing it wrong, expecting OSX to act like Windows instead of adapting to what OSX offers. For a long while OSX has had exposé, a single button that temporarily resizes and repositions all of your windows (or makes snapshot thumbnails, based on how you think of it) so that they are all visible at once. OSX Lion's Mission Control furthers that paradigm. While I might be getting old and curmudgeonly, I don't like exposé as much as Windows' system, in part because it lacks the "quick bounce back" of alt-tab, where a quick tap of alt-tab brings me back to what I was last working on (Windows has a really good "most recently used" algorithm for tasks, an easy to miss but hugely important detail that Just Works.)

UPDATE: OSX does have cmd-` (very easy to find above cmd-tab, kudos for that choice) that cycles through open windows of the current application. But this interaction is application oriented, you can't gracefully leap back to what you were doing in a different application like you can with Window's alt-tab.

(I guess I should say, Windows 7's defaults are a bit different than what I'm describing here... I set Windows to "Never combine" Taskbar buttons, and so I don't see the roughly exposé like thumbnails Windows makes now.)

This differences harken back to one of the oldest differences between Windows and MacOS-- with Mac, there's one place on the whole screen where the "File" menus will appear: each app takes over that space. (It's kind of ironic that it took OSX so long to get fullscreen mode right.) This kind of points to the idea of Mac as "information appliance"-- the whole machine is dedicated to that app. On iOS I find this perfect and relaxing, but I find it irksome on a multitasking system. (I know people argue that there are advantages to the menubar-on-top paradigm of Mac, that you always know where to look, and your mouse can target the menu faster, but for me those bonuses are outweighed by having to figure out which menu bar applies to which window.)

I have some more thoughts on Windows vs OSX, but that can wait 'til next time...

room to write

2011-11-21T08:16:00.001-08:00

Apologies for the less-than-fully-assed entry that follows:

I thought a pretty common task for jQuery would be to make a textarea automatically expand as content was added into it. And a bit of googling shows that a number of people have taken a stab at it. But it looks like no one has gotten it quite right, and I don't have enough time and energy to fix that.

The best I found is padolsey's jQuery.fn.autoResize. Once you include the .js file usage is trivial:

<script>
$(document).ready(function() {
$('textarea').autoResize();
});
</script>

There are some configuration options as well.

I'm not 100% enamored of it: if you edit the value manually (like by calling $("textarea").val()) , the thing is not resized, and while it has basic coverage for resizing when users paste in text, it gets a bit wonky.

prettier json

2011-11-17T07:18:00.001-08:00

Yesterday I talked about JSON, and the inspect() method I use. While that example actually did some nice indenting, sometimes I have a mass of untabbed JSON I'd like to visually inspect. The best tool I've found for that is http://json.parser.online.fr/ . Slightly confusingly it shows both the "String parse" and the "JS eval" versions of the string, but usually it doesn't matter which one you look at. The way it builds a treeview of the code is really nice.

Before finding that page I used to just Google for "json pretty print" which would lead me to Cerny.js' entry as well as curiousconcept's. Both are ok in a pinch, I think the former sometimes got confused by special characters in the content, even if they were properly escaped.

loggin'

2011-11-16T09:42:00.001-08:00

Yesterday I mentioned the importance of "log-based debugging". It's crucial to browser-based work, in part because alert()s and stepping through with the debugger mess up the timing of stuff, so they're not as much help for timing-related issues. I also think the act of putting in log statements forces a programmer to challenge their assumptions.

For reasons that are obscure to me, at work we call our main debug function "ccdebug". Its code is like this:

function ccdebug(s) {
if (typeof console != "undefined" && typeof console.log != "undefined") {
console.log(s);
}
}

Pretty simple! The check for console existing is necessary for preventing errors when the console isn't around...

I've been using that for just under 100% of my log statements... poking around I realize we have equivalents for console.warn() and console.error(). In firebug, the former has a nice yellow highlight, and the latter even includes a stack trace. So to improve my practice, I should probably start differentiating my information and coding messages from messages for more serious problems.

One other function I find useful, with both console.log() and good old alert():

function inspect(thing, indent){
if(indent == undefined || indent == true){
return JSON.stringify(thing, undefined," ");
}
return JSON.stringify(thing);
}

That's just a great way to see the content of data structures and what not. The indent makes it a lot more readable, so I include it as the default.

simplicity simplicity simplicity -- shouldn't that just be 'simplicity'?

2011-11-15T14:34:00.000-08:00

The other day I was thinking of Richard Gabriel's classic The Rise of 'Worse is Better'. The article has a kind of old context, but I think its core is still valid. (I also appreciate the vacillation within the article; these are issues about style and mood where there won't be a single correct answer.)

As the Wikipedia Page reiterates, the core components of "Worse is Better" are, in roughly descending order:

Simplicity: The design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
Correctness: The design must be correct in all observable aspects. It is slightly better to be simple than correct.
Consistency: The design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either complexity or inconsistency in the implementation.
Completeness: The design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

The essay goes on to explain why these factors can be crucial to a technology really taking off.

I find a rough analogy in my professional life as a UI Engineer when it comes to the selection of toolkits. I had a miserable time with "Wicket" and its bizarro blend of delicate flower Java class/HTML pairs. (It was barely ok for light work, but god help you in having to learn this whole lifecycle flow if something went wrong or you wanted to make your own component.) These days I've been arguing sticking with basic jQuery rather than taking on some heavier duty toolset like YUI or jsMVC.

So I ask myself, am I just a stick-in-the-mud curmudgeon who hates to learn new stuff? That's at least partially true: I'm much more interested in what technology can empower me to build than in the tools themselves, so I'm only interested in new toolsets when they let me do something new or in a vastly easier way, not just something old in a slightly more concise way. But I think there's something deeper in my preference for light weight toolkits, more profound...

I've said "People and computers should be judged by what they do, not by what (you think) they are." No one cares how finely crafted the objects in your code are, they just want to know, does it do the job well, and have you set yourself up to do the next few, slightly different jobs well. When I'm debugging, it's because the system is DOING something wrong, and I need to correct that behavior. My tools are-- lo and behold-- a debugger! and thoughtful logging... (good old log-based debugging is a crucial tool. I say that's because it forces you to think about what your preconceptions are at each step of the way, and then show them in action. But there's a chance it might also be because the debugging tools I used in college were so awful and opaque. Also, debuggers mess with the timing of stuff.)

Anyway, when I'm debugging, in a debugger, if I'm mostly looking at other's people code in the stacktrace, my job is much, much tougher. Most toolkits are extremely configuration heavy. (Toolkits by their nature don't just solve YOUR problem, but a hundred other problems as well, so you have to specify lots of things) It takes a fair amount of expertise and learning to set them up right, which costs time-- time you often don't have, the whole reason you're using the toolkit is for it to quickly solve your issue-- and when things break, there's often a huge gap between the misbehaving code and your error. The lighter the toolkit, the more likely the mistake is near where the debugger is showing the problem, the nearer the observed effect is from the code that caused it.

JQuery, I hardly ever have super tough to understand problems with. The few times the issue shows up in "jquery.min.js" itself, its been where I'm setting some property IE thinks should be read only or some such. Other tools I used, like Java RichFaces, the situation was much, much hairier. But with basic Javascript calling jQuery when needed, I can get to the problematic code easily.

Now this argument could be taken to an illogical extreme. I'm not saying you should code in assembly or anything like that... but your toolkits should be simple, reliable, and your widgets and libraries should be of the do one (hopefully difficult) thing and do it well.

(Of course, someone pointed out another reason to hate toolkits is they put a coating over the 90% of coding that is easy and pleasant and 'hey I built this!' and leave behind the 10% that is difficult anyway, and how you earn your pay... in fact they usually make that 10% significantly harder.)

Continuing the comparison to assembly, you still get people trying to spin Javascript as the Assembly language of the web, the code that all browsers speak, and it shows up in your debugger, but not what you want to be coding in. This kind of thinking is weak, because the additional layers, while slick and clever (epecially in the early baby tutorials) don't actually let you say stuff new. A concise essay about that in terms of toolkits is Uriel Katz' Why JavaScript is NOT the new Assembly and a longer one against CoffeeScript and other pre-processor type languages is blog.izs.me's "JavaScript is Not Web Assembly".

not so angry birds

2011-11-11T10:48:00.001-08:00

Today, our UX guy posted a link to Why Angry Birds is so successful and popular: a cognitive teardown of the user experience. This is the bulk of my resposne.

Cool article, though I disagree with what it assumes makes Angry Birds so popular.

The author is remiss in pointing out the obvious: some big chunk of Angry Bird’s addictiveness is because the base activity is a fun thing: it is fun and pleasant to launch a slingshot at a building of blocks.

At [Alleyoop, my College Readiness webcompany], we aren’t based on a core activity that offers such a low learning curve / high satisfaction + feedback . I think at the best points of [our Math practice and quiz subcomponent], kids can get that extra Zing! of satisfaction of a problem mastered, but in most other ways it’s a reach for us.

So with the article, I agree with some bits (the importance of pleasant and detailed visual design, even the inclusion of extra details like the chattering birds) and disagree with others (iPad icon spacing provoking a sense of tantalizing mystery? Puhleeze)

I thought margie's comment was more insightful to the charm of this particular game: (highlighting mine)

AB is a game for non-gamers. Gameplay is simple, the rewards are many and often, hence, continued play from all players. Any game that increases in difficulty and/or timing & speed too quickly I’ll drop out of […]. ~ AB is always the same: slingshot, birds, structures w/pigs.

I think the fact that players are frequently rewarded (it’s easy to pass a level, not so easy to 3 star a level) plays a huge part in why AB is so popular, especially with people who are not hardcore gamers.

Other commentators talk about “quick retrying ‘til I get it right” is a big aspect, maybe one we can learn from. Not punishing failure so much is a hallmark of modern gaming.

It’s funny too, the opening paragraphs:

Surprisingly, it is a rare client indeed who asks the opposing question: why is an interface so engaging that users cannot stop interacting with it?

The funny thing is, that’s not “engagement” so much as “low level addiction”. And frankly, popular games use some of the same pattern as drugs—an initial big rush (of success, in the case of games), a long haul of trying to recapture that high, and it being made harder to do so.

(It’s funny contrasting that with the addictiveness of say Farmville—there the addiction comes from a web of social obligations. The gameplay itself is decidedly NOT very fun in the way slingshots-at-buildings is, though it does carry a pleasant sense of “I Made This” construction. (I haven’t gotten into it either but I think Empires & Allies has those social and building aspects, along with an empowering “strong kid on the block” aspect in the fighting)

So I think [our company] would be well served if we could capture some of this addictiveness:

well balanced challenges with quick redo
a carefully ramped increasing difficulty
pleasant and juicy UI
social obligations
a sense of building

The single biggest thing that Angry Birds and Farmville have that we don’t are a real feeling and visual model of steady progress. (With Angry Birds getting through a series of levels, with the chance to go back and do better, with Farmville a nicely expanded and built up farm.) [Our former point system is] now a currency. Badges were nice, but were always more of a novelty than a core “gotta catch ‘em all!” experience

BONUS:

Some more thoughts that were a bit too specific about Angry Birds as a game to be relevant to my company:

I think the article missed out one of the best UI bits for the "try again" factor: you get a little dotted line showing you what your last trajectory was, thus enabling a higher degree of fine tuning. This little dotted line is more significant than a lot of the things the article discusses.

Another thought I had: if I was designing Angry Birds, I might try to give it a split view: a zoomed-in view of the current bird (allowing more fine control of the trajectory at the launcher, and then a fun closeup view of the structure being destroyed, or possibly a pan back to the smug pigs if you totally miss) and then a view of the entire playfield, visible at all times.

The thing is, I'm not sure if this system (more complex in its display, but simpler in its control scheme than panning and zooming Angry Birds) would be more or less satisfying than the current scheme. But when thinking about what deliberate choices Rovio made (vs, say, the delays once the bird has hit the building, which I think owes more to giving time to the physics engine to work things out than a deliberate design decision) alternative solutions to the challenges they faced should be discussed.

jsonp for cross-site fun

2011-11-09T12:45:00.000-08:00

So, today's fun:
We run a few different servers for testing: www is our live site, cert is for final testing, test is for preliminary testing, and we hack DNS a bit so that dev loops back to each developer's machine.

We have a single WordPress install that we use for our blog, as well as to store the content for certain activities on the site. My most recent project was to add a simple tag system that would change a WP slug like
[lookup value="user.profile.firstName"]
into a rest call to /rest/user/profile and substitution with the fieldName parameter. (I also added conditional tags, something like
[start_if value="user.grade" is="GRADE10"]Welcome to Tenth[end_if]
would display "Welcome to Tenth" only if the endpoint said that was their grade.

So when you just have the one WP install there's an obvious small problem when you want to test before pushing live, that while WP (which I keep accidentally calling "WordPerfect" not "WordPress", a habit that is catching on at work) can do its own preview, it's not part of the whole dev/test/cert/www cycle. We added a "src=http://dev.alleyoop.com" type parameter, telling the plugin where to pull its javascript guts and then rest calls from, but... d'ohh... the rest calls were failing, losing out to the draconian cross site scripting rules.

The cool kids solution to this is JSONP, JSON-with-Padding. (The wikipedia page for it is a decent introduction.) The server needs to be configured to recongize a jsonp request, and then it forms a response of the form "<script>yourcallback(THE DATA)</script>"-- script tags aren't beholden to the usual xss rules. (Which is kind of a headscratcher, given that running code from another site seems to be a lot more dangerous than just grabbing data, but sometimes you have to take what you can get.)

So, in practice, I made a version of our wrapper for getting JSON that added a parameter dataType: "jsonp" to the jQuery.ajax call. We then ran smackdab into a kind of known Firefox issue (I'm not sure if us using a more up to date version of jQuery would have helped or not) where Firefox thinks that the JSON, what with its hashes and : and all, looks like it's trying to generate labels (what is this, BASIC?) and spits up "invalid label"... our fix for that was in the middle tier, a known solution is that wrapping the data in an additional set of parentheses fixes it, so that's what we did.

There's of course a bit of a security concern when you're allowing shenanigans like this-- especially if we were showing content from one user to another user. We'll look for some ways to tighten that up.

mobile flash in the pan

2011-11-09T09:31:00.000-08:00

So the news is making the rounds, Adobe to stop doing mobile browser Flash.

For some Apple fans, this is a giant validation of Apple's view that Flash was the wrong technology for portable devices. (And as some have tweeted ActionScript might still be viable for making standalone apps.)

At work, our designer's response was "Aple wins!" and our lean startup guru marketing guy responded "The Internet wins!". That, along with Gruber's tweet thinking 2015 would mark the end of Desktop Flash players got me thinking...

What's next?

The most common opponent for Flash is usually described as "HTML5" which seems a little funny to me-- technically, HTML5 is about the semantics of markup, more of a topic for wonks than anyone else.

In practice, then It feels like there are two fronts for "not Flash", both powered by javascript. One is, and this is what I'm making my living with now, is what used to be called "DHTML"-- pages full of divs and graphics and one not, providing a faster and more interactive experience than the static pages of yore.

The other is stuff that makes heavy use of the "canvas" object. A lot of my gaming buddies are way into this as a technology. It's pretty cool, but there are two giant challenges for it to overcome to take the place of Flash: one is support for sound is still kind of iffy, you really have to dig if you want something that is very cross-browser and can provide "real time", synchronized sound effects. The other is support in IE (version 8 and earlier) tends to be lacking. (There are some libraries that use shims that do a good job of faking canvas support.)

I'm not sure what this means for me... Flash was on my "I should learn this" list, and now it's a little lower down. (I took one 2 day intro class and it was frustrating because the class was geared at designers, and focused on the timeline, which STILL confuses me, as opposed to ActionScript, which felt very familiar when I helped a friend recode a few things.)

(UPDATE: Gruber also pointed to this CNET article that points out somethings Flash still does better than its alternatives...)

scope-a-dope

2011-11-08T10:26:00.000-08:00

This is one of those posts that I'm a little nervous about writing, because I worry I might look a bit bad, since it represents a small bit of "trial and error" coding along with a slightly iffy theoretical understanding of the problem. Still, in the interest of being useful to my future self and maybe showing other people they're in the same boat, I'll put the process here.

I was trying to do a bit of caching of some data asynchronously.I had "neededEndpoints" that was a hash of the endpoints I needed to hit and store the data for in another hash, call it cache

So here was my first attempt: (it didn't look so blatantly wrong when I coded it, I've stripped out stuff in the name of simplicity)

for(var endpoint in neededEndpoints){
jsonGet("/rest/"+endpoint, function(res){
cache[endpoint] = res;
});
}

The trouble with this code is that javascript is not block scoped like some other C-like languages, and so "endpoint" is effectively passed by reference, not by value, and the last value of "endpoint" was used for all the cache storing.

I remembered in previous work we'd done here, we had a CreateDelegate function:

function CreateDelegate(scope, fn) {

return function () {

if(fn != undefined){

fn.apply(scope, arguments);

}

};

}

Usually we'd call it with "this" as the argument for scope, but I wasn't getting the results I expected. Googling I found this page that gave me the nudge I needed to come up with this:

for(var endpoint in this.neededEndpoints){

jsonGet("/rest/"+endpoint,

CreateDelegate({"ep":endpoint}, function(res){

cache[this.ep] = res;

})

);

}

So what's going on? The mental model I've come up with says CreateDelegate is in effect making a snapshot of the current state of things-- that's what a delegate is, in effect. It's actually the act of instantiation of CreateDelegate that makes the snapshot, and then the code inside it can have exactly the context we give it.

thoughts on keeping the global namespace clean

2011-11-08T08:17:00.000-08:00

So one well known issue with javascript is that it's a bit too easy to pollute the global namespace.

Personally I find this is a big issue more in theory than in practice, choose reasonably distinct function and variable names, and you hardly ever have a problem.

Half the problem is that if you just start using a variable without a "var" declaration, it gets slapped into the global namespace. Douglas Crockford, among others, considers it a bit of misstep in the design of the language.

(The other half of the problem is the same "bootstrapping" problem any language faces: how do you tell the system where code execution starts, and where is the tree of object and functions rooted ? C and Java have their main(); in Javascript, you can start putting function declerations and even calls anywhere, in practice there's a lot of $(document).ready(function(){}); )

So, you can go a little crazy with loaders and tools to control your namespace and keep your private variables and functions private etc, and also with CreateDelegate() functions to pass thing to page elements and whatnot. This is overkill for most projects where you're more interested in the functioning of the site than making a reusable toolkit. (YMMV). A good compromise is "make one global variable per functional grouping". For example, today I was working on a "madlibs" controller (for eventual integration as a WordPress plugin) Part of the code for that was:
var ao_madlibs = new function(){
this.neededEndpoints = {};
this.doMadLibs = function(){
//CODE GOES HERE
} //end doMadLibs
}//end ao_madlibs

In practice I find this a good balance of control and ease of reading. One caveat, in the doMadLibs code I used jQuery's .each() function, and in the anonymous function in there, "this" had a different meaning, so I had to use the global reference ao_madlibs.

I was looking at a bit of coworkers' code... he's more of an architect, and cribbed this from FB's api code:

if (!window.AO) {
window.AO = {
processElements : function(){
//do something
},

someVariable: {}
};
}
This code is using more of the associative array syntax, plus doing that check to make sure it's only called once. I find it's a little more "foreign" looking to me, but makes a good amount of sense if you're used to JS's variable syntax. Pick your poison I guess! Sometimes I do miss Java's class structure syntax...

The nice thing about using a global variable, to, is that you can really easily and concisely refer to your "functional grouping" in page elements and in other parts of your system, again without worrying about ever-changing meaning of "this" and using tons of oddball CreateDelegate functions... I find KISS (Keep it Simple Stupid) to be an important principle in making code I can read in the future, and in communicating my intent to other people looking at my code.

quick hit: a link o' snippets

2011-11-07T07:57:00.001-08:00

http://www.catswhocode.com/blog/10-jquery-snippets-for-efficient-developers has some decent little snippets, I liked the age verification one in particular, and the one for seeing if an image had loaded was good as well.

metablogger

2011-11-04T10:20:00.000-07:00

So yesterday was the first day I tried making an embedded interactive bit... it wasn't as bad as I had feared (I've used other blogging software that has the WYSIWYG mode kind of running roughshod over the code you're trying to include), weirdly the one gotcha was that none of the parts seemed clickable... firedebug showed a "clickTrap" div around where I was expecting the action to be. Doria's Design Notes had the fix, however, you need to put this as some CSS in the entry
<style>div.blogger-clickTrap {display: none;}</style>
Not sure what that's all about but the fix seems fine.

a more pleasing easing

2011-11-03T06:45:00.000-07:00

The other day I mentioned my admiration for making the jQuery animation default "swing". Today I'll talk about some of the other options provided by the jQuery Easing plugin.

Used judiciously, animations can make transitions to the state of the page less abrupt. Fiddling with easings gives you more options to add a "physicality" to the objects in question. Together, animation and easings can add a pleasant physicality (or bit of "juiciness" as I've got people saying at work.) to otherwise boring pages. (There's a reason why these kinds of animations and a sense of physicality is deeply baked into iOS...)

Actually, that page itself does a good job of showing usage... but I'm not crazy about the widget they give you to try out the various easings provided-- on that page, "The Clicker" always shows you 2 animations back to back (one for increasing the boxes size and one for putting it back) and so it's difficult to get a feel for each selection in isolation. Also, I think moving objects is a more common form of animation, and in general I prefer not to have to fiddle with select boxes. So I present: The Mover/Grower(tm). Like "The Clicker" it builds the list of easings by querying the module itself... you can set the speed, decide which (or both) of the things you want to animate, and then click to see any easing. (Click in rapid succession to combine.)

Mover:

Grower:

Speed:ms
Demonstrate:movegrowboth
jQuery Builtins:linear swing
From easing extension:

In terms of which of these to use, if you're in a hurry...our first use case for this was an object flying from off the screen-- "easeOutBounce" had the nicest feel to the landing. Some of the "In" animations feel a little corny when they start, like a Hannah-Barbara cartoon character getting its feet under it before starting to run, but "easeInOutElastic" is subdued and pleasant.

Some other caveats are that animations can feel choppy if there are too many at once, or if the page is still kind of loading, or if there's a json-ish query or what have you, so want to be careful and minimize other things going on on the page when the thing loads (for example, a second delay before a message notifiation flies in, or launching a JSON request on animation completion, rather than at the same time as the animation started.)

color animation

2011-10-31T12:11:00.000-07:00

As a developer quickly learns, jQuery offers a nice toolkit to fiddle with CSS on the fly. In particular, you can use animate() to trivially make rough transitions smooth:
$(".something").animate({"property-name":numericvalue);

The default easing (how it changes from the first state to the next) is called "swing", and gives a nice effect that implies the object has a bit of momentum. (It's a subtle touch of designer-influenced genius that they made the default "swing" rather than the nerdy, more-engineer-friendly linear...) More on easings later...

One seeming gap is that out of the box you can't use the animate() function on colors... but now, "there's a plugin for that", Bitstorm.org's jQuery Color Animation.

Put a reference to it atop your file:
<script src="/path/to/jquery.animate-colors.js" type="text/javascript"></script>
and then you're free to do something like
$(".userProfileHolder .yoopTab.messages").animate({"background-color":"#ffffff"});

A few small caveats:

with the version I'm using, you need to use r/g/b hex values, not the human readable colors like "white"
you need to make sure the object your modifying has a base color set (preferably in hex colors too.)
if you're changing, say, the background-color property, you may be implicitly setting the background color (or rather semi-explicitly leaving out the background color property) with the "background" shortcut property, which might cause problems. In today's case we were using a "background" property to show a transparent PNG, and then letting the parent's bckground color shine through. I broke up the "background" shortcut property into its individual parts and THEN set the background-color explicitly.

That's it though-- it's might handy and makes for some nice looking transitions than just toggling from one color to another

FancyBox: prettier dialogs

2011-10-24T11:29:00.000-07:00

So, one easy way of getting pretty (prettier than jqModal, anyway) modal dialog boxes is FancyBox. I've seen its distinctive "phillip's head" close button all over the place, so I'm guessing it's pretty popular.

Like jqModal, you put the content somewhere on your page, and then there are 2 functions, one for telling the library what should be in a dialog, and another for launching it.

FancyBox's boilerplate is similar to jqModal, with 2 exceptions:

You call the "make this a dialog" on the link that refers to the div, not the div itself. I thought this was a bit counter-intuitive.
If you use jqModal's jqmWindow class it default would tend to hide the content before it's ready, but with fancybox we tend to put the dialogs inside a div which is then hidden.

Here's the code:

<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>Page Title</title>
<link rel="stylesheet" type="text/css" href="fancybox/jquery.fancybox-1.3.4.css" />
<script src="jquery-1.4.3.min.js"></script>
<script src="fancybox/jquery.fancybox-1.3.4.js"></script>
<script>
$(document).ready(function() {
$("#fancyLaunch").fancybox();
});
</script>
</head>
<body>
<a href="#fancyDialog" id="fancyLaunch">Show Dialog</a>
<div style="display:none;">
<div class="jqmWindow" id="fancyDialog">
HELLO AGAIN
</div>
</div>
</body>
</html>

So pretty much the same.

Disclaimer, I did establish that it is FancyBox (probably it's modal screen) that is interfering with other animations we have on the page, that FancyBox interferes in a way jqModal doesn't. But for simple tasks, FancyBox has the edge because it's less work to make it pretty.

jqModal: flexible dialogs

2011-10-24T08:14:00.000-07:00

A common task is putting up a "modal dialog", a box that appears over the rest of the website.

We've been having some trouble at work that might be related to the modal kit fancybox. (More on that later.) Meanwhile I've started investigating jqModal jqModal, "Minimalistic Modaling with jQuery". Besides a possible timing issue we're seeing with fancybox, I appreciate how jqModal really strips things down to the basics, while still providing some sensible look and feel defaults. Here's the example boilerplate I came up with, just grabbing the js and the css from that link:

<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>Page Title</title>
<link rel="stylesheet" type="text/css" href="jqModal.css" />
<script src="jquery.min.js"></script>
<script src="jqModal.js"></script>
<script>
$(document).ready(function() {
$("#dialog").jqm();
});
</script>
</head>
<body>
<input type="button" onClick='$("#dialog").jqmShow()' value="show">
<div class="jqmWindow" id="dialog">
<a style="float:right;" class="jqmClose">X</a>
HELLO AGAIN
</div>
</body>
</html>

The trick is putting the content in the div, and then blessing it with ".jqm()". Although there is a facility for turning any link into a dialog launcher, I like that the emphasis is on the programmatic launch, just calling .jqmShow() on that dialog. I did use the link-blessing pattern for the close, however.

Easy, and flexible.

easy rounded corners

2011-10-24T07:20:00.000-07:00

So, probably old news to most developers here...

IE should be ashamed at not supporting any standards for CSS rounded corners up 'til the very recent IE9. Rounded corners looks better, designers are always asking for it, and faking 'em is generally a pain in the ass, involving polluting simple design with gratuitous graphics and/or ungainly structure.

The easiest solution to this is the jQuery Corner Plugin. In its simplest form you include the library:
<script src="/path/to/jquery.corner.js"></script>

and then something like this when the page loads:

document.ready(function(){

$(".selector_for_class").corner();

});
Unfortunately, you might get a small flash of square corners 'til the document ready kicks in, unless of course you're hiding items with a loading type screen.

The defaults for rounded-ness are well chosen, but if you want many more options you can check out the demo page.

The library uses native rounded corners where available (there were a few different standards, alas) and graphics for earlier versions of IE. In practice you sometimes get into trouble on older IE if the div is over a complex background.

Still, easy-peasy, and 9 times out of 10 it looks just great.

skeuomorphtastic

2011-10-19T10:52:00.000-07:00

Skeuomorphic design is a difficult to spell buzzword for an easy to understand concept: in the UI world, it's making virtual things look like their real world counterparts. Sometimes it's just window trimming, sometimes it's the core of the interface.

Here's a brief rundown on the thing. Apple has been a big proponent of this flavor of design, to some people's rant-tastic dismay. I agree that the leather-ette look is pushing things a bit, but I'd like to hear Apple's side of it. I assume the hoi polloi must dig it, even as the fanboy elite sniff.

an image making the rounds

If you don't go crazy with it, by and large it's an aesthetic decision. (In some cases it can help instruct a user in the use of an unfamiliar interface, but other times you're stuck with the limitations of whatever the physical device is. So from a usability point of view, it's probably a wash.) Personally I prefer the opposite approach as championed by Microsoft and their sense of Authentically Digital, shunning most of the chrome and gratuitous shading of many other design paradigms.

UPDATE: James Higgs rips into Apple for the use of this style, calling it infantile kitsch... I like any discussion of interface that can invoke the author Milan Kundera...

css selector 101

2011-10-18T07:14:00.000-07:00

So, around a year and a half ago I started my new role as "UI Engineer" at Pearson, for the then unnamed College Readiness startup they were incubating, now known as Alleyoop. I had a lot to learn when I started out... while I had always thought the work I did on my own websites gave me an edge as an engineer (I was used to doing sites front to back, including the frontends) I was kind of self-taught with a lot of the UI stuff, and a lot of best practices from the late-90s got stuck in my brain. (I know when I'm dealing with some old HTML of mine because I tend the tags in all caps: <TABLE><TR><TD>like this</TD></TR></TABLE>. Actually, in my heart of hearts I don't think it's a bad practice, it really makes it easy to see what's markup and what's content, but now it's so idiosyncratic, not to mention against all the "xhtml" standards, that even though it works and makes sense I don't do it.)

I was fortunate that some of the first alleyoop projects involved working on existing prototypes that made pretty decent use of jQuery and heavy use of CSS. (I had used CSS before, but generally just to replace bad old <FONT> tags and what have you. I had even done some fancy (for the time) work in in javascript, like this online editor for Atari 2600 sprites. It made heavy use of document.getElementById() rather than the sophisticated selectors that would be available later.) We had outsourced this work to some experienced people, and I was able to learn from it, even as I took advantage of my engineering history to improve on the javascript.

Anyway, recently I was helping one of the content people here manage a CSS template in Wordpress, and it made me realize I could put some learnings here, just in case I don't use CSS and jQuery for a while and forget, or in this blog's mission as a possible instructional guide. (This blog entry is probably jack of all trades, master of none, not low level enough to be good for beginners, way too simple to be useful to a veteran, and not comprehensive enough to be a reference! Ah well.)

So:
HTML elements will generally be identified for purposes of CSS styling by:

the kind of element they are- often a CSS stylesheet will apply a look to all elements of a type
a style slapped on to the element itself, e.g style="property:val;"
the class you assign directly to them with class="someclass" (and while any element should only have one class tag, an element can have multiple classes, e.g. class="someclass someotherclass")
a style applied to an element with a certain id ala id="my_unique_id"
A combination of 3 and 1 where it's elements of a certain class name, but only elements of a certain type.
A combination of 1 and 3, like where an element gets a style when it's inside another element of a certain class (for example all the divs inside a class'd containing div.)

So for each of these, you have a different way of selecting them in the style sheet:

To review, in a stylesheet (or block of CSS style) the format is:

selector {

someproperty:someval;

some-pixel-property:10px;

}

So what's the selector for each of these cases?

For all elements of a type, it's just the tag name, e.g div
If you're doing inline styles, you don't need to worry about the selector!
For class name, it's "." plus the name of the class, e.g. .someclass
For an id, it's "#" plus the id of thelement, e.g. #my_unique_id
For elements of a certain class AND of a certain type, you write the element type and then the classname, WITHOUT a space: e.g. div.someclass
For elements of a certain type WITHIN an element of a certain class, you use spaces: e.g. .someWrapperClass div
Finally, you can use commas when you want a block of style info to apply to different selectors, e.g.
elemselector1,elemselector2,.classname{
property:val;
}

There is an art and balancing act to choosing the right type of selectors. In my early days, I noticed how classnames could be very similar to keys in the Hash Maps I used in programming languages like Perl and Java, so I tended to use a lot of unique classnames. Also, I wasn't yet comfortable with selector type 6, there, and could barely understand the code I was looking at. (On the other hand, it is very possible to get over specific with your selector hierarchies there! If you're too specific about that stuff, than you can't reuse the styling because it only works when embedded in that particular setting)

Another rule of thumb is, if there are competing selector patterns, the more specific one tends to win, a style added via id is more specific than something applied to a whole class is more specific than something at the element level, so the "id" would win if there are conflicting CSS properties from different selector. (Of course if it's different CSS properties, they will be all applied, rather than having to fight it out.)

Also, I think people go a little nuts in avoiding inline styles; it violates the holy grail of "all beautification goes in the CSS file" but frankly trying to get a pure-content HTML page is a pipedream; and hell, that's what we have Content Management Systems for.) So if I need to nudge something a bit, and it's a style that is totally not reuasable, I might go ahead and style it inline. Sometimes it just makes more sense than making up an arbitrary key.

And that is how I cope with CSS selectors... I love, love, love that jQuery uses the same selector pattern. It makes like so much easier.

Also, as a "well duh" bit of advice to newbies: you probably NEED to have firebug on your system NOW if it's not there already. (It's also built into chrome, but I find Firebug a bit more deft) Being able to right click on an item and "Inspect Element" is a HUGE benefit, especially how it shows you what file the properties came from, as well as what other properties got ignored when there's one of those aforementioned conflicts. (The overridden property is indicated with a ~~strikeout~~.)

easy sortable tables

2011-10-17T08:08:00.000-07:00

This weekend I did a great quick project with a nifty new (to me) jQuery tool -- I found my final creation immediately useful, see the final paragraph)

The backstory: There's a videogame I enjoy destressing with called "Earth Defense Force: Insect Armageddon" (nothing more relaxing that using guns and rockets to save the earth from endless hoardes of giant insects and robots.)

The game has a plethora of weapons, and while the game reveals some hard data of damage dealt and reload times and what not, it's not always easy to figure out what the most effective weapons are... enter twxabfn's EDF:IA Weapon FAQ . It features a massive table with all 372 weapons listed. The trouble is... it's a massive table and a typical user is probably only interested in the weapons for the soldier type they're playing, and even then probably wanting to focus on weapon type or tier. (In short, they're probably looking for "what are the most powerful weapons for my character right now")

So, I decided to make a more manageable UI to that big flat table. I found Christian Bach's excellent jQuery tool tablesorter. With about one line of code, it makes a regular table sortable... it's smart about sorting numeric values by number (and not alphabetically) and you can even sort multiple columns.

The line of code in quetion is:
$("#myTable").tablesorter();

Put that in your document ready after including the js file like this:
<script src="/path/to/jquery.tablesorter.js"></script>
and you're good to go, more or less... (optionally you can tell it which columns to sort on to begin with)

A couple caveats: one is you need to use <th> tags if you aren't already, and include <thead> (to wrap the header row) and <tbody> (for the other rows) tags inside the table, something lazy or old school folks might not always do. The other thing to note is you won't get the nice up and down sort arrows or pretty formatting unless you also include one of the themes (two skinds are downloadable from the bottom of the page) e.g.:
<link rel="stylesheet" href="style.css" type="text/css" />

After adding sortable columns, I built some simple filters -- I added classes to each table row indicating what armor, type, and tier it was, put in select boxes with the available options, then wired it together with Javascript to call $(".rowclass").hide(); on all the rows that weren't included with the current filter settings. I played with the idea of making a more complex UI with multiple selects or checkboxes (useful if you wanted to, say, compare Rocket Launchers vs Missile Launchers, or this tier's weapons to the next) but thought that for now the extra power wasn't worth UX complexity.

I also made a little readout of how many weapons were being displayed out of all available.

You can play with the finished product and view source for coding details of the filters and line counts.

So in terms of being useful... yesterday I was able to run the numbers to see that the SV Diablero mk2 was CLEARLY the best bet for close-in fighting for Level 5 Tactical Armor soldier, over any other shotgun or assault rifle, and that the Long Wattkins mur Missile Launcher I was messing around with was a complete waste of time... like, I said, USEFUL! (For certain flavors of use.)

boilerplate

2011-10-16T06:35:00.000-07:00

I have a homebrew online database (in practice each db looks like a spreadsheet page, and then it autobuilds a form to let me edit and add entries. All backed by my old friends Perl CGI and flat files...) One of my databases is "jquery", and that's the one I'm hoping to convert an entry at a time to this blog.

Enough jawing, lets get to the meat of the thing!

One of the things I like about jQuery is that it's low overhead, you don't have to type too much to get things going. (My memory is verb-based rather than noun, good at remembering how things interact rather than exact syntaxes, so I appreciate easy-to-remember things like that.) Still, I find it handy to have the "boilerplate", the barebones code ready to go for a new HTML page that uses it.:

<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>Page Title</title>
<link rel="stylesheet" type="text/css" href="style.css" />
<script src="http://cdn.jquerytools.org/1.2.5/full/jquery.tools.min.js"></script>
<script>
$(document).ready(function() {
alert('Hello world!');
});
</script>
</head>
<body>
Content Goes Here
</body>
</html>

Thanks for the Improvements Ossian!

That's a good start! There might be some meta tags I'm leaving out, I'll look to improve it. But that boilerplate lets you know that hey, things are working, and it reminds me of the syntax for the link and script tags.

As a note, I used to think it was cool to link directly to remote .js files when invited to do so, but now having been burnt a few times by URLs that went away, I'm a big fan of pulling down the file, and making sure your page is self-contained. and as free of external dependencies as possible.

yadb - yet another dev blog

2011-10-16T06:15:00.000-07:00

This is my new blog, designed to help me keep track of things I've learned about UI and UX development. For now, that means a lot jQuery, with some general HTML5, CSS, and design thrown in.

This isn't just meant as a "notes to myself" blog, though I'm not expecting any big following. Besides replacing my private database of developer notes I've been keeping, this blog might serve to give potential employers and coworkers insight into how I think about UI... it's a little scary because I might inadvertently air some "dirty laundry", places where my opinion goes against conventional wisdom, or times when I'm willing to make shortcuts in the name of expediency, or otherwise let my old curmudgeonly hacker self shine through. On balance I think it will be worth the risk.

My job title is "UI Engineer", and I think UI is a fun place to be: it's the boundary of where the people meet the machines, and boundaries are always interesting areas. In my experience, there are two types of UI/jQuery developers: design people who are pushing to be engineers, and engineers who are pushing to be design people. I'm in the latter category, and I'd like to think that gives me a bit of edge in making powerful, delightful, "juicy" UIs, even as I have my own challenges in learning great design and graphic arts.