Coffee, Process, and the making of the web by Alex Cabrera

One of the first things I did when I moved to New York earlier this year was order a hot plate and a stovetop espresso maker from Amazon. Having been forewarned by another Miami expat of the lack of proper Cuban coffee in the city, I was determined to maintain productivity in the afternoon by taking part in the holy three o'clock ritual.

Unlike a cup of joe, a cafecito is as much about the elaborate process of preparation as it is about the final product. When I began to make it for the first time, one of the HackStars was carefully watching every step. About halfway through the process he observed how he always enjoyed watching people who took process dead seriously. I was, very clearly, not messing around when it came to my coffee.

It made me think a bit more about how the real challenge of what we were building at Marquee has everything to do with process.

The cobbler's son has no shoes

Over the years, I've had countless fits and starts of putting together a website for myself. Every time I would start, I would get caught up in the process of how to go about it. When I began my first experiments on web in 1997, I quickly grew frustrated by the lack of template systems, reusable components, and the amount of manual work that went into maintaing the content that went on the site.

Looking for a template solution lead to Perl and terrible CGI scripts. Looking for a way to back content with a database lead to PHP. Living with PHP lead to Python. And on and on it went. The deeper I got into any one solution, the number of new things I realized I had to learn in order to come up with The One True Way™ of doing things.

I became so consumed with the process of building for the web, that I lost sight of my original goal of building something. As it turns out, it wasn't my worst decision; those experiments laid the foundation for what would eventually become my career. Still, after using those skills to build countless websites for others, my own site could have easily been made with the notes I took from books at Barnes & Nobel fifteen years ago.

I, for one, tried to welcome our new blogging overlords.

When blogging began to come into its own in the early 2000s, it seemed for a while that the web publishing problem had been licked. Building a blog soon became the Hello World of the web. Ruby on Rails famously launched with a jaw-dropping demo of a fully-functional blogging engine being built in under 15 minutes.

Blogging was well served by the relatively low technical barriers to entry. Like many others that would roll their own blogging systems or install any of the myriad open-source options, I cut my teeth over the past few years on basic web technologies. By the time it came to putting a blog together, it was relatively straightforward. Use simple server-side includes for templates, get MySQL running, put together a basic data model - Title , Body , Published Date - a Post - duct tape everything together with (godforsaken) PHP.

But the problem of process over product remained. As I continued to hack on blogging engines, I realized the issue wasn't the tools we had built, but rather the assumptions we made. The early web was the glorious explosion of a new medium. The world built by blogging, on the other hand, was about efficiency, page views, and administrative management. As much as bloggers wanted to talk about content being king, it wasn't. The Post was king, and somehow that became the way we thought of web content - a reverse-chronologically ordered list of text blocks.

It was an efficient, if not terribly dim view, of human creativity.

The blogging systems that have morphed into the de-facto content management systems of the web are burdened by this adherence to the Post. No matter how many plugins are released, how many times the admin screens are rewritten, or how many URL hacks are created, everything that they do will always be based on Title , Body , and Published Date .

Again, it was about process; but unlike the process of those early experiments, it was one of monotony, routine, and efficiency. Every time a client told me their web strategy involved buying a Wordpress theme, the web got just a little bit sadder.

The times, they are a-changin'

The Slow Web Movement is largely a reaction to the monotonous efficiency brought on by template-driven blogging engines. The focused, art-directed approach of Jason Santa Maria's v4 or the hand-rolled approach to Dustin Curtis's work (who is now working on the only promising advancement of the form in years over at Svbtle ) were the canaries in the blogging platform coal mine.

Blogging has lost the real-time war to the stream , aggregation sites have taken over thoughtful discussion, and media focused verticals have changed the nature of content sharing. Blogging's advantage - The Post - has been commoditized, fractured, and decentralized. What's replacing it, is something that's more expressive, malleable, and interoperable.

Blogging is giving way to the API. More specifically, the Post is being subsumed by JSON - it's merely one of many structures that can be expressed and delivered from a server to a client.

At Marquee this is core to our outlook of how the web will be constructed. By developing flexible, open structures that can be used to express all kinds of content, we can focus less how to shoehorn everything into a content management model, and instead return to focusing on making the process of expression enjoyable. By admitting that we don't know what everyone is going to want to make, we can focus on solving the lower level issues - those of interoperability, hosting, design, and delivery.

It's clear that all content is becoming web content; and we don't want to live in a world where all of that is trapped inside of a blogging engine.

We believe the process of making for the web can be fun again. If you'd like to see what we're doing, we'd love for you to sign up and let us know what you think.