Jump to content

My W3C speech on Web browsing + a full explanation


Recommended Posts

Guest Menneisyys
Posted

As has been announced some weeks ago, I had a W3C speech a week ago devoted to Web browsing on mobile devices. You can find the (English) slides HERE. (Sorry, some of the example screenshots are in Finnish. This, however, doesn’t have a detrimental effect on the overall understandability of the material.) In order to understand the slides, I’ve also decided to comment on all of them so that the entire Windows Mobile, Symbian and BlackBerry mobile community can benefit from my speech – in written form. Finally, note that, albeit this article is over 80kchars long, it in no way can provide a FULL, absolutely thorough overview of the Web browsing scene on these platforms. That is, if you don’t understand something, don’t despair: in my referenced, previous articles, you can, in most cases, find a very thorough dissemination of the subject. Just an example: in this article, I only devote some 2kchars to the subject of downloading files while my original, devoted article, along with its (recent) updates, amount to over 100 kchars.

I also provide in-line screenshots in this article so that you know what I'm speaking about without constantly switching to PowerPoint; however, to see the original document at its full (and copy/pasteable) glory and resolution, you'll need the PPT file.

W3CEsitys0526TH.jpg

(Sorry for the comparatively bad quality – captured from the 1024*768 M-JPEG video(!) recording of my Canon 960IS camera.)

Slide01.PNG.jpg

(no comments needed)

Slide02.PNG.jpg

(just some self-promotion :D )

Slide03.PNG.jpg

(Promoting my employer and me. Incidentally, should you want to support my employer - and, through that, me - with a, say, contract for some kind of development or any kind of IT consultation [if you work for a company that would like to outsource some kind of consultation or quality (!!!!), in-depth research], feel free to contact me and I’ll make sure my employer contacts you back. Even a, say, US$ 50,000 project would be welcome. I’ve been a generic – not just mobility! – IT consultant and lecturer [for example, for Sun’s Java training courses], but am also well versed in traditional Electric Engineering stuff like telecommunications and signal processing; see for example my forthcoming Digital TV / Telecommunications Bible for more info on the latter. That is, I’m in no way a mobility-only type of professional. In e-mail [werner AT pocketpcmag PISTE com, where change AT to @ and PISTE to . (dot)], I’m also ready to provide you with a more thorough list of past IT consultation, education etc. projects. It’s me that would be working on these contacts; together with an English editor to get the English right. I only expect serious inquiries. Please, if you like my articles and would like to see similar articles come out in the future too [it’s mostly because I have a lot of free time and a really cool environment at work that I am allowed to work on articles even during work hours], look around at your company to see whether there’s some way of outsourcing your, say, consultation, education or research needs. International contracts [on which I/we’ve worked several times] are welcome.)

Slide04.PNG.jpg

OK, let’s get to business. Given that in a 45-minute speech it’s entirely impossible to give the listeners a complete, detailed picture of the problems, the compatibility issues of each and every browser for all the three operating systems, I’ve added references to all slides (whenever applicable). To quickly look up the referenced article / Bible, just change “1327” in http://www.pocketpcmag.com/blogs/index.php?p=1327 to the number given after „Ref:“

Also, you’ll need to be aware of three articles not (always) linked as references. The two Windows Mobile Web Browsing Bibles have the reference number 1828 and 2084 for Pocket PC’s and MS Smartphones, respectively. They, therefore, translate to real URL’s http://www.pocketpcmag.com/blogs/index.php?p=1828 and http://www.pocketpcmag.com/blogs/index.php?p=2084 . My Opera Mini 4.1 (Ref: 2571) review, which is currently not discussed in either of the Web Browsing Bibles, is worth checking out for the latest information on this excellent browser. Also, you can find all my Web browsing articles in the Web Browsers category on my blog at http://www.pocketpcmag.com/blogs/index.php?blog=3&cat=61

Slide05.PNG.jpg

There are several established mobile operating systems (platforms). In this slide, I quickly list them. Of course, this is just a very high-level overview of the operating systems; it’s later that I elaborate on them more thoroughly; one by one.

Web browsing-wise, probably the most advanced platform is Windows Mobile (WM for short), which itself has basically two, starting with WM5, converging subplatforms: touchscreen-enabled Pocket PC’s (PPC for short) and touchscreen-less MS Smartphones. In WM6 parlance, they’ve been renamed to Windows Mobile 6 Professional / Classic and Windows Mobile 6 Standard, respectively. I’ve also listed Handheld PC’s for completeness (and as an introduction to the slide explaining the evolution of the built-in Web browser pre-installed on WindowsCE devices in the past 11.5 years), which are a dying breed.

Symbian is another, very important, consumer-focussed mobile operating system. The most featureful browser for its most popular breed, Nokia’s Series 60 (S60), is the Nokia S60 Web. They are, in addition, also able to run Opera Mini and other MIDlet-based browsers. It also used to have an Opera Mobile port, as was the case with some Linux-based models like the Sharp Zaurus.

RIM's BlackBerry is a very important business (and, with the advent of more consumer-friendly models like the Curve and Pearl and the, particularly multimedia-wise, really enhanced 4.5/4.6) operating system. Its Web browser has traditionally pretty bad. With operating system version 4.5/4.6, however, it has undergone a major facelift and received a lot of new features. For example, now, searching for text in pages works. This highly useful feature is only supported by very few other browsers – for example, it’s only been introduced to the two Opera browsers this year.

The hugely popular Apple iPhone runs Safari. It’s really a decent browser. The only real disadvantage is the complete lack of, for example, Flash (Lite) support. As YouTube (one of the major usage areas of Flash as of today) has a dedicated YouTube client, this isn’t that big a problem. Note that, unlike with the first three operating systems (and like all the following ones), I don’t elaborate on this operating system in the rest of my speech. Currently, iPhone doesn’t have Java MIDlet support; therefore, you won’t be able to run Opera Mini on it. Java, however, will be - hopefully - soon added.

Linux, after the, unfortunately, discontinued, but, technically, really-really excellent Sharp Zaurus series, seems to have been reborn: Nokia's Web Tablets and the non-Nokia phones based on the LiMo foundation’s operating systems are gaining popularity. Note that, as far as the old Zaurii are concerned, it had both Opera Mobile and NetFront (NF for short) preinstalled.

Finally, the once market-leading Palm OS is pretty much dead now; this is why I don’t elaborate on its (compared to what is available on Windows Mobile, iPhone and Symbian, not very advanced) browsers like the, with newer versions being NetFront-based, Blazer at all. Unfortunately, the only MIDlet manager (an environment to run Java-based applications like the Opera Mini browser) for the operating system is IBM’s now-discontinued J9, is really buggy and crashes frequently; this means you can’t even use Opera Mini on the platform.

Slide06.PNG.jpg

First, let’s take a closer look at Windows Mobile and the core operating system, WindowsCE, paying special attention to how the built-in browser was enhanced during the 11.5 years of maturation.

With WindowsCE 1.0 (Handheld PC), which was released in early 1997 and used on several models like the HP 300/320LX, the Philips Velo etc, has only a really basic (no frames) but already online (non-offline) browser. (We’ll soon see why I emphasize it being online.)

The next two major releases of the operating system, WindowsCE 2.0 and 2.11 (released early 1998 and 1999, respectively) has gone in two directions to cater for people wanting a really palm-sized and, to keep the size down, keyboard-less version of the, compared to the, then, like-hot-cakes-selling Palm handhelds, not really popular WindowsCE models. The new form factor was named Palm-size PC (PsPC). Several WindowsCE hardware manufacturers released PsPC’s; for example, Casio released the Cassiopeia two-digit series (E10 etc.); Philips released the Nino, HP the Jornada 430 which was even featured in a James Bond movie etc. These devices only offered offline browsing; that is, if you had any kind of Internet connection on them (via, say, an infrared connection to a mobile phone), you still couldn’t directly access any Web pages. Instead, you needed to use the desktop based ActiveSync tool (earlier called as WindowsCE Services) to fetch the pages for you and synchronize it to your handheld for offline viewing.

