Sunday, August 8, 2010

How to pick & prepare an Ignite talk


I am now somewhat of an Ignite veteran. I've given talks at multiple Ignites, including Ignite Spatial (for GIS folks) and Google I/O Ignite (for hard core developers). I don't necessarily give the best talk, but I usually give a talk that goes over well. So, I thought I'd share my personal technique for creating an Ignite talk, as it can be a bit different from typical talks.

When I think of a topic for an Ignite talk, I look for one with the following characteristics:

  • Something that mixes humor, inspiration, information
  • Something I'm personally passionate about
  • Something that tells a story or has a narrative


Then, once I've decided the topic, I need to actually create the talk. I typically take these steps:

  • Spend a week simply thinking about the topic, hearing yourself talk about it in my head. It's a great way to spend the morning commute, and a great way to make sure that the flow of the talk will be natural once it's down on paper.
  • Create a text document. I usually draft in Wave these days, so that I can share it with my friend and ask for comments, but otherwise any old editor will do - some folks even use real-life things like post-its. The important thing is that it should be a format that allows you to iterate easily.
  • Write down a list of all the bits of information you potentially want to communicate, and order them according to what feels natural.
  • See if you are at or around 20 bits of information, where a bit is about 2-3 sentences (you may want to time yourself to see what your personal pace of communication is, and calibrate that #). If you have too many, think about what point to cut, or what details to leave. If you have too little, think about what else you might communicate - maybe more backstory, a calls to action, or an anecdote.
  • Say this talk to yourself. Say it to a friend. See if it feels natural, that everything transitions together, and that it's similar to the way you might spontaneously tell these bits of information. That will make it easier to deliver.
  • Start thinking about the visualization of your information bits. If you've got 5 bits in a row that you have no idea how to visualize, you may want to re-think those bits. Eventually, each bit will need a picture.
  • Keep playing around with the talk, moving bits of information around, moving them in and out, until you get to a point where it just feels right, and you're at the right # of slides.
  • Create a powerpoint (or keynote) presentation.
  • Insert a text box on each slide that contains the text for that slide. Position it below the slides.
  • Start filling in the visuals. They might be photos that you've taken, images from the web (like iStockPhoto or CC-licensed Flickr pics), or hand-drawn doodles. Try and make them be something that jives with the audience, but also jives your memory about the content of the slide.
  • Add short headers to each slide, if you want. Position them near the top of the slide, as the bottom is often hard for the audience to see. Try to avoid adding any text besides a header -- you don't want to distract audience members from what you're saying, and you don't want to make them feel they're reading off your talk.
  • Move the slide text up to the bottom of the slide.
  • Set the animation settings for auto-advance every 15 seconds.
  • Start practicing the talk. Since the slide text is visible, you get to view the text while practicing. After each practice, go back and make any tweaks to the text, change anything that didn't feel right, went too long, etc.
  • Once you feel comfortable, move the slide text below the slides, and practice the talk that way multiple times. This is the test that most nearly mimics the actual event characteristics.
  • Create a text document with all of your slide text, and print it out. You can now carry it around and practice it to yourself when you have the chance, like at the bathroom at the venue. :)
  • Go to Ignite! Drink water. Give the talk. Be excited.
  • Create a version of the slides that's consumable by non-Ignite attendees by moving the slide text box back onto the bottom of the slides. Upload it to Scribd, Slideshare, Google docs, and share it on Twitter, Facebook, etc. People love to read through these short slidesets, and with the transcript pasted on, the slides will actually make sense.



My past Ignite talks:

Friday, August 6, 2010

Why I Like Prezi

In my life, I have given a *lot* of presentations. In high school, they were presentations on group projects. In university, they were presentations on research projects. At Google, they're presentations on how to use our APIs. When I first started giving presentations, I used Powerpoint, like everyone else. But I kept thinking there must be a better way, and I experimented with other options - flash interfaces, interactive Javascript apps. Then I discovered Prezi, and it has become my presentation tool of choice.

