Code as Content

Modern software practices were brought up on computer science pedagogy that promotes clean and beautiful object-oriented (OO) architectures. They were fed a healthy dose of open source-powered movement toward behavior driven development (BDD). Not quite all grown up yet, these efforts are aimed at producing high quality software outcomes. There is still a missing link in the chain that connects a user’s interaction with a software developer’s intention when it comes to content.

The web is full of content. And the line between content and software is becoming more difficult to detect. While many can make persuasive arguments that coding is an art–“artwork” at least has a different character as “content” and it doesn’t nest so nicely in software architects’ object hierarchies. Content requires different standards from both an OO and BDD point of view.

On one side of the line, for example, no one would rightly call an image file “software”. Similarly no one would call a sorting algorithm “artwork”. A procedural flocking animation written for the HTML 5 canvas though is tricky.

When an artist (call them a creative coder) performs that mystical creative act of bringing a piece of artistic content into the world, more and more these days that act may involve writing code, but the artist may consider that code just a means to an end–expression.

So the point isn’t about drawing a line, so to speak, between software and art. This isn’t a metaphysical discussion. The application of OO and BDD techniques to art are different, and recognizing how to architect and how to test content vs code may mean the difference between expending resources effectively, or squandering them. I’ll save the implications of object-oriented architecture on art for another day, for now I’ll focus on the BDD side.

What would behavior driven development tests of artwork look like? Remember BDD starts with user stories in human terms: what experience do I want the person using my software to have? So for example, a common BDD story would be written like this: “As a Facebook user, when I login, then I should see my news feed.” And a programmer could write software tests that perform just those steps: login to facebook with a valid username and password, check what page appears, is it the user’s news feed? If so, PASS.

If the question turns to, “what experience do I want the person viewing my content to have,” the BDD user story might become, “As a Facebook user, when I scroll my news feed, then I want to feel like it has a physical weightiness.” Yikes, how does a programmer write a software test for this nicely articulated artistic motivation? Weightiness? Well, artist, what do you mean by that?

Effective BDD would require the artistic motivation to be reduced to purely software terms, perhaps: “As a Facebook user, when I scroll my news feed, then its scrolling motion should decelerate gradually when I release my mouse.” This is not a naturally artistic statement. The artist had in mind to make a page that feels weighty, so involving words like deceleration pollutes the user story with the “hows” instead of sticking to the “whats.”

As opposed to artists, for non-programmer product designers, BDD requires expressing in human terms what software should do. But it can only be successful if the language those product designers use to describe the software is actually testable by the engineers who write the tests.

Let’s face it, art is hard to describe, and unless its creator is also a bonafide critic, even artists themselves usually do not possess the language to describe the reaction they wish to engender in their audience. Content is in fact, not software, and should not be tested as software.

Content by its nature, even if it involves software, does not fit a software testing model. Perhaps a new model is needed to provide a softer, squishier, more qualitative way to evaluate whether content is operating effectively.

We can test whether an image renders on the screen correctly. We can test whether an animation with easing is slowing according to a cosine or a cubic curve. But how do we test if a user thinks the Facebook news feed feels weighty?

I think the answer is: ask them. BDD forms part of a software “immune system” but it is only one layer, just as unit testing, and human quality assurance testing are others. With all of today’s emphasis on metrics, it is time for BDD to naturally extend outward, beyond the bounds of the continuous integration servers that execute software tests with each commit, beyond the confines of the software develop’s network, and out into the world, where people can look at a software feature combined with its content, react to it, and tell you what they think–analytically, scientifically, measurably.

I imagine a BDD user story of the future to tie with an analytics system like this, “As a facebook user when I scroll my news feed I should feel as if it were weighty.” And I imagine a test report with a result such as “18% feel the news feed is somewhat weight, 48% feel the news feed is very weight, 4% feel the news feed is too weighty.” Some metrics frameworks such as Qualaroo, or conversion experts such as CROmetrics will provide this sort of data, but to use them, you have to separately set up the metrics system, ask the right questions and compare the results outside the normal design and development cycle.

Software maturity would benefit if the distance between the qualitative usage measurement (in the wild) and the design of software were shortened, in the same way that BDD shortens the distance between usage correctness and software implementation. It is time for customer experience data to integrate seamlessly with BDD toolkits so that artist intentions, no matter how much or little code is involved, align with the business, usage and artistic intentions of software products.

Credits: What Is Art