It was only in the “traditional” Handheld PC handhelds, for example, the HP 360LX/620/680 (with the OS version 2.11, called Handheld PC Pros) that still had online access capabilities with a hugely enhanced and updated Web browser much better than the one in WinCE version 1.0.

The market’s answer to the 2.x-series handhelds was pretty much lukewarm. This also resulted in several manufacturers like Philips leaving the scene for ever. It was not before mid-2000, with the release of WindowsCE 3.0 and its hugely popular Pocket PC platform (a heavily enhanced version of the PsPC platform, fixing a lot of issues like the lack of online browsing support) that anyone would say WindowsCE-based handhelds would seriously endanger the market penetration of Palm handhelds and BlackBerry messengers.

WindowsCE 3.0, which was released in May 2000, was the first really successful MS mobile op. system. As with the 2.x series, two operating system subversions were based on it: the, technically, much more advanced (for example, its built-in browser was already capable of finding text in pages, which the Pocket PC version isn’t even now capable of) Handheld PC 2000 (HP 720/728 etc.) using the traditional clamshell form and the descendants of Palm-size PC’s, now, renamed to Pocket PC’s. The latter received an online Web client again; at the time, it was clearly less capable than that of the Handheld PC 2000 OS. Ironically, the latter operating system has practically died out pretty soon and now (its descendants) is used in niche models only.

Slide07.PNG.jpg

Let’s go on with the Pocket PC operating system and its built-in browser, Pocket Internet Explorer (PIE). This was, incidentally, renamed to Internet Explorer Mobile (IEM) in 2005 with WM5.

In late 2001, the first version of the PPC OS (also called Pocket PC 2000) was updated to PPC2k2 (2002). While it did have certain advantages over the old operating system, Web browsing-wise it was more of a step back in speed / memory handling because it was incapable of rendering larger (about 150+ kbytes) pages – unlike its predecessors and successors.

In Spring 2003, Windows Mobile 2003 (WM2003 for short; notice the operating system name change!) followed with a much-much better built-in browser with, among other things, CSS support added. (Previous browsers didn’t at all support CS sheets.) Then, in Summer 2004, WM2003 Second Edition (WM2003SE) followed suit, with the native One Column mode being the most important enhancement (on which I’ll elaborate later), Web browsing-wise.

In Autumn 2005, WM5 arrived, also renaming PIE to IEM. It contained a heavily bugfixed IEM engine – some CSS contructs no longer result in the prompt termination of the PIE session, unlike in WM2003(SE). It was also the first PIE (IEM) version to support file uploading – a painful omission from previous PIE versions.

WM5 (and subsequent operating system releases) was also unique in that internal updates during the lifespan of the operating system were well-documented and referred to, easily checkable by an end user, via “AKU” versions. Just some major enhancements: while the initial WM5 IEM browser was pretty very slow to load Web pages, AKU 2 has fixed this almost completely. AKU3.5 introduced a High-Resolution switch for high-resolution VGA devices – another long-demanded feature.

In Spring 2007, WM6 followed suit, with no real improvements except the support for IFrames. Finally, this (2008) Spring, WM6.1 was announced with no real improvements either; a fully revised and enhanced version (a full port of the desktop IE6 engine) is promised later this (2008) year.

Speaking of the built-in browser, it still is pretty much incapable when compared to alternative browsers like Opera Mobile or even Mini. This is why there exist several so-called “plug-ins” or, with some less popular solutions, “shells” to enhance its functionality by adding, for example, multi-document (multitab) support. The most important plug-ins are as of today: Spb Pocket Plus, PIEPlus and MultiIE.

In the rest of my presentation, I’ll return to the compatibility issues of IEM several times; for the time being, let’s check out the other, alternative browsers.

Slide08.PNG.jpg

In addition to PIE / IEM, there are several third-party browsers on Windows Mobile. Let’s start with standalone, native Windows Mobile ones (native means you don’t need to run them in a specific environment like a MIDlet manager). The first group is non-streaming too, meaning no excess data fees over a non-flatrate connection / inability to use over non-3+G connections.

* Opera Mobile: probably the most important Web browser. It’s, more or less, based on a direct kernel port of the desktop engine, meaning excellent compliance with core Web standards. Note that the currently, officially available version, 8.65, is still based on the 8.x core; it’s only the latest, 9.x-series Opera Mobile that have, finally, switched to the 9.x core and delivers full compliance with all current standards. While it’s a fairly new browser (the first beta was released in early 2006), it’s taken the Windows Mobile Web browsing scene by storm and is the preferred Web browser of many.

* NetFront is a long-established browser. Unfortunately, while it does have its merits, the development seem to have slowed down and several major bugs haven’t been fixed for years. (For example, you still need to rely on the definitely inferior built-in Flash interpreter instead of having the ability to use external, official and much better-quality Flash plug-ins.) I really hope Access, the developer of NetFront, finally starts to make some serious enhancements to this browser.

* Thuderhawk: this is another long-established browser. The classic (native Windows Mobile) client has received no real improvements in the last about two or three years (except for adding Java applet support back in 2006) and it seems it’s completely abandoned as the company is switching to a MIDlet-based and, therefore, truly multiplatform (not only WinMo) solution.

* Minimo, which is an unofficial and, now, abandoned Mozilla Firefox-port. Unfortunately, I can’t really recommend this browser – its speed, performance and memory consumption is pretty bad when compared to most of the alternatives. Note that it has nothing to do with the real, official Windows Mobile Firefox port announced some months ago.

* Picsel’s browser is an OEM-only one and, therefore, can’t be acquired (legally) if it isn’t included in your factory ROM. It’s pretty slow and is incompatible with even basic Web standards. Nevertheless, some people still like it.

* Maximus: it’s a really poor and in no way recommended browser.

Streaming-based but still native browsers follow. The most important of them is SkyFire which, currently, only works in the 3G networks of the U.S. As I’m in Europe, I can’t really give it a thorough ride at the moment. Another, similar (but, based on the raving user reports on SkyFire, speed- and usability-wise, really inferior) solution was Microsoft’s DeepFish, which has been discontinued in the meantime. Also note that there are other, streaming-based, dedicated mobile solutions like DataWind’s PocketSurfer 2.

Finally, let’s elaborate a bit on MIDlet-based browsers. Their biggest advantage is the compatibility with all other mobile platforms, including even “dumb” feature phones (but excluding BREW-only dumbphones used in some American networks). This will even include the iPhone as soon as Sun (and Apple) gets their MIDlet manager, the environment you can run MIDlets in, ready. Their biggest disadvantages are

1. the somewhat reduced speed. In practice, however, you won’t really notice this; the only real difference is the download speed when you use the in-process download manager, as opposed to using the system-level Web browser to download files. As you will want to prefer the latter, this isn’t an issue.

2. the lesser integration with the operating system. For example, you can’t copy arbitrary text from Web pages. This can be done in a very awkward way with Opera Mini 4.1: save the page to a file and inspect the saved file (containing the Web page in a textual, albeit non-HTML form) with a copy-capable file viewer.

Another major issue is the inability to make the browser the default one for the entire system – at least for non-Windows Mobile operating systems. On the latter, thanks to me and two other developers, this is already possible, making your life much easier: you can now just click links in a, say, e-mail and Opera Mini (or, alternatively, any other Java MIDlet-based Web browser) opens the given page.

Of the MIDlet-based (non-native) browsers, it’s Opera Mini that is the most important. Now, as of version 4.1 and all its new goodies (like file upload and page saving), along with our direct invocation tools, it’s a serious alternative to fully-fledged, non-Java-based browsers.

Some other MIDlet-based browsers include TeaShark and UCWEB. The brand new version of Thunderhawk (TH for short) is also Java-based but is strictly OEM only and isn’t available for the general public.

Slide09.PNG.jpg

BlackBerry from RIM, as has already been pointed out, is mostly a business “push mail” platform, only recently opening its gates for the consumer wanting more multimedia and camera. Officially, it’s still at OS version 4.2 / 4.3; the new version, 4.5 / 4.6, is slated to be released in a few months. In the meantime, you will really want to check out the (largely unofficial) betas as they offer a lot of goodies seriously enhancing the usability, user- and, through the new fontsets, eye-friendliness of the platform.

