I've been searching for a few days now for an answer to no avail.

The situation is that I am part of a group developing a complex,
multi-form application for Windows Mobile 5.0 on a Dell Axim x51. The
application is geared towards the elderly and must be simple and
appropriately responsive. During usability testing, a large issue came
up: the users were impatient about screen loading times, and so would
often press buttons (or on the screen in general) multiple times. This
would be simple to fix on a single form (simply deactivate buttons
until loading is complete), but because this is a multi-form
application, the screen presses register on all of the consecutive
loading forms.

We have two ideas for fixing this problem, but have had no luck with
either. The first is that when pressing on any button that leads to a
form change, we ask the device to lock (stop accepting input) and then
unlock the device once the form change is complete. I have checked just
about every group and the MSDN in an attempt to find out how to do
this, but there does not appear to be reference material in regards to
how to accomplish this.
The second idea was tag the message queue and filter out the messages
that occur during the times when the pages are loading, but this, in
concept, sounds like it may be unreliable and perhaps risky, as
important messages may be discarded.

Any advice on how to either lock the screen briefly from accepting
input or somehow filter button presses across multiple forms?

Thank you,
-Sam O.

>> the users were impatient about screen loading times, and so would
often press buttons <<

In my humble, (and "elderly") opinion, that's not an "elderly"
problem... that's a programmer problem!

It's because the programmer doesn't have a clue about user issues such
as that it's best to _immediately_ put something on the screen (even if
it's a blank screen) so the user knows that the button press was received...

If you are concerned about the "elderly" perceiving that response...
expand it... go from a white background to a bright green screen.

Then, if you app is going to take it's time, _do something_ on the
screen... a large digit countdown, color changes, something.

When developers of vertical software begin to understand that they need
to think like users instead of programmers, a high percentage of user
problems will fade away.

<end of soap box>

Beverly Howard [MS MVP-Mobile Devices] ...an "elderly" programmer.

Questions about programming are far more likely to get useful answers
in a newsgroup for programmers. If you are using a .NET language, that
would probably be microsoft.public.dotnet.framework.compactframework .
Otherwise, microsoft.public.pocketpc.developer


On 8 Aug 2006 09:46:28 -0700, "JadeBlueSkies"
<jadeblueskies@gmail.com> wrote:

>I've been searching for a few days now for an answer to no avail.
>
>The situation is that I am part of a group developing a complex,
>multi-form application for Windows Mobile 5.0 on a Dell Axim x51. The
>application is geared towards the elderly and must be simple and
>appropriately responsive. During usability testing, a large issue came
>up: the users were impatient about screen loading times, and so would
>often press buttons (or on the screen in general) multiple times. This
>would be simple to fix on a single form (simply deactivate buttons
>until loading is complete), but because this is a multi-form
>application, the screen presses register on all of the consecutive
>loading forms.
>
>We have two ideas for fixing this problem, but have had no luck with
>either. The first is that when pressing on any button that leads to a
>form change, we ask the device to lock (stop accepting input) and then
>unlock the device once the form change is complete. I have checked just
>about every group and the MSDN in an attempt to find out how to do
>this, but there does not appear to be reference material in regards to
>how to accomplish this.
>The second idea was tag the message queue and filter out the messages
>that occur during the times when the pages are loading, but this, in
>concept, sounds like it may be unreliable and perhaps risky, as
>important messages may be discarded.
>
>Any advice on how to either lock the screen briefly from accepting
>input or somehow filter button presses across multiple forms?
>
>Thank you,
>-Sam O.

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 478
Boston, MA 02116
www.penfact.com

Your response is the same response that we had, but this was not the
case during our initial usability tests. We had a declarative vocal
response from almost every tester (all between the ages of 65-85) that
1) they could not follow the program with screens changing so often and
2) that color differences and screens made them feel they had broke
something.
We have spent a considerable amount of time attempting to focus in on
how to best present this system, and every developer on this team has
spent an equally considerable amount of time with our projected users
(including much of our own family and staff) to determine what they
want.
I appreciate the suggestion, and it is true that many developers don't
think like the user base, which is why we have kept up such a heavy
regiment for involving the user at every step.


