Testing mobile sites on Nokia Series 60, Series 40 and Meego (Mobilizing websites with responsive design and HTML5 part 13)

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

This blog post gives you intro how to test mobile sites in Nokia phones, with one exception. Windows Phone phones will have their own blog post following soon after this post.

1. Series 60 and Meego

N8 is the most notable Series 60 phone. Though Series 60 is at the end of its life, it still represents around 30% of world smartphones. Series 60 was the first OS to use WebKit, but unfortunately Nokia decided to develop its own Web Run-time Javascript based development environment instead of focusing delivering good HTML5 experience on the browser. Sadly, HTML5 experience is not that good, but acceptable, somewhere little bit behind Android Browser.

N9, the best phone in the world, is the first and the last Meego phone ever produced. It’s market share is unknown. Most developers prefer this phone due to its Debian/X11 based operating system. You can apt-get install software into your phone.

2. Remote Device Access

Nokia has remote service to access Meego- and Series 60 (Symbian) phones in a publicly accessible “phone cloud”. This is the recommended option for testing your mobile site on these phones unless you have a device yourself. This service seriously kicks ass and I hope other vendors would provide such free service for developers.

Remote Device Access cloud accessible phones are real devices, not emulated ones.

The service requires

  • Sign Up
  • A web browser
  • Java run-time, with Web Start bootstrap. Note that the service uses Java Web Start, not Java applet, though it does not make any difference.

Remote Device Access does not have Windows or Series 40 phones as writing of this.

When you open the service you can request ~30 minutes usage time for a device and remotely access it over Java application. The phone is fully yours, there really aren’t any limitations (beside making calls and such).

Image

N9 running in a window from Nokia Remote Device Access service

There is some lag when using the service, but you can can withstand it to get the mobile site testing done.

3. Series 60 simulator and SDK

Series 60 simulator is based on recompilation of Series 60 components for Windows and emulating some Symbian OS features.

Some features of SDK

  • Windows only
  • Pain to set up
  • Awful to use

Skip it.

4. Series 40

Nokia Series 40 phones are wide-spread in developing world due to their cheap price, physical durability and long battery life.

Nokia low end Series 40 operating system is closed, proprietary and not very portable. There does not exist much testing tools for this OS, outside the phones themselves.

Newer Series 40 phones have a WebKit based browser, older phones some proprietary browsing engines which really can’t do even the basic CSS.

Opera Mini, based on Java ME, is popular third party aftermarket browser available for Series 40 devices and making the web surfing actually pleasurable. You can recommend using Opera Mini for your Series 40 users.

These phones are cheap, so just buy the most popular Series 40 of your target market.

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

Testing mobile sites on Firefox Mobile, Opera Mini and other aftermarket browsers (Mobilizing websites with responsive design and HTML5 part 12)

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

Firefox Mobile and Opera Mini are popular after market browsers the user can install on their device. They offer additional functionality and speed over the stock browsers. You should also test your mobile sites with these browsers.

There also exist plethora of other after market browsers, especially for Android platform. I am not sure how popular they are, but they all are based on the same WebKit engine shipped with the Android platform, so they generally yield the same rendering output as the Android Browser stock browser does and separate testing is not needed.

1. Opera Mini

Opera Mini has over 100 millions users and it is the most popular mobile web browser.

Opera Mini is not a full web browser – it’s a thin client. The pages are rendered in a server-farm in a Norway where Opera comes from. The servers send a compact subset of the webpage page to the handset instead or raw HTML, CSS and Javascript. This allows even the most low powered devices render complex web pages.

The thin client strategy in web page rendering is also used by Kindle Fire.

2. Opera Mini simulator

Opera Mini Simulator is a Java applet which you can run in your web browser.

Image

3. Opera Mini on devices

You can install Opera Mini on any device, including low-end phones and iOS devices.

Sadly, Opera Mini offers little debugging tools because the pages are rendered on remote servers. Your best shot is use Opera Mobile to render the pages, as the underlying Presto rendering engine is the same.

Opera Mini, even if being thin client, can execute Javascript on page load and click handlers on the server side, but the execution time is limited (around one second).

4. Opera Mobile (not mini)

Opera Mobile (not mini) is a full browser which you can install various handsets, including Android, Nokia and Windows Mobile.

Opera Dragonfly debugging tools support remote debugging on the mobile devices. You can use desktop debugging tools to inspect a page running in a mobile phone. A very handy feature for all mobile web developers.

5. Firefox Mobile (a.k.a. Fennec)

You can install Firefox Mobile on Android devices. There also exists community maintained port for Meego mobile platform and unofficial builds for iOS and webOS. The current builds use native Android UI and mobile optimized version of Gecko rendering engine. For more complex (web)  pages the speed of the browser beats Android Browser stock browser. Firefox Mobile is also the only currently shipped mobile browser supporting WebGL.

Image

A Firefox Mobile PC built exists for Microsoft Windows, OSX and Linux and is suitable for testing purposes. Note that some effort might be needed to make it run,  as these builds are not officially supported.

Download instructions for PC/Mac:

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

Testing mobile sites on Android and its emulator (Mobilizing websites with responsive design and HTML5 part 11)

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

This blog post deals testing mobile sites for Android devices. Android comes with a browser called Android Browser (very Germanic naming habits they have…). It is developed separate from Google Chrome which saw its first mobile release recently. Android also features many after market browsers which will be dealt separately in an upcoming blog post.

Android Browser’s WebKit based rendering engines is a moving target and support for HTML5 and CSS3 vary greatly between Android releases. For example, HTML5 <video> support is known to be broken to the point you cannot really use it. It also does other funny stuff. JIT Javascripting support was introduced in Android 2.3.

