Pages

February 11, 2006

Boxely, pt 2

Updated: Corey, who actually works on Boxely at AOL, had a few thoughts about my Boxely ramblings. He speaks from a point of some authority, being one of the people who turned it from science project into core application infrastructure. Not that I agree with all his points (in particular, I think CSS is junk - but I said that already :)), but its worth a read, filling in a number of gaps in my discussion below.

Boxely is the UI toolkit that serves as one of the pillars of the OCP.

The basic execution model is a markup-based/script-behind one - very similar to
XAML or MXML. When I say "script behind", I mean that the code is not inline as it usually is with HTML - its in a separate "code" file. The underlying protocol/data model utilizes a discovery/reflection/dynamic binding model provided by the EE (Execution Environment of the OCP), which I'll discuss in some more depth at a future date.

In this post, I wanted to discuss the UI model we use, briefly, and then discuss some of the benefits and drawbacks. Understand, by way of context, there were two goals for Boxely: (1) Make it faster for AOL and partners to iteratively build, maintain, and integrate features with AOL desktop applications, and (2) Enable richer, more modern, user interface experiences.

I'm not going to delve too deeply into Boxely samples or markup - this isn't going to be a how-to-use Boxely primer. At some point (soon-ish), I hope to just make the Boxely documentation and samples available online.

Unsurprisingly (given its name), everything in Boxely is based on the idea of a "
box" - more or less the very same w3c box element that formalized and codified the grammars of HTML/XHTML layout elements for browsers. And it follows directly that Boxely's layout model is primarily a flex/flow model, much like HTML/XUL/XAML/MXML, etc.

It was an intentional design goal to try and keep the Boxely language as syntactically and grammatically consistent with w3c standards as much as we could, except where(a) standards were non-existent and/or underspecified (extensions), or (b) where strictly adhering to the model caused unnecessary complexity in the authoring process (revisions).

We tried to keep most things, early on, in the "a" category, leveraging CSS, namespaces, etc., where appropriate, with only a few things in the "b" category. Obviously, we extended the range of the addressable element space to include desktop concepts like windows, taskbar entries, icons, etc. We addded a "nine-grid" image brush style to make stretchable UI bits easier, and it is possible, in Boxely, to explicity change the z-order and/or the flow-order of a box independent of its location in the DOM.

Now, if you're not too familiar with (at least)
HTML - and by that I mean you haven't built anything at any scale - you're probably going to be a little lost on the values driving some of our design choices.

In any case, the primary nuanced evolution in the second/third generation of mark-up languages beyond HTML is of self construction. There are a few very basic box types (fill, text, image, etc.) that can be combined and nested (i.e. boxes within boxes) with some basic layouts and behaviours to make all kinds of applications and content - this is one of the basic principles of HTML to begin with. Where Boxely (et al.) go further is that they then allow you to formally construct new markup elements out of some attributable collection of markup elements - essentially markup "functions" - that you can then reuse as first class markup tags within your UI source files.

And, of course, these can be nested - you can combine these gadgets, as we call them in Boxely, to make even more complicated gadgets. It is a pain to do that well (quality, speed, flexbility, and maintainability) in something like HTML.

Initially, we had this idea that the "class library" gadgets in Boxely (the ones we provided for all common UI elements) would have their own internal spacing rules to make layour easier. So, for example, a button gadget (that you might have constructed out of a text box inside a fill box - with a rounded corner, naturally) might have a padding of 3 pixels on either side. That way, it is always consistently spaced from other elements and gadgets you place around it.

Seems like the right way to go, but this was a surprisingly wrong-headed idea.

It turns out that in real word applications, the spacing between elements is more likely a function of the container than the element. And so, we added "hspace" and "vspace" parameters to our layout that you can specify on the container box that specifies how far apart its children are.

Most of the details of the differences aren't that critical for my point, and I hilited that one only to say this: there's a gap between the requirements of commercial applications (especially on the desktop) and content (in the technology sense) and most of our choices were about closing gaps between theory and execution. Basically, we weighed creating an "exception" against "does it make performance or authoring creation/maintenance significantly easier?"

So, some things I like about Boxely:
- Syntactic and grammatic familiarity of markup and script (XUL-ish and Javascript, respectively). We've brought up a number of teams very quickly, both internally and externally.
- Performance: its smaller, faster, and more flexible than Flash/MXL or XAML.
- Differentiation: we're able to create uniquely AOL applications. More on the good v. bad of that in the future - but I'll state that for our (AOL) purposes it's a big plus.
- Separable, layered development: That self construction I was talking about makes it MUCH easier for our applicaitons teams, designers, and product people to spend time worrying about the right set of problems. Now, they don't always LIKE that we can seggregate our development this way, but that's a different issue...


