Today I want to announce the project I've been working on as a hobby for most of the past year: QuickUI, a framework for creating web user interface controls. The work on QuickUI has taken the place of my normal blog writing, hence the long hiatus here on flow|state.

Why create a web control framework?

I couldn't find anything that met my needs. I was so completely frustrated by the dearth of good tools in the middle ground between image editors (PhotoShop), prototyping tools (I've often used PowerPoint), HTML editors (e.g., DreamWeaver), and raw code using JavaScript UI frameworks and libraries (jQuery et al.). There are plenty of tools contending for this middle ground, but to me they seem to avoid working with the substance of the web—HTML, CSS, JavaScript—in favor of something that obscures those technologies (Cappucino, etc.) or does away with them altogether (Silverlight).

I want to work in the real stuff of the web. The web is built with HTML, CSS, and JavaScript, so that's what I want to use. I just want to be more efficient doing so. The fact is, those technologies are riddled with idiosyncrasies, and I don't want to feel like I'm solving the same problems over and over again. And it's not just me—the UI world wastes uncounted hours painfully (re)learning the various hacks to do something as simple as centering something on the page.

For me, the worst problem with the web is that it lacks a native control framework. There's no way to easily bundle up a bunch of content, visual styling, and behavior into a reusable control. There are certainly JavaScript control frameworks (YUI, jQuery UI, etc.), but most seem to be either a very small library of common controls, or a set of utilities for writing controls on your own. Nothing seems to be scaling up to permit an ecosystem of controls. The Visual Basic 1.0 community had a more vibrant control ecosystem of VBX controls in 1991 than the web does nearly twenty years later.

I'm sure the HTML 5 team has worked long and hard to get to where they are today, but the last thing I need are new HTML tags with fixed semantics. What I want is to be able to write new tags and define their semantics. (XAML is great, and would be incredible if it weren't proprietary.)

A good framework should give me a way to package things up so that I can easily share those tags with other people—and they can share them with me. If we had a good control framework, someone could package up good solutions to common problems as live code. I wouldn't have to find the answer to my question on StackOverflow as little fragments of HTML, CSS or JavaScript embedded in text—the answer to my question would be a fully reusable piece of self-contained working code.

A markup language for controls

The control framework I envisioned was built around a markup language that looked and felt like HTML, but defined controls (at any level of the UI) instead of only pages. The control would define a new tag, so it could be used inside of other controls just like a native HTML tag. As with HTML, the control markup would define document elements for the control's contents, a <style> tag for CSS defining the control's visual appearance, and a <script> tag for JavaScript defining the control's behavior. A control would be packaged up in a single file that could be added to a new UI project simply by copying the file into the project folder.

This idea eventually took shape as QuickUI, and evolved into the release I'm announcing today. For details and examples, including a full tutorial, please see the QuickUI site. Here I'll simply mention that QuickUI currently comprises:

1. The Quick markup language for defining new controls.
2. A compiler for compiling Quick markup files into JavaScript and CSS files.
3. A build tool for compiling a collection of Quick markup files and combining the generated output into a project-level .js and .css file.
4. A JavaScript library used by QuickUI controls at run time.

The QuickUI compiler and build tool are themselves written in C#, and I use the tools on Windows machines and Macs (via Mono) alike. (For the time being, I've posted instructions only for Windows use, but hope to document Mac use soon.)

The generated JavaScript makes use of the jQuery library to build the user interface on demand. QuickUI works well with jQuery, but should be able to interoperate with other JavaScript frameworks.

Adding a compile-time step to web UI design is, admittedly, a hassle—but only a minor one. A small amount of tinkering with a reasonable development environment makes it possible to automatically invoke the QuickUI build tool whenever a Quick markup file is updated. These days I prefer Aptana Studio, and have documented steps for integrating QuickUI into that environment on the QuickUI site. Other tools make similar integration possible. With that in place, working in Quick markup feels only a small step removed from working in raw .html and .css files, and the productivity gains of a modular control framework quickly outstrip the minor inconvenience of compilation.

So far, so good

I now use QuickUI almost exclusively to quickly prototype functional UI designs for Cozi. I occasionally take recourse to PhotoShop to create image assets for inclusion in specific QuickUI controls, but the vast majority of my design work is now authored in Quick markup. The tools are good enough for my everyday use that I'd never go back to working without such a framework. And, as I slowly build up a library of reusable controls, I'm spending less and less time fighting old problems, and more time moving forward.

