BoF Scheduling tool

ezra-g++

Just to clarify, the attached PDF shows slightly outdated flow/wireframe, but we will update it soon.

Modal windows (dialogs?) are also difficult to make accessible, particularly for screen-reader users. My suggestion would be to avoid their use unless it is absolutely necessary.

I would much, much rather see the following:

1) The main interface is DnD where the visible schedule and the scheduling interface are one and the same. This was a critical innovation that I think is being overlooked which made the workflow very intuitive.

To schedule, I click the tab for the day, cast my eye over the whole schedule and see what other BoFs might be at the same time, and then drag to a slot.

To unschedule or move between days, I drag from a time slot to the "staging" area that lists all my unscheduled BoFs.

2) An simple non-modal scheduling form that can be used by mobile devices, screen readers, etc.

@Ezra

1. It is not possible to detect screen-readers in order to serve alternate content.

2. Drag and drop causes problems for screen-reader users, keyboard only users, and other users, such as those using some mobile devices.

In Core we have addressed drag and drop (table drag) by exposing a link "Show row weights" which essentially allows the table drag interface to behave as if JS were disabled, even if JS is enabled in the user's browser.

At this time there really isn't a good way to reliably provide accessible drag and drop, so any drag and drop UI should also have a method of performing the same tasks from the keyboard alone. Note, that even this is not always sufficient. As an example, table drag can be performed from the keyboard, but insufficient feedback is available to screen-reader users to make this accessible, the method of using table drag from the keyboard (for sighted keyboard only users) is also non-intuitive.

@Ezra

I think that the bst approach is to have a design meeting where all possibl ideas, including pros and cons, can be discussed. I think that for a UI of this complexity / novelty discussion in the issue queue is going to be far less efficient. Let me know if you and others are interested and we can find a time to meet, perhaps on Skype or IRC.

I've done quite a bit of work already on the design of the display of Bofs in the mobile app (iPhone and Android both). While thinking through the mobile app interface, I got a lot of ideas about the web interface as well. I'll post what I've got here as soon as I have a chance.

And thank you Erza for opening this issue. There were too many separate discussions going on in hard-to-keep-track-of-places.

@ezra-g how do I see which other BoFs are scheduled at the same time while I'm deciding where to schedule mine? I am going to see if I can build a quick version of the DnD one this weekend. Short of trying to re-establish the Szeged site someplace, that seems liek the best way to let people feel the experience

Here's a functional prototype module (as feature) plus a DB dump that's configured with a couple bof days and a few misc sessions. The main dependency you might need is jquery_ui, in addition to features, cck, and date.

You can see the action at ?q=cod-bof/schedule and ?q=cod-bof/interactive/schedule assuming that some BoF program day nodes have been created.

Some of the table generation code is rough - hard coded html instead of theme(table). The thing looks ok in Gardland, haven't tried the Chicago theme.

Note all the roles/permissions, etc are quite built out, so it's not quite at a state to deploy.

If you restore the DB dump, each user name and pass are the same.

Here are a couple screen shots. Note that the rightmost column is wider, since that room will accommodate 3 BoF sessions.

Can someone please describe these screen-shots and describe the interaction pattern so that I can begin to assess if we are moving at all in the right direction to ensure that this is accessible to all users?

Subscribe

@Everett - The screen shots show the "static" and "dynamic" versions of the BoF schedule.

The static version is the one that would be e.g. projected in the conference center, or referred to by people to find a BoF. It's just a schedule organized in a html table by room (across) and time (down), so I hope it would be readily accessible to a screen reader.

The interactive version allows the user to drag and drop via JS within the html table to schedule or unschedule sessions. This is almost certainly not suitable for mobile devices or screen readers, so the plan is to have an alternative (see above comment from jensimmons) based on some kind of simple form that can be used to schedule each individual BoF session.

To reiterate, the credit for the concept, as well as some of the markup, CSS and code I used as a starting point belongs to Gábor who created such a tool originally for the 2008 Szeged Drupalcon.

@pwolanin

Is the DnD functionality progressively enhanced? What happens if JS is disabled?

JS doesn't need to be disabled for accessibility, but if the UI is progressively enhanced than the non-JS version might be an accessible alternative. With tabledrag we have essentially allowed users to use the non-JS version, even if they have JS enabled.

@Everett - at this point there is no progressive enhancement since in general I think the table will be too large to access via a mobile device, and the DnD generally won't work for those either. Hence, the intent to have an alternative. The pages with the DnD could be enhanced in a sense with a non-JS fallback by providing links on each of the user's sessions to get to the accessible form. By hiding the links with JS, we'd have a kind of progressive functionality when JS is absent.

Coming up with a reasonable accessible solution would be far easier for me if:

1. there were a place where I could test the current implementation, and

2. there was a design spec for the required functionality.

Here is a new tarball of the Feature code including a role and permissions. This includes placeholder functionality for the accessible form - the link is there and is hidden when JS is enabled, but the form is not built other than a dummy "Save" button since it seems like Jen/Ezra and others have ideas about how to make that work well and I don't want to waste my time.

Also included is a DB dump.

@Everett or anyone else - if you want me to put up a copy of this that's publicly accessible (but not advertised), use my contact form.

I'm about at the point where I won't have much more time to work on this, but perhaps it's done enough to add to the project codebase and others can add the mobile/accessible form?

The design document for the Chicago site has these 2 sections about BoFs:

BoFs

* Node (same type as session), jQuery UI
* Drag-n-drop scheduling in online whiteboard/grid
* A main difference in behavior compared to session is that anyone can create and schedule a BoF (or convert a non-selected session to a BoF), while only organizers have permission to schedule a session. see: http://drupal.org/node/358129

Birds of a Feather (BoF) Sessions are submitted by and ran by community members who are attending. Community members may submit BoF proposals or convert session proposals that were not accepted for the main program.

Every day several rooms or open spaces are allocated for BoFs - in some cases, a single space may be scheduled with multiple at the same time, while in other cases a room may be designated to hold only a single BoF due to its size or projection equipment. BoFs are self-scheduled and not moderated, so the BoF creator needs to be able to add it to the grid of open times/spaces, though event organizers need to be able to move BoFs especially between rooms in the event of unreasonable squatting.

Based on the existing COD architecture for session scheduling using features, this BoF feature does not actually use the same node type as the main sessions, so we don't expect to achieve the ability to convert a session proposal to BoF, but that's minor... copy/paste.

@pwolanin

Thanks for the additional information. After taking a quick look at the demo it is pretty clear that in its present state the UI will not be accessible to keyboard only or screen-reader users.

As far as I am aware, the mobile version of the schedule is part of a mobile app, not a mobile site (Jen can correct me if I'm wrong about this).

So, we still need to discuss a method of either:

1. Modifying the proposed drag and drop UI so that it is accessible.
2. Designing an accessible alternative UI (which needs to work with JS enabled, and ideally with JS disabled).

Again, I am available to discuss the issue should anyone be interested.

The current state should provide a link from each of your sessions within the "interactive" screen which takes you to a tab visible on the session node itself (so you'd also see it after completing initial node creation). I expect this tab will have a scheduling form which is totally free of JS, or at least fully functional in the absence of JS.

I do now see the "Schedule" tab on the node view. I was not able to find the session link on the "Interactive" schedule screen. The session is scheduled, but it is not a link.

Browsing w/ JS enabled.

I'm curious if it will confuse users that clicking on the Schedule tab doesn't take them to the interactive schedule. Also curious how easily screen-reader users will find it to discover the schedule tab, this will likely be less of an issue if it is easier to find the option from the interactive schedule.

Looking again at the Szeged code, it only supported interactive scheduling of one session at a time. Perhaps it would make sense to go back to that, since it would simplify a number of issues that arise when allowing all to be scheduled at once.

@ezra-g yes, I was considering those points in terms of data, especially in terms of showing a combined schedule. However, I'm a little unsure how to manage the coordination between the 2 features, or whether this code needs to become part of the session feature?

For example, there are session views which should not show BoFs, right? And the main schedule perhaps should not show all the time slots available to BoFs? Does it make sense that the BoF and session time slots are strictly coupled?

#1024938: Configurable room order on schedule and #1027430: Support different rooms on different days of the schedule will allow for a room that does not hold sessions on a day to not appear on the session schedule. That room could hold BoFs and appear on the BoF schedule.

It makes sense to me for the room node type to be the same between session or bof, though I'm not certain what to do about time slot nodes.

I'm not sure if time slots should be strictly coupled, no. There's an existing issue for #973988: Support overlapped time slots in the schedule. We should figure out how to handle time slots. Ideas?

Well, the code I put together is a bit ugly, but already supports different rooms on different days by referencing a node per day which has noderefs to rooms and a list of time slots.

To display both on the same time grid it would be helpful to have the day, room and time data work the same across both.

This BoF code has an actual date field on each BoF node, rather than using a node ref to a time slot node. that makes it less robust if time slots are changed, but possibly easier to integrate with other views and calendar.

While it's always encouraging to see someone jump in to help get things done — and thanks, Peter — I have some real concerns about the accessibility and usability of what's being proposed.

In the demo that Peter built, scheduling a Bof is a two step process. First you "create" the Bof and it shows up as a square at the top of the page. Then you "schedule" the Bof by dragging it down the page to an empty slot. Perhaps this could be fun. I think it's something to consider for a BarCamp-style event, where the whole group spends the first part of the first day planning a schedule together. (Traditionally BarCamps are planned with post-its stuck to a wall. Peter's feautre is an electronic version of that model. The thing is, our DrupalCon Bofs are not scheduled BarCamp style. Each person just picks a slot.)

Everett has already express great concern about the accessibility of this interface.

I am concerned about the usability for everyone.

This drag and drop interface will only work with a small schedule. Peter's demo site has only seven time slots on it, and only three rooms. The Bof schedule for DrupalCon Chicago is much bigger. How is a person supposed to drag and drop a box from the top of the page down to one of the last slots of the day, when the full list of sessions is 8 screens tall?

I sketched out one day's worth of Bofs will look like on the website to show what I mean. If you click on the image link below, and blow that jpg up to be an actual-sized picture of the website, you'll see that a full-days table of Bofs is very, very tall. Dragging something from the top of that page to the bottom is impossible. The drag-and-drop will not be fun for people, it will be upsetting.

http://extras.jensimmons.com/drupalconchicago2011/Bof_Grid_example.jpg

Instead I think each open slot should have a button in it. The user clicks the button, and then fills out a form with the Bof information. The time is pre-populated already in the form. When they hit save, the Bof is created and scheduled all at once, and shows up on the table automatically. One step. Done. This flow is much closer to what people do in person with a white board. Find the empty slot, and take it.

Here's a sketch of what having buttons in the open slots might look like: https://img.skitch.com/20110125-ekptqknmxh7hpb1rgpk25u87fw.jpg

I don't know what needs of the user the drag and drop fulfills. I highly recommend against it.

Yes, I don't think we can make this drag and drop scheduler work for DrupalCon bofs. Also take into account that rooms are available 24 hours a day. Even if we don't display all 24 hours by default, in theory, it could get rather long.

Here's a closeup of grid from the mockup that ezra-g, coltrane and I worked on for several hours. We are def suggesting that the user clicks the 'Schedule a BoF' link in the grid square they want to claim as theirs. We have only mocked up two columns but we understand there will be up to 8 rooms. In the rooms that can hold multiple BoFs, I think we should try to stack BoF titles rather than place them side by side.

Edit: oh yeah, I see jensimmons mockup does the same.

I have to agree with Jen here. Drag and drop is useful when you're doing a lot of reorganization. I simply don't see that happening here. You'll find an open slot, claim it, and be done with it. Reorganization is the edge case, and a drag and drop 2-step process is overly complicated.

I much prefer an edit-in-place or edit-in-popup or whatnot approach. I'm very -1 to drag-and-drop here as it seems to offer no practical benefit other than being cooler because DnD is cool.

Thanks Jen. To clarify, I think you're proposing one change from the OP, which is that the creation of the BoF content (title and body) happen in the same step as scheduling. Is that correct?

How would it work to reschedule a BoF with this one step method?

One consideration we had was that the scheduling form (perhaps a popup/modal dialogue, though that is not accessible to keyboard-only and screen readers) could list all of the user's created BoFs, allowing them to reschedule one of their previous ones rather than continue creating a new one in that slot.

I think the key aspect (for me) is being able to schedule in the context of the overall schedule grid, at least as an option when using a full-featured web browser.

The DnD piece worked well before, but it's by no means essential.

I like where #32 is going, but it's not clear how it would work if you want to create separately and then schedule a BoF session, or if you want to change the time for an existing session. Could we show this grid with links (or buttons) with a context of only one BoF session at a time? So the top might have a title like "Pick a slot for: My BoF session about COD". I'd prefer that to having to go into another window and having to select from a list.

re: the mockups in #31, I think we need to work to compress the grid much more vertically as suggested in #32. There would be no need have large times between each segment.

create separately and then schedule a BoF session

Please see the OP attachment, which outlines that method and is the basis of #32

I do like Jen's suggestion in #31. I am a bit confused about the workflow for rescheduling a BoF once it is in the schedule. Jen, can you please provide a bit more clarification about your ideas for this?

@Everett, the rescheduling workflow that ezra-g, coltrane & worked on is like this:

* An edit link will appear alongside BoFs titles you've scheduled in the BoF grid.
* Edit your session and at the top will be an overview of the BoF's schedule status (will reiterate date, time and room if scheduled). The only action here is to click an 'Unschedule your BoF' link (or it can be a radio button or checkbox, but link is probably the most clear).
* To reschedule, return to the grid and select a 'Schedule your BoF' link within one of the grid boxes.

@lisarex

So, on a BoF node that is not scheduled there will be a "Schedule your BoF" link that will bring up the schedule. On a BoF node that is scheduled there will be a link to unschedule? This sounds clear and simple to me.

I'm sorry, but, what in the world does "OP" mean? I decoded "DnD", and realized you don't mean Dungeons and Dragons, but.... (please people, using codes makes people feel like they don't belong.)

"OP" == original post. i.e. the thing at the top.

Hmm...OPP, how can I explain it
I'll take you frame by frame it
To have y'all all jumpin' shall we singin' it
O is for Other, P is for People...scratch yo temple
The last P Well...that's not that simple
It's sorta like a, well, another way to call a cat a kitten.................

You down with OPP! — Yeah you know me
You down with OPP! — Yeah you know me
You down with OPP! — Yeah you know me
Who's down with OPP? — Every last homie

About how to 'reschedule' a BoF.

I see two options.

1) The user who created it (and maybe other people they user-reference in as organizers) can edit the Bof node — and change the title, update the text, add new tags... AND change the time. If node reference is used to reference the Bof node to a time slot node (and prepopulate on creation a la Node Reference URL Widget) then when a user edits the node they can easily switch it to a different timeslot. The trickest part is to get the list of available timeslots to only display open slots, and not the ones that have already been taken. AND the list of room-time, anotherroom-sametime, firstroom-newtime, ... is not very UX happy. But this is a rare use case.

2) The other option is that the user can't move it from one time slot to another. They can cancel it (delete it?). And schedule another one. But not "move" it. This is the easier functionality to build.

