Posts Tagged ‘mobile’

Thursday links (July 8)

Thursday, July 8th, 2010

Mobile

YouTube Mobile Gets a Kick Start
Battle of Champions: HTC Droid Incredible vs. Palm Pre Plus
Designing for the Retina Display (326ppi)
AUDIO: John Resig: You Don’t Know Mobile (Webstyle Magazine) – ~$5,000 minimum to do mobile testing
Tapworthy: Designing Great iPhone Apps
eMobile: We have the fastest network in Japan!
Apple iPad User Analysis — Phase II
VIDEO: Using iPhone with a Braille display (Victor Tsaran)
Mobile Access 2010 (Pew Research)
BlackBerry and iPhone losing ground to Android, overall smartphone growth (comScore data)

JavaScript

JavaScript needs modules!
JavaScript Cache Provider (Dustin Diaz)
Writing Testable JavaScript

CSS

VIDEO: Nicole Sullivan on CSS (The Big Web Show)
CSS Media Queries & Using Available Space
Data URIs make CSS sprites obsolete (Nicholas Zakas)

Books

HTML5 For Web Designers
Tapworthy: Designing Great iPhone Apps
HTML5: Up and Running
JavaScript Patterns

Etc.

Web Forms: Semantic Mark Up in our Forms [part 2]
Non Hover – “Elements that rely only on mousemove, mouseover, mouseout or the CSS pseudo-class :hover may not always behave as expected on a touch-screen device such as iPad or iPhone.”
Video to ASCII conversion with Canvas
CAPTCHA slider
Rich snippets and structured markup (Google Webmaster Central) (SEO)
Firefox 4 beta 1 is here – what’s in it for web developers?

Using mobile-specific HTML, CSS, and JavaScript (Mobile web part 5)

Tuesday, June 29th, 2010

Mobile-specific HTML

Use the viewport tag to properly fit the content to the screen:

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"/>

Use the tel scheme for telephone numbers, allowing users to initiate calls by clicking:

<a href="tel:18005555555">Call us at 1-800-555-5555</a>

Or use the sms scheme to initiate an SMS message:

<a href="sms:18005555555">
<a href="sms:18005555555,18005555556">          <!-- multiple recipients -->
<a href="sms:18005555555?body=Text+goes+here">  <!-- predefined message body -->

You also have access to several Apple-specific tags to use in your web application (iPhone and iPod Touch):

// iOS 1.1.3+: this is the icon that's used when the user adds your app to the home screen
<link rel="apple-touch-icon" href="/custom_icon.png"/>

// iOS 3+: full-screen startup splash screen image
<link rel="apple-touch-startup-image" href="/startup.png">

// enable full-screen mode
<meta name="apple-mobile-web-app-capable" content="yes" />

// controls the appearance of the status bar in full-screen mode
<meta name="apple-mobile-web-app-status-bar-style" content="black" />

And also some handy attributes to turn off annoying autocorrect features (works on iPhone, but anything else?):

<input autocorrect="off" autocomplete="off" autocapitalize="off">

Mobile-specific CSS

Media queries enable you to target specific features (screen width, orientation, resolution) within CSS itself. You can use them two ways: 1) inline in a CSS stylesheet or 2) as the “media” attribute in the link tag, which targets an external stylesheet. The following is an example of inline CSS that’s applied only when the device is in portrait mode:

@media all and (orientation: portrait) {
	body { }
	div { }
}

Here’s the same media query using the other method, which points to an external stylesheet (not recommended, as it creates another network request):

<link rel="stylesheet" media="all and (orientation: portrait)" href="portrait.css" />

Here’s a few examples:

// target mobile devices
@media only screen and (max-device-width: 480px) {
	body { max-width: 100%; }
}

// recent Webkit-specific media query to target the iPhone 4's high-resolution Retina display
@media only screen and (-webkit-min-device-pixel-ratio: 2) {
	// CSS goes here
}

// should technically achieve a similar result to the above query,
// targeting based on screen resolution (the iPhone 4 has 326 ppi/dpi)
@media only screen and (min-resolution: 300dpi) {
	// CSS goes here
}

Read more: Media queries (Mozilla Developer Center)

(edit: removed section on body[orient='portrait'], which requires JavaScript and is in error. See Part 6: Dealing with device orientation for more details.)

Mobile-specific JavaScript

window.devicePixelRatio: determine screen resolution (analogue to the media query). (iPhone 4 has the value 2, while Nexus One has the value 1.5).

window.navigator.onLine (boolean): not strictly mobile, but helpful for apps to determine if they’re being run offline

