Kirk's UI Dev Blog: October 2011

Monday, October 31, 2011

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

Monday, October 24, 2011

FancyBox: prettier dialogs

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

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

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.

Wednesday, October 19, 2011

skeuomorphtastic

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...

Tuesday, October 18, 2011

css selector 101

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~~.)

Monday, October 17, 2011

easy sortable tables

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.)

Sunday, October 16, 2011

html5 boilerplate

UPDATE: here's a version updated to use handlebars as well...
(And semi-related: here is something similar for p5.js)

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 lang="en">
<head>
<meta charset="utf-8">

<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Page Title</title>
<link rel="stylesheet" type="text/css" href="style.css" />
<script src="https://code.jquery.com/jquery-1.9.1.min.js"></script>
<script>
$(document).ready(function() {
alert('Hello world!');
});
</script>
</head>
<body>
<div class="content">
Content Goes Here
</div>
</body>
</html>

And while we're at it, here's a style.css with some things I use a lot:
body {
background-color: white;
color: black;
font-family: sans-serif;
}
a {
color: black;
}
.content {
width: 800px;
margin: auto;
}

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. (Followup: I also like this javascript Singleton pattern as a page controller object.)

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.

Another followup: remember that OSX et al have a nice little webserver builtin:
python -m SimpleHTTPServer 8081

or with CGI:
python -m CGIHTTPServer 8081

Yet another followup: replaced http://code.jquery.com with //code.jquery.com - now that my sites are https, they balk at running stuff from untrusted places, and whackwhack fixes that.

Follwup to the followup: replaced "whackwhack" with https://, since whackwhack doesn't work when doing stuff locally ala file://

FOLLOWUP: HERE'S THING MINUS JAVASCRIPT AND PUTTING THE CSS IN THE FILE ITSELF
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Page Title</title>

<meta name="viewport" content="width=device-width, initial-scale=1">
<style>
body {
background-color: white;
color: black;
font-family: sans-serif;
}
a {
color: black;
}
.content {
width: 800px;
margin: auto;
}
</style>
</head>
<body>
<div class="content">
Content Goes here
</div>
</body>
</html>

FOLLOWUP 2:

Often when I am churning out a quick and dirty PHP page, I want to use one of these functions to read CGI params without generating noise in my log if some fields aren't present:

yadb - yet another dev blog

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.

A UI Developer's Blog