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.
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.
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.
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.