For you, this image may or may not conjure up intense feelings of nostalgia. For me, this was The Beginning of the Internet. It was a land accessed through a ritual of weird sounds, a tether of harsh but magical noise that made it possible for me to climb through the phone line into a realm of shared imagination. I had conversations with strangers and pretended to be someone different. I flew spaceships and fought dragons and hung around taverns quaffing ale and discussing the finer points of dagger combat with dwarves. My Nintendo became suddenly very lonely.


The early internet was a place that felt more wild and free than my non-virtual life but at the same time, exclusive. It was a private playground for those with the inclination and access. At first, I reveled in this exclusivity. To my parents, my sister, and most of my peers it was an unintelligible landscape. I enjoyed the secret power I was able to wield, to create images and sounds, to find information, to connect with individuals that were far away. But I also felt the immense potential of the internet to unite, to make the world smaller and more friendly, and I became interested in the problem of how to bring everyone in.

The digital divide profoundly affects the culture of the internet. In the beginning, this meant only wealthy or middle-class first-worlders. Today, there is a more subtle divide I want to talk about.

While access to networked computers is required for participation, it’s only the first step. The ability of a person to create and find information on the internet once they have access is constrained by the tools they know how to use. The cryptic settings dialog, the command line, these are some of the very earliest tools and were inaccessible to most people. We’ve made many advancements, each one giving more people more power and each time we push the envelope, new horizons appear and we’re challenged to make more and more sophisticated tools. The web has transformed from an innovative way to publish documents into a complex extension of our daily lives and the dream of giving non-specialists the full power of this medium continues to live on the horizon. Let’s walk through some of the history so we can put today’s tools into context.

HTML (1993)

Ah, the mid-90s. The flannel was flying, the VMAs became a thing, the Bosnian War ended and Star Trek Voyager began. This period also brought us what we think of today as the consumer internet. People started using the word browser in conversations, and it became possible for non-programmers to carve out their own space on the internet by “coding” HTML pages. Creating a web presence was still firmly in the realm of the nerd, but the barrier to entry became much lower and the audience bigger and more easily reached. When GeoCities started hosting member pages in ‘95, the barrier became even lower.

The proliferation of browsers and browsable content was huge, but the technology went largely unused by businesses and other organizations. The need for the manual management of content required a new profession, the Web Master, and not everyone could find someone to fill this role nor did they always see the need. Who wants their marketing gated by a socially awkward kid that speaks in jargon half the time?

Page Builders (1997)

FrontPage and Dreamweaver brought web publishing to the masses. Now anyone that could wield a word processor could create a basic web page. These tools really did change the game, but they never fully lived up to their promise of allowing anyone to create really robust web experiences. Complex interactions, connecting to a database, interfacing with third-party services, all of these things still required a specialized skill set.

And there was a new problem. As more complex applications started to be in demand, teams comprised of developers, marketers and designers became more common. WYSIWYG tools were great for the marketing folks but a nightmare for developers. They generated unwieldy code and forced you into a workflow that seemed never to have considered collaboration with developers but the developers were still required in order to implement the more complex areas of the application. This was the origin of a tough problem in web publishing and software creation, in general, that continues to plague us. Tools that automate the creation of code empower non-technical users but tend thwart developers.

Web Frameworks (Early to mid-2000s)

During this same period, far nerdier changes were afoot. First we started to see web-specific languages pop up like PHP. This dramatically reduced the effort involved in building web sites and web applications. Still, none of these languages made it easy to interface with page builders. Developers that managed to steer clear of FrontPage had a different problem. For each application, they had to build and maintain interfaces that allowed non-technical users to create and manage dynamic content. This is a repetitive and error-prone task. The administration interfaces would often double or even triple the size of a project.

One approach to ease this pain was to make more and more powerful libraries that could abstract away as much of the repetition as possible. There is a huge list of these libraries as well as much debate about whether to call them libraries or frameworks or something else. There was a lot of experimentation, and it seemed like everyone was writing one, including me.

Big players released their own frameworks like ASP and JavaEE. We even started to see some integration between certain frameworks and page building tools which seems like it would solve a lot of issues but in practice--let’s just say they continued to incur excessive overhead.

While frameworks made developing large applications much easier, they still carried a large maintenance burden and developers, like their Web Master ancestors, were and still are often the gatekeepers of content.

What did developers do about this? Well, they wrote some software of course! Specifically, they wrote software to try to abstract and automate the process of creating interfaces for content creators.

Content Management Systems (Mid 2000s)

The original purpose of a CMS is to provide a way to easily manage all the documents, images, etc. generated by an organization and to make it easy for individuals to link and categorize this content. Many do this well, but few are actually used for that purpose. These days organizations need more than what is essentially a shared file system. They need to be able to access their data in many different ways depending on the audience. In other words, they need to provide experiences, not merely access to content. Some systems have evolved to try and provide this usually through some combination of page builder-like tools and plugin APIs

Platforms like Joomla or even WordPress and their many cloud-based children, like SquareSpace have ushered in a world where nearly every business can have a full suite of powerful publishing and commerce tools without hiring developers. For many companies it is design and vision that are the barriers, not technology.

What’s Next?

The CMS way of seeing things, indeed the whole model of the web, is starting to wear thin. The lines between what is a web “page” and what is a complex, interactive experience has been blurred for a while, and our tools are being strained. The need for cohesive experiences across multiple devices only adds to this strain. A lot of experimentation is going on around how to deliver interactive experiences across platforms, but it is mostly confined to the dev world. This is a great time to step back and ask ourselves if content publishing is no longer the right model, or merely too restrictive, what is the right model for the web? What do the tools look like that facilitate collaboration between designers, developers, and users of the new web?