Queue Thursday morning and it’s time to get started. We know we’re building the foundations of a new website, and we want to start it off correctly. To do this, we’re going to follow what we call the ‘Assembly Process’.
Assembly Process
If you’ve worked with Cesia or myself in the past, you’ve probably seen this diagram. It’s what we refer to as the ‘Assembly Process’, and it boils down to how we like to tackle and execute the construction of a website. There are three key roles that are able to consume tickets and produce testable, demonstrable results: Content Analyst, Front End Developer, and Back End Developer. While each has their own responsibilities, they come together in various ways to figure out how something should be built in Sitecore. Of course, depending on how large your site is this process may continue for multiple sprints, or may only take a single day. It really depends upon how much scope you need to implement.
Prerequisites
Before I talk about what we actually do in the assembly process, I want to make sure that you understand that there are prerequisites and other team members involved. Part of our process involves a hand-off of design compositions created by our creative team. We typically coordinate this through Invision and Zeplin, as they are amazing collaboration tools that clients, designers, and the assembly team can use to pick apart design and infer meaning.
As you can see in this example, Invision allows for collaborators to leave comments upon design mocks. Designers can control who can see their mocks, and can annotate directly on the composition. When executed correctly, the front end developer can inspect the raw files to understand colors, fonts, padding, and other visual attributes. Having a design mock ready to go drastically speeds up assembly time. For this particular story, our designer created a mock early in the morning and we were consuming it by lunch time.
Another very important pre-requisite to consider is imagery and copy. In the model that we employ to assemble websites, we don’t generate the copy and imagery. It should be pre-defined by either a content strategist, designer, marketing agent, or any other relevant stakeholder. Something else to consider that can cause hiccups: all copy and imagery should align with the proposed design. This seems like a no-brainer when spouted out in a blog, but this is one of the most critical and fragile aspects of assembly. If copy and design don’t align, the Content Analyst will churn and assembly will take a much longer time.
Finally, we need to know what we’re building. This is where our business analyst works closely with the product owner to understand what they’re trying to achieve. You don’t want to run off and just start building things for the sake of building things. You need to know what you’re building and, in most cases, why you’re building it. Having a good Business Analyst working alongside a good Designer makes the assembly team’s life much easier.
The Roles within Assembly
The Content Analyst
The Content Analyst should be thought of as a specialized Content Author. It’s someone who has an intimate understanding of page construction in Sitecore, as well as knowledge of all available accelerator components. They need to understand not only how to build pages, but all of the pain points around building pages. They perform analysis of copy, they define URL structures, they organize the media library, they build pages, and much more. In a nutshell, they are responsible for: Site Organization and Analysis, Information Architecture and page organization, and final page construction.
In terms of collaboration, the Content Analyst and Front End Developer sit side by side for a large majority of the early phases in assembly. They work out which components to use and how the page architecture will look. One of the fallacies that immature assembly teams make is thinking that the pages can just be thrown together with random bits of content. In reality, this is very far from the truth, as every rendering you place on the page impacts the front end developer. Do I need a stripe or a 1 column widescreen rendering? Do these renderings need to be nested within a Stylebox for grouping in CSS? How do we handle the variations in the different designs of Heroes? Which components are used in the header?
The most important aspect of the back-end developer and content analyst collaboration is on page templates. Defining page types, configuring presentation elements on standard values, and establishing branch templates. We do a few other things as well, like system integration configuration (e.g., establishing an ‘Add This’ account for the website), and programmatic uploads of content (maybe a blog post on that later?)- but without templates set up, the Content Analyst is effectively blocked. What you’re trying to shoot for is: 1) establishing which page types you need, 2) and figuring out which components are used on the page to give it the look & feel of the design language, 3) in a way that the front end developer can consume, 4) with repeatable templates structures and branches, 5) that is cache-able, performant, and meets the needs of the business. Simple, right? This is the entry point to mass assembly.
The Front End Developer
Let’s face it, most of us developers are bad at front end. We know just enough CSS to establish simple designs, we can do some jQuery animations, and that’s about it. The idea here is simple: the front end developer is responsible for everything visual on the website, and they don’t really have to worry about Sitecore or the underlying CMS technology. This includes animations, colors, responsive and mobile implementation, cross browser support, and more. The Front End Developer collaborates with the Back End Developer on any custom components (read: renderings) that need to be established. Together, these two roles work out an HTML contract on each and every rendering, as well as coordinate the implementation of any JavaScript necessary to drive the website. This is an important role, and without it your back end developer will be burning precious time trying to figure out tedious bits like why-does-that-animation-not-work-on-safari-mobile?
The Front End Developer sits even closer to the Content Analyst. Subtleties in styling and design lead to interesting ways that components need to be organized. Grouping components, adding style selections, using proper containers- these are all things that need to be worked out, and they get worked out by the Content Analyst and Front End Developer coordinating their efforts.
In terms of tooling- this is a bit of a grey area. At Brainjocks, now Perficient, the Front End Developer doesn’t run Sitecore on their local machine. Instead, they style against the content being assembled on the server directly. Browser plugins like CSS inject become critical here, as well as automation that takes any committed CSS/JavaScript and kicks it to the server directly on source control commits.
The Back End Developer
As you may have read in the previous post, We Built a Site in a Day Part 1, the back end developer is solely responsible for ensuring that an environment is up and running for the assembly team. Automation is the name of the game here. Without a server to work out of, the content analyst is blocked. When the content analyst is blocked, no pages get created. Without any pages, the front end developer has nothing to work with, and they become blocked. When the Front End Developer pushes CSS changes, those changes need to deploy to the server automatically. Without frequent CSS updates on the server, the Front End Developer is also blocked. Keeping the team unblocked is the number one responsibility of this role.
Once your team is unblocked and moving along, the next primary responsibility is on establishing page templates. Remember, we’re using an accelerator here, so we have a handful of generic re-usable components at our disposal from the get-go. Here’s how establishing page templates should work:
- Back End Developer: Components completed (including testing) for page type, and deployed to assembly environment for team. In the case of this story, we used all components from our enterprise accelerator and didn’t need anything new created.
- Content Analyst: Assemble single test page with mixture of SCORE + Custom components. Coordinate with Frontend Developer on any necessary style selections.
- Front End Developer: Style test page according to Design.
- Back End Developer: Analysis on test page and configure standard values + branch template. This configuration should include Caching, Selections, and considerations for language/presentation strategy. Check into Source Control any necessary snippets, selections, templates.
- Content Analyst: Rebuild single test page using the new standard values and/or branch templates. The Content Analyst is effectively testing the templates.
- Content Analyst + Back End Developer + Front End Developer: All agree that page template type is complete.
- Designer (optional): Provide creative review to ensure that page meets their design language.
- Ready for mass assembly and/or automated import.
Finally, any custom components, hotfixes, or other server-side responsibilities fall upon the back end developer. Typically, if we know we’re going to have a significant amount of custom components, we may decide to build and tackle those as a pre-requisite of assembly. You don’t want to have to go back through 200 fully-built pages just to add a new rendering, do you? Instead, you should get that rendering in front of the rest of the team before you start down the assembly process. Again, this is where an enterprise accelerator really starts to shine.
Separation of Concerns
A place for everything, and everything in it’s place… so to speak. I’m afraid to inform you that there is no ‘secret sauce’, and there are no unicorns that work at Brainjocks, now Perficient. At the end of the day, the trick is to separate into dedicated, specialized roles and work together to achieve something greater than the sum of it’s parts. Coordinated, methodical work is the only trick. I know that we often say that specialization is for insects, but look- insects didn’t build a website in a day.
