Uniting the team with Jamstack - Trys Mudford - Conference Talk
Hi there. I'm tris. I'm a front-end developer at clear left where we help design leaders, get the most from their products and teams. Through work as an agency. And through our events. I'm going to talk today about how we went from a blank sheet of paper, to a multi-site. Headless cms, and a hyper-performant. Accessible, site. In just a number of days. I'll also touch on how, developers, can communicate, better with stakeholders. And the content, team. And use a web project, as an agent for change in an organization. Like all good stories, ours starts with a meeting. Thanks to kovid. Our portfolio. Of physical events had to be postponed. But like with this conference, an opportunity, arose. Clearleft, decided, to organize, our first, virtual, conference. Sofa conf. An ambitious. Five-day. Online, affordable, event, covering topics such as service design. Product strategy, and research. We had about eight weeks to bring it all together. It was 9am, and we gathered online, to kick off the project. With no more than a name, we began discussing. What we'd need to pull it off. Firstly. We need a website. Event websites, are a bit of a speciality. For us. Having organized, events for the past 15, years, we've built more than our fair share of them. But lately. Most new sites have been created, as annual additions, on top of established, platforms, the 2019. The 2020. Edition. This project however was different. It was a totally new prospect, with no foundations. Or starting, points or leg ups. Or, no baggage, or constraints, depending on how you look at it. It's rare, to have a project, where all bets are off and you have total, freedom. When they come along. Grab them. Developers, tend to be known as the no brigade. The ones that come to a meeting and pour cold water on the ideas of others saying, it's too complicated, or it will take too long. Come at a project meeting with an attitude, of experimentation. Enthusiasm. And excitement. Listen out for those moments where, you as a developer. Can add real value. The big issue we had for sofa conf was time. It was one of those, if we could launch this like, yesterday. That would be great to sort of meetings. We discussed, just building a hard-coded. Site in classic, html. Just to get out the door quickly, and then retrofitting. A cms. Later on. And that is a decent option if you're really strapped for time. But, strangely. I find it's often easier, to get time for a new build, than it is to get time to pay back technical debt. Once something's, launched. Unless it's causing, major problems, it tends to just get forgotten, about. Now our standard, stack for an event site is craft cms. A php. Server rendered, content management system. But it has big downsides. With the cms, and front end tightly coupled together. We end up blocking, the content team, until we've done our job building the whole site. Which often leads to a frantic, few days for them just before launch. We had a long-term, plan to create a centralized, headless cms, that would speed up development. And remove this blocker for our colleagues. But, finding time for it in the company, just wasn't really a priority. As i said, unless it's broken. Things tend to just get left alone. But as a front-end development, team, we didn't abandon that plan. We had a vision for this project. And when the opportunity, arose, we took it. Why. Because making the lives of your colleagues, easier, is a massive and often overlooked, incentive. We work on a global, web where we have no real idea if we're hitting the mark with the things that we create. How cool is it that we can remove the pain points from our peers, with an immediate, feedback, loop. And we're primarily, a front-end development, team at clear left so, why would we care about building a headless cms to begin with. Well as counter-intuitive. As working on a back end project was. In the long term, building a more complex cms, once. Freed us front enders up to work on the things we actually love doing. So despite the slightly ridiculous, time frames and the sheer amount of work building, sofa conf, and this generic, event system, was going to take, this opportunity, was just too good to miss, but, which stack to which, stack to choose. Tech stack choice, impacts the business. You need to be confident, that a decision, isn't being based on the shiny shiny. But on objective, truths that make sense for your organization. Changing, everything, can be a huge risk to a business. And you might be in that situation, where, suggesting, a wholesale, shift to a new stack. Is going to be met with stubborn retorts, like i know that feeling, i spent. Six years in a wordpress, only design studio. We were comfortable, and pretty effective, at building, bespoke, wordpress, themes, but it meant we were totally, blinded, to other better options.
Along With other obvious wins like increased performance. Less downtime. Cheaper hosting. Changing a stack, also has the ability, to unite, a team. Change is your secret, fuel, people want to be part of change, teams gather around ideas, that will change things. As a developer, taking time out to attend this this conference, i have no doubt that you want to try the latest, and the greatest technologies. And hopefully use them responsibly. So, i have some tips for bringing the rest of the organization. Along with you. Number one. Try out the tech first. Side projects or internal projects, are a brilliant place, to try out new tech, before putting into production, with a paying client, or your own company. Use them as a way of dipping your toe into the water. Seeing what works and more importantly, what doesn't. Side projects, give you confidence, to step up, and put forward a bolder solution, when it matters. Number two. Prototype. Jumping, straight into a new build is risky. So use prototypes, as a way of breaking down the problem, before you have to commit to it. Write, throwaway, code, that answers any of those like gut check fears you might have. It doesn't have to be a full, to end solution, either. Just enough, to get you to a point of being confident, that you can deliver, on the whole thing. Number three. Do your research. Unfortunately. Gathering requirements, for the web is a whole separate talk but i've written a blog post on the subject should you wish to find out more. To summarize. I start by gathering the whole team, designers. Stakeholders. Marketers, developers. And we work out on non-functional. Requirements, i.e. How the system, should work, and then our functional requirements. What the system should do. Then i'll gather a long list of stack options. And then mark them up with a weighted, ranking, to ensure that all our requirements, are going to be met. Now, break down those top results, from the ranking. Further with pros and cons, discuss the risks, as much as the benefits. And this should all feed into the beginning of a conversation. With the rest of the team. And number four. Change, one thing at a time. The scientific, method of control. Pays dividends, if you've got wary stakeholders. Changing, one thing, minimizes, risk, and can hold the key to unlocking the go ahead on a project. That doesn't necessarily, mean, only changing one thing. But changing one thing that affects, your stakeholders. Take a new cms, for example. Making the jump from one platform to another is a big step. Not only is there like a mass migration, of content, a full rebuild, new infrastructure. There's now a whole bunch of training that has to happen, to get the rest of the company, up to speed with the new system. For sofa conf, we could have even, could have either chosen a cloud cms, designed to be consumed in a headless way. Or kept the cms, the same as it is currently. And then added a headless endpoint. The first changes, everything. The second, exercise, is control. Now these tips are all a way of increasing, your confidence, with a platform, before you pitch it to others.
So To minimize, impact, we tend to use monoliths. With centralized, data. Connecting, to one database, is costly enough so why would you connect to multiple. But in a jam stack driven site, we don't have those limitations, in the same way because we're pre-rendering. Content can be fed from several places. Markdown, files, image repositories. Api, calls graphql. Queries. This means we can store, content, in its rightful, place. And those heavy database, queries i mentioned earlier. It's not a problem for jam stack, as the fetching happens at build time not at run time. You can scale down those big api, and content servers that currently have to serve every single request. And go for a cheap, server that only gets hit when the site is rebuilt. And if you need to convince your financial, stakeholders. This can be a powerful motivator. But as a user centered developer. The key differentiator. Of jam stack over other methodologies. Is the user, over, developer, attitude. With jamstack. We take on the performance, hit, so our users don't have to. That longer build time that it has, isn't there for a mistake, it's it's there for a reason. If it's minutes for us, but we're saving, seconds, for thousands, of our customers. I think it's a price worth paying, i think it makes economic, sense, but it's also the right thing to do. And in the monolith, world, there's a bit of a glass ceiling for creating a high performing, website. Surprise, surprise. Time and money tend to be the limiting factors. And if you're a freelancer. Or working in a small agency. Shared hosting is often all that's attainable, and affordable. But jamstack. Puts, global performance. Into the hands of the masses. It's in reach for all those developers, like i was who don't have vast budgets or time for performance, optimization. When you've just got to ship that next website. Now back to the story. Writing, technical specifications. Seems like a job for a developer, right. Well, kinda. Sure deciding. Database, entities, and components. Might be a technical, job, but it's also a great opportunity, to bring in the experience, of the rest of your team for a better result. This is one of the personal highlights of this project for me. I spent a couple of hours, mapping out the system with my colleague sophia. The events coordinator, who would ultimately, be the one who was using the system. With her, wealth of events knowledge and my ruthless, determinism. To make things as generic, as possible. We landed on a list of models, and fields. She was able to share what caused her pain with the previous cns's, that have been built for her, and i was able to put forward fixes. Without her input i'd no doubt have created a bunch of future headaches for her, and what a joy to be able to alleviate, those at the start of a project. We designed, the cms, there and then, and were able to share the entities, and the endpoints. With the designer, to let them know what data they had to play with. Now once planning was complete. My first goal was to deploy the cms, as soon as possible. We all know that good web development, takes some time, and there can be an unfortunate, but not always, unfounded, attitude, in our companies, that, developers, always deliver late.
And Choosing responsible, technologies. We had a maxed out lighthouse, score, as i said earlier, global performance, is available, for everyone, with jamstack. This is the fastest, conference, site we've ever built so our users will be happy. The cms, was totally, tailored to the events, and we're consistent, platform going forward, so they were happy with the events team. It was built in record, time and it's going to speed up future builds so all of our stakeholders, were really happy. And finally. It was built with modern web tools, and so the front-end team i was happy. We maxed out our internal scores as well. We got the site live in a number of days, we sold out of early bird tickets within two hours, and it was a huge team success, with genuine, collaboration. Brought together with a jam stack approach. I hope you found that a useful story with some, handy tips in there for how you can gather requirements, more effectively. Choose appropriate, technology. And bring your organization. Along for this exciting, jam stack ride. Thank you so much for listening. I've got a few minutes now for any questions, if you'd like to type them in the chat window, and if not just have a great time at the rest of your conference. Thanks so much.