Forum Building or Area
Forum Space or Room
Forum Schedule
I have some suggestions for making changes in them. While the suggestions will add a little more complexity to the data model, I think it will make it a lot easier to generate reports and avoid scheduling conflicts in the long run. These are the suggestions:
Forum Building or Area: This is perfect as is. This CCK type represents a single building (address, directions, etc.)
Forum Space or Room: This type has a field that links it to the Building or Area it is part of. That's also great. Currently this type also has a list of text fields where you are to indicate the times and dates that the room is available during the conference. The way these fields are setup will make it difficult to programmatically query them.
I would propose removing these fields from the Forum Space or Room CCK type. And, I would propose adding a new field called Schedule Block Availability. This field would be a node reference that allows for multiple values. The node reference would refer to a new CCK type called Forum Schedule Block (see below).
While on the subject of Forum Space or Room, I also think that this CCK type has too many fields (Project, bathroom access, etc.). I know having those fields would be great, but given the amount of data entry required I think it creates too much data entry stress and complication. I would suggest getting rid of everything after number of people it can fit (except restrictions and other comments). Asking people to fill in the number of electrical outlets for every room is really overwhelming!
New content type: Forum Schedule Block. This CCK type is a simple one that has:
Display Name (e.g. Morning Plenary or Afternoon Workshops)
Start Date/Time (e.g. June 27, 2007 9:00 AM)
End Date/Time (e.g. June 27, 2007 11:00 AM)
A new schedule block can be created at any time for any time period.
Forum Schedule: This existing CCK type would be modified. It would only have the following fields, all of which would be node references:
Session (a link to a single USSF Session Proposal) - the session proposal CCK node will provide all relevant information about the session sponsor, etc.)
Room (a link to a single Forum Space or Room - which in turn links to the Building or Area with full directions on how to get there).
Time (a link to a Forum Schedule Block - which in turns provides the date and time of the session).
With these CCK types, I would envision data entry looking like this (this includes some fancy javascript/ajax code that is currently existing as a fantasy in my head, but seems like it should be do-able):
Building and Areas are entered
Space and rooms are entered
Forum Schedule blocks are entered
(Obviously more can be entered at later dates, but this initial data entry will get the ball rolling).
To schedule an event:
Create a new Forum Schedule node
From the drop down, first choose the Session from the table of Session proposals (the drop down will only include sessions that have not yet been scheduled)
Next, either choose a Scheduling Block (once chosen, the list of Rooms is reduced to the rooms available during that block) OR choose a room (once chosen,m the list of Scheduling blocks is limited to the ones available for that room).
Next, choose either the room (if you started with the scheduling block) or the scheduling block (if you started with the room).
If we enter all data in this way, we can easily create a view based on the Forum Schedule that can display sessions in chronological order.
This sounds good! I think this should also allow us to use existing calendar modules (including the Timeline module) to automatically generate event calendars, yes? If not, is there an easy way to modify this so that we can?
Also, can I assume that each scheduling block is discreet? If sessions are 2 hours, and a room is available from 10AM-4PM, there's three blocks (10-12, 12-2, 2-4) instead of one block (10-4), correct?
I think that the Forum Schedule Block CCK type can be an "Event" type (since it has a start time and end time) which I believe will allow us to do all the fun calendar stuff. However - I'm not sure that the fun calendar stuff can deal with the fact that the actual information about the event comes from related nodes. :(. I think the default way an Event type works is that the calendar display info in that type itself. We should explore this before moving forward.
As for the scheduling block/discreet question:
Yes - that's exactly correct. And if there as a block from 9:00 am to 11:00am, you would not indicate that the room is available for that block (since the room doesn't become available before 10:00 am). Similarly, there could be overlapping blocks defined. So, maybe you'd say the room is available for all of these blocks: 10 - 12, 12 - 2, 2 - 4 AND 10 - 3.
There will need to be some kind of logic that will prevent you from scheduling a room with both the 2 - 4 block and the 10 - 3 block - but that shouldn't be terribly difficult.
Hey all,
Just getting up to speed with this online discussion. Didn't know it existed and was doing email with Ana and Jamie. I'm on a work deadline (yeah, I guess I have to pay the bills somehow!) so I don't have time to give a full rendition of issues from a on-the-ground space perspective right now. Will try to write something up more detailed this weekend after our Scheduling conversation tomorrow.
The quick issue for me is to Please, Please, Please do not delete any of the specs info I have input regarding the rooms... it took a long time and we understand that those doing sessions in rooms will need that information as well as site managers. I am not sure that is even contemplated by the discussion above because some of it was lost on me, but I wanted to be sure this decision was not being inadvertently made somehow. Thanks!!!! I will be putting in a Tech request related to some queries on the database that we will use on the ground here but haven't made it a priority since I have not yet input all the data.
I look forward to discussing this more with you soon. Thanks!!
Back to work:(....
Susan
Hi Susan - no worries! I saw how much work you've put into the scheduling rooms, which is why I proposed working with what you've entered rather than making a change. I think we can make it work. Thanks for all the data entry you've done.
jamie
Thanks for alleviating my fears:)! We missed you on today's scheduling subcommittee call. Seems that things are changing a bit. Due to the many special considerations for various workshops, and the pressing deadline for the printed program schedule, a team has formed to do a physical match of space with workshops - Allison from Program with the ad hoc printed program team: Stephanie, Luke & Jules (and me sort of adjunct, though I missed their conversation yesterday). The match will be used for the printed program which has a fast-approaching deadline, and will be useful for building and room signage.
So, the main question for me is whether that workshop match information will then need to be uploaded in a similar manner as the other data entry I've done... or can be uploaded as a PDF or Excel sheet... so it can be viewed and searched as we approach June 27 and during the USSF.
A secondary question is whether there is still an online scheduling plan for "open space" (times other than workshops and other program uses) and how this will work. A sub-issue is how to make sure we have blocked out all the programming times - workshops, receptions, films, children social forum, other uses. I think this is something that will need to be answered by the NPC at their next meeting.
I look forward to hearing your thoughts.
And, have a great holiday weekend!
Susan
(16:50:31) Channel founder on scheduling is jamie
(16:50:39) ana: hey jamie
(16:50:40) jamie: hey ana
(16:51:01) ana: so scheduling...can you remind me where we last left off?
(16:51:09) jamie: I'm experiencing some latency so be patient if it seems like I'm not responding right away.
(16:51:15) ana: sure
(16:51:27) ana: latency in thhefriedian sense?
(16:51:35) ana: the freudian sense
(16:52:17) jamie: I'nm not even sure what freud said about latency! if my internet connection was doing mored quickly i'd wikipedia it :)!
(16:52:46) ana: he likened it to strange sex feels at the age of 7...for ones mother, I think...
(16:53:33) jamie: of course, I think you have to add "for ones mother" to everythingbout friedu
(16:54:03) ana: exactly
(16:54:15) ana: he was so fond og the nipple
(16:54:18) ana: of
(16:54:48) jamie: yeah, liked the nipple, but apparntly not athe women attached to them.
(16:54:57) ana: lol
(16:55:09) ana: do any of us ever?
(16:55:13) ana: ;)
(16:55:14) jamie: so, here's the latest that I've worked on :
(16:55:22) jamie: http://www.ussf2007.org/en/node/2075
(16:55:46) ana: lookingnow
(16:55:50) jamie: ha - maybe not our own - but at least we don't condemn *all* mothers :)!
(16:57:38) ana: k...i'll comment as i go
(16:57:52) ana: the schedule block is not an issue. I can do that this week
(16:58:03) ana: the too many fields is what susan wanted
(16:58:13) ana: ialthough i agree, i think it is important to her
(16:58:37) ana: she is wanting to do the work...
(16:59:59) ana: regarding scheduling and having only the 4-5 fields mentioned...
(17:00:20) ana: i'm worried about if people want to schedule their own events...
(17:00:23) ana: what then?
(17:00:39) ana: also, can we restrict the list of proposals and films to accepted ones only?
(17:00:44) ana: at least for proposals?
(17:01:22) ana: regarding people scheduling their own events (dynamic events and mapping idea) maybe that should be it's own CCK node_type?
(17:01:28) ana: jamie, you there?
(17:01:37) jamie: yes
(17:01:52) jamie: reading and thinking (and re-reading my notes, because I realize I don't remeber exactly what I wrote)
(17:01:56) ana: k
(17:01:59) ana: take your time'
(17:02:59) jamie: on too many fields: I don't think we should remove them without getting consensus from Susan, but I do think we should strongly encourage her to leave them out to simplify the data entry. If she won't budge, then ok. But i think that's our responsibility as people with experience with databases.
(17:03:24) ana: sure
(17:03:45) jamie: as for scheduling: I think you are experessing the concern: we need a system that will allow both the programming committee to schedule things but also allow people to schedule events not officially approved by the scheduling committee. is that correct?
(17:03:58) jamie: or - are you expressing the opposite concern?
(17:04:29) ana: nope that is my concern
(17:05:15) jamie: so, we should *shouldn't* restrict the list of proposals to ones that are "accepted", right?
(17:05:20) jamie: wait...
(17:05:38) jamie: so we should *not* restrict the list of proposals to ones that are accetped by the programming committee, right?
(17:05:42) ana: we should restrict that node reference to only ones that are accepted
(17:05:58) ana: but also have an option for people to enter in another place their event information
(17:06:20) ana: and have that information scheduled
(17:06:39) jamie: hm. I see you logic from a permissions stand point,.
(17:06:41) ana: or even have those fields that exist there autopopulate if their attached to a node reference
(17:06:53) jamie: however, from a report generating standpoint it would be nice if everything came from teh same tables.
(17:06:58) ana: the ones like 'description' and 'event name'
(17:07:35) jamie: hm - I'm not sure I follow. Can you describe in more detail?
(17:08:15) ana: sure, so if you look at those fields: http://www.ussf2007.org/admin/node/types/content_forum_schedule/fields
(17:08:49) ana: there are some fields that are maybe superfluous:
(17:09:05) ana: Event Type is important
(17:09:21) ana: so that people can filter based on what kind of event they want to see information for
(17:09:46) ana: Event Description is important for events that people want to create and add themselves
(17:10:02) ana: Event Title: same
(17:10:08) jamie: I don't think event type or description or title are needed there.
(17:10:27) ana: But if there is a session node reference
(17:10:34) jamie: Instead - there's a link to the node reference to the session proposal which should have this info.
(17:10:51) ana: it should automatically populate the tittle, event description fields
(17:11:10) jamie: right - then that data is only entered once.
(17:11:16) ana: but if it is an event that someone creates and wants people to know about, it won't have a node-reference
(17:11:32) ana: let's say i am a professor, and have access to space
(17:11:40) jamie: unless we allow all registered users access to all these cck types we're describing.
(17:11:50) ana: and i am networking with folks in a way that I think deserves more attention
(17:12:29) ana: then I can go online and say 'everyone, this group is going to meet at this address at this time and we are going to discuss this topic and come if you want
(17:12:47) ana: by inputting something here, that then becomes available to all folks'
(17:13:09) ana: this way, this node type will 'moldt' in a way once the conference starts
(17:13:25) ana: to become a democratic forum in which to post other opportunities
(17:13:54) jamie: but - what if everyone hass access to these cck types, so anyone can add a building, add a room, or add a scchdule?
(17:14:19) jamie: so - the process for scheduling ane vent is the same, whether it is "officially" accepted by the pgoramming group or not.
(17:14:35) ana: so in that case it's looking like those types of events that people want to post, should be it's own CCK type
(17:14:56) ana: and should happen separately from this CCK type
(17:14:57) jamie: no - they should be session proposals, no?
(17:15:05) jamie: we already have that content type.
(17:15:08) ana: in other words that this CCK node_type should not have to moldt
(17:15:21) jamie: I'm not sure what you mean by moldt
(17:15:48) ana: ahh - so you are saying that people should do this by entering session types, and then scheduling their session types...
(17:15:56) ana: but this makes it too complicated for folks
(17:15:59) ana: too much training.
(17:16:00) jamie: right.
(17:16:22) ana: so we should have the events people spontaneously come up with be their own CCK type.
(17:16:35) ana: and have them listed in a different place on the website
(17:16:45) jamie: no - all events should be ussf session proposals.
(17:16:50) jamie: all of them.
(17:16:59) jamie: that's what they are: someone proposing a session.
(17:17:01) ana: how will this work?
(17:17:55) jamie: the same way it's working now: people will enter session prosals. Unless someone from the proposal admin team specifically sets it to "rejected" - which they should only do for violent/clearly anti ussf sessions, it becomes available to be scheduled.
(17:18:12) ana: okay...
(17:18:28) ana: but who will schedule it?
(17:18:31) jamie: Then - anyone can create a new "building" and a new related room (yes, a bit difficult, but we should deal with that as a UI issue, not change the data model)
(17:18:43) jamie: and then, they can schedule their own event.
(17:19:01) jamie: If the session proposal is "accepted" (which only a proposaal admin can do), then it gets a special star
(17:19:09) ana: but they will have to be lead through a tutorial or really well designed GUI to know how to do this
(17:19:12) jamie: but otherwise, all events appear together.
(17:19:36) jamie: I don't think it will be that difficult.
(17:19:47) jamie: I think the hardest part is the idea of creating both a building record and a room record.
(17:19:58) jamie: maybe we could come up with a gui for doing both at the same time.
(17:20:20) jamie: After than - you just create a schedule record, and select from teh drop down: the room, the session propsoal, and the scheudling block.
(17:20:35) ana: in which case the room would automatically select the buidling?
(17:20:43) ana: that was beign entered?
(17:20:43) jamie: yes - because they are related.
(17:21:43) ana: k
(17:22:06) ana: will ther ebe a proposal admin checking these?
(17:22:13) ana: during the forum?
(17:22:21) ana: or will they need to have been accepted?
(17:22:32) ana: to be on the list of proposals?
(17:23:03) jamie: I think the criteria should be: they cannot be in a "rejected" state.
(17:23:22) jamie: that means that if the proposal admins get overwhelmed, people can schedule their own "pending" proposals.
(17:23:46) jamie: if a fucked up proposals get scheduled, then the proposal admin marks it "rejected" and it disappears from the list.
(17:24:01) jamie: but - we're not getting held up by the proposal admin process.
(17:24:11) jamie: if people have the resources to schedule their own sessions.
(17:24:32) ana: what I am worried about is that when the admins are scheduling 'accepted' proposals, they won't want other non-accepted' proposals on that list
(17:24:34) jamie: we are only responsible for clearly denoting which proposals are "officially" accepted by the proposal group
(17:25:00) jamie: ok - maybe we could have some ajaxy button limit the list to "accpeted" one.
(17:25:11) jamie: I know I"m in un chartered territory
(17:25:17) ana: because i think that 'accepted' proposals are the onnly ones that the proposal admins wil be officially scheduling
(17:25:46) jamie: yes - I hear you. We need an interface that makes sense to them.
(17:26:02) jamie: And that doesn't concentrate the scheduling in their hands.
(17:26:15) ana: what do you mean by the button...maybe what we'll want to do is have that list be limited until the forum starts, and then we will remove the limit to say only keep out 'rejected'
(17:26:32) ana: ?
(17:26:41) jamie: well, I envisioning a lot of ajax/javascript stuff on the scheduling form.
(17:26:54) jamie: this form essentially is just three drop down lists:
(17:27:00) jamie: Proposals
(17:27:02) jamie: Rooms
(17:27:08) jamie: Scheduling Blocks
(17:27:49) jamie: It would be nice if there was a button, that executed some kind of javascript, that would limit the proposals in the proposals drop down to: all non-rejected proposals OR all accepted proposals
(17:28:16) ana: is that posible?
(17:28:19) jamie: Then - the proposal admins (and this woudl be the default) would see all accepted proposals.
(17:28:19) ana: what about films?
(17:28:32) jamie: in theory it's rather straigth forward - but requires some clever programming.
(17:28:41) jamie: I don't know very much about films.
(17:29:02) jamie: Is there a reason this is a different cck type than other proposals?
(17:29:29) ana: the main reason is that it is a different program group working on thses
(17:29:36) jamie: ah.
(17:29:39) ana: but they will need their own level of attention
(17:29:44) jamie: is there a system for approving and rejecting them?
(17:29:45) ana: similarly to proposals
(17:29:59) ana: exactly, there should be soon, but I haven't heard from them yet
(17:30:05) jamie: hm. Are they on workflow, or are they using a cck field for approving/rejecting?
(17:30:21) ana: i expect we will in a couple weeks and might want to take similar precautions/actions as with proposals
(17:30:29) jamie: yup
(17:30:48) jamie: I would think the best method would be to have the "proposals" drop down include both proposals and films
(17:30:54) jamie: so there's one field for the target event.
(17:31:20) ana: i agree
(17:31:46) ana: can we bootstrap the same acceptance procedure/workflow for films without creating a whoole new shebang?
(17:32:02) jamie: I think so. Do you know who the film people are?
(17:32:26) ana: not off hand
(17:32:35) ana: i think they are listed as a progeam area?
(17:33:25) jamie: ok
(17:33:33) jamie: I was just checking out a sample film submission:
(17:33:39) jamie: http://www.ussf2007.org/en/node/2000/edit
(17:33:59) jamie: looks like there are not fields for accepted, etc. So we may be in time to use workflow without have to translate existing data.
(17:34:09) ana: yeah
(17:34:32) ana: can we just plug it in? and what about the same UID issues?
(17:35:35) jamie: looks like all the film submissions are currently anonymous :(
(17:35:47) ana: exactly what I was worried about
(17:36:38) ana: i plugged in the workflow for new proposals, but the same thing will have to happen as before for old ones
(17:36:43) jamie: I have the following suggestion for action (I think you have to leave soon, right?)
(17:36:48) ana: to have them added to the state
(17:36:51) jamie: ah.
(17:37:19) jamie: the workflow from ussf session proposal?
(17:37:47) jamie: dkg is pointing out that that workflow is rather vague
(17:37:48) ana: yes. so we will have to add all of the existing workflows for films to the state 'created'
(17:38:14) jamie: and that we might want to create a new work flow for them, rather than give them a workflow that we can't even explain.
(17:38:26) ana: i can do that...
(17:38:31) jamie: ok.
(17:38:34) ana: but then can dkg add them?
(17:38:38) jamie: I'd suggest:
(17:38:41) jamie: created
(17:38:42) ana: the ones already submitted?
(17:39:09) jamie: right
(17:39:11) jamie: then:
(17:39:17) jamie: accepted by ussf
(17:39:25) jamie: rejected
(17:39:30) jamie: hm. still thinking...
(17:39:44) jamie: maybe:
(17:39:56) jamie: created (which means pending review)
(17:40:10) jamie: accepted (means that it meet bare minimum guidelines)
(17:40:38) jamie: or no... instead of "accepted" maybe it should be "reviewed"
(17:40:40) ana: i would think that we need one to say: and we will give it a space
(17:40:57) jamie: then: approved (yes - which means we will give it a space)
(17:41:12) jamie: and finally: rejected (this is not consistent with ussf values)
(17:41:27) jamie: so: created, accepted, approved, rejected
(17:41:33) ana: http://www.ussf2007.org/en/admin/workflow
(17:41:45) ana: done
(17:41:52) ana: can dkg do his magic?
(17:42:10) jamie: cool!
(17:42:13) jamie: i'll ask.
(17:44:00) ana: and we need to match existing emails with uid's also
(17:44:20) ana: i'll work on getting similar language to the session proposals up, and fixing permissions...
(17:44:43) jamie: ok...
(17:44:47) jamie: just got a brain dump from dkg
(17:45:03) jamie: he said we should changed "created" to "unreviewed"
(17:45:25) ana: done
(17:45:27) jamie: and then allow all users the ability to change from "created" (which is a built-in state) to unreviewd.
(17:45:46) jamie: if that's the only thing they can do - it should happen automatically.
(17:46:10) jamie: the reason is because you can't transition into the "created" state.
(17:46:31) jamie: so - with that in place, dkg's magic will take all nodes that are not in any state, and translate them into "unreviewed"
(17:46:54) ana: so the 'created' state is changed to 'unreviewed' we do not need a created state, no?
(17:47:05) jamie: no - that's built-in
(17:47:10) ana: okay
(17:47:12) ana: sweet
(17:47:53) jamie: ok.
(17:48:15) jamie: so next steps, I think, are:
(17:48:32) jamie: modifying the scheduling cck types to meet the new spec
(17:48:49) jamie: transistioning all film nodes to "unreviewed"
(17:48:58) jamie: contacting the film group to let them know how it works
(17:49:13) jamie: building the special schedule cck form with all the ajax magic
(17:49:19) jamie: does that sound about right?
(17:49:55) ana: yup
(17:50:13) jamie: can you take: modifying the scheduling cck type and contacting film group
(17:50:22) jamie: I can take transistion all film nodes and working on cck form
(17:50:26) ana: i'm transitioning the workflows part with respect to submetter instructions to register for site and forum
(17:50:30) ana: same as proposals
(17:50:39) jamie: sounds good
(17:50:46) ana: and getting them to have access denied if they haven't registered...
(17:50:54) jamie: cool.
(17:51:50) ana: i'll make the changes we talked about tomorrow
(17:51:58) jamie: sweet.
(17:52:01) ana: regarding the cck types
(17:52:14) ana: if you could start envisioning and creating the backend magic, that would be great
(17:52:32) jamie: ok - I may not start before tuesday, but will definitely get on it.
(17:52:36) ana: sweet
(17:52:39) ana: thanks, Jamie
(17:52:44) ana: i gotta go
(17:52:46) jamie: no prob - nice working with you as usual.
(17:52:50) ana: great alsways to get to work with you'
(17:52:53) jamie: ok - take care.
(17:52:58) ana: bye
(17:53:10) jamie: ciao
Below is a plain description of how the ICT teams proposes that we handle scheduling for the ICT:
There are several "types" of information that we need to schedule a session. Each one is entered into the system separately:
Forum Building or Area - This is a building or area that holds many roomt, for example, the Civic Center. It contains the name of the building or area, the directions, etc.
Forum Room or Space - This is a room or space within a building. Every Room or Space is linked to a Building or Area. It contains the room number, how many people it can hold, etc.
Session Proposal - this is the type that people are currently submitting their proposals as (it contains the full proposal information)
Forum Schedule Block - This is a date and time period (for examle, June 27, 4:00 - 6:00 pm). We will add every block of time that we expect something to be scheduled. There can be overlapping blocks.
Forum Schedule - This is the type of content that links everything together. Each "Forum Schedule" record will include:
The Session proposal
The Room or Space (which is linked to a building or area)
A Schedule Block
Once you create a record with those items, the session will be scheduled and will show up on the calendar and list of events.
Current Status:
Susan Somach is currently entering all the Buildings and Rooms that have been secured by the NPC.
We still need to have the Schedule Blocks entered.
Once the schedule blocks are entered, it will be possible to schedule events. However, the ICT team will need to spend about 10 - 15 hours of programming to make this process workable. For example, when entering scheduled events, there are no checks to prevent you from double booking a room or scheduling a room for a time when it is not available. This programming work will probably not be complete for about 2. 5 weeks (then end of May).
I just noticed that we missed one change to the Room or Space CCK type. The idea was that each Room or Space would be linked via node reference to a Schedule Block, based on when it was available.
Instead, currently, the Room/Space CCK type has text fields for each day, in which the time (8:00am - 11:00am, 4:00pm - 6:00pm) is entered.
I was worried about parsing those times - given that humans can make mistakes and not enter them all properly.
At this point, however, Susan has entered a lot!! And, from a quick check, has entered them all consistently as required. So - at this point, I'm thinking that we should leave as it and write code that can parse the expected format (and maybe some expected variations) instead of linking it to the Scheduling block as previously thought.
We've made a few minor changes to the approach for scheduling.
We are hoping complete a prototype of this system by the end of this weekend.
The planned user interface will work along these lines:
If you are logged in with the right privileges and you view a session proposal, there will be a link called "Schedule this proposal." If you click the link, based on the date requested and the number of people expected, the system will propose 10 room/time combinations (i.e. Room #1, Civic Center, Thu. 9:00 am-12:30 pm). You can either select the ones proposed, or choose to schedule it manually. If you choose to schedule manually you will get a drop down of a gazillion available room/time combinations.
The idea behind this setup is that we have:
Buildings/Locations (the 7 or so areas where events are scheduled)
Room/Spaces (the individual rooms in these spaces)
Schedule Blocks - the blocks of time to be scheduled (for example, Wednesday, 7:00am - 9:00 am).
Thanks to some great data entry by Susan, it seems as though most of the rooms have been entered.
We still need data entry to happen on the blocks though!
Once we have the potential schedule blocks filled out, we will auto-create all the potential "room/time" combinations.
Hey Jamie,
Thanks for the update! I have a few comments/questions:
1) Will it go from areas (the 7 or so, though a few are off the grid and will need to be redefined) - to buildings/locations (23 for now) - to rooms/spaces?
2) I am still entering space information.
3) We need to decide how the timeblocks will be designated. For workshops, it's clear 10:30 - 12:30, 1:00 - 3:00, 3:30 - 5:30. But for the rest of the time - "open space" we'll have to designate slots by the half hour or hour. Note that some spaces availability starts on the half hour for example.
4)Once again, I think the assumption is that I'll input all the physical workshop and special request match info once the printed program people get it done. Their deadline is sometime next week, so I should be able to start inputting after that.
5)There will be additional space requests that will come in after the printed program deadline that will need to be matched up. Does the new plan you've described make sure space will not be double booked?... or will there need to be one "booking agent" who makes sure it doesn't happen.
I looked through the scheduling CCK types:
Forum Building or Area
Forum Space or Room
Forum Schedule
I have some suggestions for making changes in them. While the suggestions will add a little more complexity to the data model, I think it will make it a lot easier to generate reports and avoid scheduling conflicts in the long run. These are the suggestions:
Forum Building or Area: This is perfect as is. This CCK type represents a single building (address, directions, etc.)
Forum Space or Room: This type has a field that links it to the Building or Area it is part of. That's also great. Currently this type also has a list of text fields where you are to indicate the times and dates that the room is available during the conference. The way these fields are setup will make it difficult to programmatically query them.
I would propose removing these fields from the Forum Space or Room CCK type. And, I would propose adding a new field called Schedule Block Availability. This field would be a node reference that allows for multiple values. The node reference would refer to a new CCK type called Forum Schedule Block (see below).
While on the subject of Forum Space or Room, I also think that this CCK type has too many fields (Project, bathroom access, etc.). I know having those fields would be great, but given the amount of data entry required I think it creates too much data entry stress and complication. I would suggest getting rid of everything after number of people it can fit (except restrictions and other comments). Asking people to fill in the number of electrical outlets for every room is really overwhelming!
New content type: Forum Schedule Block. This CCK type is a simple one that has:
Display Name (e.g. Morning Plenary or Afternoon Workshops)
Start Date/Time (e.g. June 27, 2007 9:00 AM)
End Date/Time (e.g. June 27, 2007 11:00 AM)
A new schedule block can be created at any time for any time period.
Forum Schedule: This existing CCK type would be modified. It would only have the following fields, all of which would be node references:
Session (a link to a single USSF Session Proposal) - the session proposal CCK node will provide all relevant information about the session sponsor, etc.)
Room (a link to a single Forum Space or Room - which in turn links to the Building or Area with full directions on how to get there).
Time (a link to a Forum Schedule Block - which in turns provides the date and time of the session).
With these CCK types, I would envision data entry looking like this (this includes some fancy javascript/ajax code that is currently existing as a fantasy in my head, but seems like it should be do-able):
If we enter all data in this way, we can easily create a view based on the Forum Schedule that can display sessions in chronological order.
How does this sound?