The BlackBerry World Application (yet again)

For several years now, I’ve been writing articles for this site that analyze poorly designed mobile applications.  It has always amazed me how mobile application developers just don’t seem to think about how their applications would be used and the ‘What were they thinking?’ series of articles was born. It rarely takes me more than a few seconds to see where these applications fail.

As I prepared to attend BlackBerry World, I of course downloaded the application for the conference and quickly saw that I would have yet another ‘What were they thinking?’ post centered on the BlackBerry World application. 

It just doesn’t make sense – why do they continue to produce unusable applications for the conference? Isn’t this supposed to be their showcase conference? Isn’t the BlackBerry app for the BlackBerry conference supposed to be the best of the best? Don’t they know how to build cool and useful apps for BlackBerry? They’re BlackBerry, right? The BlackBerry Travel app is amazing, why is the BlackBerry World conference application so…challenged?

Let’s take a look at the app. When I first launched the application, I saw what’s shown in Figure 1.

Figure 1

The first thing I noticed was that it appears that the only option available to me is the ‘Share This’ option. All of the other icons appear to be disabled. I seriously spent the 30 seconds or or so trying to figure out why all of the application’s options except for ‘Share This’ were disabled.

Taking a hint from Windows or Mac OS, disabled options usually appear without any coloring so users can easily tell which ones are enabled and which are not – just like most of the icons appear on the screen shown in the figure. There’s no shadow or highlighting that would make me believe that those other options were valid. When designing a mobile application, if you’re going to have a bright blue icon and you don’t want your users to think all of the other options are disabled, you have to use color on each and every icon on the screen.  The only other option is to use no color at all – for all icons on the screen.

This particular effect is even more prominent in the BlackBerry 10 Jam application shown in the figure below. In this example, the icons look even worse. Clearly nothing except for ‘Share This’ is a valid option, right?  The dull grey tone of the remaining icons on the screen screams ‘this option is disabled.’

Figure 2

