Posts Tagged ‘mobile’

Does it still make sense to use em rather than px?

Tuesday, October 5th, 2010

Alex Kessinger tweeted asking if there was a reason to still use EMs instead of PX measurements in mobile. This is an interesting question, but 140 characters isn’t quite enough to explain my thoughts. So here’s an old-fashioned blog post!

Just a quick review: em and percentage (%) units in CSS are relative measurements, whereas px and other measurements are not. What this means is that the resulting size of relative measurements depends on the size of the parent.

The original reason to use EMs instead of PX measurements

As far as I can tell, the original reason why it became a good practice to use EMs was because of page scaling and accessibility reasons. When developers used PX measurements, they found that when the page was scaled (using Ctrl + Scroll Wheel), the parts of the page with fixed PX measurements didn’t scale.

Oh no! So when a user with poor eyesight tried to scale a page to read the text better, it turns out that the text they were interesting in making bigger actually didn’t change size at all!

So is this still the case today? By and large, no. All modern browsers except IE6 will now scale pages correctly, regardless of the type of CSS units used.

From what I’ve heard, there are still many users with disabilities using IE6, but the reason is because they don’t want to upgrade their copy of the screen reader JAWS, which is quite expensive. However, these users obviously aren’t affected by page scaling issues because they are blind.

Maintainability concerns

Even if the original reason to use EMs (above) is no longer valid, I still believe there are good reasons to use them.

One of the main reasons is maintainability. If a page is designed to have one base font size (applied to the Body) and all other font sizes on the page use relative units (EMs or percentages), changing the font sizes later becomes almost trivial. If someone wants to later increase the size of the fonts on their entire page, all they need to do is increase the one base font size.

This might be a bit of an edge case, but the elegance of the solution is too enticing! :)

Media queries and mobile

Very closely related to the above point is the subject of media queries. Recently media queries have been somewhat hailed as a panacea for all mobile development. I slightly disagree, but that’s a topic for another post!

The main point here is that people are now using media queries to quickly make mobile-friendly versions of their desktop websites. That’s awesome, there’s no doubt about that.

So what about EMs and PX measurements? Here’s the problem: if a developer coded their webpage in such a way that they used fixed pixel measurements, the amount of CSS required in the mobile media query could be obscenely large. This is because each individual element with pixel measurement was designed with the desktop in mind! This makes the task of adapting to different content very painful.

On the other hand, think about a page designed with relative units such as EMs or percentages. This page was designed so that each element was proportional to its parent element, so that ideally changing the size of the entire page occurs in only a few places, at the Body level of the document. Suddenly the CSS required for the mobile media query is much more manageable, since it’s now (ideally) only changing a few values on the Body element, not on every element on the page.

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

(updated June 27, 2011)

Mobile-specific HTML

Viewport tag

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

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

Tel scheme (to initiate phone calls)

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

Sms scheme (to initiate text messages)

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

Disable automatic telephone number linking

<meta name="format-detection" content="telephone=no">

iOS-specific HTML (some work on Android as well)

You also have access to several Apple-specific tags to use in your iOS applications (iPhone, iPad, and don’t forget the iPod Touch!).



<link rel="apple-touch-icon" href="icon.png"/>


<link rel="apple-touch-icon-precomposed" href="icon.png"/>


<link rel="apple-touch-icon" sizes="72x72" href="touch-icon-ipad.png" />
<link rel="apple-touch-icon" sizes="114x114" href="touch-icon-iphone4.png" />


<link rel="apple-touch-startup-image" href="startup.png">


<meta name="apple-mobile-web-app-capable" content="yes" />


<meta name="apple-mobile-web-app-status-bar-style" content="black" />

Turn off autocorrect, autocomplete, and autocapitalize

And also some handy attributes to turn off annoying autocorrect features:

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

Mobile-specific CSS

position:fixed and overflow:scroll

Mobile browsers are now starting to support these basic CSS properties better. Position:fixed will work on Android 2.2+ and iOS 5+. Overflow:scroll works with one finger on iOS 5+.

Also, iOS 5 has additional CSS to give the native scrollbar and momentum/intertia to elements with overflow:scroll: -webkit-overflow-scrolling: touch;

Media queries

Media queries enable you to target specific features (screen width, orientation, resolution) within CSS itself. Media queries themselves are actually quite old and are not mobile specific (they used to be popular for making a print-friendly version of webpages).

