HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


Understanding viewports on mobile devices

Understanding viewports on mobile devices Hi,

Recently we have been tuning the default viewport settings in ocPortal, and a change has happened in 9.0.9. I'm not planning to give an account on what we've changed, because it'd get confused, but I do want to quickly explained how things now are and why.

Some background

Through the early web, computers got better resolutions over time. In other words, a higher dpi (dots/pixels per inch).
Later, the trend changed, and we got larger and larger screens instead.

The problem with this was that a physical width never corresponded to the width in pixels, and web designers of course work in pixels. So, the larger the resolution, the smaller the text / design elements, which of course is not great for people with eye-sight issues.

When iDevices, and later, Android devices (together, "mobile devices") came out, a fundamental but misunderstood change happened. We got the concept of "device pixels" which are distinguished from what I will call "rendering pixels".

The best way to think of this is probably that web pages now always have a zoom level, and you pan them. It's very different from having a scrollbar or a resized window, which would be the case on a desktop screen.

In either case, you have a webpage which is rendered on a "canvas", and then you may have scroll bars (on a desktop) or panning (on a mobile device) to make up whatever difference between the size of the canvas and the size of the user's viewport.

If a mobile device is zoomed out, you may not get the full fidelity of the design on the actual screen (i.e. there's some loss). If a mobile device is zoomed in, it may actually be scaled up beyond the actual fidelity.

The scenario was extended further when "retina" devices came out. The perceived display size of sites would be desired to remain the same, but suddenly devices had double the resolution. The fundamental thing to understand here is that you are essentially/typically zoomed in 2x on a retina screen because of this resolution improvement. However, if you are simply zooming in, surely that means you are not gaining the advantage of the fidelity? This is where it gets really weird - the browser is actually rendering the screen at a fidelity than the viewport's specified size, and when things are displayed the browser maintains that fidelity irrespective of the limited size of the viewport. This really hits home the fact that the "pixels" a web designer works with are virtual rather than quantum units, and the browser will be smart enough to use whatever fidelity it can between the source material (high resolution images, anti-aliased text, etc) and whatever resolution the screen can take.

How the viewport is specified

On a desktop, the designer does not specify the viewport. The user does via the size of their browser window.

On a mobile device, the designer can specify the viewport via the viewport meta tag.
This tag specifies a number of constraints, but the main one is the 'width' in rendering pixels that the physical screen is mapped to. If you want to compare this to a desktop, it is like the size of the window that the mobile device's full physical screen width has mapped onto it, with zooming used to achieve that mapping.

You can either set a viewport width in pixels, or set it to 'device-width' if you want the zoom factor to essentially be 1.0 (i.e. not zoomed). Setting it to 'device-width' is very much like setting a fluid website design rather than a 'fixed-width' website design. You are asking the mobile device to flow content to fit onto it, making maximum use of its resolution for fitting stuff on.

What ocPortal does

This is the code ocPortal now uses in HTML_HEAD.tpl:

Code

{$,iPhone/Android/etc should know they have an optimised design heading to them}
{+START,IF,{$MOBILE}}
   {+START,IF,{$NOT,{$_GET,overlay}}}
      <meta name="viewport" content="width=device-width, initial-scale=1.0" />
   {+END}
   {+START,IF,{$_GET,overlay}}
      <meta name="viewport" content="width=285, user-scalable=yes" />
   {+END}
{+END}
{+START,IF,{$NOT,{$MOBILE}}}
   {+START,IF,{$CONFIG_OPTION,fixed_width}}
      <meta name="viewport" content="width=982, user-scalable=yes" />
   {+END}
   {+START,IF,{$NOT,{$CONFIG_OPTION,fixed_width}}}
      <meta name="viewport" content="width=device-width, user-scalable=yes" />
   {+END}
{+END}

In ocPortal, mobile mode is used for smartphones. Tablets do not use mobile mobile. I realise in my explanations so far I have referred to tablets as mobile devices, but you'll need to put that aside now ;-). They are mobile devices in the sense they have a touch screen and a panned viewport, but not in the sense of ocPortal reducing down it's layout via it's mobile mode.

As you can see, we define separate for mobile mode (again, smartphones) and non-mobile mode (essentially this means tablets, as desktops won't use the viewport setting).

I'm going to simplify things down a bit for my explanation, removing the stuff in our code about overlays. It's not worth the added confusion.

Code

{$,iPhone/Android/etc should know they have an optimised design heading to them}
{+START,IF,{$MOBILE}}
   <meta name="viewport" content="width=device-width, initial-scale=1.0" />
{+END}
{+START,IF,{$NOT,{$MOBILE}}}
   {+START,IF,{$CONFIG_OPTION,fixed_width}}
      <meta name="viewport" content="width=982, user-scalable=yes" />
   {+END}
   {+START,IF,{$NOT,{$CONFIG_OPTION,fixed_width}}}
      <meta name="viewport" content="width=device-width, user-scalable=yes" />
   {+END}
{+END}

You can see mobile mode is fitted to the device-width. This is to make optimum use of the screen for fitting stuff on, which is arguably the best thing for a device of such limited size. If you are going to spend time making a very mobile-optimised site, you'd probably change this to a width in pixels that you'd designed for, and smile knowing that it was prettier for retina users (higher fidelity mapped onto the width, not scaling your images down so much, and seeing smoother anti-aliased fonts) but discernible without zooming for all smartphone users who have a certain base device resolution.

You can see that tablets have different settings depending on whether ocPortal is set to fixed-width or not. If ocPortal is set to fixed-width, it matches the viewport to the default fixed width our CSS declares. Otherwise, it uses device-width in a similar way to smartphones.

An example: fixed width mobile designs

Let's say your base smartphone will be the resolution of the original iPhone, i.e. a width of 320 pixels.
(The new retina iPhones have 640 pixels.)

You therefore would optimise your design for 320 pixels, but have source imagery of higher resolution in your actual assets.

You'd specify your smartphone viewport as 320 pixels, rather than using the device-width (which ocPortal is using by default, as discussed earlier).

On an old iPhone, this would be a direct correspondence with the device resolution. i.e. no zooming.

On a retina iPhone, it would be zoomed 2x, although the user would not have any idea about it and they couldn't zoom back out. Your high-resolution assets and font anti-aliasing would make it look great, you'd get the 2x fidelity the device could handle: more than 320 individual pixels per row would render in terms of what would be happening on the actual device. From the point of view of your CSS though, the canvas would be 320px across, and assuming the user hadn't zoomed in further, so would the viewport. It's confusing, clever, and really important to understand.

A scenario: fluid mobile designs

If you want to fit as much onto the screen as possible, rather than going for the fixed width but variable fidelity, then you may still want to do some trickery.

For example, you may want a logo to stretch right across the screen, yet have the rest of the design be fluid.

For this kind of thing you would use CSS, e.g. "width: 100%" on the image.

initial-scale

If you set the viewport in pixels and set it to be more than the user's device actually has, the user's device will probably initialise so they need to pan across to see everything in the viewport. If you set it to initial-scale=1.0 then a lower-resolution device will fit everything without panning which usually is a better experience assuming that you have made a reasonable effort to optimise your mobile layout (if you have a small font size or detailed images, it may not be possible to fully make out unless the user zooms).

The naming of initial-scale is a bit confusing. Think of it in terms of the user's understanding of the zoom level, rather than the designer's. If it is 1.0 then from the user's point of view, they start fully zoomed out; that usually does not mean the devices physical width is going to correspond with the width of your viewport, so in reality scaling/zooming is still going on. You're best of "forgetting" what the physical width of the device is from the point of view of defining CSS widths/viewports, and think of the physical width only when considering discernability.

You can also set viewport setting to specify whether the user is allowed to manually zoom or not, and what the constraints on that should be.

Smartphones set to view in desktop mode

You can choose to make a smartphone view in the desktop mode, as a user of the device. Or, as an ocPortal admin you can set specific pages to always run in the desktop mode.

In this case, your smartphone would set to display with the tablet viewport setting. If you are not using fixed-width, this could be a problem, it could really scale your desktop layout down to meet the device-width, and make a big mess of it. In the next v9 patch we will change:

Code

body#main_website {
   /* To stop it scaling down if we are applying "width=device-width" and forcing a page to displaying non-mobile */
   {+START,IF,{$NOT,{$MOBILE}}}
      min-width: 1000px;
   {+END}
}
to:

Code

body#main_website {
   margin: 0;

   /* To stop it scaling down if we are applying "width=device-width" and forcing a page to displaying non-mobile */
   {+START,IF,{$NOT,{$MOBILE}}}
      min-width: 1000px;
   {+END}
}
to enforce a minimum width for desktop mode. This resolves that particular issue.

Debugging

If you have access to a Mac, I highly recommend you get a copy of Xcode. It contains an excellent iPhone/iPad simulator, and you can attach Safari to it to do interactive debugging. I don't think the tools on a PC are as good, but the Android dev kit probably has something similar.

If you don't need to debug viewports, you can do "poor mans" testing. Just size your browser down (ideally Google Chrome of Safari, which are both reasonably close to what runs on iOS and Android) and set to display the mobile version.

Responsive design

Some people may wonder how this fits into everything. Essentially, responsive design is the same as having a fluid width but also defining CSS rules that make the layout adapt based on what the available width actually is. This has been made possible via something called "media queries", but also other techniques are used, such as sizing images proportionally rather than the actual size of the image (i.e. relying on the browser to down-scale as required).

View all

Trackbacks

There have been no trackbacks yet

Edited