At an early stage of the planning of BiCon 2005, I was going to be in charge of the sessions timetable. Later on, we had a "team reshuffle" whereby I let go of that role and concentrated on other things (see my BiCon 2005 report). But meanwhile I had begun to design this interface to collect people's offers, and a database structure for storing and managing them.
The principal aims of it were
In the end, this version was never implemented for 2005, although a similar thing was done which fulfilled the first two of those aims. So I wanted to document where I'd got to, for the possible use of future organisers.
Eventually it dawned on me that probably the easiest way to explain most of my ideas was to do a mock-up of the front end, so that's what this is. To make it actually work would want some PHP (or similar) to interface it with a database.
In the course of my own enterprises, I've done a lot of designing databases which I later used on a regular basis myself. So I've "paid my dues" in terms of those moments where you go "doh! If I'd only known I was going to use it for this, I'd have made a separate field for that!" I've also set up numerous mail-merge-type things where a database is processed to create a printed document (or the basis of one). And I've been to 10 BiCons now, and run individual sessions at some of them, and thought a lot about how the session-organising process generally seems to work. So even if you disagree in the end with aspects of this design, I think it'll be useful as a source of possible ideas and considerations.
Text shown like this is explanations for people filling in the form, intended to appear in the final version.
[Design-related asides are shown like this.]
Here begins the mock-up.
If you're planning to offer a session at BiCon 20XX, or thinking about it, please use this form to tell us your ideas.
If you have questions, please email ________ or call ________ or post your questions on the BiCon LJ.
If you would like to offer a session while keeping some details confidential, please contact ________.
Session title, or working title/approx subject
Name(s) of session organiser(s), as you'd want it/them to appear on the programme & on the web site
Choose a password for updating this entry later
[Or the allocation of a password could be automated. Either way, the entry will need an automated ref number in case the person offering the session decides later to change its title.]
Email address, or more than one separated by commas
(won't be displayed on BiCon website)
Email addresses will be kept confidential, and only used for update emails from the BiCon team.
We may stick the results of this box directly into an email, so please don't add other notes here - only include the email address itself (or addresses). There's a space for "other info" a bit further down.
[It might be worth including some level of automated checking (on submission of the form) that people have stuck to the requested format.
If I were in the workshops coordination role, I would plan to do a considerable amount of email broadcasting, using a list formed by concatenating answers from this field (whether all of them or a selected subset of them). More on this below.]
Status of planning:
[The list of sessions displayed on the website would sort on the above field, with the "definites" shown first, and both kinds of "maybes" second.]
Collaboration, if any:
Other info about where you're at, or questions you'd like to discuss about running this session
(won't be displayed on BiCon website)
Filling in the session description at an early stage will help visitors reading the list to see what's already been offered. You can come back later to update it.
Programme blurb, or interim approx description of what the session's going to be like
Is that the final text which we may print in the programme, or just an interim draft to give people some idea?
[The answers from this drop-down field, and the other similar questions allowing an "interim" or "not sure yet" option, can be used to pull out from the database a list of people who have not yet submitted their final programme blurbs, etc. Concatenating the selected email address fields then gives the list of recipients for a reminder email, sent out at some point(s) before BiCon, to say "Please finish giving us your session details, or get in touch if there's something you need to discuss".]
Age groups:
Some advice on how to decide what age range to offer your session for [not a real link yet]
This session will be suitable for / aimed at
Not sure yet
Over-18s only
Over-16s only
Teens 13 and over (at their parents' discretion), and adults
Accompanied children under 13, teens and adults
Age range as specified here:
[The above categories are based on what we said in the 2005 programme. I was keen to ensure that if, for example, a bi teenager turned up with a supportive parent, there would be things for them to go to. So I envisaged "Teens 13+ and adults" as the default, on the basis that a thoughtful teenager would be able to contribute to - and benefit from - most discussions. Then, in the programme, we would indicate "Children welcome", "16+" or "18+", by icons in the timetable, and in the programme by both words and icons. In the event this was all a bit half-baked and last-minute in implementation, and no under-16 teens turned up anyway, but I like the idea that if they did, BiCon would be ready for them.
What I would put in the (so far, imaginary) advice document linked to above would include some similar thoughts about provision for children and teens, but also any relevant legal limits, e.g. anything involving nude photography having to be 18+. ]
Limits other than age:
Note: This bit of the database won't be printed out in the programme. So please also include any non-age limitation as part of your programme blurb, preferably with a brief explanation of why.
Not sure yet
This session would be open to everyone (age limits aside)
This session would be for a particular group, e.g. women, men, bi women:
Brief description of session leader(s), in particular any background which relates to this session.
If some people will recognise you by a screen name (e.g. LiveJournal name), you may like to mention that here.
Is that the final biog text which we may print in the programme?
[There's a choice to be made here about the programme design, to deal with the situation where one person is offering two workshops on unrelated subjects. If the session-leader descriptions/biogs are to be printed next to the session entries, then it could make sense to have two descriptions for the same person, customised for each session. On the other hand, if the biogs are going to be in a separate section, e.g. alphabetical by leader name, then you want one biog to apply to both sessions. That decision should be made clear at this point on the form, and the drop-down list may need to include something like "Biog is attached to other session entry".]
Information in this section will be needed as BiCon approaches. It's primarily for the session coordinator's use. Checking each other's time preferences may occasionally also help other people to plan, e.g. to plan a day visit on the day a session is more likely to happen, or to avoid a clash between a session they're offering and another session they want to go to.
Timing preferences
Please indicate on the grid below when you would ideally like your session to run. We will try to give everyone a time that they are happy with, although we can't guarantee that you get your first choice.
1 = Preferred time(s)
2 = Don't mind either way
3 = Would prefer not
x = I don't plan to be at BiCon during this time-slot
Note that although there is no foolproof way to get the slot you want, having more 1s makes it more likely you'll get one of them, and having fewer 3s makes it more likely we can avoid them.
| Friday | Saturday | Sunday | |
| Morning session 1 | |||
| Morning session 2 | |||
| Afternoon session 1 | |||
| Afternoon session 2 | |||
| Evening session |
[Obviously a compromise is needed in this area in terms of how much detail to collect and then how to use it. This is my current best guess of a good compromise, based on experience of somewhat-similar logistical things. At the time of writing, it hasn't been tested in real life.
If I were doing the sessions timetable, the way I would use this is to print out cards with the session offers on. Each card would include a tiny version of this grid. (If on a colour printer, I would make each number a different colour.)
I would start by putting everyone in one of the slots they had marked "1". This would be the first iteration of the timetable. Then I would move things around to even out the number of sessions in each slot. At first I would use only the other options of "1". Then I would resort to the 2s if necessary. I suspect this would leave only a few which couldn't be made to fit, at which point if necessary I would resort to the 3s, probably in conjunction with contacting specific people.
As an aside, not related to this particular method of doing it, note that I would lean towards filling all rooms in the early slots, while leaving the later slots more thinly populated in order to accommodate sessions added during BiCon.
The drop-down for "display" or "keep private" was a late addition to this design. Originally I was going to keep all this information hidden. But then I thought: actually, why not let people see what others have said? There might be situations where it was useful (as I've now suggested in the explanation above). But then I wasn't sure if some people might feel that their availability - in particular, their intentions to be present/absent for particular days of BiCon - ought to be considered confidential. So to be on the safe side I included that option.]
Resources
Tick if you will need...
Flip chart
Specially big room (if available), e.g. for games or dancing
TV/video
TV/DVD
Some other resource, as follows:
[More things could be added to the list above. I was thinking before finalising this form, I'd have done a post on the BiCon LJ and invite people to suggest resources they've ever seen used at a BiCon]
End of mock-up
Clicking on any of the buttons would take the person to a page where they could check what they'd done, and return to edit it if necessary. It would start with a thanks for the offer.
Aside from the info collected on this page, the database itself would also include fields for
The link to this input page would make clear that "possible/tentative offers" can be listed as well as definite ones.
There would be a list of all the offered sessions. As mentioned above, this would be sorted so that all the definites appeared before all the maybes. The maybes would be all one list, but you'd be able to see in the entry "which kind of a maybe" it was.
The main (h1) heading would include "as at [automated date/time]". This is partly to make it quick and easy for people to distinguish one printout from another, if they ended up printing it out more than once, and partly just to emphasise to casual visitors that the list would be changing over time.
Where a description of the session (either final or draft) had been submitted, the session title would be a link to that description and the other public information. Where there was no description yet, there would be no link (not a link which takes you to a page with no additional information on it).
The "detail" page would include the dates of most recent changes to the info (as in list of additional fields, just above).
(Another nice bit of functionality would be to have a subtitle to the page which told visitors when the information as a whole had last changed. This would be useful if people had already been to look, and were back shortly afterwards. However, that particular kind of timestamp would take some extra coding to implement: the session organiser might be tweaking both public information and fields which wouldn't appear on the public list, and for this purpose, hidden changes ought not to count.)
Obviously, a reasonable level of security is required to keep people's email addresses confidential, although there's probably no point making the database more secure than unencrypted email is.
For the 2005 system, there was some debate about whether each new entry ought to be checked by the team before going live. I argued that it would be preferable to start off with no such checks in place and find out whether in practice they were needed, because otherwise it was creating needless extra work for someone on the team, as well as introducing delays for the visitors. This view carried the day, and in fact the facility to add entries wasn't abused, so i.m.o. that's the default to start with in future. It could still be added if needed, though.
A separate page and another database would collect suggestions - i.e. wishlist of sessions people would like to go to - as opposed to offers.
The suggestions would then be available to view by browsing visitors. They might give someone an idea, or they might help a potential session-running person to choose among various possible subjects.
A version of this was implemented for 2005 and I think maybe for 2004.
Ideally, someone (perhaps the sessions organiser) would be in charge of annotating the list every now and again, to link from each suggestion to any identical-or-related sessions subsequently offered or maybe-offered.
At BiCon, aside from the printed programme, there's usually some kind of updatable canonical timetable on display in reception, often on Post-it notes. Additions and room changes are done in different colours from the listings which match the printed programmes.
2003's on-site session information was the best (i.m.o.) that I've ever seen at a BiCon so far. Their setup (run by David Matthewman) included
Given the energy to set up the formatting in advance, each of these kinds of printout could potentially be sourced from this database and printed off with one command. If I were doing the job, I'd definitely want to do that - investing time up front to make things run more quickly at BiCon itself.
In fact, I would like to think that this (or something like it) could be developed into a system which one BiCon could pass on to the next. From time to time, someone might have a new wizard wheeze about how to format things better. And different BiCons have different "house styles" for colours and fonts. But there's no reason why all the main database/interface functionality should have to be rewritten from year to year, once it's running well in the first place.