All posts tagged as "Review"

I finally got around to visiting USAA Mobile. If you’re unfamiliar with it, the company provides insurance, banking, and brokerage services to military families. (Thanks, Dad!)

I am thrilled with it. It provides text-only access to:

• View account history.
• Pay bills.
• Transfer funds.
• View transfer activity.
• View account balances.
• Place a trade.
• Check order status.
• Request an auto ID card.

They’ve made text-only access to the things that people need mobile. At the store and the credit card was declined? You can fix it! Need to send a payment to anybody? Pay bills lets you pay anybody already set up. Got in a traffic collision? Get your proof of insurance right away.

What I find so interesting is that bill payment is through a third party and their brokerage services are pretty separate from their insurance and bank services. The organizational work behind this is quite impressive. It worked fine on my old Blackberry and my Sanyo.

The home page is so simple, only 4 items for me and clearly not much for anybody, that they simply append the entire home menu to most screens. I can press 2 to pay bills anywhere in the site.

If handset manufacturers won't give us widget-based idle screens, maybe individual app providers can just cheat their way into it for us.

My N75 is pretty customizable for a mobile phone, really. But it only allows me to customize a small line of icons (six, actually) on the idle screen. The rest of that screen is occupied with an events list from the calendar I never use. And of course, I am always reminded its an AT&T phone; 'cause the screen-printed logo is almost 2" away from the top of the screen.

One of my favorite mobile apps, LCG Jukebox, snuck a sort of portlet/widget thing onto an unused spot on the idle screen while playing music in a very useful and unexpected cheat of the interface.

And now google has made their new mobile search a downloadable app for the S60. And it puts a neat little (passive) widget thing on the home deck.

It even fades away after a while, which is perfect since they recognize that this is a reminder of a shortcut, not an interactive element itself. Clicking the shortcut key (the little pencil is a key on most S60 devices, like mine) brings up a real, interactive search widget!

This search widget, unlike some full-screen apps I have used lately, supports the existing device interfaces completely. The input method is changable (from predictive to triple-tap, for example) and uses the conventional symbology, just inside its little widget. Simply pressing OK/Enter submits the search, and it even takes over the softkeys for options.

The results are full-screen, as they should be and are basically identical to the web based search results and are just offered up in the default web browser. Options are available, but are at the bottom of the screen, again exactly as they should be. If there is anything odd, its that the app has a cursor.

Despite being a very standard-looking list-based layout that would have worked fine with simple scroll-and-select indicating, its got a pointer . Not sure why that is. because its in the default browser, which I don't like much. I wonder if there will be a way to change to results target, so I can just open them in Opera Mini instead? Especially when following links to other sites, a better browser and single set of bookmarks would be nice.

I don't think Symbian originally expected Google (or LCG) to do this with their software. I certainly see nothing about this functionality in their documentation. So I wonder what else can be pulled out of various existing OS's as clever developers work to bring us better experiences, one app at a time.