Beverly Howard [Ms-MVP/MobileDev] wrote:
> >> the users were impatient about screen loading times, and so would
> often press buttons <<
>
> In my humble, (and "elderly") opinion, that's not an "elderly"
> problem... that's a programmer problem!
>
> It's because the programmer doesn't have a clue about user issues such
> as that it's best to _immediately_ put something on the screen (even if
> it's a blank screen) so the user knows that the button press was received...
>
> If you are concerned about the "elderly" perceiving that response...
> expand it... go from a white background to a bright green screen.
>
> Then, if you app is going to take it's time, _do something_ on the
> screen... a large digit countdown, color changes, something.
>
> When developers of vertical software begin to understand that they need
> to think like users instead of programmers, a high percentage of user
> problems will fade away.
>
> <end of soap box>
>
> Beverly Howard [MS MVP-Mobile Devices] ...an "elderly" programmer.

Thanks for the response.

>> We had a declarative vocal response from almost every tester (all
between the ages of 65-85) that... <<

Again, I point you back to the users... the age different _is_
significant, so, consider refocusing on your (the programmer's)
relationship with the users.

As I programmer for almost a quarter century, I found (eventually) that
sitting with the users (and keeping my mouth shut) was one of the most
important part of my job designing software.

Watching them use the software, my goal was not to "educate" them on how
to use my product, but to let them educate me on how they wanted to work
and how they _expected_ the program to function to help them do the job
where _they_ were the expert. In addition to watching, I'd have
extended dialogues with them to help _me_ understand why what I had
produced was not working as well as it could to help them achieve what
they need to accomplish.

You indicate that you are getting feedback, but it appears that it's
advesarial feedback... a focus on the negative rather than the positive
aspects of what you are trying to achieve.

If the users are drawn into the development process, the answers to this
and future problems will be there... for example, asking why something
is confusing and solidifying that by asking what they would do to deal
with the problem. If they are invested in the project and begin to see
their input and suggestions implimented, you both will make progress.

>> that color differences and screens made them feel they had broke
something. <<

This is a "defensive response" ...it's easier for a user to place blame
than to admit inability to deal with the program in the first place,
which points back to getting them invested in the design so they can
"deal with the program." With advancing age, it's exaggerated by cases
where you are faced with the increasing ability to do things you once
could with ease... and denial that you can't or that somthing else is
responsible for that is an easy "out"

If the screens changing create confusion, handcuffing them so they can't
do anything is going to create more confusion... pointing back to the
original problem, they are taking action against what the device is
doing which they seem to be disconnected from.

You give their age range (fwiw, I'm near the bottom of the ages,) but
what is your age and the age of others involved in the project? What
kind of personal and social interaction do you have with them beyond the
tech details? How do you get feedback?

Beverly Howard [MS MVP-Mobile Devices]

Beverly raised some good points about developing user-friendly
programs, and I _think_ you mostly agree. I'll stay out of that larger
discussion, and just focus on a small piece. More below (in line)


On 9 Aug 2006 06:26:06 -0700, "JadeBlueSkies"
<jadeblueskies@gmail.com> wrote:

>Your response is the same response that we had, but this was not the
>case during our initial usability tests. We had a declarative vocal
>response from almost every tester (all between the ages of 65-85) that
>1) they could not follow the program with screens changing so often and
>2) that color differences and screens made them feel they had broke
>something.


How about working to find a _small_ but noticeable change? Similar, at
least in size, to the hourglass. I don't know the context, so I can't
be much more specific. If you're "walking" through a series of
screens, you can make them look mostly similar, except perhaps for the
title and a small graphic in the upper left corner.

I have disliked excess flash for several years, and am still (barely)
under 60.

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 478
Boston, MA 02116
www.penfact.com

