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.

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars

Copyright ©2009 Little Springs Design, Inc.

My father is a geek like me, though has been budget-conscious for my whole life. A few months ago, he started asking me a wide variety of questions of different types of devices he could use to fill his various needs, including bicycling and genealogical research in an area with highly spotty coverage. Numerous email exchanges later, we both decided on getting a Motorola Droid. He sent over this commentary on how it works for bicycling, partially to help another person in his device decision. I find the analysis fascinating. I hope you do, too.

I’ve experimented with using the various GPS Receiver functions of my new Motorola Droid toy. In short the Droid functions about as well as my Garmin eTrex in determining location but the Droid has limited navigation functionality when it is outside 3G coverage. Additionally the battery drain rate is high.

It appears that the Droid uses GPS satellites to determine its location for navigation type functions although it uses cell tower and WiFi data in conjunction with some apps.

Satellite acquisition and initial location determination

When I first turn on my Garmin it takes a couple of minutes to acquire satellites and calculate the current location. The unit “knows” where it was when it was turned off and has a catalog of satellites that it should see but it takes time to acquire those satellites and gather enough information to calculate location.

At home when I turn on Google Maps on the Droid it first shows a location based on cell tower data (I’m away from any known WiFi hotspots). It then quickly (less than 30 sec) zeros in on my house location. The impression is that the Maps App is much quicker in getting to the initial location than the eTrex. Ed. note: This is most likely due to the cell tower assistance.

I turned on the satellite view mode on Google Maps which shows aerial photography of my area. The blue dot showing my calculated location indicated that I was in the guest/sewing room rather than at my computer in the living room.

Tracking a bicycle ride

One of the apps tracks your movements. I assume that this uses GPS data and is not dependent on being connected to the network. I used this on a short ride that I believe includes areas that are out of coverage. I had the Droid in a handlebar bag and the Garmin mounted on the handlebar. On a 20 mile ride both units calculated the same moving time, distance and differed slightly on the altitude and total climb calculations.

I put the calculated tracks into Google Earth so that I could compare them side by side. Both tracks had errors. When compared to the rectified aerial photo I was all over the road and off the road for much of my ride. The Garmin seems to do a little better but that might be because it is set in a mode to attempt to follow the road. The errors were worse when I was in the trees. During one part of the ride the Droid seemed to have a consistent bias to the north of the road.

If I really cared about the accuracy I’d do some more tests with the Garmin set to ignore map information.

Navigating

I turned the navigation mode on for a 70 mile car trip home yesterday. The trip included a significant amount of time out of 3G coverage. I didn’t observe the navigation continuously but checked a couple of times when we were out of coverage. The screen was white, showed no map data, and showed that the app was doing a rerouting.

So as I expected you can only navigate when you are in range of the towers.

When it is navigating the default is to have the screen backlight on continuously. The Droid actually feels warm after awhile.

Also yesterday I unplugged the Droid around 6:30 AM. We did a round trip through low and no signal areas, I made a couple of phone calls, I also connected to a WiFi network and viewed various web sites, for about 2 1/2 hours I had the navigation mode in use. The GPS and WiFi receivers were on for the whole day. When I got home around 6:30 PM the phone was begging for a recharge.

Conclusion

No surprises. With the current apps the Droid will not replace my stand-alone GPSR. If they offer a capability to store map data and calculate routes on the device then maybe it could replace it. Since my intended uses include camping based bicycling trips I have recharging issues that would limit how I would use the Droid. For a trip that doesn’t include back country and has regular access to a USB power source it would probably be OK.

I am going to explore various off the grid recharging options such as solar cells and a new generator that runs off of body motion.

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars


Copyright ©2009 Little Springs Design, Inc.

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.

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars


Copyright ©2009 Little Springs Design, Inc.

While this seems simple, it really isn't. Consider my ongoing experience on my Nokia E71, on the AT&T network, in a non-impacted 3G area, using the highly optimized Google Reader (and I'm using the "mobile" version not the "iPhone" version, though the device supports both). I also use the same site in Opera Mini.

Typically it takes two tries before the native browser can find the page, and if I reload the page that is there Google errors out. Opera Mini is faster, but I have to tell it which network to use two or more times before I can load the page.

I just outlined problems with the browser, the network, the site, and the operating system/device. Each contributes to my slow experience. And most sophisticated users won't be able to distinguish these, let alone typical users.

Perception vs. reality

Before we get too focused on speed, consider some fascinating research by User Interface Engineering titled The Truth About Download Time. Don't get wound up in the age of the research; the conclusions are still true.

There are two paragraphs you really need to read:

