Archive for the ‘Mobile’ Category

File Under: Browsers, Mobile, Web Standards

Microsoft Offers Guide to Adapting Your Site for IE 10

Nokia Windows Phone 8. Photo: Ariel Zambelich/Wired.

Microsoft’s Windows Phone 8 offers much better HTML5 support than its predecessors thanks to the Internet Explorer 10 web browser.

Unfortunately, if you’ve been building WebKit-centric sites IE 10 users won’t be able to properly view your site, which is why Microsoft has published a guide to adapting your WebKit-optimized site for Internet Explorer 10.

If you’ve been following CSS best practices, using prefixes for all major browsers, along with the unprefixed properties in your code, then there’s not much to be learned from Microsoft’s guide (though there are a couple of differences in touch APIs that are worth looking over).

But if you’ve been targeting WebKit alone, Microsoft’s guide will get your sites working in IE 10, WebKit, and other browsers that have dropped prefixes for standardized CSS properties.

Sadly, even some the largest sites on the web are coding exclusively for WebKit browsers like Chrome, Safari and Mobile Safari. The problem is bad enough that Microsoft, Mozilla and Opera are planning to add support for some -webkit prefixed CSS properties.

In other words, because web developers are using only the -webkit prefix, other browsers must either add support for -webkit or risk being seen as less capable browsers even when they aren’t. So far Microsoft hasn’t carried through and actually added support for -webkit to any versions of IE 10, but Opera has added it to its desktop and mobile browsers.

Microsoft’s guide to making sites work in IE 10 for Windows Phone 8 also covers device detection (though it cautions that feature detection is the better way to go) and how to make sure you trigger standards mode in your testing environment, since IE 10 defaults to backward-compatibility mode when used on local intranets.

For more details on how to make sure your site works well in IE 10 for Windows Phone 8, head on over to the Windows Phone Developer Blog (and be sure to read through the comments for a couple more tips).

File Under: Browsers, Mobile

Internet Explorer 10 Brings HTML5 to Windows Phone 8

Web font support is just one of IE 10′s new mobile tricks. Image: Microsoft

Windows Phone 8 brings Internet Explorer 10 to mobile, which means Windows Phone 8 devices have much better HTML5 support than previous releases.

The version of IE 10 that ships with Windows Phone 8 packs in most of the improvements found in its Windows 8 desktop/tablet cousin, though there are a few exceptions web developers should be aware of.

First the good news. IE 10 on mobile is leaps and bounds ahead of its predecessors and supports web app essentials like the Application Cache API for creating offline apps and IndexedDB for storing data. There’s also support for Web Workers, WebSockets and several of the new HTML5 form elements. For more on the latter, be sure to check out developer Andrea Trasatti’s nice rundown of HTML5 form support in IE 10.

IE 10 on mobile has all the new CSS features found in the Windows 8 version as well, including CSS layout features like CSS Regions and Grid layout. The Windows Phone Developer Blog also touts Flexbox, but it appears that IE 10′s Flexbox support uses the older syntax, which effectively means it doesn’t support Flexbox (so far Chrome and Opera are the only browsers to support the new syntax). Hopefully Microsoft will add support for the new syntax in a future IE 10 update.

While IE 10 for Windows Phone 8 is very close to feature parity with the desktop/tablet release, there are a few things web developers need to be aware of. Here’s Microsoft’s full list of things IE 10 can do on the desktop but not on phones:

  • Inline video
  • Some of the new manipulation views APIs  for touch panning and zooming, with the exception of –ms-touch-action
  • Multi-track HTML5 audio (simultaneous)
  • ActiveX and VBScript
  • Drag-and-drop APIs
  • File access APIs with the
    exception of blobs which
    are supported on Windows Phone 8
  • Windows 8 integration features: Link previews, pinned site icons & notifications and support for connecting sites to apps
  • Also in Internet Explorer 10 for Windows Phone, Window.open does not return a valid window object. This is because on the phone each “window” is isolated in its own sandbox.

The lack of support for the File Access API is disappointing, but to be fair iOS has been around for over five years and it just recently added File API support. However, the biggest gotcha for web developers may well be the last item since it’s not so much a missing feature as an unexpected behavior and could affect applications that would otherwise work just fine.

For more info on what’s new in IE 10, check out Microsoft’s technical documentation. For IE 10 on Windows Phone specifically be sure to read through the entire post on the Windows Phone Developer Blog

File Under: Mobile, Web Basics

Bandwidth and the Mobile Web Browser

Your website’s view of the tubes. Photo: Stig Nygaard /Flickr

High-resolution screens on mobile devices present web developers with an interesting conundrum — the screens are capable of displaying very high-res images, but on a mobile device bandwidth may be limited. What’s a web developer to do?

The answer, for now, is that there is no good answer; be it bandwidth or image quality you’re going to have to compromise somewhere.

That’s why mobile expert Peter-Paul Koch thinks browsers need to start broadcasting the connection speed of the device. “Browsers, especially mobile ones, should give information about the speed of the connection they’re on,” writes Koch in a recent blog post exploring just what that might look like and how web developers might use that information.

Here’s what Koch thinks developers need:

  1. We need an HTTP header, so that a server-side script can use the information to decide whether to send the lowsource or high-res images. Let’s call it X-Connection-Speed for now.
  2. A JavaScript property, say navigator.connectionSpeed, also makes sense.
  3. Chris Coyier proposed a bandwidth media query with matching min-bandwidth and max-bandwidth. Sure, why not?

Check out Koch’s post for full details on other aspects like units, how connections speed might be calculated and what to do with edge cases — like when the connection speed changes between read and page load (Koch’s scenario imagines a user on a phone in a train with a good connection that deteriorates when the train enters a tunnel).

