This is a series of several posts broken out from a single presentation.  I originally presented a consolidated version of this to a group of Web Design students as a guest lecturer at Philadelphia University in March 2015.  These are some of the points I made during those 2 hours, based upon my experience over the last 15 years.  This is Part II.  Read Part I.


It was my first year at Anthropologie, and I was an integral part in their 2008 website redesign.  It was just me and another front-end developer, and we only had 1 lead web designer who was in a different department.  When I look back on that today, I’m amazed at how much we were able to achieve without Project Managers, QA Analysts, and SEO Specialists — but it was also a period when we didn’t get as many web feature requests, and times were simpler.  The designer went through the site, mocked up new designs in Photoshop, exported them as PDF files, and sent them to us to apply their designs to the website.  

Courtesy of An Event Apart 2012

Courtesy of An Event Apart 2012

The whole process was similar to traditional print design, where one team would hand off work to another team to execute.  This is also when the “waterfall” style of project management worked really well.  It certainly helped that the site that we started with was relatively simple; it had a fixed width, and it was left-aligned.  Our subcategories were populated by a Javascript dropdown menu (which was bad for SEO) and we had inline CSS all over the place.  Our checkout UI was in Flash (that remained untouched during this redesign).

Courtesy of Wayback Machine

Courtesy of Wayback Machine. This was the basic layout with some missing styles.

As developers, we did a great job applying the designer’s comps to pixel-perfection.  It didn’t matter what size my browser was; we only needed to design for 1 size!  The first iPhone had made its debut the year prior and nobody would be using that to browse webpages unless they wanted to pinch-to-zoom in all the time, right?  As for the variety of browsers at the time — well, the majority of our traffic came from IE6 so that was where we did most of our QA (and yes, we did all of the QA ourselves as a team).  Chrome wasn’t out yet and our demographic was mostly using IE, Firefox, and Safari, in that order.

Courtesy of Smashing Magazine

Courtesy of Smashing Magazine

If the text on the site needed to be a pixel to the left or to the right, I would adjust it.  And regardless of how differently IE6 rendered fonts, I still did my best to ensure that the site looked exactly like the comps that the designers created in Photoshop on their Macs.  I’d even take a screenshot of the site and overlay it on top of their PDF file.  They matched up almost perfectly!

They sent along “slices” and we took those slices and put them where they needed to be, using whatever method made sense at the time — either by embedding the image directly in the HTML/JSP or making it into a background image.  No compression or anything fancy, it was purely just trying to apply designs to meet specifications.  To eliminate some of the back-and-forth between designer and developer, we asked for the PSD files instead of PDFs, so that way, if we needed a different size for a slice, or if we needed it in a different format, we could do that ourselves.

To reiterate, it was a much simpler time for web design and development.  We:

  • Didn’t worry about front-end load performance.
  • Didn’t worry about dynamic data overflowing outside of a perfectly styled background image.
  • Didn’t worry about error states of forms.
  • Didn’t worry about SEO.
  • Didn’t worry about accessibility.

I should mention at this point, that this is an antiquated process for redesigning a website and this method would not work as well today, since there are a lot of other factors to consider!  More on that, and the future of front end development in an upcoming post.

And the result?

There were a lot of fonts and colors, and we kept a lot of deprecated styles in the code because we weren’t sure if they were still being used.  We couldn’t just search through our codebase because the reference may have been coming from elsewhere.  So we decided to create a style guide and the onus wasn’t completely on the designers just to create one, but it was also the responsibility of us developers to consolidate the code and streamline the styles throughout the site.  We hadn’t used semantic markup, HTML5 didn’t exist yet, and CSS could have been written in a separate file, inline with the HTML, or worse yet, it may have been returned server-side with some markup that was embedded in with a piece of data.  How did our code become the way that it was?  I think 2 of the most common culprits were a lack of enforcement around code/design standards within our teams, and also the sheer number of people that updated our site on a daily basis outside of our teams.  Not only did we have developers within Anthropologie that touched the code, but we also worked with distributed teams that contributed to the site and each group had their own standards.  This is a problem for most large companies, and even if you’re at a small company, you’ll see this problem happen as you begin to grow.

So there’s a challenge, and a solution.  The challenge is that styles are coming from all different sources, written by a lot of different people.  You’re not going to be able to refactor the code overnight, nor will you be able to come up with an end-all be-all style guide in a day, and even if you did, by the time you do, you’ll end up needing to do another redesign and create a new or modified style guide all over again.  One of the best ways I’ve found to combat this smorgasbord of code is education.

“All code in any code-base should look like a single person typed it, no matter how many people contributed.”

– Principles of Writing Consistent, Idiomatic Javascript

When you on-board a new person onto the team, make sure they have a central source of documentation where they can find what the team’s policies are on coding standards.  Conversely, if you are the new person, ask what standards they have in place, and if they don’t have any yet, then start documenting what you’re doing so you can pass around that information and share it with everyone else.  Future generations will thank you for it, and your future self will too.  Think of all those times you were working on a project and you say to yourself that you’ll clean it up later or that you’ll remember that you used a certain naming convention for your Sass variables one way over another.  You won’t have time and you won’t remember later.

Unless you start your own site from scratch, the site you’ll be working on is one you’ll be inheriting from some other person that was there before you, so document judiciously and adhere to a standard format.  Luckily, these days there are tools out there that you can use to help standardize everyone’s code like CSS Lint or JS Hint.  We didn’t have that back in the day, and I think these tools are a testament to the fact that there was this inherent problem of being able to easily understand and update someone else’s code, especially as companies’ websites have started to mature — and having a consistent format ensures the scalability of your code later on.


In the next post of this series, I’ll go over how we applied the learnings of past redesigns to help in the decision-making of Redesign 2012… and some other new challenges we faced as the shift to mobile web was happening.

Comments

comments