BEeS, Part 2

Old college threads.
Locked
User avatar
Alejandro
Wakka
Posts: 165
Joined: Mon Jul 10, 2006 8:39 pm
Location: Redmond, WA

BEeS, Part 2

Post by Alejandro » Sun Mar 21, 2010 5:50 am

I am happy to announce that the development of BEeS, a program that helps organize and run tournaments, should begin this summer.

In order to make BEeS as useful as possible, I will be holding a requirements gathering meeting this Monday at 4 PM PST. The purpose of this meeting is to find out what features you would like in this program as well as to figure out in which cases having a program automatically perform a task would be useful during a tournament. The meeting will be held on IRC on the SlashNET server (If you have an IRC client, connect to irc.slashnet.org) on the channel #beesqb.

If you have any suggestions or questions, feel free to post them here.
Alejandro
Naperville Central '07
Harvey Mudd '11
University of Washington '17

User avatar
dtaylor4
Auron
Posts: 3733
Joined: Tue Nov 16, 2004 11:43 am

Re: BEeS, Part 2

Post by dtaylor4 » Sun Mar 21, 2010 3:01 pm

I will state one of the biggest issues right here:

I must not require an internet connection to have full capabilities. Yes, many hosts will have wireless access, but from experience I can tell you this is not always the case.

User avatar
grapesmoker
Sin
Posts: 6364
Joined: Sat Oct 25, 2003 5:23 pm
Location: NYC
Contact:

Re: BEeS, Part 2

Post by grapesmoker » Sun Mar 21, 2010 3:44 pm

dtaylor4 wrote:I will state one of the biggest issues right here:

I must not require an internet connection to have full capabilities. Yes, many hosts will have wireless access, but from experience I can tell you this is not always the case.
I disagree. The problem of internet access at most universities has been solved. If you don't have reliable internet access, you already have a method of doing stats that doesn't need it: scoresheets and SQBS. I think a new system like this should utilize all the advantages of currently available technology. That way, if reliable internet access is available, it can be used, and if not, you can always just revert to SQBS.
Jerry Vinokurov
ex-LJHS, ex-Berkeley, ex-Brown, sorta-ex-CMU
code ape, loud voice, general nuissance

User avatar
dtaylor4
Auron
Posts: 3733
Joined: Tue Nov 16, 2004 11:43 am

Re: BEeS, Part 2

Post by dtaylor4 » Sun Mar 21, 2010 3:47 pm

grapesmoker wrote:
dtaylor4 wrote:I will state one of the biggest issues right here:

I must not require an internet connection to have full capabilities. Yes, many hosts will have wireless access, but from experience I can tell you this is not always the case.
I disagree. The problem of internet access at most universities has been solved. If you don't have reliable internet access, you already have a method of doing stats that doesn't need it: scoresheets and SQBS. I think a new system like this should utilize all the advantages of currently available technology. That way, if reliable internet access is available, it can be used, and if not, you can always just revert to SQBS.
Right. I'm saying that I'd stick with SQBS. If this has the versatility to switch without making it cumbersome, I'd consider using it.

User avatar
grapesmoker
Sin
Posts: 6364
Joined: Sat Oct 25, 2003 5:23 pm
Location: NYC
Contact:

Re: BEeS, Part 2

Post by grapesmoker » Sun Mar 21, 2010 3:52 pm

dtaylor4 wrote:Right. I'm saying that I'd stick with SQBS. If this has the versatility to switch without making it cumbersome, I'd consider using it.
Ah, ok. I think any realistic system that's more advanced than SQBS is going to have to use some kind of online interface in order to be properly scalable. Alejandro is probably a better programmer than I am, so if he disagrees he's likely to be right, but my vision for such a system would be a web-based interface to a centralized database. If you start breaking this system into constituent parts so that it can be done offline, it might become unmanageable.
Jerry Vinokurov
ex-LJHS, ex-Berkeley, ex-Brown, sorta-ex-CMU
code ape, loud voice, general nuissance

Charbroil
Auron
Posts: 1141
Joined: Fri Jun 09, 2006 11:52 am
Location: St. Charles, MO

Re: BEeS, Part 2

Post by Charbroil » Sun Mar 21, 2010 3:53 pm

