Opera Developer News

A simple survey of screen sizes

By Daniel Davistagawa. Thursday, January 17, 2013 7:50:18 AM

reference, RWD, responsive, media queries

I got a bit frustrated the other day. I'd come across yet another site that was designed for at least a 1280-width screen, meaning it wouldn't fit on my trusty 1024-width laptop and I had to scroll horizontally. "Yada yada, first world problems", I hear you say, but considering the small effort it takes to make a web page look good at different widths (and the abundance of RWD tutorials out there now), surely it's worth web designers making such tweaks. Besides, there's got to be many other users in my position, hasn't there?

I decided to find out, so I took a sample of around 5,000 unique visitors to my demo pages at people.opera.com/danield and noted their screen sizes based on the JavaScript screen.width and screen.height properties. Of course, this audience is going to be pretty techie and not representative of the world at large, so I did the same sampling at the same time on a long-running personal site of mine aimed at new dads — a pretty non-techie audience.

Ooh, pretty graphs!

The scatter plots below show the screen dimensions for each group of users — vertical scale is screen height and horizontal scale is screen width.

Click the image to see the original graphs and their raw data.

Top 3 screen sizes

Technical users:

1366x768 - 18.1% of users
1920x1080 - 14.2% of users
1280x800 - 9.7% of users

Non-technical users:

1366x768 - 15.5% of users
320x480 - 14.7% of users
1024x768 - 12.5% of users

Observations

