[ggo-discussion] Re: usability: How do I play?

  • From: Peter Strempel <zotan@xxxxxx>
  • To: ggo-discussion@xxxxxxxxxxxxx
  • Date: Sat, 3 May 2003 08:25:31 +0200

On Fri, May 02, 2003 at 05:07:11PM -0700, mAsterdam wrote:

> And Peter spoke:
> > ...  the forth is irrelevant unless you really intend 
> > to play multiple games (who does?).
> 
> What would "Open False Looking True" mean ?

Ehrm yes, I used the fifth combination with "toggle brain off". This indeed
makes no sense.


> "How do I play?". 
> 
> Well, I did not have that question at any time. But if tweet is in the
> know that should be usability issue number one immediately. Did you ask
> what the people who ask the question _tried_ in order to play? (this is a
> very good source for ideas on improving usability) It is a much broader
> topic.

That doesn't make it top priority in my eyes yet. I pondered a bit more
about the topic and have not found a smooth solution I really like. I will
ponder a bit more.


> You could add a level, for instance: 
>     Top-level: Info Play Action
>            Info: Stats / Results / Probability / Stored / SGF
>            Play: Send Match request / Send Automatch request  
>            Action: Talk / Trail / Friend|Neutral|Ignore

You are right, the popup is too big. It grew with time, and I added the
dialog last. So before I did depend on the multiple items. Actually I still
prefer to use "Stored" from the popup instead of looking at the dialog when
I want to quickly screen some potential opponents. Saves me closing the
dialog. I am usually keen in reducing the number of actions to be performed
to achieve a certain result. A submenu inside the popup would then mean you
need to move your mouse to open the submenu and then find the right entry.
Doesn't sound so thrilling. But I suppose it might be no bad idea to clean
the popup a little.

There are two quick-access actions additionally to the popup:

* Double Left click opens the playerinfo
* Double Middle click opens the match request

So you can actually bypass the popup to open the dialog already.
(I didnt figure how to implement Double Right click avoiding the popup to
appear).
I think double-clicking is something pretty obvious people might try, and it
gets the most obvious result, the dialog.

The problem with newbies here is, they don't even find the popup menu or the
double-left-click action. They try to mark a player (the line) and then
wonder where the "Play" button is (as in PandaEgg). But I dont want to
clutter the player table window with a useless button. The current buttons
are ok and useful, but already too many of them.


> But this is just to coin a few possibilities along these lines. 
> I don't like them. A simple: "How to play" entry in the top help
> menu (even above "Manual") would be enough:

This would be my prefered option, too. I think it is currently not so
difficult once you discover the popup, and I personally find it smooth and
convinient as it is now. What does not mean it follows the GUI standard
design patterns and is approved by a research group of psychologists.


> Text: something like:
Thanks, I will use that for copy&paste :)


> > A better manual might help,
> That is to big a project - hey you might consider making the manual open
> source :-)

Yes, first I fear writing the manual takes too much of my time from working
on the client, second Im not so interested in writing manuals.

Tweet had offered me to write the manual, but so far has not started yet. I
do not insist on writing the manual myself, I would appreciate help very
much. I would want to convert the whole thing into JavaHelp, so you can
display it in that already implemented Help viewer (quite similar to the
common Windows help, which is actually one of the better things in Windows).
Plus I want the manual available in a complete HTML set to publish it on the
webpage.

There are two possibilities: Write the manual in DocBook/SGML which can be
converted to JavaHelp and HTML (like the current poor manual is created), or
just write the manual in HTML which can be used for converting it into
JavaHelp with some minor modifications (I found some tool to do that:
JHelpDesk). Whatever is prefered. Probably its easier to fire up something
like Dreamweaver and create a HTML manual set. I just happen to know DocBook
fairly well, so I used that.

There is not much to open-source for a manual, after all. What I do not want
is a manual-Wiki, too chaotic. It would be no problem if several people
contribute, but there should be one person to organize the whole thing and
give it some consequent design, and this has not to be me. Actually I dont
know much about webpage design, so I am not the most competent person for
this job. The whole HTML/SGML set would then be sent to me so I can add it
to the JavaHelp thing.

I think what Tweet had in mind was something like the PandaEgg tutorial on
the IGS webpage, maybe you have seen it. I don't see this as a manual, but i
think it is convinient for beginners who are too lazy to RTFM (amazingly,
people don't even read the PandaEgg tutorial, when I look at some
questions).
This is the remaining huge problem. You can have a really cool manual, but
if someone doesnt read it and pretends the software does not work, there are
not many options left. I know this problem from other projects, not only
talking about gGo here. The common user who has no experience in software
starts a program, he does neither read a manual nor bothers to check
tooltips. He expects the program is so intuitive that he understands
everything from just looking at it. This is how Microsoft software is
designed and what makes it so successfull. But I lack the energy and
knowledge to invest in this, and as there is no commercial background to gGo
it does not hurt me if someone does not use gGo. To say it bluntly, if
someone thinks the client sucks because he doesn't understand it, I do not
care.

To sum it up, my prefered solution would be a good manual which explains
each part of the GUI, plus the FAQ for the really common stuff, plus
optional a sort of tutorial like the PandaEgg one. When I say "manual" I
mean a manual, not a tutorial or HowTo. This is work I would love to have
someone else do, so volunteers are welcome. However, I cannot offer money
for it, gGo is not a commercial product. But of course, the usual
free-time-project rules like no time limits etc. would apply, like I apply
them to myself: No time or motivation to work on it? Allright, don't work on
it.


 Peter

Other related posts: