If there’s one thing I learned while attending DrupalCon Baltimore 2017 this past spring, it’s that those of us involved in building the web are only getting more and more specialized in how we help build it. It boggles the mind to witness the sheer amount of new session tracks, new technologies, new design patterns, and new discussions that come up each year at DrupalCon. However, amongst all the topics discussed this year, I was most intrigued by one of the oldest concepts in web development, which predates the web itself: content. Specifically, as sites and apps allow content to be distributed in more and more ways, we need to emphasize best practices around structured data from the start of any project and help clients view their own content in the same way.
As a developer mostly specializing in back end technologies, I often find myself caught up in the never-ending race to discover and learn more about each and every corner of the expansive Drupal core and contributed ecosystem, along with all the constant discussions around the next big thing in this or that area of work. But, with so much discussion about the newest technologies and concepts, my focus is continually brought back to content as the center of the web development universe. Specifically, structured content, which was the topic of Dori Kelner’s excellent session on “Employing a Collaborative Model for Structured Content”.
The Importance of Structured Data
A website without meaningful content would be useless. But a website with compelling, yet poorly structured, content is not very usable either. For example, imagine a site where you can only enter content via singular WYSIWYG textareas. Granted, the WYSIWYG functionality may give you the sense that your content looks good and appears to be well formatted to the human eye. However, the data within that WYSIWYG textarea is effectively being saved as an amorphous blob of content, especially when viewed from the perspective of search engines, automated web services, and so on. Furthermore, it cannot be easily tagged or related to other content, with all the data being saved in an unstructured manner. As a result, this type of “blob content” ends up being significantly less shareable (in the eyes of search engines) and less reusable (by content authors on your site).
The problem is that we humans are often too good at understanding content, when compared to computers. People can almost always read and understand a site’s data, no matter how it's structured or formatted (within reason). And that is not to say that good UX design is not an extremely important task unto itself. However, sites should also be concerned about allowing other applications (in addition to humans) to come in and find, parse, and use their data. That is, the data on a site should not only be highly human-readable, but also highly machine-readable.
If a site’s data (and metadata) are easily parseable by machines, in the form of distinct, annotated fields, then that data can be gathered and shared efficiently by countless applications. This can even apply to a site internally, when considering a decoupled site that effectively contains multiple internal applications—the simplest example being a site with an independent front end and back end—where each of which needs to efficiently communicate with one another. Therefore, content is well structured when disparate pieces of data are saved in distinct fields and when metadata is available to describe the types of data in those fields. And metadata, in turns, helps to free your data by making it organized, logical, and classifiable. As Dori Kelner explained in her talk, when content is created as well-structured data, it becomes:
- and future-proof.
The (Non-Technical) Roadblocks to Well-Structured Content
Seeing how useful it is to have well-structured data, why do we still struggle in this domain, even when we know the right solutions?
As a developer, my job is most often focused on how and where content is being fetched, rendered, and served. But, if content is truly at the center of a site, then it touches everyone's job no matter what. And so, in theory, everyone should be involved in content modeling as soon as possible to ensure the most effective meeting of business needs. Unfortunately, this common-sense approach to collaborative content modeling can still run up against many roadblocks from the start. In fact, the biggest roadblocks to having well-structured content are often not technical in nature at all. Instead, content problems often reflect people problems.
For web agencies that are starting new web-based projects/engagements with clients, the client can often come to the table with many preconceived notions about how the content on their site or app should be structured. As experts in their particular business domain, a client will naturally believe that they have the best understanding of their industry and related content, compared to their partners at a web agency they’ve hired. However, this natural expertise about the content doesn’t always translate to how it ought to be structured, especially on the web. Many a project can spiral out of control, exceeding budgets and timelines, when a client insists on playing the role of information architect on top of being the content author. This approach forces the developers to adapt their practices to a potentially malformed conception of how a site’s content should be structured.
With that being said, web agencies can often be their own worst enemy as well in regard to how they approach content modeling with clients. For example, it can seem efficient to have a lone digital strategist sit down with the client to hash out their content needs. Afterwards, these requirements are passed down the chain and ultimately land in the laps of the developers. However, at that point, it’s already likely too late for the developers to make suggestions based on their particular knowledge of what might be the most efficient way to implement a content model with certain technologies.
Similarly, client and developers alike can get caught up in providing “easier” ways of authoring content, as a way of circumventing the hard work of content modeling altogether, via technologies like WYSIWYG and in-place editing capabilities. Rather than sitting down to accurately model how content will need to be presented and stored on the site for efficient future use, it can be very tempting for all parties involved to allow for content entry in the form of unstructured, WYSIWYG, in-place editors that permit users to enter data in practically any way they see fit. Then, only later do the client and agency come to regret their decision, when suddenly the data needs to be presented in a different channel or format, and it becomes prohibitive to manipulate the existing data in its amorphous, unstructured form.
The Case for Agile Content Modeling
As we’ve seen, it can be very easy to get things wrong when it comes to developing well-structured content for any project. But what if we were to take some lessons we’ve learned in modern software development, and apply those to modern content development as well?
In today’s software project management practices, the perils of the “waterfall” approach and the virtues of the “agile” approach have been touted for years now. When developing modern applications for any number of business needs, many of us take it for granted that it will be more efficient to build that application using an iterative, team-based approach, rather than a one-way, planning-first, building-later approach.
In fact, our very own Jen Slemp at Mediacurrent recently laid out the benefits of agile vs. waterfall, explaining why an agile approach has consistently been much more effective than a waterfall approach for our agency. And, as Mediacurrent’s Cheryl Little explains, it should also go without saying that an agency’s designers and developers need to work hand-in-hand as a cohesive team throughout any project. Of course, there are many other project management methods out there, but, to keep things simple, we can focus on a waterfall vs. agile approach and how we might apply that to the content development process.
While much has been said about agile processed within the software development world, these same insights often still appear to be missing from the content development world. As Dori Kelner mentions in her talk, the goal is “to get you to feel like you are part of the content creation team.” However, instead of having this feeling of being on the same team, our first inclination as clients and agencies is often to let a more classical waterfall approach take over all of the content creation processes.
As a method for content development, this waterfall approach can be laid out in four phases, as Dori Kelner cites in her talk based on Atherton and Hane’s paper “Designing Future-Friendly Content: Modeling Structure for Every User Interface”:
- Phase 1 would involve domain and content modeling for the purpose of mapping out content types.
- Here, domain modeling refers to the mapping of the entities that will exist on a site and how they relate to one another, while content modeling refers to the mapping of the attributes within each of those entities.
- This phase would traditionally be handled by the content strategists on a team.
- Phase 2 would involve content creation as well as the creation of wireframes/prototypes, traditionally overseen by content authors and UX designers.
- Phase 3 would involve visual design comps created by graphic designers.
- Phase 4 would involve the actual front- and back-end theming/coding carried out by developers.
If these phases are followed in a strictly linear path, as laid out above in a waterfall style, then the site’s content and its structure are often planned out by a small number of people—without much outside input. Consequently, it becomes very difficult to tackle any issues later on in the process as they arise, especially when it is often the developers who are the last ones to have any input in the content design.
For example, say we fast forward to the end of this process, where the developer is handed a visual comp and told to replicate it pixel-perfectly. If that developer runs into an issue where the Drupal API would have dictated a slightly different content model, there is not much the developer can change about the content model at that point. Instead, they would need to find some less-than-ideal workaround in order to match the visual comp they were handed while still trying to conform to Drupal best practices and its API requirements.
By contrast, how would this process appear under an agile approach? Assuming we maintain the same four basic phases, we can at least make each of them more flexible and responsive to our business needs. Furthermore, each phase of the content development process should be a truly collaborative effort across many disciplines, to guarantee efficient decision- and revision-making processes throughout.
For example, in the initial domain and content modeling being done, it would be ideal to involve developers from the start and let them play a much larger role in finishing the content model. This is preferable because content strategists might not be aware of what's possible/cost efficient when working within a specific technical framework like Drupal. Is this way, developers can bring their expertise to bear on the specifics of building content type, and should be able to preempt many common or less common issues with implementing certain content structures. Conversely, it is also up to the content strategists to still provide the developers with a solid, understandable base of requirements and models to work from.
Similarly, during a more agile version of the wireframing/prototyping phase, content authors would have already worked up a significant amount of real sample content, which they could use to validate the wireframes and prototypes being built by the UX and graphic designers. In this way, the wireframes and prototypes can be iteratively revised before anything is set in stone. By getting the content authors involved as soon as possible, we can ensure that their needs are anticipated during the design process, so that they can consistently maintain authoring standards later one, and not be forced to enter data in a convoluted way that may lead to bugs in the system or simply cannot be handled adequately.
The Bottom Line: Content Modeling is a Shared Responsibility
The bottom line is that being proactive in the conversation about content with your client is essential, regardless of whether you're a freelance developer or team member at a large Drupal agency. And as technologies like decoupled site architectures become more and more prevalent, having good information architecture from the start will only become more and more crucial. With that in mind, content should never be the roadblock standing in the way of a successful launch. But the only way to systematically prevent that is by bring you agile software development practices into your content modeling and creation practices. If your team can achieve this, then you’ll be capable of:
- Having fully updated content at launch;
- Integrating real content during development phase;
- Faster turnaround between development and launch;
- Validating decisions (information architecture and menus) with the client during the discovery phase via user testing.
Just remember that, if content is at the center of a site, then it also touches everyone's job. Therefore, everyone should be involved in content modeling as soon as possible and as often as possible, in order to ensure the most effective meeting of business needs from day one.