[helene_t]

fred, on Jul 26 2007, 06:15 PM, said:

5) It will be much easier for us to work with 3rd party programmers to develop modules that can be integrated into BBO.

Interesting. Like we now have a group of volunteers maintaining standard FD files, just a broader scope? What kind of kits would I need to make plug-ins for BBO? JavaBeans? Applets? Corba? Or is it some Flash-thing?

[jillybean]

I like BBO just the way it is, I just want to play bridge. However, I am sure the changes will be great.
These events sound like a lot of fun, not to mention great bridge. I am looking forward to one day being able to attend and not just watch on VuG and read about it afterwards.

Moreover, Fred you are a remarkable guy, not everyone could find something kind to say to Limey.

[fred]

helene_t, on Jul 27 2007, 10:20 AM, said:

fred, on Jul 26 2007, 06:15 PM, said:

5) It will be much easier for us to work with 3rd party programmers to develop modules that can be integrated into BBO.

Interesting. Like we now have a group of volunteers maintaining standard FD files, just a broader scope? What kind of kits would I need to make plug-ins for BBO? JavaBeans? Applets? Corba? Or is it some Flash-thing?

Some Flash-thing would be best.

Good that you bring up the subject of convention cards since this is a perfect example of what I was referring to. The new BBO does not have a convention card facility yet and I have to admit that this is one part of the program that I am not exactly eager or interested in writing myself. Perhaps we will hire someone to do this for us or perhaps we will have a contest in which developers are invited to create a convention card facility for us (with the winner being paid for their efforts).

If any programmers out there think they might be interested in getting involved in this sort of thing, I suggest they look into something called Flex (by Adobe). Please don't spend too much time on this right now - I am not in a position to promise that we will actually be willing to do something like what I described in the paragraph above.

Those of you who are looking for powerful new functionality may be disappointed with what we are working on. The new BBO is not geared toward "power users". It is meant for the much, much larger population of people who lack strong computer skills and basically just want to play online bridge.

Forums regulars are typically long time BBO members who have strong computer skills so some of you may find the following hard to believe, but we know it is true:

There are many people out there who have great difficulty getting started on BBO and never really become comfortable using our software. They find our site to be overwhelming. These are the people we are trying to reach with the new BBO.

Eventually I suspect that almost all of the functionality that exists in the current BBO client will be available in the new BBO. No doubt we (and you!) will think of cool new functions and features that we will eventually support as well.

But that is not our main priority right now.

Sorry in advance if you are disappointed in the direction we are heading, but I hope you can at least sympathize with our reasoning.

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[hrothgar]

fred, on Jul 27 2007, 08:22 PM, said:

Some Flash-thing would be best.

Good that you bring up the subject of convention cards since this is a perfect example of what I was referring to. The new BBO does not have a convention card facility yet and I have to admit that this is one part of the program that I am not exactly eager or interested in writing myself. Perhaps we will hire someone to do this for us or perhaps we will have a contest in which developers are invited to create a convention card facility for us (with the winner being paid for their efforts).

Hi Fred:

This sounds somewhat intriguing. There’s a very real chance that I might be able to convince a couple friends to work on a project to try to “solve” the whole Convention Card issue once and for all. I suspect that the most important factor in convincing folks to sign up will be the quality of the interface to the rest of the BBO code. Making it easy for a developer to add new features/functions will mean a lot more than the compensation model. Seeing a product used/enjoyed by hundreds of thousands of people often means more than a few dineros...

With this said and done, I’d appreciate a bit of guidance regarding where you see the product going in the long term. Personally, I think that it would be suicidal to try to support two different BBO GUIs for any length of time. With luck, even the “power Users” will see real value in the new GUI and accept it as a platform for future development. In turn, this would allow you to deprecate the existing interface that we all know and love.

[pbleighton]

Quote

Those of you who are looking for powerful new functionality may be disappointed with what we are working on. The new BBO is not geared toward "power users". It is meant for the much, much larger population of people who lack strong computer skills and basically just want to play online bridge.

Speaking as a software professional and a BBO regular, I have to say that this is a smart move.

One word of advice: try as hard as you can to minimize takeaways. In my experience, if you give users 10 things they have been asking for and take away two, they notice the two

Quote

Personally, I think that it would be suicidal to try to support two different BBO GUIs for any length of time.

I agree completely.

Peter

[pclayton]

Kibbed the Spingold - so was about an hour late for the reception. Met a few of you - not as many as I would have liked.

