Tag Archives: XSeed

The Foucault pendulum in the lobby of the Oregon Convention Center is one of the prettiest I've ever seen, but I never did figure out how the disks reset through the day.

Saturday turned out to be just as interesting as Friday was.

We began to be more comfortable with the new look of all the paper we were working with. FT is flexible about how you can print everything—we can have pods and/or quadrants and/or page numbers and/or table brackets and/or a unique bout ID number with or without an accompanying barcode on the DE bout slips. We experimented a bit with the placement of all these items to get the most helpful combination, so that everyone could use whichever bit worked best for them.

XSeed’s unique identifier is the fencer number, derived from the alphabetical list of everyone entered in the entire tournament. It took most of a day for those of us working the table side to quit having to slap our hands to stop our automatic search back up the tableau to find that fencer number we no longer needed to worry about, and a bit longer not to feel like we were forgetting something by writing only the fencer’s name on the slip.

We discovered one advantage to FT’s use of the unique bout ID when someone inadvertently handed a stack of bout slips to the wrong computer operator, who didn’t notice that they weren’t for her event before she entered them. She scanned the barcodes, which pulled up the proper bouts in the proper event, and they were all entered properly into the correct event without her having to switch from the event she’d been working in. We just have to be careful that the bout slips all end up in the correct physical folders.

Another cool thing is that FT lets you print whatever range of the tableau you want. So if we’re stopping at the 16 to move to the replay pod, we can print the tableau only up to that point, and then print out a new one from the 16. This will be handy for SN—when BC table space is at a premium, we can switch to smaller tableaux as events fence down from their original four or eight pages.

During the turn of the Division I Men’s Saber, we discovered a fairly serious bug in FencingTime (which was also a perfect illustration of why we prefer to post the pool results and the DE tableau separately). James Williams came to the BC table to complain that even though he’d won all his pool bouts, his win percentage showed on the round results as .83. It turned out that there had been a medical withdrawal from the pool before it was completed, which means that all of that fencer’s bouts are thrown out. FT did that, but when it calculated the pool results, it still figured it was a pool of 7 instead of 6. Not only was James’s win percentage wrong, but so was that of everyone in the pool except the poor guy with no wins. Dan and Joe figured out a workaround for the problem, so we could continue the event—there was only about half an hour’s delay dealing with it—and Dan added it to the ever-lengthening to-do list in his FT notebook.

The bug didn’t seem to do James any damage, though—he went on to take the gold medal. (We BC folk aren’t supposed to play favorites, but since James started fencing at the same club my daughters did, I can’t help but be pleased when he does so well.)

Late night, unfortunately. As is usually the case, the concession food we could get with our vouchers wasn’t nearly as good as what we’d had for lunch.

The hotel restaurant was almost ready for service by we arrived promptly at 6:00 am, so we got a relatively leisurely breakfast and didn’t need to rush to catch the train to the convention center. Tanya, Joe, and the BC computer morning crew set to work out at registration with the new FencingTime (henceforth to be referred to as FT) check-in module, to make sure they were familiar with it and that it worked properly before they began training local volunteers on it.

As I set up my own computer at the BC stage, a couple of A/V techs were just finishing setting up a speaker line for us, so we would be able to play the national anthem over the PA system. We’ve had an mp3 of the anthem on the tournament computers for years, but just holding the microphone to the computer’s speaker doesn’t work, so we’ve had to skip the anthem when there was no live singer. Inevitably, though, we never got to use the speaker line—the Portland local volunteers had arranged singers for every day of the tournament.

The folks out at registration discovered a small bug in FT— the first scan of the membership bar code brings up the fencer and a second scan checks the fencer in. Dan had apparently intended for the first scan to bring up the fencer name but had planned that the second step—checking the fencer in for that event—would be done with a mouse click on a screen checkbox. The double scan was far more convenient, so it was immediately reclassified as a feature.

