slior

In the current web client (flash app) kibitzing a single hand is selected through "Options -> More options -> Advanced Options". But generally speaking "options" refers to permanent selections like the font sizes, sound and so on. I don't think a transient selection like which player to Kibitz should go there. I'm not sure how difficult it would be, but I'd like to propose moving this option to the subwindow you get when clicking on the player at the table (showing their identity, convention cards, etc). It would also be great if you could incorporate the functionality in the mobile app.

Just received the update -- thanks for removing the requirement for the "networks connections" permission on Android, and for restoring the chat button for kibtizers!

Agree: for my use case (mostly kibitzing tables watching VuGraph), the bar offers nothing (would never use any of the buttons) and takes screen space while chat is very useful.

Confirmed: on Nexus 6P running Android 6.0.1, asked for three permissions: 1. File access 2. Camera access 3. View WiFi connections (connection status, identity of connected devices) I don't see why you need to be able to know access point names or what devices are tethered to my phone. You probably never try to access that information.

Version 4.0.1 (Android) wanted both camera permission and permission to see all the WiFi connections. I'll try removing and installing to see what permissions are asked for that way.

The web client (and the old PC executable) allow kibitzing a single player rather than a while table. The UI isn't great (it's in the "advanced" tab of "more options" despite not being a global option) but it works. I haven't found the equivalent feature in the mobile app. So I have two suggestions: 1. Move the option to the user box you get when clicking on the name of a player in the table. 2. Add the feature to the android app.

That's roughly what I had in mind. However, I now see that with the current architecture this idea makes no sense. The kind of "option" I'm proposing needs to be stored locally on the device and accessed before login (otherwise, how would the app know if the option is set?), but currently the only suported options are user-dependent options that are stored on the server and are hence only accessible after login. So, implementing this idea would require changing the home screen (add a checkbox for the "direct login" option), which I'm not sure you want to do.

I'm not proposing extra login button but rather an extra checkbox in the options dialogue.

Love the app [runs well on a Galaxy Nexus with Android 4.0.1]. One suggestion: most of us have a single userid which we always use. In particular, even those who share desktop machines rarely share mobile devices. It would therefore be nice to have an option so that clicking "Log in to BBO" will just use the stored credential without asking for confirmation. I think this option would make sense for the flash client as well, but for some reason I don't mind the extra click as much there.

6.5 years later, the file is not there anymore. I've been looking for the BB Basic online notes for a while before finding this post -- could you find a permanent home for the notes?

If this works we're in good shape. How well is the distribution of hand results in this club approximated by the statistical distribution from the underlying model given the players' ratings?

