Incorporating updates and new technologies

One of the challenges of being a web designer/developer in this rapidly-changing environment is that one must constantly be updating one’s skills, not only keeping abreast of the latest changes, but also filtering them, filtering out the ephemeral whims of fashion and technological cul de sacs while incorporating new advances which are useful and widely supported by users’ browsers.

I confess, I’ve been rather remiss in this regard in recent years. I had been building and maintaining sites pretty much the same way for several years, and in last year or two it really started biting me in the butt. Basically, all of the coding languages I use have changed radically.

MYSQL (for interacting with databases) has morphed into MYSQLi.
PHP (which generates the code my sites run on) has had several new versions with significant revisions and additions.
CSS (which defines the visuals) has added many new features.
HTML (the main language of the web) has had a major conceptual paradigm shift, going from the “structural markup” of XHTML to the “semantic markup” of HTML5.

So, I’ve been spending a lot of time and investing many brain cells learning new stuff and figuring out which parts of it are useful, which parts are essential, and which parts are gratuitous fru-fru. But, what good is this information to people who are thinking about starting a new site or who need to maintain an existing site? Let me summarize some of the things I’ve been learning with an eye on that question.

Responsive Design

First off, responsive design (the same site adapts its design to a wide range of browser window sizes) is a much more viable thing than it was just a few years ago. As more and more people surf the web with their cell phones, the web site technologies have adapted.

For a time, many websites required their phone visitors to download a special app to view the site. Madness. I doubt I’m the only one who objected to downloading and installing an app every time I wanted to read a news story. Then, they started routing mobile device users to separate .mobi sites with the same content. Double madness. This reminds me of the bad old days of the mid-1990s, when sophisticated web developers would try to sniff the browser a visitor was using and send them different versions of the same site based on whether they were using Explorer or Netscape. Then, a new version of one of the browsers came out with a new set of foibles, and the developers had to develop a new set of coping strategies. Any attempt to segregate site visitors based on their devices or their browsers is doomed to an ever-accelerating spiral of madness. There are so many different screen sizes, browsers, devices, operating systems, and personal preferences that it’s just not possible to send out different versions of the site to each permutation. The only sane approach for most sites is to have maximum flexibility designed into the site.

This image changes size and alignment in response to different browser widths.

Pretty much all of my sites since forever have used “liquid design”, where the main text blocks were defined as a percentage of the screen width. When the browser is re-sized, the text re-flows to adapt to its new space. That gives the site a significant degree of flexibility, but these designs break down at some point. If the window is the size of a vertically-held cell phone, the result is a mess. For a few years there, the main route to truly responsive designs used lots and lots of javascript. I don’t want to get into the technical details of why I despise this option, but here’s the short version: if you love code bloat and strange behavior in some browser or another, use lots of Javascript.

Developments in CSS which have recently become (nearly) universally adopted have made real responsive design with little or no Javascript possible. Not only text blocks, but images can now be defined by percentage values rather than fixed pixel widths, allowing those images to shrink and expand with different window sizes. CSS now allows “media queries”, which make the browser apply different style rules based on the size of the window. So, font sizes and margins can adapt. Whole sections of the web page can appear, disappear, or move. Images can change from aligned on the right side of the text block with the type flowing around them, to centered with line breaks before and after. This gives designers and developers a whole new tool box to build responsive sites.

If you’re reading this on a computer with a decent-sized monitor, you can re-size your browser window and get a good idea of what I’m talking about. Watch that green image as the window gets smaller. It stays on the right and gets smaller, smaller, then pop! and it’s center-aligned. Then it gets smaller, smaller until it reaches the width of a vertically-held cell phone. Also, notice the section navigation block, where the links to other website articles are listed. On a wide window, this is a sidebar on the left. On narrower windows, it jumps to the center, down below the article. Font sizes and margins also adapt.

So, if you want to build a new site, it should almost certainly use a responsive design. More and more web traffic comes through cell phones these days, and search engines are threatening to penalize sites which are not mobile-friendly. If you have an existing, non-responsive, site, you should consider updating it. Responsiveness retrofitting can be a substantial job, so if your site isn’t a money maker, and you’re not super-concerned with the experience of vertically-held cell phones, you may need to opt out for now.

Secure Servers (https instead of http)

Once upon a time, a domain-specific secure certificate was a rather exotic thing. Most shared hosting accounts allowed you to use a shared certificate, so most small sites didn’t need their own. There was a frightful performance hit attached to using the secure server; even a simple text page took a looooong time to load. The notion of using a secure connection for graphics-heavy, non-sensitive pages seemed ridiculous. So, I’d just connect to the secure server when sensitive information, like credit card numbers, was being transmitted, and use the regular http protocol for the rest of the site. But now, servers and connections are faster so there’s little or no performance hit, secure certificates come as part of most hosting accounts, hackers are a bigger problem than ever, and search engines are threatening to penalize sites which use the non-secure protocol. So, gosh-darn it, my new sites use https throughout, and I’m gradually updating the existing ones to enhance security. Fortunately, it’s not a big job to switch existing sites to secure connections.

So, yes, new sites should use secure connections. Existing sites using the old non-secure protocol should upgrade as soon as practical.

Back-end Shenanigans

I threw in a random pretty picture because there are just too many words on this page.

Sometimes changes occur in the web world which are not visible to site owners, but require developers to update the code which runs the site. For example, a couple of years ago, I noticed that some of my sites were generating huge error logs. Server computers dutifully record a range of problems in an error log, a text file which developers can access and use to troubleshoot the problem(s). In this case, the host had automatically updated the versions of PHP and MYSQL which the sites were using. Each MYSQL query, and each time the results of that query were used, a warning was written into the error log. Some pages would generate hundreds of warnings with each page view, so these logs got very large very quickly. The sites continued to work just fine through all of this, they were just generating enormous error logs. Eventually, with newer versions, the old queries would stop working entirely; we needed to update before that happened.

Once I learned the critical differences between the old MYSQL and the new MYSQLi, it wasn’t terribly difficult to update the sites to the new version. It’s not trivial, either. While most of the updates can be accomplished with a series of global search and replace operations, the code still has to be carefully checked.

This is only one example of how changes in the underlying technologies can require significant maintenance just to keep the site functioning correctly, doing the same stuff, and looking the same. As an old fart, this makes me grumpy, but it’s the way the web works. At least in this case, the updates have real security advantages; it’s much harder to hack a site which uses MYSQLi.

…and in Conclusion

I strive to build sites which are up-to-date, yet compatible with older devices. I adopt new technologies when they are useful to help communicate to the sites’ visitors, widely supported by those users’ devices, and compatible with legitimate security concerns. Existing sites sometimes need coding updates whose advantages may not be readily apparent to site owners or visitors.