In the two screenshots at the bottom of the slide, you can see how the old, 4.2 OS (on the left) rendered the first few entries in my Opera Mini favorites list and how the same is done under 4.5 (on the right). As can clearly be seen, under 4.5, much more contents can be displayed on the screen and the fonts are much better-looking and readable.

Slide10.PNG.jpg

As far as Symbian is concerned, there used to be several subversions of Nokia’s Symbian. (Here, I don’t elaborate on Sony-Ericsson’s handsets.) Of them, S60 is the surviving one and the once-common S80 and S90 versions are both dead. A major breakthorugh, touchscreen, will be added this or next year and Nokia is promising an iPhone killer, Nokia Cube.

S60’s later versions (namely, ones that represent the 3rd generation of S60, S60 3rd, and come with Feature Pack 1 (FP1) or [in the future] higher), have an excellent built-in Web browser, Nokia S60 Web. It’s based on WebKit, an excellent core to build Web browsers on. It also supports Flash Lite 2 and 3; the latter has been delivered in firmware updates (v21 for the N95) and not as standalone downloads. Flash Lite 3 is much better to play back YouTube / other videos than the full Flash 7 on Windows Mobile.

On the screenshot on the right, you can see one of its major features, the minimap, in action. It helps in positioning on a page quite fast and is, now, widely copied by other browsers like NetFront 3.4+.

Slide11.PNG.jpg

Now that we have had a bird’s view overview of what’s available on the three platforms (and, as far as Java/MIDlet-capable phones are concerned, - including, sooner or later, the iPhone - all of the other), let’s take a closer look at the issues a mobile Web browser can be confronted when browsing pages originally targeted at desktop (and not resource-restricted, dumbed-down mobile) browser users.

First, you need to consider architectural restrictions, the (comparatively) small amount of RAM (dynamic) memory (10...90 Mbytes on higher-end handsets; (much) lower on feature phones) being one of the biggest problem.

While you can, generally, build up the in-memory representation of even several kilobyte-long Web pages using less than 10 Mbytes, having restricted RAM severely restricts the handset’s ability to store multiple Web pages in-memory for quick access without having to re-fetch (re-download) them. Note that dynamic memory consumption-wise, I really recommend my thorough RAM usage tests in the Web Browsing Bible.

Different Web browsers certainly have vastly different memory needs; this is why, for example, Opera Mini 4.1 is able to keep up to 30 pages in memory even on devices with little RAM. Opera Mobile consumes about an order of magnitude more memory, but is still about two two three times better than IEM, NetFront or Minimo.

The CPU efficiency (a 624 MHz Intel / Marvell XScale is equivalent of a max. 200-300 MHz Pentium) can also be an issue, particularly if you provide dynamic content. While Java Script and Ajax (if it’s compatible at all) run pretty OK, the case isn’t necessarily the same with embedded Flash content, particularly on Windows Mobile platform, where the current, official Flash 7 plug-in is pretty slow. (NetFront’s own Flash interpreter being even worse.) As a rule of thumb, you should use Flash Lite 2 or 3 instead if you want flawless, fast execution. (Currently, Flash Lite 3 is supported by Symbian only and Windows Mobile is slated to introduce support only later.)

On mobile devices, cache reading / writing can also be about an order (or even more) of magnitude slower than on a desktop / notebook hard disk (1-2 as opposed to 20-40 Mbyte/s being typical). This means far higher page loading times if the particular browser employs a bad caching algorithm. (I’ve also very thoroughly elaborated on all these issues in the Bible; the reader is referred to it for more info.)

Multitab browsers may also be affected by the process number restrictions under pre-Windows Mobile 7 (that is, all current) operating systems. This will mostly result in issues with multitab browsers spawning an entirely new process for each and every tab (all IEM plug-ins work this way); that is, not with, say, Opera Mini.

Finally, "from stratch" browsers (that is, browsers that aren‘t direct ports of any established desktop Web browsers; some examples are NetFront, Thunderhawk, UCWeb etc.) generally suffer from severe bugs / errors on even the HTTP protocol level, let alone higher-level HTML / CSS bugs.

Slide12.PNG.jpg

Let us still elaborate on the question of what a mobile browser can be used for. As has already been pointed out, their biggest advantage on all mobile platforms is the fact that you aren’t restricted to specially formatted PDA/handset-only pages like WAP pages and you can access full pages initially meant for desktop users. This makes it possible for you to access orders of magnitude more pages than some 5-6 years ago with feature (dumb) phones’ only able to access WAP pages.

However, as has already been explained in the previous slide, you need to be avare of several possible problem areas when accessing an initially desktop-optimized page.

* First, >500k HTMLs (for example pages generated by Snitz Forums 2000 or even YouTube) may result in a severe slowdown or even crashes on the client; under Windows Mobile, particularly under the PPC2k2 operating system, which, as has already been explained, only allows for rendering max. 100-120k HTML pages without crashing

* As has already been explained, under IEM, the memory usage is about an order of magnitude more than the original size of HTML. With alternate browsers (particularly with Opera Mini and, to a lesser degree, Opera Mobile) this isn’t an issue.

* (Desktop) ActiveX controls are not supported, not even on Windows Mobile because it’s not an x86 architecture and, therefore, can’t run native x86 code.

* Some browsers (IEM and, particularly, Thunderhawk and Picsel) have very weak javascript support

* Unfortunately, Java applets (login, authentication) are only supported by custom third-party JVMs only. What is more, it’s only available on Windows Mobile – that is, there’s no applet support at all on Symbian / BB. On Windows Mobile, applet support is pretty restricted and is only compatible with up to JDK1.4 (unless you use Thunderhawk). There's no official support from Sun on these three platforms either, unlike on iPhone.

* I’ve already mentioned the Flash incompatibility and problems and the less important HTTP/HTML problems, bugs and restrictions.

Slide13.PNG.jpg

On slide 8, I’ve already elaborated on the different networking models used by Web browsers, as far as client-middle tier server streaming-based vs. standard, middle-tier-less browsers are concerned. A nonstandard setup can be vastly different from the pretty much bandwidth-hungry streaming-based solution, however. On this slide, I further elaborate on this distinction.

Most online (as opposed to offline; see for example AvantGo, Mobipocket Reader or iSilo offline web downloading and ActiveSync-based syncing to the handset) browsers use direct connections.There are, however, clients that do have a (sometimes simplified) client-side textual (!) renderer component – as opposed to traditional streaming clients (SkyFire, DeepFish and specialized hardware like PocketSurfer 2) – don’t consume much data. On the contrary: one of the design goals of these clients was to vastly reduce data usage, which is of paramount importance with non-flat rate connections - like those of Canadian mobile operators - and make them usable even over super-expensive, typically, 3...5 Mbyte/month BlackBerry data plans. That is, they work in exactly the opposite way as data-hungry apps like SkyFire and deliver considerable data saving even when compared to accessing the same Web pages with a standalone client.

The most important of these client/server browsers, making use of (pretty much) transparent proxies, are Opera Mini (and most of? all? the other MIDlet-based browsers) and Thunderhawk.

These solutions have some drawbacks:

* possible eavesdropping (definitely not the case with Opera; as far as some new, “noname” Chinese browser companies are concerned, however, many believe that the opposite is true; as a rule of thumb, never ever enter any credit card info in any of these new and pretty much unknown browsers)

* they are not flexible enough – there’s no way to use other proxies like the highly useful header rewriter proxies to allow for, say, asking for nationalized versions of pages (more on this later)

* sometimes introduce a definite delay because the (sometimes overburdened) middle-tier server has to process the source pages themselves. With Opera Mini, the delay, typically, ranges from 2 to 30 seconds – that is, sometimes it’s on the verge of acceptability.

* Some incompatibility issues with some sites; for example, the current Opera Mini 4.1 is not compatible with the “Quote” button in vBulletin version 3.6.8 currently used at, say, forum.xda-developers.com.

Some of the pros (much less data overhead) have already been mentioned; on top of that, what you gain is also anonymity. That is, your real IP is hidden – the Web page you access sees Opera’s middle-tier server as the client, not your own IP. Note that your IP is told to the Web server but in an extended HTTP request header, which few of these servers log.