Because there are no forced firmware updates and carries and OEMs are being more evil than Google, Android version market share is very fragmented. Currently the most popular Android versions are 2.2 and 2.3. Android 4.0 (Ice Cream Sandwitch) is generally under on 1% depending on the markets.

Luckily, unlike with IE, Android mobile devices broke down quite fast and we don’t need to bear with old buggy browser releases for unforeseeable future, only for the next few years.

1. Android Emulator

Android SDK and emulator run on all Microsoft Windows, Linux and OSX, the SDK being most versatile of all mobile vendor SDKs. Android SDK is free – no registration needed.

Download Android SDK

Note: Android emulator is an actual emulator, not simulator. It emulates the full device, including executing ARM processor code on your CPU. It is 1:1 emulation. However, the price for this accuracy is that the emulation speed is sluggish as a brown bear waking up on Finnish winter morning. Testing sites on the emulator is painful – testing on the actual device with proper logging support (see below) is recommended.

Image

Note: There is x86 Android port coming up and if someone has more information if x86 emulators already exist and if you could run Android Browser on then I’d like to know. Running native processor code should greatly speed up the emulation experience.

For Android SDK, get the Eclipse IDE plug-in. It features nice logging options and quick start for different emulator versions.

Android emulator allows you to experience with different screen sizes and DPI ratios.

Image

2. Android Devices

Android devices are cheap and for testing you should easily get low end Android smartphone under 150 USD. SIM card is not necessary, you can test mobile sites over WLAN connection.

The device speed is an also an issue – many Android devices are equipped withß underpowered CPU and GPU. When you test for Android, get the cheapest possible device (ZTE) to make sure you’ll get the crappiest user experience out of it – this is what the most of Android users will get. Don’t get expensive phone like Samsung Galaxy or Nexus.

3. Logging and debug console output

Android emulators and devices have a logging capability called LogCat. console.log() output is directed to LogCat log stream.

4. Screenshots

Taking screenshots on the Android device itself is pain – special debugger commands are needed. Samsung has made its own screenshot shortcut for Android devices.

 

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

Mobile site testing overview (Mobilizing websites with responsive design and HTML5 part 9)

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

After your mobile site starts look complete in a development browser (e.g. desktop Firefox+Firebug combo) then it is time to begin testing it in actual mobile browsers. This blog post gives you introduction and some general tips for mobile browser testing. Each platform (iOS, Android, others) are dealt separately in the future blog posts, so don’t forget to follow.

1. The micro battle field of browser vendors

Like with desktop where you test your site across browsers you need to test the mobile site in different mobile browsers. The testing is important because mobile browsers use different browser engines and different engine versions. Thus, sometimes output differences are expected and you need to iron out the ugliest issues.

The major mobile browser engines are WebKit on Safari/Android, Opera (Presto) and Firefox (Gecko). You luckily could say that mobile Internet Explorer’s market share is so minor that you might want to bother for it currently. Microsoft is constantly improving its mobile browser, but currently it is not in a state to match the competition in feature wise and we’ll look forward to see what Windows Phone 8 will give us.

There exist two popular after market browser (Opera Mini, Firefox Mobile) with their own engines. Opera Mini is a thin client browser and special considerations with e.g. Javascript interaction must be followed to make the sites behave well. Firefox Mobile can be installed on Android devices. There exist several “browsers” in app stores for iOS and Android, but they are simply wrappers around the native operating system WebKit component and do not contribute significantly to HTML rendering bits. Opera Mini, being the most popular mobile browser in the world by “shipped devices” count is preferred in developing countries due to capability to run low end phones, or anything having CPU and battery power. Don’t forget to test on these also.

The good news are that if the mobile browser support CSS3 media queries, as used in the mobilization strategy of this tutorial, then they are likely to have very good support for HTML5, CSS3 and other modern goodies. The fixing and workaround work found during the testing is usually less than what it takes to make the site run older Internet Explorer.

If you need to define compatibility list of browsers e.g. for an offer I recommend use this jQuery Mobile mobile browser grading table. It gives you an overview how “good” mobile browsers are.

2. Accessing different mobile browsers on devices and simulators

If you aren’t a mobile developer you might not have access to a real test device repository. Luckily, the simulators by the mobile vendor themselves are pretty good nowadays and you don’t need to be physically able to access the every device out there.

It is desirable to minimally have one iOS and/or one Android device for testing. If you are targeting popular iOS devices (iPhone, iPad) it’s pretty hard to get around the fact that you need to get a Mac. Apple tools are only for Apple computers, like Microsoft mobile tools are only for the latest Windows 7.

There exist generic remote testing services for mobile phones, but they often are costly and not a substitute for the real thing.

3. No shortcuts to testing happiness

Warning: Do not use browser+<iframe>-based “mobile simulator” or whatever crap web search throws on you.

These so called simulators are usually pitiful attempts to grab web traffic for ad money without actually adding any value to testing. Running <iframe> based simulator in your web browser is simply the same as opening the page in your desktop web browser directly, with the window size shrink.

Shortening URLs

Typing on the mobile devices is cumbersome. Use URL shortening services like bit.ly to shorten your test page URLs, so you can type them in faster on touch screen or keypad.

4. Desktop web browser testing

If you need to alter HTML code or main CSS when mobilizing a legacy website you still want to see that your HTML changes did not introduce issues on the desktop browsers, especially older and problematic Internet Explorers. Here are some desktop testing resources, but I’d hope to hear of more pointers and services so please comment.

5. Internet Explorer virtual machines

How to automatize the installation all Internet Explorers on OSX and Linux using VirtualBox and one liner shell script.

6. Remote page rendering services

Please refer to this Smashing Magazine article for list of cross browsing testing tools.

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