February 28, 2006

Content engineering

You know what's nice about the Internet, as an end user?

You don't have to install the Web.
You don't have to upgrade a webpage.
You don't have to download a whole website before you can begin perusing it.

Some nice examples of actual applications as content:
http://www.gapminder.org/ (Flash)
http://babynamewizard.com/namevoyager/lnv0105.html (Java)
http://www.dhteumeuleu.com/ (DHTML)**

These are a little data-viz centric, I realize, but hilights (for me) the difference between the old world of content and the new (hint: Its participatory :P)

**OK, this one's just demo-ware, but it shows that just DHTML fun can be had.
To use it, click a category, then select a demo in the list below that, and then click ON the demo picture itself to activate it.

February 26, 2006

Javascript Applications, pt 1

Updated: Continued in Part 2.

Languages (and language studies) are an interesting phenomenon. As we know from anthropology (and middle school social studies), Eskimoes have 20 different words for various kinds of "snow", whereas we have just the one: "snow".

Now, it turns out this is just one more in a long line of urban myths that we've repeated into "truthiness" - and that's also interesting (but a whole 'nother discussion).

We look at language as deeply revealing reflections of underlying culture and structure. And while I don't deny the power that language has and the values that it can imply, I don't believe that it fundamentally enables new capabilities for a society. Is there a language that lacks poetry? Or laws? Or stories? Or religion? And I'm not sure a particular language, in and of itself, has any particular evolutionary advantage - though clearly a particular language's economy of communication is likely a reflection of a culture's evolutionary challenges.

For computer languages, this seems even more apparent. I mean, its pretty much the same CPU underneath, so the language is just a question of vanity and preference, no? It really doesn't matter what language you use, so long as you use it well?

Turns out, not so much
.

Although I think there is a fundamental provability to the notion that good programming is language invariant, the grammar and semantics of a particular language can be measured along a number of axes:


My point here is that language features are not about CAPABILITY: you can (literally) do MORE in Assembly than any other language (although, you know what they say: you can't spell "Assembly" without "Ass"). But languages developed - some evolved, some were designed (intelligently and otherwise) - because there was a need to enable significantly greater complexity and abstraction on top of vastly increasing linear computing power.

Bottom Line? The abstractions various languages provide ultimately matter because they enable significant flexibility, at the cost of some performance. Its all just a question of the value of the tradeoffs.

Pretty long way to go to say that I think while Javascript is great, it also sucks.

I'll explore what features have been valuable and where we've suffered using it to build
desktop applications in my next posts on this topic - along with some specific recommendations (for developers USING Javascript, as well as suggestions for the language itself).

As I've
mentioned before, I think we're among the bold few attempting to use Javascript for Programming in the Large for desktop applications, at scale. Though AJAX is all the rage (*cough* DHTML), the discussions tend to center around "Bitless applications" - stuff in the browser.

A lot of the problems are essentially of the same type (but exaggerated for desktop apps), so I think most of the discussion applies to both, but, obviously, there are some interesting differences as well.

February 24, 2006

Credit where credit's due

This is a follow-up to my previous post.

I think a lot of us at the bigger software companies are here for more or less the same reason: the opportunity to impact hundreds of thousands, if not millions, if not tens of millions (and more) users. It feels great to feel like your work matters - and to be
recognized for that.

Heck, for that matter, I think many folks at smaller tech companies feel the same way (though there, its often more about potential than realization).

That impact might even be life changing; or inspirational; or there might be unintended happy consequences: you connect people, enable them, and/or empower life defining moments. At enough scale, you can start do all of those things, and it can be rewarding.

But there's a big difference between doing good, either as a side effect or with ancillary (financial or corporate) benefits, and intending to do good, for its own sake. There's a difference of will that I think is morally significant.

So in that spirit, I have to say: I'm proud to be a part of an industry that is starting to
actively accept the social authority and responsibility that comes with great power: to intend good. I try in little ways - and we do a LOT of community and charity outreach at AOL, but I am humbled by the ambition of vision I see and the opportunity for impact it implies.

(BTW, if you don't know the man they appointed to run
google.org, Larry Brilliant- I didn't - pretty seriously cool.)

February 22, 2006

About... credits

Updated: David Besbris makes a point that is more or less at the heart of why I think this matters: Software is a players' game.

I was recently reminded: one of the nice minor things I feel quite proud of helping accomplish during my tenure here is the (re)instatement of credits in our "About..." boxes at AOL for our desktop applications.

Most of the things that that my group has done has really been my group: I might have helped make the room, but others better than I filled the space. And the ideas and desire had been here long before I started.


This one was I feel I contributed to more directly, though :)

Its important that the people building the software feel connected to it, and pride of ownership is a key part of that. I'm even more pleased that software engineering come first in that list - that's on purpose.

Other folks, like Product teams, Business owners, Marketing, etc. have other outlets for this pride of ownership - whether its because of press interviews, org structures, or simply because they're the ones delivering the updates and plans in executive reviews and public forums inside and outside the company.

But programmers? We make the product.

I realize its very, very trite, but its also very, very true: The intellectual capital at software companies is in the people, not the code.


Not like a big initiative or anything, but I'd like to find some way to do this for "bitless" applications (online only) in a "standarized" way as well - its not about being splashy or territorial, just giving credit where its due.

February 21, 2006

Present in the Industry

My woman - that is, my wife, who it turns out DOES read my blog, and would henceforth liked to be referred to as "my woman" (she finds "my wife" to be too 1950's) - anyway, "my woman" has been known to give me a fair amount of grief for not being "Present". She says I'm often thinking about other things when I'm supposed to spending quality family time with, well, my family. So I've really been working on being "Present" (though working on this post might be considered evidence to the contrary :)).

In a similar way, one of my specific goals here at AOL is to help us be more "Present in the Industry". It bugs me a little (read: a LOT) that when people talk and think about Internet companies and the behaviour transformations driven by technology, AOL often doesn't even make the top 10 (Google, Yahoo, Amazon, E-Bay, Microsoft, Apple, Skype, MySpace ... yada yada yada). Or the articles tend to be stand-alone "What ever happened to...?" style COMPANY articles - they're not enough about our products, technologies, and services in a real competitve business context (side-by-side reviews, recommendations, etc.) , i.e. the relevance of our efforts in the industry.

Now (historically), that's not THEIR fault, its ours.

The
good news is I think this is changing. We're STARTING to show up on the same page with other relevant, competitive Internet technologies (which means we're STARTING to matter again), in small ways, though its still with some surprise ("Maybe its a fluke?", they think; "If only it didn't say 'AOL'", they write).

We've had a lot of internal
reformation and disentanglement that we needed to achieve here over the last year/year-and-a-half - both technically and organizationally. And though we are FAR from done, I think we're indeed over the hump - these emerging AOL technology and employee blogs are but one, small, visible sign of this.

Our progress in this regard, I expect, is going to be accelerating much more visibly, in some
substantial ways, over the course of the next year. As these things become more public, I'll be expanding my discussion here to cover our increasing efforts across our whole technology base to be MUCH more present and transparent, "in sych" if you will (sorry - inside joke :)), with the Internet community at large - with products, services, and, yes, technology.

If AOL is going to become relevant again, if we're going to be "Present in the Industry", we're going to have to erase the boundaries between AOL and the Internet, and between AOL and your computer . We need to become an increasing part in the clickstream and thoughtstream of an increasingly connected world - in the browser, WITH the browser, and beyond the browser.


And I believe that this is as much a cultural transformation for us as it is a technological one.

Our karmic niche is pretty simple (no, not
this one, wiseguy. :P): We democratize the Internet - making powerful things accessible. Too often, especially during the heady boom/merger days, I think we realize AOL took the "So easy to use no wonder its #1" mantra a little too literally. Understood the wrong way, it can became about being "dumbed down" instead of "empowered".

February 19, 2006

Legal Security: OCP and Apple's Intel Macs

John Robinson continues to expand his discussions on the runtime layer underlying our new desktop software architecture, the OCP. His post is here, with some background discussion here.

There's some novel concepts around services and process groups John
covers, and a few unique details he skims over without real comment, but I wanted to point out one specific, um... interesting thing he mentions only in passing - the OCP Haiku that you (developer-"you", not end-user-"you") must submit (in code) before you can activate and consume services:

Writing Code
The Dawn Sun Breaks
I am at Peace

-
The OCP “Haiku”© AOL 2003-2006

Almost exactly like the
poem that Apple embedded in the software/hardware interface of OS X for their Intel Macs, this isn't a cute wink to hackers or a nudge to anyone's conscience: its actually a platform "security" feature. The idea is not to prevent hackers, per se, but to try and cloak one's technology with as many legal protections as possible to prevent "white hats" from absconding with your IP without recourse. In the OCP design, we attempt to engender the protection of patent, contract, DMCA and copyright law - our Haiku being about the latter two, in particular, of course.

An original poem is the smallest legal copyrightable work - or I should, a poem is a copyrightable work, of which a Haiku is the shortest legally recognized form (or so I'm told). Incidentally,
John was the author of our OCP Haiku - we held an internal contest amongst our client developers, and his was selected as most poetic.

It will be interesting to see how this
turns out for Apple - as far as I know, these types of protections have been in the theoretical category (legally speaking), though they've been extended and applied in the real world in a number of novel ways (including ours) for a few years now.

February 18, 2006

Small Block Allocator Challenge!

I recieved quite a few requests about the mini-coding contest (here, but scroll about half way down to the "Who's your Daddy?" section) that I mentioned.

To refresh your memory, the idea was to write a memory allocator that could substantially outperform the Microsoft CRT (and Windows OS) for small block allocations - inspired by some
problems we had. You can read the rules or download the source to the benchmark.

Although I'm not releasing the code to my winning entry (just yet), I did include executables for both the winner (me :)) and for malloc()/free() compiled against the benchmark - they're in the source package referenced above.

The benchmark is NOT normalized for CPU/machine speed, so you should only compare your score to the winning executable (SREE_memtest.exe) run on your machine to see how you're doing. The benchmark will run twice when you launch it - the first run generates your actual "Score"; the second run is only to test validity.

Additionally, there is an "OS score" that it generates - this uses the same "total time" as the regular (official) score, but gets its efficiency measures from the OS rather than relying on you to call blockalloc()/blockfree(). We used that both to validate memory usage - and to compare to
SmartHeap, which of course, does NOT strictly follow all the rules, but whatever :P

Be warned that you'll need a tiny bit of patience (the test performs well over 1000000 allocations) and a decent amount of RAM (it allocates over a half a gig) if you're going to run the benchmark(s).

Read More or Download it

It is absolutely possible to beat the winner- we spent a week (after hours) on the problem in isolation (i.e. to each, his own); it was clear after we compared notes at the end that there were lots of things that we each did that would hugely benefit the others' attempts.

February 17, 2006

Twiddling the FPU

I wrote an article for a website a friend of mine keeps. I'll warn you now: its preeeeettttyyy geeky. It had been sitting in a state of partial completion for years, but I've been in a lot of meetings lately, and so I finally got a chance to finish it :P

Its definitely in the
"See how smart I am/educational" category, and not a commercially material type of thing, but, still, I think there are some nice tips there.

Embarassingly - in the course of writing the article - I discovered a long standing bug (*cough* - my bug) that I'd been blaming on the
Boxely team. You can see the bug in action pretty easily in AIM Triton 1.0, AOL Explorer 1.2, AOL Safety and Security Center, and the AOL Suite Preview.

What's the bug you say?

RTFA.

And sadly, you have to get all the way to the bottom to see what it is. See? Even us Programmers can learn from Programmers :)

February 16, 2006

My $0.56 on Blog updates

If you update your blog less than once a month, it's not a blog: that's called a "webpage".

Now, if you update it once very two weeks or so, I'd still call it a blog - albeit a slow one (a "slog"? :)). Update at least once a week, on average, and I think you get full marks.

I have to admit, I'm a little surprised with my blog: it's been easier than I expected to update it regularly.

I've been doing it for a few weeks now - its a real
commitment. We'll see how long that lasts, but so far its been fun. And Google's Adsense dashboard tells me that the traffic (and click thrus) to my site are worth $0.56. That's some cra-za-zee chedda', yo!

I started to blog because... well, its 2006 and I'm "in the biz", as it were, but its turned out to be a nice place to put all those thoughts that don't really fit anywhere.

February 15, 2006

Yahoo's YUI Goodness

A few days ago, Yahoo released some source code and guidelines for user interface construction and design for the Web. Called YUI (Yahoo UI), its a robust but basic set of cross-platform cross-browser script samples, code libraries for AJAX-y style web applications.

I'm not quite sure what to make of it.

YUI is (at first glance) robust, clean, well thought through - its not perfect or stunning or anything, but it is, most surprisingly, commercially material. Most of the intellectual property that companies tend to release as "open" fall into either the "Look how smart we are/educational" camp - and so are valuable but not usually in a quantifiable commercial way - or into the "Its free [in any and/or all senses], but it furthers our strategic ambitions". Google's really good at the latter, for example - its not that their stuff is not good for developers, its just that its usually (read: almost always) also good for Google.

But that
doesn't appear to be the case with YUI. Its genuinely valuable to developers - educationally, and because it will save man-months and years, and also because it will more easily enable and advance the development of enhanced features and experiences. But I can't really see how it helps Yahoo, even strategically, except in that "Oh, aren't they super-nice?" kind of way.

And I'm torn.

As a consumer and a developer, I'm (more or less) ecstatic. Its basically free money (go
download it now!)- whoo hoo!

