"You're what kind of an engineer?"
I'm Randy Cox, a Senior UI Engineer here at Compendium.  The vast majority of software currently in the world only has to interact with other software.  But as a User Interface (ah-ha!) engineer, nearly all software I write directly interacts with people.  I work on all of the stuff that end users can see and touch on their screens.  My goal is to make Compendium's blog management software as user-friendly, accessible, and (ideally) beautiful as possible.

On my off hours I like making things (kites, games, etc) as a means to entertain myself and my children, watching foreign-language DVDs with my wife, and learning new storytelling techniques to try and hold the attention of the preschoolers at church.
Comments (0)

Slick-looking or Usable?
Posted Friday, December 19, 2008 by Randy Cox
You can pretty safely assume that any article with a title that starts with some variation of "10 Great Tips For..." is going to knock your socks off.  Case in point: Dmitry Fadeyev's article for Smashing Magazine entitled "10 Useful Techniques To Improve Your User Interface Designs."  Fine, Dmitry didn't break any new ground, but he did describe a few techniques that I've been considering for our application.  One UI technique in particular I've been pondering for a while. He calls them hover controls.

The administration portion of the Compendium Blogware platform includes a user list from which to perform various operations on individual users.  Administrators can edit user info, grant or revoke administrator rights to users, etc, and there's precious little space left for adding new buttons.  One way to squeeze more functionality into the user list is to use hover controls.  If you've used any of the 37signals apps, you've seen these.  You move your mouse over a simple-looking list of data, and icons will pop out of the row that you're hovering on.  Click an icon to perform an action on the user in that row.  If you move your pointer away from the row, the buttons disappear.  It keeps the interface a little cleaner since the page isn't cluttered with action buttons for every row in the table.

Hover controls make a very slick-looking application, but it gains the slickness and clean appearance at the expense of a little usability.  When a user of a website first loads a page to accomplish some task, the first thing they do is look for something to click.  When the action links are hidden, the user may be confused.  Even if the confusion lasts only for a second, odds are that they will apply a little red X next to the application in their subconsious. Too many little red Xs, and the user will have a negative emotional reaction to your application, although they might not be able to explain exactly why.

The moment of confusion is avoided only with training or experience in using the application, and probably a visual cue that there are hidden buttons.  The hope of the UI designer is that the learning period is very short so that there isn't much time to build up many red Xs.  Furthermore, we hope that the visual appeal of the page, the ease of accomplishing their task quickly, and the "neato" factor will earn enough green checkmarks that the user will have an overall positive reaction; that they will like using your application.  Users are more productive if they like the application they're using, and making happy, productive users is what a UI engineer's job is all about.

The article: http://www.smashingmagazine.com/2008/12/15/10-useful-techniques-to-improve-your-user-interface-designs/
Comments (0)

FireUnit: JavaScript unit testing extension for Firebug
Posted Friday, December 19, 2008 by Randy Cox
John Resig, creator of jQuery and a member of the Firebug development team, announced yesterday on his blog the release of a JavaScript unit testing extension to Firebug/Firefox called (what else?) FireUnit.  It's a very young tool, so right now it doesn't have a ton of features.  There are APIs for asserts, string compares (including regexes), simulating UI events like mouseDown, clicks, and keypresses, as well as running a batch of tests that are defined in a specified HTML file.  Test results are published to a new "Test" tab in Firebug.

The tool was originally intended for testing of Firebug and other Firefox extensions.  That's a task that can't be easily accomplished with other JavaScript unit testing tools since other tools can't access Firefox's browser "chrome" to get at the extensions.  Still, it has potential for general web application unit testing as well.  I'm going to give it a try on some front-end code here at Compendium.  We have a good system of unit testing of our back end code using phpUnit, but it's a weak area for our front end.  Unfortunately FireUnit won't be usable for automated testing.

FireUnit is open source software licensed under the MPL.

Release announcement: http://ejohn.org/blog/fireunit/
FireUnit website: http://fireunit.org/
FireUnit wiki on GitHub: http://github.com/jeresig/fireunit/wikis

Comments (0)

Is it time for another browser war?
Posted Friday, December 12, 2008 by Randy Cox
I watched a very interesting presentation from Douglas Crockford the other day.  He examined the lack of progress in web development and web browser technology over the past decade and speculated on some ways to bring innovation back to web software.