You can use them two ways: 1) inline in a CSS stylesheet or 2) as the “media” attribute in the link tag, which loads 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):

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

This is not recommended because it creates an additional HTTP request (bad for performance). Also, in the case of screen orientation, the separate CSS stylesheet is NOT downloaded when the screen is rotated.

Here’s a few examples of using inline CSS:

// target small screens (mobile devices or small desktop windows)
@media only screen and (max-width: 480px) {
  /* CSS goes here */
}

/* high resolution screens */
@media (-webkit-min-device-pixel-ratio: 2),
             (min--moz-device-pixel-ratio: 2),
             (min-resolution: 300dpi) {
  header { background-image: url(header-highres.png); }
}

/* low resolution screens */
@media (-webkit-max-device-pixel-ratio: 1.5),
             (max--moz-device-pixel-ratio: 1.5),
             (max-resolution: 299dpi) {
  header { background-image: url(header-lowres.png); }
}

Read more: Media queries (Mozilla Developer Center)

Miscellaneous CSS

-webkit-tap-highlight-color (iOS): override the semitransparent color overlay when a user clicks a link or clickable element. To completely disable it, set the value to ‘transparent’ or ‘rgba(0,0,0,0)’

-webkit-user-select: none; – prevent the user from selecting text (also works on desktop WebKit)

-webkit-touch-callout: none; – prevent the callout toolbar from appearing when a user touches and holds an element such as an anchor tag.

Mobile-specific JavaScript

window.scrollTo(0,0);

This hides the address bar and takes advantage of the entire device screen. You’ll have to set this in a timeout and make sure to get the timing right. See Remy Sharp’s post for more details.

window.matchMedia()

(iOS 5+) Again, just as CSS media queries aren’t specific to mobile, they do come in especially useful for mobile, so it’s worth mentioning their JavaScript counterpart. window.matchMedia() is a JavaScript-based version of media queries. You can use respond.js as a polyfill for devices that don’t support this functionality natively.

navigator.connection

(Android 2.2+) Determine if the phone is running on WiFi, 3G, etc. Example:

if (navigator.connection.type==navigator.connection.WIFI) {
  // code for WiFi connections (high-bandwidth)
}

window.devicePixelRatio

Determine screen resolution (analogue to the CSS media query). (iPhone 4 has the value 2, while Nexus One has the value 1.5).

window.navigator.onLine

Not strictly mobile, but helpful for apps to determine if they’re being run offline.

window.navigator.standalone

(iOS 2.1+): determine if it’s running in full-screen mode

Touch and gesture events

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)

Screen orientation (every 90 degrees)

orientationchange event: triggered every 90 degrees of rotation (portrait and landscape modes). The current orientation is available through window.orientation

Device orientation (more fine-grained)

The deviceorientation event will fire very frequently, and gives more fine-grained information about the device’s orientation in three dimensions.
MozOrientation (or onmozorientation?) (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 running Mobile Firefox. On the desktop this works with laptops such as Thinkpads and MacBooks.

devicemotion (shake gestures, etc.)

devicemotion fires when the user shakes or moves their device. Devicemotion taps into the accelerometer, which is fires off when the device accelerates. Contrast this with the deviceorientation event, which taps into the device’s gyroscope (if it has one), which only measures the 3D angle orientation, even when the device is at rest.

Media capture API

While iOS is still lacking basic file inputs, Android is forging ahead, giving developers fine-grained control over content users can upload.

<!-- regular file upload (Android 2.2+, NO iOS) -->
<input type="file"></input>

<!-- opens directly to the camera (Android 3.0+) -->
<input type="file" accept="image/*;capture=camera"></input>

<!-- opens directly to the camera in video mode (Android 3.0+) -->
<input type="file" accept="video/*;capture=camcorder"></input>

<!-- opens directly to the audio recorder (Android 3.0+) -->
<input type="file" accept="audio/*;capture=microphone"></input>

BlackBerry specific

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

I’ve created a separate entry for the available mobile libraries and frameworks.

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).

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.

Slides

More from the Mobile Web series:

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
Part 5: Using mobile-specific HTML, CSS, and JavaScript
Part 6: Dealing with device orientation
Part 7: Mobile JavaScript libraries and frameworks

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.