In this excerpt taken from the upcoming book, Front-End Architecture: A Modern Blueprint for Scalable and Sustainable Design Systems, Micah Godbolt details the history of this new discipline and explains why it is such a vital role to embrace in our industry.
With the evolution of the web came changes to the roles of the modern web team. We went from a small group of generalist webmasters to a team of talented specialists. As each of these specialties developed, and members became more proficient in them, the web began to form a new set of roles… or disciplines.
Those who strategize about content
Very early on in the development of the web there was a particular personality that seemed to believe the words on any given page were at least as important as the design, the code, or even the Search Engine Optimization. Before they came along, content had always been a problem to deal with later. “Just throw up some lorem ipsum into the design and move on”. The client will eventually fill it in with real, quality, inspired content before the site goes live… really… always.
These lovers of words were ultimately quite vocal that the web was content, and that it deserved our time and attention. It was always a battle, but occasionally they were invited into early planning meetings, and on occasion they were contacted to lend their expertise on proper SEO techniques or to develop a consistent voice and tone for the editorial strategy. They were making progress, and though the fight was difficult and lonely, the results were worthwhile.
Thus went each of these lone warriors until the fateful day where they happen to come across another logophile, and they realized that they weren’t alone in this struggle! This single kindling of a friendship quickly grew into a blaze of new connections. Eventually a community of these word disciples was formed, and they continued to focus their efforts on convincing others to treat content as a valuable asset, and not a liability.
A dozen years passed and the fight for content was far from over. But even as one more designer was asked to “just make something up” for the homepage copy, a new rallying cry could be heard in the distance. December 16th, 2008 was the day that Kristina Halvorson stood up high atop A List Apart Blog and raised a banner for content strategy. She asked us all to “take up the torch” and begin “treating content as a critical asset worthy of strategic planning and meaningful investment”. Those who practice content strategy were to “Learn it. Practice it. Promote it”. They were to become content strategists. And like that, a discipline was born.
Ms. Halvorson’s article was not the first one to approach the topic of content strategy, but what it did was define the heart, soul, and purpose of content strategy, and the Content Strategist. Overnight, a large group of web content creators realized that they had a name, a discipline and a collective calling. These disciples would usher in an era of blogs, podcasts, and conferences revolving around this simple notion that “content mattered.”
A responsive web was born
Around the same time, a man in a black turtleneck got up on stage and utterly ruined everyone’s conception of what an internet connected device was. For the first time in the history of the web we were truly forced to accept that websites were not browsed solely on 1024 x 768 pixel screens in the comfort of our offices and living rooms with the fat pipes of broadband internet. The introduction of the iPhone ushered in a new era of web connected devices with a multitude of screen resolutions, varying capabilities, fluctuating connection speeds and inconsistent input modes. As developers we could no longer make assumptions about our user and the properties of the device they were using to view our websites.
In response to this shakeup we tried a number of different solutions. We tried relying on pinch and zoom, or double tap to zoom, leaving our sites mostly untouched, or we used user agent string detection to redirect any mobile device to a stripped down, mobile friendly m-dot website. Neither solution really solved the problem. Pinch and zoom sites were difficult to navigate in order to finalize purchases, or sign up for services, and increasing mobile traffic meant increasing lost revenue. M-dot sites, which more user friendly for mobile devices, required development teams to maintain two separate websites.
Many m-dot sites languished, failing to be updated as frequently as their larger sibling, or the reduced feature set of the m-dot site forced users to switch to desktop devices to do anything more than get directions or place a phone call. It was obvious that something needed to be done. Though some considered the iPhone a passing fad, it was soon quite obvious that the future of the web lived inside of these small, personal screens.
Three years after the release of the iPhone, the web development community got the mobile solution they had all been waiting for. On May 25th, 2010 Ethan Marcotte penned a lengthy article on A List Apart called simply, “Responsive Web Design”. This article did not describe some new discipline, or a banner for embattled developers to gather under, instead “Responsive Web Design” or RWD described a method for creating a new breed of website that would respond to the size of the user’s device and mold itself to that viewport. He described this process, not as some new or emerging technology, but rather a collection of already existing tools and techniques.
RWD was nothing more than a combination of the following:
- Fluid grids – percentage based widths rather than fixed pixel dimensions
- Flexible images – 100% width images fill the container they are put inside of, and flex as the viewport changes size
- Media queries – being able to specify different styles for different viewport sizes, we could now change page layout based on the size of the screen.
All of these techniques had been available in the browser for years before Mr. Marcotte’s article, but just like the article on Content Strategy, Responsive Web Design was able to clearly explain how these tools could be put together to achieve a result that everyone was desperately looking for.
I can still remember reading that article for the first time. The imagery used in his examples make my first exposure to Responsive Web Design very easy to recall. I remember practically smacking my forehead, because none of it was rocket science, but the resulting effect was magic. Shortly after reading it I built my first site using those techniques… it was a horrible site, but it worked! Since that day I have not been involved in a single project that did not embrace those 3 pillars of responsive web design. In a single blog article my career, our profession, and our industry was transformed almost overnight.
The seeds of front-end architecture
I started to think about the notion of Front-end Architecture in the middle of 2013. As a Drupal front-end developer I knew full well the pains and frustration felt by content strategists. The front-end styling, or the theme, was always an afterthought. It was a layer of ‘pretty’ applied to the default markup after the designers and back-end developers had finished their work. The challenges we faced couldn’t have been better exemplified than in the order in which people were brought onto a project. As part of an agency I saw projects start, designs debated over, functionality developed… and then a front-end developer was pulled onto the project to apply whatever design was tossed over the wall to whatever markup was thrown at us.
Having gone through this process several times I knew the pain and frustration I was going to experience as I tried to deconstruct a set of mobile and desktop photoshop documents into a theme that could be applied to the div soup that Drupal spit out. Speaking to Rails friends about the challenges of styling a website navigation I eagerly confessed “One does not simply change Drupal navigation markup,” and it was true! Once that markup was set, and the developer had moved onto another task, the chance of modifying the combination of divs and lists, and links was all but a dream. This inevitably lead to ridiculous CSS hacks to make a design, never meant to fit the default navigation markup, actually work in production.
For many years a front-end developers worth was measured in their ability to create these Frankenstein design patterns. “Now if I put a pseudo element on the 3rd nested div, and use a background image from this sprite…” was the epitome of our battle plans, and frankly it sucked. We were doing nothing but patching up holes in a failing levy, and our only hope was that the site would launch before getting swept away by the piles of technical debt we were leaving behind us.
I knew then that this process for developing websites wouldn’t be sustainable as the complexity of our projects continued to grow. So instead of doing things the way we’ve always done them, I decided to start imagining how a project would differ if we made front-end development, as Kristina would say it, “a critical asset worthy of strategic planning and meaningful investment”. What if we had a voice in things like CSS frameworks, documentation tools, build process, naming conventions, or even the markup itself?! I started to wonder what a large scale project would look like if UX development fed backend development, instead of the other way around?
Would this create a revolution? Would others pick up the same torch and start to “Learn it. Practice it. Promote it.”? But before we could all rally under a single banner, it was important to understand what that banner stood for. What were our demands? How would we accomplish our goals? What would we be called?
What’s in a name
Seeing as my current employer did not have a role doing this type of work, I started to research other similar job titles, hoping to find one that was at least similar. After a bit of digging I found that after senior developer the next role was a “software architect.” Reading the job description made my heart skip a beat! The role of a software architect was to come onto a project very early on to discuss the needs of the client with regards to the platform. What technology stack were we going to use? What were our content types? How was content created, stored, and displayed back to the screen? I realized that the role of a software architect was to make sure that nothing was ever created by chance, but rather guided by an overarching architecture. It didn’t take long for me to convert database and web server to Sass folder structure and build system, and the title of front-end architect was born.
Now that I had a job title, I went to modifying the job description thinking what this role would bring to the table, and how it would impact a project given the proper opportunity. These ponderings lead to a quick lightening talk about front-end architecture at our annual company retreat, and a submission to CSS Dev Conf that got accepted and forced me to focus my thoughts into a concise 45 minute presentation.
“Raising a Banner for Front-End Architecture”, given to a packed room in New Orleans, was a rallying cry for front-end developers who had already been on the front lines of this fight. I wanted them to know that they were not alone, that there were others out there to support them and back them up. I also spoke directly to the project managers and sales teams outlining the power of a properly architected front-end and the value that it brought to the team and to the client. The only way we were going to be able to make an impact on projects was to be brought on earlier in the process, which meant clients paying for those hours, and managers being willing to schedule those resources.
After the talk I heard story after story of developers who finally understood who they were, and the role they played in their organization. Many people found themselves performing the role of front-end architect, but had never taken on that title, or felt confident enough to ask for the authority the position should carry. The weeks after CSS Dev Conf saw many people changing their Twitter bio’s to read “front-end architect”. And I, being one of those to make the change, haven’t looked back since. No matter the title I currently hold at my job, I am a front-end architect.
Public domain architectural image via Pixabay.