Posted on: April 3, 2015
In 16 years of developing I haven’t been happier or more excited to launch a website than I am right now. The launch of connectivedx.com represents many things to many people in our agency, but it hits a particularly sweet note with me.
Often, you don’t get to really see or appreciate the aspects of a brand that go deeper than look and feel. But the new Connective DX brand represents those of us in the tech department very well, showcasing the connections across the systems, data, and requirements, and presenting the ideas and goals of multiple people to the world in a meaningful way.
In this post I’ll talk a little bit about what we did in the building of connectivedx.com but also about how our process worked so well.
We changed stacks from PHP to .NET and from Drupal to Sitecore. Drupal has served us very well, and we continue to use it, but we love Sitecore, and our partnership with them over the years has elevated our practice to the point that it seemed silly not to use it for ourselves. We decided to use version 8, even prior to it being released, based on our past successes—and maybe just a little bit of cockiness with having our very own Sitecore MVPs Kam Figy and Dave Peterson undertaking the development and architecture. I’m going to let them tell you about that part of the project in more detail than I can.
We developed the frontend and backend code in tandem for a large part of the development phase. And I’m not going to lie; as the frontend developer, keeping up with Kam and Dave was demanding at times. However, we’ve repeatedly found that this approach is much more efficient than simply handing over the template files for CMS integration in a traditional waterfall approach, because it allows us to assemble the parts in a way that works for everyone.
It’s not without some pain points along the way, but in the end we get the best of both worlds: clean and accessible markup that can be integrated in the CMS without weird hacks, all the while staying true to the experience design. Did I have to rebuild some components to make it work better in the CMS? Yes. Did I have to rebuild some to meet creative standards? Sure. But I did it when it was fresh in everyone’s minds—not weeks or even months later.
This abstraction is largely because of our frontend framework Phoenix, which also took care of so many of the things associated with getting a modern site up and running quickly, with best practices built right in. Phoenix gives us that stable foundation to start designing with the UX and visual design teams in the browser immediately. This is becoming more and more important as we truly embrace design in the browser. Good things happen when the left- and right-brained folks are truly working together.
Optimization & performance
We took optimization seriously from the start, and we took our fastidious nerdery to new heights by continually testing throughout the build process to discern the best approach. To that end, we kept these keys in mind:
- Accessibility compliant output
- Clean CMS integration
- Maintainable code base
Our process covered the gamut: from things like self-hosting our font files to reduce cross-domain network traffic and caching anything and everything we could get our hands on, to monitoring how many times the browser has to perform a redraw while loading the requested page and concatenating and minifying every asset we could, to… well, you get the idea.
This level of optimization is painstaking and requires a willingness to rewrite your code a few times, but the rewards are significant and really satisfying. An end user may not recognize that 15-millisecond speed increase, but they will notice when it’s not there.
Taking “design in the browser” to a new level
Kam and I represented the technical department in all phases of the project, including the planning and assessment phases—well before design even began. Working alongside the creative, user experience, content, and sales and marketing teams, we provided early prototype concepts right in the browser and even introduced high-level CMS architecture months ahead of time—even while we were still tweaking the color palette. This was a huge factor in determining how much we could deliver (and how well we could deliver it) in our timeframe.
This level of continuity between the various teams allowed us to work very fluidly. We didn’t have technical specifications or feature matrices and we even continued to design and redesign right up until the last week of the build phase. Call it agile, iterative, maybe even RAD, but we just worked in a way that felt natural and efficient. We had a lot of work to do, but we knew what was important to whom and why, and that level of comprehensive understanding has a way of trickling down to those little decisions we make in our code every day. This meant fewer meetings, fewer email threads asking for clarification, fewer JIRA tickets, and a lot more efficiency.
More to do
Obviously, there’s always more to do and a website is never done. In the coming months we will assess performance from many angles and work with the Experience Analytics & Optimization, Sales and Marketing, and Creative and UX teams and continue to build upon and improve what you’re seeing today.
We hope you enjoy the site as much as we’ve enjoyed building it.
Posted on: November 25, 2019 In Content, Technology The Content Hub rollout came into focus at Symposium 2019 If you’ve never been to Sitecore Symposium there are a few things
Posted on: October 21, 2019 In Technology On October 16, we celebrated the 10-year anniversary of the New England Sitecore User Group meetup. The group, or #NESUG as it’s come