The first thing that stands out is that both graphs have a sort of slanted V-shape. These are two rough lines showing screens in portrait and landscape format, with a slight variation due to differing screen ratios. This indicates non-technical users tend to have a higher ratio of portrait to landscape devices than technical users.
Not surprisingly, there's a high concentration of large screens or multiple monitors among techies but this is clearly not representative of a wider audience.
Non-technical users have less variety in the portrait format devices they use. It looks pretty much like iPhone-size (320x480) and iPad-size devices (768x1024) rule in this group. (Note I'm ignoring manufacturer and OS in this study.)
Non-technical users have notably smaller screens than technical users, on the whole, and my beloved 1024x768 screen size is indeed very popular with non-techies. Admittedly that resolution could be a horizontal tablet or a laptop but I don't care. Jason Grigsby explains very well how the distinction between such devices is rapidly disappearing.

Takeaway

This may be just a small, simple experiment, but what lessons can we learn from it? Namely that devices in use in the real world are much more varied than we might think, and much more mobile-centric than I personally expected. As web designers and developers, we often socialise with a similar crowd of colleagues, friends and those we meet at tech events. It's been said before, but it's important we look out of this bubble when designing web apps and sites. Real users out there in scary non-geek land are the ones we should be thinking of and getting feedback from if we want our creations to reach their full potential.

19 comments

HTML5 canvas performance: Drawing circles

By Daniel Davistagawa. Thursday, December 13, 2012 2:59:29 AM

performance, JavaScript, HTML5, canvas

HTML5 canvas baubles on a Christmas tree

As it's nearly Christmas, I was playing with HTML5 canvas to draw baubles on a photo of a Christmas tree. Wondering what was the best way to do it, I came across this answer on Stack Overflow about drawing circles with just radial gradients.

Circles

As you probably know, the standard way of drawing circles is to use arc():

// Drawing a circle the traditional way
ctx.beginPath();
ctx.arc(x, y, radius, 0, Math.PI * 2, true);
ctx.fillStyle = 'rgba(195, 56, 56, 1)';
ctx.fill();
ctx.closePath();

This way of drawing a circle is a bit cumbersome in my opinion, compared to SVG for example. I thought the idea of using just radial gradients was a clever alternative and wondered what the performance difference would be.

// Drawing a circle with a radial gradient
var gradient = ctx.createRadialGradient(x, y, 0, x, y, radius);
gradient.addColorStop(0.95, 'rgba(195, 56, 56, 1)');
gradient.addColorStop(1, 'rgba(195, 56, 56, 0)');
ctx.fillStyle = gradient;
ctx.fillRect(x - radius, y - radius, x + radius, y + radius);

Sure enough, using radial gradients is slower than arc(). Several times slower! You can play with this canvas test page here to see the speed difference for yourself.

If I'd thought about it properly, I should have realised this without needing to test it and saved myself some time, but then I tried playing with spheres (well, circles with shading) as well.

Spheres

There are two common ways to make spheres in canvas:

Radial gradients
Existing images using drawImage()

// Drawing a sphere with radial gradients
var gradient = ctx.createRadialGradient(x, y, 0, x, y, radius);
gradient.addColorStop(0, 'rgba(255, 255, 255, 1)');
gradient.addColorStop(0.2, 'rgba(255, 85, 85, 1)');
gradient.addColorStop(0.95, 'rgba(128, 0, 0, 1)');
gradient.addColorStop(1, 'rgba(128, 0, 0, 0)');
ctx.fillStyle = gradient;
ctx.fillRect(x - radius, y - radius, x + radius, y + radius);

// Drawing a sphere with an existing image
var img = new Image();
img.src = 'images/baubles.png';
ctx.drawImage(img, x, y, width, height);

As before, radial gradients are several times slower. Of course, the flip side is that radial gradients are generated dynamically and so can be changed on-the-fly with JavaScript, whereas images have to be pre-made in graphics software. These images can't be edited directly with JavaScript although you can easily change their size. You can also control the colour in a couple of ways:

Using an image sprite of a particular image with varying colours.
Using a greyscale image and applying a semi-transparent overlay with arc().

Don't forget that using images means they have to be downloaded first so it's better to pre-load them if possible.

You can test the performance of these on the same canvas test page.

As you can see, the overlay approach is obviously slower but not as much as with gradients. It also gives you more freedom in controlling the colours, however the overall effect has lower contrast than the original image.

Summary

In general, the speed difference is not noticeable for simple applications or fast hardware, but could be an issue if you're using animation, making a high-performance game, or designing for a TV or set-top box. As always, every decision is a compromise so here's a summary of the various trade-offs and what I've learned:

If you just want to draw a circle, use arc().
If you want to draw a sphere, use an image (and pre-load it).
If you want to draw a variety of spheres, try using image sprites.
If you want spheres with dynamically-changing colours, consider using an image with a semi-transparent overlay.
Only use radial gradients if you really need to.

One final thing I've learned is that adding thousands of baubles does not enhance a Christmas tree's beauty!

UPDATE:

Marcelo came up with the cool idea of creating a single image on a hidden canvas using a radial gradient, and then repeatedly drawing that with drawImage(). This gets around the need to create images in advance and also means you can edit the colour on-the-fly. But here's the best part — ignoring the initial gradient creation time, it's actually faster than using drawImage() on an existing image! The code looks something like this:

// Create a second "buffer" canvas but don't append it to the document
var tmpCanvas = document.createElement('canvas');
var tmpCtx = tmpCanvas.getContext('2d');

// Add the necessary gradients here, as above

// Draw the image from the second "buffer" canvas
ctx.drawImage(tmpCanvas, x, y, width, height);

So, if you're drawing lots of circles or spheres, this is my recommended method. Nice one Marcelo!

4 comments

A few tips on TV web development

By Daniel Davistagawa. Tuesday, December 11, 2012 3:13:28 AM

presentation, emulator, web, tv ...

An Opera TV Store seminar in Tokyo

Over the past few days I've been lucky enough to give a couple of talks on web development for TV. It seems there's growing interest and enthusiasm in this area, which I'm pleased to see, because although it can be frustrating, web on TV also offers opportunities for innovation and interesting technical challenges.

There are many things to consider when creating a great user experience and we have some in-depth TV tutorials over on Dev.Opera, but in my experience there are a handful of priority problems that, when fixed, go a long way towards making life easier for TV users. They can mostly be linked to three main characteristics of TVs:

TV screen — actually quite small from a normal viewing distance.
Remote control — keypad-based and slow, due to infrared lag.
TV hardware — generally less powerful than mobile phones.

These characteristics lead to a number of problems; in the next section we'll expand on these and outline some possible solutions.

Problems (and what to do about them)

Font size: Text on most websites is too small to be read on a TV while sitting on a sofa. Try increasing the font size by about 2.5 times.
Lack of on-screen space: Because the text should be large, you now have less space for other elements so reduce or hide unnecessary page sections, much as you would for mobile.
Non-focusable elements: With a keypad, it's hard or impossible to click on a div or image that is pretending to be a button, for example if you are using JavaScript to capture a click or other event. Use tabindex="0" to make such elements focusable, as in this spatial navigation challenge.
Cumbersome scrolling: Scrolling should be minimized where possible. A relatively unknown but useful optimization is to use CSS directional focus navigation for easily moving around lists of objects, like an image gallery for example. See our Tweaking spatial navigation article for more details and an example.
Inputting text: Quite simply, avoid this wherever possible! Text input on a keypad over infrared is fiddly and frustrating. Either offer lists of choices to provide users with sensible defaults or see if any of the newer HTML5 input types can help.
Animation: Try to minimize the use of animation. Because of the lack of processing power you'll encounter on TVs, animations can really slow things down if you're not careful. A couple of tips are a) use CSS3 effects rather than JavaScript; b) animate properties that require fewer reflows, for example transitioning left or top is usually faster and smoother than width or height.
Caching/localStorage: This can be unreliable because of a lack of hardware storage space and inconsistent behaviour across devices. Store things like user preferences on the server-side if possible.
Detecting TVs: Unfortunately the TV media type is rarely used, including in Opera's TV browser and Google TV. An alternative is to detect TVs with media queries — there are only 2 or 3 standard TV resolutions. It's a bit of a hack, but here's an example of how to use it to enlarge font size when a page is viewed on a TV.
Difficulty in testing: Testing on a TV is essential but can be time-consuming, so in the early stages of development I recommend simply moving back from your PC until the finger and thumb on your outstretched hand are the same size as the PC screen. Believe it or not, this viewing size is about the same as for the average TV viewer sitting on their sofa. To test keypad usage, a handy feature in Opera is the ability to press [Shift] + [arrow keys] to move around a page with spatial navigation. Finally, we have a free TV emulator, which provides the same environment as that on many actual TVs.

The good news!

Despite the hurdles, TVs have some key advantages over PCs and mobile devices:

The big screen and speakers mean good video and audio quality.
Many people, especially the young and the elderly, and more familiar with using a TV than other devices.
TVs enjoy pride of place in the home and can be viewed by multiple people at the same time.
You don't need to be close to a TV to use it.

There are a few ideas of using these advantages to create TV apps towards the end of my TV strategy slide deck. As you can see, we're restricted in what design techniques we can use but these restrictions can be fuel for creativity. It's still a young area of web development and is ripe for a new breed of apps and experiences to emerge.

2 comments

« Prev 1 2 3 4 5 6 ... 96 Next »