Skip to content Skip to navigation

Drupal Sitebuilder, Citizen-Engineer

Either we shape the the technologies that we use, or they will shape us.  Stanford’s commitment to the Drupal CMS enables more of us to think like engineers, embrace the Maker ethos, and craft our own tools.

“The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it.”
Mark Weiser, Xerox PARC (1991)
“As much as we love the open, unfettered Web, we’re abandoning it for simpler, sleeker services that just work.”       
Chris Anderson, Wired (2010)

Drupal’s affordances “allow non-developers to do developer-like things” (quoth Rob Ristroph, ninja developer) and the Sitebuilder is a class of Drupal expert that doesn’t get the billing it deserves. Drupal allows more of us to behave like engineers — individuals that can apply technology and ingenuity to solve real world problems.

It is important that we technologists retain our status as Makers in this consumerist age of technical atrophy. By technical atrophy I am specifically referring to the trend of becoming mere consumers of services and products, rather than technologists that are fluent in the technologies we use and capable of understanding and modifying software to suit our purposes. 

The above quote from Mark Weiser is an astute observation, and I have heard it cited many times by designers aiming for the holy grail of invisibility as a marker of success. A good thing. But I don’t think it’s necessarily good for everyone. Invisibility-in-use is great for Users, but bad for Makers. Makers should know how stuff works, and grokking requires visibility.

The Appification of Everything

I went to SXSW Interactive for the first time this year, and I was struck by the marked focus on mobile apps.  There was still a Mozilla booth with a dude in Firefox costume and conspicuous Yahoo! and Google lounges and events (I seem to recall whole buildings sheathed in massive dropcloths emblazoned with brands), but in the rarefied world of SouthBy, it seemed that the cool had drained out of the web, and had been ceded to the appiverse. Seemingly everyone had a new app to promote, and the crowd was waiting expectantly for the next Twitter to be unveiled. Nevermind that Twitter was a web app first, people were panning for gold in native apps.

I have seen the projections for the growth of the mobile market, and I am aware of how important mobile devices are for web design. But still, it seems to me that, for some, the web has been occluded by mobile — which is shortsighted because native apps are just one aperture into the web.

The principal problem with the Appification of Everything (AoE) is that it accelerates the deprecation of the role of User to that of Customer and accelerates technical atrophy because it winnows the segment of people who can do interesting things with technology. It also embodies a fundamental misconception: that websites and apps are distinct from one another. Todd Nienkerk wrote a great blog post on the Four Kitchens blog recently that summarizes this problem well: Apps Are Icons.

Attributes of a Citizen-Engineer

To avoid a future where everything is super comfy, software always Just Works™, and the only device a full participant in the internet would conceivably need is a tablet full of apps,  we will need a certain kind of person, and we will need that person to understand his power and his purpose. We need Citizen-Engineers.

A Citizen-Engineer:

  • Has the ability to understand code, and learn new technologies, but does not have be a trained programmer
  • Can innovate within rule-governed creativity
  • Understands the basic principles of every layer of the stack, hardware and software
  • Can modify the tools they use
  • Has tolerance for imperfection
  • Has problem solving skills
  • Has expertise in a field other than web development
  • Values the commons of the Internet
  • Understands how policy can affect technology, and acts to protect freedom and innovation

A Citizen Engineer: The Drupal Sitebuilder

There is a startling array of configuration possibilities in Drupal using just the administrative UI, without writing a line of code, because core and module developers in the Drupal community have intentionally built power tools for us to innovate with. This is a particular quirk of Drupal.

Sitebuilder is a term that has emerged over time, and there may be some dispute as to what kind of skillset it includes (at some shops, a person with this title is a web developer, but I think most people think of Sitebuilder as an adept in the Drupal system, that relies mainly on savvy configuration and implementation of existing code written by others) but it has a special meaning in Drupal compared to other systems. That we have so many talented Sitebuilders is one of the least celebrated, yet most important attributes of the Drupal community.

The reason why the Sitebuilder is so important is that often they are experts in something else, subject matter experts that can use Drupal to model things that exist in their discipline, and since Drupal is also a collaboration platform by nature, the datasets that are created with it are ready-made for allowing communities to grow around the tool, or the practice that it encodes.