Koch’s post isn’t a proposal; rather its an exploration of the idea and he’s looking for feedback. There are already some great comments from other developers, including several that question whether web developers should be allowed to decide how much bandwidth a site uses.

While developers might like to be able to control bandwidth and deliver the images they’d like to be seen, that just might be a decision best left to users. For example, I may have a great 4G connection, but my data plan might be a mere gigabyte a month and I may not want to waste it on your high-res images. As David Ellenwood points out in the comments, a YouTube-style approach, choosing a sensible default and then offering up links to higher-res content (e.g., the 480, 720, 1080 options on most YouTube videos) might be the more user-friendly approach.

For now not only do browsers not broadcast connection speed, most don’t even have access to that information at the device level. But there are already proposals to add some sort of bandwidth info to HTTP (like the HTTP Client Hints proposal from Google’s Ilya Grigorik or Mozilla’s proposed Network Information API) and it seems likely that something along these lines will be added before too long. Be sure to read through Koch’s post for some more background and details. If you’ve got ideas, leave a comment on his site.

File Under: Browsers, Mobile

Firefox Aurora Brings Mozilla’s Web-App Marketplace to Android

The Firefox Marketplace in Android. Image: Screenshot/Webmonkey.

Mozilla is taking the wraps off the Firefox Marketplace, the company’s new web-app store for Firefox on Android.

Marketplace apps are only available in the newly-updated Firefox for Android 18, which is currently in the Aurora channel. To get Aurora installed on your Android phone you’ll need to be using Android 2.2 or better and make sure that the setting to allow apps from “Unknown sources” is checked. Once that’s done, head to the Aurora mobile download page and grab the latest release.

Once Aurora is installed the new Firefox Marketplace is available under the Options Menu. Choose the “Tools” item and select “Apps”. From there you’ll see a link to the Marketplace.

Given the convoluted installation and pre-beta status of Firefox 18, this release is obviously not meant for everyone. It does, however, offer developers a look at what Mozilla has been creating.

Right now the Firefox Marketplace is still rough around the edges. So far there isn’t even a way to accept payments, one of the much-touted aspects of the Marketplace. Mozilla says that payments and other common app store features like ratings and reviews are coming soon. There are plenty of free apps available already though, including Twitter, Lanyard, Todoist and quite a few games.

Installing an app from the Firefox Marketplace is as simple as clicking a button, which installs the app and adds a shortcut to the Android applications list. Mozilla has done a great job of making web-app installation indistinguishable from native apps on Android.

Firefox apps in the Android app switcher. Image: Screenshot/Webmonkey

The difference between native and web apps becomes more obvious when you start comparing speed side by side. For example Twitter from the Mozilla Marketplace is noticeably jerkier when scrolling compared to the native Twitter Android client.

It’s worth asking though, even if Firefox Marketplace apps matched native apps in performance, does you need web apps on Android?

The answer for most people is probably going to be no. However, building out the Firefox Marketplace on Android now ensures that the bugs are worked out and that there’s a smoothly functioning app store ready to go when Firefox OS officially launches.

And there are definitely some bugs and quirks in this early release, like the fact that in Android’s app switcher all Firefox Marketplace apps are labeled simply “App” rather than the name of the application, which can make finding what you’re after tricky when you have a lot of apps open at once.

The main purpose of this release is to work out exactly these types of kinks. As Mozilla Labs Engineering Manager Bill Walker writes on the Labs blog, “our goal is to collect as much real-life feedback as possible about the Marketplace’s design, usability, performance, reliability, and content.”

Developers interested in building apps for the Firefox Marketplace should head over to the Mozilla Developer Network and the Marketplace Developer Hub, which contain extensive documentation, FAQs and emulation tools for building Marketplace apps.

File Under: Browsers, Mobile

Opera Mobile for Android Gets ‘SPDY’

Opera Mobile 12.1. Image: Scott Gilbertson.

Opera Software has released a new version of Opera Mobile for Android phones. This update doesn’t offer many visible new features, but under the hood there are quite a few improvements that make Opera Mobile 12.1 well worth the upgrade.

You can grab the new Opera Mobile 12.1 for Android from the Google Play Store. Unlike some Android browsers, which only support the latest Android release, Opera Mobile has you covered all the way from Android 1.6 Donut to the latest and greatest, Android 4.1 Jelly Bean.

Like Opera 12.10 for the desktop the new Mobile 12.1 adds support for the SPDY protocol, WebSockets and a host of new HTML APIs. Opera Mobile’s support for the SPDY network standard, which promises to be even faster than the HTTP protocol, is especially welcome since it means speedier page loads on SPDY-enabled sites like Twitter and Gmail.

Opera Mobile 12.1 also introduces support for more “unprefixed” CSS rules, including transitions, transforms, gradients, animations and flexbox, all of which will now work without the -o- prefix. For now any code you have with an -o- prefix will still work as well, but make sure you’re including the unprefixed rule too since eventually Opera (and every other browser vendor) will drop support for the prefixed versions.

This is the first mobile release to introduce support for some -webkit- prefixes on poorly coded sites that don’t use unprefixed versions of stable CSS properties. Opera’s decision to support another browser’s CSS prefix has caused considerable outcry among web developers and members of the CSS Working Group, which created vendor prefixes. While the controversial -webkit- prefix support has been around in preview versions of both desktop and mobile builds, this the first official mobile release to support it.

For complete details on how Opera’s -webkit- prefix support works, as well as the details on everything that’s new in Opera Mobile 12.1 — like support for Drag and Drop, the Clipboard API and the Page Visibility API — be sure to read Opera’s blog post.