Slide14.PNG.jpg

Now, let’s turn our attention to IEM, that is, the browser coming with built into the Windows Mobile operating system. As has already been explained, it has pretty weak and, with standard Ajax, plain non-existing Ajax/javascript support. Its CSS support is equally bad. It doesn’t support the multidocument model (which was introduced in IE7 on the desktop) support without 3rd party so-called “plug-ins”. It’s also pretty much limited in that it has no link target / current page saving capabilities (which are pretty much essential). The same used to apply to image saving in operating system versions prior to WM5. Also, it has severe restrictions like absolutely no IFrame support in pre-WM6 versions and only supports displaying 12 (in WM6) and 10 (in pre-WM6) frames. In this regard (too) alternative, commercial browsers fare far better.

Its stability used to be pretty bad in pre-WM5 times too: it frequently crashed because of certain CSS constructs. I’ve found and published several such CSS constructs back then. This is, fortunately, no longer the case in WM5+.

The two screenshots show how the mobile version of the PPCMag blog and the desktop version of YLE’s (Finnish Broadcasting Company) main page is displayed on a high-resolution VGA device.

Slide15.PNG.jpg

Historically, on high-res Windows Mobile models, IEM had the “pixel doubling” problem, meaning images were still rendered as low-res, with double their size. This was fixed in WM5 AKU 3.5 (in early 2007), which lets the users switch between “High-resolution” and the default standard mode. This, however, didn’t really help external applications making use of the IEM rendering engine to display HTML-formatted contents like CHM readers – they still render images with pixel doubling (and, unfortunately, charts too) on high-resolution devices.

Incidentally, when used as a plug-in, there is another source of problem. If you don’t close HTML tags right after the (last) word like in foo bar (as opposed to foo bar), then, the two (formatted and the next) words will be rendered without a space in between them. In the two screenshots presented in the article (a low-res QVGA and a high-res VGA one), I show the results of this “bad-formatted” construct. Note that in the expression “fox jumps over a lazy dog”, ‘fox jumps’ is rendered as one word only because its HTML source was like this: “fox jumps over a lazy dog” and not the recommended “fox jumps over a lazy dog”.

Slide16.PNG.jpg

Let’s turn our attention to NetFront, a well-known commercial browser for Windows Mobile. While it’s a bit expensive ($30), it offers an excellent browsing experience – except for some (rather major) problems and bugs. For example, it has built-in Flash support, which is, unfortunately, weaker than that of Adobe / Macromedia used by both IEM and Opera Mobile (it has compatibility issues and severe CPU usage problems). It supports SVG (which is very commonly used in Japan’s 3G content networks) and also has a Java VM to run applets. The latter, unfortunately, is definitely weaker than that of CrEme, the best JVM available for Windows Mobile and, in cases (where there isn’t much animation / graphics involved), even the Java support of the traditional, non-MIDlet-based Thunderhawk. It supports multitabs but their number is, unfortunately, maximized (to five) – as opposed to IEM plug-ins, Minimo or the Operas. I just can’t understand the rationale for this restriction; after all, on a modern 128 Mbyte RAM device, dozens of Web pages can be stored in RAM for quick access / swith. It also has minimap support and, which is very important for many iPhone fans, iPhone-like acceleration when dragging the screen contents by a finger / the stylus.

It has, as of version 3.4 and 3.5 (not NOT previous versions!), has pretty good Ajax/ javascript/ CSS support and its rendering engine is definitely better than that of IEM.

The recent releases are as follows: 3.3 (Summer 2006; inferior); 3.4 (Fall 2007): OEM only; currently: 3.5 Technical Previews. This, unfortunately, means you can only get the outdated and (compared to later 3.4 and current 3.5 versions) pretty much incapable 3.3 if you plan to go for this browser. Unfortunately, the currently available 3.5 Technical Previews versions are pretty much limited: no more favorites than 10; no Java / Flash support; no more tabs than 2. In this regard, Opera Mobile and most IEM plug-ins with their 30-day unlimited trial is much better. I hope the NetFront developers consider this and unlock all the features of future Technical Previews, only leaving a timebomb in rendering the browser useless after a certain date. (Noone will set their clocks back – and suffer from the consequences – just to be able to run NetFront to save $30.)

Slide17.PNG.jpg

Now, let’s take a deeper look at Minimo, the free and, unfortunately, discontinued (cancelled), unofficial Firefox port. Note that the already-announced official Firefox will be later released for Windows Mobile; currently, no release date is known.

It comes in two versions: 0.16 (for pre-WM5 devices) and 0.20 (for WM5+ only). It’s plain useless on some models because of speed problems and other bugs. On the ones that it doesn’t have model-specific problems, however, is a semi-decent alternative if you really want a free browser other than Opera Mini.

Being based on the Firefox engine, it has excellent scripting (including Ajax) and CSS support. Not as good as Opera Mobile 9.xx, though.

Slide18.PNG.jpg

Now comes without doubt (as of version 9.xx) the best, fastest and most powerful standalone Web browser, Opera Mobile. It has excellent JS / Ajax support, almost 100% compatibility with all Web standards, particularly with version 9.33; it’s very fast at everything (loading pages, downloading files etc.), supports the standard Adobe / Macromedia Flash plug-in (unlike NetFront, which forces the user to rely on the built-in and definitely inferior Flash engine) and lets for opening any number of tabs, as opposed to NetFront or IEM without a plug-in. It (as of version 9.xx – but, unfortunately, not the currently commercially available 8.65) also has some other goodies like finding text in pages, which is not available in any IEM-based solutions, not even commercial ones.

Currently, it’s available in two versions: the official (8.65) and the preview (9.33 / 9.5), for both PPC’s and Smartphones. The latter, 9.xx-series has without doubt the best standards compliance of all browsers for Windows Mobile.

Slide19.PNG.jpg

Opera Mini, as of version 4.1, has become a really-really decent alternative to other Web browsers, particularly if you need a free solution. As it’s a MIDlet, it’s compatible with almost every phone out there – even feature phones. This means you get exactly the same menus, the same shortcuts on, say, your wife’s low-end feature phone and your smartphone.

It requires a separate environment, a MIDlet manager, to run. I’ve elaborated on the different MIDlet managers available for Windows Mobile in the MIDlet Bible, which you definitely should read if you want to get introduced to the wonderful world of MIDlets. (Note that you won’t necessarily need to read it if your only aim is to be able to install and use Opera Mini 4.1; then, all you’ll need to do is reading my 4.1 deployment and usage tutorial.)

As of the current (4.1beta) version, it offers even file upload, address autocompletion and page saving capabilities. Full page view is also supported (which has been added in version 4.0), retaining the full layout of the original page - as opposed to the one-column view. Incidentally, it’s this that you can see in the above screenshot too.

Its only problem is the lack of arbitrary text copying from Web pages. This could easily be fixed as is done in Russian Opera Mod (an unofficial and, unfortunately, illegal modification of the original Opera Mini) – feeding the textual page contents to a text input area, where it can already be copied to the clipboard if the particular MIDlet manager allows for this (all of them do on all the three reviewed mobile platforms; the only exception is the discontinued and outdated TAO Intent MIDlet manager on Windows Mobile).

As it’s a proxy-based solution, it has far less data usage; however, it can’t access local files (files in the file system) and the additional processing can take some time (typically, between 5 and 30 secs).

Thanks to extensive hacking, direct invocation has also been implemented (originally by me), which greatly enhances its usability on Windows Mobile because it lets for being directly invoked when you click a link in an e-mail or Office document. This isn’t as important on Symbian and BlackBerry because it’s far easier to copy / paste e-mail links in these operating systems (when you step over a link, it’ll be highlighted at once; then, you can copy it to the clipboard at once [as opposed to the, in this regard, much slower and more awkward Windows Mobile]; pasting to Opera Mini’s address input field is equally easy and quick), should you want to avoid using their built-in, respective browsers (for example in order to keep data usage down.)

Finally, still on the subject of Symbian and BlackBerry: while all public builds of version 4.0 frequently (about once a day) crashed on these platforms, I haven’t ever encountered any crashes with 4.1. That is, you won’t ever need to remove and reinsert the battery in order to reset your handsets.

