Websites are like houses. The creator of Django confirms this idea I've had in my head for a while. While I lack his experience working with the internet, and I have not worked in construction or studied architecture, I see the similarities in the processes. I also believe these similarities will can help us correctly defined the future of websites.

Definitions

Most websites are, or should be, functional, so they're rarely foremost works of visual spectacle. I am excluding the genre of the Flash-based brochure sites, as they are closer to commercialized movies. I am referring to sites that foremost deal with data: its storage, distribution, presentation, aggregation, and management. Since the internet is about interacting with information, it doesn't do much good if the information is static, like in a brochure site. Therefore I'm referring to sites where the data is very dynamic. Of course, it doesn't matter what the site does; sites do a lot of things, from tracking your life to being a game.

If making websites was about visual spectacle, it would be more like making a painting or a movie, all about the visual feel with little concern about supporting functional, non-linear interactivity. Rather, making websites is different and harder in two ways. First, websites, like other software that support user-interaction are non-linear. This changes a lot of the underlying creative thought process. Instead of just imagining the natural, cumulative, visual progression of strokes on the canvas or frames in the clip, you have to think of use cases, the variety of paths that branch and fork depending on what the user is looking for. The user is given too much interactive power for linearity to work.

And that's how, for a while now, I've realized like many, many others, the website of our time is actually software.

Analogies

And making software is like making houses. Both tasks take a very long time. There are numerous stages, and I'm sure, variations of processes for projects of various scale. There are many components and with them, are constraints. And these standards must be met, or the result is unusable. Just like poisonous Chinese drywall doesn't meet standards, make people sick, and devalue the houses they're in; a website where there are ads anchored to malware or flash banners that interfere with the layout and content upon mouse-over will drive away readers and actually lower revenue, thanks to ad-block features on browsers and userscripts. Or something as careless as forgetting user-friendly color contrast.

Software is heavily indebted to its implementation. In most fields of visual media, the task of implementation has been automated, so most of the labor of making a book is making the designs, the page layouts, and choosing typefaces, color, and other visual assets. While libraries and frameworks like jQuery, CodeIgniter, and WordPress have helped a lot, such that the level of automation that allows us to, in construction terms and according to Mr. Moss, assemble heavily pre-fabricated rooms, though at the expense of some ability to customize. Still! someone making a website has to think of why a page shows up blank; and if he wants to have more visual control over the layout, he must learn a relatively advanced subset of markup languages like HTML and CSS before being able to change something conceptually simple like the gutter-width on a column. Imagine if someone making a book had to do that. Or that a reader needed the right set of 'browser reading glasses' to view a book's pages correctly. Albeit, you can choose sewing, gluing, and binding your own copies instead of the press; but printers can do everything, while you retain near-complete control over design and material. WordPress.com and other non-coder web platforms still require coding if you want to get that other 20% of the website perfect. And they represent only a small subset of current web-apps. As Mr. Harris says, "[The tools aren't there yet. We need better tools and the people to build them.]"

So, my deductions are 1) websites are non-linear by nature, and 2) implementing a website is a process that, with our level of tools today, cannot be easily automated. And that's why making a website is a lot of work, like building a house. A big site like Facebook would be akin to a skyscraper, or maybe even a cluster of them. And designing the interaction for a big site like that requires a deeper understanding of the website's architecture and community, a keen foresight of cause and effect, and definitely of the tools available. I have always felt Facebook is what it is because of its scale and (improving or worsening) level of functionality, and not because its main color is blue, or that it mostly forgoes rounded corners.

That said, it's time for people who want websites and the people who make them to get a little more serious about the task.

Imagine a house. Here some walls are built differently than others. Some doors use a square knob, others a round one. And not one room's window is shaped like the others'. Like this house.

