Boxely, pt 1

Updated: Read Part 2.

Boxely is the custom user interface toolkit that underlies pretty much all of the current and upcoming desktop applications at AOL, including the AOL Suite, AIM Triton, AOL Explorer, AOL Safety&Security Center, among many others.

Its one of the pillars of the OCP.

Inside AOL, we also use the term to refer to our revamped style guide - which attempts to unify the look and feel of our desktop applications, web applications, and programming. For the most part, the idea is to make them feel like they're part of the same family, but to preserve the grammars of interaction that are appropriate for each context.

When I refer to Boxely, in this blog at least, I mean the desktop UI toolkit: markup, runtime, and gadget set. Now, before I dive into Boxely itself, I wanted to take a moment and talk about goals, with a little bit of history (for context) - which for me begins at the very start of 2004, shortly after I started.

I had a number of specific things I wanted to accomplish with UI, at a product level and an engineering level. First and foremost, as I've mentioned before, consumer applications are entirely about their UI. So I wanted to make it easier for us to develop desktop applications as well as enable us to build richer desktop applications. I think we've done well against those goals, though unfortunately, I'd view "rich" still as more potential than reality in terms of execution (i.e. Boxely enables us to do better things than we have so far done in our applications).

The good, and obvious, thing is that I wasn't alone in my thinking. We went through an evaluation period early here, looking pretty hard at XAML, XUL, MXML, and other mark-up driven syntaxes (go to wikipedia for more info). We also looked at other alternatives, including extending FDO and more classically Win32 oriented UI toolkits like wxWidgets.

Boxely was one of the contenders. It was a homegrown UI toolkit, which started life in a sanctioned innovation program (now defunct) called ZOOM - it was intended as a sort of son-of-XUL (as are XAML and MXML). From there, it had been adopted as the underlying UI toolkit for a web authoring product (which also never saw the light of day).

(Minor aside - I've been on mini-crusade to either ship or kill projects that have been going on longer than I've been at AOL - 2 years now. I'm still not done. )

In any case, ultimately, Boxely won because:
(a) it was intended as a desktop UI toolkit, and so it enabled the appropriate grammars of interaction you expect from applications, as opposed to websites, or other.
(b) functionally, it was ahead of XAML, MXML, or XUL in enough of the critical axes: performance, richness, and runtime
(c) we had the source code - by that I mean the people, not the code :)
This also meant we had more control over its destiny.
(d) it allowed self-construction: building XML primitives out of other underlying primitives.
This is more or less the core of the whole set of next generation UI toolkits (post HTML, as it were) - I had this notion that people using Boxely would not need the documentation to Boxely itself; they'd just need the documentation to the "gadget" toolkit that was constructed out of Boxely for applications. For example, they wouldn't have to make an image tag and then add handlers for clicking to make it a button - they'd just type aolbutton, which would have been defined in an imported library. This was very important to me and one of the reasons that I was primarily focused on next-gen XML mark-up runtimes - I wanted to be able to layer our development to help us better leverage the scale of AOL. I also felt this layering would enable us to better support third party integrations.

To be fair, had we been able to complete the deal with Macromedia I attempted to engineer, things might have gone differently. So to those thinking NIH drove Boxely, I can say, "A little, but not really". Circumstance and serendipity, though, certainly did.

Next, I'll explore a bit more by discussing about the things I don't like about Boxely.