PINGV Creative Blog Feed

HTML5 + RDFa = time to get rid of that 20th century furniture

Laura Scott — Tue, 24 Aug 2010 03:20:33 +0000

We're entering a new era of the web. To the ignorant masses, this transition will go largely unnoticed; they'll enjoy increased usability and convenience, with more robust functionality and more relevant data at hand. And they'll mostly just take it for granted.

However, for web designers, front-end developers and data system programmers, we have a lot of work to do.

Why HTML5?

Why indeed? As someone who's worked almost exclusively with Drupal since 2004, my nose has been pretty much in xhtml 1.1. Back then, moving to xhtml took some learning and patience on my part, having played with basic HTML since 1995. Now xhtml feels like the familiar friend and HTML the ugly cousin.

But then I started really looking at HTML5. And the more I am learning about it, the more I am appreciating how HTML5 looks to be a real game-changer.

DOMinate the web

Most of the buzz you see online about HTML5 focuses on the particulars — with the plurality of coverage over how HTML5's media tags stand to push most uses of Flash out to pasture. And that's certainly big.

However, there's something more fundamental in the change HTML5 is bringing to the web. I quote from Introducing HTML5 (Voices That Matter), by Bruce Lawson and Remy Sharp:

Many of our current methods of developing sites and applications rely on undocumented (or at least unspecified) features incorporated into browsers over time. For example, XMLHttp-Request (XHR) powers untold numbers of Ajax-driven sites. It was invented by Microsoft, and subsequently reverse engineered and incorporated into all other browsers, but had never been specified as a standard…. So one of the first tasks of HTML5 was to document the undocumented, in order to increase interoperability by leaving less to guesswork for web authors and implementors of browser.

This is big in itself. But it's not even the biggest thing, imho.

It was also necessary to unambiguously define how browsers and other user agents should deal with invalid markup…. The barrier to entry to publishing on the Web was democratically low, but each browser was free to decide how to render bad code. Something as simple as <b><i>Hello mum!</b></i> (note the mismatched closing tags) produces different DOMs in different browsers. Different DOMs can cause the same CSS to have a completely different rendering, and they can make writing JavaScript that runs across browsers much harder than it need be….

…HTML5 specifies new DOM APIs for drag and drop, server-sent events, drawing, video, and the like. These new interfaces that HTML pages expose to JavaScript via objects in the DOM make it easier to write such applications using tightly specified standards rather than barely documented hacks.

In other words, by clarifying specifics — especially in error handling — HTML5 stands to open the doors for much more efficient and effective JavaScript, heralding a new era for robust interactivity with dynamic interfaces and rich user experiences that would be too heavy and difficult, or impossible, to implement in xhtml or HTML4.

Suddenly that existing markup you have is starting to look kind of musty.

With new language comes new ways of thinking

The other thing to consider is how the web, and the nature of websites themselves, will change as the collective creativity of web designers worldwide starts to not just understand the syntax of HTML5 but also grok on an intuitive, subconscious level how websites can really let go of being collections of pages and embrace their web application natures.

There's a lot of old conventional thinking that is suddenly up for question. For example, while a website as a "navigation menu," an application may instead have a "toolbar": Does that change how you think about those links at the top of your page? People may be less interested in browsing, more interested in searching: Does that affect the role the search form plays in your interface layout?

Of course, for those of us who've been working building software-driven sites (you know, the "Web 2.0" things), this kind of thinking may have been percolating for a while.

Hopefully we'll also have learned the lessons taught by the untold numbers of Flash website designers, who gave us splash pages, annoying, gratuitous motion effects (with obnoxious sound effects), and user interfaces more focused on dazzling the user with the creator's cleverness rather than on serving the user with an interface that serves the user's needs. Here's hoping that HTML5 does not bring us into a new age of craptastic blinky poppy wooshy buzzy design.

HTML5 and Drupal

The Manifesto: http://groups.drupal.org/node/82664
HTML5 Tools module: Module: http://drupal.org/project/html5_tools
A base theme: http://drupal.org/project/html5_base
Another effort: http://drupal.org/project/boron
And http://drupal.org/project/html5
The community discussion: http://groups.drupal.org/html5 & in IRC at #drupal-html5

This is a lively and ongoing process that, so far, has ~~few allies — mostly I think because of the relative obscurity of HTML5 and the design affordances it brings in relation to the world of PHP/Drupal developers. Hopefully that's changing~~ a small but rapidly growing core of themers and developers interested in making this happen, especially in the past few days. Very exciting.

Wither RDFa?

The other side of this revolutionary coin (how many metaphors can I mix into this post?) is the growth and real-world application of RDFa.

In case you didn't know it, RDFa is already here. Google is consuming it where it finds it, using it to generate more accurate and relevant search results. Best Buy is now famous for having enjoyed a 30% increase in sales since incorporating RDFa into their online shopping site.

Robots speaking in complete sentences

That's the net effect of RDFa. You see, currently hyperlinks, to robots, are analagous mystery meat navigation. To the human reader, the nature and location of a hyperlink may make total sense in context — even the mouse-over reveal of the hyperlink URL can yield meaning to us cerebral bipeds. But all a plain hyperlink says to a robot is "follow me." The robot doesn't know who made the link (or the destination site), what the destination is, why the link is there — just where the link is going, and that only by its URL.

RDFa changes that by providing syntax, often abbreviated and/or abetted by libraries such as Dublin Core, to add meaning to the link.

Excuse me, did I say something?

One event happening (almost certainly) this year that could make for some very interesting RDFa developments will be the launch of Drupal 7. Historically, the Drupal user base, community and number of downloads have doubled with each major release of Drupal. And there are a number of factors that suggest that Drupal 7 will be no exception.

What's interesting about this is that Drupal 7 core implements RDFa. This means there are going to be umpteen oodles of websites and web apps out there talking RDFa — and, for most of them, without understanding the language. The amateurs are going to be joining the RDFa party. And that could become cacophonous.

This can mean an RDFa-enabled Tower of Babel. And that prospect has prompted some skeptics to argue against the semantic web. As they see it, we should make robots understand how we make the web, rather than try to remake the web so robots understand. It's an interesting topic, and I recommend Kate Ray's short video on the subject:

