The Pocket Commando by Carl Davis | Back

It’s Great to be Us…Developers by Carl Davis
Written by Carl Davis  [author's bio]  [read 20015 times]
Edited by Derek

         

Page 1  Page 2 

A few days ago I was using an application that had a number of popup messages to convey status and what was occurring with the system. I began thinking how much they seemed to get in the way as I tapped "OK" to dispose of each. It started me thinking on how efficient designs differs between desktop machines and handhelds. Receiving popup messages was natural on the desktop, but I am less forgiving on my handheld.

The next thought I had was it's great to be a developer. If you don't like how software works, you can make your own that solves the problem. Now I realize that this isn't always the case, but it's this very challenge that gets your blood flowing in the morning. So I started thinking about a couple of things that I wanted to improve in my PocketPC experience. Although there are a number of thoughts, I wanted to share two of them this time. The first is a recommendation on placing controls on your forms and layouts. The second is an improved popup information box that automatically disappears.

Pitching Low and Outside…

On your typical desk-based and web-based applications, navigation and controls are placed as far up and to the left as possible (I'll call this "high and inside" in honor of the new baseball season). For example, most web page's menu and button bars go across the top of the window and links to major sections are found on the left-hand side.

This technique works well for desktop applications, because a user's natural reading direction flows from top to bottom, left to right. This doesn't work nearly as well on the PocketPC platform. As you tap on the screen (for right-hand users) your hand will obscures the information being displayed.

Just as other professions, developers can get into a rut. We get use to building things in a particular way and don't really question whether it's the best. I was playing some games with a friend of mine and was using a dice rolling utility I created (see Figure1). I realized I had designed the application using the "high and inside" layout and each time I tapped to generate a roll, I needed to move my hand to see the result. I'm currently redesigning the application to focus on this aspect. I'll put the controls low and to the right or "Low and Outside" on the screen. Fortunately, Microsoft has done a lot of this work for us already with menus and tabs designed with this in mind already.

Some of the guidelines I've started using include:

• Keep controls that are interacted with and modify content "Low and Outside".
• The only controls that should appear at the top of the display are column headers that allow sorting changes or can drop down to show more options (e.g. File Explorer's directory selection)
• The most important information for the user should follow the "high and inside" rule. I also like the idea of minimizing scrolling and try to minimize my use of scrolling forms.

Although none of this information would fall into the category of sophistication found in aeronautical engineering of solid fuel propulsion systems (i.e. rocket science), I've seen numerous applications fall into this trap.

"A Tap Saved is a Second Earned"

Let me get right to the point, popup message boxes are some of the most annoying user interface elements found on the PocketPC. Of course, they're necessary to draw a user's attention to a important piece of information, or allow them to acknowledge a change they're about to make, but constantly selecting "OK" gets pretty old quickly. It would be wonderful if messages like "Save Completed" would disappear without telling them to and save me a couple of taps in the process!

So I put my developer hat on and went about creating an eVB message box that would automatically disappear after a short period of time. I wanted to create a popup message box that wouldn't require the user to click on "OK", but would give the user the final say whether to enable this feature or not. I also wanted to allow the user to change their mind and tap on the message box to keep it from disappearing.

The user interface for my message box is found in Figure 2.

The key elements in our new message box are a Label to display our text and a checkbox to allow the user to enable auto-hiding. To implement the message box, I created another form in my project. This allows me to do some basic encapsulation of functionality. For completeness, I created a simple API where a programmer can setup some properties beforehand or can call some mutator procedures to setup information. Listing 1 shows the two methods for calling our new message box.

Listing 1

' Use properties to setup message box
Private Sub Command1_Click()
Form2.DisplayTime = CInt(Text2.Text)
Form2.Text = Text1.Text
Form2.Caption = Text4.Text
Form2.Display
End Sub

' Use methods to setup message box
Private Sub Command2_Click()
Form2.SetAutoHide (False)
Form2.SetDisplayText (Text1.Text)
Form2.SetTimerLength (CInt(Text2.Text))
Form2.SetWindowCaption (Text4.Text)
Form2.Display
End Sub

The code for the message box is very simple. We use a Timer control to trigger hiding the display when the defined number of milliseconds elapses. Managing this configuration is handled by a couple of simple helper procedures (EnableAutoHide, DisableAutoHide). Enabling auto-hiding consists of enabling the timer, checking the checkbox, and setting the autohide Boolean value. Listing 2 shows the code that supports auto-hiding.

Next Page 

Back to the Pocket Commando | [Article Index]