[DJNeill]

Hi,
Not sure if this has been suggested, but currently if you click on an opponent's unalerted call in the bid box it will prompt the opponent to explain. This is good. If they alerted but did not explain, same thing. Also good. But if an explanation was attached to the call by the bidder already, it's just annoying the explainer who thinks they did type an explanation. Then it gets into a potential click-fight to see who can make the same thing happen as many times as possible (I won't explain again, tell me more, I won't explain again, tell me more).

Suggestion: if a call has been explained (something typed into the box when it was made, or even after it was made), that should stop any more prompts for explanations using this functionality (so, make the bid unclickable to the opponent, or have it just make the explanation appear again for them). If the opponent of the explainer wants more info on an explained call, they will have to chat the question.

Side note, a great coffeehousing technique, only on BBO would it work.

Thanks,
Dan

[pescetom]

This problem has been discussed to death, but BBO seems unwilling to fix it. What causes the click fights is not (just) the ambiguity of whether opponent is asking for more information (and what information?) but the non- intuitive choice of dismiss/ask mechanisms: as currently implemented, to get rid of the box one should not press the only button (which actually causes a new request instead) but click on the text or the border. This is counterintuitive and leads frequently to click fights unwanted by both parties. The solution is obvious: implement a conventional Dismiss button (an X in top right corner, or similar) and make clicking on text open up a chat.

[johnu]

pescetom, on 2021-December-13, 06:55, said:

This problem has been discussed to death, but BBO seems unwilling to fix it.

In defense of BBO, this has only been a problem for 20 years. Give them a few more years.

[smerriman]

johnu, on 2021-December-13, 20:04, said:

In defense of BBO, this has only been a problem for 20 years. Give them a few more years.

Actually, it's new to the HTML5 version. Was never an issue with Flash, as there were no hovers / taps involved.

[sfi]

smerriman, on 2021-December-13, 20:56, said:

Actually, it's new to the HTML5 version. Was never an issue with Flash, as there were no hovers / taps involved.

It only seems like 20 years...

[johnu]

smerriman, on 2021-December-13, 20:56, said:

Actually, it's new to the HTML5 version. Was never an issue with Flash, as there were no hovers / taps involved.

I started heard a rumor that once BBO increases their pay games by another 25% they'll have the resources to make this fix.

[DJNeill]

smerriman, on 2021-December-13, 20:56, said:

Actually, it's new to the HTML5 version. Was never an issue with Flash, as there were no hovers / taps involved.

Yes I looked back 2 years in this sub-forum and it doesn't seem anyone has mentioned this specifically, more about the location of the popup rather than the fact it pops up at all like here. It seems so easy to fix.

But as working in QA, I like the conservatism. If current BBO is a maintenance product (devoting resources elsewhere more important, just make sure it doesn't catch fire), this is good to only respond to the biggest fires. If you change something, however minor, it's a risk something else will break. I don't think there is a lot of automation testing in a complex GUI product (there could be, but it's difficult to maintain), with lots of unforeseen ways for a small change to have an effect. With hundreds of thousands of users, and lots of money coming in every minute, even a short problem could cost so much money. It would take a lot of testing by someone manually to ensure the change would be safe. Uday and co. have more important stuff to work on.

[pescetom]

As a former SW integration and QA manager, I think that position is misguided. Fixing bugs, regressions and significant limitations in your current mainstream product is the surest way to obtain customer satisfaction and remain profitable. Not fixing them is a sure way to drive away new customers. Sure, testing this fix professionally is a lot more work than a layman might imagine, but that's what QA is there for.

BTW, here are some other threads about the same problem, off the top of my search box, not an exhaustive list:

link 1

link 2

link 3

[DJNeill]

I will QA this issue for free if BBO would provide the resources, and I could document the testing. Tom, you can review the work. BBO risks nothing and gets customer satisfaction. Win-win-win?