Description

Learning objectives

Based on Mozilla’s Web Literacy Standards , participants will learn:

• • Building: Composing for the web; Design and Accessibility; Coding/scripting
  • Connecting: Sharing; Collaborating; Community Participation
  • Exploring: Navigation; Web mechanics; Search; Credibility

Additional curricula may be used to track student performance. For example, the TDSB has their own ICT Standards which track closely to Mozilla’s Standards.

What you’ll make together

Small groups of participants will make prototypes of apps that seek to solve a problem identified by each group. Apps can either be fully-functional “minimum viable products”, wire-frame prototypes, or “drag ‘n drop” web prototypes.

Materials

Organizers need to ensure that they have:

• • Space large enough to host the youth participating. Suggested total group size is between 40-200 people to get a “critical mass” of interested people.

• Enough round tables and chairs for small groups of 6-12 people working on a particular project.
• Fast and reliable wifi
• A microphone and laptop projector/screen to address the entire group.
• A laptop for each student to work on. Students may be able to share devices, or work on “paper prototypes” depending on how the work i each group is distributed, but in general, strive for a 1:1 ratio.
• Chart paper
• Markers
• Activity handouts for each group (see below)

NB: If students from a school are participating off-site, teachers need to ensure they have the appropriate documentation in place regarding field trip permissions and/or media clearance.

Pre-event

Participants should be taken from a wide mix of backgrounds and ages. Hackathons are a great opportunity to introduce young people to role-models in the tech community. Many community groups such as DevTO exist for the sole purpose of organizing hackathons and working in teams to develop products. For #EdAppHack we had roughly 200 spots available: 100 reserved for TDSB high-school students, 40 reserved for Humber app students, 40 reserved for “community mentors” (adult developers and entrepreneurs from the MaRS community), 20 for high-school teachers. This weighed the team composition to favour high-school students (which we wanted), but gave each team a strong contingent of more experienced coders or entrepreneurs. It was very important to emphasize the high-school students were the team “leads” and had final say on what app was developed and what problem was being solved. The mentors were primed to look for “adult takeover” where well-meaning adults tended to discount the views and opinions of the students due to their lack of experience. The point of the event was to encourage student voice in the edtech creation process and to have their curiosity lead the development process.

Marketing should be focused on Twitter and other social media sites where local hackathon groups are active. Consider notifying groups in the Hive Minigroup , DevTO , NerdNite , HackerNest and digital media faculties at local Universities and Colleges. Hashtags such as #hackathon should be used in conjunction with Toronto centric hackathons like #TOPoli etc.

EventBrite was used by the organizers as a way of signing up different stakeholders for the event. When securing a ticket (which was set to “free”), participants needed to choose their ticket type: Humber student, Teacher, Community Mentor or High-school student. (The high-school students were manually entered by the organizers as they were pre-chosen by the teachers). Get started here here.

Permission for youth under the age of 18, parental or guardian permission needs to be secured. As #EdAppHAck was a partnership with the TDSB, we relied on the teachers to get permission forms for the students in question. Outside of this, we recommend building parental permission into the EventBrite form. If students sign up who are under the age of 18, ask them to include their parents email address and send an automatic to their parents to confirm participation. Students need to know that without affirmative consent from parents, they will not be able to pariticipate. Additional permission might be required for capturing student images in pictures or video, and ca also be embedded into the EventBrite page.

Preperatory Emails can be sent automatically to all participants before the event through EventBrite. Consider something like the below example:

Development platform of choice can vary widely. For participants comofortable with coding, they can choose their own platform (iOS, Android). If the organizers wish to choose a platform that is common to all groups, they can do so, but we preferred to leave that option open for the groups to decide. For participants new to coding, or more comfortable with the design side, introductions to platforms like Mozilla’s Appmaker (see Activities) can be valuable to introduce the logic of coding. A full list of “Dev Tools” for coding apps can be found here.

Event

Day 1

8:30 AM — Registration:
Encourage everyone to be there at least 30 min before the event actual begins to register, find their table and receive a package of instructions. Set up a sign-up table where participants pick up their nametags and sign in to ensure you are tracking attendance. On each nametag, you might want to write the number or name of the participant’s group if known beforehand. Self-serve breakfast or juice is a good way to ensure people get there on time.

NB: Adult participants should not be placed into teams right away. Instead, work mentors and adulst developers into teams based on the needs and individual composition of the teams, as needed (see Activity: Creating a Team).