grapesmoker wrote: I disagree. The problem of internet access at most universities has been solved.
That might be true, but what about high schools hosting tournaments that would like to use this software?
Charles Hang
Francis Howell Central '09
St. Charles Community College '14
Washington University in St. Louis '19 (President, 2017-19)

Owner, Olympia Academic Competition Questions, LLC
Question Writer, National Academic Quiz Tournaments, LLC and National History Bee and Bowl

User avatar
BGSO
Tidus
Posts: 685
Joined: Sat Aug 11, 2007 12:36 pm
Location: Champaign-Urbana and Arlington heights IL
Contact:

Re: BEeS, Part 2

Post by BGSO » Sun Mar 21, 2010 4:00 pm

Charbroil wrote:
grapesmoker wrote: I disagree. The problem of internet access at most universities has been solved.
That might be true, but what about high schools hosting tournaments that would like to use this software?
Now my knowledge of this is nil but how hard would it be to be able to put the data from a match onto a flash drive and then run it to a central computer? That seems like a very minimal and easy way to solve an internetless.
David Garb-
Buffalo Grove High School '09
UIUC-'13

Former member of the most dysfunctional scholastic bowl team in Illinois.
(11:23:30 PM) garb: Wait, are you talking about the porn or the reeses?

User avatar
grapesmoker
Sin
Posts: 6364
Joined: Sat Oct 25, 2003 5:23 pm
Location: NYC
Contact:

Re: BEeS, Part 2

Post by grapesmoker » Sun Mar 21, 2010 4:06 pm

BGSO wrote:
Charbroil wrote:
grapesmoker wrote: I disagree. The problem of internet access at most universities has been solved.
That might be true, but what about high schools hosting tournaments that would like to use this software?
Now my knowledge of this is nil but how hard would it be to be able to put the data from a match onto a flash drive and then run it to a central computer? That seems like a very minimal and easy way to solve an internetless.
Again, I don't want to speak for Alejandro, since this is obviously his project and I'm only an observer. However, I think that we can already do the things you guys are talking about. The idea should obviously not be to repeat the model of SQBS, which already works fine and is centralized. The idea should be to use the maximum available resources to do something that SQBS cannot do, and that means that the possibility that some high schools might not be able to use this system for whatever reason should not be used to limit this system's potential, since anyone who cannot use it can always use SQBS.
Jerry Vinokurov
ex-LJHS, ex-Berkeley, ex-Brown, sorta-ex-CMU
code ape, loud voice, general nuissance

User avatar
theMoMA
Forums Staff: Administrator
Posts: 5652
Joined: Mon Oct 23, 2006 2:00 am

Re: BEeS, Part 2

Post by theMoMA » Sun Mar 21, 2010 4:12 pm

I'm really happy that Alejandro has decided to work on this project. I will be at the meeting tomorrow as well to address any questions that people may have about the program that I can answer.
Andrew Hart
Minnesota alum

User avatar
Mechanical Beasts
Banned Cheater
Posts: 5673
Joined: Thu Jun 08, 2006 10:50 pm

Re: BEeS, Part 2

Post by Mechanical Beasts » Sun Mar 21, 2010 5:25 pm

grapesmoker wrote:
BGSO wrote:
Charbroil wrote:
grapesmoker wrote: I disagree. The problem of internet access at most universities has been solved.
That might be true, but what about high schools hosting tournaments that would like to use this software?
Now my knowledge of this is nil but how hard would it be to be able to put the data from a match onto a flash drive and then run it to a central computer? That seems like a very minimal and easy way to solve an internetless.
Again, I don't want to speak for Alejandro, since this is obviously his project and I'm only an observer. However, I think that we can already do the things you guys are talking about. The idea should obviously not be to repeat the model of SQBS, which already works fine and is centralized. The idea should be to use the maximum available resources to do something that SQBS cannot do, and that means that the possibility that some high schools might not be able to use this system for whatever reason should not be used to limit this system's potential, since anyone who cannot use it can always use SQBS.
Jerry's right. The point of tools is for them to be specialized. If high schools without universal internet access (or colleges that have reasons to fear theirs might go out) want SQBS to do more of what they want, then that's between them and SQBS. The goal of this tool ought to be taking maximal advantage of the internet.
Andrew Watkins

User avatar
The Toad to Wigan Pier
Tidus
Posts: 528
Joined: Mon Oct 10, 2005 6:58 pm
Location: Seattle