window.navigator.standalone (boolean, iOS 2.1+): determine if it’s running in full-screen mode (Apple only?)

touch events (iOS, Android 2.2+): touchstart, touchmove, touchend, touchcancel

gesture events (Apple only, iOS 2+): gesturestart, gesturechange, gesturend give access to predefined gestures (rotation, scale, position)

window.orientation and orientationchange event: triggered every 90 degrees of rotation (portrait and landscape modes)

MozOrientation (Fennec/Firefox Mobile, Firefox 3.5+): also not strictly mobile. Gives access to the device’s accelerometer (x-y-z orientation data), updated periodically. Works on Android phones (I tested on the Nexus One), Windows Mobile, etc. On the desktop this works with laptops such as Thinkpads and MacBooks.

-near future: camera/microphone access in Android 2.3 (announced at Google I/O 2010) through the Capture API

If you’re developing for a BlackBerry Widget, you have access to proprietary information through the blackberry object (which gives access to useful information such as blackberry.network [returns values such as CDMA and Wi-Fi] and blackberry.system).

You also have the option to use PhoneGap, which augments JavaScript and gives you access to more phone features that native apps would have access to.

Use a mobile-optimized JavaScript library

Because smartphone browsers are standards-based, the aim of a JavaScript library on mobile is less towards API normalization and more towards providing an actual UI framework, usually to emulate the feel of native apps (and to provide easier workarounds to lack of access to position:fixed). We’ve seen a few libraries released that emulate the iPhone UI, and in the future we might see libraries emulating the Android UI, as well as entirely new UIs.

There’s also a bit to be said about simply loading full desktop JavaScript libraries into mobile clients. In my opinion this doesn’t particularly make sense, especially in a world where latency and bandwidth are so much more of a concern. It doesn’t make sense to force the user wait longer and download code that’s ultimately useless to them (hacks for desktop browsers such as IE 6, etc).

Here’s a few of the mobile libraries now available:
-Sencha Touch
-baseJS
-XUI
-jQTouch: jQuery-style mobile library that emulates the look of the iPhone UI
-iUI: the first JavaScript library to be released, emulates the look of the iPhone UI. Originally coded by Joe Hewitt.
-PastryKit: Apple proprietary non-public JavaScript library with no available documentation

Take advantage of new stuff!

While not specific to mobile, there’s a lot of new stuff in general that you can use. If you limit yourself to the top smartphones (iPhone, Android, and maybe webOS), compared to the desktop you immediately have access to an even wider array of new stuff, especially many Webkit proprietary features, since most of these top smartphones have browsers based on Webkit.

-HTML: new tags (HTML5 (I’m sure you’ve heard of it by now…))
-CSS: 2d transforms, 3d transforms, animation, border radius, custom fonts with @font-face, etc.
-JavaScript: strict mode, constants, block scope, Date.now(), etc.

Related posts

This post is part of a series on the mobile web. You can read the other parts of the series here:
Part 1: The viewport metatag
Part 2: The mobile developer’s toolkit
Part 3: Designing buttons that don’t suck
Part 4: On designing a mobile webpage

JavaScript SunSpider: HTC Evo versus HTC Incredible versus Nexus One

Thursday, June 10th, 2010

Result table

Test Evo (2.1) Incredible (2.1) Nexus One (2.2)
Total 16167ms 15237ms 5452ms
3D 2014ms 1835ms 946ms
Access 2126ms 1892ms 463ms
Bitops 1519ms 1591ms 360ms
Controlflow 243ms 206ms 20ms
Crypto 1033ms 1003ms 344ms
Date 1849ms 1896ms 639ms
Math 1684ms 1419ms 602ms
Regexp 1779ms 1673ms 155ms
String 3920ms 3722ms 1923ms

Thoughts

The Incredible is just slightly faster than the Evo, to the point where it’s probably negligible or within a margin of error. Both of these phones run on Android 2.1 with HTC’s Sense UI modifications, and represent the latest and greatest in Android phones available on the market today. Both run on the same 1GHz Snapdragon processor (QSD8650). The Nexus One is a bit older, and runs with an older version of the Snapdragon processor (QSD8250), however it still runs at 1GHz just like the other two phones.

As you can see the Nexus One blows away all the competition because it’s running Android 2.2 Froyo. These results were quite a shock to me and are quite impressive. These results even blow away Apple’s new iOS 4 running on my iPhone 3GS, which clocked in at a total time of 13787ms compared to the Nexus One’s startling 5452ms.

Testing methodology

Test: SunSpider 0.9.1

Devices: HTC Evo (Android 2.1), HTC Incredible (Android 2.1), HTC Nexus One (Android 2.2)