It would be nice to be able to reschedule a BoF, but most Bofs are scheduled and done. Rescheduling means telling everyone the time has changed, and that's very hard to communicate. I think it is rare for someone to plan a BoF, publicize it, and a day or two later reschedule it. I think the more common use case is that when someone is planning their BoF and filling out the form, before they are really done (or maybe after they've hit save, but before they leave to go do something else), they change their mind about the time. Deleting what they've done and starting over in that case seems just fine.

I wish I had a more polished solution. Custom code could create a whole "rescheduling" interface that would be better than a node reference drop down list — and designing that could be fun. But I think it's unrealistic to expect we have resources to create something custom for such a rare use case. I think designing and implementing a great interface for the main use case is enough. Trying to do too much on too few resources is where design starts to go to crap.

Here's what I do know. We need more than Title and Body. We need people to check off:
[] Beginner
[] Intermediate
[] Advanced

[] Coder
[] Site building and Implementation
[] Theming
[] Design / UX
[] Drupal Community
[] Business and Strategy

AND add tags — which could be things like: Drupal 8, fun, movies, code sprint, strategy, how-to, php, jquery...

In other words, TAXONOMY.

It will be especially important for the mobile app. With hundreds of Bof sessions, people needs ways to find them besides navigating through page after page of a schedule table.

http://chicago2011.drupal.org/schedule

You'll notice that on the main Drupalcon schedule the time and first session are in the same column. Can we please try to avoid that with the sessions (even if it requires fixing the actual schedule for consistency)?

Reasoning is that this is not really the proper way to design a semanticly correct table. And, means that the table is more difficult to access witha screen-reader.