9:00 AM — Introduction: Slides 1-8. Notes here are meant to accompany the PowerPoint presentation here . It’s best to address the entire group at once to ensure everyone is on the same page off the top. Thank everyone for coming and ensure they understand the philosophy of the two day hackathon: “a 2-day experiential and inquiry-based Learning opportunity that allows students to start to solve real problems with prototypes of apps that provide solutions” (to paraphrase the slide deck). Remind people of a) the wifi password (if applicable), b) where to find the bathrooms and any other locations online or in person they need to know about for the 2-days. If you have third party sponsors, thank them here (and again, and again…)

9:10 AM — Sponsors Welcome: Slides 9-22. Sponsors can send people to welcome the crowd, to set context or to welcome them to the event. Certain sponsors can talk about their programming or how their sponsorship aligns with the goals of the event. Here #EdAppHack was sponsored by the Media Studies program at Humber College and by the TDSB. Be sure to not take up more than 20 mins with speakers off the top. The students are present to make stuff, not listen to speakers.

9:30 AM — Activity: Creating a Team Slide 23-31.

10:00 AM — Guest Speaker: Robleh Jama. A guest speaker who has the power to inspire the students is a key part of a good hackathon. Robleh Jama from Tiny Hearts spoke at #EdAppHack about his experiences as a designer in charge of an app development studio. HIs slides can be found here. Note the speaker does not speak for more than 30 min as the students should want to get back to their projects.

10:30 AM — Activity: Defining the Problem Slides 36-38 .

11:00 AM — Activity: Interviewing Customers Slides 39-41 .

12:00 PM — Lunch Lunch is a good time for teams to get out of the main room and get to know each other (or the building they’re in). Teams can continue to work over lunch or take a break and get outside. We often emphasize taking a break and getting outside to provide a change of perspective.

1:00 PM — SCRUM: Storyboarding and App Design

For this scrum, a community mentor described a particular tool for the students, a sketchbook of blank screen-shots where buttons on a mobile phone or tablet are included as stickers in StickerUI. . (NB: The team behind StickerUI are in the process of posting their files to an open-source platform for remix by the community). We secured PDF versions of these sketchbooks so students could sketch out a sequence of screenshots to represent their product (often called a “paper prototype”). We then encouraged the “Hustlers” to head out and perform further customer intervuiews to validate the assumptions made in the paper prototype before code was written to encode the designs.

2:00 PM — SCRUM: Using Kickstarter This scrum, lead by a Humber Professor, was meant for the “Hustlers” on each team as a way to introduce Kickstarter as a potential fundraising tool to market an early idea, or to raise early money for production of an app or digital tool. The bonus for this scrum was that AppSeed was a real product to help people create apps, found here .

3:00 PM — SCRUM: Mozilla’s Appmaker This scrum was an introduction to Mozilla’s Appmaker tool. See Activity: Mozilla Appmaker for more.

NB: The above mentioned scrums are not meant to be reproduced for every hackathon. Instead, organizers should look at the needs of the event and the expertise of the mentors involved and determine what scrum topics would be of most interest for the students involved (ex: graphic design; MIT’s programming language Scratch; History of Innovation; Customer interview techniques; Marketing techniques; Market segmentation; Lean Startup etc.)

5:00 PM — Wrap-up Slides 50-51. For many events involving youth, a 5:00 or 6:00 PM wrap-up time is encouraged. For adult hackathons, teams are encouraged to work as late as they want (many work all night fueld by Red Bull and pizza). Young people should be encouraged to exchage contact information if they wish to continue work on the product in the evening. Many teams divide up responsibilities for the night and reconvene in the morning.

Day 2

9:00 AM — Introduction: Slides 1-12. Notes here are meant to accompany the PowerPoint presentation here . Notice the inclusion of Tweets and pictures from the previous Day to remind students of the activity in the room and the engagement of their colleagues.

9:05 AM — Guest Speaker: Marc Salzman Slides 13-14. This speaker was presented through a pre-recorded webcam video, and played in the morning just after welcoming address. He is a technology journalist that many of the students recognized from his spots before movies here . Marc talked about what he looks for when evaluating and reveiwing an app through different media channels.

11:00 AM — SCRUM: Effective Pitching Slide 17. This scrum was neccessary to introduce the “Hustlers” to the principles of an effective pitch and how to deliver a pitch that demoed their app in 60 seconds. See Activity: Effective Pitching for more.

11:00 AM — SCRUM: Entrepreneurial Thinking in Your Classroom. Slide 17. At the same time, a MaRS Facilitator took the teachers who were accompanying each group aside to talk about how to use some of the tools from the Entrepreneurial Thinking Toolkit for Educators in classes and in schools.

12:00 PM — Lunch