... we found that there was no correlation between ... [actual download speeds] and the perceived speeds reported by our users. About.com, rated slowest by our users, was actually the fastest site (average: 8 seconds). Amazon.com, rated as one of the fastest sites by users, was really the slowest (average: 36 seconds).

There was still another surprising finding from our study: a strong correlation between perceived download time and whether users successfully completed their tasks on a site. There was, however, no correlation between actual download time and task success, causing us to discard our original hypothesis. It seems that, when people accomplish what they set out to do on a site, they perceive that site to be fast.

So. Perceived speed is not the same as actual speed.

This is undoubtedly the case for the Gomez study. How many users actually count seconds? Very few. So don't be overly concerned about times in the study. But do be concerned about how fast that people think the web is, as well as failure to accomplish goals.

What to do?

Let's avoid the finger pointing here. Everybody, at every step of the mobile web value chain, can increase the speed of the mobile web. Over the next four parts in this series, we'll look at what each of the different types of organizations can do. We'll make these links as each of these is published.

• Content providers
• Operators/carriers
• Manufacturers and operating system makers
• Browser makers

In the meantime, contribute your thoughts to the (currently very brief) Design for Mobile page on Mobile Web Speed.

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars

Copyright ©2009 Little Springs Design, Inc.

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.

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars

Copyright ©2009 Little Springs Design, Inc.

The "page fold" comes from newspapers. "Above the fold" is what is visible on the newsstand, and what grabs you to make you buy it. The same concept carried through to early web design, and worked okay I guess when everyone's screen was the same size.

Those days are gone, and with different browsers, zooming, scaling, and all the variations multiplied again for new platforms like mobile it's an interesting field to look at. The link above talks a lot about how users perceive pages to understand scrolling. That /is/ interesting design to work on and stuff everyone has to keep in mind.

I think I know this topic pretty well, but just talking around the office, others brought up topics I knew perfectly well, but had forgotten to include. So far, we have these topics to help design for successful scrolling:

• Vertical Scroll
• Scrollbars
• Meet Platform Expectations
• Avoid False Bottoms
• False Tops, and Other Scrolling Up Issues
• Chrome Variations
• Encourage Scrolling With Content
• Force Scrolling

And maybe you know more about some particular trouble. If so, especially for mobile, don't comment here in the blog. We set up a longer version of all this up on the Design for Mobile wiki. Please go to the Myth of the Page Fold page, set up an account, and add your content. Or expand on my notes.

Even if you just have an opinion, thought, question or concern, this wiki is a great place to bring it up. Add it to the topic or (if not final yet) talk page.

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars

Copyright ©2009 Little Springs Design, Inc.

Over on the very nice UX Exchange, user mattti asked the question, Touch gesture usability in mobile devices – which ones work?.

As we’ve been doing a bit of work in gestures this year, I tossed off this response.

Touch gestures are only one type of gestures for mobile. Technologies such as accelerometers, light sensors, other cameras, pressure sensors, RFID, NFC, Bluetooth, and various location technologies are all possible.

Then there are the “display” mechanisms: vibration, rumble, electrical fields, force feedback, sound, and so forth.

In general, this space is in its infancy.

Phones should always be designed with one-hand use and two-hand use in mind, but it is up to the product team to decide the relative emphasis. Clearly making and receiving calls should be one-handed. Should web? I don’t think that’s as necessary. But usability can be achieved either way.

When designing gestures, you must keep in mind that they lack any innate visual affordance. You must rely on other methods to enable discoverability. There are a few approaches to this. The iPhone’s “flick” (scroll fast) gesture is a very simple extension to an existing behavior; it uses something people already do and just responds more naturally to it.

A second approach is training. The Palm Pre requires users to go through a training video to get the “back” gesture, as you really can’t use the device without it. There is no corresponding button.

Apple has used advertising to teach people about pinch to zoom. It’s less effective: many users complain that they just can’t read the browser text. They’ve not discovered how to zoom in.

Like I said, this space is very much in its infancy. But principles we’ve observed include:

1. Carefully train any gestures critical to the use of the device. Swipe left for back, pinch/spread to zoom out/in, double-tap to zoom to fit.


2. Avoid making many gestures critical to the use of the device. Provide menu or icon alternatives for most gestures. Gestures (and voice control) provide shortcuts, not navigation through menus.


3. Use natural finger or thumb paths rather than requiring strict rectilinear paths. In other words, use good biomechanics and be forgiving of error. Example: The iPhone unlock screen requires too much precision in start and end points to unlock. It is too easy to stop at the wrong place.


4. Test your gestures with real users. Redesign, test again.


