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.

It's sinking in that helming a startup through a stormy economy while adequately parenting three young children just doesn't leave enough personal time to do this blog justice. FeedBurner says I've got several thousand subscribers, and I've occasionally run into readers who offered me their encouragement (thanks, John F.!). I would prefer not to leave them wondering why there's no activity.

I need less stress, not more, right now, and think the safest thing to do is declare an indefinite blog hiatus. There are still countless UI topics on which I would like to write, and I hope at some point to find the time to get some down. At that point you—and I—can be pleasantly surprised. Until then, thanks for reading.

Best,

Jan