1:00 PM — Rules for Pitching. Slides 18-22. Based on the high numbers of students at the “Effective Pitching” scrum, we decided to address the entire group with the rules and expectations for pitching at 3:30 PM. We had initially given each team 60 seconds to pitch their apps. While a 60 second pitch is an excellent activity to force students to create a crisp and concise message around an idea, when they have an app to demo, 60 seconds is not enough. We would suggest 2-3 minutes for a pitch plus demo. Many groups wanted to plug their laptops directly into the projector, but we also had a document camera on hand so the students could place their phones on a table-top and the camera would project the image to the screen. Both methods worked well, although there was a slight delay with two groups for whom the link to the projector did not work as expected (i.e. the AV team needed to play with their resolution settings). The easiest, bug-free way to do the pitches is to get every team to upload their PowerPoint presentations into GoogleDocs by a certain time and then run them off one computer. Either way, a full technical dry-run should be completed before the final pitch. In addition, it is important to share the judges rubric with the students before-hand so they know how they will be judged.

3:00 PM — Guest speaker: Darin Graham. The CEO of ORION was the “keynote” speaker who gave the kids some inspirational messages about innovation and technology before the final pitches.

3:15 PM — Guest Speaker: Amber Mac This speaker was also presented through a pre-recorded webcam video, and played just before the pitches. Amber Mac gave a great talk but in hind-sight, we should have put her talk in one of the two mornings. The kids were getting nervous about their presentations and wanted to get on with the pitches.

3:30 PM — Pitch Competition. Slides 29-30. The judges were introduced one at a time, and then the students pitched. There were two podiums set up on either side of the stage. As one group was plugging their laptops in and getting set up, the other podium would pitch. And so on, alternating between podiums. After each pitch, the judges had 2 minutes in which to ask questions about the app, the intended use etc. The judges were given score-sheets on which to take notes, similar to the “Assessment and Review” checkist below.

All student pitches can be found here

4:30 PM — Awards. Slides 31-34. The judges retired to a side room to deliberate and tally their scores to pick four winners: 4th place, 3rd place, 2nd place and 1st place. The four winners got a different combination of iTunes gift certificates and Nuvango gift certificates. Before the winners were announced the organizers thanksed the sponsors and reminded the participants to fill in a survey designed to solicit feedback. It is a good idea to enlist one of your sponsors to announce the prizes.

5:00 PM — Wrap-up. Slides 36-39. The students were encouraged to keep in touch through social media.

Post-event

Documentation is key to understanding what worked, what didn’t, and for encouraging successful groups to continue with their apps or engaging with the dev community. #EdAppHack was documented through a series of volunteer students taking pictures, videos and writing tweets for posting here:

• EdAppHack Website: click on “Resources” here
• EdAppHack Twitter here
• EdAppHack Facebook here
• EdAppHack Tumblr here
• EdAppHack Instagram here
• EdAppHack YouTube here

Surveying the attendees is also key to understanding what worked and what did not from their perspective. For example, one of the key pieces of feedback we got from our survey was that the pitch timing was too tight to deliver a product demo. The survey we used is here and available for remix.

Assessment and review

For major learnings from the event and pedagogical implications of hackathons as a teaching model, check out “EdAppHack: The Hackathon as New Pedagogy” by Joe Romano and Brandon Zoras here. In the first section entitled “Learning Objectives” we summarize the Mozilla Web Literacy Standards relevant to the hackathon. Ontario teachers should also use as their guide the Ontario Ministry of Education’s Growing Success document. There are four relevant categories of assessment:

• Knowledge and Understanding: Subject-specific content acquired in each grade/course
  (knowledge), and the comprehension of its meaning and significance (understanding)
• Thinking: The use of critical and creative thinking skills and/or processes
• Communication: The conveying of meaning through various forms
• Application: The use of knowledge and skills to make connections within and between
  various contexts

• Discussion Questions For Teachers:.
  • What were the factors that were present in the teams that did the best work?
  • Did any teams suprise you with how well they did?
  • In which other courses could the “hackathon” model work as a project framework?
  • What other kinds of tools could students use to “hack” together a solution toa problem (instead of just technology?)
  • How did the best teams communicate effectively with one another?
• Discussion Questions For Students:. Any suggested topics or questions for follow-up discussion?
  • Did you feel like you had ownership over your idea and your team?
  • How did it feel to be in control of the adults on your team?
  • What might be some next steps you might take to continue refining your app and bringing it to market?
  • How did you resolve any communication conflicts that arose during the hackathon?
  • What advice would you give other students who were preparing for a hackathon?

Sharing Student Work: The main vector for sharing student work wad through social media, and started in real-time during the hackathon. Most of the teams created Twitter handles or Youtube accounts to post their work. Feedback, RTs and views/likes were all generated during the hackathon. Below is a list of the teams’ social media accounts. Winning team Switch On are particularly active on social media and just recently presented at a TDSB STEM conference.

Activities