As a businessman and coroporate officer (in the broad sense - I'm actually pretty far down in the food chain :)), I have to admit it strikes me as a little irresponsible. Its basically free money - what are they thinking?

OK, I'll admit that I'm not that torn: good job, Yahoo!


They've also released, as I mentioned, what they're calling their Design Patterns Library - a set of UI guidelines for the Web-at-large. I think this is VERY good for end users, but (cynically), I feel that standardization of experience favors the incumbents.

February 14, 2006

Firefox v. IE: an AOL View, pt 1

I expect that this is generally understood, but with this post its worth noting that the views expressed here are only my own, and not necessarily those held officially by my employer, AOL.

Updated: Part 2 is available.

I've been asked repeatedly and pointedly (inside and outside of AOL), "Why did you guys build a browser that is based on Internet Explorer?" The implicit question, of course, is "Don't you know that IE droolz and Firefox roolz?"

No. No, I don't know that.

Let me state a few caveats, and then explain why I think Internet Explorer continues to be a substantially better choice for AOL's desktop software on Windows.

First, I think Firefox is a good browser. It does a nice job of being compatible enough in enough of the right ways, performs well enough, and offers a number of nice experience improvements to the browser. And, as a developer, I like that I have access to the source code.

Second, I think it is good for the industry at large to have more than one browser "out there". I think Apple was actually the first to raise the issue again with Safari - in terms of re-igniting the multi-browser flames, especially because of the disproportionate number of designers and web developers on the Mac - but certainly the Mozilla Foundation broadened and deepened the opportunity to being about more than just supporting an "edge" platform. As a concrete example of that value: Do you really think that
Internet Explorer 7 would exist in its promised incarnation and be as broadly available if not for Firefox?

Third, its nice to see the original dot com browser make a comeback - and there's a certain underdog element to the whole open source non-profit foundation vs. Evil Empire thing ("Help me, Obi-wan, your're my only hope"). Lest we over-romanticize, however, we should remember that although Microsoft was very likely
underhanded and monopolistic during the "browser wars" of the late 90's, I don't believe that was the deciding factor in their success with IE. The simple truth? Internet Explorer crushed Netspace Navigator because Microsoft delivered a genuinely better browser. And now, its payback time :)

