« February 2016 | Main | June 2016 »
May 24, 2016
Household items: coding, standards, and "2x" pics
Back in the day when we published Pen Computing Magazine and Digital Camera Magazine and some other titles in print, we always prided ourselves to be in total control of our own destiny. We did virtually everything inhouse — writing editing, photography, layout, prepress, web, marketing and advertising — and most of us had mastered several of those disciplines. We didn't want to farm anything out or rely on any one expert.
We felt the same about software. We had our own webhosting, our own servers right in our building, and we programmed everything ourselves. That way, no one could force us to update or upgrade when we didn't want to, no one could quietly put more and more unrelated ads, pop-ups and clickbait onto our pages, and no one could suddenly go out of business on us. No one could control us or buy us out either, because we financed everything ourselves. One doesn't get rich that way, but it pretty much guarantees continuity and longevity.
That doesn't mean we didn't run into issues. The author of a terrific piece of software that we used and loved was of the paranoid sort and, even though we paid a hefty price for the system, insisted on compiling everything and locking the software to our particular hardware. So every time we upgraded our servers even in a minor way, we had to go and beg the man for a new code. That became increasingly more difficult, and eventually he refused altogether.
Fortunately, that was an isolated incidence, which is a good thing as we use dozens of tools and utilities that run on our own server and without which we couldn't do business. Many are orphaned or haven't been updated in many years. But they still work, and they do the job better than what replaced them.
RuggedPCReview.com is a vast site with thousands of pages. Yet we don't use a content management system or anything like it. We handcode everything. Sure, we have utilities and scripts and routines that make the job easier, but when a new page goes up, it hasn't been generated by rev. 17.22 of version 5.21 of some corporate software system. It's all coded by hand.
Don't get the idea, though, that we're hidebound and unwilling to go with the flow. We routinely evaluate whatever new tools and systems that come along. A few years we analyzed HTML 5 and recreated part of RuggedPCReview in pure HTML 5. It was an interesting and stimulating exercise, and we adopted part of HTML 5, but didn't see a need to convert everything.
More recently we took a look at Word Press. Like Movable Type that we still use (and run on our own server), Word Press started as just blog software. It's now morphed into a full-fledged content management and site generation system, one that's replacing more and more conventional websites. As we had done with HTML 5, we analyzed Word Press and recreated RuggedPCReview in Word Press.
We rejected Word Press for a variety of reasons. First, we used tables everywhere, and Word Press is terrible with tables. Second, Word Press is based on modules that are pretty much black boxes. You don't know what they do and how (unless you want to dedicate your life to learn and decipher Word Press in detail). We don't like that. Third, Word Press layout is terrible. Even the best templates look like pictures and text blocks have randomly been dropped on a vast ocean of white background. And forth, and most egregiously, with Word Press sites you never know if an article or posting is current or three years old.
So thanks, but no thanks. Which means that when we need to implement a new feature on our site, we have to be creative. A couple of years ago one of our much appreciated sponsors was unhappy that sponsor logos were listed alphabetically, which meant that some sponsors were always on top and others at the bottom. A reasonable complaint. Word Press likely has some black box for that, or maybe not. Our solution was to find a script and modify it for our purposes. It's been working beautifully.
Technology advances at a rapid pace, of course, sometimes for the better and sometimes you wonder what they were thinking because what came before worked better. That's mostly the case with software; hardware advances are generally a good thing. But here are a couple of examples of how advances in hardware affect running a site like RuggedPCReview.
There was a time when the web was on desktop and laptop monitors, and phones either didn't have anything like the web, or some separate abbreviated version of it, like the unfortunate and ill-fated WAP mobile web that was on older feature phones. But with smartphones getting ever larger displays and ever more powerful electronics, there really wasn't a need to have two separate webs. Standard web browsing works just fine on phones.
Problem is that even a 5.5-inch screen like the one on the iPhone 6 Plus is awfully small to take in a webpage. You can, of course, quickly zoom in and out thanks to the wonders of the effortless capacitive multi-touch, but that, apparently was a thorn in the eyes of interface developers. So we're seeing all those efforts to make sites "mobile-friendly." The currently prevailing school of thought is to have sites consisting of blocks that arrange themselves automatically depending on the size and width of a display. So if you have three pictures next to one another on a standard desktop browser, on a smaller screen the three pictures will rearrange themselves and become stacked on top of one another. Same with text blocks and other site elements.
That may seem like a brilliant solutions to programmers, but it's a hideous aesthetic nightmare in the eyes of anyone who's ever done layout and crafted pages just so. The mere idea that this could be a solution seems preposterous. So we're staying away from that nonsense.
But there are other issues. One of them is resolution. There was a time when most desktop and notebook displays used the same resolution, with every few years bringing a new standard that would them slowly be adopted. 640 x 480 VGA was gradually replaced by 800 x 600 SVGA which, in turn, was slowly replaced by 1024 x 768 XGA. Handhelds were in their own category with proprietary screen resolutions (like Palm) or the 240 x 320 QVGA of Pocket PCs.
That first changed when "wide-format" displays became popular. Where once everything had been displayed in the same 4:3 aspect ratio as TV sets, various aspect ratios quickly became an additional variable. The tens of millions who bought early netbooks will remember how the 1024 x 600 format favored on netbooks awkwardly cut off the bottom of numerous apps that were all formatted for 1024 x 768. And so on.
Then something else weird happened. While desktop and notebook displays only very slowly adopted higher screen resolutions, resolution virtually exploded on smartphones and tablets. Apple's introduced the concept of "retina" displays where, when looked at from the typical viewing distance of a class of device, individual pixels could no longer detected by the naked eye. As a result, high resolution quickly became a strategic battleground with smartphones. That led to the interesting situation where many smartphones with small 5-inch screens had the same 1920 x 1080 resolution as 15-inch notebooks, 27-inch desktop monitors, and 65-inch HD TVs. And now there are smartphones with 4k displays. That's 3840 x 2160 pixels, the same as 80-inch ultra-HD TVs.
What that means is that ordinary websites must now display in at least reasonable shape and quality on a device spectrum that ranges from tiny displays with insanely high resolution all the way to much larger desktop and laptop displays with generally much lower resolution, and often still using the old legacy resolutions.
Which is especially bad for pictures. Why? Well, let's take a look at RuggedPCReview. Ever since we started the site in 2005, all pages have been 900 pixels wide. That's because we wanted to comfortably fit into the 1024 pixel width of an XGA display. What happens when you look at the 900-pixel site on a full HD screen with its 1920 pixel width? Well, boxes and text and such scales nicely, but pictures suddenly look much worse. Now go on a 3840 pixel wide 4k screen, and the pictures are hardly viewable anymore.
So what does one do?
Turns out this is an issue that's been hotly debated for several years now, but a common solution hasn't been found. I did some research into it, and there are literally dozens of ways to make pictures look good on various sizes of displays with various resolutions. They use different technologies, different coding, and different standards, which means most may or may not work on any given rev of any given browser.
In general, how can the issue be handled? Well, you could have high-res pictures, have the browser download those, and then display them at lower resolution if need be. Or you could use on of the image formats where the picture starts of blurry and then sharpens. If all the sharpness isn't needed, the browser could simply stop the process. Or you could download various versions of the same picture an then display the one that makes most sense for a given resolution. One thorny issue is that you don't want to download a high res picture when all you need is a much lower res version. That'd be bad for bandwidth and loading speed. You also don't want to first load the webpage and then have it sit there with none of the pictures loaded while the software decides which version of a picture it should load, or while it's milling to get the picture into the optimal resolution. It's a surprisingly difficult issue.
After having read a good many articles on the issue, I was about to give up because all approaches seemed too complex to make sense for us to pursue.
But then I came across a solution that made sense. It's the "srcset" attribute that can be used with the standard HTML code for displaying an image. The way this goes is that you tell the browser to display a picture the way it always does. But the srcset attribute now also says that if the screen of the device the picture is to be viewed has such and such resolution, or is so and so many pixels wide, then use the higher resolution version of the picture! That sounds a bit difficult, but it's made easier by the fact that modern browsers know whether they run on a "1x" screen (i.e. a good old-fashioned standard language display) or a "2x" screen (like, for example, the retina iMac27), or even a "3x" display (like a smartphone with insane resolution). Which means the browser only has to download one image, and it'll be the one that looks best on that particular display. Yeah!
There's one problem, though. And it's one that can be frustratingly difficult to solve. It has to do with picture size. Anyone who is familiar with modern compact or DSLR cameras knows that there is a huge difference in the size of a "raw" image and one that's saved in JPEG format. And also that pictures can be saved at various quality levels in the JPEG format. For most web display situations, the art of the deal is to compress as much as you can while still having a decent looking picture.
How does that affect having various versions of the same picture for different types of displays? Well, if a standard picture takes 50kb of storage space, a "2x" picture will take four times as much, 200kb. And a "4x" picture would weigh in at 16 times as much, or a hefty 1.6mb. It's easy to see that this can result in serious bandwidth munching and sluggish page loading.
Turns out, the human eye is very easily fooled, and so we can cut some corners, but it has to be the right corners. Trial and error revealed that with our RuggedPCReview site, saving a "2x" size JPEG in what Photoshop considers "low" quality at a "10" level takes roughly the same amount of storage as saving the same picture in a smaller "1x" size at "good" quality, which is Photoshop's "60" level. But doesn't the picture look terrible saved in such a high compression? Amazingly, not. It looks great, and much sharper than the higher quality low res picture. That means that while we still must create two versions of each picture, loading a page with a high-res picture on a high-res display takes no longer than loading the low-res picture!
That sounded too god to be true, but we tried it and it works. So from now on, whenever possible, all pictures used in new RuggedPCReview ages will have low-res and high-res versions of images.
Isn't technology great!?
Posted by conradb212 at 6:26 PM