Setting mobile browser meta viewport tag (Mobilizing websites with responsive design and HTML5 part 4)

This blog post is a part of Mobilizing websites with responsive design and HTML5 tutorial. For all posts please see the Introduction post.

By default, modern mobile browsers render websites in a “virtual screen” mode (viewport) where they allocate a virtual screen wide around 900 pixel for the webpage rendering. Then the users can pinch and zoom themselves around in this viewport. The default desktop-ish viewport in mobile browsers is for the legacy reasons; non-mobile aware legacy layouts would blow up if they were fitted into a small mobile screen estate.

Pinching and zooming around is not what we want to do – it makes the browsing experience constant pain of finding the start of the next paragraph. Setting a “normalized” viewport is the first thing you do when are mobilizing a website. This tells mobile browsers that the site is mobile browser aware and the mobile browser should use the actual mobile screen dimensions instead of virtual pan and zoom screen for rendering the web page.

This happens by settings a <meta name="viewport" > tag in HTML <head> section. The tag was introduced by Apple on iOS devices and has been later adapted by other Android, Opera, Firefox mobile browsers.

Here is an example:

<!--

    Set a mobile viewport which uses actual mobile screen dimensions instead of
    a virtual screen, but still allows user to zoom in for visual impairment

-->
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=5">

This viewport tag says that

  • Use device native screen width instead of virtual screen width
  • Set scale to 1 when the page is opened
  • Allow still the user to zoom in (maximum-scale=5). Some mobile site disable pan and zoom altogether of having maximum-scale=1, but this is not recommended as a lot of elderly people like to zoom into text even if the text is very large and optimized for small screens.

Before the viewport tag was applied:

Image

After the viewport tag has been applied:

Image

As you can see there is a clear difference in the page rendering, but this is not definitely enough to make the site look good on mobile: the CSS styles must be fixed also as usually legacy CSS styling uses  “min-width: 960px” or similar horizontally centered main column definition. Since we don’t have that 960 pixels in mobile screens, the layout cannot work properly yet. In the next tutorial blog post we’ll show how to fix this with CSS3 media queries and CSS overriding mechanism.

Note: As the viewport tag is not very standardized yet, there exist tons of pitfalls with it. Especially if you try to dynamically edit it with Javascript you’ll get undesirable results or no change. Always inject the viewport tag on the server-side into HTML payload.

Note: The viewport tag may affect iPad and Android tablets. The desktop browsers ignore it, though. Test your mobile site with the tablet devices also.

1. More information

\"\" Subscribe to RSS feed Image Follow me on Twitter Image Follow me on Facebook Image Follow me Google+

Working on HTML(5) for mobile sites (Mobilizing websites with responsive design and HTML5 part II)

This blog post is a part of Mobilizing websites with responsive design and HTML5 tutorial. For all posts please see the Introduction post.

There is no separate “mobile HTML”.

Mobile sites are normal HTML sites. Separate WAP protocol has been dead several years now. “XHTML mobile profile” is also dead. Most phones do normal HTML just fine.

Also in developing countries, where the usage of mobile Internet is more prevalent over desktop internet and the device base is geared toward feature phones with less powerful web browsers, thin client browsers like Opera Mini are widely used and support normal HTML just fine.

The major web experience considerations on mobile phones are not technical, in protocol wise. They include

  • Small screen estate
  • Lack of physical keyboard
  • Touch screen instead of mouse as a pointer device

Smartphones like iPhone, Android and Blackberry devices support new HTML5 and CSS3 features and in some cases mobile browsers are more advantaged than their desktop counter-parts. Even if you don’t like Apple as a company per se, they have done a great deal to push HTML5 forward in mobile space and taken the mobile browsing user experience from old, clumsy, WAP era to something you can actually enjoy.

1. There is no HTML5; there is only HTML

There never will be a finalized HTML5 standard and asking the question when HTML5 is ready is pointless. Browser vendors keep adapting evolving HTML features to their browsers continuously and it is up to feature detection and graceful fallbacks to determine whether you can do the trick with the browser or not.

In mobile space HTML5 features provide enhancements making the surfing experience better

  • Specialized input fields for better text input on non-hardware keyboards
  • Using CSS3 styles instead of images for layout effects; this reduces HTTP transfer payload making pages load faster
  • Touch event support
  • <video> and <audio> multimedia (as oppose to Flash)
  • etc.

2. Strategies for building a mobile site

There are several options for “mobile strategy” of your site

  • Responsive layout, as described in this tutorial
  • Using a stock mobile theme or add-on for open source CMS (Web and Mobile, WPTouch)
  • A theming HTML proxy, like Diazo, is an option when you cannot touch the front-end template source code at all. A theming proxy reads web HTML, parses it and transforms the result to new mobile HTML output based on (XSLT) rules
  • A commercial scraper which is a theming proxy with fancy UI e.g. Mobify.me
  • Client-side transformations with Javascript, like Mobilize.js
  • Have a separately maintained mobile site, using mobile specific CMS with information duplicated by hand or using a custom integration. Suits for large organizations where the marketing budget is big and internal communications are an issue.