Yes, I did read the pdf in the top post. If people are allowed to change the time, "unscheduled" could easily be a "time slot" that to which a BoF can be nodereferenced. (#1 in what I was just saying.)

Yeah, the table is just done wrong. That's not semantic at all. The time should be above the row, not in the first cell — and in a <th>. The data won't get collected by search engines properly either.

About the mobile app — there is one under development now. It's designed and half-built. A native mobile app, not a mobile website. It's been designed for the DrupalCon Chicago dataset, and UX for Chicago. It's definitely being built with future DrupalCon's in mind. And can be adapted after the fact for COD. It's tough, though, honestly to design an all-purpose, use this for any event evar mobile app when most events don't have a workshops + a three-day session schedule + a BoF schedule + a exhibit hall day stage schedule + keynotes and parties and other events. It's a tremendous amount of information — what everything is, where, when... To get an easy-to-use app, I designed it for *Chicago*'s needs, not for every kind of camp or conference that might use COD. Our hope is that London will use this app, for sure. Perhaps a more-flexible, less DrupalCon-centric-UX codebase can be created in the future for COD. Meanwhile, we are simply focused on getting it done.

Honestly, for COD, I'd recommend theming COD using media queries. Then you can provide a mobile experience out of the box, no matter what kind of conference people have. Our app will ship pre-populate with data, and grab updates from the cloud. And since it's a native app, you have to have an Apple developer account and know how to compile the code to make your own app — there's no easy way to make one COD app for everyone's event ever. It has to be custom.

re #49 - you have put a header cell <th> inside a row - that's the markup my mockup had based on the Szeged schedule.

For theme('table') you need to do it like this as the first or last element in the row

    $rows[$time_range]['data']['time-left'] = array('header' => TRUE, 'data' => $time_range);

Reading through the comments I can see benefits to both approaches.

The Drag and Drop interface, especially the idea of creating (several) sessions that can then be dragged onto the schedule would be very interesting in defining an agenda/schedule in real time in front of a group. I have a different terminology view than jensimmons, my experience is that kind of scheduling is done during the first session of pure unconference or open space technology events versus bar-camp type events where the agenda is generally done in advance. Having this feature would extend the applicability of COD to those unconference events. Added: This article on unconferences just showed up on my rss feed: http://www.meetings-conventions.com/articles/planning-the-unconference/a...

But for BOFs during a larger conference I would think finding a slot with availability on the schedule, then clicking on a link to define and schedule that BOF seems most intuitive.

I'm also curious. There were multiple references to unscheduling then rescheduling a BOF session. Does that happen frequently? It would seem to me it would be rare enough that simply deleting the BOF if it got cancelled and entering it again as a new BOF if it got rescheduled. Or am I missing something?

I think it's not that uncommon to need to move the time - e.g. if you realize later another BoF or main track session conflicts. Certainly a minority, but I think it's easy enough to implement that there's no need to make it hard.

I just had another idea related to this.

At DrupalconSF, there were large screen TV's with the session schedule.

It would be great to have a display of the current and upcoming BOF sessions with no extraneous information that could be shown on a large screen TV.

@gregmarshall - yes I certainly hope and expect we will do something like this for the BoF portion of the schedule. A big advantage of the schedule being online is that we could have such displays in multiple locations.

Here's the beginnings of a bof self-scheduling tool following the method discussed in ezra-g's first post. That is, a grid with inline links to schedule BoFs, without drag-n-drop. We (GVS) have been hired by the Drupal Association to build it for the DC Chicago site.

The attached screenshot shows a table grid with rooms along the top and time slots along the side. Within each cell is a list of the scheduled BoFs (if any), the count of available slots for BoFs, and a link to "Schedule a BoF" (if there is availability in that slot) that link to the node add form for BoFs using Prepopulate module.

To test

* Download cod_bof.tgz file and extract in cod_support
* Apply cod_support-session-validate.patch in cod_support
* Download and enable prepopulate module
* Revert COD Session feature (to get new room field)
* Create (or edit) rooms with an integer session capacity
* Create time slots
* Visit program/bof-schedule to see schedule view
* Click "Schedule a BoF" link to schedule a bof

Questions

* If any modal/popup functionality is activated only by Javascript how accessible is this?

To do

* The room nodereference field is set to unlimited. BoFs should (in most cases) be in one room, so the form should be altered
* Figure out rescheduling, perhaps using a checkbox on the BoF edit form that upon submit removes referenced room and time slots
* related, list "unscheduled" BoFs on the BoF schedule page or provide a way of seeing "my unscheduled BoFs"
* "Enhance" the scheduling and rescheduling using Javascript
* Decide if all days should be shown on the same page, or if earlier and later days should be in other tabs (or similar)
* Decide if all hours should be shown or if early-morning/late-evening hours should be hidden by default

@coltrane

"If any modal/popup functionality is activated only by Javascript how accessible is this?"

If you point me to a demo site and tell me what action will cause a modal to appear I can take a look and give feedback on accessibility.

Thanks Everett, the current code doesn't provide that yet, so I'll work on it and once ready we'll also get a dev site setup for testing. Then we can modify to be more accessible.

Here's an updated cod_bof feature with provides some re-scheduling.

The attached screenshot shows the interface, which is the node add form for BoFs. Like creating a BoF, the user will click on the "Schedule a BoF" link within a cell of the BoF schedule grid. If that user has created any BoFs, including currently scheduled BoFs, they will be listed above the BoF title textfield. Clicking on one of these links will take the user to the edit form for that BoF, where the time slot and room are set to the previously chosen slot from the BoF schedule grid.

Steps and text:

1. User has already created and scheduled a BoF, "Views remystified", for 1pm to 2pm in Room-A
2. User is on BoF schedule grid and clicks "Schedule a BoF" in the 10am to 11am in Room-B slot
3. User is on BoF add form, at the top is the question "Re-schedule BoFs for 10:00AM - 11:00AM?" and below is listed "Views remystified currently in Room-A at 1:00PM - 2:00PM" followed by standard node add form
4. User clicks on "Views remystified" link, is on that node's edit form, and clicks save
5. User is now on BoF schedule grid and "Views remystified" is listed in the 10am-11am slot in Room-B

It may not be obvious that to re-schedule the user can click on the "Schedule a BoF" link, so perhaps next to scheduled BoFs there is an "edit" or "unschedule" link (if that user submitted that BoF)?

Can we please skip the modal/pop-up/anything dialog as part of this plan?

I'm not following why there is an unlimited noderef for room - why is that not defined as single valued?

I also think the interaction model might be simplified and improved by only allowing one of the user's BoFs to be scheduled at a time. Then each link (or button?) on each time slot would have the effect of scheduling that one session in that slot.

So it seems like the goal of the above is to allow the user to pick the slot before the BoF node is created. But, that seems to introduce the need for complex error handling or validation since the slot may become unavailable while the user is filling in the node form. After node creation the user could be redirected to the scheduling grid instead, and the likelihood of them colliding over choice of slot would be lower. The error handling becomes easier here too - go back to the grid with a DSM and try again.

I have to agree that if this can be designed w/o a modal it is best. I am happy to test the modal if it goes in, but modals are poorly accessible to screen-reader users (in most situations).

To be clear, the code in #59 does not implement any modal/popups/fancyness. Each link does a full new page.

I'm not following why there is an unlimited noderef for room - why is that not defined as single valued?

We are re-using existing COD content types and CCK fields. Regular sessions can be in multiple rooms (like a keynote, or lunch) so the noderef to a room must allow multiple. The form alter code is relatively small. If it's best to rearchitect the room/slot/session design, we can. But this code currently matches the COD architecture.

allowing one of the user's BoFs to be scheduled at a time.

@pwolanin, I don't understand how that would work, can you provide the steps as you think it would work?

the goal of the above

Can you clarify whose goal you mean in that paragraph. I'm not clear if you're talking about your idea for scheduling one at a time or the code in #59. Yes, some complex validation is required for creating the BoF content and then scheduling, but it was already written for the regular COD sessions. I had to add some logic for room capacity, but it's minimal. Also, using standard Drupal constructs (node, fields) it would be much more complex to write a "placeholder" BoF reservation to the nodereference tables for a slot and then let the user fill out the content for that BoF. I'm open to other ideas though, there could indeed be a land grab on slots. Perhaps the body field (and any track, exp. level fields) is hidden on creation, and only displayed on edit to force people not to fill that out?

I have to agree that if this can be designed w/o a modal it is best.

Right, nothing so far assumes modal, so as it it is now it's just regular Drupal forms (with altering) and full page refreshes. I would love for accessibility testing now, on where the current code is at. @Everett, I'll try and get a dev site setup.

@coltrane - I think in an ideal setup, people would be able to create BoF proposals in advance and then scheduling would not be opening up until approx the start of the conference.

Let me try to mock up or explain my idea better - but basically I'm thinking you only go into the scheduling grid with one session "on deck" to be scheduled via that action.

@pwolanin your suggestion (#63) would also work well in pure unconference style conferences where the content isn't determined until the opening session.

Taking that idea a little further, I could see a need to have some way for people to express interest (vote?) on various BOF sessions being proposed (should this become a new issue? I'm not clear).

I could then see a pure unconference, with a very wired audience, where the session proposals (aka BOF topics) are entered by the group, shown in a view and projected for the group to see. After collecting the session proposals, the attendees could "vote" on the sessions of most interest to them. A final step would be to assign the sessions to available rooms (perhaps topics could indicate any special needs like projectors) based on interest and room size, that's where the drag and drop interface would be really, really cool because the group could be watching the schedule being built and make suggestions.

@greggmarshall - maybe, but that's beyond the scope of this effort. I'm just thinking in terms of Drupalcon where having the proposal out ahead of time allows people to comment on it so the author can gauge interest, people can suggest merges with other BoFs, highlight main session conflicts to avoid, etc. Such information collected in advance of the scheduling being open would make for a better BoF program I think.

@pwolanin I understand. At the same time if fields, etc can be included, but not used, to support the capability in the future it would be beneficial.

I think in an ideal setup, people would be able to create BoF proposals in advance and then scheduling would not be opening up until approx the start of the conference.

That makes sense, and the code in #59 is compatible with that. The time slot and rooms fields aren't required on BoFs, so a BoF (title, body, maybe more fields) can be created first. Then once the BoF schedule grid is activated (Views access permissions) people clicking "Schedule a BoF" would see a list of their previously created BoFs. Looking forward to your mockup.

@Everett et al, to test please log in to http://devcod.usecod.com with the account name "guest" and password "guest".

Then visit http://devcod.usecod.com/program/bof-schedule to schedule and re-schedule BoFs.

If you have problems, probably easiest to catch me on IRC #drupal-cod, I'm coltrane

Seems straightforward to me.

I did note an odd behavior when I went to edit my title (from BOG to BOF), shown in the attached screen capture. The HTML didn't get rendered.

@coltrane

Works well, just did a functional test with JAWS 11 / FF 3.6.13. There may be bugs to clean up for accessibility, but nothing that should significantly alter the layout / workflow.

Looking good! LOL at "party bof whatwhat" in your screenshot - I'd go to that one! :D

My feedback...

1. Edit link
A nice fat Edit link would be great next to BoFs one has created. Otherwise it'll be harder to find them in the big Chicago BoF schedule.
Likewise, a Reschedule link (if this is a separate form - see below) would be handy here too.

2. Minimise decisions
* Time slot and room fields should be grayed out / uneditable on the edit form since users have already made their time/room choice.
* Do we need a BoF Body? If yes, make BoF body 3-4 lines by default, and relabel it 'Description' or 'Who should attend". BoFs traditionally don't have body fields anyway.

3. Rescheduling

"RE-SCHEDULE BOFS?" box at the top of the edit form is really distracting/confusing. It's especially jarring if you really just intend on creating a new BoF and instead you're presented with some other slightly confusion option.

Suggestion:
1) Remove this from the node/add form (but keep it on the BoF's Edit form).
2) Make it less prominent on the edit form, or make rescheduling a separate form, accessed from a tab next to the edit tab? I see the primary action on the edit form to change the title.

4. Each day; own tab
To answer an earlier question, I'd definitely envisaged each day appearing on it's own tab. This should speed up page load as well.

If it's possible to have a summary count somewhere in the UI of how many BoFs are scheduled for each day, that should help people space out BoFs over the available days.

I post a mockup of any of these comments, if needed.
--------
@Peter "basically I'm thinking you only go into the scheduling grid with one session "on deck" to be scheduled via that action." In my original mockup there's a separate "Add a BoF" button but others felt the process needed to be streamlined. I think we'll get some useful feedback once this is live and can definitely tweak it for next time ....

I absolutely agree with having a tab per day.

My comments above reflected feedback on Ben's partial implementation but we had a discussion and this is what we are going to build. Attached is the mockup which is a clarification of our original post. As before, various aspects of the mockups are annotated for reference.

Note that links and buttons have text specific to the task at hand.

I'll post my annotations later but right now I'm running super late!!

Now nearly functionally complete with the mockup in #73, I think I've got everything.

This is running at http://devcod.usecod.com/program/bof-schedule/ though there is a problem with the Views arguments working. It works locally.

You'll notice there are links to the other days of the event but they are explicitly tabs. Programmatically it will be hard to make tabs and be compatible with View display paths. I could get the first page display path for the View and add local tasks for the days that BoFs are available, but site builders can also specify default arguments to a display to get the same thing, with more control in their hands.

To test yourself, apply patch and untar cod_bof. Also install Prepopulate.

So, no Javascript modal/popup thing at all? Or, try it and try and make the tool still accessible?

Overall I like the approach in #74. No need for popups; they just complicate things.

I did run into a couple of issues, though:

- When I schedule a new BoF, and then edit it to unschedule it, it gets lost. There's no indication of where an unscheduled BoF goes, but the message I get tells me that it was updated, not deleted. Does that actually mean delete? Then it should say so. (I thought above it was concluded that we want to allow unscheduled BoFs for rescheduling.) If not, then I need an immediately obvious place to see my unscheduled BoFs, maybe even on the same page.

- One time slot is shown as having 1 slot available, and one session there already. I try to create a session in that slot, as there is a link to do so. When I click Save, however, I get an error that the time slot is already taken and I should try a different slow. This information is wrong. It is also impossible to try a different slot as the select boxes for room and time are still disabled.

- Will this approach cause an issue for room selection for existing session nodes by having 2-3 times as many rooms, and then it's just up to the site admin to not screw it up? (If so that's probably acceptable for Chicago since I'm the one doing most of that, but probably not long-term.)

This looks great!! I know you're working mainly on the entry of data right now, so my questions are on the other stages. Are there other issues for this?

I've been asked by the conference organizing team to help out with BoFs- to get over there during the conference and be the point person should anything go pear shaped, or if people need a hand with something. From that perspective, I imagine I will often be acting as traffic warden and usher.

1) Choosing bofs

I see in the most recent flow, there is an accommodation to write a description of your bof. After the bof is scheduled and published, can people see this description by clicking on it? Is it a node with comment capability? Or some kind of limited tool tip?
Can people comment on or communicate with the bof organizer?
Can they see the organizer?
Can they see how many are signed up?

2) Sharing bofs