[cherdano]

If I understand correctly that the new BBO will be based on Flash, I very much hope it is more responsive than all other Flash applications I have used so far.

(And personally I hope that either a Flash version old enough to run on Linux is used, or the old client is supported long enough until Linux Flash support has caught up.)

[fred]

cherdano, on Jul 28 2007, 01:19 AM, said:

If I understand correctly that the new BBO will be based on Flash, I very much hope it is more responsive than all other Flash applications I have used so far.

(And personally I hope that either a Flash version old enough to run on Linux is used, or the old client is supported long enough until Linux Flash support has caught up.)

I would guess that people will be able to use the existing Windows client for at least another year. It is not unlikely that we will let people use it "forever" if they want.

Currently we are not planning on making any major improvements to the Windows client, but if any serious bugs are found we will have to fix them.

Maintaining 2 clients is not going to be much fun (as other posters have pointed out), but since the Windows client is relatively stable and since we are not planning on changing it, I don't think it will be that big a deal.

I am not concerned about performance issues with the Flash client.

But very little of anything I have posted about in this thread is written is stone. We are entering a whole new world here and there are still a lot of things we are unsure of.

One thing is for sure: the Flash client will require version 9 of Flash.

Another thing that is almost for sure: we are not going to leave Linux people with no way to log in to BBO so don't worry about that.

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[cherdano]

Thanks for the reply, Fred (and it was great to meet you, I am sure you don't mind me saying that any forum regular who hasn't met Fred should go and say hi when he/she is at the same tournament as you).

Btw, contrary to what Helene said above, there is a an Adober Flashplayer 9 for Linux since January, so this isn't even an issue now.

[hrothgar]

Hi Fred

Quick question about the new client:

I was curious whether the new Flash based client will still leverage any kind of embedded browser? I'm not sure whether it makes sense to try to design a "one size fits all" convention card.

As an obvious example, the ACBL might very much want its convention card to look identical to the ones used for face-to-face play in ACBL events while the EBU would prefer something very different.

In an ideal world, it would be great if there was a standardized interface describing how a third party could specify a convention card. You could then push responsibility for developing and maintaining said cards onto the Sponsoring Orgs. My guess is that this might fly a bit easier if the the language used was something simple like HTML rather than some kind of Flash object.

[fred]

hrothgar, on Jul 31 2007, 04:26 PM, said:

Hi Fred

Quick question about the new client:

I was curious whether the new Flash based client will still leverage any kind of embedded browser? I'm not sure whether it makes sense to try to design a "one size fits all" convention card.

As an obvious example, the ACBL might very much want its convention card to look identical to the ones used for face-to-face play in ACBL events while the EBU would prefer something very different.

In an ideal world, it would be great if there was a standardized interface describing how a third party could specify a convention card. You could then push responsibility for developing and maintaining said cards onto the Sponsoring Orgs. My guess is that this might fly a bit easier if the the language used was something simple like HTML rather than some kind of Flash object.

Thanks for your interest in this, Richard.

Flash currently contains a primitive html control, but it is not really powerful enough to be useful (it only supports a small subset of html). Rumor has it that future versions of Flash will better in this regard.

It is possible to spawn a new browser window in response to a click from the user, but most popup blockers will get in the way if you try to do this without a click.

I agree that it would be attractive for various sponsoring organizations if they had a relatively easy way to support a convention card that looked like their real convention cards. But of course there is also a need for a generic BBO convention card that will be used by default.

In my view it is more important to have an effective generic convention card than it is to be able to support lots of different types of convention cards.

My personal opinion is that the FD concept is a good one - automatically providing explanations of bids is extremely powerful. Unfortunately the FD application itself is not very good (sorry). In order for this sort of facility to become useful for average players with average computer skills, either the editor would have to be greatly simplified and improved or a lot of "macros" would have to be created (or likely both).

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[hrothgar]

fred, on Jul 31 2007, 08:52 PM, said:

My personal opinion is that the FD concept is a good one - automatically providing explanations of bids is extremely powerful. Unfortunately the FD application itself is not very good (sorry). In order for this sort of facility to become useful for average players with average computer skills, either the editor would have to be greatly simplified and improved or a lot of "macros" would have to be created (or likely both).

Personally, I would love to see a system in which the Convention Card editor was able to dynamically create an FD file. End users would start by choosing any one of a number default systems. They could then customize the system by enabling or disabling different modules using radio buttons or drag down menus or what have you.

