MUSEUM-L Archives

Museum discussion list

MUSEUM-L@HOME.EASE.LSOFT.COM

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Mark C. Vang" <[log in to unmask]>
Reply To:
Museum discussion list <[log in to unmask]>
Date:
Sat, 7 Mar 1998 11:13:29 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (75 lines)
Sheila,

You mentioned that you are using Windows, but what version,
3.1 or '95?  Also, you mention that the program uses a
custom made database program.  Does this program use a
standard database format such as Access, FoxPro, etc, or did
the programmer create a proprietary system of their own?
Did you write this program in-house, or was it developed by
an external software company?

Ok, enough of my questions... here are some recommendations:

One of the replies to you suggested removing keys which
allow termination of the program or which can trigger system
functions (CRTL-ALT-DEL to re-boot), I guess that this is a
way to do it.  Personally, I use touch-screens in my
applications and by-pass keyboard/mouse/trackball problems
entirely.  If you are working on a nickel-dime budget, then
you may be stuck with the keyboard.  Remember, your visitors
are expecting the keys to work, so if they don't, they will
just pound on them harder.

The problem you described where the program crashes when a
long number is entered sounds like a programming issue.
Fields where your visitors enter data should _automatically_
restrict data to valid parameters or convert it to a
standard format to use in the program.  Examples of this
would be routines to handle the following:

1. numeric data fields, check for letters:  134g5 < REJECT
12345 <ACCEPT
2. check for unnecessary punctuation:  12,345 <REJECT  12345
<ACCEPT  (your database may not recognize the comma so even
though the number was written correctly, it might corrupt
the database)
3. Use valid types for text/numeric data fields:  When you
set up the database, you should have used data types which
can handle the valid range for input... some computer
numeric data types are limited to certain ranges... if you
pick the wrong data types when you set up the database, you
will get wrong answers when you use the numbers in
calculations.  If the numbers are used internally by the
program, it may seem to crash of no reason only when
specific values are used (very hard to track this type of
error after it has been written into the program code).


The bottom line is that your computer software has to be
designed to compensate for your visitors.  You should also
have a program which will automatically re-load the exhibit
software if it does crash so your visitors are not allowed
access to the desktop/program groups.  I wrote a program to
use in my exhibits called SafetyNet.  When I develop custom
interactive software for exhibit/public use there are
several safeguards I apply to prevent problems before they
start.  For example, I always use an uninterruptable power
supply/line conditioner on my systems.  If you are just
using a surge protector, you may be having problems with
data corruption due to power brownouts/glitches/noise.
Even the best surge protectors are limited.

Well, I could go on all day... If you haven't guessed it
yet, I design turn-key touch-screen computer systems for
museums and science centers.  I specialize in user-interface
design for public use software and use computer
equipment/software which has been designed specifically to
prevent visitors from getting into mischief while allowing
them to focus on the educational content you want them to.
I will be glad to provide additional assistance, also please
visit my web site, www.freyaventures.com

Mark C. Vang
Freya Ventures
[log in to unmask]

ATOM RSS1 RSS2