Sessions at Open Source Bridge 2009 about Software

Wednesday 17th June 2009

• Creating conference sites with OpenConferenceWare

  by Igal Koshevoy and Reid Beels

  The organizers of the Open Source Bridge conference needed software to collect presentation proposals and speaker bios, gather public feedback, publicize sessions, publish schedules, etc.

  The conference team quickly realized there wasn't anything available that met our needs and that we would need to build something. Rather than create another closed source app for just our conference, we decided to build an open source platform that we and others could reuse for other events.

  "OpenConferenceWare":http://openconferenceware.org/ was born out of the necessity to support Open Source Bridge. It's a much enhanced fork of the "OpenProposals":http://openproposals.org/ application we built to collect proposals for "Ignite Portland":http://proposals.igniteportland.com/ . The code works well and is in production use on half-a-dozen sites by thousands of people.

  In this BOF, the developers of OpenConferenceWare will give a quick demonstration of how to set up the software, administer it and add a custom theme. These tasks are the hardest part of getting started with the software, but once you get it going, it's a quality Ruby on Rails application with generally good test coverage and sensible design.

  We'd like to spend the rest of the BOF talking with the audience. We'd like to hear feedback from the software's end-users about how to make it friendlier and more useful. We'd like to hear from event organizers interested in using the software. We'd also really like to hear from those interested in joining the development team for this open source project.

  • Ruby
  • Ruby on Rails
  • Software

  At 8:30pm to 10:00pm, Wednesday 17th June

  Coverage note

Thursday 18th June 2009

• Practical Paper Prototyping

  by Randall Hansen

  *Paper prototyping is important*

  In user interface design we want to make lots of mistakes, and we want to make them early where they're cheapest to fix. Just about the cheapest fix you can make is drawing a large X over your sketch, turning over the piece of paper, and starting again on the other side.

  A paper prototype can be used for:
  * Design discussions: "I think these elements work much better side-by-side.
  * Client communication: "Is this what you mean?"
  * Developer scoping: "We have five screens with 14 interaction points, only three of which are non-trivial."
  * Usability tests: "What do you expect to happen if you click that?"

  *Paper prototyping is easy*

  Can you draw a box on a piece of paper with a pen? Can you write? The hardest thing about paper prototyping is the problem you're solving; the process itself is rapid, iterative, and transparent. We'll talk about the most important aspects, with efficiency tips born of years of experience. We'll also walk through several rounds of prototyping and testing a small application.

  • Design
  • Paper Prototyping
  • Prototyping
  • Software
  • User Experience

  At 2:45pm to 3:30pm, Thursday 18th June

  Coverage note