Some recent examples of projects that innovate using Drupal’s ready-made tools:

Try Hard Things

Richard Stallman, at a recent lecture at Stanford Law School, reminded us that users of Free Software assume a burden for the freedoms that they enjoy.  It is likely that a given open source system will not have a glossy, perfect user experience out of the box.  Instead of giving up, and defaulting to buying proprietary systems that seem to meet more of our needs right away with little effort, the Citizen-Engineer rolls up her sleeves and changes the rules. She knows that she has the ability to modify the system, and shape it to act more like she wants, and by contributing to an open source project she not only benefits herself and her immediate stakeholders, but potentially lots of others as well in a vast, sprawling commons that is the Internet. Being an open source software developer is harder than paying for a 3rd party service. Being a Drupal developer/sitebuilder is harder than, well, lots of other choices, really. But the future belongs to people that are willing to try hard things.

Comments

Thanks for the astute and well written piece. I only recently realized that I was a Drupal Sitebuilder. Until now I only described myself as a non-programmer, non-themer who knew his way around the Drupal API pretty well. It’s nice to be a something as opposed to a non-something. It is indeed liberating to be able to put up a site at will about nearly anything if the need or muse arises. I have on occasion availed myself of programmers and themers to more finely craft what I’m after. To its credit, I’ve never felt the Drupal community denigrates or looks down on mere enthusiasts – that’s the other term that seems fitting to me other than sitebuilder – in any way, and in fact looks to make their lives easier whenever feasible. So I’ve come out of the closet and wear the moniker proudly. Most importantly, as you imply in closing, we Drupal sitebuilders are not afraid of trying hard things, which is good, because Drupal is many things, but I wouldn’t say easy is one of them!

Hi Gabor, I'm glad you found this post affirming. You are right, the Drupal community is welcoming, and has a long history of mentoring and helping others up the ladder. No one denigrates Sitebuilders exactly, but I have noticed non-developers taking that on themselves: "I'm only a Sitebuilder, but ..." and I wanted to acknowledge somehow that I think it's the Sitebuilders that will be doing the really interesting work in Drupal. They ask the best questions. I think that one of the areas in academia that Drupal will make its mark next is bioinformatics, we should watch for work coming out of UVA, UCSF, and Stanford. But the same rule applies to all disciplines, in academia, government, media, etc. — Drupal is essentially a domain modeling framework with strong collaboration and integration capabilities, and if we can spend the time to learn it, it will, over time, outperform all proprietary software that we are told is the only solution.

This particular post did not make it into the SWS Twitter feed so I only found out about it via another source. Good article, glad I did not miss it.

Thanks Warren, I appreciate the feedback. I don't think all SWS posts are passed through to the Twitter feed, but maybe we should do that ...

I heard from Rob recently, and he has this to say about this topic: "I recently read a book title "The Computer Boys Take Over" ( http://www.barnesandnoble.com/w/computer-boys-take-over-nathan-l-ensmenger/1100660202 ) and one of the observations in there was the long history of things invented to make it possible for non-programmers to program, and how those things inevitably got more complex and became the next generate of programing -- fortran, cobol, php, basic and visual basic, etc. These things start as ways to avoid having to hire short-supply and expensive programmers, and end up being complex tools that require higher skills, and the cycle repeats -- I think that is partly happening with Drupal and it's point-and-click site building." Reactions?

I'd like to amplify my book recommendation via Zach. "The Computer Boys Take Over" refers to a moment at the start of the computer era, when "computers" were people, mostly women, who worked in large rooms with rows of adding machines doing calculations for the Navy and other big organizations. The women who survived the high turnover long enough became "computer planners" who worked out flow charts of what numbers would be passed from person to person on paper to complete the computations. These women naturally became some of the first machine computer operators and coders.

As people realized software was hard, there was the first of many waves of "professionalizing" the industry - requiring degrees, creating academic and professional societies, etc. In that first wave the programming industry switched from being mostly female to mostly male overnight.

The history of the progammer's repeated efforts to professionalize and raise the status of their community, and business manager's repeated efforts to find a way to make programming not require expensive profressional programmers, is really interesting -- I see a lot of the same issues reflected in the Drupal community's discussions about education and certification.