Tony Toews wrote:
> "Ron2006" <(E-Mail Removed)> wrote:
>
>
>>Also, that way the users accept some psychological ownership of the
>>application.
>>
>>Have fun with it. Give a certificate to the person who finds the most
>>inconsistencies - they are not bugs anymore. Listen to their problems.
>>If you can, watch them operate it - this can lead to changing tab
>>sequence and ordr of fields that can speedup and ease their work.
>
>
> As well as getting a feel for how they do things. I much prefer
> working in the next office or cubicle or desk in the corner just so as
> I'm easily accessible. I also respond very quickly to relatively
> minor things just to get some of their irritants out of the way.
>
> That said they also know it's best to send me an email or grab me when
> I'm grabbing some coffee or water or a bathroom break. They know
> that, unless it's important, to not break my concentration.
>
>
>>The constant complaint is that programmer/analyst/designers think
>>differently than users and operators. And they are right.
>
>
> I'm told that one of my strengths that I can design an app that is
> easy to use by the users.
>
>
>>So watch them
>>use it and think of ways by which they can do more of the work using
>>the keyboard instead of bouncing between keyboard and
This is a topic that's often on my mind. With two degrees in
engineering and one in mathematics I have an interesting perspective
about knowing when a solution is "correct." Pragmatically, if you do
not do any testing it is quite likely that the solution is "incorrect."
So user testing, as suggested in these posts, is essential but it is
not the end of the story.
Users can't try out every possibility so how do you know that someday
they won't discover an error? Some companies make testing software that
goes through many possible combinations of code branches and thus do a
better job than most users in trying to discover glitches. But that's
not the end of the story either.
The mathematician in me would like everything to be so airtight that you
can prove that everything is correct. That's rarely possible. The
engineer in me would like everything to be so airtight that the users
will almost never discover any problems. That's a little easier, but
not always possible either. In addition, engineering tries to balance
theory with experimentation so that the result is theories that model
reality accurately.
My users feel that if it doesn't break it's fine. Maybe not. Part of
the process I use in testing software involves thinking about whether
the process is correct or not. That's part of the reason that soon
after I finish testing, the software often runs without glitches for
many years. Sometimes I overlook things and need to go back, but much
of the time I discover those omissions without the users discovering
them first. If I cannot prove that I have done things correctly then
the code is always "open" as far as correctness is concerned. My users
are unaware that I sweat over correctness issues. My main problem
occurs when I have a well-running app that is integrated and, in
general, satisfying from a correctness standpoint, and then major
changes are requested. Small changes can often be integrated in with
blinding speed since they are in line with the design principles. Major
changes require spending time thinking about how the changes affect the
overall design paradigm. Requested changes that violate the primary
design principles take much longer to integrate. Customers have a knack
for requesting increased complexity in a way that demonstrates a short
memory for the original design principles. But that's partly my fault
because they had no clue what design principles were and I had to take
my best guess as to what they should be. You can only communicate so
much of the design principles to people who don't even know that they
need design principles.
From what I've seen so far from the PDC 05 presentations, the new
Access is not just an Access paradigm change or an Office paradigm
change; it is based on a complete OS paradigm change. VBA seems to be
in a direction that, while not opposite to the thrust of the new
paradigm, does not coincide well with it either. Since I agree with
that paradigm change in principle, though not yet in it's practical
implementation, I am trying to adjust my mind as quickly as possible as
to how I will interact with that new paradigm in the near future. In
other words, I have a new dimension of correctness to consider.
Finally, although I have learned much of value from participation in NG
discussions, I have been too lax with being in touch with the data.
Users don't see a lot of what goes on behind the scenes to make sure
that the UI and data work together efficiently and correctly. Am I
looking out for potential problems BEFORE they happen? Am I getting any
data that just doesn't make sense? Are some forms slowing down? How
large are important tables getting? Am I slowly modifying code to take
advantage of good practices that I read about in the NG's? Do I even
follow my own good advice? These are things to ponder.
James A. Fortune
(E-Mail Removed)
Similar Threads