As advocates of Firefox point out (correctly):

  • Firefox is safer/more secure
  • Firefox provides a better experience/is more powerful
  • Firefox is more standards compliant
  • Firefox is cooler

So now that the pleasantries are out of the way: Be prepared, Firefox Fans - next time, I'm bringin' the heat...

February 13, 2006

Execution Environment,
plus Who's your Daddy?

Following my posts on Boxely (pt 1 and pt 2) and the OCP, I had planned to talk about the EE (Execution Engine) in some detail. But John Robinson (aka JR), who's been the Chief Architect and (with Dave Besbris) one of the prime drivers of the OCP, beat me to it.

He jumps right to features and benefits, and so is more succinct than I would have been. Its a
good read. Plus, it saves me the trouble :)

A few comments:

  • The EE (as the underlying engine of the OCP) is about supporting a more scalable, abstracted runtime environment. For example, a lot of design time went into versioning and deployment considerations, and a lot of thought went in to figuring out how to minimize service APIs.
    There's a big difference between object-oriented or component development and the services model we're advocating in the OCP (which isn't necessarily fully reflected in all of our first generation services).
  • Although the EE provides native platform interop, we specifically limited how MUCH of the interop we exposed (feature wise) for two reasons: (1) to insure greater portabililty and less reliance on the underlying infrastructure (by portability, I even mean things like: we don't support any design patterns that only make sense in compiled lanuages vs. interpreted ones like Javascript), and (2) even more, to limit the number of design patterns we used in the construction/consumption of our services to make our APIs more consistent and learnable.
    A rationale platform is more than just a collection of services.
  • One of the core guiding priniciples of the OCP is data driven design: factoring policy OUT of code - turning technology limitations into business and product choices, as they should be.

Who's your Daddy?
Completely unrelated to the EE, but if you read further down on JR's blog, you'll see that
he discusses a coding contest some of us former hard-core coders had here at AOL a few weeks ago - as John notes, it wasn't anything official, just an informal challenge a small group of us conducted for one week (after hours, of course :)).

The challenge was to write a fast, efficient memory allocator for small blocks (1024 bytes or less), as compared to the Microsoft C common runtime (MSVCRT) and SmartHeap. We used both a custom test and the smart heap benchmark for comparison.

John goes into some more details in his post - I just wanted to point out that I was the winner :)

I'll post the code and benchmark harness at some point in the near future, but the scores (per the system JR mentions on his blog) were as follows:

Lower is better (names changed to protect the innocent):

  1. Sree Kotay 13584.3
  2. Bave Desbris 15652.2
  3. Rohn Jobinson 16378.4
  4. Mat Peenan 16709.2
  5. Microsoft CRT 52516.8
  6. Park Moesch [no show]
  7. Cave Dorboy [no show]

Justin Uberti kindly judged for us.

We couldn't benchmark smartheap entirely accurately (because it doesn't call our base allocator for memory efficiency measurement), but using the amount reported by the OS as a proxy, well, suffice it to say that it came out in middle of the pack, in both speed and efficiency.