Slide20.PNG.jpg

Thuderhawk has a long history on Pocket PC’s. (It also had a MS Smartphone-compliant version, but only for low-res, 176*220 screens, and a QVGA version has never been released for this platform.) Unfortunately, it also seems it’s no longer worked upon as the developer has entirely switched to a MIDlet-based solution to directly compete with Opera Mini. (Which is more than hard as Opera Mini is really-really good.)

Thuderhawk’s biggest advantage has always been it being based on its own fontset (BitStream is also a font designer company), which makes original-layout, full page rendering possible even on 320-wide (QVGA) screens by using special, narrow, but perfectly readable fonts not otherwise available under Windows Mobile. Note that IEM can use similar fonts to look pretty much the same condensed as is explained HERE; the lower right screenshot shows exactly this, while the upper one shows a typical forum page rendered on a 320-wide screen without any need to do any horizontal scrolling.

Unfortunately, being based on a custom fontset means Thunderhawk only supports Western characters; meaning no support for most Eastern European or oriental languages. With Eastern-European, non-cyrillic languages like Polish, Romanian, Hungarian, Czech, Slovakian, Slovenian etc. that use alphabets pretty close to Western languages, this can be somewhat fixed by converting their special, Unicode-only characters to 8859-1 on the server side; with fully Unicode languages, on the other hand, this can’t be done.

Thunderhawk has no support for hi-res ((W)VGA) screens (it displays contents at QVGA effective resolution); doesn’t let for any kind of page / link target saving at all and doesn’t even support copying to the clipboard from Web pages. It doesn‘t use client-side web page / image caching at all (meaning, at times, it may result in far bigger data usage than most of the alternatives); it is only able to download files to built-in storage (not to storage cards or other, alternative media); it has absolutely no support for file upload etc.

Slide21.PNG.jpg

Microsoft Deepfish should also be mentioned, which was more of a pilot project slightly more than a year ago to see how server-side content rendering with plain image-based client-server communication works. It wasn’t anything to write home about: because of the client’s being based on the (comparatively) slow Compact Framework and the middle tier server’s being overloaded, it was pretty slow in real use. It’s been discontinued in the meantime. It’s still not known whether it’ll be reused in future Microsoft browsers – for example, in the IE6 port slated for later this year.

Slide22.PNG.jpg

Now, let’s take a look at the IEM plug-ins, which greatly extend the functionality (but, alas, not the Web standard compliance / conformance) of IEM.

These plug-ins greatly extend IEM’s capabilities: they add multitab (multiple document) support, resource (page / link target / image) saving, User-Agent GUI-based setting; they let for using hardware buttons for much easier navigation / function access, address bar macros, altering the way the document is scrolled by D-pad etc.; some of them even have GPS-based, location-dependent services.)

* PIEPlus is probably the best and most featureful (resource saving, support for hardware button reassignment etc.). For pre-WM2003SE users (“One Column” was only introduced in WM2003SE), it has a unique feature not offered by other PIE plug-ins: the Pocket View one-column view

* MultiIE is also a decent IEM plug-in; albeit, it’s in no way better than PIEPlus any more (unlike in the past). Basically, it has a similar feature set as PIEPlus.

Slide23.PNG.jpg

ftxPBrowser: this PIE plug-in (or, more precisely, a shell), in pre-WM5 times, used to be highly recommended. As it’s mostly incompatible with WM5+, it’s not recommended any more.

Webby, another shell (not a real plug-in), is .NET Compact Framework-based and is, therefore, a bit on the slow side. However, it’s become better and better over time and offers for example extensions like Mozilla for for example ad filtering. It doesn’t let for accessing some of the features of the underlying IEM; for example, it has no One Column mode.

The brand-new Touch Browser, which tries to mimic Safari on iPhone, is pretty similar to Webby in that it’s another CF-based shell. The initial versions were pretty bad; hopefully, future versions will, hopefully, improve on the situation.

Finally, Spb Pocket Plus 4 should be mentioned (see screenshot on the same slide, showing its tabs). While before version 4 it was definitely worse (it didn’t even offer on-screen, easily clickable tabs) than PIEPlus or MultiIE (the two major alternatives), this is no longer the case: version 4.0 has fixed this, along with other goodies like accelerated screen dragging just like on the iPhone.

Slide24.PNG.jpg

Now that we’ve seen the major browsers (and plug-ins) for the three operating systems, let’s quickly elaborate on what problems running them under Windows Mobile may result in.

The most important of them, particularly under pre-WM5 operating systems (particularly under WM2003SE), is the driver memory usage, which rendered NetFront and Opera Mobile unable to start under certain circumstances – unless you reset the entire handheld.

Slide25.PNG.jpg

Let’s go on with discussing the different client-side techniques helping in reformatting (“reflowing”) a page to (horizontally) fit in a low-resolution screen. If we don’t do this, the low (horizontal) screen resolution (240 by default - 320 when used in Landscape -; some low-end MS Smartphones and pre-v3 Symbian S60 Smartphones had even worse-resolution (176*208 / 220) screens) results in having to scroll horizontally. This is why there are several “One column” client-side implementations. (There’re also middle-tier implementations like Skweezer; more on them later). On Windows Mobile, these special modes are supported by all browsers except Thunderhawk. On Symbian S60’s Nokia Web, in most cases, they are unnecessary as the browser is smart enough to be able to correctly re-flow text – as is the case in Opera Mini in non-one column mode. These two browsers are truly excellent in intelligently reflowing text.

In IEM, there’re (with WM2003SE+ devices) three rendering modes: the truly one-column “One column”, the “Fit to screen” (later renamed to “Default”), in addition to “Desktop view”. The three screenshots on this slide show an example BrightHand forum page in the Desktop / Fit to Screen (Default) / One Column order (from left to right).

Note that One column isn’t necessarily better than Fit to screen. There are cases when the latter delivers better results than the One column mode; for example, when you render simple charts (tables) not wider than 3-4 columns (or 6-8 columns in High-Resolution mode, if your handheld is a high-resolution one). Then, One column will display all the cells vertically, making the original layout completely messed up, while the Fit to screen mode will try to render them horizontally. However, in general, Fit to screen delivers results not needing horizontal scrolling in much fewer cases than Nokia Web or Opera Mini 4+ in non-mobile view mode, particularly on low-resolution (for example, QVGA) screens.

Slide26.PNG.jpg

As, as has already been pointed out, pre-WM2003SE PIE’s, where there’s no One Column and the only “Fit to Screen” (Default) mode can’t correctly render the contents of the page without horizontal scrolling, you’ll need to use one of the following alternatives:

  1. External Web compression / reformatting / one-columnizing services (Skweezer, Google Mobile etc.). They, unfortunately, get rid most of javascript code, making a lot of javascript-based functionality like changing pages in some forum engines inaccessible.

  2. PIEPlus because of the explicit Pocket View mode, which fixes this problem

  3. Use an alternate browser like Opera Mobile (WM2003) or Thunderhawk (compatible with even PPC2k / 2k2), which handle these cases much better

  4. Wait for Touch Browser’s (which does have a built-in One Column mode) becoming much better
Slide27.PNG.jpg

With Opera Mobile, the three rendering modes are almost the same as under IEM. It should, however, be pointed out that the One Column mode is buggy: the horizontal size is 240 pixels; that is, it’s only really usable on QVGA devices used in Portrait – preferably not in Landscape and definitely not on a (W)VGA hi-res model.

It, as has already been stated, generally fares much better in rendering blocks of texts without any need for horizontal scrolling. Just compare the first (leftmost) screenshot to the Desktop rendering screenshot of IEM: as can clearly be seen, this particular page was correctly (no need for horizontal scrolling) rendered by Opera Mobile in Desktop mode, unlike with IEM. (Of course, most of the time, you won’t want to use the Desktop mode, unless you need to see images in their original size, without being resized to fit the screen.)

The three screenshots, from left to right, show exactly the same three modes, in the same order, as with IEM: Desktop, Fit to screen and, finally, One Column. As the screenshots have been taken on a VGA device, the latter is buggy and only uses the left half of the screen.

