See also my LJ post, which has the same content, and you can leave your own comments.
Thoughts about the Program Schedule E-mail messages.
1. Main Prog Div, or Live Prog Dept, or whatever role is responsible for the program (call them "Prog") should be in charge of WHETHER and WHEN to send schedule e-mails, and to WHOM.
2. Prog needs to be able to easily send out the messages.
2-A. There should be a way to produce a spreadsheet of the data needed for the membership database.
2-B. There should be a way to produce a directory of names and phone numbers & e-mail addresses for Prog to use to contact people on the day.
3. Prog needs to have the data readily available to make the decisions of whether, when, and whom.
4. Prog needs to be able to update the master schedule.
5. A "minor change" is one that doesn't really require a message to go out. A "major change" should result in that person getting a new schedule message at some point.
6. Example: A panel has persons A, B, C on it. B & C are dropped and it was C's last panel. D is added. For B & D it's a major change, for A & C it's a minor change. Minor because C has apparently cancelled everything, and doesn't need to hear from us. Start day/time is a major change. End time and room can be classed as minor changes. Updating A's contact info is a minor change, and arguably for B & D in our example it doesn't have to result in an e-mail message if they're the ones who told us to change it.
6-A. Changing rooms: it would be a minor change if still located in the same building, major change if moved to another function space.
6-B. The definition of "minor" and "major" change shall be controlled by Prog. It may vary from one convention's Prog to another. And Prog should be able to override how a change is labeled.
7. Most messages don't need to be CC'd to Prog. They can always look at the master database to see the current schedules. Sometimes they may want to do so anyway.
8. I believe a person's schedule should include all their appointments, which may mean two Divisions have to talk to each other. Example, Music GOH puts on a concert, performs during Masquerade Half-Time, appears at Opening Ceremonies and on a panel. They'll want to have all of that. They may even want their sound check listed too.
9. I believe a program item should include all of the people that need to be there, especially all of the people who might also need to be somewhere else at another time.
10. People, and rooms, should not be double-booked. This includes timeslots that start at the same time, and timeslots that start before another one ends.
11. "First Draft" and "Final" schedules should be available to be sent BEFORE the printed program's deadline. Sending out the "first draft" AFTER is just asking for trouble.
12. Issues that arose recently that could have been detected automatically by a computer: person A was booked for three consecutive timeslots that overlapped by 15 minutes on each end. Many, many persons were scheduled for three or four consecutive timeslots with no break to get a meal.
13. Other issues that resulted in an immediate change request: An "18-plus" item was scheduled for 12:15 pm instead of 12:15 am. A GOH who was contracted for two or three panels was placed on five on the same day. A featured guest was put on an "18-plus" panel, which is something she doesn't do.
14. Some people don't need their schedules e-mailed to them at all, such as convention event staff.
15. If a group is traveling as a pack for their panels (examples: Lolita Dark, Team Lift XMA, Captain's Savvy Sing-Along, Chocolate Covered Cosplay, and many groups of fans that applied for panels) it may be sufficient to send schedule messages to one person. If any of the group members participate outside the group, they should be listed in the schedule.
15-A. Some groups travel in packs, but not all members participate in all events that list the group name. Watch out for that sort of thing, and handle it somehow.
15-B. Some groups travel in packs, and appreciate getting individual e-mail messages because e-mail to the leader is an unreliable way to get messages to all.
Thoughts about Table Tents.
16. A table tent is a piece of cardstock (or cover stock) folded in half with a name printed on the side that faces the audience.
17. Some program items don't need table tents. Masquerade, for example, or anything where they're not sitting behind a table.
18. My preference is for disposable single-use table tents. Last time out, we had 533 table tents for 257 program participants on 354 program items.
19. Printing all of these should be easy to do.
20. When we get to the stage of printing them, we'll want all the names of all the people who will be at the table, regardless of whether we send them e-mail messages about their appearance.
Thoughts about Applications.
21. An Application is a form that can be filled out, often during a limited-time window, and approval is not guaranteed. We'll say "Applications" to refer to all of them, and "Form" to refer to just one that "Submitter" has submitted. "Dept" refers to the person or role with primary responsibility for approvals. "Div" refers to that person's direct report, or other boss.
21-A. Applicatiions have included; DJ, Fan Panel, Press, and Industry. Others too, that's just a sample list.
22. The start and end time for an Application's limited-time window should be clearly visible.
23. It would be nice if the Application's window status is clearly visible -- APPLICATIONS NOT YET OPEN, APPLS OPEN, APPLS CLOSED, APPLICATION CONFIRMATIONS SENT. Maybe color-coded on the web page.
24. A Form's data should be stored in a proper database, not a CSV spreadsheet. (CSV files break down when there are very long lines involved, and they also don't like embedded line breaks.)
25. Some approved Forms will result in free badges for Submitter. If that is the case, we may want to specify a maximum number of badges. (We saw a number of Press forms asking for extra badges in the Comment field, rather than submitting multiple forms.)
26. After Submitter has submitted a form, Submitter should be able to determine its status.
27. Submitting a form may result in an e-mail message being sent directly to DEPT. Or, DEPT may get periodic summaries of the forms submitted so far. It should definitely result in an immediate message back to Submitter.
28. DEPT should have a way of updating a form's status. Possible states could include SUBMITTED, PENDING, MAYBE, YES, NO. Or perhaps those last three should be FINAL ROUND, CONFIRMED, DENIED. (Pending means someone's actually looked at it, and we don't want Submitter to rewrite the form.)
29. We ought to give Submitter the ability to modify its form, at least as long as it's still in "SUBMITTED."
30. DEPT should be able to log a NOTE that only DEPT & DIV can see, and also a MESSAGE that will be shown to Submitter.
31. We should have a way to produce a usable spreadsheet on demand.