So, in summation: NYAH NYAH NYAH hahah!!!! :P

February 12, 2006

Recursive Blogging

OK, two thoughts from other blogs about my blog - specifically, my post on Google's CEO, Eric Schmidt, visiting us.

One, from
Inside Google, makes an important point that I don't want to lose:

The software we build at AOL is for people, in the broadest sense. Its why I'm here and therein lies both opportunity and challenge for us (royal AOL "us").

That theme, of people-centric computing, I believe is the key to recovering our karmic niche in the online world. It feels like we lose our way when our strategies and goals become too inward facing (audience, revenue, OIBIDA, etc.) and abstract; its very easy for that to happen in a big, still hugely profitable company. And we have lost it in the past - I hope to keep it in the past :P - lost it even more maybe, whenever we've imagined those people are other(i.e. lesser), and our software condescends rather than empowers.

(As always, IMHO)

So here's my thought: If we, as developers of that software (and I mean that again in the broadest sense), don't place ourselves in the set of users for whom we're building that software, I don't think it will ever be GREAT. I'm not saying we need to be in the bullseye, but we need to be in a part of the target audience. I think we've made
a good start in the last two years in changing that, but its only a start.

And I'm hopeful.

Two,
Dossy, who also works at AOL, makes a COMPLETELY fair point about taking quotes out of context. Having been at the event in question, I have to say I didn't realize how it might read until he pointed this out on HIS blog, and certainly I was not intending to imply that Eric was comparing apples to apples (i.e. our coders to his coders). I amended my post to hopefully clarify. Indeed the point was that "Programming" at AOL is about content, whereas "Programming" at Google is about code - language has power, and yes, it implies values.

