Software for Humans

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

The Benefits of Corporate Blogging

Tuesday, September 8, 2009 by Randy Cox

One vital component in any company is communication. Now that connectivity through the World Wide Web is enhanced and is made available to a large group of population, it is a good decision for big and even small corporations to make use of Corporate Blogging.

Corporate blogging is mainly focused in the online marketing side of a company. It is a way to connect to the employees and the most importantly to the clients. By creating a buzz online, potential customers will be able to get hold of the information and will gain trust and confidence in the product. A certain business blog is utilized to have a better outcome and also uniformity in the marketing process.

Like many great ideas also lies a downside to blogging. The opposite of gaining fame may strike caused by malicious attack or improper presentation of products and ideas.

It is important that corporate blogging will go along with the marketing policies of the company. Since corporate blogging is now widely used as a vehicle for communication and product launches, it is better to make use of it now so as not to be left behind by others.

Now is the beginning of the future.

The Wisdom of Robo-Baggott

Monday, September 7, 2009 by Randy Cox

Joining Robo-PJ is the newest markov chain based blogger, Robo-Baggott! Fed a steady diet of content written by his flesh and blood counterpart, Robo-Baggott can generate endless keyword rich blog posts at the click of a button. Here is a sample:

"Regular readers here know that this is were Marketing Democracy won. With Corporate or Organizational Blogging and adhering to blogging best practice! This Compendium Blogware is a perfect example. As a blogging best practice. Compendium Blogware is a terrific media if used correctly. Most of his advice comes right out of the company, the products and solutions and of course the passion of the fact that Home Pages are becoming less and less relevant in a world where people search, and can actually see and hear what your audience is thinking about."

Please understand that this is 100% experimental technology and there is no truth to the rumor that all of Chris Baggott's blog posts since July 22, 2009 were written by Robo-Baggott while Chris lounges on a beach in Hawaii.

Google Chrome for Mac: First Screenshots

Friday, February 13, 2009 by Randy Cox

Google released the Chrome web browser last year, but it was for Windows only. I got to try it out, but since I use Macs both at work and at home I felt pretty left out, to be perfectly honest. As a JavaScript developer, Chrome's V8 JavaScript engine really caught my attention when I first read about it in the (ahem) Chrome comic book.

My heart skipped a beat today when I saw the first screenshots of Chrome for Mac. To be fair, the software has a long way to go, but the Chromium development team is making progress. Take your time, Google, to get it right. But hurry!

Know For Sure That It's Broke Before You Fix It

Friday, February 13, 2009 by Randy Cox

I wrote previously about the benefits of experimentation in web application design. Such experiments will reveal conclusively whether or not a new feature, UI change, etc, will help your users or hinder them. But experiments will not tell you what new features you should consider implementing or what parts of the UI need streamlining in the first place. How can you figure out what comes next in your product development roadmap?

Most importantly, you need to know your users. They don't use your application because it is pretty; they use it to accomplish tasks. What are the tasks? As an application developer you might think you know, but your users might surprise you. I never would have expected that one of the tasks our blog admins need to accomplish with our software was to figure out who has won their blogging contest.

Looking at the list of tasks, which ones do your users find to be frustrating? If your application includes page analytics you can get an idea by watching which task workflows have the greatest abandonment rate. Your support staff may have hard data regarding the parts of your application that generate the most support calls. Don't only rely on their hunches, though; get the metrics.

Better Web Applications Through Science

Friday, February 13, 2009 by Randy Cox

Compendium Blogware's corporate blogging software has come a long way in a very short time. We've been adding new features and making changes to our application at a very rapid pace, mostly based on Ali Sales' and Chris Baggott's excellent knowledge of our market with a healthy dose of input from our support folks. That works fine for a startup company, but as a company grows it needs to get more scientific in its approach. Decisions eventually need to be made based on hard data.

The trick is to find a way to know for sure that a change you're making to your application is a beneficial one, and that information can only come from experimentation. Three men from Microsoft's Experimentation Platform Team have written a paper that describes how such experiments are performed.

The basic idea is that the new feature is shown to only half of your application's users for a given period of time, typically a week or two. The data collected during that time will tell you how effective the change is. Did the group of users who got the new green buttons on their interface complete their work faster and more accurately than the users of the old yellow buttons? The data will tell you.

User behavior can change dramatically as a result of even very small application changes, and often in very unintuitive ways. Get the real data and get rid of the guesswork.

Practical Guide to Controlled Experiments on the Web: Listen to Your Customers not to the HiPPO: http://exp-platform.com/hippo.aspx

More UI Design Patterns

Friday, February 13, 2009 by Randy Cox

A couple of weeks ago I wrote about Jenifer Tidwell's great Designing Interfaces book and the associated website. Now there's a new book, just released from O'Reilly, called Designing Web Interfaces. Where Tidwell's book is a broad look at proven UI patterns for all kinds of software, Bill Scott and Theresa Neil focus on the user interfaces of consumer web sites.

To tide over her readers until their books arrive, the authors are posting tasty morsels on their blogs. I'm particularly interested in this series of posts from Theresa Neil:

These posts explain the pros and cons of various user interface design patterns that users are all familiar with, particularly focused on the UI for rich Internet applications like the one we're building here at Compendium Blogware. It's a good place to start if you're having to design such an interface for the first time to ensure that you aren't reinventing the wheel. Stick with proven patterns and your users will feel more comfortable with your application from the start.

Improve Your Writing in One Simple Step

Friday, February 13, 2009 by Randy Cox

As an aspiring blogger, I'm on the lookout for things I can use to improve my writing. Here is a tip from Philip Yaffe, former columnist for the Wall Street Journal, that is very simple to do: Put the two most important bits of information at the beginning and at the end of each sentence. He calls them "hotspots."

