Discussion: New version of OEvent - orienteering management software

Hi,

Just wanted to let you know that I have released new version of OEvent. Actually it's just a preview 1, not final version yet.

However, since previous versions of OEvent did get very good reviews, I am sure many of you will like this new version too.

For those of you who are not familiar with OEvent let me just give you short history:
First version of OEvent was released in 1996, and it was very feature rich program. At first it had support for EMIT only (SportIdent did not exist at that time). Later when SI was released it still did not gain a lot of users because at that time SportIdent pushed another software, and users were mainly buying that one.

Anyway, biggest problem with that version of OEvent was that it used flat file as storage and it was impossible to make it work with multiple users. That's why I stopped working on it. Later when I stared helping my brother on OrienteeringOnline cup (5 days competition in Slovenia) we used another software, but we didn't like it.

Also, we needed simple and reliable online entries system. At the end I ended up writing first OrienteeringOnline.net entries system, and later also OEvent (from scratch) which is now almost finished.

The idea behind OEvent is to integrate it tightly with OrienteeringOnline system, and to make downloading entries and uploading start times/results/splits a task that does not require more that a few clicks with mouse. No import/export, OEvent talks directly with OrienteeringOnline.net. Later, speaker support and live online results (again through OrienteeringOnline.net) will be added.

Basically the idea is to simplify the organization process as much as possible. And since I am author of both entries system and management software I think I can pretty much achieve this.

For those who are interested it uses embedded Firebird database engine, but can also be used with Firebird in client/server configuration.

You can get see how it looks here:
http://www.oevent.org
and here
http://www.oevent.org/Preview1.aspx

On the second link you will also find download button.

I will be happy to hear about any comments/suggestions you might have, especially about how to simplify things for those who are not so computer literate.

Dear Goran,

it seems that you have given a lot of attention to the database interface side of things. Software written with this as primary focus is very likely to be registrar- and webmaster-friendly and that is super nice. I am a hardware guy and as such I am interested mostly in the hardware-related problems with the existing software (I assume someone can fix the databases eventually). My key questions to a piece of event management software that claims it can work with SI are these:

1. Two people in the database with the same SI number. Is this situation resolved gracefully? A common problem at multi-day will be that Bob Jones runs M35 on Day 1 (Long) and M21 on Day 2 (Middle), with the same SI number. Usually this means creating two separate entitites for Bob Jones. Some EMS will let you enter this situation into the database and then it'll gag at the exactly wrong time, when Bob is downloading and expects his splits in a timely fashion. I'm not saying the EMS should accommodate different people running in the same race with the same SI number, this perhaps should be always illegal, but running on different days, it is a common situation.

2. Someone runs with an SI unit not previously entered in database. Of course you can say this must not happen, start officials should catch this, but it always happens. Someone may lose an SI stick on the way to the start and borrow a stick from someone, and the start officials aren't computerized to enter it. And I see no reason why it shouldn't always be a valid and legal situation, perhaps at local training events it is the norm, but even at large events there should be a way to pull a runner who just ran with an unknown stick off to the side and enter all of his info/match it with an existing entry.

3. (Here we get into angering IOF Gods) I assume your EMS writes some kind of punches file/database that can be queried after the EMS crashes or is shut down. I think there should be a straightforward and easy way to add a record from a queried SI unit to that same database on top of the downloaded punches from the competitors, in case the event runs into one of those SI firmware bugs that they claim never happen, or only happen when the runner punches "too fast", whatever that means.

To explain: Bob Jones downloads and he is missing Control 31. Bob swears he has been at Control 31 and it has flashed and beeped, and produces someone else who vouches that exactly that happened, yet there is no record of Control 31 in Bob's stick. IOF says Bob must be disqualified, but I personally have seen too many SI firmware bugs to not be so sure. (I also create hardware/firmware for a living and have learned a certain humility that seems to be absent in SI, and a trust in redundant systems.)

