The Standards Consensus: Separate Content Structure from Content Behavior
— Treehouse blog January 2014
“The separation of structure, presentation and behavior is dead. It has been dead for a while. Still, this golden rule of web design sticks around. It lives on like Elvis and we need to address it.”
— Treehouse blog January 2012
Over the past five years, the big change in the web world has been the adoption of HTML5, with its heavy focus on applications, in contrast to the more document focused XHTML it replaced. The emphasis among developers has been more about enhancing application behavior, and less about enhancing content structure. HTML5 killed the unpopular proposed XHTML2 spec that emphasized greater structure in content, and developers have been seeking ways to remove XML-like markup where possible.
The emphasis on applications behavior has resulted in new interaction capabilities and enhanced user experiences. Rather than view a succession of webpages, users can interact with content continuously. This has resulted in what’s called the Single Page Application, where “the web page is constructed by loading chunks of HTML fragments and JSON data.”
People are now thinking about content as apps. An article entitled “The Death of the Web Page” declares: a “Single Page can produce much slicker, more customized and faster experiences for content consumption just as it can for web apps.”
Risks Associated with Content On Demand
The rise of the Single Page Application is the most recent stage in the evolution of an approach I’ll call content on demand.
Dynamic, constantly refreshing content can be relevant, and engaging for users. But it doesn’t always meet their needs. Especially when the implementing technology assumes audiences will want the existing paradigm exactly as it is.
Forcing users to interrogate content consistently could pose problems with the emerging category of multimodal devices. To access content, audiences may depend on different input types such as gestures, speech recognition and voice search. Content needs to be available in non-browser contexts on phones and handheld devices, home appliances, intelligent autos, and medical devices. But input implementations are not uniform, and can be often proprietary. Consider the hottest new form of interaction: speech input. Chrome allows speech input, but other browsers can’t use Google’s proprietary technology, and x-webkit-speech only supports speech interaction for some form input types.
When viewable content is determined by a sequence of user interactions, it can become an exercise in “guess what’s here” because content is hidden behind buttons, menus and gestures. Often, the presence of these controls only provides the illusion of choice. In older page-based systems, users might choose many terms and be lead to pages with different URLs that had the same content. Now, with “stateless” content, users might not even be sure of how they got to what they are seeing, and have no way to backtrace their journey through a history or bookmarks.
Some kinds of content hidden in the Deep Web (via Wikipedia)
Dynamic content: dynamic pages which are returned in response to a submitted query or accessed only through a form, especially if open-domain input elements (such as text fields) are used; such fields are hard to navigate without domain knowledge.
Contextual Web: pages with content varying for different access contexts (e.g., ranges of client IP addresses or previous navigation sequence).
Know Your Risks, Prioritize What’s Important
My goal is not to criticize the app-ification of the web. It has brought many benefits to audiences and to brands. But it is important not to be intoxicated by these benefits to the point of underestimating associated costs.
Functionality should support choices significant to the user, and not mandate interactions. There is an unfortunate tendency among some cosmetically focused front-end developers to provide gratuitous interactions because they seem cool. Rather than be motivated by the goal of reducing friction, they present widgets for their spectacle effects rather than their necessity to support the user journey. Is that slider really necessary, or was too much content presented to begin with which required the filtering?
A big consideration with content on demand is understanding what entities have an enduring presence. As content moves toward being more adaptive and personalized, it is important to know and manage the core content. There can be a danger when stringing together various and changing HTML fragments via continuous XMLHttpRequests on a single page that neither the audience nor the brand can be sure what was presented at a given point in time. This is not just a concern for the legal compliance officer working at a bank: it’s important to all content owners in all organizations. For audiences, it is hugely frustrating to be unable to retrieve content one has seen previously because you are unable to recreate the original sequence of steps that produced that view.
What’s the Future of Structure?
An approach that decomposes content into unique URIs could provide the benefits of dynamic content with the benefits of persistence. Each unique entity gets a unique URI, and entities are determined through the combination of relevant facets. URIs are helpful for linking content to content hosted elsewhere. One could layer personalization or modifications around the core content, and reference these through a sub path linked to the parent URI. Such an approach requires more planning, but would enable content to be ready for any device or platform without scripting dependencies. I can’t speak authoritatively concerning the effort required, any implementation limitations, or how readily such an approach could be used in different context. This kind of approach isn’t being done much, but it leverages thinking from linked data about making content atoms that communicate with each other. I would like to see developers review and explore the practicalities of URI-defined content as content strategists think through the organizational and audience use cases.
Content strategists often advocate XML-like markup for structure, but I see few signs that is gaining widespread traction in the developer world, where XML is loathed. XML markup seems to be in retreat in the web world, while JSON is king. How do we express structured content in the context of a programming language rather than a documentation language? We need collectively to figure out how to make structure the friend of development, rather than a hinderance.
— Michael Andrews