5. Consider a device mode in which everything is done through the menu. This is the “share with somebody else” mode. Verbally communicating gestures while driving is frustrating for everybody.


6. Be smart about automatically doing things. Sometimes, for example, a person might want to lay down while reading a web page. Indeed, “in bed” is a common context for use. The iPhone makes this challenging, as it automatically rotates sideways. Some applications have a “lock” mode in which they won’t rotate.


7. Where possible, re-use gestures. Pinch to zoom should be preserved. Flick to scroll should be preserved.


8. Think outside the box. Or off the screen. I want a function that intelligently locks and unlocks my screen based on device position and light input (i.e., it’s upside down in a pocket or purse then the keys are locked; I pull it out and they are unlocked). This is far more important than an extra on-screen gesture.

Also, be sure to read some of Kevin Arthur’s work. I keep coming back to Evaluating Gesture Usability – it includes a method to actually develop and test good gestures.

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars


Copyright ©2009 Little Springs Design, Inc.

Mobile websites should be designed to be small, simple and distilled down to their most crucial aspects.
—Mobile Web Pages Need to Be Simple, Web Design SEO

When it comes to mobile websites, simplicity is key.
— Mobile Web Design Trends, Smashing Magazine

Less will always be better- that is the primary rule of converting your website to mobile.
— What Should My Mobile Site Do, MoFuse Premium

While we advocate simplicity in design, we're not really sure this is especially true for mobile. First, there may be functionality in the mobile possibly not in the desktop version of the site. But let's ignore that. Is simple always the best answer? Should we always reduce functionality to the "core"?

What is Simplicity, Anyhow?

And are we even talking about the same thing? The quotes above essentially suggest simplicity and complexity are opposite ends of a continuum, with everything true and good in the world to the left, like so:

This over-simplifies the simplicity discussion. Or, simplicity is more complex then this.

What does "simple" or "complex" mean? In one of our Friday design discussions, we realized the argument is mistaken in one of the commonly encountered senses, where "complex" frequently means cluttered. We've all heard this from reviewers and clients. We drew this on the whiteboard to frame our discussion:

The two axes are mostly independent of each other. A highly complex functional product can have a "clean" interface (consider www.google.com), or it can look cluttered (think Facebook and Myspace). A product with few features can look cluttered, the way Craigslist does, or can be clean like many online stopwatches.

The simple/complex axis largely relates to functionality or amount of content. The clean/cluttered axis is more a measure of the visual, information, interaction, and content design.

Another benefit of the chart above is that it's a 2 x 2 grid! All MBAs like 2 x 2 grids. Not only do many of our clients have MBAs, but so do I. So this is a good thing. Here we map some services into our grid:

Visually Clean

Most interesting digital systems are indeed functionally or organizationally complex. But they needn't look cluttered.

The essence of being "visually clean" is that the possibly complex system doesn't look complex. One great way to accomplish this is to display only the information relevant right now.

Is Simplicity Universally Desired?

The aversion to "cluttered" likely has a cultural component. Consider this set of Japanese mobile portals selected for their good design; they have a lot going on. Many modern cityscapes are similarly cluttered.

Not only does the aversion to cluttered have a cultural component, it also have a contextual component. Sticking with the Japanese, check out Presentation Zen's 7 Japanese aesthetic principles to change your thinking. So this culture desires both cluttered and clean, in different contexts.

Complex Cluttered Arrangements of Simple Clean Objects

Or, portals, dashboards, and cockpits.

We humans have a repeated behavior of collecting simple things and arranging them for aesthetic or functional purposes. iGoogle, NetVibes, and Pageflakes are all examples. Web portals tend to do the same. If you want a bit of fun, get Steven talking about portal theory.

These systems, as a whole, are complex and cluttered. But each element is simple.

Is Functionally Complex and Visually Cluttered Bad?

For consumer systems, probably yes. Choices are overwhelming, users don't understand the complexity model, features get lost. The ability to handle functionally complex is typically through visually simple interactions in which content is well organized in time and space.

But consider an airplane cockpit. Lots of information is immediately visible, even in glass cockpits with their modal display of information. These are complex systems, both functionally and visually. They require a lot of training to learn to use. There is still a lot of design here.

The key to making these systems easy to use is to work on matching displays to mental models, and training users on the proper mental models.

Back on the consumer side, or even enterprise employee mobile phone user side, you can add complexity over time. If a new Facebook user were to see a heavy Facebook user's page, she would be lost. Actually, I'm lost; I only use Facebook sporadically. The site is manageable because users learn small parts of the service before being bombarded with memes, applications, and friends.

The Challenge of Functionally Simple

