The Unscheduler is an app for managing the voting and scheduling process for unconferences, inspired by my work as a co-organizer for Offline Camp. (Yes, unconferences have schedules!)
Check out the code or the live app!
- Front-end client
- GitHub repo (unscheduler-client)
- Live site (deployed on GitHub Pages)
- Back-end API
- GitHub repo (unscheduler-api)
- Live site (deployed on Heroku)
- Front-end technologies
- JavaScript
- jQuery
- Handlebars
- Bootstrap
- HTML5
- CSS3
- Sass
- Back-end technologies
- Ruby on Rails
- PostgreSQL
- Active Record
As a member of the Offline First development community, I co-organize an unconference called Offline Camp, where attendees propose topics for discussion and then vote to determine what topics are actually discussed in the limitedtime we have available. As organizers, we take the votes (a sticky note for each proposal, with stickers representing votes won) and give some careful thought to how to best schedule the winning sessions so that the most popular ones are spread across different timeslots from each other and in the largest available rooms, topics that should appeal to similar subgroups of attendees aren't scheduled to conflict with one another, etc.
Check out these photos for a taste of the current analog process:
- Voting on proposed discussion topics with sticky notes and stickers
- Scheduling the winners on a grid of available session slots
This Unscheduler app is meant to mimic the analog process we use at Offline Camp by:
- Allowing event participants to nominate discussion topics (complete)
- Allowing event participants to vote on proposed topics (complete)
- Allowing event organizers to open and close proposal and voting periods (complete)
- Allowing event organizers to easily identify winning sessions (complete)
- Allowing event organizers to schedule sesions into timeslots (upcoming)
- Allowing participants to view the final schedule (upcoming)
Preparation and planning were key to my success with this project. Here's a look at my strategy and process.
These user stories guided my development process:
-
Proposing (Complete)
- As an event attendee or organizer, I want to see a list of all currently proposed sessions so that I don't create a duplicate proposal.
- As an event attendee or organizer, after seeing other proposals, I then want to propose a new unconference session topic for everyone to vote on so that my favorite topic will be covered.
-
Voting (Complete)
- As an event attendee or organizer, I want to see a list of all proposed sessions so that I can choose how to use my X number of votes.
- As an event attendee or organizer, I want to apply my X number of votes to my favorite sessions (either all to one or one/some to multiple) so that my favorite topics are likely to be selected.
- As an event organizer, I want to view all proposed sessions with their vote counts to determine which are the winners.
-
Scheduling & Admin (Upcoming)
- As an event organizer, I want to add some keywords (such as UX) to winning sessions to help guide my timeslot assignments, ensuring similar sessions aren't scheduled on top of each other.
- As an event organizer, I want to add a list of daily timeslots avialable for sessions to create my base schedule.
- As an event organizer, I want to add a list of rooms available for discussion sessions to create my base schedule.
- As an event organizer, I want to assign each winning session to an available timeslot and room so attendees can see their options.
- As an event attendee or organizer, I want to see today's sessions by time, with room indicated for each so I know where to be when.
These wireframes guided my front-end development:
- Version 1: Proposing Discussion Topics
- Version 1: Voting on Discussion Topics
- Version 2: Scheduling Sessions
- Version 2: Viewing Final Schedule
I created the following entity relationship diagrams to map out my relational database structure before devloping my API, and adjusted the plan to meet time constraints on the project.
I took a methodical approach to development of the app, first building out each SQL table and getting my Rails server up and running via curl scripts before adding the related front-end functionality. Here's a look at my project plan. I was able to complete my MVP and add additional admin functionality before deadline, and I have lots of functionality I'd still love to add in the future.
- Version 1 / MVP (Proposals & Voting)
- API: Build USERS tables, API, and curl scripts
- Client: Implement auth functions
- API: Build DISCUSSIONS tables, API, and curl scripts
- Client: Implement DISCUSSIONS resource functions (propose, vote)
- Style, debug, deploy
- Version 1.5 (Event Admin)
- API: Build EVENT table with single event belonging to admin
- Client: Enable EVENT admin functions (updating proposing/voting/final status, updating event name and max votes per user, determining winning sessions)
- Style, debug, deploy
- Update documentation
- Version 2 (Scheduling & Schedule View)
- API: Build SLOTS tables, API, and curl scripts
- Client: Implement SLOTS resource functions (create timeslots, schedule discussions, display final schedule)
- Style, debug, deploy
- Version 3 (Better Scheduling UI)
- API: Build TIMESLOTS tables, API, and curl scripts
- API: Build ROOMS tables, API, and curl scripts
- API: Turn SLOTS into a joins table for ROOMS & TIMESLOTS, re-test
- Client: Revise SLOTS/TIMESLOTS/ROOMS resource functions (better UI for adding timeslots and rooms to scheduling engine, incl room capacities)
- Style, debug, deploy
- Version 4 (Improved Styling)
- Optimize scheduling features for laptop/tablet horizontal
- Optimize proposing/voting for mobile
- Style, debug, deploy