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