The SunSpider test was run five times on each phone. The phone was completely turned off and on before each test. The most extreme values of the five tests were thrown out, and the resulting four tests were averaged (sometimes from three tests when the values were very close together).

Raw results:

SunSpider HTC Evo results (5 tests)

SunSpider HTC Incredible results (5 tests)

SunSpider HTC Nexus One results (5 tests)

Related links

JavaScript SunSpider test: iOS 3.1.3 versus iOS 4 GM

Mobile First: Luke Wroblewski on mobile design

Saturday, June 5th, 2010

Click to play Luke Wroblewski: Mobile First

In episode 6 of The Big Web Show, Luke Wroblewski gives his “Mobile First” talk, explaining his philosophy for designing for mobile, the challenges, and a look at the road ahead. Luke explains that because of the limitations on mobile, developers are forced to really optimize the user experience for mobile. Often times this mobile experience turns out much better than on the desktop, where the “gluttony of resources” results in distracting and excessive webpages.

On designing a mobile webpage (Mobile web part 4)

Wednesday, May 26th, 2010

The frontend engineer lives at the intersection between design and engineering, and this is perhaps nowhere more true than in the world of mobile. In order to make a usable desktop website, an engineer must have at least some sense of design, and fortunately a lot of this has been standardized over the years. But the world of mobile is full of more unknowns, and the field is changing rapidly, especially lately from the shift away from older feature phones to the focus on smartphones. As such, the mobile engineer has to be on their toes in the sense of both design and engineering.

The focus of this article is on mobile design in general. I’m by no means an expert, but these are some things I’ve found to be essential and basic topics. Hopefully you will find this useful!

Only one column?

Mobile websites should only have one column of main content. This point is stressed again and again in mobile design, and for good reason: the paradigm of multi-column layouts is fairly well-entrenched in desktop design, but it’s simply not an option for a well-designed mobile site.

To illustrate this point, the following two images are both 320 pixels wide, which is a common smartphone width in portrait mode. The image on the left is the Yahoo! front page (yahoo.com) in its three-column fixed width desktop size, and the image on the right is Yahoo! mobile’s front page (m.yahoo.com):

This might not be a fair comparison, as the desktop version isn’t optimized for mobile, so you can’t even read the text without zooming in. However, even if the size of the text was increased, it’s apparent that three columns is just too much, both because of screen width concerns as well as concerns about too much content. There’s simply too much information being crammed down the user’s throat. Chances are the user only wants to check a few things and then put the phone back in their pocket, and this three-column version of the site is preventing them from doing that.

Modules, modules, modules

It’s helpful to think of a webpage as being composed of modules. If you’re converting a desktop website into a mobile site then you must essentially think of the website as bits of rearrangeable components:

What you’re doing is essentially grabbing your most important components and making sure they appear at the top, then stacking each module on top of each other. And don’t forget we do have variable screen widths on mobile (even on phones themselves, since they can be either in portrait or landscape mode), so we should be sure that each module is taking up 100% of the available screen space. In more technical terms, yes, this means we have to make a fluid layout.

Clarity and concision

It’s important to be both clear and concise in presentation. On the desktop we can get away with a certain amount of screen bloat, but users always appreciate simple sites when they come across them. This is a huge part of what made Google so successful: users came to the site for one thing, search, and the site was kept simple to facilitate that interaction.

As it turns out, it’s quite hard to be clear and concise. I like to compare this to writing papers for school. Often we were given assignments that needed to be a minimum of X amount of words or pages, and it was sometimes challenging to find information to meet this minimum. Fortunately (or unfortunately) many students developed a highly refined skill of BSing to fill the word limit. But were you ever given an assignment where there was a word/page MAXIMUM? This turns out to be much harder to write for, mostly because you can’t BS it. You have to identify the fluff, the nonessential bits, and surgically remove them from your paper. (As a side note, in the area of computer science, notice how many HUGE tomes there are out there compared to smaller books. I would venture to guess that engineers have a hard time being concise.)

This is just the problem we now face with mobile. We know how to fill up webpages with fluff: add an RSS feed here, add a module that ties into Facebook there, add another feed here, stick a relatively unimportant module there, add an excessive amount of social sharing buttons, and presto, we have a website that looks pretty active. But how does that translate to mobile? The questions you’re forced to ask yourself are: “do I really need this data feed displayed here?”, “do I need this huge Facebook module here taking up space?”. Or more positive questions like “what are the things users will come to my site to check, and how do I make it easier for them to find those things?”.

