Ending active development of QuickUI

I’ve decided to end further investment in the development of the QuickUI web user interface framework.

I’ve spent the past half-year experimentally porting various QuickUI components to HTML custom elements under the rubric of a project called Quetzal. That project makes use of Google’s Polymer project, which supports the deployment of web components to mainstream browsers. While the Quetzal element collection doesn’t yet offer the complete set of QuickUI components, and working on top of Polymer has been shaky at times, Polymer is becoming good enough for real use, and the advantages of building with web standards will quickly outweigh any proprietary advantages which QuickUI could offer.

I started QuickUI a number of years ago because it seemed clear to me that a component-oriented approach to UI design and development would let you create better and more maintainable user experiences. I didn’t see anyone else working on that in an open way, and so began my own effort to make progress in that area.

The current wave of web component standards embody many of the ideas I was pursuing in QuickUI. For fun, I just dug up from my notes the earliest source code I could find for the component markup language I thought would be useful for creating web components. Here’s sample QuickUI markup I wrote at the very beginning, probably late 2007:

<control name="taskPage" arguments="name pageTip content">
    h1 { font-face: Arial; }
  function foo() { }
    <div ...>
      <p class="pageTip">%pageTip%</p>
      <div id="#content">

Here’s the corresponding source code in late 2013 for the same custom element in Polymer:

<polymer-element name="task-page" attributes="name pageTip">
  function foo() { }
      h1 { font-face: Arial; }
    <div ...>
      <p class="pageTip">{{pageTip}}</p>
      <div id="#content">

Aside from minor syntactic differences (curly braces are in vogue now instead of percent signs; “attributes” instead of “arguments”; the style tag needs to be inside the template instead of outside; the element name requires a hyphen), the source code is nearly identical. In other words, the source code I wanted to be able to write in 2007 is essentially the source code I can now write today. Hooray for the open web!

Going forward I’ll be using web components for my own work rather than QuickUI. If you have been using QuickUI or were interested in QuickUI, I would encourage you to look at adopting web components instead, either through the Polymer project or through similar projects such as Mozilla’s x-tags.

I’ll continue to keep the quickui.org site live for the indefinite future. In particular, for the time being I’ll continue to use this blog to post thoughts on developing user interfaces, with a focus on using web components.

To those of you that used QuickUI or provided feedback on it, I’d like to offer my warm thanks for all of your support.

Jan Miksovsky


QuickUI 0.9.4 released

This release fixes a number of small bugs in both QuickUI and the QuickUI Catalog.

The most significant change is in the Control constructor. QuickUI previously went through a lot of trouble to subclass jQuery. This code involved patching up a class when an attempt was made to instantiate it so that the result would be acceptable to jQuery. Specifically, the resulting patched-up class could be instantiated without requiring the “new” keyword. This code was quite complex and brittle, and was eventually broken by a change to the CoffeeScript 1.5 compiler. The CoffeeScript folks graciously backed out that change in CoffeeScript 1.6 so that QuickUI could continue to function.

Meanwhile, a workaround had already begun to drastically simplify the Control constructor — in exchange for dropping the ability to instantiate a control class’ constructor without the “new” keyword. As it turns out, QuickUI controls are typically instantiated via the framework itself, either declaratively through Control JSON or imperatively by invoking Control.create(). Only the framework needed to directly instantiate a control class, and so the framework source was updated to always make use of the “new” keyword.

By the time this workaround was ready for deployment, the CoffeeScript 1.6 change made that workaround unnecessary. However, because the workaround was already working, and had significantly simplified the framework source, it was decided to keep the workaround. It was probably still correct for CoffeeScript 1.6 to back out the earlier breaking change to control constructors in CS 1.5. As this experience shows, the change not only dictated what CoffeeScript developers could do, it prevented or impaired their ability to integrated with plain JavaScript libraries which made use of “other typed” constructors.

In general, despite this constructor change deep in the framework, QuickUI developers should generally observe no changes in framework behavior.

The QuickUI Catalog has a few small bug fixes, but the version number has been bumped to to keep in sync with the new version number for QuickUI 0.9.4.

QuickUI Catalog released

The QuickUI Catalog has been updated to version This is a modest update in terms of functionality, but a significant milestone for the catalog — it represents the culmination of an effort to port all the Catalog controls to a combination of CoffeeScript and LESS.

The original QuickUI framework included the use of a local build tool called the QuickUI markup compiler. This compiled a markup format that was essentially HTML plus the use of custom tags. (In this, the format was remarkably similar to the spec’ed format for Web Components.) Because this format never got any traction, it was eventually deprecated, although still used for the vast majority of the Catalog controls. 2013 has begun with a major push to port all these controls to CoffeeScript for content and behavior and LESS for appearance.

Now that that port has been accomplished, it will be easier to move the Catalog forward, including the addition of new controls and some refactoring of existing ones. Along with this port, a handful of other controls were added to the Catalog:

  • ToggleButton is a button that can track a selected state. This can be used as is, or as a base class for custom toggle classes.
  • Link wraps a standard HTML <a> tag, and can be used as a base class for custom link classes.
  • TextBox wraps a standard HTML text input element, and can be used as a base class for custom text box classes.

QuickUI 0.9.3 released

This minor release is being made now because it contains a fix for the forthcoming release of jQuery 1.9. Changes:

  • A new Control member called Control.browser replicates the behavior of the now-deprecated jQuery.browser member. jQuery is quite reasonably trying to encourage people to use feature-detection libraries like Modernizr instead of looking directly at the user agent to determine behavior, and jQuery 0.9 is removing support for jQuery.browser. However, in developing the QuickUI Catalog controls, minor bugs have been found time and again in specific browsers to prevent controls from working correctly. These bugs are the sorts of things that will never be detectable with a feature-detection library, and hence checking the browser’s user agent is the only practical way to ensure cross-browser compatibility.

