dispatchEvent

Blood, Sweat, Tears, but Mostly Cupcakes

By Roger Braunstein | on September 6, 2007
In AS3, Authors, Flash, Schematicers, Site-seeing |

These are some of the things that went into the making of the new schematic.com site, which has finally been released in public beta. Yeah, yeah, you found a bug, I suck, you’ve never been so offended in your life, what a waste of time, I get it. Go file a report. I won’t accept comments on bugs here.

Anyway, I worked on this site for about the last six months of my tenure at Schematic. It’s all AS3, with no Flex. I took the designs and features that had been built up over the last year, during which the company had aborted several attempts to build the vastly ambitious site, and assembled a schedule, tasks, a feasible set of functionality, a general approach, a process to follow, and an architecture, and then set to work. I was joined in my development by two great developers, Michael Avila and Jeff Yamada, who saw the site through to the end, and who made it possible for me to take time to write the AS3 bible while working on the site. But before I get into thanking everyone…

There’s some fun stuff going on inside and outside of the site. First off, it’s completely CMS driven. There’s something like 30 templates we built, using quite a few elements. In the CMS, you just pick out a template, fill it up with your images, text, backgrounds, video, animations, feeds, and links. Then you can take that page and stack it up with other pages, or drag it anywhere on the grid. Call me a hypocrite, but I think the number one best feature of the site is that there’s a fully functional, fully accessible HTML site behind it with almost 100% content parity. The HTML site works great on phones, it looks fantastic thanks to genius Patrick Phegley and it’s super spiderable. Now, when spiders pick up links to these deep HTML pages, there’s javascript magic by Richard Hererra that works with SWFAddress that will bump your HTML path into an anchor path, bring you back to the main page with the flash embed, and pass along that path back into the Flash, allowing you to pass links back and forth between the HTML site and the Flash site seamlessly. Of course, it also has bookmarking, deep-linking, and back/forward functionality.

So each template has an HTML representation and a Flash one. The Flash templates are built out in Flash, using elements with a visible stage presence, so without modifying code, nondevelopers can rearrange, resize, shift, and restructure existing templates, or create new ones. There were some tricks I developed to deal with templates rooted in DisplayObjects, particularly utilities converting runtime instances into class factories — so you can drop in one element, preview it visually in the authoring environment, and instead of populating it directly, use it as a template to fill out as many of those elements as required. Another nice utility that I couldn’t have done without was getChildByType(), which reduced my dependence on instance names in the template sprites, along with the DisplayListIterator Michael built.

Another utility I created along the way that proved invaluable was an implementation of asynchronous tokens, which gave us the ability to admit the realities of asynchronicity in the type system itself (a function returns AsynchronousTokens when it’s asynchronous, and the returned token acts as a Schrodinger’s cat until the operation completes), and the ability to cut through tons of dependencies that would have otherwise crippled us. With composite asynchronous tokens, we could group sets of asynchronous tasks in a single task, waiting on arbitrarily complex tasks without any care for what was occurring, only for its result. This opened the door to a lot of efficient, lazy loading and kept my architecture loose.

In addition to this, a set of small semaphore implementations I wrote helped keep states from complicating things. Instead of an enabled boolean accessor, often-used items would have a public semaphore, which could broadcast when it becomes available or unavailable, and be checked out. One implementation gave you a token when you checked it out, allowing you to pass the baton between unrelated tasks, calling release() on the lock token itself rather than trying to find where it came from. Another implementation tied the semaphore to an asynchronous token: the semaphore remains locked as long as the asynchronous process is active. This is really invaluable for navigations and animations that shouldn’t be interrupted.

We have a lot of instances in the site of a holy trinity of classes: flippers, transitions, and layouts. Flippers are a nice and simple abstraction of any kind of selectable set. Often they have both a flipper and a flippee, such as the media players, where the flipper is the row of photo icons, and the flipee (ok, FlippableCollection) is a view stack of images. Layouts allow you to flow together elements and control their display, and transitions, you can guess what they do. These seem a bit flex-ish but I approached them in an extremely low-dependency, lightweight fashion. Thus, we build up complex functionality by slowly seeping in features up the inheritance chain, pulling in interfaces that define the additional functionality. So for example, we have a PageStack, which is just a view stack, then a TransitioningPageStack, which uses an ITransition between showing pages, then we have a PageFlippableCollection, which is a TransitioningPageStack that implements IFlippableCollection (bringing in the idea of pages as flipper fodder). You can see these PageFlippableCollections in the pages of job descriptions and the pages of case studies. Also, you can see them in the news and accolades sections, but here instead of the pages being powered by a text field paginator, they’re powered by a column layout. Both of these just spit out IIterators of pages for the PageStacks to consume.

We use a lot more fun tricks that I would like to cover in more detail later. Mostly we do a lot of juggling between bitmap caches and display lists. Display lists take up CPU and memory, bitmapdata takes up a lot of memory, and the thumbnails of the pages loaded in externally take up little CPU and little memory, so while downloading a bunch of those thumbnails takes a bit of time, we have big fat broadband connections now, and it helps be able to run the site, while I play a juggling game, showing you real pages, dynamically generated snapshots, and compressed thumbnails of the pages as you use the site.

Speaking of those, the thumbnails of the site are generated by the site itself, using an AIR app! The app is kicked off by the CMS when a page has been changed. It calls up the current site (so that the thumbnails are always generated by the latest code, with the latest changes), and puts it in a special mode, eschewing the normal operation of the site and instead rendering a single page in its initial state. The AIR app then gets a signal, takes over, takes a bitmapdata snapshot, and writes it out to disk. Viola, picture-perfect thumbnails every time! I sound like Martha Stewart.

The site also uses a bit of the dynamic text wrapping and object serialization techniques I posted about earlier.

All in all, this sucker was huge. The hugest thing I’ve ever attempted. Something like 17,000 lines of original code by me, MA and JY (ok, counting my copious whitespace and occasionally thorough commenting). I knew it was gonna be huge so my basic design principle throughout was decoupling. I relied on interfaces to pull together common ideas, usually sketching out my design in interfaces before writing any concrete classes. Because there’s so much shared functionality mixed up between things that aren’t totally alike I made lots of small extends to implement up more interfaces, so I ended up with quite a few classes, but also the ability to start extending from points that didn’t have irrelevant functionality stuck with them.

The designs and required functionality, of course, also changed throughout the project, and since it was our own website, I never wanted to push against these. Decoupling, of course, helped us here too. I tried to keep things in broad strokes and fill them in with details in the ways that people could see early on, and we were showing stuff at builds even at the first week. Of course, we could have done a lot of things better, but I feel like this project was pretty successful (I mean hey, we didn’t get cancelled!) and an immense learning experience.

My thanks go out to everyone who had a hand in this site, especially Isaac Golino, Jeff and Michael, Lisa Smith, the countless people who have lent a hand or worked on previous iterations, and the people who were brave enough to clear up our schedules to work on this thing at their own expense. Hopefully the team will plug some of the remaining bugs and people will take good care of the site, keeping it fresh with content and taking advantage of its extensibility.