Yaffe's article in ACM Ubiquity shows many examples that demonstrate the strength of this technique. A sentence organized in this way is far easier to understand than another sentence with the important ideas buried in the middle. Give it a try in your next blog post!

UI Matters: The $300 Million Button

Friday, February 13, 2009 by Randy Cox

How can a publisher justify selling a full-color, 220 page book completely dedicated to creating forms for a web site? Jared Spool has a great answer. . .

"It's hard to imagine a form that could be simpler: two fields, two buttons, and one link. Yet, it turns out this form was preventing customers from purchasing products from a major e-commerce site, to the tune of $300,000,000 a year. What was even worse: the designers of the site had no clue there was even a problem."

Read the whole story over at User Interface Engineering and it might change the way you think about the design of your website. Luke Wroblewski's book, Web Form Design: Filling in the Blanks, is giving me new tools to use in my quest to make our product the best blog software solution out there.

Using Markov Chains to Create Content: Introducing Robo-PJ

Thursday, February 12, 2009 by Randy Cox

Here at Compendium Blogware we are constantly searching for new ways to help our customers come up with ideas for new blog content. What if we could come up with technology that could just write their posts for them?

I've been experimenting with using markov chain software to create brand new posts based on existing content. I fed it everything written by Senior Software Engineer and prolific blogger, PJ Hinton, and the resulting Robo-PJ had a lot of very interesting things to say.

Robo-PJ is very candid about his early days at our company:

"Prior to joining Compendium, I can say there is no one right way to build user-friendly blog software. The transition proved to be antithetical toward that which makes blogs interesting."

He is very opinionated about how people are using our blogging software, perhaps placing blame on the very technology we use behind the scenes:

"Don't let your blog become a web marketer? It means that you have a chance to make sure that many a peril await those who gathered, dreamed up, and analyzed the information, those other parties have often themselves been shortchanged by the Yahoo User Interface library, XSLT, XML/HTML DOM, memcache, XML-RPC web services, RSS search feeds, just to become a one-way channel of communication with it's customers."

Robo-PJ makes strangely dark jokes about articles he has read:

"The story leads off well by asking readers to talk about the benefits of reuse comes at a conference that is as well as individual blogs. These topics are selected based on the "electric shock" feature, though. :-)"

He provides some unusual advice for blogging companies:

"His strongest argument is about tying corporate blogs to its full promise, service providers will need to build up a cheap book titled burps and Technorati."

The truth is, I'm pretty skeptical about some of Robo-PJ's sage wisdom:

"Compendium's approach to the bottom line? Be relaxed in your proofreading. That's just a search engine."

I don't think this technology is quite ready for prime time.

SitePoint Fire Sale

Tuesday, February 10, 2009 by Randy Cox

Technical book publisher SitePoint announced on their blog today that they are offering five books (in PDF format) for the price of one until this Friday, February 13. SitePoint makes really great books for web development folks, and this deal covers their whole catalog, so if you've got US$30 to invest in your craft, don't miss it.

Why the great sale? SitePoint is headquartered in Melbourne, Victoria, Australia. Victoria is currently experiencing a horrendous wave of bushfires that have killed hundreds and displaced thousands. The fires are considered to be the worst in Australian history. Every cent of the money that SitePoint takes in during this 5-for-1 deal will go to the Australian Red Cross for disaster relief. Their goal is to raise US$50,000 through this effort.

It's a good deal for a great cause. Way to go, SitePoint!

SitePoint Bushfire Relief Sale: http://5for1.aws.sitepoint.com/

A Content Delivery Network for the Masses

Friday, January 30, 2009 by Randy Cox

This week we took a big step for our blogging application and started using a content delivery network (CDN) to serve most of the "static assets"--files like images, CSS, and JavaScript that don't change very often. A CDN is a set of interconnected data centers that are placed all over the world, each caching files and delivering them to geographically nearby web browsers.

CDNs are a boon for website performance for a number of reasons:

Compendium Blogware's web servers no longer bear the burden for serving the files.
The files are replicated all around the world, making the files download much faster than if it was served from a single server.
Since CDNs have multiple data centers, they are more robust in the face of network outages, etc.

I thought it was pretty cool that our company can do this, but what about my personal website? I figured there would be no way I could afford CDN hosting, but I discovered a post by Matt Riggott on 24 ways that explains how I could use Google's App Engine service as a poor-man's CDN without having to pay a cent. There are some limitations and hoops to jump through to get things running, but Matt's instructions are very thorough, and you can't beat the price.

Matt Riggott's article: Using Google App Engine as Your Own Content Delivery Network

Indispensible UI Web Site: Designing Interfaces

Thursday, January 22, 2009 by Randy Cox

Jenifer Tidwell is a well-known voice in the user interface design community. In fact, she wrote the book on the subject. She maintains a very helpful reference of "design patterns" (really just an abbreviated version of the patterns she describes in her book) to help folks solve UI problems. It's a great list, and if you ever need to create a new UI for a website or an application, take a look at her list before you try to invent some new UI technique. There's a good chance that she'll describe something that will fit the bill. If not, it's still time well spent because you'll come away with lots of ideas of what might work and what probably won't in your quest to create a predictable, usable interface.

Jenifer Tidwell's Designing Interfaces: Patterns for Effective Interaction Design: http://designinginterfaces.com/About_Patterns

Slick-looking or Usable?

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/

FireUnit: JavaScript unit testing extension for Firebug

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

Is it time for another browser war?

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

I love you! I eat your website!

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:

In 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:

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

I love this job.

The Paradox of Technology

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.

When Not to Do It Yourself

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.

On becoming a Douglas Crockford fanboy

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.

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