The big advantage to the FT check-in function is that it’s a live check-in on the network, so that the current information is accessible from the computers within the venue. Once we reach close of registration, we don’t have to wait for the printed list of no-shows to be brought in from registration—we can print it directly right there at the stage. Even better, any club changes or other corrections made out at registration go directly into the database, so that we don’t have to wait for them to be entered into the computer before we can start the event.

Because of this new version of FT, though, we were all slower getting events started and running. The computer operators (even those who were familiar with earlier versions of FT) were working with unfamiliar screens, with a different order for setting event formats, and the printed pages looked different from what XSeed gave us. That’s one of the reasons January was picked for FT’s first full run—with only three events each day, any problems wouldn’t be likely to affect the overall schedule much, and we’d be able to adapt our work flow appropriately.

One major difference between XSeed and FT is that in XSeed, you set up the event format for all rounds at the beginning. FT asks you at the beginning of each round what the format for that round will be, which is great if you want the flexibility to suddenly opt for a second pool round or repechage or fencing out 16 to all places. For us, that’s an unnecessary opportunity for operator error—in a tournament like January’s, where the Division I events have a 75% promotion rate from the pools instead of the more common 80%, it’s all too easy for the computer operator to simply hit the default selection. It would not be (and was not, in fact, when it happened) a big problem in Portland, but could be disastrous at SN or one of the NACs with multiple age-levels of Veteran or Youth events. So Joe’s asked Dan for a configuration function, with which the computer lead could set all the formats in advance.

Another FT change from XSeed, which required us to change our process, is the ability to include the strip assignments on all the sheets we print. So instead of printing out all the pool sheets and then writing the strip numbers by hand, we give the strip assignments to the computer operator before printing. The only trick with this is, in events with lots of pools of 6 and 7, to be sure to distribute the uneven pools among the available strips so that the 7s have the option of double-stripping on adjacent strips once the 6s are finished.

So eventually—in better-than-average time—the pools went out, the pools came back, the DEs went out, the afternoon event started—and then we got to the really fun part of the day. We’d already had quite a few people come tell us how much more legible they thought the FT printouts were, but we hadn’t yet made public the next logical step.

Joe had created a QR code and sent it to me a couple of weeks earlier, and my immediate reaction was that we should tell people about what was coming right then. Calmer heads prevailed, though, with the idea that we should make sure it all worked right before we went public. So I’d satisfied myself with making the signs to post as soon as we were ready, and once in Portland waited all through Friday morning for Joe to give the word.

Once we were well into DEs and knew all the rounds were functioning the way they were supposed to, Joe gave the OK, and I grabbed the signs I’d copied the day before and posted them on the bulletin boards and around the BC table.

Finally!

Once the signs were posted, I sat and watched to see how people reacted to LIVE RESULTS! at a USA Fencing national tournament.

The reaction didn’t take long. Tanya even received three or four approving emails within the first few minutes after we went public. We got positive responses all weekend, of course, and though it was difficult to tell because the venue was one of those rooms that never seemed crowded even when it was full, it looked as though a substantial percentage of fencers had realized they could find their strip assignments using their smartphones, so the bulletin boards never seemed quite as jammed as in the past. A few coaches and parents joked that it just wasn’t right that their at-home spouse knew how their kids placed before they did.

There was that one guy, though, who looked at the sign on the bulletin board, took out his iPhone, and proceeded to take pictures of the posted sheets. But we took pity and showed him he could find much more information without using the camera at all.

A great day for flying up to Portland—all too often, there's too much cloud cover for this view.

I expected this would be an interesting NAC—in every sense of that adjective!—and I was not disappointed in that expectation.

Even if there had been nothing else going on, I would have been disoriented for this NAC, just because I’m so used to needing to get up at 2:30 or 3:00 am to get to the airport in time for an early morning flight with at least one layover to get me to the venue early enough for setup. I always use the lack of real sleep and the time zone change to put myself into Tournament Time—that weird actual-time-doesn’t-matter state necessary for running national events. A lunch-time flight in my home time zone with no layover just doesn’t seem like a real fencing trip.

