A few months back I had the opportunity to present at the Tridion Developer Summit in Amsterdam. Gino Toro, (former) product manager for Media Manager was going to be speaking on Media Manager, so I decided to try a different topic. After debating on a few different topics, I settled on “CSS3 and HTML5 for a better content author experience.” It seems like a lot, but the premise is simple: you can do things with your front-end that can make it easier for CMS users. So what I’d like to do now is zero in on one aspect of “Front-end for the middle”: Good markup makes for a good Tridion implementation.
Alas, it’s a really long topic, so first I’d like to explore the basic issue of how design impacts front-end development.
The Focus of Front-end
It’s not about cool video effects, neat tricks with images, or animating slides. While it’s certainly fun to do cool and next-level things with our code, it’s really not about the code, or the visual. It’s about helping a user consume content.
- HTML is HyperText Markup Language; we are marking up content and conveying meaning
- CSS is used for describing the presentation of a document
- JavaScript is about making the content dynamic and interactive
Outside of the context of a website, each of these languages can have a myriad of other purposes. But when a front-end developer is coding for a website, the unifying theme of his code should be the content.
Missing the forest for the leaves
Sometimes when I do a code review, I ask the developer, “what does this code do?”, the response is usually along the lines of, “animate this panel” or “make a slideshow.” These responses aren’t inaccurate, just incomplete. Whether a snippet of code, file, or the entire code base, ultimately it’s supposed to exist for the purpose of presenting content to the end user.
Unfortunately, most companies don’t kick off new website implementations because of the content. It’s almost always because of the design. So the company goes to a design agency where they design the site. Design agencies don’t deliver a better presentation of content, they deliver better pictures of content. To quote Jeffrey Zeldman,
Content precedes design. Design in the absence of content is not design, it’s decoration.
Because design agencies are singularly focused on “pretty”, they deliver pictures, and pictures are what front-end developers have to work with.
Burning down the forest for crap
In July of 2015, a cyclist in Idaho burnt down 73 acres of a forest because he thought burning his toilet paper was, “the right thing to do”.He pooped in the woods. Wiped his butt. And thought the best thing for the environment was to set his dirty toilet paper on fire. His myopic view of “right thing to do” proved to be very harmful.
A front-end developer’s short-sighted focus on the visual experience of the website turns content into dry leaves, where the best possible outcome means no one notices the shit.
The visual experience is not the thread that ties back-end developer, content editor, front-end developer, and end-user together. Only content does that. If content is that one common theme that connects everyone on the team with both middle-user (the content editor) and the end-user, then we should talk about how front-end can be content-focused.
Front-ending for Content
It’s not hard for a front-end developer to have a content-first mindset. In fact, many experienced front-end developers already do. What’s hard is getting everyone else in the same mindset. there are ways to help ensure that front-end is content-oriented.
Document the Design
When a front-end developer gets design specifications, he should also be given content model information. In the world of Tridion, This looks like a functional design document. While the functional design document has some information that isn’t important to a front-end developer, most of this information is crucial:
- Content Models / Schemas. This tells her what constitutes a unit of content
- Editorial Rules/ Schema Fields. In addition to knowing a unit of content, our developer knows how content is created. She knows if certain things are mandatory, optional, or repeatable.
- Content Views/ Component Templates. This turns a picture into an example for our developer. She knows the relationship that content has to the visuals with this.
- Taxonomy / Categories and Keywords. This gives the developer an idea of how the ‘middle users’ will classify things and name things.
You can very much defeat the “develop for the design” mentality by delivering content modeling requirements with your design. Don’t let a front-end developer just write some code based on a design. Make sure she’s educated on how Tridion works; the relationship between schemas and components, how components can link to each other, and how templates are produced.
This also helps her look through her own code base, recognize common patterns, and surface those common HTML patterns as potential embedded schemas, whole views for your app, or even partial views.
The big idea
Don’t let your front-end developer think that her only job is to turn a PSD into markup! That’s not her job at all. She is responsible for making content consumable, and the visual is only one part of her job. She must also make that content consumable to those who are visually impaired and search engines, which is where markup comes in to play.