Recent site activity

Graphics‎ > ‎

Event Templates

Lecture/Talk (Single Speaker)

  • Goal: Impart the expert knowledge of a speaker on the audience.
  • Preparation:
    • Find a speaker 
      • If you're specifically looking for a Googler, email the GTUGs list and specify desired topic + location. It is very unlikely that we can accomodate the request (particularly if we don't have an office near you), but it's worth a shot. Most of our developer relations folks are in Mountain View. To see where Google has offices, check this map.
      • Make sure your website has a prominent link for other people that want to talk at the GTUG ("Want to Speak? Contact us!"), so that hopefully you will get some speakers volunteering to present.
    • Get a bio and picture for the speaker, and an abstract of their talk.
    • Advertise the event to the list and on the website. Email the speaker a link so that they can advertise it to the people they know.
    • Check what equipment the speaker needs (audio speakers), if they will be using their own laptop, and what laptop they have (to make sure you have proper cords).
    • Ask the speaker to come 20 minutes before the event so that they can setup their slides and make sure everything is working.
    • Find a way to thank the speaker after the talk - send them a thank you note, buy them a beer, etc.
    • Ask the speaker to share the slides/material with you. Email and post them on your website.

Codelabs (Workshops)

  • Goal: Get people actually using technology, and get them over the initial hump so that they're able to go further when they're on their own. Note: Codelabs are hard to do effectively. Make sure you understand what you are getting into. The reason codelabs are hard to do, especially in large settings (~100 people) is that no one is at the same place, skill/experience wise. You will constantly be stopping to explain things to newbie developers, while more advanced developers will get bored. 
  • Preparation:
    • Decide on the topic. The best topic is one that doesn't require a lot of setup - JavaScript APIs are great because all people need is a text editor and a web browser. Server-side APIs are difficult because they require attendees to either have a server or install a server-  or requires you to provide a server that everyone can SSH into. ools (GWT/App Engine) are difficult because there is usually a different installation process for each machine. If you pick a server-side API or tool, be prepared to spend most of the codelab installing servers, languages, etc. T That said, it is sometimes worthwhile to pick one of the difficult APIs if you're very experienced with them, because you are helping your users do something that might otherwise be too intimidatingly hard for them to do in their freetime. Also pick a topic that doesn't have a lot of prerequisite knowledge, since you can then appeal to more users. 
    • Decide whether you want to encourage attendees to work in teams. This can help resolve the issue of different skill levels - an advanced developer could work with a newbie. If you want devs to work in teams, you then need to decide if you will encourage team forming before the event or at the event, and what you will do in terms of people that don't know eachother. Try to avoid a team of all newbies at all costs, or pair them with a TA.
    • Decide whether you want the codelab to be guided or self-guided. A guided codelab involves a teacher leading the audience slowly through each step, and waiting for mostly everyone to be done before moving onto the next step. A self-guided codelab usually starts with a teacher giving a first intro and going through the first step, and then leaving the audience to follow steps in a document for the rest of the time. The self-guided codelab can be better at dealing with mixed audiences, but it can also lead to some people not being motivated enough to continue on their own.
    • Decide if you want to have a competition aspect to the event. This can be as simple as a small reward for whoever finishes a codelab first (if self-guided). Don't make it too competitive, as the emphasis should be on learning.
    • Find a venue with good internet connectivity and tables. The best tables for a guided codelab is classroom style- long tables facing the front. The best tables for a self-guided codelab are round tables, so that people help eachother and that it's easy for TAs to get around. A possible venue is a computer lab, particularly if you're at a university, and this can work well if you don't expect people to have laptops or want them to have a consistent setup. Be wary with computer labs however -- if your topic requires any installations, the admin level may be too restrictive to install.
    • Find TAs that can help answer questions at the event. Generally it's good to have 1 TA for every 10 students, but the more you can get, the better. The TAs should either be already familiar with the topic, or they should be very smart developers that can educate themselves about the topic before the event.
    • Create a backchannel for the event for developers that want to ask questions without having to approach a TA in person. You can use IRC with web clients like mibbit, or you can re-purpose the App Engine simple-ajax-chat app. Make sure the backchannel is moderated by a TA.
  • Agenda:
    • Guided codelab:
      • 2 hours: Guided codelab.
    • Self-guided codelab:
      • 30 minutes: Talk by teacher
      • 10 minutes: Everyone gets out their laptops, completes first step along with teacher
      • 1-1.5 hours: Everyone follows along with a doc, TAs walk around and answer questions
      • 10 minutes: If anyone wants to show off the result, you can have demos. 
      • 5 minutes: Conclude by pointing at future resources (docs, group) and where they should go for help.
  • Materials:

Hackathon - One day or less

  • Goal: Get people using a technology and actually creating demo-able apps. Also, encourage networking amongst attendees. Be careful to avoid having too many talks at a hackathon - you want to educate people enough so that they can use the technology, but you don't want to squash their energy and put them in passive lecture-watching mode.
  • # of Attendees: 10-80
  • Preparation:
    • Decide on the topic.
    • Decide on the agenda.
    • Book the venue.
    • Arrange for food (coffee, snacks, lunch, dinner).
    • Send out registration sheets.
  • Topic:
    • Should be interesting to many people.
    • Should be something that people can be creative with (make non-obvious apps).
    • Shouldn't require alot of setup, so that people can actually get something done in the relatively short period of time.
  • Venue:
    • Good internet connectivity is a must. Wifi best, ethernet as a backup.
    • Preferably round tables, as they're conducive to small chitchat as well as team forming.
    • Preferably near a kitchen, cafe, or vending machine in case people get hungry.
  • Agenda:
    • One day:
      • 10am: Registration/Welcome - Provide coffee (and little breakfast snacks, if budget)
      • 10:30am: Introduction talk to the topic
      • 11:30am: Show short demos of what other people have already created (to give ideas)
      • 12pm: Brainstorming lunch - split people into groups, encourage them to exchange ideas
      • 1pm: Idea pitches - encourage people to share their ideas with the rest of the group
      • 1:20pm: Show attendees where to go for resources, how to ask questions, etc.
      • 1:30pm: Hacking begins
      • 6pm: Demos, food, and drinks
      • 9pm: AFTER PARTY!
    • Half day:
      • 2:00: Registration opens
      • 2:30: Introduction / Housekeeping
      • 2:45: Intro Talks
      • 3:15: Team forming + Snacks + Brainstorming
      • 3:45: Hacking begins
      • o Encourage random 5-minute demos during hacking time
      • 6:30 - Dinner
      • 9:30 - Demos / Wrap-up

To add:
Weekend Hackathon
Social Events

Subpages (1): Google Maps APIs Talk