Back in the early 1990s, nobody complained about stagnation in web technology; we were in the middle of the "Browser War," and stuff was changing faster than web developers could keep up! Browser makers Netscape, Mozilla, and Microsoft added features to the flavors of HTML that their browsers supported without regard for compatibility, so designing a site that worked consistently across browsers was very hard.  The solution to the problem was standardization.

The W3C (World Wide Web Consortium) in the US, and ECMA in Europe took the best of the features from the various browsers and created a standard for subsequent browser versions to follow, which they all eventually did to varying degrees.  Today's web browsers provide a much more stable, level playing field for developers, and they rejoiced.  The browser war was over, and at the time it seemed like the developers themselves were the winners.

Crockford now points out that the standards we are now using are ancient, by Internet standards.  The latest HTML standard (version 4.01) and JavaScript standard (ECMAScript 3) were codified in 1999.  Progress toward developing updated standards has been slow and extremely painful because nobody wants to break existing applications and browsers.  In short, the standards that we thought were are our saviour turned out to be our curse.  What can be done?  Crockford's call to arms: "Bring it on.  It's time for a Browser War."

If browser makers begin to focus on innovation at the expense of compatibility, the job of web developers will once again become very hard and websites will become more expensive and time-consuming to produce. But will the value of the innovation outweigh the temporary pain?

Perhaps the tree of web technology must be refreshed from time to time with the blood of web developers and standards bodies...
Comments (0)

I love you! I eat your website!
Posted Friday, November 14, 2008 by Randy Cox
A couple of weeks ago I made a page that will be displayed if there is a catastrophic problem with our behind-the-scenes servers and databases.  The old error page displayed a bunch of stuff that would be completely unhelpful to all but five people in the whole world.  It looked like the quadratic formula had exploded.

I wound up making a very silly error page that used a goofy photo of a plastic toy dinosaur taken by my friend Jeremy Stockwell.  If we do our jobs correctly, you may never see the page in real life, so here is a screenshot:Failosaurus screenshotIn case you can't see it, the dinosaur is saying "RAWR! I eat your website!"  Imagine my surprise when my teammates presented me with this t-shirt last week:

 Dinosaur T-shirt

That's right, kids: RAWR means "I love you" in Dinosaur.

I love this job.
Comments (0)

The Paradox of Technology
Posted Thursday, November 13, 2008 by Randy Cox
Book cover image: The Design of Everyday Things, by Donald A. Norman
"The same technology that simplifies life by providing more functions in each device also complicates life by making the device harder to learn, harder to use. This is the paradox of technology."
This statement was as true in 1988, when Donald Norman wrote it, as it is today.  Norman's book, The Design of Everyday Things, has become essential reading for anyone in the business of designing things that will be used by humans.  Teapots, doorknobs, and yes indeed, web user interfaces.

There are some products that have hit the feature/complexity sweet spot.  The iPod is a good example.  Until the iPod Touch, the user interface of Apple's portable music player remained largely unchanged: A circle for scrolling, five buttons and a switch.  Many other music players that had more features, but Apple's decision to keep their device as simple to use really payed off--at the last count, 50 bajillion iPods have been sold*.  Now that the technology is cheap enough to put a high-res touchscreen on a pocket-sized device, Apple can now add new features without having to worry about where to put the new buttons, which would make their product more difficult to use.  People who want to use the advanced features can do so, and the folks who are satisfied with the basic features can ignore everything else.

As we add new features to our blogging platform, we think about the Paradox of Technology, even if we don't call it by name.  It's a fine line to walk, and I know we will make mistakes along the way.  One thing that I love about this job is that I have the opportunity to make frequent updates to our software (we average one software release a week), so if we find a problem we can fix it quickly.  It's gratifying to have a hand in creating a product that gets better and better all of the time.

* I made this statistic up.  But I'm sure it's close.
Comments (0)

When Not to Do It Yourself
Posted Tuesday, October 28, 2008 by Randy Cox
I'm a do-it-yourselfer at heart.  I like to be in control and I don't like to have to rely on other people for things that I can do myself.  In spite of this tendency, I've learned that there are certain things that I should leave to others.