(I also sorta wonder if this will change Google's ranking of device use; I for one will never, ever be using the yahoo! search built into the Opera Mini browser anymore.)

For our complete thoughts on how widgets and home decks could and should work, request a copy of our widgets white paper.

I am a Google addict of sorts. I'd be fine with any other sufficiently good search engine, but these days Google seems to have won. For example, the default search on the Opera Mini home deck is Yahoo! Its demonstrably terrible. I used it for a while without success before switching over.

So, I spend a lot of my mobile browsing clicks on Google. I hit the link (or accesskey) from the Opera Mini home deck and get:

Yes, the Opera-squishes-everything-to-fit view. Zoomed out, and unusable (you cannot click fields or links without zooming). So I click into it, and focus on the field.

Then I have to scroll over to the search button and hit that.

Clearly, I'd rather have a mobile version of this, at least. Not much going on at the Google page, so why can't I just view and use it directly? I try the mobile specific URL, m.google.com

Yup, same thing. I guess some bit of the user agent string is tricking google into sending over the desktop version. Maybe their other mobile URL works google.com/mobile/

Naturally, it doesn't. Same as the desktop, it even tells me to just go to where I am from my mobile device.

Though there is a link if I am on a mobile, its inexplicably on the right side, to make sure I cannot see it on one of these browsers. At least its not also at the bottom of the page.

So, I click that. And it gives me a relatively mobilized listing of all their services, even downloads like the Gmail reader.

Click into the Search item reveals -- finally -- the correct, mobile-centric search page. I bookmark it, so I can use it later.

So, here I am the next day, trying to search for something. I hit my "Google mobile" bookmark and get...

...the desktop view, again!

Lest you think Google simply doesn't work on mobiles, we can switch Opera over to a mobile view (not even a need to switch browsers).

And sure, it works after a fashion. Its /still/ not the mobile version, just a compressed, style-less desktop view, but it works.

Not to mention, that setting is not per page, or domain, but global. Now Opera Mini is just a glorified WAP browser. So I switch it back, and muddle on.

I want to be clear that I am not picking on Opera alone. The same thing happens on some other browsers, to some degree or another. Similarly with Google; why be so smart about detection that when I enter a mobile URI the desktop version is displayed instead?

If you are a content provider, try to divine the user's intent. Did the I type .mobi in the URL? Or m.yourdomain.com? or yourdomain.com/mobile? I probably didn't type that by accident, and should therefore be shown the mobile version. Next, try to figure out if the user is on a mobile device. Opera Mini will always be on a mobile device; it doesn't matter as much which device as long as you know its not a desktop computer.

If the user typed a generic URL in a fully capable mobile browser, then it might become hard to tell which one to display. I personally think that if you have a mobile version of your site, this seems like a good time to serve it up. If you think some people will want the desktop version, just offer a link at the top of the screen to switch over. This extra click doesn't add much to the full-screen browsers that already require clicks just to get to the zoomed-in-enough-to-read view.

For the transcoders (e.g., Opera, Novarra, Openwave), you also need to try to figure out when the user means "mobile." I've been told by some very nice W3C folks that there is a list of methods to accomplish this (typing .mobi is one of them) but we've still somehow got Opera deciding that a web page needs to be transcoded even when it was typed as .mobi). I find it hard to see how this can do anything but fail to meet user expectations, and continue to emphasize how the mobile web is just a pale shadow of the desktop version.

You’ll find a wide variety of pundits asserting that the future of mobile is the web. I only somewhat agree.

The future of mobile is a mix of person-to-person communications and access to on-device and off-device data, all through a variety of mechanisms. These mechanisms include browsers, local applications, synchronization, and widgets. Browser-accessed information will be a mix of mobile-optimized web pages and generic web pages (some of which may be primarily aimed at mobiles).

Offline access is critical to some situations. Consider this: at the doctor’s office, I need to schedule a new appointment. I have my calendar out. The woman at the desk looks at her information, and asks “Is March 18 okay with you?”. I want to be able to answer her question within 5-10 seconds. I can do it with a paper calendar. I can do it with a local calendar. I can NOT do it with a web calendar, not when I have to either type in the date or instead navigate to the date. Don’t forget that loading a page on most devices takes well more than 5 seconds alone. For this morning’s task, I could have answered that question within 18 seconds based on my current setup, but only because I already had the browser page pre-loaded, and merely had to navigate to the correct date. This is rather stressful when there are people behind me in line.

This is why Google’s product release last week is so important. Google now synchronizes Google Calendar with Blackberry. This is significant: my best mechanism prior to this was to use iCal to view Google Calendar, synchronize iCal with my Blackberry, view my calendar in Blackberry, then open up a web page to be able to add event. This morning was far better: I opened up the native calendar (1 second), navigated to the correct week (1-2 seconds), confirmed that the time was good and had started entering the new appointment (1 second). When I got to my desk, my event was sitting on my calendar.

There are limitations. For now, it’s only for Blackberry. Because Blackberry is built on a variant of Java ME, I expect the next set of devices will be those with the Java ME “PDA Profile” (that’s JSR 75), which allows access to the device’s address book and calendar. Those are a relatively small population of all Java devices, and introduce the problem of communicating which devices support the feature. Next, while Google supports multiple calendars, Blackberry has no idea that they exist. So Google sends down all the calendars you request, but new events go to your primary calendar. This is completely livable for most people.