Note that the One Column mode is clearly better implemented in Opera Mobile than in IEM (apart from the 240-pixel bug): it renders charts much better than IEM in One Column mode. See the example screenshots and discussion at the end of section 1.2 Opera Mobile of the MS Smartphone Web Browsing Bible.

Slide28.PNG.jpg

NetFront has three similar modes: Normal, Just-Fit (about the same as “Fit to Screen” / “Default” in IEM and Opera Mobile) and, finally, Smart-Fit. The latter mode is without doubt the best: it’s like One Column, but still tries to render contents horizontally where applicable, unlike IEM and like Opera Mobile.

The three example screenshots (from left to right), as with IEM and Opera Mobile, have been taken using Normal, Just-Fit and Smart-Fit.

Slide29.PNG.jpg

Minimo only has two modes: the default (desktop) mode and SSR (Small Screen Rendering), which is almost the same as One Column mode in the other browsers. The two screenshots show this (left: default, right: SSR).

Slide30.PNG.jpg

Finally, in the Thunderhawk screenshot, you can see how well it manages to display even the most delicate screen contents without the need for horizontal scrolling. Note that it forces the user to use the horizontal orientation, which may be overly problematic on models with screen polarization issues in this orientation (as opposed to Portrait mode). However, users of devices with pre-WM2003SE operating systems (and a device without polarization problems) will surely welcome Thunderhawk’s using Landscape mode – none of the alternate browsers do so, not even the ones that, otherwise, could (as with some e-book readers like Mobipocket), not being based on IEM. (It was in WM2003SE that user-switchable Portrait / Landscape rotation has been added.)

Guest Menneisyys
Posted

Slide31.PNG.jpg

Now that we’ve reviewed the browsers’ approach to rendering pages / textual page content originally designed for at least 800-wide screens on 176…640-wide screens, let’s turn our attention to other questions like (easily) controlling the browsers – for example, scrolling pages using hardware buttons.

There are several ways you can easily scroll a Web page up and down without using the touchscreen. The most common way of doing this is using the D-pad.

1. If you stick to using the D-pad, under IEM, by default, you’ll end up using link scrolling (as opposed to page scrolling). This can be a pain in the back, particularly on pages that have several links on them (you end up having to press Down several times to be able to scroll to new contents); fortunately, it can be altered on the Registry level (with a Registry hack). Most IEM plug-ins (PIEPlus, MultiIE at least) allow for doing this on the GUI level, making Registry hacks unnecessary.

Some browsers / plug-ins even allow for supplying the one-page-at-a-time scroll amount in percents. The screenshot in the slide shows exactly this with NetFront, where you can easily set this.

2. If you (also) utilize other buttons for at least page scrolling down, you can still use the D-pad for link scrolling (assuming you prefer one-handed use and don’t want to touch the screen to follow a link) by assigning the Page Down operation to any hardware button. This has thoroughly been explained in the Button Enhancer Bible.

3. Also, if you have a volume slider on your handset, you can use the jog dial / volume controller with the excellent SmartSKey utility; most of the browsers support this.

4. Under Settings / Buttons, you can also directly assign the “Page Up” and “Page Down” functionality to any hardware button (or, for that matter, even special buttons, jog dials and volume sliders with advanced, third-party button enhancer utilities like AE Button Plus.)

Note that, as far as Symbian is concerned, it Nokia S60 Web makes navigation pretty easy with its minimap accessed by pressing and holding the up/down button. So does the built-in Web browser with the latest, 4.5/4.6 version of BlackBerry. Finally, don’t forget that Opera Mini and Opera Mobile support page scrolling using the numeric buttons on phones that do have these – then, you can still use the D-pad to scroll link by link (or, if you use Mobile View [that is, One Column mode] with Opera Mini, left/right to scroll pages).

Slide32.PNG.jpg