So, if I then come out of the woods with Control 31, is there a simple way to reevaluate all punches from the control and not have to do it manually? What I mean is, the control unit is interrogated similarly to an SI stick, and then I select "Evaluate Punches" or some similar and all runners who have a valid record in Control 31 are magically reinstated. To me that's good enough; a hardware record that Bob Jones indeed was at a certain place in space at a certain moment in time is enough to qualify Bob, no matter what the IOF says.

4. An even-more-obscure variation of this situation that seems too much to ask for from an EMS author to handle, but it happens more often than you think, is that of a misprogrammed control. That is, Control 41 actually got programmed as Control 40 (or, godness, as Start! (as Clear would be non-recoverable, but this is not discussed, and usually only happens out of mailce)). People come back from the woods and some punched this 41 that wrote as 40 and some also have the real Control 40 on their course, so the EMS is super confused. There seems to be no way to fix this situation without querying the control units (you can't just substitute 40 for 41 because the real 40 was also in the woods), so there is guaranteed to be an angry mass of competitors asking what happened, that's life. But, the situation should be at least survivable once the control units have been brought back from the woods—if the EMS knows how to handle it.

5. Hardware (download unit) death (usually just link hanging) should be handled gracefully. If someone has half-downloaded, then hardware restarts, and s/he downloads again, there should not be an irrecoverable error.

6. And I assume, of course, that your EMS keeps backing things up continuously, so that if power is lost and/or batteries discharge and/or Windows crash and/or the SI download unit causes a Blue Screen of Death with USB_DRIVER at 0x0000000F, as much as possible can be recovered, preferably everything up to the point that the problem occurred.

7. Anyone else have hardware-related concerns/horror stories?

Sorry maybe you already provide answers to some or all of these questions if I only had downloaded your EMS and played with it, but it seemed faster to just type up the questions.

Adding to the horror list...

7. Times should be handled gracefully. In particular in OE/MT there is a concept of "zero time", which is nonsense. If I have punches at 5 am AND the event download person ascribes them to the correct race day of a multi-race, there is no reason that these should show up as yesterday or tomorrow.

Anyone else have hardware-related concerns/horror stories

How about this: One of the punch units at finish line (or forest) is found to be couple of seconds off compared to the other units there. Could one just take the unit and plug it to the computer and it would half-automagically fix splits & results?

Yes this is a good one. Ideally it requires keeping track of the time offset for each unit. A lot of things would be easier still to keep track of if SI didn't just write control number into the stick but instead a unique unit ID/serial number/tag. Then two of the situations I described above wouldn't arise, if the control number were misprogrammed it'd be the alias to the unit in the EMS, not semi-hard in the unit itself. Of course SI is hardly based on robust hardware design concepts (don't get me started on their battery management—they did an end-run around it by just getting better batteries).

but instead a unique unit ID/serial number/tag

Possibly you could work this around by programming all units with unique code and using feature #4 above - so if there is several units at a control you just program extra units as alternative codes, and those codes are converted to "main" code for split analysis/exports. Like this you wouldn't have to read units to fix time offset issues. Well, not quite - there is start/finish units with common code - to fix it properly you would have tu use units programmed as normal controls as start/finish units. I have never understood why there has to be special start/finish units.

Also if a unit fails and you have to replace it, the replacement unit doesn't need to have that same code - it could be what ever free code, you just type it as alternative (ideally you wouldn't have to care what time is it running, you just find out the offset after placeing it to forest and type that as offset for that code - wouldn't matter if its hours off).

Thas about how it's been done here for ages - we have no choice since we our units are not programmable (fixed codes).

Being in charge of OrienteeringOnline.cup competition (1100-1700 runners) for almost 8 years (for the part where EMS is used), I am well aware of the issues you raised. My opinion is that EMS needs to be the best in the part which covers competition days, because then you don't have all the time in the world to fix times/controls. Everything should be as smooth as possible.

I appreciate your comments, since I do want to make especially that part as helpful as possible.

1) Each competitor have SI card number for each stage. Like you said you would have to have 2 Bob Jones entries, one for each class, and if you assign him SI numbers correctly (in one class the first day and in another class for second day) you wont have any problems. If you assign same SI number in both classes for both days, you will be asked (after data is downloaded) to which of those two runners you want to assign the readout. This second part is not implemented yet, but it will be in final version. Now, I do see a little problem with this, because I don't particularly like modal boxes being opened when people read their SI chips, and if you have a better idea how to handle this let me know.