It was difficult to pick out good "simple" and "clean" examples within the web domain. We discussed a currency calculator and an online stopwatch.

This comes as no surprise. Most apps and sites are built by an organization. Organizations have as their very nature a key unstated goal: to continue existing. To do this, they have to keep growing. To do this, they have to add value. Most apps and sites run by organizations will grow, and become less simple.

As your site grows, that original clean interface may simply stop working. It's not any one person's fault, but it often happens when organizations grow, and as individual needs are met without stopping to reconsider the whole product. Beware.

Several good design and product management practices can help avoid creeping featuritus. The use of personas, themes for each product release, and more can all help. The selection of which tool depends on your organization. (we can help)

How Much Simplicity?

Everything should be made as simple as possible, but not simpler.
—Albert Einstein

Einstein is right: don't overdo the simplicity. And let's make things complex enough to meet users' needs.

The features required for any particular context, be it device, user, time of day, location, situation, etc. vary a lot. There's no way to tell, and one context's simple is another's too complex. Worse yet, is being too simple.

There is a good cutoff, at the arbitrary (and unscaled) point shown above, where any design should probably have a certain degree of "clean-ness" -- avoiding the clutter of your typical overdone web portal.

The functional complexity might not need to move, especially with an increasing number of people using the mobile as their primary access to the web. Do you want to reduce functionality for a class of user? If so, be sure that they would agree.

How Simple is Too Simple?

If your target users can not accomplish key goals, your service is too simple.

What Does This Have to Do with Mobile?

Nothing and everything.

Nothing: These ideas behind simplicity apply to most design exercises; they certainly aren't limited to mobile. Indeed, there is a growing sentiment around the web to design for mobile first, then design for other platforms in a progressive enhancement approach. Even David Wood's recent Symbian blog entry on simplicity is more about software development in general than anything mobile specific.

Simplicity (cleanness) is a design ethic of our times, not just for mobile.

Everything: Mobiles are pretty complex already, especially including the wide variety of contexts they will be used in. And many operating systems expose much of that complexity to the end user.

Considering solely the use on the phone and making that as simple as possible, particularly functionally simple, can increase complexity for the user. In an effort to achieve mobile simplicity, Gmail mid-to-low capability mobile sites and Java applications do not provide labeling functionality. If you use labels to organize your many gigabytes of email, you'll have to do it on the desktop.

In contrast consider the Twitter application for the S60 platform, Gravity. If you've not seen it, please do go read the All About Symbian Gravity review and also see this set of Gravity screen shots. The user interface is visually clean, with a functionally complex set of controls appearing as needed. It keeps the complexity in context, making it not seem complex.

Impact of Multitasking

This brings up a good point. Are simple applications or web sites really great for general computing devices that do not have good multitasking? That (of course) depends. If you need to use the simple app in some continuous, largely uninterrupted, and finite manner, such as a stopwatch, weak or no multitasking is fine. But if you need to dip into the application several times over the course of the day, such as a task timer used for billing, then the repeated time costs of loading the application will become unacceptable.

Clean on the Small Screen?

Yes, you can get functionally rich services with simple design on the small screen. You can keep the white space, though you should design with the frame of the device in mind.

What you shouldn't do is take out too much. Most of the time, you should only remove what is truly irrelevant when mobile. Just like you should remove desktop-irrelevant stuff from the desktop interface.

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars

Copyright ©2009 Little Springs Design, Inc.

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.

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars

Copyright ©2009 Little Springs Design, Inc.

A group makes a mobile site or app. When making the desktop site to promote the mobile service, they say something like:

Use your phone and visit: m.google.com/reader

That's a direct quote from the Google site promoting their mobile services. I copied the source code, not just the text.

Usually this emphasized text is also underlined. This is true on the actual Google page with their CSS applied. It looks like a link. That's fine, right? It's a link?

That's the problem. It's not a link.

I thought, "I want to find the mobile version of my favorite service. I will search for that link from the search tool on my mobile." The Google search results were terrific, leading me right to the page where I would find the information I needed. But the link didn't work!

I had to look at the URL, remember it, and then type it in. Bad plan. Most smart phones' browsers will render desktop web pages. And search results will typically return desktop web pages.

Opera also did this last week when they launched Opera Mini 5 beta. I mentioned it on Twitter; they have fixed the problem. Kudos to Opera for monitoring social media. But shame on Opera for not thinking that some people might visit their desktop site from a mobile phone, and make it a link in the first place.

Your simple takeaway: when telling customers how to find your mobile content via a URL, make the URL also a link.

This includes you, Google.

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars

Copyright ©2009 Little Springs Design, Inc.