Performance optimization of mobile sites

This is in reaction to a post on Google Plus complaining about why the BBC mobile site wouldn't serve large images to a phone that is capable of downloading and displaying them. (This is current practice on many mobile sites, as it were.)

So, the BBC website is also serving developing countries, where the best mobile infrastructure consists of what in advanced economies is essentially legacy technology. For example, only this year did Pakistan begin adopting 3G.

Many sites are not necessarily willing to incur additional bandwidth costs, unless they were ready, willing, and capable of serving very large amounts of content (such as YouTube).

Another typical issue is with designers of lesser websites, who fail to optimize their content.

Mobile data connections incur charges for data, which can be substantial for people with limited budgets. Thus a major factor to consider when designing a mobile site with worldwide viewership is responsible data usage, which then requires designs that are made for the lowest common denominator.

Because when people must pay money to read a website, they will avoid those that are expensive to visit.

AFAIK, there seems to be no easy way for a site to automatically detect if a user is visiting through 2.75G (GRPS/EDGE), 3G or 4G. The best indicator is the user agent string, but that doesn't always tell if the phone is actually on the net via 3G/4G; only that the device is capable of such.

If phones were able to report through the user agent string that they're browsing via 3G/4G, or even better — if a device were able to report its download speed on a certain network/infrastructure, websites would be able to fine-tune the content served to their various visitors. Unfortunately, this would be ripe for abuse, if content providers began actively excluding devices with speeds and connections under a certain threshold.

Another point to consider is that when mobile phone users are tied to a limited data plan, they are not willing to download more than absolutely necessary. This being text, and more would be large images.

A solution could be for mobile users to select which connections they would want which version of site. If people have a limited plan, they'd want small content; if using a dedicated connection over Wi-Fi, they'd be content with bigger images.

There are some solutions (or workarounds), such as one based on cooperation between site and user by implementing cookies to select the lite or heavy site, if such functionality is offered. There are also apps for mobile devices.

Another possibility is for users themselves to specify which version of a site they want to visit at a time, especially if a mobile version is on offer.

Simple maths on image height

It has taken me a while to post new stuff, but since I finally got around to it, I'll post it anyway.

This time, the description of the problem is not in the lede, but hidden somewhere in this post.
I know there may be a much simpler way and I might have even thought about it after creating this post, but the following is just a way to express how I got to it. My best excuse is that I wanted quite a lot of precision and I found the following to be the best way.

Recently I got my hands on a very simple GPRS feature with only a WAP browser as its most advanced feature. It has 600 kilobytes of storage for small sounds and images, and I'd learned to use the WAP browser to download previously down-scaled photos as background pictures to customize the phone.

One problem that I ran into, is that the phone's default main screen UI text showing operator, date and time is in white colour, and this interferes with images that have white elements of it.

At that time I hadn't found out yet that I could customize UI text colour as well as add text shadows. The limited selection of colours, and text shadows made things legible, but not nice-looking, so I decided on keeping the white text.

Usually, this means that I'd only have to choose pictures with coloration that avoid the white colour. But recently I photographed a very beautiful event, and I wanted the phone to contain a picture of it, but in a way that much of the event would stay under UI text, with the sky above the event serving the function of a beautiful background to white text.

The final photo had to have the dimensions of 128x97 pixels (width x height) without the loss of aspect ratio.

I had previously created myself an XCF template image of that size in GIMP to be able to test the background image against the precise UI simulation before using mobile data charges to download the final and best version.

The precision was based on a "screen measure" image I'd saved in the phone to measure how many pixels the main screen text used up height-wise and how much of the background was free.

Out of a height of 97 pixels I measured 46 pixels that are used up by main screen UI text.

This is what I did in GIMP:

• In the original large photo, I chose a baseline from the bottom of the selection from which I wanted to expand the selection upwards. The baseline was the lowest point from which I wanted to include information in the selection that would make it to the final image, small as it would be;
• Then I cropped away the parts below the baseline and kept the rest of the photo. That way it was easier to select from the bottom.
• After that, I raised the selection, but discovered a roadblock, because I didn't know how high I should raise it: I wanted the event to stay more or less just below main screen text, but in such a way that the text and the top of the stage wouldn't touch.
  
  The trouble, of course, was getting the height right. I kinda knew that trying to get it right 'by hand' just by making a selection and then testing to see how it looks would take too much time.

I knew I had the base information: 97 pixels height, 46 pixels reserved height at the top which I couldn't use, and 51 pixels that I had free.

Yes, I could have just downsized the big image with Shift+T and a 128x97-pixel layer above it to try and get the approximate right size, but that's not enough for a small image that has to be pixel-perfect.

I realized that it should be possible to get to the right height from the selection that encompassed the area that I wanted to stay below main screen text. This became the essential question.

(I didn't really need the width, because I'd use the template image to calculate the width of the selection using the Scale image widget by just inputting the desired height, given that 128x97 were already set as base dimensions.)

I do admit not being very proficient in mathematics. So I found a simple-to-understand online percent calculator and the default operating system calculator. After much trial and error (but hey :-) I got the right calculations and put them in the right order. Then to automate the whole thing so as to spend less time in the future, I proceeded to put these calculations into LibreOffice (I had to separately find out how to do percent calculations there), and eventually got to connect individual calculations into several formulae.

Yes, I am sure there are probably much simpler math formulae for these calculations, but the main one along with adjacent ones works as expected.

Then I turned to Google Docs, which is this awesome thing if you want to share interesting documents with the world,^* and made the spreadsheet look nicer for embedding in a blog.

* Note that information that people want to keep private, secure, and in a cloud, should be kept with the companies that meet three criteria: that said companies are headquartered in countries that have strong respect for people's privacy, that the clouds they use are also located in those countries, and that said companies do not have operations in countries that do not respect people's privacy.

So here's the embedded document, and a link to it:
Calculating reserved image height from a selection

So, in the blue column 47 pixels from top of the image is reserved height; if I change it to 46, the other figures will change accordingly. The 'Input free height' cell is where I set the height of the selection that must include everything I want below main screen text; 'Total' is the total height of the selection.

After I get the total height, I use the 128x97-px template image in another window and the Scale image tool where I replace 97 px with the total height, move input focus with the tab button, and the Scale image tool will calculate the right width for me (if height and width values are connected, as in keeping the aspect ratio).

Then I changed the selection in the big image to that size, moved the selection around a bit, copied it, pasted as a new image, and then scaled the image down to 128x97 px. In the scale image tool, I only needed to change the height from 698 pixels to 97 pixels; the width — as the aspect ratio was correct — was then calculated to 128 pixels.

All in all, I had only four tries and not more. That last two consisted of moving the selection around in the big image to more or less center the stage that I had photographed. The right image turned out to be the one at the third try, when I compared the third and fourth tests.

Maybe in the future I'll provide example images to make a visual point of what I wanted to achieve.