The next thing I noticed in Figure 1 is that this is a browser application (see the ‘mouse’ cursor in the upper-left corner of the screen? The first thing I did was swipe on the device’s touchpad to scroll through the options (the icons) on the screen. No can do, the touchpad does nothing but move the mouse cursor. You can touch the screen to click the icons, but if you use the little optical touch pad, all you can do is move the cursor around on the screen (and click buttons). What an inefficient input mechanism.

As a developer, you have access to the touchpad and you could use JavaScript code to take that motion and translate it into something that highlights each icon as you swipe across the touchpad. Even if you didn’t have direct access to the touchpad input, you can still track ‘mouse’ movement and know that the first down motion of the ‘mouse’ should highlight the first icon (sessions) then as the ‘mouse’ moves left/right/up/down, move the highlight to the appropriate icon as needed. Oh, right – there is no highlight, all the developer created were these lackluster icons.

Whoever developed this application didn’t take into account users like me who has a BlackBerry Bold and didn’t want to reach all the way up (no, I’m not lazy) and touch the screen when I could simply use the touchpad. You have to accommodate both input mechanisms – touching the screen and using the touchpad. To ignore one and assume the other is poor application design.

When you scroll down the page, you see what I’m showing in Figure 3. Why did the developer feel the need to use a background graphic that’s far bigger than what is needed for the application? When you scroll to the bottom of the icon list, it should stop immediately below the last screen element displayed. It should not take up so much additional space on the screen. There’s no need to waste the space like this.

Figure 3

Now, I know the developer setup that background image to accommodate all of the icons that appear after you login. But why not show all of the icons, only disabling the ones that are not active – that way, this scrolling issue goes away and with that little extra effort you would have been able to tell that some icons were active and others inactive.

All that aside, I can’t seem to use the application since when I start it, I get the following error and I can’t do anything with my schedule.

Figure 4

On the second day of the conference, RIM released an update to the application, but because I didn’t get around to updating it. However, it doesn’t make sense that you’d need to release a new version of an application in the middle of a three-day window where the application would actually be used. They really should have done more testing. I'm assuming they fixed this particular problem, but I don't know.

I’d hoped years ago that this would be obvious, but I guess I’m going to have to say this out loud: What RIM should do is give me an application in advance of the conference and I’ll assess it for ridiculousness as I’ve done in this series. I'll identify the problems, RIM will fix them and all of you will have a better experience and I get to avoid having to write another ‘What were they thinking’ article.

It would only take me a minute to point out many of the simple design flaws that exist with each version of the application.

Got up early this morning and made it over to the hotel’s gym. It was nice to get some exercise in before starting my day. When I finished, I decided to walk around a bit just to get my back loosened up. As I walked past the BlackBerry World registration desk, I thought about my registration process and thought I’d write about it.

This is my 6th BlackBerry World (or Wireless Enterprise Symposium, WES, as it used to be called), so I knew exactly what to do. I walked toward the registration area, following the signs and walked up to the registration tablets. Of course RIM uses the BlackBerry Playbook for registration, makes sense. Of course, there’s always someone there to make sure you know what you’re doing – as I walked up purposefully to one of the tablets, she asked me ‘You here to register?’  I’m not sure what else I’d be doing in the Registration area, but yes.

Anyway, as I typed away at the registration process, I truly struggled. For some reason I just couldn’t type my email address (all that’s needed for that part of the registration process). I love my BlackBerry Playbook; I use it all the time. Suddenly I kept mistyping then having to back up and fix the text I just typed. Embarrassing. It wasn’t until I walked past the registration desk this morning that I realized why. The tablets were attached to the table using Velcro! Of course I couldn’t type on them – they’re designed to be held in your hand not strapped to a table. The angle was all wrong. If I’d been able to pick up the tablet and use it like I always use it, I wouldn’t have had problems with the registration process.

I understand the need to keep the tablets from walking away, but they should allow me to use the device in the manner in which I’m accustomed. Not force me to use it in an unnatural way.  Attach it to the table using some sort of cable; accommodating both left- and right-handed people and you’d have a better experience for registrants.

Once the application showed me that my registration had been accepted, it told me to go to badge pickup area B to get my credentials. As I walked away, the handler, the girl watching everyone register, told me I had to click the finish button to finish the registration process. This isn’t critical, but I think this is an application design issue that needs to be addressed.

The finish button was a standard web browser button that I’d completely missed because it was too small for fingers. When the application told me to go to badge pickup area B, I immediately attempted to walk away from the station to pick up my credentials. That’s expected behavior, right? Why do I need to click the Finish button? The application knows I’m finished, why not leave the information up there for 15 or 30 seconds or so before moving on to the next screen itself rather than force me to click the button as I leave? Another option would be to put up a ‘Next Registrant’ button or something so that if someone else comes up before the 30-second window had completed (which is highly likely during the first 24 hours of the conference).

What they should have done is use up more of the screen real estate for the button, so it’s more easily seen and, very importantly, large enough that the user can easily click it as they’re walking away from the table. I found that because of the limited space allocated for the button that I had to force myself to stand still and concentrate on getting my finger within the button borders. If they’d used a much bigger button, I could just have swiped at it as I was leaving.

This is a perfect example of what happens when a developer designs, develops and tests an application outside of the environment where the application will be used. I imagine that if the developer had to test the application while standing up and while the tablet was strapped to a table, that he (or she) would have made some adjustments to the application’s UI before putting it into production.

If you remember a while ago I published an article (which can be found here) that explained some of the issues I encountered trying to build and run a PhoneGap application for the Samsung bada OS. Well, with the help of the developer who wrote the bada code for PhoneGap I was able to finally figure it out, get it working and finished the bada chapter for PhoneGap Essentials.

First I’m going to complain a little and then I’ll tell you what you need to do to build PhoneGap applications for bada.

Missing Files

In the article I pointed out how the files you needed to build a bada application using PhoneGap weren’t actually in the PhoneGap download. I just checked in the PhoneGap 1.7 release candidate download and they’re still not there. I simply don’t understand it. The development team knows the wrong files are included in the download, but months and months later this particular problem still hasn’t been fixed. How hard can it be to make sure the files you need are packaged into the download? I discussed this with them months ago – you would think this wouldn’t be hard to fix.

Beta

Did you know that support for bada in PhoneGap is considered beta? No, neither did I. The reason the instructions I needed to understand how to build PhoneGap applications for bada were not available is because the PhoneGap project considers (or considered) support for bada to be in beta status. I wish they’d told me that when I started.

Wrong SDK Version

OK, the reason why I  (and all of you) couldn’t get the bada stuff to work, even when you had the right files, is that the bada code (still being beta and all) was written for and will only work for an older version of the bada SDK which is no longer available for download. Perhaps I missed this when I started working with this back in August, but I finally see it listed in the readme:

DISCLAIMER: THIS IMPLEMENTATION DOES NOT WORK WITH THE BADA 2.x SDK. ONLY 1.2 is supported BY THIS IMPLEMENTATION!

So, in order to be able to use this for your bada applications, you will have had to already downloaded this older SDK (before Samsung pulled it from their web site). If you didn’t do that, you’re out of luck.

I just noticed too that actual instructions for building bada applications for PhoneGap are now posted to the PhoneGap web site: http://phonegap.com/start#bada.

Conclusion

So, now you know what you need to build bada applications using PhoneGap. As I understand it, the PhoneGap development team is working on an update to the code that will work with the bada 2.x SDK. This will essentially be a complete rewrite since 2.0 does things differently. Once that is done, building bada applications will be easier since you’ll be able to use the latest SDK, support the latest devices and have a simpler process for starting a new app (I hope).

I got up early this morning to answer some last minute questions from my editor for PhoneGap Essentials. We’re almost done with the book; I just had a few questions to answer. The editor asked me to redo one of the screen shots because it was a little blurry. I dug out the device I used to take the screen shot and setup the shot. The device battery had died, so I plugged it into power so it would charge as I began my test. As I loaded the application and started the video capture application used in the book, the application threw a couple of errors.

On this particular device, video capture is disabled when the battery life falls below a certain threshold. This makes sense, but in this case it shouldn’t have mattered since the device was connected to a power source and was charging. Apparently it does.

Anyway, that’s not really important, what’s important to me was how the application responded. As I wrote that chapter, I struggled to determine how to cause errors in the video capture process. I could of course cancel the capture and show readers what was returned to the PhoneGap application, but I was looking for real errors and finally found one. The trouble is, the information returned from the PhoneGap application wasn’t enough to help me as a developer understand what had actually happened to cause the failure.

Let’s take a look at what I mean.

If you take a look at Figure 1, you’ll see a screen capture from the device as soon as I attempted to record video from the application. The alert box is the application’s way to let me know what happened during the process. In this case, the device refused to take the video (because the battery was too low) and returned a canceled error to the PhoneGap application.

Figure 1

I didn’t notice at first, but the device also displays (for a very short time) an error indicating why it can’t capture video. It wasn’t until I’d tested this a few times that I noticed that little pop-up below the alert dialog.

Unfortunately, no error code beyond the simple cancelled message is returned to the calling program, so there’s no way for the PhoneGap application to tell what actually happened and recover cleanly. All the app knows is that the video capture failed, not why.