In many ways, Google just made the Blackberry a very compelling platform for small businesses. While I don’t have (nor want) my Google contacts on my phone, I do have my oh-so-important email and calendar. The former is an application using local logic and presentation of remote data; the latter is entirely local with periodic updates. Oh, and I have a quite good maps application from them as well. This is the sort of “one web” I want to see. Not one type of web page.

I’m now waiting on a good RSS reader for my Google feeds. There is one that looks okay, but it (a) is $40 and (b) aborts on the install process.

We all know that text input is hard. URLs and passwords are especially hard: they can't use word completion such as T9 or eZiText, they use odd combinations of letters, and they are unforgiving of errors.

Despite this, many users do not bookmark sites. They type in the URL once, then use the browser history to find it again. And again. And again. The good news is that they have gone off-deck; the bad news is that navigating history is a challenge unless careful attention is paid to the history UI as well as page titles.

Alas, that frequently doesn't happen. 15 entries all of which say, "MySiteName.com" do not help. Almost as bad is titles that say "MySiteName.com - we are a great site - Home Page", as you're unlikely to be able to read all that on the mobile.

So I was interested when I learned about http://www.pa.gd/. The concept is fabulous: want "www.gmail.com"? Type the first three letters and the last one letter: "gmal". Want "www.rememberthemilk.com"? Type "remk". Great, and you can certainly learn it.

Alas, this works best for folks who are likely to either bookmark the page, or make it their home page. These are precisely the people who will find it a little less useful because they are bookmarking other sites.

It also works best for popular sites. This site, for example, is not present. (edit: it is now) Nor is livejournal.com, which is more surprising. (edit: I made an error in entry.) They do some error-catching, but its design could very much be improved. For example: crawl the web and find all domain names that match the pattern, query their Google page ranks, and return a list sorted by page rank. At a minimum, fix the not-found page, which looks like this:

Paged mobile service message: unfortunately the requested input cannot be found. Please go back to try another input or modify the following pick to the desired web address:

Better would be something like this:

Oops, Paged doesn't know about livj. Try again or enter a URL:

Unfortunately, the service is not for novice users.

EDIT: I stand corrected. Livejournal is indeed available as a shortcut, and my (rather extensive) experience using Quicksilver with its arbitrary shortcuts had me using LJ as my shorthand for Livejournal. Don't take that as a complaint for how pa.gd is architected:   Quicksilver works for things I regularly visit, not the entire Internet. Also, as noted in the comments below, www.littlespringsdesign.com is now available. Thanks!

Alltel, a regional operator in the US, partnered with Frog Design to launch Celltop widgets. I mentioned this briefly in January.

This past week, Scott Weiss of Usable Products announced a usability study comparing Celltop to WAP and native UI for a variety of tasks.

What I found so interesting about the Usable Products study was that they compared the usability of a new interaction (CellTop) to that of well-learned applications (e.g., native UI for looking at call logs). As the entire session was only one hour, which included several tasks attempted both with and without CellTop. Thus the users had a year or two of experience with the native UI and were comparing to a UI with a new interaction paradigm. It's no wonder Celltop fared poorly.

Some tasks did not have quite as steep an experience difference. Checking weather is likely something many users only do occasionally, but the limitations of the mobile browser on the tested device means that the experience was reasonably familiar.

Celltop does indeed break many of the user expectations a bit. Some of this was done with intent. At the Austin Mobile Monday event in April, a key Celltop designer actually mentioned that she did not see the point in softkeys, and she pretty much ignored them. I disagree with her, but perhaps if everybody ignored softkeys the Celltop learning curve would have been more shallow.

In short, before believing that the Celltop widgets were indeed "less usable" than the native and WAP counterparts, I would like to see the test repeated with users who had been using Celltop for a few weeks. Alternately, give the users the opportunity to explore Celltop for half an hour, setting it up as they wish, on their own phones. Then compare task usability.