by A year or so ago, Google dropped a bomb on all website designers, publishers and online content authors: Your websites had better not only be SSL-secure, but also “mobile-friendly” — and while the first edict is easy to solve with money, the second command costs you a lot of time and money and energy — especially if you’ve been publishing live content on the web for a long time.
The Jedermann code phrase for “Google mobile-friendly” is “responsive design” so if you bump into those two concepts on your search down the design road, they both mean the same thing: “Make Your Websites Readable and Functionable for iPhones and Everything Else You Hold in Your Hand” or your Google Search rankings for your websites will tank!
I’m glad to share some evidence of that Google-stamped “mobile friendly” search return success for — Boles.com — but getting that approval wasn’t easy.
First, here’s a little bit of background on how this all came to be from where I’ve been. This is not a tutorial. I’m not taking a techie viewport for this article. I’m sharing with you a process of discovery and implementation and then providing you breadcrumb pointers if you are so inclined to enter down this darkening pathway. There is a lot of information online to help you through a redesign of your own.
I’ve been actively alive on the internet since the early 1990s, and hardcore online, non-stop, since about 1996 or so. I was an early web developer and author, and so getting your work out there and alive on the web was a valuable, important separator for many tech writers and publishers.
Being online so early and so fast meant I had a lot of legacy code across all my websites. Really old, clunky, Macromedia Shockwave sort of stuff, and bunches of hard, non-variable, tables and other riff-raff that was common to the day.
With each new renewal of an HTML update over the years, I’d do my best to keep all my sites right and up and humming up to standard, and that scratch and play melody mainly served me well with simple, fast, functional websites.
I enjoy design and crafting logos but, most of all, I’ve wanted my pages to load fast, and that, for me, always meant flat-file websites with hand-coded pages — no databases — running on really fast backend servers.
A year ago, I stepped in line and made four of my websites SSL-capable: Boles.com and BolesBooks.com and HardcoreASL.com and ScriptProfessor.com because they are my main business websites. BolesUniversity.com and SOSasl.com and DavidBoles.com remain unsecure because they are not really public-facing in purpose, and their job is to serve more of my hidden, backend needs.
This David Boles, Blogs site is non-SSL and hosted on a WordPress.com business account. WordPress.com does not offer SSL hosting for my type of business blog.
So, my main sites were SSL secure, but I still had all this old legacy code, much of it created using Notepad way back when, and while I had functional websites, they were not “mobile-friendly” or easy to read on an iPhone or other small screen device.
In April, Google started noting in their search returns if a website was “mobile-friendly” or not — when searched while using a mobile phone — so the large, looming, question for me was: Do I play Google’s game, or do I just stay with the status quo?
I know in 10 years, “mobile-friendly” websites won’t matter much because smartphone screens will be bigger, “desktop-readable” and we’ll have 5G internet, so large file sizes and big images will load in the split of a second.
What about the now and the then until 2026?
If you want to be fluid-thinking and forward-moving, you must make the decision to act now. To get a “viewport friendly” website working and playing takes time and effort, and if you don’t play along, you’re going to get left behind by people who only “see” your work on a tiny mobile screen and not on a giant desktop display. You want eyes to reflexively see what you intend, no matter how they’re choosing to look at you.
It came down to three choices — and those are choices I’ve been actively and compulsively annoyed by for the past six months across 15,000 pages of hand-coded website files — how to update my websites?
First, I could teach myself how to update the files and do it all myself at a carpal tunnel cost to wrist and fingers due to lots of copying and pasting. It only monetarily costs me my precious time. Fix it once, fix it forever (or so).
Second, I could set up mobile subdomain and hire a company to design and host that mobilized version of my website. Simple choice. Expensive. Ongoing yearly cost of around $1800 for four large-sized domains. I’d have to purchase SSL certs for those mobile subdomains as well on a yearly basis or there will be insecure pages between the mobile site and the desktop site. They do all the work, I do all the paying in perpetuity.
Third, I could re-think all my websites and bump them into WordPress.org blogs that I would host myself. That would mean being database-driven and moving everything to another server would be time-consuming and, perhaps, a little dangerous. I’d have to regularly update WordPress and backup the databases. I’d also lose all my canonical HTML links that had not only been built — BUT HAND-FORGED IN FIRE AND BRIMSTONE! — by me since 1996.
After a lot of arguing with myself, I decided to take the harder, faster, smarter, cheaper route, and just update all the websites myself to “mobile-friendly” — and I was going to go all in on being faster and simpler. No fancy nothings. Very few images. Video embeds only when precisely necessary.
I just wanted to keep it all plain and simple and clean to bring the fastest experience for my readers across all my domains. It also helped knowing that many of my images were not “retina ready” — so removing them now, in the event of a future redesign, was a compelling concern out of reality. Sometimes the better path is to not load fuzzy.
Next, I had to decide if I wanted to go with an HTML5 design, or a Bootstrap design, or a hybrid combination of both. There are a lot of free and for-pay “mobile-friendly” website templates out there, but if you don’t understand the genesis of it all, they aren’t much help.
Here’s the rub I could not easily get conquer — there’s no simple conversion tool for taking an old HTML page and making it mobile-friendly. You really have to start all over, think viewports and containers and rows and wells and Jumbotrons and code it from base one.
That was the heartbreaking part I had to get over: All my old code was all going to come down and then get built back up again, bit by byte, hand by foot by mile — until it was all reassembled again resembling something stronger, faster, better.
I also got rid of two things that, together, added about 6 seconds of load time to each page in which they premiered: The Google Custom Search box and a Twitter “Follow” button. Both of them are remotely called from servers I do own own or control, and they load slow-as-molasses when my superfast server calls them to action. They’re both GONE now, and I’m pinched a little because I pay for my Google Custom Search engine!
Since I’m an Adobe Creative Cloud subscriber, I decided to let the Adobe Bootstrap tutorials help me along the way to understanding. Dreamweaver CC 2015 is actually quite usable and friendly in pressing you into the Bootstrap world, and their basic Bootstrap templates became my new, humbler, re-beginning!
I did have to update the Dreamweaver Bootstrap files myself, though. Not a big thing, but not a mindless nothing, neither. Oh, and the fact that the Bootstrap 4.0 upgrade is looming out there somewhere also creates moments in sleepless nights — if I’ll have to do all this all over again next year.
Here’s the Google Mobile Friendly test webpage that I used at least 15,000 times! You use that site to know how Google sees your website and if you need to change anything to get into their right spec. If you’re out of spec, Google will give you specific reasons why. It’s a great help and teaching tool, but sometimes you have to reload the test a few times because Google gets fussy and bored. You’ll learn to know the difference as you do multiple checks and you realize the code reading problem is within the Google Stars and not the dark sky of your domain.
I liked Bootstrap better than standalone HTML5 mainly because Bootstrap spoke to me grander, I understood its concepts better, and I was able to get up to lightspeed faster. All of my websites are now Google-approved, mobile-friendly, and you can visit them as much as you like — and here’s how unfriendly they used to look on a mobile phone.
Since Boles University and the David Boles domains are really just one-page placeholders against behind-the-scenes derring-do — I decided to go for a fancier look and feel in the mobile-friendly redesign for those sites.
Sure, they look super-cool, but they load slowly, and code slowly, and both of those complications were precisely what I did not want on my workhorse websites — but those two domains sure are pretty now to visit for a looksee. Here’s how they used to view in their slow gory days.
That’s the story!
This whole episode was a year in the wondering, and six months in the worrying, and a couple of desperate weeks in the implementation.
I wasn’t sure if I’d ever set the right plan in mind to get everything “mobile-friendly” but I’m glad to report it all worked, and that it was all worthwhile — that is — until the next big web step is demanded by our online overlords, lest we all get left behind in the already-aging, and heaving, sighs of the day.