Unity

Around the office, Digital Telepathy's main website was affectionately known as Unity. During the most recent major redesign (Spring 2014), I was the lead developer on the project. Ultimately being responsible for delivering the working website, I first contributed by offering a developer's perspective to many of the strategy sessions that led to the redesign.

When it came time to write code, as we were starting from scratch, I was able to make a handful of new technology decisions based on lessons our team had learned from maintaining the previous site's codebase. With our direction decided, I led the development team, managing the division of the work, as we constructed the redesign together so the new structure and conventions would be familiar to the entire team.

The first slide of the current philosophy page (formerly the homepage) on Digital Telepathy's site.

Some important things I learned

  • Always make it better than last time

    Leading into the project, the head of the development department and I agreed that the redesign provided a great opportunity for us to ditch the rarely-used CMS from the previous site and transition to a static site (generated via Middleman) to expedite the response from the server. We also took advantage of the shuffle and wrote a deploy script. Instead of looking up various credentials and remembering what systems to log in to, we could run a single command that would push edits to the repo, sync the changes with the server, and clear any server-side caches.

  • Imagine your work in the future

    While prepping to write fresh code for the site, it was important to imagine how our team might feel about it 6 months later. In terms of file structure, I opted to shy away from generically named partials like "global" to keep code easy to find during future maintenance visits. Also, our team agreed to leave explanatory (and often humorous) comments in the code for anything that wasn't business-as-usual to ease ramp-up time when stumbling upon the pricklier pieces of the codebase.

  • Explore crazy ideas (or don't always say no)

    One of my personal favorite sections of the site was a temporary piece for the initial launch (until we had the bandwidth to execute the full idea). It was also one of the trickiest designs I'd had the pleasure of expressing in code (a responsive, mid-page, full-screen lava lamp takeover with scroll-controlled color evolution and smoothly updating content). I had no idea what the code might look like. Though the designer and I made back-up plans, I broke it down, piece by piece, and figured out a way to make the section, as originally designed, a reality...for the first month or two, at least.

  • Be understanding when they ask for it sooner

    Everybody is excited to see a web project come to live, but the work that happens between a finished design file and a living website is still a mystery to many. During the course of this project, I learned the importance of listening to the project's objectives as explained by the rest of the team and communicating why something would take as long as I thought to code by providing a high-level explanation of the work to be done. We had some difficult conversations to decide which pieces would fit in which phases and map out a plan that met our goals.