The corresponding release of QuickUI Catalog 0.9.3 includes some minor enhancements:

  • A new TextBoxWithButton control covers the common UI pattern of a text box with an adjacent button (often labeled “Go” or something similar). The existing SearchBox control has been refactored to derive from TextBoxWithButton.
  • A new Log control handles the common need to log text output (e.g., from a background process) to the page.

QuickUI 0.9.2 released

Version 0.9.2 is primarily a bug-fix release. Beyond a variety of minor fixes, there are just a couple of notable changes:

  1. Using $.control( element ) on an existing element to cast the element to the correct subclass of Control now returns null (instead of undefined) if the given element is not a control.
  2. A bug has been fixed which prevented quickui.js from loading in IE8. Thanks to QuickUI user Toussaint for reporting this bug and helping to test the fix!

The release of 0.9.2 coincides with the release of version 0.9.2 of the QuickUI Catalog, which includes the following:

  1. Modes now derives from a new base class called Sequence, a general-purpose class for any linear sequence of elements that can be navigated via a next() and previous() method. Modes now focuses on showing just one element of a Sequence at a time. As part of this change, Modes.activeChild() has been renamed to Modes.activeElement().
  2. SlidingPages has been renamed SlidingPanels (since its contained elements aren’t necessarily pages). The class now also derives from Sequence. Finally, SlidingPanels has been updated to take advantage of CSS transitions on browsers that support them, falling back to a jQuery animation on older browsers.
  3. LateralNavigator has been refactored to handle two general cases: first, navigating through a Sequence of elements, and second navigating through an abstract axis like time. The former case is specifically addressed with a new class called SequenceNavigator. The latter case is used in CalendarMonthNavigator.
  4. An issue that prevented CalendarMonthNavigator from correctly vertically aligning its heading elements has been fixed. CalendarMonthNavigator now also uses a new class, MonthAndYear, to show both the month and year instead of just the month name.
  5. A new VerticalAlign class handles the general problem of vertically aligning child elements in older browsers.
  6. A new Carousel class derives from SequenceNavigator, and uses a SlidingPanels class to provide a sliding transition between elements in the sequence.
  7. The TabSet class has been renamed to Tabs.

This release is also notable as the first one in which Catalog controls have been written (and, some cases, rewritten) in CoffeeScript.

QuickUI 0.9.1 released

QuickUI 0.9.1 contains two changes:

First, it’s now even easier to create web user interface components in CoffeeScript. When CoffeeScript support in QuickUI was first announced a month ago, you had to include a boilerplate constructor. This was required to work around a limitation in CoffeeScript, in which CoffeeScript’s default constructor for a class didn’t return a value. (See a good summary of the issue here.) That issue has now been fixed in CoffeeScript 1.3.3. With a considerable degree of rework in the base Control class, you can now create a new user interface control in a single line of CoffeeScript:

control window.MyButton extends BasicButton

The QuickUI documentation for creating controls in CoffeeScript has been updated to reflect this.

Second, QuickUI 0.9.1 has a simplified model for generic styling. The QuickUI Catalog controls define generic styles that allow them to function without you needing to provide styling for them. You can easily turn off a base class’ generic style by setting the subclass’ generic() property to false.

QuickUI 0.9: a significant update

QuickUI 0.9 has been released. This is a major update which includes a number of changes that make it easier than ever to create reusable, extensible web user interface components.

  • The means by which classes are defined has been substantially simplified, which means that QuickUI is doing a lot less work when a class is defined. One result is that the previous Control.subclass() method has been replaced with a simple jQuery.sub() call. An overload still permits one to pass in a JavaScript object defining the class, but now everything in that object is simply copied over to the new class’ prototype. A new “inherited:” key now holds the Control JSON used to render the control; see the docs for more details.
  • The way you refer to an element within a control’s DOM has changed. Previously, you set an ID on an element in Control JSON using an “id:” key. Under the covers, this set an ID on the HTML element. As of QuickUI 0.9, to refer to an element in code, the Control JSON should include a “ref:” key. (See the tutorial example.) Under the covers, this will set a CSS class on the element. As before, this also implicitly creates an element reference function you can use to get that element through code: e.g., setting ref: “foo” on an element lets you get back to that element with the element reference function $foo().
  • A control’s initialize() method now implicitly invokes the initialize() methods of its base classes. Previously, you had to remember to have initialize() invoke this._super(), which was error prone. Failure to invoke this._super() would often mean that a base class’ event handlers didn’t get wired up, which could lead to bugs which were difficult to track down.
  • CoffeeScript support, announced earlier, has been folded into the core quickui.js runtime.

While the above work was underway, the QuickUI source code was substantially overhauled:

  • The aforementioned support for creating QuickUI controls in CoffeeScript has gone so well that QuickUI’s own runtime has now itself been ported to CoffeeScript. This does not mean that QuickUI developers need to use CoffeeScript; QuickUI supports plain JavaScript development and CoffeeScript development equally well. For people using QuickUI, this simply means that a number of planned improvements to QuickUI (including those listed above) could more easily be tackled.
  • The quickui.js runtime file itself is now built with Ben Alman’s handy Grunt build tool.
  • The optional QuickUI markup compiler has been moved into a separate GitHub repo, quickui-markup.

Please take a look!