What Three Decades of Publishing Programs Teaches Us
There's a game I play on the web—maybe you play it too. When I visit a new site, I try to guess what platform it was built on. Is there a widget in the upper-right corner to change the font size? That's an easy one—it's Joomla. A blog-like format with a list of archived posts by month in the right column? WordPress. I then check my guesses with the browser plug-in Wappalyzer (which is, by the way, a site built on Drupal).
Drupal's incredible flexibility allows sites to escape its tell-tale signs: That's why the game-library site Darkadia.com looks and acts nothing like Recovery.gov. But frankly, those are exceptions. The vast majority of Drupal sites look damn similar, and it's because the tools that could let Drupal designers exploit that flexibility are just too hard to use.
Despite Drupal's success, its design capabilities are still about twenty years behind those of desktop publishing tools, and ten behind those of HTML editors. It's worth looking at how those fields developed to gain guidance for Drupal's eventual evolution as (I hope) a leader in easy online design.
Codes and Modes
Desktop publishing started the same way as web publishing: with lots and lots of code. Just as the first web designers hand-typed angle brackets around every tag, early users of TeX, troff, and WordStar needed a head full of obscure codes to format their pages.
TeX, troff, and WordStar aren't considered part of the desktop publishing (DTP) revolution: That term didn't appear until 1984 and the advent of WYSIWYG design on the Macintosh. And yet Drupal design today is no more mature than TeX, troff, or WordStar were, in that you need to know codes—the arcana of CSS and PHP—to make simple design changes.
The first true DTP programs had other frustrating limitations. Most notable was the concept of modes: You designed in a mode that showed graphics as outlines or gray boxes, then previewed the work in a second mode. (Some programs also had separate modes for entering text.) While that seems primitive to modern designers, it's exactly what Drupalists face when designing with Panels.
Further, early versions of the DTP software QuarkXPress forced designs into a mother-daughter pattern. You first created a box (mother) that represented the page, then created boxes (daughters) inside it to contain pieces of content, then optionally created boxes inside those boxes, ad infinitum. A daughter box had to remain inside its mother—you couldn't freely drag it out, as if the mother was in a perpetual state of pregnancy. And overlapping boxes were not possible.
That is where Drupal stands today. Blocks have to be within predefined regions; they can't straddle two regions or be placed in arbitrary locations on the page. While that model enforces design consistency—and there are ways to get around it—Drupal stubbornly frustrates designers' yearnings for an unfenced field.
Toward Drag-and-drop Web Design
Flash back a few years: it’s 1993, and Wired Magazine introduces the world of electronic communications to America via its coffee tables; 1994, and the first popular web browser (Mosaic) drives website creation above the 1,000 mark; a year later, America Online gives its million members web access and Netscape Communications' stock offering proves there is money to be made in the internet.
The web's promise of rapid growth stimulated development of authoring tools, among them AOLpress, HoTMetaL, Macromedia HomeSite, Vermeer/Microsoft FrontPage, and Claris Home Page. Like early versions of QuarkXPress—and today's Drupal—these programs rigidly limited where the designer could place elements.
But the relaunch of one such program showed the future of web layout. The year was 1996. The product was GoLive, from an unknown German company with the unfortunate name of Gonet, and it was terrible. I was a reviews editor for MacWEEK at the time; I think we gave it a highly critical 2/5 rating and I bid the product good riddance.
Then, less than a year later, the company came back with a reworked version called GoLive CyberStudio that allowed designers to put elements anywhere on a page. Its clever use of HTML tables and transparent .gif graphics was pretty nonstandard, and the pages didn't work well in some browsers. But the die was cast, and soon freeform layout was a standard feature of all web layout programs. (The product was later sold to Adobe, which abandoned it in favor of Dreamweaver.)
Making Drupal Do That
It is tempting to dismiss the histories of print and web design tools as irrelevant to Drupal. For one thing, those products faced simpler output demands: They only needed to deliver standards-compliant PostScript or HTML. Drupal also has to produce exchange formats (RSS), descriptive strings (RDF), and so on. Drupal pages can contain interactive elements, and must function equally well on cell phones, audio-only interfaces, and standard screens.
But those challenges don't affect the essential problem: making Drupal design more flexible and easier to work with. Fortunately, several projects have started to take on the task in interesting ways. (See sidebar.) Will such add-ons alone be enough to bring Drupal up to par? Possibly—if one eventually provides a complete solution which is then integrated with Drupal core.
A more likely (and long-sighted) scenario is that Drupal's concept of display will have to fundamentally change from one of fenced-in block regions and node content to something more freeform. Three of Drupal 8's initiatives could potentially address that enormous challenge: the Design for Core, HTML5, and Mobile initiatives.
I don't think that so grand a vision will be possible for Drupal 8. But by the time we start actively working on Drupal 9, we'll have gained experience from such modules as Panels and Sweaver and Skinr; we'll know what works best; and we'll have the structure in place to make it happen.
In any case the web will keep moving forward and Drupal will no doubt continue to implement catch-up features. But in design, it has the opportunity to innovate—to change the look and feel of tomorrow's web. In turn, those changes could affect the entire field of human communications, as desktop and HTML publishing did before it. The stakes are high. As media critic Marshall McLuhan put it: "We shape our tools and thereafter our tools shape us."
Code-free Tools that Change the Design Game
While none of these tools gives Drupal the layout power of a 1987 DTP program (or a 1997 web program), they all give designers new abilities—without the need to code.
(Semi-)WYSIWYG, full-page design tools. These are essentially CSS editors with a point-and-click interface and minor interaction with the theme's underlying PHP templates.
Alternate block systems. Panels essentially allows you to define any part of the content area as a block region—and then put any kind of content in that region. (Panels Everywhere extends that model to the entire page.) It holds a lot of promise for Drupal layout, but its interface is highly modal.
Extensions to display settings. These tools give designers easy access to settings formerly only available to programmers. None has an "in-place" interface—you have to make changes on an administration screen, then go back to your main site to see the effects.