Potential for UI

[Echognome]

I'm not sure if this is the right forum or if it is even a problem, but wanted to bring the topic up in case anyone else has had the same concern.

 

As we alert our own bids (and I am quite religious about doing it), opponents can still click on one of our bids to ask for a follow up explanation even if we have properly alerted. Furthermore, opponents can click on a natural bid and ask for an explanation even though it has (properly) not been alerted.

 

Now, suppose South is playing a contract and West is to lead. I've had people click on my bids before the lead both when I'm dummy and when I'm declarer. I feel this is ripe for UI problems. If I am East and want a suit lead that was bid by dummy, I can just click on that bid and ask for another explanation. If I am West I can click on one of declarer's bids to indicate wanting a return of that suit. Thus, I think the software should not allow any further questions of bids before the lead is faced. (I understand the difficulty of this as normally one could explain the entire auction after the lead has been faced in face-to-face bridge.)

 

Alternatively, should I just cancel any requests for further explanations and if I do, will it "pop up" with the same explanation?

 

Not really sure what should be done. But I find it disturbing when I face opponents that constantly repeat questions on bids that I have properly alerted or those that I have not.

[mrdct]

Very good point! I've noticed this behaviour myself.

 

Perhaps the updated explanation should only reveal itself to the person who asked and if the other person asks about the same bid a delay commensurate with the length of the response should be inserted by the system - that way a secondary question asker wont get the UI that his partner has already asked.

[mrdct]

A further thought is having an option to play either a teams match or in the main bridge club as if screens were in use with the following features:

 

- a screen is diagramatically represented across the table;

- players can only communicate with their screenmate (SW & NE);

- bids are revealed to the players on each side of the screen simulataneously (two bids at a time);

- North and South choose the tempo of when they want to send the virtual bidding tray to the other side of the screen;

- players alert their own bids and their partner's bids to their screenmate;

- players describe their own bids and their partner's bids to their screenmate;

- at the end of the hand, the system will reveal which bids were alerted and by whom and show the explanations (some of which may be inconsistent).

 

Having such a mode of play would closely replicate actual conditions in major tournaments and would be a great experience for players aspiring to play at that level.

 

About 18 months ago my local bridge club bought 8 screens so that we could use screens in the finals of our major club events and in selection events. By doing this virtually all of our "serious" tournament players get a chance to play with screens at least a few times every year and wont be intimidated if and when they come up against screens at major national or international events.

[extrasolid]

A further thought is having an option to play either a teams match or in the main bridge club as if screens were in use

:D

 

A very nice idea! Looks complicated, but very nice.

[Echognome]

I think the screen idea would be fantastic. However, perhaps it could be an option on a table. You could make a 'screen table' or a 'regular table'. It would also be good for people that are not used to screens to learn how they work.

 

Another option to help witth the UI is for the opening leader to make his lead and the card shows up face down on the table. An 'any questions?' dialog then goes to his partner and the partner will have to click 'NO' before the card is turned over and play commences. Unlike other suggestions (e.g. ones to avoid miscclicks), this adds one extra click to each hand.

[fred]

You make a good case for changing the way we handle this. Thanks.

 

Unfortunately this would be relatively hard to implement given the way that the software is currently designed. I will give it some more thought and, if I can find an easy way to change this, try to do so before too long.

 

I am going to be travelling to a lot of tournaments in the near future which will greatly limit the time I have for development work. Also, Uday and I have put the "scaling" issue on hold for a month or so, but we really have to return to that and make it our number 1 priority.

 

As such, the recent spurt of new features may be about to end for a couple of months (or at least to slow down significantly).

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com