2) I know this happens a lot, people just lose their SI cards, or even mix them with another competitor, and of course start official can't prevent him starting the race. This is similar as above: dialog will be opened and operator will be asked to find competitor. This dialog will optimized for fast searching of competitor. Again, I have same problem as above with dialog boxes. It just happens sometimes that operator at the PC looks the other way, then person with unknown chip comes, puts his chip in readout station and walk away, Dialog is opened and operator does not see it (looking the other way). Next person comes, reads his chip, hears beep, and also walks away (however his readout is not registered). Sure, it's a mistake of PC operator, but it does happen sometimes at our competitions, that's why I don't like those dialog boxes.

3) Sure, I agree this is necessary. I'll try to add it in final version.

4) Yes, this is a bit more complicated to handle, but I'll think about it.

5) Agree, I think this is handled properly.

6) Well, it's transactional database so nothing is lost if power is lost. This is not a backup though (against human mistakes for example: PC operator just deletes all competitors)...backup should be done separately every N minutes or something like that.

7) I don't completely understand this point. What do you mean by zero time? Is this like first start? For example 10 o'clock. I don't see how I could do without that if I want to display both relative and/or absolute times. Can you explain this a bit more. Why would you have times around 5am? And how you would like your times to be computed then?

@Jagge: Good one, I'll think about this too.

How does your system fix up WOC Sprint qualifier results - this is the first time the results for each heat have been ranked on fastest 15 DSQ?

1/2. Modal windows are awful and "not registered" must not happen. Feedback to user must reflect what happens inside the system. In the case you described, the EMS should create a record for further evaluation, and send a message to the operator, not a modal window. In any case nothing should beep, indicating a successful download, until there has actually been a successful download.

7. Regarding zero time: There shouldn't be one. Yes it's like the first start, but people often run before the official first start, for whatever reason. At the North American Championships people were in the woods at 6 am who then had work at the event. If the zero time is 9 am and you started at 8 am and you finish after 9 am, OE/MT will think you actually started at 23 hours past zero time but finished right after zero time, and it is not equipped to handle that.

One solution around this while retaining the zero time concept is to make the zero time absolutely before anyone starts. But then "relative times" stop having much meaning, most of them will be several hours and people will be confused.

The correct solution is not to have zero time, or relative times. All times within the EMS should be actual times. If you need to resolve an ambiguity that is brought in by the SI clocks, e.g. if you have a night-O and you roll over 24:00:00 inside the SI, the EMS should know how to handle this; it should know when the race day begins (and ends), but you should not publish start information offset from this time. To elaborate, start time information like "0:02", meaning two minutes after the first start, should not exist. It should be "10:02" or "10:02:00", meaning two minutes past ten o'clock in the local timezone. (The same effect can be achieved in OE/MT by making zero time equal to midnight, unless you have a night-O or a Jukola, in which case this effect cannot be successfully emulated in OE/MT.)

Hm...seems I am not the only one that hates those modal windows. However, I do have to say that sometimes they are very handy. At first OEvent did what you suggested...it has something called "Errors buffer" where all readout problems are logged (and data from SI remembered). Operator can then resolve those issues.

But like i said sometimes those modal windows do come handy (at least to me) that's why I implemented them. But now it seems I'll have them as optional only.

