John Wargo

This example of 'What Were They Thinking' is for a Java application, not a web application - but I thought it would be an interesting addition to the series. It refers to something that absolutely drives me crazy in BlackBerry Java applications and I've seen the same kind of thing on other mobile platforms as well. Here we go...

As i've mentioned before, I'm getting older and with my advanced age comes reduced eyesight. If you see in the sample screen shot below, my BlackBerry client is configured to use pretty large fonts:

This approach makes it easy for me to read the screen without my reading glasses (which I've not yet gotten around to keeping with me always). I know this takes up more screen space, but it's something I just have to do.

Now, last week I was working in RIM's Chalk application (Chalk is a recent purchase and allows organizations to easily push rich content to devices). When I opened the application's main screen, here's what I saw:

The developer (or developers) who built this application, selected a font and size to be used for the application without paying any attention to how I had my particular device configured. For me, it's completely unusable without my glasses.

Why do developers disregard the user when desiging their applications? The BlackBerry device provides me with the means to configure the screen using any font and font size I want, but I have to deal with applications that completely ignore that. I know they've done this so they can give their application cool effects (like the graphical background you see in the figure) but that just doesn't take the needs of the actual user into account. I know any 20's user can see this easly, but it just doesn't work for us that are in our 40's.

Mobile developers - when building rich client applications on mobile devices, query the system to determine the font and font size selected by the device user and use that to craft any and all of your application screens. It's unreasonable to do otherwise. Trust that the device user knows better than you do how he or she wants text displayed on the device's small screen.

I'll try to scare up a sample application that does this (on the BlackBerry of course) so you can see how it works.

At first I thought I might have difficulty finding enough examples to make this an interesting series but that's turning out to not be the case. Just on a whim, I navigated over to linkedin.com to see how their site looked on the BlackBerry Browser. I expected that they'd detect that I'm running a BlackBerry and give me a mobile version of their site, but I was wrong - take a look at the following screen shot:

The LinkedIn developers broke the first rule of Mobile Web Development: Always (and yes, I do mean always) Detect the Browser!

What were they thinking? I cover this in the book, but it's important to highlight something here.  Because of the iPhone and other smartphones, developers are building their sites disregarding the information available to them about the target device. The iPhone and the Storm for example have pretty large screens, so 'normal' sites render on them OK, so developers have gotten lazy and just assume everyone's a desktop browser and tosses out the page. Unfortunately, even though the modern smartphone can render pages designed for the desktop (because of their supports for desktop browser standards and the larger screen than earlier smartphones) it doesn't always make sense to do that. Big web pages on small screens just don't look right (see the figure) and it's disrespectful of mobile users to send a whole bunch of gunk to the browser (graphics and a bunch of menu items).

Mobile web sites must be designed with the mobile user in mind and crafted so the user can get as quickly as possible to the data that matters to them. In this case, LinkedIn doesn't seem to be sensing that I'm accessing their site from a BlackBerry and gave me their standard page. Developers must always detect the user-agent and send a text-only, designed for small screen page to mobile devices.

On the BlackBerry and other mobile platforms, the user has the choice of changing the browser's personality to IE or Firefox.Let the user make this configuration change then get the whole page when they have the browser impersonating a desktop browser. Then, when people like me who let the BlackBerry announce itself as a BlackBerry, send a mobile-friendly version to all mobile devices.

For our Lotusphere presentation in January, Rob Wunderlich and I started talking about how to approach our topic about mobile web development. One of the things that came up was an agreement that a lot of developers, while they know all about web development, didn't think of the ramifications of their decisions as they mobilized their sites. Even though the mobile browser supports most of the web development standards, it doesn't mean you should make use of them. Also, even though you know how to build a site for a desktop browser, doesn't mean you should do the same thing for the mobile user.

We decided then that the underlying theme for our session was going to be 'What were they thinking' and in preparation for that I have started collecting examples of bad (bad, very bad) things that mobile developers do that makes life hard for mobile users. As I collect these things, I'll start posting them to the site and see where I can take this.

The first example for this series is is shown below. I am at a hotel attending some sales training (yep, I'm a sales guy now) provided by my employer and tried to connect to the hotel's wireless network to do some work. My BlackBerry Storm 9700 was smart enough to recognize that I was on a hotspot network, so immediately launched the hotspot browser so I could login to the access point before going on to do my work. When I looked at the page, I noticed something that I thought I'd share with you as the first rule in the 'what were they thinking' series.

Take a look at the following image:

The site gave me an easy way to select my language that didn't consume too much screen real estate (always a good thing). Imagine how much harder it would have been to use if there was a big list of languages or a drop-down list containing the list of supported languages?

Where the developer went wrong was in the way he (or she) used the radio button. Whenever you present a radio button to a mobile user and there's only one item in the list, you make them do extra work to select that tiny little button before clicking next. The smart developer will detect how many items there are in the list and either remove the choice all together or, if you're going to put a single item in a radio button list, pre-select the only available option. Don't make the user make the selection if there's no possible other option for them to use. It just doesn't make sense to make the user do that extra work when it's not necessary. 

I'm a little older and I'm starting to have trouble reading mobile device screens without my glasses, so when I was first presented with this page I immediately clicked the next button and didn't think about the radio button.Of course the page errored out and I had to go back and pay close attention to what I was doing - but this wasn't a good use of my time.

If you're building a site like this, please think about the impact of these types of things on your user. There's no reason to force a selection when there's really nothing to select.  Make sense?  Implementing this in dynamic environments like PHP or Domino is really, really simple - just a simple if statement with two different HTML outputs depending on the number of options in the list.

I’m excited to announce that I’ve been selected to present two sessions at Lotusphere 2010.

Rob Wunderlich and I are presenting a session entitled: ‘Delivering IBM Lotus Domino to Mobile Devices: Top 10 Mobile Browser Dev Tricks.’ The topic stems from some sessions Rob’s done at previous Lotuspheres and some sessions I’ve done at the View Domino Administrator/Developer Conference. It’s designed to highlight the trips and tricks of building Domino browser based application for mobile phones and smartphones. There’s so many things web developers need to worry about when working with mobile devices – we’re going to try to lay it all out for people who attend the session.

Rob and I have been working on the outline for the session and it’s really beginning to come together. I’ve known Rob for a long time and he and I both have interesting perspectives to bring to the session. We’re having some interesting discussions about some common misconceptions and things that need to be taken into account when building mobile web applications.

Here's a link to the session abstract:

https://www-950.ibm.com/events/wwe/lotus/lsph2010.nsf/sessionabstract?openform&sessionid=BP212

The other session I’m doing is called ‘Beyond the Mobile Browser – Building Rich Mobile Applications for Domino.’ It’s really an extension of the first session. In this one, I’m going to demonstrate how to build several mobile rich client applications that talk to a Domino Database. The assumption here is that although the browser is cool and all – that sometimes the browser isn’t sufficient for your application. Perhaps the user needs to manipulate data while disconnected from the network (on a plane for example or when in a business location without wireless coverage) or integrate with other applications on the device (such as the contacts, tasks or messages application). This session is an new and improved version of a session I did at the View Domino Administrator/Developer Conference in Boston earlier this year. I’m going to be building a rich client in Java (for the BlackBerry platform), Windows Mobile and probably Android. I’d like to do iPhone, but I don’t have a Macintosh and just don’t have the relevant skills right now.

Here's a link to the session abstract:

https://www-950.ibm.com/events/wwe/lotus/lsph2010.nsf/sessionabstract?openform&sessionid=AD114

Anyway, both sessions should be high energy, very interesting sessions. Please plan on attending if you’re at Lotusphere. The sample code for the applications will be posted to this site in January during the conference.