Some things I don't:
- Performance: a box is 144 bytes (it was a LOT bigger when we first started - so its improving), and we make a lot of boxes; and though Boxely is faster than the comparables, its still quite a bit slower than straight Win32 applications.
- Javascript: Some major dichotomies here - its a powerful but extraordinarily goofy language that everyone only thinks they understand. I'll delve into this in some depth in the future, but suffice it to say that its ease of use (but lack of GOOD scalability) is exactly the problem. Too much of our applications are built in script because it was easy (not too be confused with right) to do so. The nice thing about the
OCP (the EE really) is that it lets us easily choose how we implement services and applications (its basically language agnostic) - but too much ended up in script. Some of this is not Javascript's fault per se - its just that the tradespace of scripting languages is quite different from that of compiled code, and not always readily understood - an opacity problem. As I said, more on this soon - its too big to tackle here.
- Layout: Flow and flex I like for some special cases, but they're really not a great fit, in my view, for most real world applications. I think this lately pervasive thinking is directly a "If you only have a hammer, everything's a nail" outgrowth from HTML's impact on the world of front-end application development.
- CSS: I think its pure crap. In my view, its an ivory tower computer science solution for style specification that's been inflicted on the world in the name of "standardization". Its complicated, NOT very powerful (why can't I address attributes?), and forces awful
implementation tradeoffs.

Most of the minuses I don't think are fatal in anyway, over time (because we make them better or because they become less significant), but they did provide a newly discovered set of challenges in getting our
first generation of applications shipped.

OK, next I'll dive into scripting and languages more directly, probably expanding this discussion into a look at the EE itself.

4 comments:

Anonymous said...

Sree,
I have to agree. It seems as if Boxley was an excellent idea to start off with however complications seem to have kept you guys in JS and tons of it. It is nice to see something universally adaptable as well. Being able to transition from XHTML and XUL and XML over to the boxley format is simple to do, it seems also to back closely with XAML which is just now getting in the field due to Expressions Designer from Microsoft.

I think personally while on newer computers the benefits of the "chain reaction" launch sequence with boxley are apparent they are still slower than regular Win32 apps. However as you stated as code is boiled down then the speed should start being evident.

On a side note...I love reading your blog. It's beautiful to see a SVP (Besides Calacanis) stepping out and blogging and blogging so technically just helps in increasing the transparentness of AOLT giving others the ability to gather a nice base to invest their ideas. Again, thank you.

Sree Kotay said...

Hi Shawn,
Thanks for the kind words on the blog - feedback is always nice :)

In terms of the chain reaction at launch - yes, its a bit goofy. There's one core thing we need to fix (which I didn't even mention because I consider it so basic; we just ran out of time for it round 1) - which is support for an archive/package format rather than "loose" files.

Beyond that, the performance launch adjustments will be more at the higher levels (in our layered development model) - which is where they belong (Suite Framework, Authentication Gadget, etc.)

Twinsen said...

So as not to pollute your comment real-estate with a verbose rant - I've provided an alternate take here.

And hopefully this thread won't degrade to discussions of penis enlargment and luxury lifestyles like the other thread you referred us to. ;o)

Charmingirl said...

Wholesale lingerie directly from China?
As a famous brand and specialized manufacturer of sexy clothing in China. Charmingirl supply the international market with fashionable sexy lingerie and sexy costume since 2002. With advanced technology,all our products are of high quality. Now we have clients all around the world. Lingerie Wholesale and OEM are welcomed!
As a Lingerie Manufacturer, Charmingirl has standard workshop and production line, professional designers and experienced workers.
We do Wholesale Underwear,
Lingerie Wholesale, including corset and bustier,
Sexy Lingerie Wholesale, including bikini, underwear
Lingerie Wholesale, and Babydolls, Sexy Lingerie Wholesale, and
Sexy Lingerie Wholesale including sleepwear,clubwear.
Lingerie Wholesale from China: Lingerie China, you will find the
Leather Lingerie and PVC Lingerie, also you can buy
Christmas Costume and Xmas Lingerie
for your Christmas Lingerie Christmas day.
Our Wholesale center: Sexy Lingerie Wholesale can do Lingerie Wholesale online.
Halloween Costume,
also wholesale Adult Costume with fashion Babydoll Babydoll, and bra and panties Bra and Panties, Sexy Uniform Sexy Uniform is also our major products.