Prezi is an online tool for creating presentations — but it's not just a Powerpoint clone, like the Zoho or Google offering. When you first create a Prezi, you're greeted with a blank canvas and a small toolbox. You can write text, insert images, and draw arrows. You can draw frames (visible or hidden) around bits of content, and then you can define a path from one frame to the next frame. That path is your presentation. It's like being able to draw your thoughts on a whiteboard, and then instructing a camera where to go and what to zoom into. It's a simple idea, but I love it. Here's why:

  • It forces me to "shape" my presentation. A slide deck is always linear in form, with no obvious structure of ideas inside of it. Each of my Prezis has a structure, and each structure is different. The structure is visual, but it supports a conceptual structure. One structure might be 3 main ideas, with rows of ideas for each one. Another might be 1 main idea, with a circular branching of subideas. Having a structure helps me to have more of a point to my presentations, and to realize the core ideas of them.
  • It makes it easy to go from brainstorming stage to presentation stage, all in the same tool. I can write a bunch of thoughts, insert some images, and easily move them around, cluster them, re-order them, etc. I can figure out the structure of my presentation by looking at what I have laid out, and seeing how they fit together. Some people do this process with post-its, but I like being able to do it with a digital canvas.
  • It works well for explaining concepts that make more sense with a diagram, because you can basically make your entire presentation be the diagram — and then you can just fly around that diagram, pointing out the flow and zooming into the important bits. For example, I used pseudo diagrams inside the robots API and gadgets API prezis to explain the API <-> server interaction.

Prezi isn't perfect, of course. I've made several feature requests, and have a list of others. There are the small requests, like wanting higher quality images and a code style for embedded snippets, and there are also the big picture requests. I want to be able to link prezis inside of prezis, so that I can make "components" of presentations, and easily zoom from one to the other. I want to be able to create multiple paths for a given prezi, so that I can skip over bits for some audiences, and emphasize them for others. Hell, I'd love if I could have one canvas that had every bit of possible content on a topic, and I could use that one canvas for 20 different presentations. I don't know that Prezi will ever implement these ideas, but I have more faith in them doing so than any other presentation tool, since they are making a point of thinking different.

Generally, I just love the fact that somebody is thinking different about presentation tools. There are so many people out there that are giving presentations every day, so as a society, we owe it to ourselves to invest more thought into how we do presentations. That's why I also like events like Ignite and Webjam, because they are challenging people to rethink the timing aspect of presentations.

(Not to talk about Wave all the time, but—)

My love for Prezi is similar to my love for Wave. Prezi is re-thinking presentations. Wave is re-thinking communication. Prezi gives me a blank canvas that can turn into a presentation of any shape. Wave gives me a blank wave that can turn into a document or conversation of any structure. Both of them are unfinished, but both have a bright future, and even if they don't succeed, they're successfully challenging the traditions of today.

Friday, July 23, 2010

How-to: 80s-ify your geek shirt!

I've created my first "instructable" on the technique I use for modding my t-shirts. Check it out here!

Sunday, July 18, 2010

Sydney MCA: Notable Artists

Wednesday, July 14, 2010

GTUG Campout: A weekend of HTML5 in 11+ Cities!

To quote the organizer:

"GTUG Campout is an annual weekend-long event where Google Technology User Group members have an opportunity to design, develop, and demo a complete application over the course of three days. This year, the theme will be HTML5. The event kicks off on Friday, August 13th, where ideas and teams will come together. Teams will then have the rest of the weekend to build their HTML5 applications before presenting their work to the public on Sunday evening."

The campout is so far scheduled to happen in GTUGs in 11 cities:

I will be in the bay area around that time anyway, so I'm going to join in on the SF Bay meetup. As I've done other hacking weekends and seen Wave is pretty useful for these kind of things, I'm going to put together a Wave-based forum and team wikis for the weekend. If you're participating in the campout, stay tuned for details on those!

Hacking weekends are always a lot of fun, and HTML5 is freaking awesome, so I encourage you to join at the city nearest you, or hey, just reserve that weekend for hacking and join in virtually!

Thursday, November 12, 2009

Developer Relations Explained (The Nerdy Way)

I often find it hard to answer the question, "So, what do you do at Google?" I find it hardest when that question is asked by someone completely outside the tech field, like a face-painter or a taxi driver, but it is hard even to explain to techies. It's not as simple as saying that I'm a tester, a software engineer, a product manager, or a support staff, because it's a crazy awesome combination of all the above. I'm in developer relations, and there are an awful lot of ways to relate to developers. We write articles and blog posts, create sample code and one-off projects, maintain open-source projects, respond to forum posts, triage bugs, speak at conferences, meet with partners, and generally do what needs to get done.

One way of explaining our various roles in developer relations is to break it down into two parts: first, the type of developers that we support, and second, the particular developer product(s) that we support. For example, I generally support long-tail developers, and I supported the Maps APIs for the first 3 years, and now I'm supporting the Wave APIs. Some of my colleagues support our higher-touch partners or even our paying customers, and their role involves more 1-on-1 meetings and emails. You can play with the little app below to experiment with more configurations of products and developer types:

