?

Log in

No account? Create an account
   Journal    Friends    Archive    Profile    Memories
 

Some Technical SMOFing: Programming Information Systems - RonO's Ramblings

Sep. 2nd, 2009 10:28 am Some Technical SMOFing: Programming Information Systems

Inspired by my experience working in Programming Operations at Anticipation, as well as attending other Worldcons, attending the San Diego ComicCon, attending and working several regional and local SF cons, and some other discussions (like the "mind meld" article that kevin_standlee recently referenced), I've been thinking off and on about how computers and Internet technology can be used to improve programming communication for conventions.

From those thoughts, I've started coming up with some ideas what such a system might be able to do and how it could be built.

I'll start with some "non-functional" requirements. Given the budgets of the intended users (cons) and their diversity, such a system would need to be cheap, probably open source itself, and based on technology that is both cheap and easily available on a number of hosting platforms, both public and private.

Since this is a data based system, some sort of a database will be required. Similarly, since this system needs to be easily accessed by a number of different people in different locations and roles, it should probably have a web-based front end.

All of these lead to the need for something backed by an open source database such as mySQL or Postgress, and a front end written in PHP, Perl, JSP/Java Servlets, Ruby on Rails or other similar systems. (If I were the primary designer I'd probably go with mySql and either PHP or JSP/Java Servlets since throes are what I'm used to using, and I'd lean to PHP since it is more often available on less flexible hosting systems).

If this were a formal project being specified for a company or consultant to bid on, there would also need to be specifications for capacity and reliability, but for a volunteer project that may not ever happen, those can be ignored at least for now.

With these non-functional requirements out of the way, there needs to be some functional requirements. I can outline what I'd like to see from a couple of perspectives.

First, from the perspective of the programming planner, I'd want to see a system where I can enter my resources (panelists, rooms, tech equipment, etc.) in appropriate categories, and then assign them to panels and times appropriately. Ideally the system would be able to flag conflicts for unique items (panelists and rooms) and produce a list of the maximum usage for non-unique items (tech equipment).

Of course, it would be wonderful to have the system automatically produce the perfect schedule of rooms and times. But I'm pretty sure that that is a task that has proven sufficiently computationally hard to do that there are few if any successes. (I've seen this problem in graduate testing classes enough to make me think that it is something that CS professors want to create but end up just using as a sample system).

Second, the system should then be able to produce, at least in a starting format, most or all of the programming schedules for publications, including program listings by time or track for the main programming book, programming grids for the pocket program or daily updates, indices by room and panelist, etc.

Third, the system should allow for easy updating of the schedule on the fly, especially changes in the panelists and the tech equipment. It should also be able to produce a report of the changes that can also be put into daily updates.

Fourth, the system should produce a tech services chart that will allow them to distribute their equipment easily.

Fifth, the system should produce the information that needs to be communicated to the panelists. This would mostly be the schedule stickers or cards for their quick reference and possibly a bigger sheet that has the descriptions of their panels.

Ideally the system could also generate a reports that can be directly used as the tent cards for each panel (perhaps with notes to the panelists on the back) and the room schedules for each room.

But another set of important users are the regular convention attendees. They should have more limited access to the system from a public site.

The public site should allow the user to download the most current schedule -- through direct access to the database if it can handle the load -- at any time. They should also be able to search the schedule by time, track, panelist etc. I would think that having the system automatically bring up the panels and events starting in the next couple of hours would also be of great use.

This information also needs to be formatted so that it is useful both on computers and smaller devices (phones, PDAs, web enabled MP3 players, etc.).

Users should be able to download the schedule in at least a couple of common formats for calendar import.

Were the budgets and technology available, I can think of some other things that would be nice to have. Being able to put the next few hours schedules onto large electronic signs (i.e. monitors) that can be kept constantly up to date would be ideal. I'd also love to see a smaller electronic sign for each panel room that would always display the current schedule, and the schedule for the rest of the day. But both of these are probably beyond most cons, even Worldcon, unless the facility has the electronics in place and is willing to let the convention have access to them to tie them into their system.

