Don't Make Your Current Site Mobile-Friendly Until You Have A Plan
In 2015, Google scared many website managers when they announced it’s important to have a mobile-friendly website. We’ve since been hired multiple times to “retrofit” existing websites to be mobile-friendly (or better yet, “responsive”).
We quickly learned that simply adding CSS @media queries to existing code is not the quickest or most stable way to go.
Sometimes, however, this was exactly the method we chose because it was the best way to retrofit a website for mobile use, utilize existing content, and fit the changing needs of our clients.
In the interest of determining if modifying the existing front-end code will take longer than rebuilding it, we came up with the following list red flags as a guide.
Responsive Retrofit "Red Flags"
CSS Box Model Sizing:
If the current site uses the older default CSS box-sizing model "content-box" rather than "border-box." This means all the width and height calculations for elements were made subtracting padding and border width and height from the final size, making responsive builds more time consuming.
Set Pixel Widths on Everything:
It's understandable that a static site’s main layout components have set widths (i.e., main content area, sidebar, etc.), however if the contained content also has set pixel widths on everything, it may take a lot of work to undo all of this for a responsive layout. I would consider this more of a "Yellow Flag" as it really depends on how clear the existing CSS is. Use your best judgment here.
If the site makes extensive use of the inline HTML style attribute, beware. Overriding these styles with CSS will become cumbersome and the only way of doing a good build will be removing them from the HTML and rewriting them in your own CSS.
HTML Table Based Layouts:
Need I say more?
Reliance on Outdated Frameworks:
If the site uses an old static version framework for everything, you'll spend more time trying to figure out where to edit it to make it responsive, than starting from scratch ... even if you are lucky enough to have documentation on it.
Messy and/or Uncommented Code:
Guided by this list, we've analyzed many websites for all sorts of clients and industries, and more often than not, determined that it is best to completely rewrite the CSS and add new classes in the HTML markup where appropriate.
For example, when we made the Columbus Symphony website mobile-friendly, we decided to rebuild the CSS from scratch. It hit enough of the markers above that we knew trying to update it from its existing state would have been way too time-consuming, costly, and ultimately ineffective compared to just re-coding the front-end HTML and CSS.
If you’re still behind the times and need your site to be mobile-friendly, get in touch. We can fix that for you.