I was asked this past week to consult for a company embarking on a huge new website redesign. I thought I’d write up some thoughts that I would share with anyone in that position.
Look at any graph of mobile usage and it will tell the tale for you. Millions of mobile devices enter the world every day. Ignore this to your own demise.
Mobile is a whole different world. There is literally less room on their smaller screens. They often have lower bandwidth. They often have user input that desktops doesn’t have (think: swipe, pinch, or shake) and vice versa (think: mouse cursor, right-click, or modifier keys).
Can you handle all of that in a single site? Maybe you can. Responsive design can help with this and is an awesome solution for a lot of sites. But don’t force it at the determent to both desktop and mobile experiences. You might have to split into two – which ensure speedier and easier-to-dev sites. But now there are two sites to keep in sync which comes with its own struggles.
You should be able to ask your CMS for anything you want and get it. I need a full size image of that product – here you go. Now I need thumbnails of related products – here you go. I want the title, subtitle, and intro paragraph of that article – here you go. I want a bunch of content inside of this template – here you go – now the same in a different template – here you go. I want to request some content via Ajax and get just the content back, no markup – here you go. At the outset of a project is a perfect opportunity to build/choose/customize a CMS that works for you.
Need a guide? Try the book Content Strategy for Mobile by Karen McGrane.
Karen says in her talks there are companies that will go out of business because they are so bogged down by their CMS and can’t accomodate mobile and the future of content delivery. I’m sure she is not wrong.
You have options for just about every other technology you choose for a project, but you always need to use CSS. CSS is simultaneously very easy and incredibly difficult (day to learn, lifetime to master). On a large project, you really need to develop a design system. That means re-usable parts and design patterns that help you build quickly and keep you consistant.
Everyone is happier when the code we interact with is clean and consistant. Even if it doesn’t match your own style perfectly, consistency is the most important thing. Establish a style guide. Here’s some to peruse.
Design systems are a lot easier to build (and CSS is generally a lot easier to write) when using a preprocessor like Sass. You can set variables for colors to keep those consistant. You get CSS3 mixins for free with Compass or Bourbon. You can break up patterns into individual files to keep sane and organized. You can compress your CSS as you author so essentially performance is part of your workflow (small concatenated files = fast).
Need a guide? Rebecca Murphey writes about this kind of thing.
Team development requires version control. Git is a solid choice. I’m no version control master, but the popularity of it and resources to be found about it speak for themselves. Branching and merging is fairly easy.
Have a pristine master branch that nobody works from. Then a staging branch. Then individual “feature” branches. You can “merge up” from staging anytime into a feature branch to keep in sync. Then “merge down” features into stage when they are ready. Staging is what you test and where all features come together. Then when ready, that goes to master.
Beyond the obvious advantages of keeping code in sync and tracking changes, it gives the whole team the ability to see what everyone else is working on by looking at commits. This helps team accountability.
That staging branch I mentioned above? That would be good to have auto-deploy (deploy = move files to a live server) to a testing server. Ideally this testing server is as identical to your live server as you can make it. Do your testing there. Then when it’s good, move staging to “production” (you’re live server that your user’s actually use).
Deployment itself is an entire big topic. Likely you are caching assets, so you’ll need to break that cache on assets that change and not break it on assets that don’t.
Can you upgrade your servers on the fly? How do they handle heavy load? Are you load balancing? How is the customer support at your hosting provider? Will they respond 24-7? What are the costs? Are they substantial enough to bring hosting in-house?
Do they monitor your server performance or is that up to you? Your host probably has tools for monitoring server performance. New Relic is an app that can help with that.
Most big websites have someone (or a team) just for handling servers. It’s a unique skillset, different from development.
Every decision you make should be about making things better for the people who use the site. Try to never make a decision based on technical difficulty. That might mean you specifically have UX people. Even better, everyone on your team understands and cares about UX and makes it a priority. This isn’t just a design thing, it’s everything.
Performance is often this thing web teams do “later on.” You have a good opportunity here to make smart decisions about performance from the beginning. Load as few assets as you can. Compress them as much as you can. Cache as much as you can both on server and client. Make sure your server guy is on top of things like response time.
Need a guide? Steve Souders’ books and blog are fantastic.
Building a big website is huge and all-encompassing endeavor. It’s hard to do at all and much harder to do well. You need a team with a fairly wide array of proficiencies and likely someone steering the ship who’s proficiency is ship-steering. It takes time and patience. It takes money. Beyond all that, you all need to be excited about it. You won’t make good decisions if you aren’t excited about what you are building. Struggles are harder to overcome if you aren’t excited to get past them.
I asked on Twitter: “What kind of advice would you give someone about to start a huge new web project?” I got back some good stuff.
@chriscoyier Figure out the time investment and budget and then multiply by at least three.
— Ryan McLaughlin (@ryanmclaughlin) December 18, 2012
@chriscoyier Organize. Organize. Organize. Organize. Design. Organize. Organize. Organize.
— Tim Panicucci (@tpanicucci) December 18, 2012
@chriscoyier fire incompetent devs and hire someone who can do it right from the start.
— Nando Vieira (@fnando) December 18, 2012
@chriscoyier Plan and prototype. Really understand every part of the problems you’re trying to solve.
— Paul Lewis (@aerotwist) December 18, 2012
@chriscoyier For a front end developer, I suggest looking at the whole site and identify the components. Think about CSS architecture.
— Jeff Bridgforth (@webcraftsman) December 18, 2012
@chriscoyier “Measure twice, cut once.” (Or…”Requirements, requirements, requirements.”)
— Chris Cashdollar (@ccashdollar) December 18, 2012
@chriscoyier Buy great Scotch.
— ★ jen strickland ★ (@inkpixelspaper) December 18, 2012