Re: BEeS, Part 2

Post by The Toad to Wigan Pier » Sun Mar 21, 2010 5:30 pm

A third option is a distributed system where each computer would have an instance of the software and a copy of the current stats. The computers would be able to synch either automatically via the network or by manual transfer(flash drive). This way you can have the advantage of an internet based system, while allowing continued operation if there is no internet.
William Butler
UVA '11
Georgia Tech 13

User avatar
Mike Bentley
Auron
Posts: 5713
Joined: Fri Mar 31, 2006 11:03 pm
Location: Bellevue, WA
Contact:

Re: BEeS, Part 2

Post by Mike Bentley » Sun Mar 21, 2010 5:58 pm

Last time I thought about creating such a system, I ran into the following problems:

1. If the system is going to require online components, it's not going to be used for many tournaments. Jerry is incorrect in stating that the problem of wireless access at college campuses has already been solved. In addition to reliability problems, many campuses still don't have guest access, necessitating the creation of guest accounts, etc. to get online. When you have outside staffers coming, laptops being switched, laptops being turned off for lunch, etc. this becomes a big hassle.

Additionally, if this isn't a system that you can use at every tournament, then people are just going to use SQBS. People already know how to do that, and won't be likely to move to a new system if they can only use it in some cases.

2. If you're entering stats without online access, you run into problems merging individual stats. A human can pretty easily figure out that "Mike B." is the same person as "Michael Bentley" or "Bently" but this is a decent bit harder for a computer to do.