I consider the current state of QuickUI to now be minimally interesting to others, hence this announcement. Nothing’s set in stone, and any part of it could be made better.

If you're interested, please check out QuickUI for yourself. You can post questions or comments on the discussion board there. If you like this and want to make it better, I would welcome the help.

Just breaking the radio silence to say that this week I'll be down in Newport Beach, CA, attending UIE's Web App Summit 2009. If you'll be there, let me know via a comment or mail to jan at cozi dot com; it'd be great to connect in person.

At the beginning of January, I set myself a goal to see if I could make at least one post on flow|state a month. January's now over, with no post. I've had a draft of the promised follow-up to the last post on the Shared Suffering Hypothesis under construction for three months. (Thanks to Michael, Barry, Evan, & co. for their comments, the most interesting dialogue I've received on a post in a long while.) I still can't find the time to finish off the darn post.

Tinkering endlessly with computer hardware and software can be fun... if you have the time. As for me, I eventually came to the paradoxical conclusion that the more I tuned a product to my specific needs, the less likely the product would actually work as intended—and the less likely I could find someone to help me when a problem did arise. Product manufacturers often tout the ability of their products to be configured to a user's idiosyncratic needs, but maybe users can most effectively minimize heartache this way:

The Shared Suffering Hypothesis: You're best off configuring a product so as to maximize the number of other people who can help identify and resolve problems with that configuration.

Here's an example: A number of years ago I set up a media PC, eschewing the small number of commercial media PCs then available to get a tricked-out gamer PC. I maxxed every spec—video card, hard drive, etc.—and for its day, this machine rocked. What didn't occur to me was that, with each component I picked, I was reducing the number of other people who had the same device I had. And upon receiving the box, I wiped it and installed an early beta of an obscure OS version. Fantastic! Now I had a blazingly fast PC, the likes of which were possessed by no one else on the planet!

I was a user community of one. When sorting through the inevitable driver weirdness and other nightmares, I had no one to turn to for help, because no one else shared this configuration or anything like it. The OEM and its component manufacturers, of course, had no experience with that OS, nor had the OS manufacturer ever tested on any of that hardware. The nascent media PC user community couldn't help either. This left me solving every configuration issue on my own. I spent hours on exciting tasks like trying to see if the PC motherboard would cope better with the hard drive configured for RAID 0 or RAID 1, or maybe I should try RAID 5? Damn, and all I wanted to do was watch TV on this thing.

Lesson learned, when I bought a new media PC a couple years later, I abandoned impressive computer specs in favor of amassing the largest number of people who could share my problems. If I ran into a problem, I wanted a hundred other people to have already hit it and collectively solved it. I purchased a basic media PC from a huge OEM—not because they made great media PCs, but because they sold a lot of them. I purchased the most vanilla configuration possible, more or less blindly accepting the OEM's self-serving default hardware recommendations. The more defaults I could accept, the more likely it was someone else would have something like the same box I did. When the box arrived, I tried hard to avoid changing anything from the default config, and in generally avoided installing funky apps on the box. In the end, the new PC wasn't a perfect media experience—but it worked, and I spent very little time keeping it that way.

(And now the impending forced cutover to digital cable in the U.S. is going to kill me. It's forcing me to rebuild a perfectly good media PC setup, all so that our seldom-watched analog cable TV can now be a seldom-watched digital cable TV. Once again I'll be searching for the solution that involves the least weird configuration.)

The problem here are the economics of configuration. You'd think you'd benefit by tailing a product to your needs, but I believe in most cases that benefit is overwhelmed by the benefits of not customizing. And the issue has implications for software designers: each time you add an option to your product, you might be making things worse for your users, not better. I'll take a cut at that question in the next post.

Next time: The economics of configuration

Last week Cozi posted an update to our family calendar that included a small but significant usability fix to the UI for entering appointments. In addition to a traditional form-based UI for entering appointments, the bottom of the main calendar page offers a text box in which a user can type an appointment in English:

In general this UI for entering appointments works well, but usability testing had indicated that a sizable population of users would hesitate when entering an appointment. They would type the text of the appointment, then move their mouse over the right end of the text box, apparently searching for a button they could click to save the appointment.

These users were likely conditioned by web browsers, which generally have a Go button to the right of the address field. Advanced users generally don't click the Go button (and may take steps to hide it), but many users navigate with it. We had originally left off a Go button in the interests of reducing visual clutter, and expected people would be able to figure out they could just press the ENTER key to save the appointment.

In testing, it became apparent that we were correct, but only to a point. Most users would, in fact, eventually try pressing the ENTER key. The issue is that it would take a second or two of uncertainty before they would figure it out. We didn't like the thought of producing any uncertainty or anxiety, especially in relation to the natural-language appointment feature. That's a star feature in our calendar, and we want to show off. (Yes, Google Calendar and others have a similar feature, but we think ours is better.)

We were reluctant to add a permanent button to the page if we could avoid it. Instead, we opted to follow the lead of Internet Explorer and Firefox and use a transient control: a control that's only visible part of the time. Both IE and Firefox used to have their Go buttons visible all the time, but both changed the Go buttons to a transient control that is only visible when the user is actually typing a URL.

Here's how it works in Cozi's case. When the user enters the page, the focus is in the appointment entry text box. The text box sports hint text to let the user know what the text box is for. (Significantly, the hint text does not disappear when the text box has the keyboard focus—since the text box has the focus by default, hiding the hint text on focus for this field would mean the hint text was invisible when it would have been most valuable. If the user clicks on the text box, we do hide the hint text, so the user doesn't waste any time trying to delete the hint text before typing their own text.)

When the user starts typing, the transient Enter button appears on the far right:

When the user moves the mouse (not shown below) over the Enter button, the Enter button exhibits its hover state:

The user presses the button or types the ENTER key, and the appointment data is sent to the server to be parsed. During this round-trip to the server, the text box and its associated change to a quasi-disabled state to suggest that: a) something is happening, and b) the user shouldn't type again until the text box has left this state.

