I’ve complained in the past about how I don’t like application architectures being led by the front-end team. Rather than complain some more, I want to talk about how front-end developers could meaningfully participate in the architecture of a project — particularly the CMS part.
I want to talk about how front-end developers can be involved in architectural discussions in a useful way that makes the product better for everyone.
A Quick Caveat
You could extrapolate much of what I say to API design in general. But I’m leaning on my experience specifically in delivering UIs that are supported by content management systems. So if something I say sounds weird, then ask yourself, “Have I worked in content management since Breaking Bad was still on the air,” and if you say, “no,” then maybe just be like, “hmm. Maybe that doesn’t apply to me,” and move on.
Front-end Developers Should Have a Say in Their APIs and CMS
They should have a say because the way content is structured could influence everything from how they write the markup through how reusable their templates could be. I’ve written about how content modeling choices influence markup choices in the past. Hell, I even have a slide deck on it.
The way content is modeled in a CMS is directly related to how the data is shaped in the API, and the shape of the data affects how you render that content. The front-end team should have some ideas how the content works:
- The types of fields in a CMS inform your semantic and accessibility choices
- Knowing if a field is required/optional/repeatable/limited tells you if and when you need templating logic
- Being aware of sets of fields that are reused across content models clues you into where partial templates could exist
- Syndicated content should mean syndicated design, and syndicated design means similar if not same templates
- Front-end developers are the last stop for accessibility; they should make sure the upstream data gives them what they need to deliver an accessible product
Front-end Developers shouldn’t drive content & API design
Our world is the browser where it’s all JavaScript all the time. The browser is the last stop for the data. It should not be leading the API and CMS discussions.
Information architecture, business requirements, and functional / systems requirements should come before the front-end. So while front-end developers absolutely need to be involved in CMS discussions and architecture discussions — they shouldn’t be running the show!
Good Content & API design is Content-Centric
When you’re building stuff for the web, you really need to focus on the content first. Because fundamentally, that’s why users to go websites and web applications. So start from the content and work your way out to the user interface.
That means that some groups get more input than others. Sorry.
First dibs in content and API design: People who know what the content is
Step one is to simply know what the hell is going in this thing. This is where you need people who know the strategies and goal of the project and fundamentally what’s in it for the end-users.
These folks will tend to be information architects, editors, reviewers, copywriters, translators, and SEO people.
They should establish:
- What kinds of content you have
- Global content: headers, footers, navigations, menus
- Page-specific content: articles, banners, heroes, cards, image collections, accordions
- Content vs Control vs Label distinctions
- When is an image content vs being design?
- How do buttons and other user controls get their text?
- How do table headers or modal headers treat their content?
- Information hierarchy
- What are the page types?
- What kinds of content are on each page?
- What is the URL strategy for the site / application?
- Your translation and localization strategies
- Is the entire page always translated, or only parts of it?
- Will the translation be reflected in the url?
- Will the localization be reflected in the url?
Second dibs in content and API design: People who know what the business does with content and who needs it
These could be product owners, business analysts, and really just others who know what kinds of rules need to exist with the data.
These rules might include things like:
- Content and data contracts
- Required fields
- Optional fields
- Default Values
- Content and data variations
- repeatable sets of fields
- multi-value fields
- minimum values
- maximum values
- The conditions under which certain kinds of content or data could change or even not be available
- Pre / post authenticated content (i.e. What’s different before and after a user logs in?)
- Authorized content (i.e. What users are allowed to see which content?)
- Personalized content (i.e. How could content change on an individual basis?)
Third Dibs: People who know what technologies can support the content
Once we know the kinds of content and the rules needed for that content, we need to get our first round of (hopefully) tech experts involved.
These are the architects, product owners — and sometimes accountants. They’re going to consider how the different applications are interacting with each other, the greater project, and the user. Not only that, they’ll consider what systems and technologies they can afford. The choice between PHP, Java, Node, or .net could be a combination of how many concurrent users they’re expecting and how much they can afford to pay for hosting (hence the accountants).
So that means that they might decide things like:
- Technology Stack
- Operating Systems: Linux, Windows
- Server Frameworks: .net, Apache, Django, Express, Ruby on Rails
- Databases: SQL flavors, NoSQL flavors
- API architecture
- One API vs many APIs
- Serverless / microservices
- GraphQL or a façade / Gateway API for consolidating information from different sources
- Rest or API design
- Data retrieval: endpoints, paths
- Data transmission: paths, request bodies, headers
- Data internationalization and localization; how you do all this again for other languages?
- Relational data strategies; how can data from one request refer to data from another?
- Will one response contain a URL to another request?
- Will you use paths on an endpoint?
Finally: People who know how to render content
So first you’ve gotten your content experts and information architects involved to figure out what kinds of content and data even exist. Then you got your business people to establish things when content and data are delivered and to whom. After that, people figured out how that data gets to a front-end.
Now it’s time for front-end to participate by establishing what is needed to deliver a good user interface:
- Controls that protect layout:
- Required fields
- Minimum values
- Maximum values
- Default values
- Controls that protect brand
- Plain text fields instead of WYSIWYG
- Check boxes and radio buttons for discrete control of visual variations
- Signals for different template options
- Data that guarantees accessibility
- Fields to supply aria values
- Captions for tables
- Transcripts for video and audio
- Limitations to prevent inaccessibility
- Requiring alt text for images
- Disallowing off-brand / inaccessible colors in WYSIWYGs
- Data for localization and internationalization
- Content metadata that can signal if you’ve received content in the correct language
- Configuration / management for non-content-managed UI elements that require translation
- Configuration / management for locale-specific presentations (i.e. how will you know when to change date & number formats or change currency symbols)
TL;DR
Should front-end developers be telling everyone else what the architecture is going to be? Absofuckinglutely not.
Should front-end developers have a say in what the architecture is going to be? Absolutely.
What kind of say should front-end developers have? The kind of say that guarantees that the layout and brand are protected from content authors while also guaranteeing that end-users have the most accessible and inclusive design possible.