Building 3rd Corner Studios

The 3rd Corner Studios website was developed with the philosophy we call “experience based design”. With the advent of popular JavaScript frameworks like jQuery and mooTools, creating an experience for users has never been easier. If you take a look around our website, you’ll start to notice that it’s not really a “website”, but a presentation.

This is the bleeding edge of the web. We’ve combined over 20 years of experience, hard work, deliberation, and concept creation with the latest technologies and techniques to create an experience for our potential clients. All bragging aside,let’s get to the meat and potatoes.

The tech:

Our JavaScript framework of choice is jQuery. Super fun, easy to use, and supported by a great open source community, programmers, and plugins. The 3rd Corner Studios website isn’t very technical on the server side. So, besides serving the ajax fragments, their wasn’t a need for much backend work. We’re running your typical LAMP setup on Rackspace’s Cloud Sites. Our CMS of choice is WordPress.

What we did do on the server side was turn WordPress into a data entry machine using the Pods CMS plugin (if you don’t about ths, here) and some simple changes to the standard way WordPress processes a request.

WordPress and Ajax:

  • In the template folder, header.php we check if it’s an ajax request. (code)
  • If we’re serving an ajax fragment, don’t serve the header or footer (it just skips it all).
  • If not, process as normal.

A little aside about Pods CMS:

  • With Pods CMS you can quickly add different content types and it creates all the entry forms for you.
  • This allows clients and developers to finally get along, because every programmer HATES creating forms.

So, because we’re pushing the limits of what’s currently out there, I chose Pods CMS and WordPress because we can easily prototype and test new things. Not only that, but WordPress is a huge open source project that runs over 20% of the western web, and is pretty darn stable.

Ok. So, now we have WordPress and Pods CMS serving ajax fragments and handling the CMS side. For the front end, we have HTML5, CSS3, and jQuery.

The details:
Because we’re committed to experience based design, we created an event based action framework on top of jQuery. The creative process we go through can be summed up in a few words. Don’t think about what’s possible, just imagine… Sometimes it drives our developers crazy because we want websites that cook you breakfast in the morning.

All jokes aside, here’s what we did:

  • Created an event based animation and ajax framework built on top of jQuery.
  • We call it “Viewport”. It handles events, actions, and animation.
  • Combined WordPress and Pods CMS in a unique way to serve the data. “WordPodJax” (jk)
  • Added support for sub sections and contextually bypassing actions.

Now, that probably sounds like a mouthful of word salad. Let us break it down.

The event based framework:

If you take a quick look at the home page, you can see the four main services we provide sequentially fade in. Simple right? Create a loop in JavaScript, delay a couple milliseconds times the index of the current item, then fade it in:
Screen Shot 2012 03 12 at 7.40.40 AM Building 3rd Corner Studios

BUT…….: What about the other navigation items? If a user clicks on our portfolio section before the home page fully loads, what should happen? Before we continue, let’s get up to speed.

Viewport: A container/wrapper that loads the data served from Ajax requests.
Pane: These are the different sections that are loaded into the Viewport.
Bypass: Actions can be contextually skipped.

So we defined a few words, but what is it all about?

The philosophy:

Experience based design is not about what the user WANTS to do. It’s about what we WANT the user to experience. For this reason, when certain areas of our website are animating, or loading, you can’t click away.

To enable these type of features you need a robust event based framework. The two main programming patterns used to solve this puzzle are the event model and the task/worker (what i call actions).

There are some setIntervals used in various places, but mostly just good ol’ jQuery and an incredible amount of callbacks. We dubbed the framework “Viewport”. Event based programming in JavaScript can quickly turn into DOS like .bat scripts. GOTO line 1222….. With this in mind, we aim to slightly (if it’s possible) decrease the level of frustration when creating experiences on the web with JavaScript. That being said, there are 5 default functions we use to separate different states.

This is the machine that runs everything:

  // Portfolio pane execution object
  var vpExecPortfolio = {
    before: beforePortfolioEvent,
    exec: execPortfolioEvent,
    after: afterPortfolioEvent,
    onexit: onExitPortfolioEvent
  vpA.newExec('portfolio', vpExecPortfolio);
  1. The before event: Where variables are defined and pre-animation actions executed.
  2. The exec event: Since the basis of the framework is for animating, this is typically where all animation occurs.
  3. The after event: After animation is finished, sometimes we need to bind events or process actions.
  4. The onExit event: We needed to animate things after a user clicks a different section, this is where it happens.

These for predefined events are triggered on a case by case basis.

  vpA.newExec('portfolio', vpExecPortfolio);

The code above binds the four functions beforePortfolioEvent(), execPortfolioEvent(), afterPortfolioEvent(), onExitPortfolioEvent() to the slug ‘portfolio’. This simple way of routing worked for the first iteration of our site, but when we introduced sub-sections we had to upgrade.

The second iteration:

The first incarnation handled one “slug” and provided us with the ability to give users a nice experience. When we started think about v2 and v3, we realized sub sections of the website were necessary. Thus, the framework needed some upgrading. To handle this functionality we had two design options:

  1. Use the awesome Crossroads routing framework, and make everything as dynamic and flexible as possible.
  2. Go direct. Custom. This is not something you can just port into a different website.

The first option, is always awesome because you can re-use the code in different situations. The only problem with that is… uh… their aren’t many websites like this.

The second option, it’s a whole lot quicker to prototype when you’re not worrying about extending, modifying, and being flexible.

We went the second route for a few reasons:

  • It’s one of the caveats of experience based design. An experience should be unique. If your code can simply be ported to another project, it’s going to take away from the uniqueness of your potential experience.
  • Constantly worrying about how other people would use your code, the potential problems they would run into, and trying to write support docs and what not, add about 1000 years to the project.
  • We just don’t think making it flexible is the right way to go, because we have no need for regex routing.

Experience based design is more of a philosophy than a framework. Viewport is what we built to execute the vision. At the end of the day, it’s really not that complicated. Just a different way of thinking…

We’re looking forward to what other people will create based on this philosophy. And just for the record, we’re not claiming we “created” it (but we definitely push the limit). It’s just another iteration of the evolution of the web and human kind, and we’re certain there are others out there doing the same.

In summation:

  • Viewport is our framework that processes events and defines bypass-able actions.
  • It’s more of a design/architecture philosophy than a framework.
  • We love experience and goal based design.

Comments are closed.