[dcrc2]

Many otherwise-excellent Vugraph presentations are spoilt by having a bad internet connection at the venue. I realise that the main responsibility is on the event organisers to ensure a good connection is available, and if the connection is sufficiently bad there is nothing you can do. However, it seems to me that the BBO software makes this problem much worse than it ought to be.

The standard Windows client used by Vugraph operators is very unforgiving to intermittent connections. In particular, if your connection drops you are unable to continue playing cards, and eventually you are expelled from the table. That makes perfect sense for playing in the main bridge club, where the table needs to "move on" if one of its players disappears; but it doesn't make sense for a Vugraph operator, where you are the table.

My suggestion is a separate client designed purely for use by Vugraph operators. The key feature would be the ability to enter bids and plays irrespective of whether your connection was currently alive. Then the relevant messages would be sent to the server as and when a connection could be made. Obviously the operator would still have to be notified when the connection drops, but not in such a way as to prevent him from following the play.

The server should also not close the table as soon as it loses connection to the operator, but wait until either the connection returns or the broadcast is manually aborted. The current situation, where all of the kibitzers are chucked out when the operator's connection dies, is really unfortunate. Ideally, send a message to the table, like "The operator has lost connection". Much better if the commentators can continue to talk, even if they know there is a problem, rather than everyone being kicked out and having to come back in again.

I would imagine that this can all be done without affecting the existing clients. From the current client's point of view, a Vugraph operator would still appear to be a normal Yellow user, but in fact this just be a proxy created by the server. Obviously I appreciate there would be substantial work involved in creating a new client, and the new protocol it would use, but since it only needs to perform a single function it would be much less work than creating a complete reimplementation of BBO.

A separate client for Vugraph operators would have other benefits:

- A simpler interface, so that the operator can be presented with the options for starting a broadcast directly, rather than having to navigate through the existing client. Amongst other things, this would help to make restarting quicker in case of problems. The fact that you use the same UI for playing bridge as for running Vugraph broadcasts makes many things a little counterintuitive at the moment (like the way you use "redeal" to start a new board).

- Ability to add new functionality that would be useful to operators. For example, being able to make corrections to calls in an auction without having to "undo" all the way back to the relevant place. e.g. to insert the pass that you forgot right back at the start. (The server could easily translate this into the series of undos and replacements needed for the existing clients.)

- Currently (or at least, when I last did it) operators are still using the old Windows client which is not being updated. A dedicated client for operators would allow for future updates to improve Vugraph, without having to roll out a new version of the old client.

[fred]

Thanks for this thoughtful post.

Allowing vugraph operators to use the web-client is on our list of things to do, but this list is unfortunately quite long and the specific item in question is not currently something we consider to be a very high priority (at least compared to some of the other items on the list).

When the time comes for us to do this, I have no doubt that we will make a serious attempt to improve things for the operator (and for the audience) versus how things currently work with the Windows client. You make some excellent suggestions along these lines.

Until that time comes, all I can really suggest is that tournament organizers interested in broadcasting vugraph pay close attention to two specific suggestions we make in the documentation we send them:

1) That they make sure in advance that reliable connections will be available at the playing site
2) That they make sure in advance that all operators are familiar with the vugraph-related aspects of our software

Taking these steps (which I understand are not always as simple as they sound) will lead to vugraph broadcasts that generally run smoothly. Eventually we will help in this regard by improving the software itself, but that might not happen for a while.

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com