My daughter got the real fencing travel this time—she had a layover at O’Hare, and the hour her plane sat sitting through two gate changes before it could unload made her miss her connection. But she was first on the standby list for the next flight, so even with the delay, she still made it to Portland in plenty of time for dinner.

Setup for me was relatively painless—all the scoring boxes were set up in plenty of time to get the strip numbers up on Thursday, and everything—bulletin boards, copier, all our supplies—were in place fairly early on.

The process was a bit more involved on the computer side, because this was a momentous NAC for us: since the contract with Dan was signed last summer, FencingTime had met all the intermediate tests, so Portland would be the first national tournament where we would be running FencingTime. While we had XSeed available to open up as a backup if it turned out to be necessary, we would not be using it to shadow FencingTime in real time.

So the little netbooks we use for check-in had to have the new software installed, as did the tournament laptops, and Joe had to make sure the server was configured and the network set up properly. And, as always, Carla and Tanya had to find and correct problems with the event seeding, especially in the Division I events, with their more complicated seeding rules. All in all, though, considering the amount of work we had to do, our 7:00 pm setup finish time was pretty good, and we were as ready as we could expect to be for dealing with whatever glitches and bugs and workflow changes we’d face in the morning.

Of course, that morning would come awfully early—because of the new check-in process with FencingTime, we—Tanya, me, Joe, and the rest of the morning computer staff, would need to be at the venue by 6:50 am. So we arranged to meet for breakfast at 6:00, so we could catch the train early enough to be at the convention center in time.

I realized from some of the comments on Fencing.net after my Playing With Numbers post that there are still a lot of misconceptions about how the bout committee works. One comment suggested that a more useful statistic than the ones I’d come up with would be the number of bout committee staff per total fencers—that more BC staff would make tournaments easier to run. Another suggested that splitting the hall in half and having two separate BC tables and staffs would ease tournament operations.

Neither is true.

(Don’t think for a minute, though, that we don’t need more BC staff. However, what we need is a larger pool of qualified staff to hire from, not more people up on the platform at any given time. We need more staff so we have time to train current staff to handle jobs like lead computer and BC chair, and time to train new people at the entry level. With more regional tournaments, we need that larger pool to help those organizers staff their events—we ought to have (and are already planning) a BC staff list like the referee list the FOC has on FRED.)

For a typical NAC, we hire a BC chair, a computer lead, three computer operators, and three table staff. If the NAC is very large, as the November and January NACs were this season, we’ll add another table person. If there are many events—say, more than 18 over 4 days, as in March this season, with all those Vet age-levels—we’ll also add a fourth table person. If there are team events, as at JOs or the March NAC, we’ll hire both a fourth table person and a fourth computer operator, because teams are run on a separate computer at a dedicated floor-level team table.

During the week or two before the tournament, the BC chair and computer lead use the strip management spreadsheet (which gives us the number of pools, DE bouts, and estimated times for each round of each event, among other useful information), to plan the staff schedule, which is sent out to all staff a few days before the tournament. Usually, computer staff each day work one computer with all the events in a single weapon. Table staff assignments vary a bit more—one person might work a single huge event, or one morning and one afternoon event, or one morning and several simultaneous small afternoon events.

The BC chair and computer lead normally fly in late Wednesday or early Thursday to be able to work on set-up day at the venue, usually along with a couple of other BC staff whose flights are early enough, unpacking the big black BC crate (just like the ones strips are shipped in). The computers are unpacked and the network set up: there is a master computer and three laptops set up as slaves; if there are team events, another laptop is set up as a team computer for when it will be needed.

(On tournament days, you’ll usually see quite a few more computers up on the platform. Tanya has one with access to Railstation, so she can check (and correct) entries and fencer profiles. The BC chair and computer lead usually bring their own laptops—I use mine to run the strip management spreadsheet for planning throughout the tournament. The head referees often bring their own machines, too. This proliferation of electronics got so bad, what with all the referees who want to charge phones or other devices, too, that this season we seriously upgraded our power strips; the tournament computers are always on a separate circuit from everything else.)