Essentially, an "hourglass" type display is what we are aiming for, it
is simply a matter of ensuring that any accidental or arbitrary screen
touches during that time are ignored, as even with the hourglass they
still queue up for the form once it is reloaded.

Beverly did raise some good points. However, our usability testing is
being done with the actual intended user base during hour long
individual sessions where we say nothing at all. Both sides, the users
and developers, are a fairly tight knit group, and they know, for the
most part, what they want. Next week, our product will be put in the
user's home and tested in the intended environment with the intended
user, and we will certainly receive a heavy amount of feedback from
that.

Either way, because of the nature of the product and the users (most of
which have Alzheimer's or Parkinson's), the solution we need is some
way to turn off the screen's ability to accept input for short times.

Thanks for all the feedback, everyone.

-Sam O.


r_z_aret@pen_fact.com wrote:
> Beverly raised some good points about developing user-friendly
> programs, and I _think_ you mostly agree. I'll stay out of that larger
> discussion, and just focus on a small piece. More below (in line)
>
>
> On 9 Aug 2006 06:26:06 -0700, "JadeBlueSkies"
> <jadeblueskies@gmail.com> wrote:
>
> >Your response is the same response that we had, but this was not the
> >case during our initial usability tests. We had a declarative vocal
> >response from almost every tester (all between the ages of 65-85) that
> >1) they could not follow the program with screens changing so often and
> >2) that color differences and screens made them feel they had broke
> >something.
>
>
> How about working to find a _small_ but noticeable change? Similar, at
> least in size, to the hourglass. I don't know the context, so I can't
> be much more specific. If you're "walking" through a series of
> screens, you can make them look mostly similar, except perhaps for the
> title and a small graphic in the upper left corner.
>
> I have disliked excess flash for several years, and am still (barely)
> under 60.
>
> -----------------------------------------
> To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).
>
> Robert E. Zaret, eMVP
> PenFact, Inc.
> 20 Park Plaza, Suite 478
> Boston, MA 02116
> www.penfact.com

>> the solution we need is some way to turn off the screen's ability to
accept input for short times. <<

Ho Kay, back to the original point ;-)

What worked for me when this was needed was to go ahead and collect
input into a buffer while transitions were happening, then read and
discard the buffer when the new field was ready to accept input. As far
as the hardware buttons for other apps, most can be disabled in the
settings section (volume and power normal exceptions)

Since there is no "HourGlass" on the ppc (only a spinner which might be
hard to perceive, consider upping the font size to "huge" during the
transition, then printing "- \ | /" in the center of a blank screen at
each possible point during the transition.

Personally, I feel that a color change such as an animated gif of a
blank screen transitioning slowly from white to a color such as a cool
green and back could serve as a good transition background... perhaps
with a pause word appearing, then dissolving.

Good luck and thanks for listening... you will remember this as the
other grey cells begin to depart ;-)

Beverly Howard [MS MVP-Mobile Devices]

An input buffer would be excellent. Let me layout the situation:
1. A user presses on the screen
2. Onclick event fires and begins to load next screen
3. While next screen is loading, user presses again (or accidental
"double-click")
4. Once next screen is loaded, the second+ press activates on the new
screen, possibly selecting a button that was not visible when the press
occurred.

How do we implement an input buffer to ignore those presses during load
time?

-Sam O.

The specifics are going to relate to the development language (.NET?)
and for that will refer you to the microsoft.public.pocketpc.developer

While I know how to do it in my programming language, I don't know how
to do the same in yours.

Beverly Howard [MS MVP-Mobile Devices]

On Wed, 09 Aug 2006 17:04:43 -0500, r_z_aret@pen_fact.com wrote:

