All posts tagged as "Mobile applications"

With all the latest announcements for e-readers and book pricing, I’ve been thinking a lot about the nature of reading recently. It seems like each company’s reading experience presumes everybody and every bit of content is the same experience.

Amazon is quite proud of their $9.99 pricing for e-books. They claim that it is cheaper than paper. And it is … for one type of reading. If you read mass market hardbacks or trade paperbacks (the ones that are the same size as the hardbacks) then $9.99 is cheaper than $15.99 or $25.99.

I do that type of reading, but only for professional-related books. These books I might want to learn from, cross-reference, make notes for adoption at the office, and so forth. I will read while traveling, but not relaxing in the tub. I don’t really share these books with my friends, though I share some of the ideas with my colleagues.

In contrast, my personal reading time is spent almost exclusively with cheap paperbacks. They’ve increased in price to $7.99, which I think is too much, but I pay it anyhow. I actively share these with people I live with, and share with friends. These are the books I take into the tub, and are more likely to come to bed with me. I keep them for a long time, but if they get lost on a trip or wet in the tub, it’s okay.

Several of these books currently live on the shelves of the people I lent them to, and while I’d like to have them back it’s completely livable. You can tell which series I really enjoy, because I no longer have the first book in the series. It’s been loaned elsewhere.

Then there are newspapers and magazines. This content is temporary by its nature, and at least for me is more akin to skimming online news and blogs.

These are not the only types of reading out there. One of the key lessons in graduate school was how to read research papers. Reading for learning or book clubs might also look very different. Reading business documents, at least in my product development world, really needs a large screen and a strong social connection. The documents do not live in a vacuum, and their business context must be considered while reviewing the product requirements document. I suspect that legal reading is different again.

Each manufacturer/provider has presumed one type of reading. Kindle is targeting trade paperback/hardback reading, largely for pleasure. The Que is designed for business use. Hearst’s Skiff is targeted more at newspapers. Apple is going after content deals galore, including textbooks and newspapers. None appear to target my pleasure-reading needs.

I’m not really worried about device fragmentation in the e-reader market. We know how to design and develop for that. I’m more worried about the purpose fragmentation. Is one going to win?

Clearly the mobile phone will continue to win here. The Kindle’s ability to continue reading on the phone where you left off on the device is brilliant. But the problems with sharing and moving content to other places still plague them; I only want to purchase material I know to be temporary. This is an industry DRM problem, but Kindle appears to be extra protective. Still a no-go for me.

In the meantime, I’m still reading the occasional book on my phone, and carrying several paperbacks on trips.

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.

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.

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.

Are you losing potential mobile users?

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.