For example, lets assume that I started with a Convention Card for a standard 2/1 type system. If I enable Bergen Raises in the "Major Suit Opening" section of the Convention Card, this would automatically load a Bergen Raise module into the FD file.

As I envision matters, the CC system should be designed to provide a simple visual summary of the system and also serve as an editor. The FD system should sit in the background and provide alerts and announcements.

Unfortunately, this would require a fair amount of work to segment bidding systems into different modules and make sure that they don't stomp all over one another. However, I don't see any good ways to avoid this.

[hotShot]

If there where an application that would be able to convert a convention card with convention list into a complete FD-file, if would be much better to bypass the FD file, because a CC with convention list will be much smaller than a full FD-file.
The main problem with the FD-data approach is that you need an entry for every bidding sequence (and against any system). This means an incredible big number of entries. To solve this you need a rule/macro based approach, where the actual sequence needed is generated from the rules defined.
If someone can make that, the bridge world will have a great bidding engine as a bonus.

[jtfanclub]

hotShot, on Jul 31 2007, 04:19 PM, said:

If someone can make that, the bridge world will have a great bidding engine as a bonus.

It does seem like, even now, if you have a FD card filled out, GIB ought to be able to play it. I wonder how much work *that* would be.

Probably more than I can imagine.

[DrTodd13]

I don't think the convert CC to FD discussion is going to be fruitful. They have different purposes. The former provides an overview. The latter provides system documentation that can auto-alert in some cases. Even less fruitful would be trying to get GIB to play based on current format FD files. Believe it or not, FD is massively UNDERSPECIFIED. The textual description portion of FD is totally ungrokable by GIB. So, CC is least specified, FD is more specified but still a long way from a complete specification which is what you would need for GIB to play a completely different system. All bids in competition depend on the meaning of those bids and FD is hopelessly incompetent here. I'm not down on FD (except that you can't alert an opening pass!!!). It is a reasonable tradeoff point in the simplicity versus complexity continuum.

I spent several weeks trying to figure out how to do a complete specification including competitive bidding. I know that I didn't solve the problem but I do know that the solution is more complex than my most complex attempt at a solution and that no one would want to specify their system using even this incomplete solution. Just look at Meckwell's notes. Look at the number of possible bidding sequences. How many of these do they document? Even by relating different sequences to each other, I doubt they cover even 1%? Yet still their notes are 800+ pages.

[Ant590]

Hi,

When I operated the vugraph in the EBU Spring 4's one pair had their FD file on a disc and gave it to me before we began. I thought this was a great idea (and it was most useful for the commentators as they were playing a strong club-relay system); I think it would be a shame to phase out the ability to have some kind of FD in place.

Flash is great news, I must admit that BBO is one of the few programs keeping me from completely moving to my Mac (which is too old for the fancy dual-booting stuff etc).

The worrying thing that you mentioned Fred was the ability for people to log in anomalously. This strikes me as an issue in a few areas, specifically
1) cases of abuse,
2) harder for new players to establish a presence on BBO- I for one don't allow any Private profiles to my table and therefore new members who don't think it is usual to have a profile are likely to be faced with many rejections initially which may be unhelpful.

But hurrah in general

[jtfanclub]

DrTodd13, on Jul 31 2007, 05:08 PM, said:

So, CC is least specified, FD is more specified but still a long way from a complete specification which is what you would need for GIB to play a completely different system. All bids in competition depend on the meaning of those bids and FD is hopelessly incompetent here.

I'm not real impressed by GIB's handling of these, which is often in conflict with the text, deciding that a passed hand has an 18 count, etc. etc.

[keylime]

Something else to consider for why I think a FD to CC conversion would struggle: if you play a method that is undergoing evolution, you could in theory cause a conflict when it "emulates" for lack of a better word from one source to the other - especially if there's oddball/non-standard conventions that a pair would use.

Admittedly the thought I had was to use a different mechanism to provide the desired convention card: a Word template that would be easy enough for users to plug away at and yet provide enough customizations for the advanced coders and crowd to modify for their using. Since Office 03/07 and OpenOffice are out there, might be the easiest route to implement in terms of cost and deployment. Any oddball conventions can appear then as a pop-up or an appendix to the opponents. I'm not a programmer by trade; am a hardware guy so this is just a thought (i.e. don't shoot me down too hard please).

[chicken]

however it would be a pitty if the zillions of hours bbo members spent on creating fd-files cant be transfered to the new client.