>Beverly raised some good points about developing user-friendly
>programs, and I _think_ you mostly agree. I'll stay out of that larger
>discussion, and just focus on a small piece. More below (in line)
>
>
>On 9 Aug 2006 06:26:06 -0700, "JadeBlueSkies"
><jadeblueskies@gmail.com> wrote:
>
>>Your response is the same response that we had, but this was not the
>>case during our initial usability tests. We had a declarative vocal
>>response from almost every tester (all between the ages of 65-85) that
>>1) they could not follow the program with screens changing so often and
>>2) that color differences and screens made them feel they had broke
>>something.
>
>
>How about working to find a _small_ but noticeable change? Similar, at
>least in size, to the hourglass. I don't know the context, so I can't
>be much more specific. If you're "walking" through a series of
>screens, you can make them look mostly similar, except perhaps for the
>title and a small graphic in the upper left corner.

Small addendum that may be irrelevant (given your reply):
One neat way to let the user know you sensed a button press would be
to change the appearance of the button. A drastic change would be
noticeable, but not nearly so startling as changing other parts of a
screen.


>
>I have disliked excess flash for several years, and am still (barely)
>under 60.
>
>-----------------------------------------
>To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).
>
>Robert E. Zaret, eMVP
>PenFact, Inc.
>20 Park Plaza, Suite 478
>Boston, MA 02116
>www.penfact.com

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 478
Boston, MA 02116
www.penfact.com

On 10 Aug 2006 06:33:44 -0700, "JadeBlueSkies"
<jadeblueskies@gmail.com> wrote:

>Essentially, an "hourglass" type display is what we are aiming for, it
>is simply a matter of ensuring that any accidental or arbitrary screen
>touches during that time are ignored, as even with the hourglass they
>still queue up for the form once it is reloaded.

The "hourglass" on "Big" Windows is called the Wait cursor in
programmer-speak. It has a different shape for CE. I've never
overlooked it, so I'm intrigued/concerned by Beverly's comments. I've
also found that it does not always appear as quickly as I would like.

Can you disable all the controls, etc. (EnableWindow is the relevant
Win32 function) temporarily? Or make input fields read-only?



>
>Beverly did raise some good points. However, our usability testing is
>being done with the actual intended user base during hour long
>individual sessions where we say nothing at all. Both sides, the users
>and developers, are a fairly tight knit group, and they know, for the
>most part, what they want. Next week, our product will be put in the
>user's home and tested in the intended environment with the intended
>user, and we will certainly receive a heavy amount of feedback from
>that.
>
>Either way, because of the nature of the product and the users (most of
>which have Alzheimer's or Parkinson's), the solution we need is some
>way to turn off the screen's ability to accept input for short times.
>
>Thanks for all the feedback, everyone.
>
>-Sam O.
>
>
>r_z_aret@pen_fact.com wrote:
>> Beverly raised some good points about developing user-friendly
>> programs, and I _think_ you mostly agree. I'll stay out of that larger
>> discussion, and just focus on a small piece. More below (in line)
>>
>>
>> On 9 Aug 2006 06:26:06 -0700, "JadeBlueSkies"
>> <jadeblueskies@gmail.com> wrote:
>>
>> >Your response is the same response that we had, but this was not the
>> >case during our initial usability tests. We had a declarative vocal
>> >response from almost every tester (all between the ages of 65-85) that
>> >1) they could not follow the program with screens changing so often and
>> >2) that color differences and screens made them feel they had broke
>> >something.
>>
>>
>> How about working to find a _small_ but noticeable change? Similar, at
>> least in size, to the hourglass. I don't know the context, so I can't
>> be much more specific. If you're "walking" through a series of
>> screens, you can make them look mostly similar, except perhaps for the
>> title and a small graphic in the upper left corner.
>>
>> I have disliked excess flash for several years, and am still (barely)
>> under 60.
>>
>> -----------------------------------------
>> To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).
>>
>> Robert E. Zaret, eMVP
>> PenFact, Inc.
>> 20 Park Plaza, Suite 478
>> Boston, MA 02116
>> www.penfact.com

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 478
Boston, MA 02116
www.penfact.com

While this is true, most of our user's with Parkinsons will press the
button 4 or 5 times before they can move their hand away.

Thanks a lot for the input. I have posted to the developer forums for
help, but this thread is the only one that people have responded to.

Thanks again,
-Sam O.