In the case of the last question, it’s easy to see from the above screenshots what Yahoo mobile thought was most important: Mail, Search, and News, all of which are visible at the top of the page. Think about your website’s main two or three features and try to make those just as visible.

Useful links

W3C Mobile Web Best Practices 1.0
Tips and Tricks for developing Mobile Widgets

In this series

Part 1: The viewport metatag
Part 2: The mobile developer’s toolkit
Part 3: Designing buttons that don’t suck

The viewport metatag (Mobile web part 1)

Thursday, May 6th, 2010

The skinny

Use this:

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"/>

Introduction

This series of posts is intended to introduce web developers to basic techniques for designing for the mobile web. It assumes at least a basic knowledge of creating desktop websites.

The problem

Ok, so you’ve settled down to learn how to write a website for a mobile device using your current knowledge of building desktop websites. So you start off with some pretty basic HTML:

<!doctype html>
<html>
<head>
    <title>Hello world!</title>
</head>

<body>

<p>Hello world!</p>

</body>
</html>

Ok! You can’t get much simpler than that. You check it out and it looks good on all the desktop browsers, since there’s really no opportunity yet for any cross-browser inconsistencies. And then you check it out on your mobile device:

Hello World on the iPhone

Doh! Where’d we go wrong? The text is obviously way too small to read without zooming in.

This is the first lesson in making mobile websites: width is your enemy. This is the first of many countless problems with device width you will encounter. Fair warning.

If you think about it logically, it seems to make sense: mobile Safari took a look at the page and assumed it was a document designed for the desktop, which is true of the vast majority of websites. So it gave the website a width of 980 pixels and presented it zoomed out. Which is why we can’t read anything until we zoom into the page.

Viewport

But this is no good! What we need to do is tell the browser that this webpage is optimized for mobile. And this is where the viewport metatag comes into the picture.

Now we tweak our Hello World just a bit…

<!doctype html>
<html>
<head>
    <title>Hello world!</title>

    <meta name="viewport" content="width=device-width"/>
</head>

<body>

<p>Hello world!</p>

</body>
</html>

And we get this…

Hello World with the Viewport tag

Much better! By setting the viewport width equal to “device-width”, we’re essentially telling it that the device width is 320px, not the default value of 980px that it guessed. If we set width=320 it would achieve the same result on the iPhone and a few other smartphones, but not all phones have this exact width, so it’s best to simply set device-width and let the mobile browser figure it out.

This viewport metatag is supported on many smartphones, from iPhone to Android to webOS (Palm) to even Internet Explorer Mobile, Opera Mini and Opera Mobile.

At the end of the day here’s what the standard viewport looks like, as grabbed from m.yahoo.com:

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"/>

More fun with the viewport tag

In addition to solving our biggest concern with the width of the content, the viewport tag has more options to play with:

Property Description
width Width of the viewport in pixels (or device-width). If width isn’t set, it defaults to a desktop size (980px on mobile Safari).
height Height of the viewport in pixels (or device-height). Generally you don’t need to worry about setting this property.
initial-scale (0 to 10.0) Multiplier that sets the scale of the page after its initial display. Safe bet: if you need to set it, set it to 1.0. Larger values = zoomed in, smaller values = zoomed out
minimum-scale (0 to 10.0) The minimum multiplier the user can “zoom out” to. Defaults to 0.25 on mobile Safari.
maximum-scale (0 to 10.0) The minimum multiplier the user can “zoom in” to. Defaults to 1.6 on mobile Safari.
user-scalable (yes/no) Whether to allow a user from scaling in/out (zooming in/out). Default to “yes” on mobile Safari.

Feature phones: when viewport isn’t available…

Unfortunately the viewport tag is relatively new and as such isn’t universally supported, especially if you’re working on older feature phones. But there are some older methods at your disposal for identifying your website as optimized for mobile:

<meta name="HandheldFriendly" content="true"/>

This tag was originally used to identify mobile content in AvantGo browsers, but has now been made the general standard for identifying mobile websites. However, it’s unknown what range of browsers support this meta tag.

Another tag at your disposal is a Windows-proprietary meta tag that also took root and eventually became used as another means of identifying mobile content. The drawback with this tag is that a specific width must be given, which doesn’t make it as flexible as the viewport tag (see above). Again, it’s unknown what the support for this tag is:

<meta name="MobileOptimized" content="320"/>

Lastly, your website will be identified as a mobile optimized site if your doctype is either XHTML-MP or WML. However, this is becoming less and less the case these days, as browsers begin to support good old HTML4.01 and HTML5+.

(info for this section comes from Beginning Smartphone Web Development)

Reference

Safari HTML Reference: Supported Meta Tags
Mobile META Tags