[ggo-discussion] Feature brainstorming

Here goes some brainstorming:

 > Much may be due to my ignorance of proper use of the tool.

Much may be due to the lack of a proper manual.


 > Sorting the games display.  Yesterday a 7d* and and NR were
 > swapping colors every game for a number of games.  One game would
 > show up, then the next was buried where I don't usually look.  It took
 > a curious look at the player's list to wonder who the 7d* was playing.
 > to realise I was missing have their games.  Sorting on both columns
 > would be nice, maybe add the two and sort on that, I think that would
 > get what I'm after.

Hmm... you can sort all columns in the games table, ascending or descending.
Left/right click on the column title. But each sort is only on the
individual column, so within all say 5d games, the rows are placed randomly.

The only use of a secondary column search currently is in the player table,
primary on rank, secondary on name. The problem is, the game table sorting
is already pretty slow and costly, I don't want to slow it down even more.
But I might give it a try if it will really be noticable, I suppose it's
more the display update which is slow, not the sorting itself. I need to
fiddle a little with it.

Im currently unsure how to exactly do a secondary search for both ranks in
the games table. You get the white 7d on top if you sort ascending-white,
and the black 7d on top if you do ascending-black. Maybe an OR search, put
all games on top which have white OR black 7d, next all white OR black 6d,
etc. And within each group ascending by white rank. Will give it some more
thoughts within the next days.


 > It'd be nice if you could spawn the kibitz off to a new window.
 > To maximize this beautiful board, I tend to zero the kib, only checking
 > it now and then.  So I miss much intelligent and wise commentary.

If you saw qGo (Q, not G. I know its confusing), my original project from
which gGo branched off, this has a feature to "rip" the comment/kibitz
textfield into a secondary window. This might be nifty for the Java version,
too. Good point.


 >I use the channel window a lot.  It would be nice to be able to
 > put blank lines into the display, so I can glance at it from a distance
 > and know if there's anything new there.  Color coding people would be
 > the cat's meow.

I tried to get the windows entry in the Windows taskbar flashing when you
don't have the channel window focused to indicate something was going on,
but that didn't work well. I suppose too Windoze-specific. And I wouldn't
know how to indicate this on the various Linux windowsmanagers or OS X
(which I don't even have myself).
One possible solution would be to use the Tabbed-mode for the IGS window,
then the tabs flash when something happens, although that means giving up
the individual windows and get all cluttered within one window. This is
probably mostly liked by Windows users as it fits Windows GUI design more, I
personally prefer the multiple windows approach which is more unix'ish.

However, allowing a return on an empty-input-line which would result in an
empty line added should be no problem.

Color coding... not possible with the simple text field I'm using in all
displays, but there is a rich text textarea class in Java, I will have a
look at it.


 > It'd be nice to direct all human comm to the same window and
 > force the use of igs native commands to direct it.  You'd really need
 > color here.  I would add this as an option, rather than a replacement.
 > I'm sure there are many who don't mind occasionally divulging sensitive
 > something in the wrong window now and then.

I suppose this is a matter of taste. My approach for the GUI design was to
redirect "classes" of IGS output to multiple windows, as I hate getting all
the output cluttered in one telnet-like display. So shouts go to the shouts
window, chats to the chatter window, etc. I suppose not everyone might like
it that way, but so far it was done intentionally as I personally prefer
this approach. One can already redirect shouts to the terminal, maybe this
could include channels, too. A slight problem would be, if you input a
command like "yell foobar", the display is echoed (a fake echo, because IGS
doesnt echo it) in the special window, not the terminal, so this would
demand a lot of Ifs and checks in the display distribution. Sounds like mess.
Well, unlike the above ideas which I like, this one I don't like so much, I
must admit.


 > Alternatively, at the IGS window type "trail <player>" and you
automatically observe all games by <player>. There's a slight bug that means
you get two windows when you play someone you're trailing, but it's not fatal.

Funny bug. :) gGo does check to prevent multiple windows opening, one for
"trail" and one for a reloaded game, for example. I am pretty sure own games
are not covered by this check, so you should indeed get a dead "observe"
board here, which doesnt observe anything.


 > I use the channels a great deal too. Other useful functionality might be a
"trail all members of this channel" and "trail all my friends" buttons and
cleaning up the channel list output so it's not echoed in the IGS window.

I personally think that is a little overkill.

However, what I did have in mind is to add another group to the
friends/ignore list: trail. This would basically just trigger a real "trail"
command on each login. IGS doesnt remember trailed players, so if you say
trail 10 people regulary, you need to restore that manually on every login.
This configuration would just start the "trail" command on login on a list
of people you define in the client. The IGS trail does the job well, so I
dont want to implement a client-side trail. However, if I can workaround the
non-persistant IGS trail and restore it properly, the same would be
achieved. The only slight problem here is the lack of an IGS command buffer.
On login gGo already sends a lot of commands, and each have to be delayed,
which is currently done manually and pretty ugly. So if you trail 20 people
(nuts, but possible), gGo will need to send each trail line with a delay, so
the complete trail setup of 20 players would require 20 seconds after login,
and during that time you should not do any other actions, but people usually
click right onward once the client started. This asks for some mess, I
suppose. Because of this I didn't implement the feature yet, as I still lack
a cool idea how to overcome the lack of IGS input buffer without telling the
user: "Busy with 20 queued trail commands. You cannot accept this match now."


 > Another useful feature might be that whenever there's any error detected
in the client/server communication any games being played issue a
refresh-board command to make sure that not moves have been lost.

The refresh feature from the boards Edit menu needs some cleanup anyways. In
own games it doesn't restore the turn properly yet. This is somewhat on my
urgent-TODO-list.


 > I've just noticed that the mouse wheel steps backwards and forwards in
games. Very cool.

Yes, one of my personal favourite features. I use it a lot. :) Actually, an
old feature. Available since the first release.


 > My "cat's meow" feature would have to be the ability to set up a board so
that it continuosly observed the highest ranking game begin played on the
server. Make an _ideal_ screen saver.

Something similar was discussed some weeks ago. A sort of "my personal
observe setup", which would pick a random game of a specified group, like:
5d-7d, highest possible, no handicap, 6-10 byoyomi time. So you could
configure a filter, and then all games (or only one at a time) would be
observed that match the filter.
Sounds cool, but currently not too urgent.

My personal cats meow would be the possibilty to create game collection
databases with a kombilo-like pattern search. :) But urgh, that's another game.


  Peter

Other related posts: