All posts tagged as "Mobile web"

Lots of “speed” tips are focused on content providers. Plenty of information available. Here’s a starting point.

In general, tips for speeding up a web site will help for at least some devices, but there are some extra niceties for mobile optimization.

Start with the giants: check out

• Yahoo: Best Practices for Speeding Up Your Website
• Google: Let’s make the web faster.
• Google: article focusing exclusively on mobile

Some specific tips:

• Each fetch request adds to latency, even more than most desktop users’ requests. Collect images into a single file.
• Design and develop as if all users were using satellite connections.
• Whenever you see a desktop maximum size recommendation, guess that you should multiply the number by 10%.
• Understand “make sure your size is no larger than 25k because that’s what the iPhone can support” type advice is not helpful for anything other than the iPhone. And 25k will take a while to download even on an iPhone.
• HTML 5, while not yet a standard, is becoming available for high-end mobile browsers. Local data cache can really speed things up.
• Design efficiently. Do you really need the JQuery library? It’s nice, but it’s big. Could you get away with a smaller framework?
• Use progressive enhancement. Design a great experience for less capable devices, and enhance it for more capable.
• Don’t get carried away with progressive enhancement: don’t send down code that a device doesn’t need.

Speed and effectiveness

Speed is not just about speed; we have to consider perception of speed. We talked about that quite a bit in part 1 of the series.

Good design is about more than just speed; sometimes slower speed can result in faster perceived speed and higher satisfaction. If a user is having fun or is easily achieving her goals, she will perceive the site (or application) as being faster.

And not all speed is the same. In general, interfaces that mimic physics, such as the buttons, sliders, and scrolling in most touch interfaces, must respond immediately. The illusion of physics must not be broken. But the parts of the experience that do not mimic physics, such as following a link, can have a delay.

So the design team must design well (there are lots of tips over at Design For Mobile), and must help the entire team decide when to break the speed optimization discussed above. For example, delivering larger image sizes than strictly necessary can enhance the experience. Using the occasional gradient can enhance the experience.

It’s a balancing act.

I was in a game on my Android. I kept seeing this kinda-teasing ad for a game; I thought it might be relevant to me as a casual puzzle game player.

Finally, after hours of play, I clicked on the ad. Many users do this, in higher rates than on the desktop-based web. The advertiser paid for me to click this link.

What should the link do?

• Take me to a landing page directly related to the ad
• Already know my region and device
• Be optimized at least for mobile
• Have a call to action on the page
• Give me access to other information in mobile-accessible format

What did it do instead?

• Site home page, not landing page
• With no information about what the game was, not even platform(s)
• Demanded that I go through a two-step process to enter my region
• Took me to the product information page, coded in Flash

For a while there, designers and developers could ignore screen and pixel size, at least for "high end" devices. Let's be honest here, "high end" meant iPhone-like: touch or multi-touch screens, high end Webkit browsers, and 320 x 480 pixels.

That time is now over. To our mind, it really wasn't here in the first place.

Why is the time now over?

1. Android has matured a bit, and manufacturers are putting it on everything. Consider this ARCHOS Internet Tablet (800 x 480 pixels, 4.8 inches), this Vega Picture Frame (1366 x 768 pixels, 15.6 inches), this 7 inch tablet, or the nook's 3.5 inch screen with what looks like a 5:2 aspect ratio
2. Even Palm's WebOS devices will not be consistent, with Pre's pixel dimensions matching the iPhone's, but Pixi's are at 320 x 400 pixels (80 pixels shorter).
3. Normal Android phones, such as the Motorola Droid at 480 x 854 pixels, no longer have a predictable size. Who knows what the next devices screens will be like?
4. The Motorola Droid's pixels, like the ARCHOS pixels, are much smaller than the iPhone's; bitmaps that work well on one may not on the other.

We wrote Photoshop layout is not your friend in March; this new array of high-end devices forces a choice: design for iPhone only, or start designing for multiple screen sizes.

If you're designing Android applications, you have some tools available to you. The Android Developers' Supporting Multiple Screens gives designers and developers a way to deliver the correct layouts and graphics to the correct devices.

For now, however, Android doesn't really support the full array of screens upon which Android is found. Here is what the document's Range of Screens Supported section says about device support:

The Droid is there, as a high-density, normal screen. The iPhone (were it an Android) and early Android phones are medium-density normal screens. The ARCHOS is a medium-density large screen. The nook and the Vega are ... not in the table at all.

Android's support of screen issues is incomplete, but many steps better than previous cross-device platforms like browsers and Java ME. Despite this, many developers have simply ignored the possibility of different screen types. My favorite example is the Fuzzy Clock widget, which is supposed to take up 25% of the screen with a single line of text. Apparently they used a single-sized bitmap font because on the Droid, the "glanceable" clock has the equivalent of about 8 point font. Not at all readable.

And frankly, I don't expect Apple to keep to the current screen dimensions. I don't have any inside information, but they will make a smaller screen or a bigger screen, or a higher-density screen, or probably all three. So even those of you focusing just on the iPhone may want to look at your process in the next few months.

The hardest type of applications to design for multiple screen types are games, as many create mazes, game boards, and levels for a specific aspect ratio. If your application uses scrolling or other pagination techniques, however, you can probably design it to comfortably manage a wide variety of screen sizes. (But all bets are off for supporting the Nook's screen, which will really want to scroll laterally, not vertically). How? Go read the resources linked above in this article. Or hire us.

If you haven’t, go check out part 1 of this series, in which I argue about the increasing role of feature phones in mobile web, and possibly apps.

I think a major shift in how we pay for mobile data is coming, within a year or two. And content companies need to figure out how to conserve bits. They aren’t free.

The role of data plans

Let’s take a look at unlimited data plans for a moment. Unlimited data plans are great! They provide enormous freedom! No worrying about how much data you use! Terrific!

And it is terrific. It’s great for people who can afford to spend $70 per month for each phone in their family. That’s not terrific for everybody. And it leaves people like my father, who want smart phones and that freedom but aren’t planning on watching video or tethering, paying for heavy users.

Variable pricing is inevitable

Unlimited data plans not only reduce access to a larger number of people, they also cause congestion problems. There is no cost to using the network, and there is cost to not using the network. It’s annoying on many devices to switch to wi-fi; it’s inconvenient to change your email or web habits.

As the operators increase available bandwidth, demands will go up. Video streaming, data cards, and tethering become more popular. People enter the world of mobile data from no experience to 3G cards, possibly with the intent to replace their home connection.

As the experience degrades (think AT&T access in places like New York and San Francisco), the operators’ brands take a major hit. Vehicle traffic planners have known this for years: roads fill to capacity. The existence of the larger roads change drivers’ behavior, even to purchasing houses further from town.

Some sort of change in pricing model is inevitable. Mark Lowenstein over at FierceWireless provides a few options. You can read a deeper discussion on the problem, and the solution, over at Slate.com.

And yes, Verizon already has a tiered data plan.

Global concern

I’ve just set out the argument for why the U.S. will not have universal unlimited data. That was the tough part of the argument; the economics for unlimited data are better here than in many places. In much of the world, pre-paid plans with pay-per-kilobyte are the norm. And this includes hundreds of millions of users (over 300 million in India alone) who do not have computer access to the Internet.

Increasing role of smart phones

As we discussed last time, feature phones are becoming more capable. Further, they have cheaper data connections than do smart phones, because on average they are used less. (There’s that tiered pricing again).

On top of this, smart phones are being pushed deeper and deeper into the feature phone market. Nokia has done this for years, and customers do not even realize they own a smart phone. Blackberries and Windows Mobile devices are being used as feature phones. Android phones “for the masses” are being deployed.

As smart phones get pushed deeper into the market, they will be selected by prepaid users more and more. Many of these users will still be paying per kilobyte.

Design implications

Right now, the bulk of the mobile web industry is moving to rich web interactions. But at what cost?

In a world of pay-per-kilobyte, is that 12kb JQTouch framework worth it? Sometimes, yes. But frequently, no.

In August 2009, the Admob Metrics report for the U.S. Admob ad impressions showed a little feature phone moving to third place after months at fourth place. Yes yes, the iPhone and iPod Touch are numbers 1 and 2. But that's not important here.

The Samsung R450. To be more precise, the Samsung SCH-R450 for Metro PCS. Not an Android device, not a Pre, not a Blackberry. A messaging-focused feature phone with a poor camera, released in 2008. And not AT&T, not Sprint, not Verizon. Instead, Metro PCS, who says "everything we do is unlimited." Smartphone users are getting unlimited voice, text, and data for $50/month. Feature phone users max out at $45. With no contract.

This price is within the range of "normobs," or normal mobile users, especially when considered as a replacement for a wireline home phone.

And guess what? They are using the mobile web. In great numbers.

Look around, kids are surfing on anything
with a connection and a browser.

Some folks are holding onto their Motorla RAZR. Yes, in 2009, the RAZR is still in the top 20 handsets hitting Admob-measured sites. Actually, it's number 6. Our UK readers may be aghast, but go look at your numbers. Three Nokia devices in the top 20? And none of an E-Series? And Apple taking over 50% of Admob traffic? (I keep mentioning Admob because they are measuring a non-random subset of mobile web data.)

And while you're at it, check out the increasing share of... Sony PlayStation Portable.

Design for more than smart phones

Okay, smart phones are great. iPhones are great. We like them. We use them. But they are not the only devices out there. Design for all the devices important to you. And by "important to you" I mean important to your customers.

"Wagging the dog"

Industry pundits have talked about how the iPhone is the tail wagging the mobile industry dog. That may be true, but let's look at user behavior instead.

I've spent time in the past few months helping my parents and a similarly-aged friend decide what device to get next. They are all very interested in smart phones, especially once I showed them applications. After all, applications let them do what they want to do, not what the mobile phone manufacturer thinks 80% of people want to do. And their needs aren't outrageous, either.

So we have increased interest in mobile web and mobile applications from folks who do not want the latest gadget. And they don't necessarily know that they need a specific brand or operating system to do it. If a device delivers a good web experience, and perhaps some downloaded apps, that may be all they need. Yup, I'm talking web and Java here, folks.

Feature phones can do it

Why won't they get smart phones?

Because they have to pay more per month, every month. $20 extra each month for Verizon, as of two minutes ago. That's $480 extra plus tax over the course of the contract, and the phone most likely costs more, too.

So my father would have to pay more for the smart phone, then pay more for the data for the smart phone. He's a smart man and is budget conscious. Why would he do this? He'll avoid it if he can. He doesn't need or want to download music or videos. Why pay extra for this?

And feature phones will serve most of his needs, especially once he discovers GetJar.

I believe that feature phones are going to be far more important in mobile data in the next few years, driven by these varying price points the operators are maintaining combined with the capabilities perceived to be part of smart phones only.

And guess what? If customers make this choice now, many feature phones have better browsers than Blackberry and Windows Mobile. So which is the better choice? As better BB and IE browsers deploy, this will be less true. But stay tuned.

We've designed a couple of mobile browsers, which makes us always curious when a new design comes along. (I'd tell you which ones, but alas they've not given us permission). Especially fun is looking at what the browsers do on some of the challenging implementation decisions we wrestled with.

So, Opera Mini 5 has increasing amounts of competition from the likes of Obigo, Bolt, Skyfire, and so forth. Rather than sitting on their well-deserved laurels they took the design to the next level.

I won't really talk about features here; that's well covered elsewhere by folks you trust to talk about such things. Instead, design.

Control overlay is very nice

The most obvious change in design is of course the treatment of the Menu button. Previously, the design was inherited from Nokia UI of over 10 years ago, with a list of available actions in a menu above the left softkey. This time they took an approach similar to Gravity, with overlays showing available controls.

The advantage of this approach is both aesthetic (it's much prettier) and functional. Most softkey menus have just order and label to suggest their functionality; they become unwieldy as application capability increases. Opera Mini 5 uses the same familiar activation of the menu, but then provides a number of controls simply not available in a menu:

• Visual control distinction: Large icons for frequent actions
• Controls beyond just links/buttons: Integrated URL and search bars
• Controls beyond just links/buttons: Access to other tabs
• Progressive disclosure without submenus: Access to less important controls by a second action

And they didn't go overboard. They could have made a two-dimensional grid of controls, adding extra confusion. The control overlay could have been very intimidating, but it's not.

Overlay problems

By putting a "power" button (odd choice, that) in one of the five limited spots in the overlay, the more-used History and/or Bookmarks. By relegating the exit function to the menu, you reduce the need for the exit guard, allow use of the word "Exit," and provide space for other controls.

The forward and back buttons are poor choices for the overlay. The right softkey is also back, so this replicates the function. And the "forward" button remains disabled most of the time, as it is on most browsers. So three of the five controls in the icon bar of the overlay shouldn't be there. No wonder I spend so much time in the little menu.

Perhaps history and bookmarks were relegated to the menu because the quick-dial feature imported from the desktop browser needed prominence. This isn't a great design choice, especially for people who don't save bookmarks but instead use history.

Other visual choices

Page wipe-to-left for "forward" (and its reverse) is interesting, but mistimed and inconsistently applied. You'll have to try a few pages before you can be sure to have seen it, but when you do you'll find that the current page doesn't wipe off the screen until the new one is loaded. This solves the problem of wanting something to look at while the new page loads, but then has the problem of a perceived disconnect between action and result. I'd drop the wiping feature.

Wiping is also inconsistent with the display of the chrome controls. Here, things fly in from the bottom, but then is left and right once in the controls. Disconcerting.

Tabbed browsing, finally

Hooray for tabbed browsing! I can have two tasks going at once. And, unlike the iPhone, it doesn't force a refresh just to look at the other tab. This is terrific, and much easier than the native S60 non-touch browser.

Interface "cruft"

We've been hearing a lot from the design elite about the goal of "the content is the interface." Proponents point to Jef Han's work on multi-touch displays, full-screen browsers, and the like.

To a degree, Opera Mini delivers here. It sports a full-screen mode that lets you really maximize your view. And by putting all of the controls in the overlay, the same keypress that gets you access to the overlay in default mode also gets you access in full-screen mode. Very nice. In contrast, the native browser uses the first keypress to display the title and menu bar; the second keypress actually opens the menu.

I guess we're crufty people around here, but we like using tools when interacting with content. And in Opera Mini 5, the cruft is the weak spot.

Helpless Help

Help has no contents other than keyboard shortcuts and the "about" information. Maybe this is because it's a beta product. But if so, it's (almost) always best to leave a feature out than to implement it half-way. And yes, that counts for not-enough-content.

"Saved Pages" vs. "Bookmarks

Because there is no help, I don't know what they are thinking with regards to "Saved Pages." This appears to be a mechanism in which the web page is stored somewhere on the device, perhaps accessible offline? Certainly I had to approve the application getting device access (no explanation of what access) about six times to use the service.

Indeed, there are three separate ways to explicitly save a site: quick dial, saved pages, and bookmarks. Let's get rid of one of those, and better integrate the other two. Maybe they are, but at least the access methods and names imply they are not.

History

Given the fact that many people use history very extensively, we'd like to see it vastly improved on all browsers. The good: Opera Mini has a clear visual distinction between sites visited "Today" and "Earlier." The bad: when, earlier? And how do I pick between these?

Perhaps it isn't fair to pick on Opera here. Even desktop browsers do this at best indifferently. We'd like to see several changes to the history function. These start with, but are not limited to:

• Define browsing "sessions" within time. "Yesterday around 8am" is contextually different than "Yesterday at lunchtime," and makes it easier to search the way people think.
• Consolidate links for pages that are just refreshing themselves (cough - gmail).
• Go beyond the page title, perhaps grabbing the first h1 in the document.
• Include favicons in the display.
• History search, ideally searching the whole page and not just the title.

Blackberry challenges

I don't have any screen shots for you, but Jana downloaded the Blackberry version. And deleted it, as she couldn't figure out how to use it. She said the controls didn't work.

I still don't like the rendering

Opera hasn't changed some of their core rendering decisions. This is unsurprising, but disappointing. Stuff that is unchanged:

• Ignore the page keyboard shortcuts (access keys) in favor of the browser's.
• Reports itself as a desktop browser, causing sites to render the desktop version even when they have a mobile one they'd presumably rather offer you.
• Insufficient control over screen width. I can't use the desktop version of Google calendar even though I am forced there.

And, rendering bugs

I tried for 15 minutes to sign into ToodleDo before giving up and using the native browser. The page was telling me it was the wrong credentials, but I typed the correct ones. Opera somehow inserted, deleted, or changed characters when sending the content up. I don't know why, but it's enough to make me use the built-in browser instead.

There are several sites or on-screen widgets of one sort or another that tend to cause issues in one browser or another, and seem to not be getting better. To view the whole web, I have to use 2-3 browsers to get everything working. These are usually pretty detailed, niggly things causing failures, such that if I could view a style-less version I could make the site work. Whether that is the right answer, all browsers (not just Opera) that proclaim desktop compliance need to look at how they are being used, and think outside the box regarding workarounds, at the least.

As far as all the not-as-mobile-as-we-wish comments, maybe it's time to start another one-web rant and talk about what the mobile internet should really be offering. Maybe, if we can rope in the right people, that's a good panel for the next Design for Mobile conference.