Here’s how an event typically runs:

Before the event closes, the table staff person (we’ve never figured out a good title for this position—event manager? competition coordinator? generic BC person?) retrieves the event sign and bio forms from the event folder, picks a marker color for the event, and stakes out a place at the BC table to hang the sign and set up the table side of the event. At close, she (usually a she, though by no means always) receives the printout of the no-shows from the registration desk and calls them over the PA system. Once that’s done, the list is given to that weapon’s computer operator to withdraw the no-shows, update the seeding list, and create the format sheet.

When the final seeding and format sheet are printed, the operator gives them to the table staff for copying and posting; once it’s posted, she announces that it’s up. Meanwhile, the computer operator sets the pools, checking for unresolved conflicts and that the larger pools are the higher-seeded pools. If solutions to the unresolved conflicts can be found within about 20 minutes, that is done; otherwise, they are left standing as unresolvable. (This process can be far more complicated than it first looks, requiring frequent reference to the seeding list and multiple cascading swaps.) Then a seeded copy of the pools is printed and given to the referee assigner, and a randomized copy of the pools and an alphabetical pool list are given to the table staff. The BC chair, by this point, has informed the table person of the strips her event is assigned to, and those are penciled onto the pool assignment sheet before it is copied and posted. (We prefer to post the seeding and pools separately, especially for point events, in order to allow a bit of time for fencers to verify their final seeding; unfortunately, few take advantage of the opportunity.)

Once the pool and strip assignments are posted and announced, the table person adds the strip numbers to the pool sheets, which she’s already marked with the event color to distinguish from the other events running that day. We usually try to spread any pools of 6 around among the 7s, to allow double-stripping the 7s more easily once the 6s are done. Then, all that’s needed are the referee assignments; some assigners (most, so far this season) are fairly quick at this, while others can take 30–40 minutes to allocate 50 or 60 referees to 30 or 40 pools. On occasion, the referees have not yet finished their morning meeting by the time the BC has events ready to go; some head referees make a point of getting to the platform in plenty of time, while others are not so conscious of the passage of time and therefore get calls from the BC chair asking if they are on their way yet.

When the assigner provides the referee list, the table person adds the referee names to the pool sheets; for a big event, we often split the list, and two or even three people will copy the referee names. Then the referees are called to pick up their sheets, and for the next 5 or 10 minutes, they’ll come in person or call to ask for second calls on fencers who’ve not yet shown up. Once the fencing is underway, the BC staff—both computer and table sides—for this event are free for most of the next 90–150 minutes, depending on the weapon.

What do we do with the free time? Read email and web-surf for those with connected devices, play computer games, read books, knit or cross-stitch, make group coffee runs if there’s a Starbucks or Peet’s in the convention center, shop at the vendors in the hall, work on other fencing matters (check seeding for the next day’s events, create training materials, other projects). Sometimes we even go watch fencing.

Ideally, about halfway through the pools, the table staff will tour the pools to see how many bouts are left on most strips and whether any have fallen significantly behind the rest, in which case, the assigner is informed and extra referees might be sent out to take bouts, if there is an extra strip available. Some assigners—but not all—keep a close watch on their events and handle this themselves. Sometimes, though, head referees get pulled into what we fondly refer to as “Things” (as in, “Sharon got called out to a strip for a Thing”)—requests to observe a particular referee or mediate a rules dispute or see that a black card is handled properly, so it never hurts for the BC to keep an eye on progress, too.

Once the pools start coming in, the table person checks them off on her master sheet and hands them to the computer operator for entry. Once all are entered, the operator prints out the round results, on which the table person draws a line between the ups and outs if there is a cut, and gets it copied, posted, and announced. While that is done, the operator prints the DE tableaux, once with divisions for the assigner and one without for posting. The assigner and the chair have usually already decided on the number of strips to be used for the DEs and how they will be grouped (in pods, in pairs or (preferably not) as singles), so the table person writes the strip assignments on the table and gets it copied, posted, and announced, too.