Also, is there a way to link directly to a bof to have people sign up. Being able to have a direct link to a bof page and description can help people share links on twitter, text email, etc. Especially in the case that bofs can move in the schedule.

Ideally there would be a page with the description of the bof, and an indication of the location, the organizer, and the status (scheduled/unscheduled/cancelled/etc). As well as comments.

3) Post Bof

One thing would be great to work into BoFs is to allow for 'scribes' to add notes taken down during the bof for the events that happened.
Is there any opportunity to accommodate this? Comments could solve this if enabled.

- Also, the bof space is opened 24 hours. Does the schedule account for that?

Hi Heather,
We are building this using the requirements provided to us by the DA. Some of the things you mentioned weren't part of the requirements.

1) Yes, they are nodes with comments enabled. People can click the BoF title to see the full node & description.
Communication with organizer could either be done in comments or via personal contact form on the Chicago site
There is no signup. It's just like old school BoFs except now we have a 'digital' version of the whiteboard.

2) People can share the link to their BoF however they'd like, but we weren't asked to provide any other invite mechanism.

3) Yep, this can be done in comments.

I did usability testing with 5 non-Drupal people last night and it was really useful! As a result there's some minor changes to the UI shown in #73.

heather "Also, the bof space is opened 24 hours. Does the schedule account for that?"