You can't see the real suck behind a bad website, but you feel it the more you use the site, and eventually the sloppiness of the architecture and construction are revealed. It could be that the free CMS you got is a half-organized gigantic bundle of patches and debris, making it hard to develop off of. So you started mixing content, presentation, and business logic; and with each ensuing update the site's visual consistency got thinner. Spacing being off, buttons not aligning, modules looking slightly yet painfully out of place, some parts not even loading. Or perhaps the plugin or extension you mindlessly downloaded lacks proper documentation, or does not follow modern web standards or an appropriate, clear design pattern. Or perhaps it doesn't know how to communicate with your other plugins to make sure they don't all do a costly HTTP import of the same JavaScript library, and so it slows down the load time of the page. And if you don't know much code, you don't know what to do when this plugin breaks with that extension, except to beg the under-compensated developer to spend his time dealing with someone else's code. It's as if we developers build websites expecting them to be short-term and disposable, because only with extra effort can a website / framework / application be made somewhat less of a nightmare to maintain. And that effort is really effortless when we understand the impact of our work. We're building real things that others interact with. We're affecting people's lives and livelihood. No joke.

So what (now)?

The problem is this is somewhat accepted, in the sense a real website analogous to that house isn't torn down. And in some places, it has become the culture, the norm; and you'd get fired for voicing out. Otherwise, a lot of the under-budget regions of the web are filled with poor software. Despite a quality website's heavy reliance on customized, product-specific implementation, the general mass have little care or knowledge to code. The result are ghost-towns where these houses do not fit/connect with their intended community, and it's mostly due to poor or inappropriate implementation, usually brought on by poor or inappropriate planning, from both the site-makers and the toolmakers.

To be fair, there are also constraints with resources. Clients think about how much money they're burning and their business' cash flow. Designers lack the time to research the platforms, frameworks, libraries, plugins, and general technological restraints they are designing for. I am almost certain this is not the case with architecture, where you don't just implement the design for a 500-story skyscraper. Meanwhile, developers think about how in the world they can make the 2-month deadline for that 500-story high skyscraper; because they are usually at the end of the production pipeline. And users, including myself, focus mostly on that the app doesn't have a subscription fee, or at least has the free option.

So then, what's the solution? Should we blame global competition and currency imbalances for driving rates down on the workers, the builders, the developers who hold the most power and responsibility for a website? Because $15/hr is a wage that cannot feed a family, at least not in Los Angeles. But web services like oDesk are making that wage deflation a harsh reality, no irony intended.

I think it's only appropriate for me to list a few things I want to fix, and to have you and the community involved in this new construction take it from there.

1. The guy in charge of content needs a better, layman tool to manage and grow it.
2. The guy in charge of the code needs a raise. He also needs to let go and stop using bad software, which thereby taints everything he builds. Hopefully with the raise, he'll have the resources to learn new tools, help improve existing open-source tools, as well as role out his own tools to grow the development community.
3. The end user needs to realize the web is software, start demanding the best quality, most forward-thinking software, and stop putting up with sloppy, outdated software. This includes browsers. The realization of software should lead to some consciousness of the different approaches to web software. Hopefully the less merited approaches will get more public criticism.
4. The client needs to research (or hire someone to research) what already exists on the web, and learn to forgo features, and if needed, leverage the existing utilities (i.e. social networks, media hubs) in his own website. This way, he doesn't copy Google in terms of features, but has a better chance of imitating Google's quality of implementation. Less things to do means more time to do them better.
5. Mentioned before, the designer needs to accept and study the two differences between web and print media: nonlinearity and the highly unpredictable cost of implementation. A successful website/user-experience design needs to find solutions for both issues.
6. Lastly, and this is more of a wish: for too long has it been OK for the general public to have this phobia/aversion to anything related to the internals of computing, primarily code. To me, the only difference between Mandarin and PHP is Mandarin is a human language and PHP is for web servers. Both have good parts and parts that suck due to growing pains. (Apparently, there was no consideration given to how the romanization of Mandarin would be compatible with English pronouciation, despite English being the world language; and this has caused a lot of our names to be butchered). There ought to be no barrier for users even submitting specifications and pseudo-code for developers to follow. The quality of community-driven tools is directly proportional to the amount of participants × their average talent × the efficacy of their participation.

If we are going to move our lives online, then let's at least demand better housing.