r_z_aret@pen_fact.com wrote:
> On Wed, 09 Aug 2006 17:04:43 -0500, r_z_aret@pen_fact.com wrote:
>
> >Beverly raised some good points about developing user-friendly
> >programs, and I _think_ you mostly agree. I'll stay out of that larger
> >discussion, and just focus on a small piece. More below (in line)
> >
> >
> >On 9 Aug 2006 06:26:06 -0700, "JadeBlueSkies"
> ><jadeblueskies@gmail.com> wrote:
> >
> >>Your response is the same response that we had, but this was not the
> >>case during our initial usability tests. We had a declarative vocal
> >>response from almost every tester (all between the ages of 65-85) that
> >>1) they could not follow the program with screens changing so often and
> >>2) that color differences and screens made them feel they had broke
> >>something.
> >
> >
> >How about working to find a _small_ but noticeable change? Similar, at
> >least in size, to the hourglass. I don't know the context, so I can't
> >be much more specific. If you're "walking" through a series of
> >screens, you can make them look mostly similar, except perhaps for the
> >title and a small graphic in the upper left corner.
>
> Small addendum that may be irrelevant (given your reply):
> One neat way to let the user know you sensed a button press would be
> to change the appearance of the button. A drastic change would be
> noticeable, but not nearly so startling as changing other parts of a
> screen.
>
>
> >
> >I have disliked excess flash for several years, and am still (barely)
> >under 60.
> >
> >-----------------------------------------
> >To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).
> >
> >Robert E. Zaret, eMVP
> >PenFact, Inc.
> >20 Park Plaza, Suite 478
> >Boston, MA 02116
> >www.penfact.com
>
> -----------------------------------------
> To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).
>
> Robert E. Zaret, eMVP
> PenFact, Inc.
> 20 Park Plaza, Suite 478
> Boston, MA 02116
> www.penfact.com

Thought about this last night a bit...

You are assigning an action to the click event... consider assigning a
code snippet that poplates variables, then runs a process that
determines somthing such as the interval to determine if the press is
valid, then run (or not run) the action based on the conclusions of that
snippet.

Beverly Howard [MS MVP-Mobile Devices]

On Fri, 11 Aug 2006 10:35:19 -0500, "Beverly Howard
[Ms-MVP/MobileDev]" <BevNoSpamBevHoward.com> wrote:

>Thought about this last night a bit...
>
>You are assigning an action to the click event... consider assigning a
>code snippet that poplates variables, then runs a process that
>determines somthing such as the interval to determine if the press is
>valid, then run (or not run) the action based on the conclusions of that
>snippet.

Perhaps something like the "inverse" of this:

//---------------------------------------------------------------------
// PFWIsDoubleClick
// returns TRUE if called twice within time for double click
// See Jan 03 thread called "how to validate against two mouse clicks"
in
// comp.os.ms-windows.programmer.win32
inline BOOL PFWIsDoubleClick( DWORD *dTimeLast )
{
// TODO: Why does this often not work properly (requires
triple-click)?
// Answer: edit boxes let user select, so first click is used to
select
DWORD dNow = ::GetTickCount();
UINT uDif = static_cast<UINT>(dNow - *dTimeLast);

*dTimeLast = dNow;

return uDif < ::GetDoubleClickTime();

} // PFWIsDoubleClick
The caller is responsible for making sure dTimeLast has the
appropriate scope. My note references a newsgroup posting, but doesn't
specify the newsgroup; comp.os.ms-windows.programmer is a good guess.

You might also want to check a current thread called "Long press event
on a button" in microsoft.public.win32.programmer.wince. Nothing there
seems really useful for you so far, but it may turn up.

>
>Beverly Howard [MS MVP-Mobile Devices]

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 478
Boston, MA 02116
www.penfact.com

Thanks, both of you. What we have settled on is that we will need
something like a glass pane in Java, a clear overlaying panel to
dispath clicks appropriately, with an input buffer like Beverly had
suggested.

Again, thanks,
-Sam O.