Yes, that's the plan. We haven't settled on exactly how it will work in the UI yet, until we can test it, since there are many rooms.

Heya Lisa!

Gotcha re: requirements.

1) Re: signup numbers, I thought if it's an implementation of flag, you'd know the numbers of ppl who flagged a particular bof, and this could facilitate flock mentality. This is useful, but I can see it's outside of the scope.

2) OK! No I wasn't thinking invites, I was just worried that we'd not be able to link to the bofs. Cool.

3) Awesome!

Looks great otherwise, I'm v glad this is going forward.

Yeah, there are 8 rooms, but there are only 2 types and 4 of each. 4 classroom style w AV for 60 people; and 4 x rooms with round tables for 80. So maybe you can just list two rooms, and the availability of each type? At which point it will assign the next available of that type?

Oh probably not, the boffers will get attached to particular room and want to select "that one". Thinking outloud.

Alas.

Also if you know that room 1 already has 5 of the 6 tables filled with people, and room 3 is empty, you'll want to schedule time in room 3 where there's going to be more room to breathe. :-)

I will diff COD Session against latest Chicago code and get an updated patch here.

A patch with the code that went into Chicago 2011 (except the exported BoF content type and view).

Leaving this as needs work for:

* Creating a new feature with exported BoF content type and view
* Updating cod_session export with exclusivity variables
* Ideally, breaking apart the mess that is template_preprocess_cod_session_schedule()
* Needs lots of testing