As for zero times, I have to disagree with you.
First, in some countries they are used to using relative times. Second, having relative times makes it easier to fix problems when you postpone first start (not saying that using absolute times makes that impossible). And third using absolute times requires using both date and time for start times. In theory (not sure if it really ever happened) it probably could happen that someone starts at 6AM and someone at 6AM next day. In that case if you print start list by classes you also need to print dates too (not just times), which seems highly unpractical (not that having relative times like 1440:00 isn't).

However, I do agree that there should be a way to handle people who start before first start. We had someone in the last OO.cup who started before first start (don't know why start officials let him) and it took us some time to realize what happened when he finished.

However, since these are more exceptions, I think that using some kind of negative starts or adding (negative) start offset for those people would be more appropriate than to sacrifice relative starts.

I have no problem with modal windows per se, but OE's implementation of the 'unknown runner' situation is awful - it only makes sense if people are running with chest numbers that match their start # in the system. At our minor events the operator is asked for a start number they can't possibly know (often they don't understand what's it's asking them anyway) and a modal dialog that won't let them look it up.

Whether you've got a modal dialog or not, if you don't trap the unknown runner as soon as he downloads you're going to have problems matching him up with his time later. The problem isn't with the dialog itself, an unknown runner is an important event in the EMS' universe.

I completely agree. We do use chest start numbers so MT's implementation was OK for us, however I do realize not every competition use has chest numbers. That's why my dialog will be pretty different.

Also, MT's implementation of using "Reserved" class and putting unknown runners there (if you click cancel there in the modal dialog) seems to me at best a bit weird.

On that note - is OEvent intended for use at minor events, or are you aiming solely at bigger ones like OO.cup? I'm always interested in software that's easier to use than OE, because it means fewer organisers asking me to fix it when I've just finished my run. :)

"A bit weird" is being nice about it.... I refuse to use that path myself, I prefer to work out why the tag isn't recognised, fix the entry and then get the person to download again on the spot.

It's intended to be used for both small and bigger events. People who used previous versions of OEvent, when they switched to OE (due to lack of development on OEvent, because of reason mentioned in first post) always told me how OEvent was easier to use. Since I heard a lot of people complaining (in general) about most programs being to difficult to use, I even plan to have some kind of dialog at the start where you will kind of describe your event/needs, and then some features will be invisible. I know this has to be done wisely, but for example: at OO.cup we use blocks so that all club members start together (not at exact same minute of course, but close enough they can travel together), which is not something that is used on small events. So, just removing blocks from interface is not a problem in my opinion and it does make program easier to use (less clutter on screen -> easier it is to use it).

Sure, I prefer myself too to handle unknown runners immediately. However, sometimes they just get pass me (when I look the other way - it's a small team, I do have to do other stuff too) and when I realize it that windows is there, and I have to cancel it. Not to mention, on bigger competitions, if I have to have a 5 minutes talk with the unknown runner because he doesn't speak english, doesn't have his chest number and so on....the line behind him can very fast get pretty big. Although on the last OO.cup we had 3 PCs, 2 for readouts and 1 for such cases. Then I just go with him to third PC and handle it there, while the other 2 PCs are still being used with no interruption for readouts.

I like your thinking on disabling features - so many features of OE just serve to confuse the hell out of people, so taking them out of play if they're not needed is a good idea.

I've had a bit of a play with the preview, and I like what I'm seeing. It's a bit too tightly bound to OO.net for use at small enter-on-the-day local events though, which is what I was driving at. I like the look of the error buffer on the finish times window, makes me want to grab some SI gear and start fiddling. :)

I completely agree about your note about enter on the day local events. I still need to work out on that part. But like i said it's not feature complete yet.

BTW, one idea I had to speed up on the day entries is to have OEvent pre-load data for all users on OO.net...their names, clubs, and SI cards and last classes which they ran. This would happen a day or two befopre competition starts. So, on the day you could just insert their SI card to master station, and if they have profile on OO.net you could get most of the boxes pre-filled. Of course past competitions could also be used for that, however if you also use OO.net's data, you have data from competitors that never attended your competitions. And the more people use OO.net, the better this feature gets.

What do you think? Also, if oyu have any suggestions how to improve those small competitions you talk about, just let me know, I'll be glad to incorporate them int OEvent.

Importing courses in .xml from Condes or OCAD so that per-km paces print along with splits. Sorry perhaps you have that already.

BTW, one idea I had to speed up on the day entries is to have OEvent pre-load data for all users on OO.net

Yup, that's the kind of thing we use currently. We have an offline membership database, which we keep more or less up to date with OE's internal archive table so people can register with just their SI tag. If you allowed imports from OO.net or IOF XML files, I think just about everyone would find a use for it one way or another.