While certainly not as widely used as Flash content (any more), Java applet support is still nice to have – some (mostly internal and/or enterprise front-end) pages (still) use Java applets. For Windows Mobile, there are several solutions - Java Virtual Machines (JVM's). BB and Symbian have absolutely no applet support.

IEM depends on JVM plug-ins (as is the case with Flash plug-ins). Only two JVM’s have applet support (JVM’s with no Applet support are IBM J9 (it’s MIDlet / Personal Java only) and Mysaifu (it’s application-only)):

* Insignia Jeode; last version dates back to 2003 (came with the iPAQ 5550 – and previous iPAQ models. Most of these are locked to either the iPAQ brand or the given model). Today, as Insignia / Esmertec has stopped developing it (because they have moved to producing MIDlet managers), it can in no way be acquired legally

* CrEme: this is without doubt the best JVM to run applets. Unfortunately, it’s not meant for non-OEM customers, albeit they do have a downloadable 30-day trial on their homepage

Unfortunately, unlike with the Flash (Lite) plug-ins, Opera Mobile can’t make use of these plug-ins.

As far as the other browsers are concerned, the following two browsers have a built-in JVM:

* NetFront 3.1+: acceptable quality / compatibility (unfortunately, worse than Jeode / CrEme – as is the case with Access’ own Flash support in NetFront)

* Thunderhawk: in order to avoid producing a huge install (even older, non-fully-fledged Java runtime libraries easily add 1-2 Mbytes to the static size of the program [let alone newer JDK’s like 1.5+], which is pretty low – around 700 kbytes – with TH) and still provide full (!) JDK 1.5+ compatibility, the BitStream folks have gone for a strictly client-server solution, the server-side actively interpreting and executing the applet and just sending its GUI as a static image to the client. It, while it indeed offers full JDK1.5+ compatibility, has some cons compared to all the other solutions using local code execution: the images are low-res, slow-to-refresh and can cause excess data usage as the image of their GUI needs to be downloaded to the client every, say, second.

There’s absolutely no applet support in Opera Mini/Mobile or Minimo. In addition, currently, the WebKit-based browsers (Iris etc.) don’t support applets either - as with the Flash plug-in. Hope at least this changes in the future.

Slide33.PNG.jpg

There’re some additional Web technologies that have become pretty standardized. You may have noticed Internet Explorer, Firefox or Opera don’t contain any kind of a Flash plug-in on the desktop Windows. The situation is exactly the same on mobile operating systems: few browsers or operating systems come with Flash support built-in (the two most important exception being NetFront on Windows Mobile and Symbian S60’s Nokia S60 Web with Flash Lite 2 / 3).

Flash being by far the most important additional technology requiring a plug-in (with most browsers), let’s take a deeper look at the Flash support on all these mobile operating systems. Let’s start with Windows Mobile.

IEM (all versions starting with PPC2k2) and Opera Mobile (as of version 8.65+) both have a somewhat restricted Flash 7 plug-in (and Flash Lite 2, in addition). It’s quite outdated and, of course, doesn’t support the latest technologies. It isn’t particularly efficient either; for example, its YouTube / other Flash video playback performance is plain sub-par.

NetFront has a built-in Flash engine, which is even inferior to the Flash 7 plug-in: it’s buggy, (even) less compliant and has major CPU usage bugs.

There’s absolutely no Flash support in Minimo, Opera Mini and Thunderhawk.

As far as BlackBerry, Symbian and the iPhone are concerned, they have absolutely no full Flash support. Symbian, however, supports Flash Lite 3 (depending on the model and the firmware used) – unlike Windows Mobile. Flash Lite will be discussed in the next slide(s).

(The screenshot shows the full Flash-based Bomberman, one of my favorite real-world Flash tester games, running in IEM.)

Slide34.PNG.jpg

Flash Lite 3, which has recently been released for some past and recent Symbian S60 3rd edition models as firmware upgrades, has excellent support for YouTube and other, Flash-based Web video repositories. It’s, unfortunately, not available for Windows Mobile / BlackBerry / iPhone (as yet). For WM, it’s coming; for the other two mobile operating system, nothing is certain.

The two screenshots show Nokia S60 Web on the v21 firmware-based N95 playing back YouTube videos; the bottom left in Landscape (the video shrinked to the QVGA screen size); the one on the right on the original size in Portrait (hence the vastly oversized video). I haven’t provided similar screenshots on Windows Mobile because the Flash 7 plug-in on WM is very slow & inefficient and it’s almost impossible to use it to play back any Flash videos. Fortunately, a lot of alternative methods for playing back YouTube exist for all these operating systems; this is the subject of the several following slides.

Slide35.PNG.jpg

As many users spend a lot of time watching YouTube (and other) Web videos, it’s definitely worth elaborating on the alternative technologies of playing them back.

First, let’s elaborate a bit on the two major formats YouTube content is delivered: the high-quality H.264 & FLV (with accordingly high data usage) returned by the firewall-friendly HTTP protocol, and the low-quality, low-(QQCIF) resolution 3GP (returned via the firewall-unfriendly RTSP protocol). We, of course, will mostly be interested in the high-quality version – unless we really need to decrease data usage and/or use a low-resolution mobile device like a MS Smartphone with a 176*220 screen.

The desktop YouTube Web interface isn’t the best for mobile usage (slow, huge – over 300 kbytes – pages; only Symbian + Flash Lite 3 is able to play back inline videos). There is a mobile version created and supported by YouTube, which

* Already supports all the functionalities of the desktop (account, upload etc)

* Is compatible with most mobile platforms having an RTSP / 3GP player like RealOne – no additional player needs to be installed

* Already has all the videos, unlike a year ago when it became public

However, it’s lower-quality 3GP only (no FLV / H.264) and requires RTSP. That is, it can be vastly inferior in most cases and, therefore, should be avoided.

The screenshot shows the results of a search using the native mobile YouTube interface (which, again, should be avoided, unless you absolutely don’t need the vastly enhanced video and audio quality of the FLV / H.264 videos).

Slide36.PNG.jpg

Let’s continue with alternate YouTube technologies – ones that don’t depend on the Flash plug-in (because of the slow and flaky Flash plug-in on Windows Mobile) or are usable on other platforms like the BlackBerry. Fortunately, there are several of them; one of the most important is vTap.

vTap has native clients for all mobile platforms. From the Windows Mobile one (see the upper right screenshot), you can even initiate video playback (this client is highly recommended and useful because it’s capable of searching on not only YouTube but also other video sites), while you can’t do the same from the BlackBerry one.

This also means you’ll need to turn to other solutions to stream YouTube videos to your BlackBerry handheld; an example of these solutions is vTap’s Web interface (not the standalone client) depicted in the three screenshots at the bottom, showing searching for clips, opening them as a stream and, finally, the media player rendering it. (Note that the rendered contents is invisible in the screenshot on the bottom right. This isn’t a bug.)

Slide37.PNG.jpg

Finally, one of the several alternative YouTube playback solutions is YTPocket, which depends on the external TCPMP FLV playback support (under Windows Mobile). The two screenshots show the results of a search and, then, initiating a download (and the consequent invocation of TCPMP for viewing).

Slide38.PNG.jpg

Let’s move on to another, completely different, but, for users of non-unlimited data plans, very important question: reducing data usage. This, incidentally, can prove very helpful for users over unlimited, but very slow (for example, GPRS, like Vodafone’s non-3G dial-up) connections.

There are several ways of optimizations and major data usage saving; this slide discusses the way you can drastically lower the data usage by employing server-side (gzip) encoding, which is supported by all mobile browsers (for example, on WM, starting with the PPC2k PIE; that is, it has had support for eigth years).

As a rule of thumb, if you can, you should check the Accept-Encoding header (telling you whether the client is able to process gzip-compressed responses) along with the User-Agent HTTP header to find out whether it’s a mobile client (should you only want to return GZIP’ed contents for mobile users if you find GZIP compression is using too much CPU on your Web server). If you go this way, keep in mind that several mobile users “spoof” their User-Agent headers so that servers never return mobile-specific contents to them. With some of these clients (most importantly, IEM), you’ll want to look for specific extended (X-) HTTP headers to be able to make a distinction between desktop and mobile clients - that is, correctly identify mobile ones.

Note that several content manager and forum engines (e.g., vBulletin) support GZIP’ing “out of the box” if it identifies the client as a mobile device.

Slide39.PNG.jpg

Unfortunately, if you are just a user and can’t ask a webmaster to return compressed (GZIP’ed) contents upon receiving requests from mobile clients but still want to (vastly) decrease your data usage, you’ll need to do some client-side work. There are two main categories of doing this.

The first group, largely consisting of the free Toonel and the commercial (between 30…50 US$ - cheaper for recurring customers) OnSpeed, runs a “proxy” on your Java-capable and/or Windows Mobile-based mobile device and configures (or, forces you to manually configure) your browser to access the Web through it. The proxy takes care of compression by being connected to another, invisible server. The advantage of this solution, compared to the next, is mainly that you 1. don’t need to pay attention to visiting a mediator Web page to do the conversion for you and 2. you will always receive full Web pages, not dumbed-down ones without, for example, scripting.

The second group consists of Web services like Skweezer, MobileLeap, Google Mobile etc. They are easier to initially set up than the apps in the first group (absolutely no need to install third-party apps on your mobile); however, they’re a bit harder to use and, as has already been pointed out, they can royally mess up Web pages. Most IEM plug-ins like MultiIE, PIEPlus and Webby automatically support the online services; the first two (Toonel / OnSpeed) can be used with all Windows Mobile Web browsers allowing for proxy usage (that is, everything except Opera Mini and TH – not a problem though as they’re content-stripped / compressed already).

Slide40.PNG.jpg

Let’s turn to an entirely different subject: compliance with different (important) Web standards. Let’s start with AJAX, which is getting more and more ubiquitous. Opera Mobile and Minimo have the best support for it; the two screenshots show these (OM on the left, Minimo on the right) rendering the entirely AJAX-based Google Image.

Unfortunately, IEM is (still) pretty weak when it comes to AJAX support, even as of WM 6.1. So is NetFront as of the currently commercially available 3.3; fortunately, 3.4+ is already much better. (But, again, currently, there’re only restricted Technical Previews of 3.5 you may not want to use because of the restrictions). Thunderhawk and Opera Mini both have rather poor support.

javascript support is pretty similar to this. The bad JS support of IEM results in, for example, Yahoo Mail buttons’ not working – a major problem with many users. The same stands for for example address autocompletion in Google Mail; currently, only Opera Mobile and Minimo support it (they have the best javascript compliance).

Slide41.PNG.jpg

Still on the subject of Web standards compliance, let’s take a look at the compatibility with CSS. In this area, Opera Mobile is without doubt the best as of version 9.xx. Version 8.65 (the one officially and commercially available; screenshot on the left) is a bit worse in this respect. Minimo is the second (screenshot on the right). The slide also shows how the desktop (9.x-series) Opera renders the test page (the only desktop browser to render it without any glitches – see the referenced article for more screenshots of other desktop browsers if interested).

Slide42.PNG.jpg

Let’s go on with evaluating the CSS2 (Acid 2) test results. This slide shows how NetFront 3.3 and IEM render the test. As can clearly be seen, they (particularly IEM) have nothing to write home about.

Slide43.PNG.jpg

Still on the subject of Web standards compliance, let’s see the results of W3C’s brand new “Web Compatibility Test for Mobile Browsers” suite. First, let’s see how the Windows Mobile-based Web browsers render this suite.

This slide shows IEM in WM6.1 (left), the 5-year-old WM2003 (middle) and 7-year-old PPC2002 (right). As can clearly be seen, the Web standards compliance of IEM is only a tad better than that of its very old PPC2002 ancestor.

Slide44.PNG.jpg

Let’s continue with the same W3C test suite, looking at the Opera Mobile and Mini results. The left screenshot shows Opera Mobile 9.33, which delivers almost flawless results (showing it’s indeed based on the new, 9.x-series kernel), as opposed to version 8.65 (2nd shot). Opera Mini 4.1 (on the right) delivers acceptable results – still much better than, say, IEM (see previous slide).

Slide45.PNG.jpg

Let’s take a look at the third (and last) Windows Mobile W3C test slide showing the current Techincal Preview of NetFront 3.5 (left); the WebKit-based Iris browser (middle) and Minimo 0.20 (right). As can clearly be seen, none of them really excel – Opera Mobile 9.x is just far better than any of them.

Slide46.PNG.jpg

Now, having finished with Windows Mobile, take a look at other mobile platforms. In the lower row, you can see the WebKit-based Symbian Nokia S60 Web (left), iPhone’s Safari (middle). The built-in browser coming with BlackBerry 4.2 (right) follows; the latest (still beta), 4.5 BlackBerry version (topmost) shows the new BB operating system indeed delivers a bit better results than the previous one – but still much-much inferior to even Opera Mini (which, incidentally, runs flawlessly on the BlackBerry).

Slide47.PNG.jpg

Finally, in order to give you a complete picture of what you can expect of desktop browsers, an overview of their rendering the same test. (On the bottom: Firefox 3 beta5 (left); Internet Explorer 8 beta (middle); IE7 (right); on the top: Opera 9.5.). As can clearly be seen, Opera is by far the best and even the latest version of IE8 is far-far inferior than even the latest 3-series Firefox.

Slide48.PNG.jpg

Now, let’s discuss the techniques needed to avoid certain HTML / page layout constructs that simply can’t be rendered by (some) mobile Web browsers. The most important stumbling block is that of frames: both IFrames and standard ones. First, let’s take a look at the latter.

With IEM (as opposed to most other major browsers) the number of (standard, not i-) frames is restricted (10/12 at most for pre-WM6/WM6+, respectively). One of the most widely known example of the affected pages is freemail.hu. The pictures show IEM (on the left) was simply unable to display the page in its entirety, unlike Opera Mobile (right), which has no frame limitations. Make sure you avoid an excess number of frames if you want to make your portal accessible to even IEM clients and you don’t have a specific mobile version!

Slide49.PNG.jpg

Now, let’s take a look at Inline Frames (IFrame). They are in no way supported by pre-WM6 IEM and Thunderhawk. The former is shown in the screenshot on the left, showing the pre-WM6 IEM’s inability to render the contents of the test page. NetFront and Opera Mobile, on the other hand, have no problems rendering this area (neither has Opera Mini).

The lack of IFrame support also means no Gmail / Yahoo Mail dynamic address completion (which works in Opera Mobile and Minimo) is possible because they’re entirely based on IFrames.

Slide50.PNG.jpg

This slide shows IEM coming with WM6 has indeed added support for Iframes and has raised the number of standard displayable frames to 12.

Slide51.PNG.jpg

This slide explains some common cookie handling-related problems with NetFront and Thunderhawk. The text speaks for itself; no need to explain it further (rather than following the links to my original, lengthy articles and elaboration).

Slide52.PNG.jpg

The next few pages elaborate on the language & encoding problems and internationalization (on Windows Mobile), which will be pretty important for you if you display / host / try to access pages not (only) using non-Western languages – or, for that matter, even special punctuation like .

First, NetFront handles the HTTP character encoding header (Content-Type) vs. meta tag entirely differently from the other browsers. It is, unfortunately, buggy when 8859-1 is used along with special 8859-1 punctuation – for example, if you write your posts in Word and don’t disable its automatic character substitution enabled (and active) by default.

Opera Mobile is pretty problematic at POSTing (NOT displaying /rendering!! Only when user interaction / form-based posting takes place) some contents; for example, special 8859-1 punctuation and everything different from 8859-1.

To easily fix these problems, if you’re a webmaster and know your pages do contain some special punctuation coming from, say, Word and want it to be rendered by NetFront or editable and (re)POSTable by Opera Mobile correctly, do convert dynamically (in the runtime) all these characters to their 8859-1, “plain” equivalents.

If an Opera Mobile client edits a non-8859-1 document (like an article or a forum post), convert all special Unicode characters (like ő and ű) to HTML char entity codes (ő and ű with ő and ű, respectively). These entity codes are correctly POSTed back by the browser.

Slide53.PNG.jpg

As has already been mentioned, Thunderhawk uses its own, Western-only character set. It contains absolutely no other characters. Even when the operating system does support the given character set (and is able to render all the characters well), Thunderhawk won’t and just display a hyphen as a placeholder upon encountering them (the text in the screenshot shows some of these). Therefore, in order to correctly display non-Western, but easily 8859-1-mappable languages (typically, Eastern-European languages not using Cyrillic characters belong to this category), as a webmaster, you may want to check for ThunderHawk User-Agents and substitute the characters accordingly when encountering a TH client.

Slide54.PNG.jpg

Some Web pages (and Web frameworks / content handlers) allow for easy internationalization – that is, dynamically returning a different-language page upon encountering a special HTTP request header. This slide elaborates on this and lists the two browsers (PIE and Minimo) that do let for setting this particular header. Unfortunately, the other browsers need an external HTTP request header rewriter proxy running anywhere (including your own PDA) to gain access to this functionality.

The two screenshots show IEM rendering b2evo’s login screen in English and Finnish (with automatical swithcing between them; no need for user interactions / language selection via links on the page), depending on the preferred language flag sent by the client.

Slide55.PNG.jpg

Unfortunately, several mobile browsers don’t really shine at Web standards compliance either when it comes to downloading and saving binary files to the local file system on these handhelds.

The problems most users face:

* Content-Type: text/plain response problems with binary content: IEM & NF don’t try to decide whether the body is binary and blindly render it – as opposed to IE on desktop Windows. No such problems exist with other Windows Mobile browsers. That is, make sure Content-Type is correctly set on the server to allow for binary downloading to IEM & NF! Alternatively, if you are just a user and have no effect on the webmaster’s correctly setting this header, either use an IEM plug-in allowing for saving link targets, use a standalone HTTP downloader tool like Adisasta WinMobile Download Accelerator 2+ or HandyGet - or switch entirely to a different browser.

* NF and Opera Mobile send out download requests twice, while other browsers – including desktop ones – only do this once. This is why for example downloading from RapidShare doesn’t work in these browsers. If you’re a webmaster, the solution is simple: never reject double download requests. If you’re a mobile client only, switch to IEM – at least for the time of download.

* Referer-related problems: before WM5, PIE (and Thunderhawk even now) don’t pass the Referer header. Therefore, if you’re a webamin, don’t blindly trust the Referer header always being sent in order to deny out-site download requests. Just make a User-Agent test to check whether download requests not containing a Referer header originate from PIE and TH. If they do, you can safely let them download.

Note that you can greatly speed up your Web (and FTP) downloads by using multithreaded downloader clients (like FlashGet on desktop). Currently, two of them are worth mentioning:

* The just-released Adisasta WinMobile Download Accelerator 2.0 (do NOT use older versions because they’re slow!)

* HandyGet 1.6

Slide56.PNG.jpg

The final slide discusses the opposite of the previous one: uploading files to Web. File upload is supported by all browsers (except for TH); IEM starting with WM5. As Opera Mini 4.1+ also supports it, you can even upload from the otherwise not very capable BlackBerry platform.

If you have a browser that isn’t upload-capable, then, switch to another browser that can. And, if you’re a webmaster hosting a page with file upload capabilities (like all forum engines, social network pages etc. allowing for attachment / image upload), you will need to ask your mobile clients to do the same. Alternatively, if you’re absolutely sure some of your clients won’t want to touch other browsers, you may also want to provide FTP upload support or, if you only look for text input, a HTML textarea to paste their text to.

The left screenshot shows PIE under WM2003SE. As can clearly be seen, there’s no “Browse” button (and file path field) in it – while the WM5+ screenshot (on the right) already displays (and lets for using) it, showing it (still) didn't have upload support.

Slide58.PNG.jpg

That's all, folks - hope you liked this all :D And, yes, feel free to ask questions even here, even now.

  • 7 months later...
Guest Menneisyys
Posted

I’ve just published my last roundup, sporting the latest Web browsers available:

Iris 1.0.16 (1.1.0 b3)

Opera Mobile 9.5b2 / b15233 (!)

Opera Mini 4.2.13337

SkyFire 0.85.0.8184

PIE, along with Spb Pocket Plus 4.0.2

Internet Explorer Mobile 6 (IEM6) (!)

NetFront 3.5.009 b729

… and compared all these to the Safari running on the iPhone with firmware v2.2.

The new roundup is available at http://www.modaco.com/content/pocket-pc-ge...cl-iem6-review/

  • 1 month later...

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.