I'm not sure if this is still part of this issue, as it wasn't a feature in the Chicago implementation of the BoFs, but it would be really nice to be able to add BoFs to your schedule. In Chicago, I couldn't really use the "My Schedule" feature because I was attending at least as many BoFs as sessions, but couldn't include them in the list.

@rootwork Yeah that could be made part of the exported COD bof feature, to re-use the "add to my schedule" flag.

coltrane, I remembered several people in Chicago told me that "Room is full" was confusing because they weren't sure if that mean there weren't any seats left, or there weren't any more tables for BoFs.

Therefore, if a room has reached capacity, let's not display "Room is full". We don't need anything there now.

Is this still getting worked on? I haven't installed COD for a conference myself, so I'm not sure if BoFs are built-in or if it was a Chicago Drupalcon-specific thing. But if they are built-in, it seems like COD should definitely support scheduling them.

Alright, alright, I made some time to work on this.

Now with:
* COD BoF Feature
* COD Session is updated for the new display Style, exclusive variable, and permissions

Also, I removed the "Room is full" text per #86

This still needs lots of testing and significant cleanup and documentation in cod_session.module.

A big lack in Chicago was that I could not add a BoF session to my schedule - is it possible to enable that?

I know this thread is long, but that question has been asked and answered :) Yes, the flag could be re-used. If it doesn't go in this commit it could go in a follow-up.

I'm trying to test this out and I'm not seeing how to restrict rooms from the bof schedule. It seems every room I create is visible on the bof schedule.

@redndahead Let's catch up in #drupal-cod during the sprint and I'll give some real-time documentation.

And another updated patch. I did not add the 'add to my schedule' Flag because of #1115824: Switch from Flag to Signup for personal session schedule. Also merged from 6.x-1.x before diffing.

I added some documentation to template_preprocess_cod_session_schedule(), I think this patch could be committed and refactoring could come in later.

Here's a reroll.

This includes new (optional) per-display Nodequeues to allow for greater control over room and timeslot ordering!

I believe the validation bug you were experiencing ezra-g is because the BoF schedule doesn't automatically include showing session node types, which is why it said a slot was available when it was not. Let's discuss IRL or IRC and handle in a follow-up issue IMO. TLA!

Documentation for this feature (as-is) is happening at http://drupal.org/node/1208088

Ezra found a bug caused by Prepopulate 2.2 and hidden fields so we decided to remove that dependency and set our own default_values.

Awesome! Sorry didn't have time to test, but glad this is in.

Works great so far for the Drupalcamp Atlanta dev site.

Yeah, looks like the spammers got one through.