3. If you're looking to provide data on where someone buzzed, you'll pretty much need to create a system that will successfully parse and display packets, which is pretty difficult (and relies on being able to do this really quickly, as many tournaments aren't finished until the very last minute).

Also, I think I had many more things to say in the last BEeS thread which I've since forgotten. Anyway, I hope this project is successful and I may be able to help out a bit.
Mike Bentley
Treasurer, Partnership for Academic Competition Excellence
Adviser, Quizbowl Team at University of Washington
University of Maryland, Class of 2008

User avatar
Sima Guang Hater
Auron
Posts: 1844
Joined: Mon Feb 05, 2007 1:43 pm
Location: Philadelphia, PA

Re: BEeS, Part 2

Post by Sima Guang Hater » Sun Mar 21, 2010 9:42 pm

Bentley Like Beckham wrote:2. If you're entering stats without online access, you run into problems merging individual stats. A human can pretty easily figure out that "Mike B." is the same person as "Michael Bentley" or "Bently" but this is a decent bit harder for a computer to do.
During registration, couldn't you just type in everyone's name and instantiate that file in everyone's copy of the program, then simply have a dropdown menu of the teams? Then you can just merge the data at lunch/convenient breakpoints during the day.
Bentley Like Beckham wrote:3. If you're looking to provide data on where someone buzzed, you'll pretty much need to create a system that will successfully parse and display packets, which is pretty difficult (and relies on being able to do this really quickly, as many tournaments aren't finished until the very last minute).
This is certainly an obstacle; if everyone's going paperless, would it be simple to copy the tossup being read into a window of the program?
Eric Mukherjee, MD PhD
Washburn Rural High School, 2005
Brown University, 2009
Medical Scientist Training Program, Perelman School of Medicine at the University of Pennsylvania, 2018
Intern in Internal Medicine, Yale-Waterbury, 2018-9
Dermatology Resident, Vanderbilt University Medical Center, 2019-

Member Emeritus, ACF
Member, PACE
Writer, NAQT, NHBB, IQBT

"The next generation will always surpass the previous one. It's one of the never-ending cycles in life."

User avatar
Alejandro
Wakka
Posts: 165
Joined: Mon Jul 10, 2006 8:39 pm
Location: Redmond, WA

Re: BEeS, Part 2

Post by Alejandro » Sun Mar 21, 2010 9:54 pm

Crazy Andy Watkins wrote:
grapesmoker wrote:
BGSO wrote:
Charbroil wrote:
grapesmoker wrote: I disagree. The problem of internet access at most universities has been solved.
That might be true, but what about high schools hosting tournaments that would like to use this software?
Now my knowledge of this is nil but how hard would it be to be able to put the data from a match onto a flash drive and then run it to a central computer? That seems like a very minimal and easy way to solve an internetless.
Again, I don't want to speak for Alejandro, since this is obviously his project and I'm only an observer. However, I think that we can already do the things you guys are talking about. The idea should obviously not be to repeat the model of SQBS, which already works fine and is centralized. The idea should be to use the maximum available resources to do something that SQBS cannot do, and that means that the possibility that some high schools might not be able to use this system for whatever reason should not be used to limit this system's potential, since anyone who cannot use it can always use SQBS.
Jerry's right. The point of tools is for them to be specialized. If high schools without universal internet access (or colleges that have reasons to fear theirs might go out) want SQBS to do more of what they want, then that's between them and SQBS. The goal of this tool ought to be taking maximal advantage of the internet.
Deciding whether BEeS should be a cutting-edge product used for only a few high-profile tournaments or a program that can be used at any tournament will depend on what people want. Personally, I believe that requiring internet access in order to use BEeS would be problematic for the reasons Mike stated.
Alejandro
Naperville Central '07
Harvey Mudd '11
University of Washington '17

User avatar
Alejandro
Wakka
Posts: 165
Joined: Mon Jul 10, 2006 8:39 pm
Location: Redmond, WA

Re: BEeS, Part 2

Post by Alejandro » Wed Mar 24, 2010 12:36 am

A log of the meeting can be found here. A basic summary:
  • Slideshow interface for going through questions (can first see range of Tus/bonuses, then can click on previous/next buttons to go to the appropriate tossup or bonus).
  • Show tossup number, score, tossup, and next bonus.
  • Popup with summary of the score as an option.
  • Allow for different ways to indicate who got a tossup based on an initial option: it can be done by clicking on the word buzzed on and assigning a score to a player or just by assigning the points to a player.
  • Powers should be recognized manually.
  • Should time how long it has been since a buzz.
  • Formats that should be supported with presets: ACF, NAQT, mACF, PACE.
  • Support a schedule generator, and have a “rebracket” option.
  • Stats should be uploadable via the internet and through local disk (i.e. flash drives).
  • Since internet may have problems with transmitting stats, failed stat uploads should be saved and resent when possible.
  • Stat analysis: should have tossup, bonus, player, and team summaries. Tossup summary could show a histogram of buzzes or highlight in the text where people buzzed in.
  • The statistical data set of a tournament should be storable in a separate file that can be released when a tournament is done. This data should only be accessible after a tournament is over, however, since teams could use it to change how they play.
  • Packets do not need to be password-protected, round number should clearly indicate if someone is reading the wrong packet.
  • Quick rescheduling a must (because of teams dropping out).
Alejandro
Naperville Central '07
Harvey Mudd '11
University of Washington '17

User avatar
The Toad to Wigan Pier
Tidus
Posts: 528
Joined: Mon Oct 10, 2005 6:58 pm
Location: Seattle

Re: BEeS, Part 2

Post by The Toad to Wigan Pier » Wed Mar 24, 2010 10:34 am

Alejandro wrote:A log of the meeting can be found here. A basic summary:
  • Slideshow interface for going through questions (can first see range of Tus/bonuses, then can click on previous/next buttons to go to the appropriate tossup or bonus).
  • Show tossup number, score, tossup, and next bonus.
  • Popup with summary of the score as an option.
  • Allow for different ways to indicate who got a tossup based on an initial option: it can be done by clicking on the word buzzed on and assigning a score to a player or just by assigning the points to a player.
  • Powers should be recognized manually.
  • Should time how long it has been since a buzz.
  • Formats that should be supported with presets: ACF, NAQT, mACF, PACE.
  • Support a schedule generator, and have a “rebracket” option.
  • Stats should be uploadable via the internet and through local disk (i.e. flash drives).
  • Since internet may have problems with transmitting stats, failed stat uploads should be saved and resent when possible.
  • Stat analysis: should have tossup, bonus, player, and team summaries. Tossup summary could show a histogram of buzzes or highlight in the text where people buzzed in.
  • The statistical data set of a tournament should be storable in a separate file that can be released when a tournament is done. This data should only be accessible after a tournament is over, however, since teams could use it to change how they play.
  • Packets do not need to be password-protected, round number should clearly indicate if someone is reading the wrong packet.
  • Quick rescheduling a must (because of teams dropping out).
So is stat entry itself going to be strictly through an application or is there going to be a browser based option?
William Butler
UVA '11
Georgia Tech 13

User avatar
Alejandro
Wakka
Posts: 165
Joined: Mon Jul 10, 2006 8:39 pm
Location: Redmond, WA

Re: BEeS, Part 2

Post by Alejandro » Thu Mar 25, 2010 4:38 am

The Toad to Wigan Pier wrote: So is stat entry itself going to be strictly through an application or is there going to be a browser based option?
From what I see it will either be done automatically (by sending the information to a central server) or it will be done in a program that takes in a file.

I also forgot to mention that one of the requirements was that the reader should be able to input txt, rtf, and doc files.
Alejandro
Naperville Central '07
Harvey Mudd '11
University of Washington '17

User avatar
Deviant Insider
Auron
Posts: 4532
Joined: Sun Jun 13, 2004 6:08 am
Location: Chicagoland

Re: BEeS, Part 2

Post by Deviant Insider » Thu Mar 25, 2010 10:25 pm

I think that I could host a tournament at our high school that takes advantage of all of this program's features. I would think that any college could do likewise.

Also, it should be able to easily handle tossup-only tournaments since there are a number of singles events in that format.

If this works well, it could lead to new ways to format tournaments. If you have a power-matching system like HSNCT, there could be some way of running the last few rounds that would guarantee no repeat matches--an algorithm could be used to determine match-ups for the last few rounds that would be based on which teams win which matches, and the room assignments for the next round could be sent to teams via their moderators at the end of their rounds. Such a system would be much too inefficient without a program like this.
David Reinstein
Head Writer and Editor for Scobol Solo and Masonics (Illinois), TD for New Trier Scobol Solo and New Trier Varsity, Writer for NAQT (2011-2017), IHSSBCA Board Member, IHSSBCA Chair (2004-2014), PACE Member, PACE President (2016-2018), New Trier Coach (1994-2011)

User avatar
Pilgrim
Tidus
Posts: 637
Joined: Mon Oct 08, 2007 12:20 pm
Location: Edmonton

Re: BEeS, Part 2

Post by Pilgrim » Thu Mar 25, 2010 11:23 pm

Westwon wrote:If this works well, it could lead to new ways to format tournaments. If you have a power-matching system like HSNCT, there could be some way of running the last few rounds that would guarantee no repeat matches--an algorithm could be used to determine match-ups for the last few rounds that would be based on which teams win which matches, and the room assignments for the next round could be sent to teams via their moderators at the end of their rounds. Such a system would be much too inefficient without a program like this.
Programs that can do this already exist; the problem isn't the remote entry of results, the problem is that no room assignments for a round can be handed out until all matches of the previous round have been completed. Unless you think that BEeS could somehow solve this (which I don't see as possible), I think any such system is going to remain inviable for a tournament as large as HSNCT
Trevor Davis
University of Alberta
CMU '11

User avatar
Alejandro
Wakka
Posts: 165
Joined: Mon Jul 10, 2006 8:39 pm
Location: Redmond, WA

Re: BEeS, Part 2

Post by Alejandro » Fri Mar 26, 2010 6:37 pm

Westwon wrote:Also, it should be able to easily handle tossup-only tournaments since there are a number of singles events in that format.
It should be easy to do this with an option. However, this reminds me of an issue: if there are no tossups or bonuses left when one needs to be read, what should the program do?
Alejandro
Naperville Central '07
Harvey Mudd '11
University of Washington '17

User avatar
Captain Sinico
Auron
Posts: 2838
Joined: Sun Sep 21, 2003 1:46 pm
Location: Champaign, Illinois

Re: BEeS, Part 2

Post by Captain Sinico » Fri Mar 26, 2010 7:45 pm

Panic. I guess you might include a consistency check before the round that says something "Hey, dumbass! You (potentially) don't have enough questions!"
Actually, that makes me think that maybe questions (or rounds) could have a tag for who wrote them and warn the reader if a player of the current round is listed as a writer to avoid reading wrong rounds.

MaS
Mike Sorice
Coach, Centennial High School of Champaign, IL (2014-) & Team Illinois (2016-2018)
Alumnus, Illinois ABT (2000-2002; 2003-2009) & Fenwick Scholastic Bowl (1999-2000)
ACF
IHSSBCA
PACE

Locked