What strategy you should use depends on your IT skill, organization structure and business goals. You need to balance between the wanted user experience level, budget and available competence.

3. Tools for mobile site building

Since mobile sites are normal HTML there is no need to have specific “mobile SDK” or “mobile IDE”.

When you are working on mobile HTML, excluding the device testing phase, a normal web browser fine. Use Firefox + Firebug or Chrome/Safari + developer tools. You usually don’t want to develop on mobile browsers directly, as they lack CSS inspection tools, Javascript debugger or any interaction with the HTML page source.

Note: Opera mobile browsers provide some decent HTML, CSS and Javascript remote debugging capabilities thru their Dragonfly debugging toolbar

4. Spoofing the development browser as mobile

When mobilizing a web site with responsive design, the only trick you usually need to pull is to shortcut the responsive CSS loading so that the development browser loads the mobile stylesheets.

You can do this in your own code level: instead of selectively load mobile.css file force it to be loaded in the desktop browser too by hardcoding mobile.css to be loaded for all browsers.

You could include a server-side conditions which allow you to perform the spoofing using an URL parameter:

http://site.com/?force-mobile=true

On Javascript level touch events might also needs spoofing.

Note: It is not worth of doing mobile development using Internet Explorer as the development browser. Microsoft has recently improved their track record regarding open web standards, but they still have few years catch up to do in order to be able to match the pace of the competition.

5. User agent detection

User agent is a HTTP request header which the web browser uses to tell the web server the software version the web browser is running.

User agent detection is a method of discriminating mobile devices on the server-side and serving them a different HTML payload. I strongly discourage using this old and deprecated method of mobilization in the contemporary world unless you really really have to.

  • The philosophy of HTML is to let the client device decide how to display the information, not the web server to guess how. Today mobile devices support enough Javascript to make it possible.
  • User agent detection is fragile, because the user agent strings themselves are a mess and different devices may have the same user agent or the same devices different user agent: false positives ensure
  • You need to maintain a server-side database of devices and the quality of available databases leaves room for improvement
  • Different HTML payloads varying by user agents destroy front-end caching performance, as there are thousands of device types and each would create its own front-end caching entry
  • It seems that widely spread, semi-open, device database project Wurlf is alienating its users

If you need to have different code paths for mobile devices then use something like detectmobile.js which performs the mobile feature detection on the client-side, effectively replacing 5 MB user agent string database with 100 lines of Javascript.

6. Native apps

A native application is nowadays almost synonym for “embedded WebKit” – unless you are doing some really high profile applications. The apps are out of the scope of this tutorial.

If you need to wrap your mobile site for App Store, Android Market, etc. distribution you can use PhoneGap. The user experience is not as great as building expensive 100% native application from the scratch, but the price tag is usually something you can swallow easier.

\"\" Subscribe to RSS feed Image Follow me on Twitter Image Follow me on Facebook Image Follow me Google+

Opera Mobile emulator for mobile site development

Opera distributes it’s Opera Mobile browser emulator for Windows, OSX and Linux.

A very useful tool when developing mobile sites. Especially considering that Opera Mini, which most of mobile users are using instead of the bigger browser Opera Mobile, offers limited debug capabilities. Opera Mobile should use the same layout algorithms as Opera Mini, so you should be able to debug layouts with it.

Opera Mobile emulator has Dragonfly debugging tools for Javascript / CSS. These are especially when you need to simulate small screens – something Firefox et. al. fail to do well.

\"\" Subscribe to RSS feed Image Follow me on Twitter Image Follow me on Facebook Image Follow me Google+

Setting Google Apps hosted email as your browser’s default email client for mailto protocol

Would it be nice that when you click email link (maito) in your browser you could directly send email from your organizations’s Google Apps hosted service? (Google Apps is GMail + Google Docs for corporate/organizations with own domain name).

Here are instructions how to achieve it.

1. Firefox

Follow instructions by Steve Novoselac.

2. Opera

Here are instructions for Opera 10:

  • You have file webmailproviders.ini where web mail backends are lsited
  • This file is located in Applications/Opera (you need to right click and choose Show package contents) and Resources/defaults/webmailproviders.ini (on OSX, for Windows Linux follow the instruction links below)
  • Add the email provider description as below. Note that you need to change Google Apps domain name to your link. After saving the file you need to restart opera. You don’t need icon if you don’t have one.
  • Then restart Opera, choose Preferences -> Advanced -> Programs -> mailto -> your email account.
[DOMAIN_NAME]
ID=8
URL=https://mail.google.com/hosted/DOMAIN_NAME?extsrc=mailto&url=%s
ICON=https://mail.google.com/favicon.ico

Web mailto in OperaWiki

More HTTP links to trigger email send for various email providers

\"\" Subscribe to RSS feed Image Follow me on Twitter Image Follow me on Facebook Image Follow me Google+