I think that developing a rating system for bridge requires considerable research. Apologies for the technical language that follows, but you cannot really discuss the technical merits of a rating system without some mathematical language. I don't have anything to say about social and business questions such as whether BBO should have a rating system, whether some games should be rated and others unrated and so on. The post above game the numerical calculations involved in running a rating system, but omitted the heart of the system -- that mathematical model that leads to these calculation. The basic model for chess, proposed by Arpad Elo, is the following: 1. We assume that every player has a current "average ability level" (this is the number that the rating system will be trying to measure). In any individual game, the player will play at an ability level which is randomly distributed around his "average" level, and the winner of the game is the player who happened to display a higher level during that game. 2. The key assumption (to be discussed below): the distribution of abilities around the average is normal (Gaussian), with a standard deviation of 200 rating points. 3. Say we have two players with true abilities r_1, r_2. We can calculate the probability that player 1 will beat player 2 (that's the probability that a random sample from N(r_1,200) is larger than a random sample from N(r_2,200)). This is the "expected result of the game". Now assume that r_1 and r_2 were only the ratings associated to the players instead of their true abilities. We can still compare the calculated probability to the actual result of the game (player 1 can score 0,0.5, or 1 point). If player 1 did better than expected, we infer that we underestimated r_1 and overestimated r_2, and make a small adjustment to the ratings accordingly (dlbalt's post above explains how this is done). Conversely if player 1 did worse than expected. 4. Mathematical fact: If assumption 2 is valid, then then o a long series of games the ratings of all players will converge to their true ability levels. The main weakness of this model is the fixed standard deviation of 200 points. If all players of a given level had the same standard deviation, this would simply serve to fix the value of "1 rating point". In practice they don't quite. Another weakness is that an input to the rating update process is a measure of the "rating uncertainty" (if we are very confident that r_1 is close to player 1's ability, we want to only make a small change after the game; if we are unsure we want to make a large change), which affects the speed of convergence of the ratings to the true abilities. The original Elo system had a fixed value (later versions give players a higher uncertainty during their first games). Glicko's system improves on this in two ways. First, he modifies assumption 2 by assigning a different variance to each player (which the system will also try to measure). Second, we improve step 3 by assigning to every player a "ratings deviation" which more directly measures our uncertainty about his rating. The first change is fundamental (makes the model closer to reality) while the second is designed to improve the convergence properties). How does one test the system? Take a set of players and a large collection of games. Use the first part of the sample to calculate ratings as described above, using enough games for the ratings to converge. Then examine the remaining games to see whether the statistical model really predicts the results (i.e. whether the probability of winning is really given by the larger-of-two-Gaussian-samples model, and whether our model for the variance [either 200 points or per-player] agrees with reality). In chess this works to some extent -- see for example the papers by Mark Glickman. What about adapting this to bridge? Here are some thoughts: 1. Formally, one could simply look at each hand played separately (say looking at the points margin). Given enough time (hands), the ratings may converge. I think the general perception is that convergence here would be too slow, and that it's better to compare what player did with the same cards rather than compare NS to EW directly. Also probably different models are needed for team games (only one other table) and duplicate games (many other tables). 2. On the other hand, bridge has more detailed scoring information than just "win/draw/lose", which should help. It is not a-priori clear which component of the score best predicts future success. This much is for rating pairs. But what we really want is rating individuals, and this raises the last question: 3. Can players be assigned individual ratings which effectively predict the performance of pairs? The naive answer is that established partnerships perform much better than pick-up partnerships with the same ability, but I don't know of research into how large this effect actually is and (more importantly) to what extent it limits the accuracy of individual ratings in predicting results. To get a genuine answer we have to create a statistical rating model and then test it against actual data. Side thought: in trying to extract individual ability from pair data, it would be helpful to incorporate the identity of the declarer into the model (that is, probably the ability of declarer affects the result of the hand more than the ability of dummy), but since the identity of declarer is not simply a function of the cards I don't see an obvious way to do this. In summary: before we discuss whether BBO should have a rating system, it may be worth doing some statistical research and actually <i>validate</i> a rating system for bridge.

[details cut] Thanks for the details. Yes, please send a screenshot to fred@bridgebase.com when convenient. Do the menu items in question work properly despite the display problems? Fred Gitelman Bridge Base Inc. www.bridgebase.com Screenshot sent. The menu items work fine; the underlined letter even works as a keyboard shortcut.

Thanks for the bug report, but I can't replicate this problem in any of the 3 browsers I tried. What browser and operating system are you using? Fred Gitelman Bridge Base Inc. www.bridgebase.com * OS: Linux x86_64 (Fedora 12) * Browser: "Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.5.9-2.fc12 Firefox/3.5.9" * Flash: adobe flash player version 10,0,42,34 (64-bit) * BBO Client: version 1.36 according to "Help -> About BBO" The problem also occurs with the "Who's Online" side panel. I can send a screen dump if you want me to.

There's a bug with the context menu when right-clicking on usernames which contain underscores. In detail, when you write-click the name of a user in the chat window you get a menu, and the menu widget interprets underscores in menu entries as signifying keyboard shortcuts. However, some of the menu entries (such as "define [user] as friend") include the name of the user. The obvious thing now happens: right-clicking on a name like a_User will give the entry "define aUser as friend" (U underlined) instead of the expected "define a_User as friend".

Recompiled gnash but the outcome was negative anyway. I think not enough of SWF9 is implemented for this to work and we should try again in a few months. Thanks for helping in the attempt. Technical details follow. The system is an up-to-date x86-64 Fedora 12. The sources were gnash-0.8.6.tar.bz2 from the ftp site. I used the following flags. The first flag is supposed to enable what SWF9 support there is, and the others are basically arbirary choices (also, for some reason it couldn't find the cairo include directory automatically). configure --enable-avm2 --enable-renderer=agg --enable-media=ffmpeg --enable-gui=gtk --with-cairo-incl=/usr/include/cairo

Thanks for the responses. I'm trying gnash since 64-bit Fedora 12 ships with a version of firefox which crashes on contact with libflashplayer. I got Uday's message and am starting to test. First problem is that gnash support for SWF9 is not compiled in by default, so no chance with the gnash that comes with the distribution. Recompiling now ...

I wanted to see whether the flash client would run on gnash, a free implementation of flash. However, the current setup includes an explicit check for Adobe's flash player (see the calls to DetectFlashVer in http://www.bridgebase.com/client/client_v32/bbo.php?). Could you set up a page which simply embeds the SWF file with the right parameters, without checking for flash versions?

I don't know if it's a bug or a feature-request but suit symbols (!S,!H,!D,!C) don't work in the "describe claim" field in the flash client. Writing "you get !SA" produced that literal text, exclamation mark and all where I was hoping for "you get ♠A" like in chats and alerts.

Font issue (running Mozilla 1.5, adobe flash 9 on Linux): the suit symbols are not appearing in chats (they are replaced by blank spaces). Since I don't know how to debug flash myself, could someone tell me which font the application is requesting for displaying the suit symbols? Given that it should be no problem to set an alias.

Minor point: I moved from playing at a table (where I was chatting to "Table") to kibitzing a table where kibitzer couldn't chat to players. The arrow at the bottom left wasn't updated and so continued to read "-> Table". Chats correctly went to the other kibitzers though. Cheers, Lior

Report after short test of the current flash client (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061025 Firefox/1.5.0.8). 1. Basic interface works except that card animation is slow so I deselected that for now; perhaps this will be resolved later. 2. The ability to resize the window is great. 3. I'd like to second mghatiya's point: the "mouse hover" features of BBOWin are really nice. Each and every one of them speeds up my interaction with the client. They are certainly not essential -- I wouldn't have thought of them if they weren't there -- but you should keep them if at all possible. 4. The "BBO Now" menu is great. One issue: if you attempt to join the table you are currently kibitzing, you get the error message: "Error. could not join table." This happens both through "Interesting tables" and "all tables". Possible alternatives are: a more informative message ("Error. You are already kibitzing this table."), silent success (if the user is asking to join the table he's at, there's nothing to do), or the BBOWin behaviour (leave the table then rejoin it). 5. A problem with both BBOFlash & BBOWin: the default chat target for a kibitzer at a table should be the other kibitzers, not the whole table. Inadvertent chat to table is a very very common error. If non-players had to make an explicit click to chat to the table this problem would disappear. -- Aside: It's difficult for a flash application in a broswer to compete with stand-alone compiled code: BBOWin + Wine provides a faster, smoother experience. Of course it's not as portable. As a free-loader, all I can say is that I will test the flash client occasionally but would probably stay with the existing client under Wine until the future evolution of the client/server protocols breaks it. Cheers, Lior