Speaking of which - daaaaaamn, Dossy - that's a BIG friggin' ad on your blog :P

As
Nathan pointed out in his post about my post, that this new post is attempting to clarify - oop - [...stack overflow....]

My blog has moved: http://sree.kotay.com

Repeat. (and Welcome!)

My blog has moved: http://sree.kotay.com

You won't see updates there (graphicallspeaking.blogspot.com) any longer. I wasn't sure if I'd actually update my blog with any regularity, so wasn't really wanting to bother with it - but turns out I do. And so:

My blog has moved: http://sree.kotay.com

Thanks. See you there. (er... here).

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.

February 8, 2006

Increasingly Connected Computing

Every now and again I try to push a phrase into the common vernacular. Like the phrase, "Not so much." - I claim I invented and popularized it in the late 90's.

OK, maybe not so much.

I have quite a few new pithy phrases I've been known to whip out over the last few years, but none has really caught on yet. For example (remembering that I told you in advance this would be an "industry" blog):

  • "Its not rocket science - its barely computer science!"
    (c'mon - that's a good one!)
  • "Your vote doesn't count, but your voice does.", or its variant:
  • "It's not a democracy."
  • "The intellectual capital at software companies is in its people, not its code."
    (trite, I know - but that one's true)
  • "He who last laughs laughs last laughs laughs last... laughs laughs... uh ... last."
  • "We need a little rizzle-dizzle, yo!"
  • "What you call 'fertilizing', I call 'dropping turds'."
  • "Your PRD [product requirements doc] is NOT your architecture diagram."
    (oooh - burn!)
  • "Buzzword compliance does not a [Platform/Product/etc] make."
  • "The best way to predict the future is to invent it"
    (oh wait, I only
    wish I said that...)
As you can plainly see, its just crazy that one of these gems has not yet fully memed out into the public zeitgeist. In the same vein, my wife has one she's been trying to get out there for years:

  • "You gotta love the blues."

I don't know what it means, exactly, but I like the sound of it, and use it at every reasonable opportunity for some cheap brownie points.

For example, right now.

(I'm also trying to see if she actually reads my blog; she claims she does.)

In any case, a new one I've been trying out in a number of places for the last two months or so is "Increasingly Connected Computing" .


Its a direct play on a concept from Intel (at least, that's where I first heard it) that they call
Occassionally Connected Computing - which is about how wireless is cool, but kinda flaky (this was when the Centrino was first coming out). Wide Area WiFi (WaWiFi? yoinks!) is more or less in the same boat, conceptually - not to mention the rise of portable computing generally - and, therefore, you really need to build more resilience into your data models.

My notion of "Increasingly Connected Computing" is both social and technological, and related to the Intel phrase in the idea that our data model has to evolve significantly to solve for the disruptive experiences that will emerge in the near future.

I think that as barriers to communication and data proliferation lower, because of ubiquitous and fat and unwired connectivity pipes, because of the preponderance of connected computing devices (PCs, laptops, phones, PDA's, remote controls, PSPs, Consoles, pens, etc., and the rise of cheap storage, there will be broad new opportunities to enable a wide class of new behaviours, consumer and otherwise - though I think the PC will continue to be a task oriented hub (as opposed to more social activities which be increasinly untethered).

That's not a big new prognisticative thought - "convergence" has been a buzzword for HOW long now?

But at the core of that, I think the underlying data model will be synchronization based. No more IMAP, or HTTP, or NFS, or ... you get the idea. Just transparent, secure, generic data access. And by this I don't mean
Network Computing or Web/Host based storage. Those might be underlying enablers, but the really interesting user experience stuff will be at the edges - in those "Occassionaly Connected Computing" devices...

This is clearly the space in which peer-to-peer, tagging, bluetooth,
swarming, edge-serving, etc. live. I think there are also some interesting social behaviours that we'll see in an increasingly connected computing environment (look! I even used it in a sentence!) - for example, I think we'll see far more transience in terms of community and group spaces and communities. The number of abandoned blogs, and stranded homepages and e-groups presages that (all that work right down the drain)...

But as I said, I don't think I'm tossing out any particularly new thoughts here....

...I'm just naming it :)

February 7, 2006

Programming

Eric Schmidt from Google was just here (last week) speaking at our Corporate All Hands. It was pretty nice, though I have to admit to being a tad disappointed we didn't get Sergey Brin or Larry Page. Mostly, the meeting was some deserved back patting on both sides for the recently completed deal. Clearly, I have LOTS of thoughts on the details, of the deal and the meeting both, but not much I'm really in a position to share :)

Anyhoo, an interesting question came up, which speaks a LOT to the philosophies dividing the old world from the new (remember "Content is King", anyone?). I don't remember, verbatim, the question, but the gist of it was, "At AOL, we tend to have [Content] Programmers that offer our members a very managed experience that comforts them, whereas at Google, its much more automation and technology oriented - can you comment on this philosophy difference?"

And Eric replied, "When you say Programmer and we say Programmer, we mean very different things... Does that answer the question?"

Yes.

Yes it does.

(And here I thought we didn't get one of the "good" ones - sorry, Eric :))

On which side of the divide do you think Google would place AOL?

One interesting comment he made: "We don't view you as competitors."

I have to say, it's pretty embarassing when you enter the battle arena thinking you're facing a worthy adversary - an equal - and he thinks you're there to clean his sword and groom his horse... ya-ouCH.

February 6, 2006

Firefox Historical Perspective

I came across a pretty interesting read:
http://weblogs.mozillazine.org/ben/archives/009698.html
(credit where its due: saw it on slashdot :))

It speaks a lot to how transformation and desperation are not good bed-fellows (at least, that's what I took away). It reads as a little romanticized - and one sided - but hard to argue with a happy ending, and there are definitely lessons to be learned there.

And it even has a fun easter egg (if you ever worked at AOL, at least). Scroll down the page and click on the "bloodbath" link... its about 40% down the page...

February 4, 2006

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.