I live in Noblesville, a little town on the northern edge of the Indianapolis Metro Area.  At my last job I commuted 45-minute each way to my office on the west side of Indy.  Now that I work downtown I can take the bus, and I've realized that driving through rush hour is one thing that I definitely prefer to let someone else do.  It's a 15-minute drive to catch the express bus that drops me off 30 minutes later, two blocks from my office.

There are lots of benefits to leaving the driving to the pros.  I save on gas.  I don't have the expense of parking downtown.  I'm forced to be more disciplined about my work schedule.  Best of all, I can do other things while I ride; I nap, read, do work on my laptop--I'm writing this blog post on the bus!  My wife told me that I'm in a much better mood when I get home now than I was when I had to drive.

As a software developer, I used to want to build as much of my software as possible from scratch.  My excuse was that I wanted to understand every detail of how the software worked.  Now I've realized that I can be far, FAR more productive if I use a software library.  For example, here at Compendium we use the fantastic Yahoo! User Interface library in most of our front-end web application code.

Could I create a site that would be just as good without it?  Maybe.  If I could afford to spend months implementing every little feature.  I'd spend most of my time trying to fix browser compatibility problems.  The people who create YUI are individually expert in various aspects of web development; I would need to become an expert in everything.  It simply would not be practical.  I used to think that using a library was a crutch.  As it turned out, I have learned more about web development in less time by using YUI and learning from the YUI team than I ever would have going it alone.

What about improving search engine optimization for your company?  Could you create a ton of topic-specific blogs and manually fill them each with relevant content?  Sure you could.  But wouldn't it be better to spend less time worrying about SEO tricks and more time on your real job?  You should really consider leaving it to the experts here at Compendium Blogware.
Comments (0)

On becoming a Douglas Crockford fanboy
Posted Wednesday, September 24, 2008 by Randy Cox
If our Seth Godin-obsessed CEO is truly the trendsetter people make him out to be, then I supposed I shouldn't be ashamed to announce that I've recently become a Douglas Crockford fanboy.  It happened entirely by accident, I assure you; I was not actively searching for a hero.

JavaScript: The Good Parts book coverIt started when I was in the midst of the job search that landed me here at Compendium.  I needed to brush up on some of the more advanced JavaScript programming techniques, and like many software geeks, I started by surveying the latest O'Reilly books on the topic.  The most current book I found also had the snappiest title: JavaScript: The Good Parts, by Douglas Crockford.  I printed out the sample chapter and spent many days puzzling over it.  It went way beyond the depth of JavaScript magic than what I suspect most web developers would care to master.  I was intrigued by this man who had obviously devoted a huge amount of time and energy studying a language that most developers had written off as a toy for the first decade of its life.

The book states in no uncertain terms that many features of JavaScript are bad, awful, and even evil.  I kid you not.  Even so, Crockford is clearly fond of the language and uses his book as a soapbox from which he can preach his message of how to use the good parts of JavaScript to make elegant and powerful software.

Once I joined the Compendium Blogware engineering team I needed to learn YUI, the Yahoo! User Interface Library.  Yahoo! provides a great library of videos for developers who want to use their tools.  Since Crockford happens to be Yahoo!'s resident JavaScript guru, he stars in many of the videos.  Now I had a face and a voice to put with the name and the strong opinions put forth in the book.  Crockford typically appears in worn jeans and a sloppy shirt.  He's got gray hair and a scraggly beard and his manner brings to mind a grumpy old man who yells at kids to get off of his lawn.

Crockford wrote a JavaScript code-checking tool called JSLint that I started to use.  He warns on the website that "JSLint may hurt your feelings."  At least his software is consistent with his personality.  JSLint enforces a style of JavaScript programming that many programmers would find to be overly restrictive, but each restriction is backed by common sense and vast experience with the language.  The idea is that is we write JavaScript code within his framework, the code will be more readable, less ambiguous, and less buggy.  It's hard to argue with that. Crockford is very active on the JSLint Yahoo! group, which is fantastic for us fanboys, but his replies to many questions posted to the list are terse to the point of almost being rude.

"Oh," we fanboys say. "That's Crockford for you."  Then we smile and shake our heads a little.
Comments (0)