Web projects are integration projects, combining skills from a number of disciplines. Lousy interfaces can obscure brilliant code, and ingeniously engineered back-end systems can still fail when they hit resource limits. “Content” lurks in many guises, requiring support not only from writers and illustrators but from video specialists, game designers, and many more. Marketers have built businesses on the Web, and influence conversations from design to analytics. You don’t have to be a programmer to do great work on the Web. The Web stack is vast.
Web development models include far more than code. Creating great websites and applications demands collaboration among content creators, designers, and programmers. As applications grow larger, supporting them requires adding a cast of people who can help them scale to demand. As projects grow, specialization typically lets people focus on specific aspects of those larger disciplines, supporting networking, databases, template systems, graphics details, and much more.
In some ways, that’s a recipe for fragmentation, and some days the edges are sharp. All of these communities have different priorities, which conflict regularly. Battles over resources sharpen the axes, and memories often linger.
At the same time, though, often even in environments where resources are scarce, different perspectives can reinforce each other or create new possibilities. Sometimes, it’s just because the intersection spaces have been left fallow for a long time, but other times, the combinations themselves create new opportunities.
I’ve written before about the possibilities of applying design values in programming contexts, but a concrete example keeps gaining traction lately: hypermedia. It’s an old term, going back to Ted Nelson’s many efforts to mix computing into other disciplines, but it took off in the ’90s to describe a wide variety of hypertext and multimedia projects, including the World Wide Web. As the Web came to seem less exotic, the word faded. Hypermedia has picked up a new charge, though, for computer-to-computer communications. Many of the same ideas that work for human-to-human exchange and exploration work for computers, and terms developed for human experience apply to APIs.
Even though Web developers frequently enjoy contrasting their practical approaches with the “ivory tower” of academia, the Web is capable of absorbing lessons from doctoral dissertations. Roy Fielding’s 2000 UC Irvine dissertation, “Architectural Styles and
the Design of Network-based Software Architectures” sounds pretty abstract, but the chapter on “Representational State Transfer (REST)” might sound familiar. Of course, it probably also helps that Fielding co-founded the Apache HTTP Server project and was an active participant in various software and standards processes, but a lot of people found REST through that chapter.
Some crossovers are made easier by similarities in roles. I’ve enjoyed listening to software architects and experience designers sharing war stories over a meal, finding that the challenges of human interaction while creating industrial-scale projects are, well, disturbingly similar. Both roles require coordinating groups of people who have their own priorities, trying to get them to agree on core values and structures. The structures look very different on the surface, but there are often similarities.
Creating great websites and applications demands collaboration among content creators, designers, and programmers.
I always like to go to “Git for Designers” talks. Git began as the epitome of a programmer’s tool, initiated by Linus Torvalds over a weekend (a few months to completion) to manage the source code for Linux. Pull requests? Branches? Diffs? Cryptographic history authentication? Delta compression? As it turns out, distributed development isn’t just a programming problem. Sympathetically told, git’s story fits the needs of many kinds of Web developers. GitHub put git on the Web and added social features, and today you can even use git to manage blog content.
As much as similarities can drive collaborations, though, differences and collisions can drive critical conversations.
Accessibility is contentious. Tearing down barriers often gets in the way of people who didn’t realize they were building barriers as they built something they thought looked cool. Accessibility folks rarely set out to be specialists in Web architecture, in the details of browsers, or in programmer education. However, accessibility specialists have had to face and call out more bad and good practice than almost anyone else out there. They work with more tools and among more details than most developers, and while their work is primarily on the front end, it also requires an understanding of interaction with the back end. Many accessibility folks work as consultants, giving them an outsider status that makes it easier to acknowledge what’s broken. If you need a good filter for what’s best for the Web and its users, ask an accessibility specialist.
Another key filter that often works through collision is the group of programmers who actually write the many browsers we all use. In the early days of the Web, browsers were small, and there were many, but it still took a lot of programming effort to build one. By the time Netscape released what became the open source code base of Mozilla in 1998, the Web was complicated and the skill sets were very different. People asked whether enough Web people cared about C++ (or vice versa) to sustain such a project. Today, it’s clear there are enough people willing to see Web technologies from a programmer’s eye to ensure that these projects can continue to flourish. Some days the programmers wisely tell us that it’s not yet time for processing-, memory-, or bandwidth-intensive features.
Of course, these two groups and many others don’t always agree, but that’s much of why I’m glad the World Wide Web Consortium (W3C) deliberately tries to include many different kinds of voices in its membership and experts.
One last group, often unheralded, is key to the Web’s cross-pollination: a constant flow of beginners. For many people, the Web is their first stop in creating content, applications, and sites. They bring experience from everywhere. That constant flow means that we have to take each other’s crazy ideas a little more seriously than fields limited to experts. In the long run, that openness — and especially that welcoming — is what keeps the Web diverse.
Have your own stories about the success (or failure) of cross-pollination? Let us know in the comments or through Twitter (@simonstl)!
Photo by Berit Watkin on Flickr. Used under a Creative Commons License. This post is part of our ongoing exploration into cross-pollinating communities in the Web space.