At 5:23 PM -0700 5/25/99, Michael S. Davis wrote:
>Ok I have it working now but I'd like to pursue your point. Are you
>saying that it is better to avoid "dialogs in general" or just the "modal
>type" that halt instructions until input.
I'm not explicitly talking about the program flow, but if you change the
UI, the program structure naturally changes too.
The point I'm after is that stopping your user to have them make a decision
that MUST be made before they can continue is generally a bad thing to do.
Note I said "generally." Putting up more than one of this kind of decision
point in a row multiplies the problem.
If you have more than one decision to present, you're better off with a
dialog that has several controls.
The user's inner dialog with the halt instructions until input is forced to
be this: "I want to do X, so tap the button that says X, then decide if
it's X1 or X2 or nothing at all." The user's inner dialog with multiple
controls instead is "I want to do X1, so tap the button that says X1", or
"I want to do X2, so tap the button that says X2"
I was recently playing around with a little freeware game that was
halt-instruction-dialog driven. At the top level, it had a variety of
destinations. Tap on a destination, and several events might or might not
happen to you. In one destination, there were a couple of financial
institutions to visit, so the flow was something like this:
Tap "Bronx"
Dialog pops up: "Do you want to visit the loan shark?"
Tap "no"
Dialog pops up "Do you want to visit the bank?"
Tap "no"
Dialog pops up "Do you want to buy a larger coat for $100"
Tap "yes"
...
Same thing for buying and selling -- you'd tap on what you wanted to buy or
sell, and a dialog popped up with a field for you to fill in how much. If
you entered the wrong value, it put up an error dialog that you had to
dismiss.
This gets old, fast. I don't want the program asking me about every little
thing -- I want to feel more in control.
I'd much rather have seen a field next to each thing I could purchase,
already filled in with the maximum amount I could buy, and a little control
labeled "buy". Same thing for selling. If there was a bank or loan shark
available, those options could have appeared as seperate widgets to
interact with. Now *I'm* in control, and get to say what I want to do and
when.
Back to the program flow -- obviously you can't implement the
user-in-control style of interface with alerts and dialogs. Instead, you
have to craft a form with useful controls, popups, lists, buttons, etc.
Then you have to respond to events that are generated as the user interacts
with the form. This flips your program design upside down, so instead of a
single large procedure with linear flow through the segments, you end up
with little functions (or methods) that do little things, and they're
chained together by the user.
You can actually end up seperately designing the user interface, the data
model, and the control flow. The end result there is portable, easily
expandable code.
--Bob