Currently, in developer relations, we have one of two specific titles: "Developer Programs Engineer" and "Developer Advocate". Basically, the DPE supports the long-tail and the DA supports the high-touch partners. It doesn't really split as even as that in reality, but that's the basic idea.

So, that brings me to the real reason for this post. We are now hiring DPEs and DAs. The jobs site only lists positions for Mountain View and New York, but there are also scattered positions around the world, in places like Australia, China, and India. It's a fun challenge to figure out how best to relate to developers using our growing number of developer products (including the just-released Go language), and we can always benefit from having a broad range of opinions and skills represented on our team. If you're interested, apply! :)

Wednesday, October 28, 2009

Being a Girl in CS Doesn't Suck

When I posted last week about an experience with gender bias in "Should I Defend My Cred?", some of the re-tweets basically implied that post was proof that it sucks being a girl in CS. Well, I want to clarify that it doesn't suck. It's actually pretty freaking awesome.

What rocks:

  • Working with mostly guys.
    I'm sorry, girls, but I've always gotten along better with guys, ever since I was in elementary school. It's probably because I didn't quite fit into the girl mold (or any mold) back then, and thus girls were hesitant to accept me, while guys didn't really care as long as I was willing to shoot cannons with them. I know a lot of other girls in CS who say the same thing - that they're mostly friends with guys - and actually, those are the girls that I get along with best. So, yes, I should learn how to get along better with girls. But in the meantime, I'll always feel more comfortable working with guys.
  • "Working" with mostly guys.
    I once famously said "I only date guys who program in derivatives of ECMAScript". Well, it's kind of true. I prefer dating guys in tech because I have more stuff to talk about with them, so it's pretty handy that the tech industry is mostly guys. And yes, there is a bit of truth in the phrase often applied to guys in CS: "The goods are odd, but the odds are good"...but I'm pretty sure that the ratio of good guys is still in my favour. It's nice to be in an industry where I constantly encounter so many potential mates, and I don't have to rely on meeting random guys in a bar (which appears to be the dating preference of choice amongst adults, ick).
  • Being recognizable.
    As a girl amidst a sea of guys, I'm pretty easy to find. At a conference, all someone has to say is "find the girl with the red|blue|pink hair", and they can make a positive match pretty quickly. This easy recognition means that I can connect with more of the developers that want to talk to me. It can sometimes cause problems when people remember me better than I remember them (there's a limit to the number of white guys I can store in my head at once), but they are usually quite forgiving.
  • Getting more opportunities.
    Okay, I'm still not 100% sure how I feel about affirmative action.. except that I bet it's worked for me, and that I've probably benefited greatly from it. I remember asking my high school English teacher to review my college essay (which revolved around toilet flushing), and he glanced it over and said, "Well, you're applying as a girl in CS with a high SAT score, right? This shouldn't matter much."
    When an employer or university is comparing 2 equally skilled people, it makes sense that they select the one that increases the diversity of their staff/student body/conference/etc. Diversity is a good thing for teams, and it just so happens that the easiest way to measure diversity is by looking at aspects like race or gender. Theoretically, affirmative action could also applied be to hobbies and interests, and I could be selected due to my intense passion for 80s music (which actually does come up surprisingly often in my talks and demos). Until that happens, I will take advantage of the opportunities that I get by being a girl, and trust that I am not being given opportunities that I don't deserve.

What sucks:

  • Not enough chick flicks.
    I'm pretty sure I would have more excuses to watch romantic comedies if I hung out with more girls. But oh well, I'll just schedule a few more 12 hour trans-pacific flights.
  • Too little dancing.
    Guys don't generally go out dancing as their night activity of choice, at least not guys in western cultures. They tend to prefer a night of tipsy talk at a pub. I sometimes wish that I was a rock star or celebrity, and got to spend every night clubbing in exotic places... but until I acquire any sort of stage talent whatsoever, I think I'll settle with tricking guys into going to pubs with good music.

What really sucks:

  • Being afraid to admit all that.
    As a girl in CS, I am meant to have a very particular opinion about girls in CS. I feel that I risk being viewed as a traitor if I express other opinions. So, I generally try not to express any at all, and just go on my merry way. But, I now worry that other girls may feel the same fear, and that it is cowardly of me to keep my opinions to myself. Now, it's up to you to express your opinions, whatever they may be.