Meanwhile, back at the computer, the operator prints out the bout slips (at 4 per page, a full 256 table would be 32 pages for the first round alone), marks the sheets with the event color, and slices and sorts the bout slips in stacks for each bracket of the table, the process we refer to as “slicing and dicing.” When the assigner gives her the tableau with the referee assignments, the table person makes two copies and returns the original to the assigner. One set will be used at the table for recording bouts as they come in; the other is split up and given to the assigned referees with the bout slips for that section of the table.

After the slips have been sent out with the referees, the table person organizes her tableau. Most of us lay the pages out vertically in pairs—a table of 128 prints out in four pages, so pages 1 and 2 would be on the left and pages 3 and 4 to the right. The table person then numbers the bouts on the tableau (XSeed puts bout numbers on the bout slips but not on the tableau, so if we want to match them up, we need to do our own numbering) and then sorts the slips for each round into quadrants (or octants, in the case of an 8-page table of 256) so that there’s a stack for each page.

As bouts come in, the table person verifies that the winner is actually the fencer the slip says it is (you’d be amazed at how many fencers sign slips that say their opponent won), records the winner and the score on the paper tableau, writes up the next bout slip if there is one, and stacks the returned bout slips for the computer operator, who usually comes to pick them up more often than the table person gets a chance to take them over to the operator.

Why do we even run the paper tableaux? Why don’t we just enter results directly into the computer? When there are four or five events at once in the same weapon on a single computer, there’s less waiting for the fencers if there are separate lines to turn in bout slips for each event. It’s easier for the computer operator to enter the data accurately if she’s insulated from dealing directly with several hundred fencers. And with all the paper we produce, even marked with its distinguishing colors, it’s easy for bout slips to be misplaced, and the paper tableau gives us an additional record of each bout in such cases, rare though they are.

A table of 128 (or fewer) can be run easily by a single person; using two for an event that size is overkill. Only if we’ve got a BC trainee will we split a 128 table, so they can see how the event is done without it being overwhelming. For a table of 256, it’s nice to have two people for at least the early rounds of the DEs—8 pages of tableau is a bit of a stretch for one person to cover, though it’s nowhere near impossible. Sometimes, if there aren’t too many other things going on, we’ll have a computer operator or a volunteer act as a concierge of sorts, to check fencers’ bout slips as they arrive and direct them to the proper half of the tableau. (For a table of 512, which the BC has done once and hopes never to do again, we’d need at least 3 people—preferably 4—to run the 16 pages of tableau, and a concierge would be a necessity rather than a luxury.)

But those extra bodies are only useful for the first few rounds. From time to time, I’ve run a 256 saber table alone, and it’s always a rather breathless experience getting through the the first few rounds, because the bouts just keep coming and coming. (But it’s fun, too!) Big tableaux in foil and epee are easier to keep up with, because in those, the fencers tend to come in small waves—the bouts are longer and more of them go to time. But by the time any event fences down to the 64, one person is plenty for running the table. Getting the strips and referees assigned for the round of 8 is a snap (though less so than it used to be for events using replay these days); once the fencing is completed, all the table person needs to do is arrange and mark the bio forms according to placement for the medal presentation and then make sure the bio forms are returned to the computer operator for the event folder.

For tournaments with many smaller events (in Detroit we held 44 events), it’s common for a table person to run two or three events simultaneously. When events are only two or three pools, if that, and the DEs fit on a single page, it’s easy to run multiple events as long as each has its own color, and it’s far less stressful than adding extra people to the crowd already on the BC platform.

But what about that idea of having two separate BCs in the same hall? Wouldn’t that solve the crowding problem? I’ll talk about that next time, along with running teams and a few other ideas.