[Source: Web 3.0, on Vimeo

From where I sit, perhaps the ideal falls somewhere in a combination? There's no question that Open Data, for example, benefits from semantics. But on the other hand, it would be great to develop parsers that can interpret in existing contexts the underlying semantics of existing content, much like HTML5 provides for the kinds of sloppy markup errors that happen in the web (especially with user-generated content).

Nevertheless, it's hard to dismiss the potential of RDFa when there are be thousands of web developers bringing their creativity and initiative to the rave. For example, in Drupal, one project with interesting potential is AutoRDF, a Google Summer of Code project by Tushar Mahajan, that promises to "automatically tag node content. It will find important words and patterns in a node to tag important keyword and Rdf'ing it. It will build a taxonomy tree."

The SPARQLy Views

The fact that Drupal 7 will play a role in this democratized explosion of RDFa-related endeavors is itself very exciting. And that's not just in the RDFa structure on publishing content, but also in reaching out and pulling in structured RDFa data from elsewhere.

In other words, the web can be like one big website. Jane's site could query Joe's site's data without having any direct access to Joe's database.

One example is the a module (still in development) that leverages the power and flexibility of the Views module to consume and present SPARQL query data.

The SPARQL Views module by Lin Clark will likely be a first introduction for many to the kinds of wondrous things RDFa on the web can enable. Its drag-and-drop query builder will empower people with ability to plug SPARQL queries into Views for customized presentation. Awesome! (Disclosure: I am a Google Summer of Code mentor on this project, so feel free to take my enthusiasm with a grain of salt.)

I want my SEO

Ultimately a — if not the — big convincer for adoption of RDFa will be its effectiveness in getting content noticed. Years ago, Drupal seemed natively and naturally to beat other CMSs when it came to SEO. Drupal sites rose quickly to the top. Will it happen again with Drupal 7 and RDFa? We assume so, but the proof is in the results, and those are still many weeks, perhaps months, away yet.

But imagine what the web will be like when so many sites can be queried and polled from the outside. Information is power, shared information is empowering. When the World Wide Web becomes the World Wide Database, watch out. We'll look back at 2010 as the quaint time of horse and buggy.

Out with the old, in with the new

What this all means is that change is upon us. And all of us web designers, programmers, database administrators, information architects, strategists, and front-end developers need to get busy. We have some learning to do. Some new skills to perfect. Some new thinking to explore. Some new best practices to embrace.

The end user may not really notice as these improvements in user experience roll out. But the end user will notice if you're not rolling with these improvements. Just as a "Web 1.0" site from 1999 stands out to us today as an archaic relic, today's "Web 2.0" sites are going to feel very outdated a few years from now. And just as sites with table-based layouts or built in Flash can make for frustrating user experiences (or out and out inaccessibility) on today's delivery platforms like handhelds and tablets, websites built without the front-end affordances made possible with HTML5 may seem limited to end users, and websites without semantic metadata layers on their content may come off as rather opaque.

As a Drupal aficionado, I'm delighted to have Drupal 7 leading the way on RDFa. However, Drupal is still deeply entrenched in xhtml. The HTML5 phenomenon, while a long time coming, really sparked to life only in the last year — too late to be embraced and incorporated into Drupal 7's core.

But perhaps that's a good thing, because things can happen rapidly in Drupal contrib, and HTML5 is still evolving. So there's a new HTML5 working group on g.d.o to drive towards an HTML5 module (to transform all the markup of Drupal into HTML5-valid code) and an HTML5 base theme.

It's all very exciting. We are in interesting times. Don't stand still. The Drop is always moving.

For further reading:

If you're an Amazon shopper, here's a handy link to Lawson and Sharp's excellent book:

Floater Theme to get away from columns

Laura Scott — Sun, 25 Jul 2010 22:15:04 +0000

As a part of wanting to throw out some of the outdated design furniture of the 20th century, I created a new theme to simply float content elements against each other.

Contributed in a stripped-down version to the Drupal community as the Floater Theme, this theme is about embracing the various kinds of devices and resolutions which people use to access the web. After all, your site could be viewed on a little crap handheld or a big screen 2550 pixels wide. And in theory you want everyone to be able to see what you're offering.

This screenshot is from the soon-to-be-launched LauraScott.net

The first Alpha 1 release of this theme for Drupal 7 has just a few basics:

The main content area is a fixed width.
Blocks in the "right sidebar" (as Drupal 7 currently calls the region) are of fixed width and height, so they float cleanly and line up well with the content.
Narrower-resolution screens get an alternative stacked layout of all the content.
Generic styling (assuming the primary use case will be using this theme only as a base theme).

Once Drupal 7 stabilizes into a Release Candidate, I plan to step into the regions definitions and simplify the regions in this theme. I've generally stayed away from all that for now simply because there's still too much change happening in Drupal 7.

I've been working with Drupal nearly six years now, designed and created dozens of Drupal themes, helped people with theming questions in IRC, and presented on Drupal theming at DrupalCons, but only now have I risen to the CVS challenge and contributed a theme (or any project). CVS is that notorious bugaboo (and barrier to entry) for many designers, but even so I don't know why CVS daunted me so much. I used Subversion (which is quite similar) for years. At PINGV we use Git for versioning. Even so, I was tempted to just wait until the Drupal community gets onto the Git footing later this year.

But today I decided I'd waited long enough. Too long. So there it is. I hope people like the theme. At this point, I have no firm plans on where to take it in terms of features and characteristics. I'm open to ideas.

What's your brand? Do you have a brand? (Do you want one?)

Laura Scott — Tue, 06 Jul 2010 13:01:27 +0000

In The Rhetoric of Fiction, the late Wayne C. Booth discusses a concept of the "implied author."

The implied author, according to Booth, is a "second self" from the actual historical person who wrote the work in question, not the flesh-and-blood being but a hypothetical entity that includes "not only the extractable meanings [of the text] but also the moral and emotional content of each bit of action and suffering of all the characters" (73). To rely solely on extratextual sources that will verify an author’s "intention" is at least problematic, if not a "fallacy." The implied author, though, is a construct prompted by the text itself. The implied author, Booth asserts, is responsible for the "norms" and "values" that seem to be expressed in the work but cannot necessarily be attributed to a narrator and should not be attributed to the historical author.

From "Every Picture Tells A Story: Agency And Narration In Film," Panel: Movies as Paradigmatic Narratives. Modern Language Association Annual Conference, Washington, D.C., December, 2000

In other words, you can't know the "real" author of a book by reading the text. The implied author is the author as perceived by the reader, the audience, based upon perceptions of the text. The implied author is not the same as the actual author. Quite often that's deliberate. But it's also a matter of perceptions, and how imperfect the text can be in communicating intended meaning. All you can do is extrapolate an "implied" author: the person who seems to be who wrote the text. The text is the lens, and who you see as its author is not the same person as the actual author, it's a reflection. A projection.

This concept translates to branding quite easily.

Brand Intentions vs. Brand Perceptions

When we see a disaster like the broken underwater oil well in the Gulf of Mexico, consider that to be "the text." Whether you believe BP or Halliburton or the government is responsible, your perspective of those entities is guided — defined, in fact — by their outward appearances to you. Such views may be closely aligned with the true characters of those entities, or you may be way off. You can't know. We can't know. All we can go by is what we see. The actions. The text. –And third-party descriptions (by the media, friends, persons with axes to grind) of the text. The brand ends up being defined by perceptions, not simply the brand-maker's intentions.

Flip that around now.

How misunderstood does an author feel when her book is interpreted in ways she never intended? Writers will often blame the reader for misunderstanding a text. Samuel Beckett wryly commented, "No pun where none intended." This consummate self-reflexive author who always seemed so aware of the implied author his texts projected would steadfastly refuse to explain his texts, yet seemed not to want to accept it when people took the wrong meaning.

But how can there be no pun where none intended? Whether intended or not, a pun is in the ear of the beholder. If there's a pun, and nobody's around to hear it, is there a pun after all?

And yet, and yet, Beckett's work was about how author and implied author were rarely, if ever, the same. Take the opening lines of Worstward Ho:

On. Say on. Be said on. Somehow on. Till nohow on. Said nohow on.

Say for be said. Missaid. From now say for missaid.

To be said. To be missaid. Your intentions are for naught.

Let's take this back to brands. No matter what a company may intend, what people react to is the company they see through an imperfect lens, colored by their biases, attitudes, expectations, prejudices, politics.... What they react to ends up defining the brand. It ends up being the brand.

The brand is the implied company.

Personal Brands, Personal Intentions

On BlogHer recently, Maureen Johnson declared in her Manifesto:

I am not a brand….

I am not saying that it is a bad or dishonest thing to try to sell your work. It is not. What I am saying is that I am tired of the rush to commodify everything, to turn everything into products, including people. I don’t want a brand, because a brand limits me. A brand says I will churn out the same thing over and over. Which I won’t, because I am weird.

But what Maureen is describing — this churning over and over — is not branding, this is factory work. Branding is not about being a factory. Branding is about being aware that you have an image, and that image may have little or nothing to do with who you really are. And if you have a reality out there where people don't know the real you, just this impression of you from your logo and/or ads and/or website and/or blog and/or tweets and/or news profile, guess what!

You have a brand. Or at least an implied you that is not your own real you.

Maureen's manifesto starts off:

The Internet is made of people. People matter. This includes you. Stop trying to sell everything about yourself to everyone. Don’t just hammer away and repeat and talk at people -— talk TO people. It’s organic.

I agree. But that is not a negation of branding.

But I will say that even the most seemingly transparent, honest, heart-opening writer ends up projecting an image that is only a facsimile of the actual person doing the writing.

Call it a brand.

Call it an implied author.

Call it an image.

A rose by any other name smells just as sweet. So let's cut the baloney.

(To be fair, Maureen's post seems to be, at least in part, a rebuttal to a woman who, as she describes her, could play straw-woman in any branding discussion — huckster, pushy, microphone hog.)

Brands have a way of happening whether you want them to or not. It's not about selling. It's about perception.
Fake Brands Image by Chuck Coker

Tara Hunt, in a blog post last year, takes a slightly different tack:

We talk about authenticity, but people rarely want to see the negative side of a person. When I’ve been truly honest – angry, sad, scared, belligerent, grumpy, negative, depressed or anxious (and I keep it under control, but I have terrible anxiety) – people get nervous. I lose followers. I get long emails from people asking me to stop being self-indulgent. I get messages from concerned friends saying, “Don’t you worry about damaging your brand?”

And that’s it. Do we want authenticity? Or do we want branding? One of the most memorable lines in a movie for me is from Magnolia, where Claudia says to Jim:

“I’ll tell you everything, and you tell me everything, and maybe we can get through all the piss and shit and lies that kill other people. ”

I love that line because I think it’s what we all want to do, but are afraid to do it. We love people who represent the ideal, the perfect, the imperfectly perfect, the happy, the successful, the amazing, positive, go-for-it, wa-hoo in life. And I’m not saying those people don’t exist. They just don’t exist as much as we think they exist because there are so many bloomin personal brands out there that are inspiring the crap out of us that we lose the fact that behind the scenes, they are probably falling apart now and then….

I don’t have a personal brand, I have a personality – complete with crazy moments and drunken nights, super highs and heartbreaking lows. And every single one of those moments define who I am. Now. Who are you? A personal brand or a personality?

Tara's awareness that the image we project, or even the image simply perceived by others, can be at odds with the real us, gets at part of what I'm saying. She rejects the word "brand," but is a "personality" as perceived by others really that much different? Especially when you consider that brands can have personality?

Of course we are more than our public persona. That's true for everyone — even companies … even BP.

But maybe the issue, then, is not about whether we have a "brand" but rather how authentic is our brand. How much does your "brand" — your public image, your persona, your personality as perceived by others — truly reflect who you really are?

And is that even the goal? Do we really want everyone to know about our phobias, our weaknesses, our cravings, our petty jealousies, our financial worries, our medical concerns, our family aggravations? If I know all about the fungus between your toes, do I now know the "real" you? Or does that fungus just distort my image of you? To you, that fungus may be a minor pain in the arse annoyance, but to me, if every time I see you I think about the fungus between your toes, am I now seeing the real you?

My point is that what you choose to project ends up influencing how people perceive you. And being more "honest" or "transparent" is not necessarily going to lead to people seeing the real you. Or liking you more. Or even understanding you better.

The Unnamable

When Samuel Beckett said, "No pun where none intended," he was in effect declaring that critical interpretations, or for that matter any reader's views, of his text were secondary to his own intentions. He was, in a way, trying to take charge of his image, his brand — even while he generally shunned publicity. For him, greater transparency in his life did not mean he would enjoy a truer public image. The uncontrollable nature of identity as perceived worked at the center of his writings. And if you'll forgive me one more quotation, Beckett touches on this theme in the opening paragraphs of The Unnamable:

I am not I.

Or: I am not the "I" you read here.

Doc Searls writes, in Brands are Bull, that brands are by definition non-human:

The man is not only the closest any golfer has ever come to walking robotics, but his whole golf persona has always been remarkably mechanical as well.

Turn a person into a brand [emphasis mine], and what do you get? Something incomplete at best, and fake at worst. Borrow that human brand to represent your company, and you take some risks. Your branded celebrity might actually be a fine human being. Or they might be a philandering scumbag. Either way, the brand is a paint job. It’s not real except in the commercial dimension, and only in a narrow way even there.

The only advertiser that has stuck with Tiger since the bimbo bombs started going off is another landmark brand: Nike. The latest Nike/Tiger ad features the golfer’s sad face, staring at the camera, while the voice of his dead father speaks. “I want to find out what your thinking was,” Earl Woods says.”I want to find out what your feelings are. And did you learn anything.” Well, one thing the rest of us learned was that Tiger was with one of his mistresses on the night he got word that his father had died.

To me, this only emphasizes that you can't always control your brand. Accenture and Nike did not turn Tiger Woods into a brand. Tiger Woods already was a brand. These two corporations simply tried to hitch their brands onto the shining image of Tiger's own brand. That they suffered when Tiger's brand crashed and burned is merely guilt by association.

Every professional athlete is a brand — not because they are selling something (even if they are), but because they have public images driven by media, surrounding hype, lockerroom talk, as well as their own actions, interviews, tweets, whatever.

And when you pull the scope back from the spotlight and turn it on "regular" folks, the same is true — not on the same level, but still true. We have reputations, grades in school, credit ratings, driving records, things people say about us, perceptions drawn from things we do (almost always taken devoid of a larger context). Don't call it a brand, call it an image, call it a reputation, call it buzz, call it karma — it's expressing the same thing.

We are not our image. Our image to others is not necessarily similar to who we really are. And if not, the problem may not be not enough transparency but perhaps the wrong transparency, or too much surrounding noise.

Or poor management of getting out your message, whatever it is, in business or in your personal life.

The Bigger Picture

All this is not to say that we should focus on brand at the exclusion of all else. There's no question that, in our culture, there seems to be a real obsession with brands. For example, in politics one could say the mainstream media have been focusing on political brands far too much, when you consider things like the press coverage of the recent national healthcare reform debate in Washington, which a recent Pew study found:

Fully 41% of health care coverage focused on the tactics and strategy of the debate while various reform proposals filled another 23%. But only 9% of the coverage focused on a core issue -- how our health care system currently functions, what works and what doesn't.

For which we can all collectively thank the press for focusing on brand battles rather than what the legislation was actually about. (How many of us understand that even now?)

No, focusing on brand is not the only thing.

But it's something to be aware of. Even if you don't want one.

Drupal Disruptive Open Source: Part I — From Brobdingnag to Lilliput

Katherine Lawrence — Mon, 05 Jul 2010 03:28:18 +0000

Is Drupal a Disruptive Technology?

Drupal's founder, Dries Buytaert, in his keynote at the 2010 San Francisco Drupalcon, asked the rhetorical question: Is Drupal a disruptive technology?

Product improves to serve more demanding markets. Image: Sun Blogs.

The term, "disruptive technology," was coined by Harvard Business School Professor Clayton Christensen and popularized in his best seller, "The Innovator's Dilemma." (ISBN 0-06-662069-4)

In its lowest terms, a disruptor enters a marketplace with an alternative technology and "kills" the leader(s).

But killing the market leader is not easy. The leader will defend its leadership position in the market. That strategy is called, simply, "defense."

Almost always leaders easily beat-back challengers because the leaders have the motivation and the resources — know-how, talent, organizations, capital reserves, and client relationships — which entrants must more or less replicate. The entrant must overcome what business schools call the barriers to entry.

Yet sometimes leaders are toppled. Just last year, the American auto industry collapsed. GM and Chrysler faced bankruptcy. Were American automobile manufactures leaders any longer?

Leaders

Who can rightfully be called a leader?

Ries & Trout, Marketing Warfare

In their classic book, Marketing Warfare, (updated and reprinted in 2006, ISBN 0-07-146082-9) co-authors Al Ries and Jack Trout observe,

We've never met a company that didn't consider itself a leader. But most companies base their leadership positions more on creative definitions than on market realities. Your company may be the leader "east of the Mississippi on Monday morning," but the customer doesn't care.

Companies don't create leaders—customers do.

Market leadership is not linked just to dollar volume, either.

Size, of course, is relative. The smallest automobile company (American Motors) is considerably larger than the largest shaving company (Gillette). Yet American Motors should fight a guerrilla war and Gillette should fight a defensive war.

What's more important than your own size is the size of your competition. The key to marketing warfare is to tailor your tactics to your competition, not to your own company …

… history teaches the power of a guerrilla movement. In business, too, a guerrilla has a reservoir of tactical advantages that allows the small company to flourish in the land of the giants.

So, there is hope for players, other than giants.

The Lay of the Land in Brobdingnag

Actually, the Ries-Trout model lays out four segments, each one relative to the other players in a specified market:

Defense — leader
Offense — challenger
Flanking — dark horse
Guerrilla — niche player

The guerrilla must not mimic the leader. Image: The Cinematic Intelligence Agency.

Christensen's disruptor, at least in the early stages, does not fit into the role of a leader (defense) nor challenger (offense). Rather, the disruptor better fits the definition of either a "guerrilla" or a "flanker." The advice Ries-Trout give each of these categories, respectively, is:

Guerrilla:

Find a segment of the market small enough to defend.

No matter how successful you become, never act like a leader.

Be prepared to bugout at a moment's notice.

Flanking:

A good flanking move must be made into an uncontested area.

Tactical surprise ought to be an important element of the plan.

The pursuit is as critical as the attack itself.

Strictly speaking, the Ries-Trout model is marketing focused — positioning, if you will — while the Christensen model is technological innovation focused. For example, the Ries-Trout analysis aptly applies to brand battles among beers, among colas, and among hamburgers; and while lite beer might be a "technological innovation" of sorts in the "beer wars," it is not epic in the way that transistors displaced vacuum tubes in the electronics industry. On the other hand, when it comes to handheld devices, the battle for the hearts and minds of consumers can be addressed by both models — brand and technology.

Flanking moves must be made into uncontested area. Image: Out on the Porch

With this in mind, let us look at Christensen's concept of a disruptive technology.

A disruptive technology provides a product or solution that is not quite good enough; it is a technology that enters the market at the low end where expectations are modest, or even non-existent — often competing against non-consumption.

An entire class of low-end electronic products came from Japan in the 1950s and 1960s. In 1950 the label, Made in Japan, was synonymous with poor quality. Thirty years later it meant cutting-edge — top quality. The crummy transistor radio that teens bought in the 1950s gave way to state-of-the-art transistor-based electronics in many fields — televisions, audio equipment, cameras, copiers, and cars.

Christensen points out that in the 1950s, transistor-based technology was on the "radar" of the big American electronics manufacturers. The leaders used vacuum tubes to run the electronic systems. The leaders knew transistors would eventually replace the vacuum tubes, but at the time the transistors were not powerful enough to run the large console televisions and console home entertainment systems.

In 1975 the head of General Electric research addressed Professor Richard Rosenbloom's "Management of Technological Innovation" class at the Harvard Business School. He was asked by students why GE had not developed computers. Computers would seem a "natural" for GE. In part the reason was that IBM accounted 25% of GE's vacuum tube business. GE wanted to profit from that business and did not wish to alienate IBM.

Nevertheless, the leaders in electronics, according to Christensen, invested the equivalent of at least $3 billion of today's dollars in transistor technology, hoping to make transistors good enough to run the console-sized systems.

The Japanese transistor radios were not created to compete with the consoles. They found a niche among teens who could listen to their kind of music on something they could afford. Transistor radio performance was not as good as the expensive upmarket consoles, but the consoles were largely controlled by grownups who usually would police what got played.

For the teens, essentially it was the transistor radio or nothing. The alternative was non-consumption.

The leaders in the market did make some transistor radios, but they largely left the market to Sony, and others, who targeted the low-end market, and in this way the entrants established a beachhead, from which they worked their way upmarket.

When the "not quite good enough" technology displaces the leader. Image: CTI Tek

Disruptive Technology is not a technology problem

Professor Christensen recounts that shortly after the Innovator's Dilemma was published, he gave a top level presentation to Intel management in which he introduced the concept of disruptive technology. It was Andy Grove who pondered briefly, then said that it was not the technology that was disruptive, but the marketing that was disruptive.

In another lecture, Professor Christensen observed, in the case of the vacuum tube manufacturers, that the electronics market leaders had framed transistors as a "technology problem" — i.e. as a technology that would replace the vacuum tube, outright.

As described above, the Japanese transistor product was not framed as a technology problem. Instead, it was sold for what it was — i.e. hence a marketing strategy.

Not-quite-good-enough technologies evolve. Images: Salon.com, Inside View from Ireland

In another example, in 2007-2008, Professor Christensen describes a very low-end, low-cost, solar technology developed at Hewlett-Packard (HP) that could barely run a light bulb. The idea for using it for a product first found acceptance in not-yet industrialized countries in locations that have no electricity or appliance that need electric power. Again, competing against non-consumption.

In 2010, the HP technology is being developed to provide solar power to wrist watches, and likely a host of other applications. The technology developed for the non-industrialized world finds a host of uses worldwide.

HP's thin-film solar technology is being used in small, undemanding applications, competing against non-consumption. Image: CNN.

Christensen gives example after example of technologies that mirror that model — technologies that entered down-market in undemanding applications — again, competing against non-consumption — and he traces how these entrants "killed" the leader(s) and ended up with the lion's share of the market. Inspired by a report by Michael Finley, here are a few other examples:

e-commerce. Amazon.com redefined books-selling and beyond.

Automotives. When Datsun entered the US market Detroit laughed. Today Lexus gets top dollar.

Modular computers. Dell started in a dorm room. Computers used to be large integrated systems. Today computer systems are assembled from interchangeable parts.

Handhelds. The Newton was an underpowered flop. Today iPod, iPhone, and iPad rule!

Internet telephony. Not good enough before, now VOIP providers such as Skype, are mainstream.

Twitter. Competing against non-consumption, Twitter has changed the shape of how we communicate. So has YouTube, for that matter.

Drupal

So to Dries' question: Does Open Source, especially Drupal, represent a disruptive technology? Looking to the bottom of the "food chain," is Drupal at least a guerrilla?

Recall, again, the hallmarks of the guerrilla:

Find a segment of the market small enough to defend.

No matter how successful you become, never act like a leader.

Be prepared to bugout at a moment's notice.

Find a segment of the market small enough to defend.

Drupal became popular in a small market that was largely invisible. In 2006, when my firm at the time approached Rackspace to provide Drupal hosting for one of our enterprise-level clients, Rackspace said that we were the first firm to approach them for Drupal hosting. A year later, when that same client went looking for venture capital, VC-financing, the folks on Sand Hill Road told the client that they should switch out of Drupal because Drupal was "limited," "brittle," "does not scale well," "rinky-dink," "too new," "too small" "unproven," and "open source."

Ironical though it might be, this dismissal by the VCs meant that the technology was coming in under the radar, so to speak. Like the Borg in Star Trek who ignore "irrelevant" intruders on their cube, Drupal was too small to be assimilated.

Thus, if Drupal was a guerrilla, it met the first criterion.

No matter how successful you become, never act like a leader.

By this, Ries-Trout, seems to mean that the guerrilla should not follow the business model of the leader, nor is it advisable to structure the organization in the same way. Be a guerrilla, not a gorilla.

We would have won the war in Vietnam if we could have persuaded the Viet Cong to send their officers to West Point to learn how to fight like we do.

Successful guerrillas operate with a different organization and a different timetable.

Be prepared to bugout at a moment's notice.

However, it does not say you have to bugout.

Disruptor as flanker

I suggest Drupal has started to move from a guerrilla strategy to the flanking strategy.

Christensen's classic case of the steel minimills is the story of the flanking strategy where the guerrilla took the battle to the next step.

Briefly: In 1975 minimills made cheap, low profit, low-spec steel, rebar — steel re-enforcing which is buried in concrete. No one expected that the minimills would ever be able to manufacture anything but rebar. The giant integrated mills produced high profit, high quality steel, whose properties were imparted in the rolling process. Since the minimills did not have a rolling process, they were shut out of the profitable sheet steel at the upper end of the market. The integrated mills were not worried.

But then, over a period of about 15 years, the minimills continued to make profit-driven technological leaps and they moved from making rebar to making bars and rods, to making structural steel, and finally to making sheet steel. At every stage, the integrated steel manufacturers abandoned the less profitable lines to the minimills and focused on the higher tech, higher margin business. When in the last stage, the minimills figured out how to make sheet steel, the barbarians were indeed at the gate, because the minimill technology was more cost efficient. There was nowhere for the integrated mills to go. The minimills had moved from being flankers to being challengers, to being leaders. The integrated mills were beaten at their own strength. Christensen tells us that "Bethlehem [Steel] closed its last structural beam plant in 1995, leaving the field to the minimills." p. 105.

Most of Christensen's disruptors more or less fit the Ries-Trout model of the flanker.

In Christensen's case studies, he deals largely with organized firms and corporations that pursue coordinated marketing strategies. In the minimill case the big minimill companies Nucor and Chaparral pursued concerted strategies to go after high profit market niches.

Nevertheless, Christensen points out that the integrated steel makers became very efficient.

USX, for example, improved the efficiency of its steel making operations from more than nine labor-hours per ton of steel produced in 1980 to just under three hours per ton in 1991. It accomplished this by ferociously attacking the size of its workforce, paring it from more than 93,000 in 1980 to fewer than 23,000 in 1991, and by investing more than $2 billion in modernizing its plant and equipment.

One logical strategy for the integrated mills was to abandon low-margin segments such as rebar. Professor Christensen tells us:

[the rebar] market was the least attractive of those served by established steel makers. And not only were margins low, but customers were the least loyal: They would switch suppliers at will, dealing with whoever offered the lowest price. The integrated steel makers were almost relieved to be rid of the rebar business....

...The minimills, however, saw the rebar market quite differently. They had very different cost structures than those of the integrated mills: little depreciation and no research and development costs, low sales expenses (mostly telephone bills), and minimal general managerial overhead. They could sell by telephone virtually all the steel they could make — and sell it profitably.

Has Drupal moved from being a guerrilla to being a flanker?

Guerrilla or flanker, the Drupal shops share a lot of similarities with the minimills as described above:

little depreciation.
no research and development costs.
low sales expenses (mostly telephone bills).
and minimal general managerial overhead.

With Drupal accounting for one percent of websites, and the high profile sites being too numerous to mention, Drupal can rightly be classified as a flanking technology, possibly more.

Open source disruptor Linux takes on leader, Microsoft. Image: Business Week.

CMS Wire in cooperation with Water & Stone published the "2009 Open Source CMS Market Share" report, which runs just under 100 pages. The report says that Open Source CMS is dominated by Joomla!, WordPress, and Drupal.

Dries in his DCSF keynote reported that 10% of all websites are WordPress to Drupal's 1%.

Yet, is this the ultimate market? Are these top three players just top players in the "rebar" market?

ECM, Enterprise Content Management

At the beginning of this essay, Ries and Trout were quoted, "we've never met a company that didn't consider itself a leader."

Open source is not the driving factor in the enterprise-level marketplace, known as ECM, Enterprise Content Management.

This market, with $4 Billion of annual revenue, is dominated by a few key players who are acquiring one another through a series of nine- to ten-figure buy-outs. For example IBM paid $1.6 Billion for FileNet. Documentum fetched $1.7 Billion when EMC2 added them to the corporate family. Just recently Open Text gobbled up Vignette to the tune of $321 Million.

ECM Players compete in a $4 Billion market. Image: CMS Watch.

A recent press release from Open Texts describes the firm as earning just under $180M annually, with a customer-base in the tens of thousands, installations approaching 50,000, and millions of seats. Their staff is over 2,000 strong serving over a hundred countries.

Coming Full Circle Until Next Time

To answer Dries' original question, is Drupal a disruptor? gets down to who it is that is being disrupted. If Drupal sees itself as the market leader against other open source CMS, then Drupal is not. Yet if the ECM players are in the lead, Drupal would be a disruptor.

Forrester Research calls the ECMs "integrated players" Their clients are large corporations with heavy database and process management needs — clients who want the "whole solution," or "end-to-end."

And yet, as the worldwide web continues to evolve, data handling and storage becomes a less erudite field. When the web itself becomes the "whole solution," the competitive advantage that the ECMs currently have will be less of an advantage.

We will look in detail at these players and modularity in the upcoming essays.

KIT: Best Practices for Making Drupal Features

Laura Scott — Mon, 07 Jun 2010 15:12:25 +0000

So you're building a Drupal Feature! Woohoo! Okay, so…. What to include? What to leave out? How to structure the thing so it doesn't conflict with other Features? How to avoid known issues? Where to start?

When, in theory at least, you can make an entire site into one big Feature, these questions become extremely important.

If you're using Features simply to help facilitate your own site-building workflows, this may be something you can pretty much ignore. When dealing with Features you've made for yourself, you may remember your thinking, you may follow your own logic, you may be using Features as a blobby deployment system for all kinds of stuff glommed together. Whatever works. It's all good.

But that approach won't fly with publicly shared Features. In fact, it won't work too well for teams either, probably. Without best practices, clearly laid out and understood by all, Features can trend towards amorphous nightmares. Features might conflict with each other, undoing each other. Improperly utilized, Features can easily become a nightmare that slows you down, undoes your hard work, and leaves you ready to scream and throw your computer out the window.

Enter KIT

The KIT Specification clearly lays out requirements for building clean, discrete Features.

This document provides recommendations and requirements for Drupal features to ensure the interoperability of features between different distributions and prevent conflicts between features themselves and between a compliant feature and a distribution….

–KIT Feature Specification 1.0-draft

The specification goes through terminology, namespaces, inclusion of user roles and permissions (and what not to include), working with variables, paths and menu items, blocks and dependencies.

Not all Features have to be KIT compliant, of course. But having a good, clear specification for self-contained Features that mostly likely will not break other things in your site is a great thing.

If this topic interests you, be sure to visit the KIT issue queue, where there are several discussions on clarifying, adjusting and improving the KIT spec. Good stuff is happening.

Announcing our Feature server: downloads.pingv.com

Laura Scott — Sun, 06 Jun 2010 22:49:39 +0000

Over the weekend we launched a Feature server at http://downloads.pingv.com.

Currently it has but one simple Feature: an initial release of "Photo Essay," for posting images inline in the text of an essay. We hope some people may find it useful. Or informative. Or inspiring to go make their own Features.

We see a bright future for Features. As strategists and designers, we embrace systems and practices that increase the speed and efficiency of development. Features are a great way for people to be able to mix and match components to build sites to suit their needs, without having to install and configure everything by hand, and without needing to embrace a whole website strategy inherent in a full-blown Distribution.

This is a new area of growth and rapid change in the Drupal community. It's very exciting.

So far it seems like most of the Features that people have released are designed to serve use cases more on the advanced, complicated side — with a goodly proportion of those targeted specifically for installation in Open Atrium, which in many ways has been the proof of concept for Features in the first place.

We feel there's room for Features solving more basic and common use cases, to encourage more site builders to try them out and (hopefully) get hooked on the concept. Features may seem to some like stuff for experts to dabble with, but Features are for everyone. Features can make things easier.

Features are fully formed, preconfigured functionality that can be "plugged in" to Drupal.

We had wanted to do this server months ago — soon after starting up the new company — but the best laid plans of mice and cats and all that…. Anyway, when we finally got around to it, the handy Feature Server profile shared by Development Seed made the setup easy. We also ended up building the site on Pantheon using a sweet Linode StackScript written by Justin Ellison, which worked really well. Yes, Pantheon is total overkill for a small Features server, but it was there, so what the heck! When we have more than one Feature, maybe it will make sense to let loose the SOLR search.

Other Feature Servers

There are a few Feature servers out there, but so far there doesn't appear to be any comprehensive list anywhere, and as far as I know no p2p way for them to discover each other.

Here are some directories I've found:

Directory of Public Features Servers: A wiki page with links to servers and projects, posted on Groups.Drupal.org in the Packaging & Distributions group.
Community features: A wiki in the Open Atrium Community site, with links to many features for Open Atrium.
community.featureservers.org: A community Features server and directory hosted by Miguel "mig5" Jacq.

Are there other resources? Please share them in comments and I'll update this post.

The State of Drupal: Building the Future

Laura Scott — Thu, 03 Jun 2010 05:02:54 +0000

Half dozen of the other

Has it been six years already? I'm astounded. Drupal in 2004 was really really really different. It's been quite a ride. And it's getting better and more fun and more interesting with every passing moment. And that's because of the stellar contributions of the dozens of core developers on Drupal 7 (and 6 and 5 and 4.7 and 4.6 and 4.5), the leadership of people and companies in the Drupal community, and all the people who contribute back — whether it's out of the notion of "giving back" or out of the self-interest of inviting the rest of the community to help them on their project.

Always kind of an open secret living in the obscurity of web geekdom, Drupal has had some heady mainstream buzz these past few months. As adoption of Drupal continues to increase, and open source gains "acceptance" [read: understanding] in corporate, educational and governmental realms, this trend has some legs, I think. Expect the buzz to bump up louder a notch when Drupal 7 comes out in the next few weeks (or so). Back in 2006, Dries Buytaert noted that the Drupal community doubles with every major release. Will the community double again this year? I guess we'll find out soon enough.

But there are a few really good reasons that it will. Here are a few of them.

Not a conventional convention (or maybe more conventional)?

DrupalCon this spring, the biggest Drupal event ever (so far), simply rocked. 3000 attendees, a Tim O'Reilly keynote, White House-generated buzz, trainings, code sprints....

The State of Drupal keynote that Dries Buytaert gives at every DrupalCon this time focused on Drupal's role in CMS market disruptions ... and RDFa. Where is the web going? Will Drupal lead the way?

DrupalCons have changed quite a bit since my first "major" Drupal event: the 300-person OSCMS gathering back in 2007. Things have gotten pretty sharp, corporate and professional in the Drupal conference world. For some, "corporate" and "professional" are dirty words. But I feel that this professionalism in the Drupal ranks has helped Drupal disrupt some dominant players in the enterprise web market.

Without a doubt, Drupal is changing the web world. And it's happening ... openly.

Profile Tracings

From the kind of swiss-army-knife-like hosted Drupal services like Buzzr and Drupal Gardens to the extremely specialized distributions like Open Publish and Managing News, Drupal is being packaged in new ways, offering new affordances for target markets.

The real power, though, is in Installation Profiles, which are like coded, self-cooking recipes for fully realized Drupal sites.

Combined with Drush Make, which can go and get various modules, themes and libraries from a variety of sources (not just Drupal.org), Drupal Installation Profiles can empower site builders to create complex, configured sites in minutes. The challenge is not in using Profiles for site building: it's in creating the Profiles in the first place. It takes hand coding. There have been some "profile builder" projects spun up here and there, but none seems to have traction today.

Which is why distributions, which already contain all the modules needed, can hold such appeal. (Of course, many distributions are installed and configured via an Installation Profile.)

When I first got into Drupal in 2004, CivicSpace was a popular Drupal distribution designed primarily for non-profit communities. While it rocked if it already did what you wanted, I ultimately grew tired of the large integrated nature of maintaining a distributed version of Drupal plus modules. Inevitably the distribution lagged behind the various module updates and even security releases from the Drupal community, leaving me with the question, "Do I go ahead and update the modules myself? Should I wait for the next full release of the distribution?" As a designer and site builder, I ended up moving away from dabbling in CivicSpace, preferring to work with Drupal a la carte. It wasn't because I disliked CivicSpace; rather I preferred the flexibility of solving my own use cases through my own module selections. But the experience left me with this caveat: a distribution is only as good as its maintained state. It can be awfully difficult to keep up with the Drupal community. So I always recommend caution and consideration before adopting a distribution for a site. [See Dries' thoughts on this from 2006.]

Nevertheless the power of Profiles is real. And the number of Installation Profiles is growing. And Drupal.org can now build Installation Profiles into distributions automatically. Despite having been around since Drupal 5, this is a new frontier for Drupal. Expect this to go places.

And go there openly.

Features, Spaces … Chaos in a Kit

All the amazing site administration power you have in Drupal means that a lot of what makes your Drupal-powered site do what it does is not written in code but stored in the database. And that means it can be very hard to deploy a set of site functionality from one server to another.

Features changes all of that by providing a way to write configuration settings in various Drupal modules into one custom-generated "feature" module that can be distributed as code.

A feature is a Drupal module that provides a collection of Drupal entities which taken together satisfy a certain use case. A feature module differs from a standard Drupal module in several ways:

- A feature is built to target one or more use cases - concrete, task-specific functionality - not address a general problem space.
- The bulk of a feature's work is to provide exported configuration, either in the form of exportables or scripted configuration of components.
- A feature provides no API of its own. Any custom code and hooks it may implement are targeted at addressing user stories.

—KIT Feature Specification 1.0

What does this mean? It means, ultimately, the ability to install new features feature by feature, rather than having to install and configure several modules for each feature you want.

The advent of Features has brought about a nascent scattered network of "features servers" hosted here and there. What's needed is some kind of peer-to-peer way to make these findable. Meanwhile there are manually compiled attempts here and there.

It's a new way of sharing in the Drupal community. So expect this, too, to go places. And go there openly.

Build in a Drush

What can I say? Drush is for everyone. This command line tool (don't look way, you designers) saves a ton of time in basic site-building chore of downloading and installing modules. But really that's just the start. Drush (Drupal shell) affords new power in streamlining the Drupal development process, from helping to make (as in Drush Make … okay, sorry) those Features and Installation Profiles to updating modules and even deploying them on remote servers.

If you can type, you can save time.

(My recent post (with video!) walks through the easy steps to install Drush on Mac.)

Of course the code is open sourced. (Thank you, Moshe Weitzman, Greg Anderson, Owen Barton, and Adrian Rossouw [who is truly in fact 1337]!)

Drops in Aegir's Sea

As someone who finds Drupal deployment chores something of a bore, Aegir is the bee's knees.

Point. Click. Voila! A new site is deployed! This isn't site building — it's site provisioning. And it's just about as easy as creating a node on a Drupal site. In fact, that's pretty much what you're doing, in a way, because Aegir itself is built in Drupal.

So when you have your Installation Profiles ready (or found the ones you want), with Drush and Drush Make at hand, Aegir provides the GUI for managing those deployments.

Of course the code is open sourced. (Thank you, Miguel Jacq, Antoine Beaupré, Lior Kesos and the 1337 Adrian (again)!)

As Fast as Mercury

Now I am going to talk about some Distributions.

The whole Pantheon Mercury stack is pretty impressive. I'm not quite sure which is what between Pantheon and Mercury, so I just call it Pantheon Mercury … or simply Pantheon for short.

What it is is what counts.

Pressflow, the distribution of Drupal with some nice code optimizations to improve performance across the board.
Memcached, the tried and true caching system to reduce strain on the database.
Varnish, the kick-ass http accelerator.
Solr, the awesome search engine, powered by the awesome Apache Lucene project, that gives us fuzzy search, faceted search, and generally just smarter search than what Drupal offers up by default.

Taking these all together: Can you say screaming performance? We've gone with Pantheon on just two smallish deployments so far, just to try it out.

And it.

Is.

Fast!

And you get SOLR search on top of all that. We love it so much, we're implementing it on two more sites, and Pressflow-sans-Pantheon for a third that is in a more rigid hosting environment.

Of course the code is open sourced. (Thank you, Four Kitchens (for Pressflow) and ChapterThree (for Pantheon)!)

Stay-in-the-community folks should know that Pressflow involves no database schema changes, so you're not really going down a forked path by opting for this Distribution. And the rest of Pantheon is just gravy. You can always take your site later and migrate it back to stock Drupal with no pain. —That is, if you wanted to.

But why would you?

Working in the Open Atrium

I've been a huge fan of Open Atrium since it came out last year. Now in a Beta-6 release, Open Atrium is rapidly becoming a richly featured project that can offer a serious alternative to Basecamp. We use it here for our client support desk, as well as basic ticket tracker and communications center.

Infrastructure is always a potential resource hog and time suck for a web company. The last thing we want to do is have to build and maintain our own homegrown Basecamp. And Basecamp is yet another paid service that, in the end, doesn't quite have the flexibility and power Open Atrium offers. Recently, Matt Butcher tweeted a link to his QueryPath script on GitHub that he used to migrate 3 years of Basecamp data into Open Atrium. It is possible to move on from old ways.

Of course the Open Atrium code is open sourced. (Thank you, Development Seed!)

Just last month the Development Seed team led an effort to provide some truly outstanding documentation on how to use, manage and customize Open Atrium.

Making Drupal Classes

So many of us love Drupal so much, is it time to objectify Drupal? By "objectifying Drupal" I don't mean placing Drupal on some sort of pedestal for self-gratification activities (though I suppose in a way we do that, too), but rather taking the organically evolved Drupal code from its almost biological interconnectedness of everything to everything towards an object-oriented model.

"Drupal mud." Each major part of Drupal core overlaps several other parts. Every change in one component cascades throughout.

Sometimes Drupal gets a little dirty to get things done. And we love it for getting things done. But Drupal can mature now, and perhaps benefit from a focused, high-level, directed approach towards refactoring to take advantage of the great benefits afforded by PHP 5.

Larry "Crell" Garfield described Drupal's current code as "mud" in his DrupalCon SF presentation presenting a vision of Object Oriented Drupal. He throws down a compelling challenge for the future. Drupal 8 is already in development, and starting to classify certain components of Drupal is on the agenda for many ... as part of what is likely a longer-term project.

Object Oriented Drupal. Clean. Each class contained. With this structure, without all the interlinked entanglements, Drupal core components can evolve more quickly.

Imagine a more modular, OO Drupal.

Letting Data Roam Free

RDF is the future. With Drupal 7, it's becoming the now.

One of the biggest barriers to a truly open, interconnected web is siloed data. Last year at SxSW, Robert Scoble told me that he was seeing increased open API development as the big thing then. And it's been great to see the various closed social networks developing APIs to allow interconnection and integration with other systems. This interconnectedness of separate systems is a start.

RDF is something different. But it can be much more profound, and have an impact greater by orders of magnitude, because it's about structuring data in meaningful ways so that site A can consume structured data from site B without having any access to site B's database. No API necessary for that.

RDF sets data free.

One immediate application of this is that RDFa is now being consumed by Google and other search engines, resulting in more meaningful search results for those sites feeding out RDFa-structured content. The web is ready for RDFa.

Somewhat difficult and time-consuming to implement in Drupal 6, RDFa is part of Drupal 7 core. That means all sites built in Drupal 7 will have RDFa support! (That is, unless the developer or themer disables it out of ignorance, negligence or choice.)

This topic is a particular passion of mine, which is why I'm thrilled to be "mentoring" [read: collaborating with] Lin Clark on her Google Summer of Code project on RDFa.

Of course, all of the RDFa efforts for Drupal are open sourced. (Thank you [for the Drupal 6 efforts], Arto Bendiken, Miglius Alaburda, Ben Lavender, Jeff Miccolis, Frank Febbraro and Stéphane Corlosquet, OpenBand and MakaluMedia. Thank you [for getting RDFa into Drupal 7 core], everyone who participated in these issue queues!)

777

In short, these examples demonstrate that, with Drupal, you can read, write and execute in all kinds of ways.

And as powerful as Drupal has been up through Drupal 6, even more power is unlocked with Drupal 7, which has a bunch of usability improvements, huge steps in the theming system, some important changes in the way the code loads and executes, a new database abstraction layer opening the doors to potentially running Drupal on all kinds of databases, and so much more.

I've seen some big changes in Drupal over the years, but Drupal 7 stands out as the biggest single leap in a major Drupal release. A big part of that is thanks to Angie Byron, who has proved to be cat herder extraordinaire in her role as Drupal 7 co-maintainer.

Everyone can help with Drupal 7 by reading up on what's still needed, writing patches and documentation, and executing patch tests.

And six years from now, we'll perhaps look back at these days as the quiet times in relative obscurity. Because....

Graphic by Dries Buytaert showing Drupal.org activity through 2007. As I write this, the node count is in the 811,000s. My first user account in 2004 was in the 14,000s. Nearly 800,000 users have registered since then to participate in the community in some way. (Okay, I was one of them by registering again [for reasons off-topic from this post].) Throughout this time, from Drupal 4.5 through 4.6, 4.7, 5.x and 6.x, Drupal's adoption as pretty much doubled with each release. Imagine the community doubling in 2010 with Drupal 7!

...growth happens.

You see, the great thing about all these fabulous, powerful things coming out of the Drupal community is that they make developing easier, so that you — we — can spend more time on strategy, on design, on content, and less time on reinventing the wheel or riding the bicycle up that same hill over and over again.

It's a good time to be working and playing with Drupal. Let's make the future together.

A Roadmap for Success: The Design Brief

Jen Schultes — Tue, 25 May 2010 13:23:51 +0000

Described succinctly by Tad Crawford in AIGA Professional Practices in Graphic Design, the design brief “digs deep into a project and identifies the main factors that drive the entire creative strategy.”

Indeed, a well-crafted brief is invaluable for most any sizeable design project. It functions like a compass, allowing client and design team to ascertain periodically that north is still north, and that everyone is headed in the same direction. A design brief will clearly state, for both client and design team, the expectations and objectives of the project, and as such, it is a critical tool, laying the groundwork for what is to be done, why it is needed, and how success will be measured.

The brief is thus part business strategy and part design strategy. To the design team, it points the way ahead, answering the basic questions necessary to inform the design process and keep the project on track. To the client, this early articulation of goals will assure that the project purpose and needs are clearly articulated and understood be everyone. This in and of itself is project gold, as the early discovery of fuzzy goals allows for immediate clarification and, if necessary, course correction. Many a project has been caught between the Scylla and Charybdis of unclear purpose and unidentified goals. The brief is a map for safe sailing.

A Design Brief keeps the project on track. [Illustration: Children's book from 1948 explaining how maps work, "Described by H.J. Deverson and drawn by Ronald Lampitt." Photo: I like.]

The design team will work with the client to create the brief, based on the RFP, the design proposal, the kick off meeting and additional interviews as neceassary. A formal review of the design brief should be held as the project gets underway in earnest.

The following questions are a guide for creating a thorough and effective design brief. Questions with fuzzy answers can lead to better defining project needs; or they can identify new needs, such as additional branding or strategy work. Some of the questions are really just conversation starters and idea generators. The list that follows is loosely organized by importance, but is by no means comprehensive or conclusive. Every project will need tailoring.

About the Project

Why are we doing this project?
Why are we doing this project now?
What are the goals of the project?
What do we expect to have achieved at the end of the project?
Who are the stakeholders and the decision makers in the process?
What deadlines or timeframes must be adhered to?
What is the budget?
How will the success of the project be evaluated?

About the Market

How is your organization perceived today?
Are there aspects of your market perception that need improvement?
Who are your competitors?
How are they perceived in the marketplace in relation to your organization?

About the Target Audience

Who is the target audience? As specifically as possible, note the age, income, location, lifestyle, occupation, gender ratio, et cetera of the intended audience.
Are there additional, currently-untapped audiences that would benefit from the project if their needs and goals were taken into account?

Branding & Inspiration

Do you have marketing collateral to provide for this project, such as photos, brand guidelines or messaging?
Are there words, colors, metaphors that convey the feel you are looking for?
Are there websites/brands/campaigns/publications/paintings/movies/other media that could provide inspiration ? Or that you specifically dislike/would like to avoid. Jot down why (color, content, typography, overall look and feel, imagery, etc.)

About the Organization in General

What is your business?
How old is your company?
How do your employees dress for work?
Is there an object/animal/building/metaphor that resonates with your organization's identity?

Preparing a design brief will help keep the process on track, giving the design team a point of reference, and helping to clarify client goals in a concrete way that sets the project up for happy success all around.

Want more information on creating a design brief?

Check out this blog post by Peter L. Phillips, the man who wrote the book (literally) Creating the Perfect Design Brief.
Look at this Google Books overview of AIGA Professional Practices in Graphic Design by Tad Crawford.

A peek at Drupal 7 theme system changes

Laura Scott — Mon, 03 May 2010 06:42:31 +0000

Every major release has introduced significant changes to the core API. There's no backwards compatibility between major Drupal releases; you can't run Drupal 7 modules on a Drupal 6 site, for example. In fact, if you tried you'd likely end up with the white screen of death. This willingness to let go of past thinking and old code has allowed Drupal to be as awesome as it is today.

For theming, fortunately, the changes have usually been rather incremental — a short checklist of minor changes to themes to get them working in the newer Drupal. And none was as radical or challenging as the change from Drupal 4.5's xtemplate theming engine to the phpTemplate engine that emerged around Drupal 4.6 and became part of Drupal 4.7's core. That "upgrade" actually required total reimplementation. You simply could not just tweak an xtemplate-powered theme into a phpTemplate-powered theme. Thankfully, since then it's been a much easier road for theme upgrades.

That is, until now.

Many Drupal themers will be daunted by the changes in Drupal 7. But we're excited about the new power.

50 (or so) drops make for an ocean of changes

Drupal 7 represents just about as big of a theme refactoring as possible, without replacing the core phpTemplate theming engine. I won't say this upgrade is harder than the xtemplate-phpTemplate migration. No, we're still working with the same basic concepts, same general approach — in theory, anyway. But the changes are still enough that anyone looking at doing a theme upgrade from Drupal 6 to Drupal 7 might seriously consider simply rebuilding it from the bottom up, rather than trying to apply this change here, that change there … for 50-something changes.

At my Drupal theming presentation at DrupalCon San Francisco, I touched upon some of the big things that D7 theming is introducing. There's video on the DCSF site. Here are my slides:

Grok Drupal (7) Theming

View more presentations from PINGV Creative.

But a more detailed rundown of the changes are (mostly) detailed at drupal.org/update/theme/6/7.

There are 49 changes documented so far, as I write this (with Drupal 7 still in alpha), and a few others to boot. In fact, some changes are not documented there yet — or are actually incorrect. (See bottom of this post for links to issues where I and others are working to correct some of these.)

So without trying to be comprehensive, here is an introduction to some of the Drupal 7 theming changes that will make Drupal theming even more powerful:

html.tpl.php

As I write this, nothing about html.tpl.php is documented in "Convert 6.x themes to 7.x" in the Drupal.org handbooks (and this is something I'm working to change). html.tpl.php is now the new page wrapper for your theme. Here you have the DOCTYPE declaration, the <head> info, and page closer.

modules/system/html.tpl.php contents

Here's a marked-up image of what you find in html.tpl.php:

The html.tpl.php template in Drupal 7 takes over the webpage container duties previously managed by page.tpl.php in Drupal 6. In Drupal 7, the latter template contains pretty much all of what you see on the screen; the <head>, <html> and <body> tags, as well the DOCTYPE declaration, are all moved to the html.tpl.php file. The page.tpl.php template is actually called from within the html template. Note: You can always find the base templates Drupal is sending your way by finding the *.tpl.php files within Drupal core's modules' folders, and in most of the contributed modules.

As you can see, this template has taken up the markup and renderings for pretty much all of the meta wrapping around the actual page that gets displayed, including new items $page_top and $page_bottom. page.tpl.php gets called this way:

<?php
 print $page; 
?>

This template is pretty straightforward, and something most themers won't even have to deal with. ~~But if you forget this template, you're going to run into some problems. So remember to include it.~~ But if you include it for the purposes of override, be careful or you could run into problems. [Thanks to Pasqualle's comment for correcting me on this!]

More: api.drupal.org documentation on html.tpl.php and an issue for documenting html.tpl.php implementation and changes.

region.tpl.php

Regions templates contain the content area, sidebars, footer, etc. By default, they follow Drupal core's region.tpl.php template.

Yes, regions now have templates. The active code Drupal 7 core provides for region.tpl.php is this:

<div class="<?php print $classes; ?>">
  <?php print $content; ?>
</div>

As usual, you declare your regions in the theme's .info file. If you don't declare regions, you will get these by default:

header
help (yes, help is now a region of its own)
highlight (this replaces $mission)
content (which is required in all themes)
sidebar_first (whose naming reflects a generally more semantic approach to Drupal theming)
sidebar_second
footer

The various regions are called out and rendered by code in the page template, page.tpl.php, by using a syntax identifying the region as a variable, e.g.:

<?php print render($page['help']); ?>
<?php print render($page['sidebar_first']); ?>
<?php print render($page['sidebar_second']); ?>

Of course, to conditionally print the region only if it has stuff to display, it might look something like this:

<?php if ($page['highlight']): ?><div id="highlight"><?php print render($page['highlight']); ?></div><?php endif; ?>

More: api.drupal.org documentation on region.tpl.php.

Hidden regions

This is a neat little one. It's a way to define regions that are available for modules but are not available in the blocks administration area. Why would you want to do that? The Drupal.org Handbook's theme update page explains a use case:

The page_top and page_bottom regions are hidden, which means they will not show up on the blocks administration interface. When doing site-specific themes, it might also be useful to add more hidden regions (to provide ways for modules to add output to more places in the theme without defining blocks showing up on the blocks interface), you can do that via the regions_hidden[] .info file array which is new to Drupal 7:

theme .info file extract:

regions[content] = Content regions[help] = Help regions[page_top] = Page top regions[page_bottom] = Page bottom regions[indicators] = Indicators regions_hidden[] = indicators

In this above example, the region named "indicators" is additionally defined as a hidden region.

Two ways of hiding elements with CSS

Speaking of hiding things, there are now two standard ways to hide content using CSS:

.element-hidden — to hide an element from all users. ("An example would be a collapsible fieldset that will be expanded with a click from a user. The effect of this class can be toggled with the jQuery show() and hide() functions" — handbook.)
.element-invisible — to hide an element visually, but keep it available for screen-readers. ("This class should be used for information required for screen-reader users to understand and use the site where visual display is undesirable.... This class must not be used for focusable elements (such as links and form elements) as this causes issues for keyboard only or voice recognition users" — Ibid.)

It's extremely handy to have these predefined, especially as browser-viewed design patterns get increasingly complex and specific to particular use cases. All themers have to recognize that they are implementing an application interface, not a "web page" as conceived by many since the advent of Netscape in 1994.

All titles in templates get prefix and suffix

Thusly:

<?php print render($title_prefix); ?>
<?php if ($title): ?><h1 class="title" id="page-title"><?php print $title; ?></h1><?php endif; ?>
<?php print render($title_suffix); ?>

Why?

One reason is to generate contextual links — such as a handy block edit link right there where the block is displayed, visible to and accessible by users with appropriate permissions.

Granular display of `$content` info in node.tpl.php

Now this part is really cool. It no longer requires preprocess to break apart node $content output. Of course, you could print each field on its own, but what a pain in the ass!

But in Drupal 7, you now have two new functions for printing out content in a node or user profile:

render()
hide()

Let's look at an example taken from node.tpl.php:

<div class="content">
  <?php
    // First we hide the comments and links now so that we can render them later.
    hide($content['comments']);
    hide($content['links']);
    // Then we print the content. Comments and links end up not included here.
    print render($content);
  ?>
</div>
    // Then we print the links and comments separately
<?php print render($content['links']); ?>

<?php print render($content['comments']); ?>.

What this means is that you can pull components or fields out of your template's big $content blob and display them in a more controlled way — e.g., to split them out of the "content" div, as illustrated above.

Fields are in core

With fields now in core, if you weren't CCK-prolific, you have more theme components to account for by default.

This isn't so much a theming-specific thing, but it's really cool! The field.tpl.php template is pretty straightforward:

<div class="<?php print $classes; ?> clearfix"<?php print $attributes; ?>>
  <?php if (!$label_hidden) : ?>
    <div class="field-label"<?php print $title_attributes; ?>><?php print $label ?>:&nbsp;</div>
  <?php endif; ?>
  <div class="field-items"<?php print $content_attributes; ?>>
    <?php foreach ($items as $delta => $item) : ?>
      <div class="field-item <?php print $delta % 2 ? 'odd' : 'even'; ?>"<?php print $item_attributes[$delta]; ?>><?php print render($item); ?></div>
    <?php endforeach; ?>
  </div>
</div>

In there, like in Drupal 6's filefield module template, it's pretty clear where the <div>s are, so you can get at your markup output.

The box is dead

Ding dong! box.tpl.php is no more. What was the box for? Good question! Moving on….

Search in the theme is dead! Long live search in a block!

Because it seemed silly to have search live in both places, the search form call in page.tpl.php is no more. You can place the search form using its available Drupal block.

Template suggestions' delimiter change

Template suggestions now use a '--' delimiter rather than the '-' that was used in Drupal 6. To illustrate:

page--front.tpl.php
node--blog.tpl.php
node--event-performance.tpl.php

Note that word separations within an element remain '-'. This allows for cleaner logic in handling instances of hyphenated elements, so the double hyphen always indicates a more targeted override of what comes before the '--'.

preprocess, process and process_html

This is a change that really deserves its own blog post (and a long one at that). Suffice to say that preprocess no longer stands alone as a high-power tool for themers.

There are now two sets of variables process functions. The first are the existing "preprocess" functions. The second are "process" functions which are run after preprocessors. All the various prefixes and suffixes apply to this second phase in the exact same way. This is useful when certain variables need to be worked on in two phases.

For example, adding classes into an array for the "preprocess" phase then flattening them into a string in the "process" phase so it's ready to print within a template.

Also there's now preprocess_html. Documentation issue: drupal.org/node/579698

This alone should be enough to inspire the dedicated Drupal themer to brush up on her PHP chops.

RDFa

RDFa is here to stay. Robots will love it. You should just stay out of the way.

Providing extra rich robot food in every pageload is one of Drupal 7's big improvements, and that means new RDFa requirements for themers so that this layer of robot food gets loaded into the page. Here's what you want to make sure you do in your html.tpl.php template :

Declare the appropriate "XHTML+RDFa" doctype:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
Print appropriate <html> info, language attribute, and RDF namespaces:

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="<?php print $language->language; ?>" version="XHTML+RDFa 1.0" dir="<?php print $language->dir; ?>" <?php print $rdf_namespaces; ?>>
Print the GRDDL profile to facilitate consumption of this RDFa metadata:

<head profile="<?php print $grddl_profile; ?>">

See: Wikipedia info on GRDDL.

Yes, I know, this may not seem like it's relevant to a themer, but this is the future. Drupal is leading the way in CMS adoption of RDFa, which will lead to a future where the web increasingly behaves like one big machine with one big database of information. So feed the robots.

A couple of open issues

Conditional stylesheets

This is a big issue for me, and I believe for all Drupal themers: There's a question whether themers should be able to declare conditional stylesheets in the theme's .info file.

The alternative, placing code in a preprocess function, requires a modicum of PHP knowledge, which is not ideal for front-end development. Yes, there is a lot in Drupal 7 theming where PHP knowledge is extremely helpful, I know.

But conditional stylesheets, in this day and age of multiple platforms, are such a common use case it would be great not to have to bury that implementation in preprocess. Conditional stylesheets should be easy peasy to declare!

If you think so, too, please let it be known on this issue.

Documenting all of this

This blog post is I hope a helpful read for Drupal themers and front-end developers interested in working with Drupal. But it is not documentation. The documentation on Drupal.org is incomplete and inaccurate in places. Here are some issues where you might help.

The Drupal 7 theming guide is outdated. In fact, it really doesn't exist except as an add-on to the Drupal 6 theming guide. drupal.org/node/740194
Documentation on html.tpl.php is missing or misplaced as "changes" to page.tpl.php. drupal.org/node/786312
There's discussion on documenting html.tpl.php clearly, with all the various changes: drupal.org/node/579698
And where themer help is needed: working on and testing patches for theming-related critical and normal issues.

This is only a start

In the coming weeks, I hope to find the time between client work and company business (and helping with testing and documentation of Drupal 7) to follow up on this post with more highlights and tips on Drupal 7 theming. If you've come across other really cool bits, please share them here.

Mood Boards? Welcome Aboard!

Jen Schultes — Thu, 29 Apr 2010 18:20:31 +0000

Taking a step back to review methodology every so often is a great way of keeping work fresh, as it means you don't slip into a routine. Lately here at PINGV, we have been looking for ways to streamline projects and enhance how we communicate conceptual ideas to our clients.

At one point in the discussions, thinking about how we create and present visual design comps, we all remembered Mood Boards. Oh, wonderous Mood Boards....such utility! such style! the way you perk up the grayscale sketchiness of wireframing with a burst of ideas and colors....where have you been all our lives? Actually, we had each used them before, but they had not been part of our PINGV team process. Until recently! And now, we can happily report that their integration has been a smashing success.

First Off: What Is a Mood Board?

Everyone needs inspiration to make and communicate design proposals. Architects use a process called Charrette, in which they gather up and throw around ideas, obstacles and solutions to the project at hand. Interior and Fashion Designers create Swatch Panels to visualize solutions and work through possibilities. In Web Design, the Mood Board (sometimes called Inspiration Board) is our tool of choice.

Mood Boards allow one to create broad stroke representations of look and feel, free from structural distractions, similar to the way that wireframes allow one to sketch out page architecture without broaching visual design. The Boards are collages or templated representations which can indicate typography, imagery/photography style, color palette, use of space and iconography.

Here are two examples, one collage-style and one template-style.

A Mood Board in collage style

A Mood Board in template style

Our process now is this: as wireframing begins to wind down and most structural elements are falling into their general places, we take our first foray into the visual elements of the site. Generally, we have been snipping images from websites and magazines, gathering elements and inspiration ever since the project started. We now gather those files and clippings into 3 directions (more or less).

The Directions

The look we feel instinctually is best
A more conservative or more formal approach
A more extreme or more casual approach

(At the Boagworld blog Paul Boag writes that his shop creates a 4th Board which is way out in left field and intended as a creative, idea-generating activity. The formal inclusion of a push-the-boundaries Board makes a lot of sense, and we will definitely be giving this a whirl for our next site.)

How to Create a Mood Board

Template versus Collage

Now that we have our buckets of styles, we need to choose whether we need to present them in a loose or structured format. Depending on the temperament of the designer and the type of client you are working with, this is usually a simple decision. Some clients are very adept at looking at a collection of images grouped and scattered across a page, while others will really need to have a Board in which different items are clearly labelled (Palette, Icons, etc). By now, you probably have a good feeling as to what sort of client you are working with ;)

At PINGV Creative, we tend towards collage style, as the layout of the Board itself gives you an additional tool to indicate mood. For example, you can create an open collage with a lot of white space or a densely layered one with patterned backgrounds. As you are talking your client through the Boards, these details open points of discussion which can illuminate future decisions.

Things to Watch Out For

Be sure you don't make your Boards look too much like a web page. This defeats the whole purpose and can actually confuse the client. To avoid this, there are a number of strategies:

Spend less time on the individual Boards. It's easy to get fussy and what we are wanting is fresh and fast. The longer you push pixels around in this particular process, the more likely you are to create a DESIGN, rather than a collage of inspirational images.
Make a physical Board...get out the scissors and the glue stick and print out those digital images, snip snip the magazine pages. Not only can this be a truly satisfying way to spend a few hours, but you are very unlikely to glue together a web site ;)
Use a different aspect ratio or size. Make them square or tall or long and narrow.

How to Present a Mood Board

If you have done your job and your Board does not look like a web page, you will most likely have few problems talking through the Boards with your client. Many designers attach a few adjectives to each Board, almost as talking points. Or you can title them. You will want to point out regardless that these are NOT comps, but rather conversation starters. Welcome their first impressions, listening for what they like and what they dislike, as both pieces of information are important. At the end of the session, ask your client to look at the Boards again the next day and report any additional thoughts.

Why Have We Found Mood Boards Invaluable?

Mood Boards Focus the Approach

With a Mood Board, we are focusing on site aesthetics not structure or content. Breaking the process up into these chunks, just as we do with Wireframes, unmuddles the decision-making and discussion.

Mood Boards are Quick and Disposable

The process allows for rapid prototyping in the visual design process. Mood Boards can (and should be) quick to produce, somewhere between and hour and 3 hours, depending on the style you are using. Moreover, if after you have gathered and grouped your inspirational elements, it becomes apparent you are barking up a barren tree, you can file the ideas away without tears.

Mood Boards Enhance Creativity

The process allows you to work through ideas in an unstructured way that encourages experimentation and does not punish trying to push the envelope here and there. Even if all your Mood Boards are rejected, its totally ok! You have gained a better idea of the look and feel directions your client is NOT looking for, and you have lost only a few hours...much better than discovering the same information after several days of design work.

Here at PINGV Creative we are happily embracing our long lost friend the Mood Board. We love how it has opened up our creative process and stream-lined the acceptance of design comps. Designers, if you are looking for a new approach, give Mood Boards a try. We think you'll like 'em.