I know that systems that do at least some of this exist. Anticipation was using a system that seemed to handle a lot of the scheduling work. But it didn't produce the printable schedules, nor the change sheets which had to be done manually. Depending on the nature of that system, or similar ones used elsewhere, it may be a starting point.

One thing to keep in mind is that the computer tool is never more than an aid for the volunteers. Many scheduling and other crises will occur that will need to be resolved without being able to update the database, and the volunteer staff will have to adjust.

Also, people will never be 100% happy. Schedules will change, and nothing will ever be completely up to date. Plus late changes will be missed by a lot of people.

But, I suspect that a decent information technology that is well understood by the key staff users and used consistently would be of benefit, and I know that an increased ability of the general membership to get at real time programming data will help as well.

7 comments - Leave a commentPrevious Entry Share Next Entry

Comments:

From:robot_grrl
Date:September 2nd, 2009 05:52 pm (UTC)
(Link)
So, how much time is it going to take you to write this? ;)
From:rono_60103
Date:September 2nd, 2009 09:56 pm (UTC)
(Link)
Not that I'm going to try (at least not this year). But the most likely way I'd get involved with such a project would give me between 12 and 18 months, depending on when the 2012 Worldcon needed to start putting together their program.

I'd try, however, very hard to start with something already written and then improve it.
From:qnofhrt
Date:September 2nd, 2009 05:58 pm (UTC)
(Link)
Fourth, the system should produce a tech services chart that will allow them to distribute their equipment easily.

You have it backwards. You put the equipment in the rooms that are best equipped to handle it (size, location etc) and schedule the events into said rooms.

The last time I heard a system like this discussed was at Midwest Construction umpty-ump years ago. Supposedly very stable and easy to use...


...as long as you have a computer that runs DOS 3.1 and DB2.
From:shsilver
Date:September 2nd, 2009 06:11 pm (UTC)
(Link)
You have it backwards. You put the equipment in the rooms that are best equipped to handle it (size, location etc) and schedule the events into said rooms.

Totally agree. You decide which rooms will host technology-reliant programming, ensuring a couple of different sized-rooms, and you keep those items to those rooms.

Capricon has a very nice bit of programming software that is on the web. It was developed by verhulst and I plan to use it if I do programming again.
From:dave_ifversen
Date:September 2nd, 2009 07:06 pm (UTC)
(Link)
Definitely the way to go - your Tech Services people are (most likely) volunteers - very *overworked* volunteers. The less they have to schlep equipment around, the better.

The other thing is, as long as you start with your tech equipment in one (or two or whatever) rooms and schedule events around it, you are pretty much assured that you won't end up scheduling for more equipment than you have on hand. (This could be fixed in the program as well, but given the way I've seen fannish con programs done, I wouldn't count on it.)

I've talked to quite a few people who have started working on programs like this, but they never get anywhere with it. And they quickly learn that it is just easier to start with the equipment placed in rooms and go from there.
From:rono_60103
Date:September 2nd, 2009 09:59 pm (UTC)
(Link)
"Fourth, the system should produce a tech services chart that will allow them to distribute their equipment easily."

You have it backwards. You put the equipment in the rooms that are best equipped to handle it (size, location etc) and schedule the events into said rooms


I agree that at least to the extent possible the equipment should stay in place. I also suspect that this may not always be a solution that scales -- with the variables being number of tracks and number of rooms.

Of course I've never personally tried to do the "Master/Mistress of Time and Space" bit for a convention and get everything in place. I've just dealt with the results from several perspectives.
From:kevin_standlee
Date:September 2nd, 2009 08:58 pm (UTC)
(Link)
And good for you for not saying, "prohibit invalid states" like programming conflicts; some people have assumed this in their design ideas. It's not uncommon during the development of a con's programming to generate invalid conditions (people scheduled in multiple places simultaneously). It's excellent to flag the errors, but bad to prohibit them from happening at all.