Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!olivea!oliveb!amdahl!key!jsp
From: jsp@key.COM (James Preston)
Newsgroups: comp.sys.mac.games
Subject: Re: pararena (was Re: PD/SW Games list)
Message-ID: <2524@key.COM>
Date: 3 Apr 91 23:50:10 GMT
References: <1991Mar31.194518.1957@magnus.acs.ohio-state.edu> <2515@key.COM> <1991Apr1.212723.29398@kuhub.cc.ukans.edu>
Reply-To: jsp@penguin.key.COM (James Preston)
Organization: Key Computer Laboratories, Fremont
Lines: 97

In article <1991Apr1.212723.29398@kuhub.cc.ukans.edu> 2fmlcalls@kuhub.cc.ukans.edu writes:
>You're certainly right.  I haven't ever even see the user-interface guidelines,
>but I can generally glean what's okay and not okay from other Mac programs. 
>And, I certainly need to put the command-Q in there.  BTW, is this version 1.2?

It's version 1.2.1.

>Consider the dilemna though.  Documentation never follows a program.  Now
>that's not my justifying using the menu bar to display info, because I don't
>think it's that way at all.  

But you already have a couple of help screens _in_ the program.  I would say
that you should include the command-E info -- perhaps highlighted in some way
so that it stands out -- on one of those.

>Nonetheless, this is a game where you click and
>drag all over the screen (were the cursor visible).  Allowing normal event
>handling would cause all kinds of crazy things to happen without your intending
>it.  Therefore, menu access is out of the question while the game is in play
>(in fact I don't even call GNE or WNE).  The command-E is a 'faked' menu
>command call.  The reason it is dimmed is because you can't end a game when a
>game hasn't even started (at which point you don't get menu access - so - the
>dilemna).  But, you're correct that I should try to find an alternative (and
>atleast fake a command-Q).

My point is that this thing should not be in the menu bar _at all_.  As you
say, it's not even really a menu item, so don't even put it there.  I have
no problem with disallowing menu access during the game, and I don't care
how you handle events.  The point is that this is a very crucial piece of
information -- how the user gets out of game play mode -- and putting that
crucial piece of information in a dimmed menu item just doesn't get that
crucial message across.

At the very least, you must provide a way for the user to get out of a game 
in progress when that user has no specific knowledge (i.e. when someone like 
me just starts it up to see what the game is like before having read anything 
about it).  Even if you put detailed instructions on one of the help screens,
you cannot prevent users from just going right into the game.  Even if you
put instructions on a start-up screen, you can't force anyone to read it.  So
the friendliest thing to do is to enable command-Q during game play.  If you 
want to strictly conform to the guidelines, its action should be to exit from 
the application.  However, I (and I think probably everyone else) would have 
no problem if its action were what now happens with command-E, i.e. to stop
game play and put the user back in command-mode.  From this mode, another
command-Q would exit the application.  This is the same number of keystrokes
as the current situation (command-E, then command-Q), but it saves the user
from needing to remember two different commands, it's probably a tiny bit
easier for you to implement, it avoides the need for any special documentation,
and it will certainly prevent the kind of frustration that I experienced.

>A final note.  In truth, I don't have any idea how to program.  I'm NOT a
>programmer.  

Well, if it walks like a duck, and quacks like a duck . . .  Maybe you don't
CALL yourself a programmer, but anyone who writes things like Pararena and
Glypha most certainly has many "ideas how to program".  Sorry, but you're a
programmer, whether you like it or not.

> . . . but you know I see a lot of very well crafted
>programs out there that follow (I'm sure) ALL of the user interface guidelines. 
>Many of these though as games are a little boring or unoriginal.  I come up
>with a lot of ideas, but lack the technical prowess to pull them off correctly.

Wrong.  You most certainly do NOT lack the technical prowess.  Your games
are irrefutable evidence of your technical prowess.  All you lack is a 
little knowledge about user interfaces.  Besides, a good program is both
interesting and well-crafted.  That there exist programs that are one but
not the other is no excuse for you to write programs that are the reverse.

>A final final note - look at how many other games break interface guidelines
>(like how many arcade games - popular ones - even HAVE a menu bar?).  Suppose
>though if I use one I should use it 100% correctly though (I already hear you
>saying).

I think, perhaps, you missed my point about the guidelines.  I have no problem
with programs that don't follow the guidelines _IF_ there is a good reason
for it and IF said deviation is properly documented and explained.  Pararena
breaks from the guidelines in two ways (no command-Q from game play mode,
and putting instructions in a dimmed menu item).  Neither was justifiable
nor explained.  But the real problem is that the combination of the two led
to at least one very frustrated user.  And I'm willing to bet large sums of
money that I am far from the only person who has experienced that.  What
you'll find, though, is that users of shareware -- particularly games --
have gotten used to sloppy programming and so just "live with it".  I think
there is no excuse for sloppy programming, even from self-proclaimed non-
programmers, regardless of the cost of the software.  (Not to toot my own
horn, but just as proof that I practice what I preach, check out my shareware
program, IntCalc, or my soon to be released game, Chello.  I spent a lot of
time on them and a significant portion of that time was an attempt to get
the best user interface I could.  I gave beta copies to friends and made
many changes due to feedback about things that weren't adequately explained,
or deviations from the guidelines, or things that just plain could have been
done better.  There is no way in hell that the shareware fees will amount to 
a fraction of what my time spent was worth.  So I don't want anyone expecting
me to be forgiving about a program's shortcomings just because it's shareware.)

--James Preston