All forward-thinking technologies share one attribute: the original designers intentionally build in opportunities for future users to innovate. It requires humility and a belief in the creativity of others. This is true for buildings, computers, networks, and other tools.
As we design systems in Drupal, we should try to imagine how its flexibility can reward future sitebuilders, and allow for innovations that the principal designers cannot imagine themselves. This post is part of my answer to the perennial Why Drupal? question, but it’s also deeper than that, and gets at an inherent tension in web design that I’d like to examine carefully as SWS grows its product line. Drupal is a flexible tool-building-tool. Jumpstart is a purpose-built product. How do these attributes co-exist?
Room to Tinker
In October of 1990, having recently convinced CERN that a world wide web would be a good idea, Tim Berners-Lee sat down to write his first web client. He had working software about a month later (!) due in no small part to the affordances of the computer he was using — a NeXT machine. As it turned out, the fact that Sir Tim was using a NeXT mattered. A lot.
“I still had to find a way to turn text into hypertext, though. This required being able to distinguish text that was a link from text that wasn’t. I delved into the files that defined the internal workings of the text editor, and happily found a spare thirty-two-bit piece of memory, which the developers of NeXT had graciously left open for tinkerers like me. I was able to use the spare space as a pointer from each span of text to the address for any hypertext link. With this, hypertext was easy.” [1]
In 1990, the emergence of the Web was not a foregone conclusion, in fact, this was a KM side project, a curiosity on which the CERN leadership gambled, and they gave Tim a couple of FTE for six months. That’s it. What if he had struggled with development because he had inflexible tools and had little to show when the six months was up? Would we even have the Web that we know today?
Learning from physical spaces
Leave room to evolve is an imperative that calls out from the landmark book Make Space, by Scott Doorley and Scott Witthoft.
“Allow the space and the people to continue to adapt and grow. Do less. leave some aspects of the space open-ended, even though your impulse might be to take care of every detail. … Open space provides a buffer for identifying, absorbing, and responding to unanticipated needs” [2]
Of course most of the digital spaces that we build do not start with the same brand of high-flying creativity that bursts from the seams of the d.school (When was the last time your web project called for 9-foot grain thresher?). Nevertheless, there is a lot that we can learn from the ubercreative plaid-wearing set from Building 550. Sure, we iterate. We’re all agile and whatnot. Our projects have version numbers and roadmaps, and hell we even listen to real people (gasp!) and think about what they need before we make stuff for them. But what about identifying, absorbing, and responding to unanticipated needs? Evolving needs? Do we as web designers, have a line on how people inhabit the digital spaces we build, after the work is done? What are the hacks and workarounds that users employ to make our tools do what they actually need (c.f. desire paths), even the things that they didn’t know they needed when we asked them during discovery?
This is exactly the question that Stewart Brand explores in his book, How Buildings Learn: What Happens After They Are Built. Brand shows how people modify the places that they live and work, that the best buildings learn over time by the inhabitants hacking their own solutions to problems. Vernacular Architecture is the term for a transmitted popular culture, an eminently practical structural dialect that emerges in a given place, based on local needs.[3] What distinguishes it from the high art of professional architects is that it follows the advice of the d.school above:
“Vernacular buildings evolve. As generations of new buildings imitate the best of mature buildings, they increase in sophistication while retaining simplicity.”
Can we build an Adaptive Architecture for the Web?
(Here I mean “adaptive” in Stewart Brand’s sense of creating room to tinker, not RWD.)
The good news is that Drupal is awesome at adaptation and scaffolding future growth. Stanford University is a mind-bendingly expansive enterprise, and we have chosen a tool that can expand as our needs on the web evolve.
For this reason Drupal is chosen over and over again by large, evolving organizations. It’s a domain modeling framework and a toolkit that can start simple, but expand to meet complexity, which is why it’s the tool of choice for many universities, the U.S. government, municipalities, non-profits, and large corporations alike.
Stanford Sites Jumpstart was conceived to harness the power of Drupal, but make it dead simple, even pleasant, to use. We pruned off the rough edges from the Drupal installation process, and gave our users a simplified UX that they could get started with from day one —without having to take a Drupal training class first!
This simplification approach has been wildly successful, and our users have validated this design philosophy. But have we let the pendulum swing too far toward simplicity? What if the needs of our users are complex? Let’s not lose sight of how we got here, how the great visionaries on whose shoulders we stand (like Steve Jobs, and Tim Berners-Lee) left us room to tinker, and to innovate. As we design today’s systems, let’s have a similar amount of faith in our future users.
“Let people do things.”
—Stuart Brand
Complications for Products
Though I am advocating for people to retain the freedom to tinker with the tools we create, this can be dangerous idea if we also expect these tools to also behave like products.
How does the imperative to design for future innovation jibe with platforms and products like Stanford Sites, Jumpstart, Open Atrium, Commons, DKAN, Open Aid, Open Outreach, etc. in which it might matter more that things Just Work™ ?
This is where the parallel with physical buildings breaks down: a builder of homes never hears from a client: “I’m sorry, I accidentally deleted all my walls, can you help me get them back?” If we follow Stewart Brand’s advice, and let people do things, they will inevitably break stuff. This is just going to happen, and is a natural step in the learning process of becoming a site owner, and eventually a Sitebuilder. As designers we have to have some tolerance for learning-by-breaking-things path, and resist the urge to make that impossible, since that choice ramifies toward taking away sitebuilding capacities altogether.
Challenge: the only way to enjoy the benefits of a distribution over time is to use it as intended, and not modify it’s fundamental aspects. Patching or modifying significantly takes you out of the upgrade path, and defeats the purpose of the distro as such. So how do we strike a balance?
I don’t really know the answer, but I do think that SWS is onto something with the Jumpstart product suite. It’s a simplified user experience, but it’s still Drupal under the hood. We are consciously working on this problem of “leveling up”, which applies both to websites, and to users, as they learn and grow with their system. We work iteratively, we test, and we pay attention to the desire paths that our users convey in the way that they adapt what we have built.
Affordances and Desire Paths
The image above depicting a no-parking sign posted on Stanford campus is an example of how users will satisfy their needs expediently, with tools that are available (aka “satisficing” ). This signage probably isn’t the version that Stanford would officially endorse, but it works, it satisfied a need, and the person that devised this solution spent maybe a couple dollars in materials costs (I count 8 zip ties.)
Websites powered by CMSes work like this too (at least the good ones do). Drupal is a powerful, flexible toolkit. Even when we package it up as Features and products, it’s still a toolkit underneath, and a natural process in a user’s development as they learn and grow with the tool is to solve their own problems expediently with what’s available, using tools they can reach. And our toolkit includes the equivalent of zip ties —super-handy, seemingly all-purpose tools whose affordances allow the user to apply them in multiple (sometimes surprising) ways.
Certain kinds of vernacular architecture were innovation-friendly because they communicated their affordances to their inhabitants. “The lesson for the ages from three-aisled structures is that columns articulate space in a way that makes people feel comfortable making and remaking walls and rooms anchored to the columns”[4]. Is there a digital equivalent? What can we do with UX design to help our users see what’s possible, without letting them get into too much trouble? Can we design the user experience so that the tool teaches its users?
Design is human.
Design is about solving problems for people. As designers of tools we always strive to empathize with the people that use the tools we make, and part of that is making complex things simpler, but we shouldn’t sacrifice our users’ ability to innovate with our tools in ways we can’t imagine. There are things they know about what they need that we can’t anticipate. The NeXT engineers left Tim Berners-Lee the 32 bits of memory he needed to write a hypertext editor, which gave birth to the web as we know it. Now it's our turn.
We should always leave a few zip ties within reach.
Notes:
- Weaving the Web, pp. 28-29
- Make Space, pg. 76
- I see a direct parallel to Vernacular Architecture in what we commonly call “best practices” in Drupal development, and how that term can refer to slightly differentiated discrete practices in different locales, institutions, verticals, and communities of practice. Darwinian. We are finches.
- How Buildings Learn, Chapter 9