When the updated calendar data returns from the server, the calendar view updates to show the new appointment. The appointment entry text box resets to its original state to let the user know they can type again:

So far, this transient Enter button seems to work well, but we will continue to watch that button closely in testing. We're cautious about employing this UI technique, because it's easy to accidentally sacrifice discoverability in the name of visual cleanliness. Here the transient control works well because it manages to appear just when a user is about to start looking for it. In other cases, a user might hold their mouse still while looking around the page, and if they didn't see the control they were expecting, they might jump to the reasonable conclusion that such a control did not exist.

I find myself faced with the question of whether to accept animated ads in an ad-based product. An animated ad likely detracts from the user's experience—everyone says they dislike them—but to what degree? I'm finding it difficult to find persuasive research quantifying that effect.

It's relatively easy to find data on the side of the advertiser or the site showing the ad. An animated ad will likely be noticed by more people, and can have higher click-through rates, which is what an advertiser is looking for. Accordingly, a site willing to show an animated ad can charge a higher premium for such an ad over a static ad. Animated ads = more revenue. It's hard to argue with that—especially at an ad-funded startup.

To put the potential revenue upside in perspective, I'm looking for concrete research on the impact of animated ads on the user experience. Here's the kind of research that would be most helpful:

• Hard data. An anecdotal personal claim that, "I refuse to use a site that shows an animated ad", holds little weight. Same goes for claiming, "Everyone hates animated ads... obviously!" If everyone hates animated ads, then it should be easy to find research proving that point.
• Focused on the actual effect on site usage. The little research I can find seems focused on user opinions. (Example, from Jakob Nielsen's AlertBox) I don't want to know whether people like animated ads—I want to know how much they actually impair site usage, or diminish a site's brand, or drive people away.
• Recent. I can't use a study done way back in the halcyon days of 1997 when the web was fresh and new and people didn't think there should be ads in it anywhere.
• Expressed in money terms. It'd be helpful to find, for example, a case study comparing a site's gain in ad revenue from the introduction of animated ads with the monetary downsides (if there are any) of those same ads.
• Objective. A tiny study done by a user interface designer with a personal bias may not help. A large study done by a company that's taking the long view, and trying to balance revenue with customer satisfaction would be better. A peer-reviewed scholarly paper on the topic would be ideal.

Any timely pointers here would be helpful in making this decision. Thanks.

Updated 6/22/08: A big thanks to Michael who in the comments posted links to a pair of relevant papers. Those papers were very helpful to us in deciding whether to accept animated advertisements. We ultimately did decide to accept animated ads, but did put in place some guidelines that we hope will keep out the more egregious uses of that medium.