Think

Presenter tip: animated GIFs are not as cool as we think

Disclaimer: I have no right to tell you what to do and how to present – how dare I? You can do whatever you want. I am not “hating” on anything – and I don’t like the term. I am also guilty and will be so in the future of the things I will talk about here. So, bear with me: as someone who spends most of his life currently presenting, being at conferences and coaching people to become presenters, I think it is time for an intervention.

The hardest part of putting together a talk for developers is finding the funny gifs that accurately represent your topic.

The Tweet that started this and its thread

If you are a technical presenter and you consider adding lots of animated GIFs to your slides, stop, and reconsider. Consider other ways to spend your time instead. For example:

  • Writing a really clean code example and keeping it in a documented code repository for people to use
  • Researching how very successful people use the thing you want the audience to care
  • Finding a real life example where a certain way of working made a real difference and how it could be applied to an abstract coding idea
  • Researching real numbers to back up your argument or disprove common “truths”

Don’t fall for the “oh, but it is cool and everybody else does it” trap. Why? because when everybody does it there is nothing cool or new about it.

Animated GIFs are ubiquitous on the web right now and we all love them. They are short videos that work in any environment, they are funny and – being very pixelated – have a “punk” feel to them.

This, to me, was the reason presenters used them in technical presentations in the first place. They were a disruption, they were fresh, they were different.

We all got bored to tears by corporate presentations that had more bullets than the showdown in a Western movie. We all got fed up with amazingly brushed up presentations by visual aficionados that had just one too many inspiring butterfly or beautiful sunset.

added text to sunrise

We wanted something gritty, something closer to the metal – just as we are. Let’s be different, let’s disrupt, let’s show a seemingly unconnected animation full of pixels.

This is great and still there are many good reasons to use an animated GIF in our presentations:

  • They are an eye catcher – animated things is what we look at as humans. The subconscious check if something that moves is a saber tooth tiger trying to eat me is deeply ingrained in us. This can make an animated GIF a good first slide in a new section of your talk: you seemingly do something unexpected but what you want to achieve is to get the audience to reset and focus on the next topic you’d like to cover.
  • They can be a good emphasis of what you are saying. When Soledad Penades shows a lady drinking under the table (6:05) when talking about her insecurities as someone people look up to it makes a point. soledad and drinking lady When Jake Archibald explains that navigator.onLine will be true even if the network cable is plugged into some soil (26:00) it is a funny, exciting and simple thing to do and adds to the point he makes. jake and the soil
  • It is an in-crowd ting to do – the irreverence of an animated, meme-ish GIF tells the audience that you are one of them, not a professional, slick and tamed corporate speaker.

But is it? Isn’t a trick that everybody uses way past being disruptive? Are we all unique and different when we all use the same content? How many more times do we have to endure the “this escalated quicklyGIF taken from a 10 year old movie? Let’s not even talk about the issue that we expect the audience to get the reference and why it would be funny.

We’re running the danger here of becoming predictable and boring. Especially when you see speakers who use an animated GIF and know it wasn’t needed and then try to shoe-horn it somehow into their narration. It is not a rite of passage. You should use the right presentation technique to achieve a certain response. A GIF that is in your slides just to be there is like an unused global variable in your code – distracting, bad practice and in general causing confusion.

The reasons why we use animated GIFs (or videos for that matter) in slides are also their main problem:

  • They do distract the audience – as a “whoa, something’s happening” reminder to the audience, that is good. When you have to compete with the blinking thing behind you it is bad. This is especially true when you chose a very “out there” GIF and you spend too much time talking over it. A fast animation or a very short loop can get annoying for the audience and instead of seeing you as a cool presenter they get headaches and think “please move on to the next slide” without listening to you. I made that mistake with my rainbow vomiting dwarf at HTML5Devconf in 2013 and was called out on Twitter.
  • They are too easy to add – many a times we are tempted just to go for the funny cat pounding a strawberry because it is cool and it means we are different as a presenter and surprising.

Well, it isn’t surprising any longer and it can be seen as a cheap way out for us as creators of a presentation. Filler material is filler material, no matter how quirky.

You don’t make a boring topic more interesting by adding animated images. You also don’t make a boring lecture more interesting by sitting on a fart cushion. Sure, it will wake people up and maybe get a giggle but it doesn’t give you a more focused audience. We stopped using 3D transforms in between slides and fiery text as they are seen as a sign of a bad presenter trying to make up for a lack of stage presence or lack of content with shiny things. Don’t be that person.

When it comes to technical presentations there is one important thing to remember: your slides do not matter and are not your presentation. You are.

Your slides are either:

  • wallpaper for your talking parts
  • emphasis of what you are currently covering or
  • a code example.

If a slide doesn’t cover any of these cases – remove it. Wallpaper doesn’t blink. It is there to be in the background and make the person in front of it stand out more. You already have to compete with a lot of of other speakers, audience fatigue, technical problems, sound issues, the state of your body and bad lighting. Don’t add to the distractions you have to overcome by adding shiny trinkets of your own making.

You don’t make boring content more interesting by wrapping it in a shiny box. Instead, don’t talk about the boring parts. Make them interesting by approaching them differently, show a URL and a screenshot of the boring resources and tell people what they mean in the context of the topic you talk about. If you’re bored about something you can bet the audience is, too. How you come across is how the audience will react. And insincerity is the worst thing you can project. Being afraid or being shy or just being informative is totally fine. Don’t try too hard to please a current fashion – be yourself and be excited about what you present and the rest falls into place.

So, by all means, use animated GIFs when they fit – give humorous and irreverent presentations. But only do it when this really is you and the rest of your stage persona fits. There are masterful people out there doing this right – Jenn Schiffer comes to mind. If you go for this – go all in. Don’t let the fun parts of your talk steal your thunder. As a presenter, you are entertainer, educator and explainer. It is a mix, and as all mixes go, they only work when they feel rounded and in the right rhythm.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Teaching people to think about code instead of acing a test

One of my biggest bugbears with education, learning and teaching – especially online – is the focus we have on testing people by giving them multiple choice questions or having them fill out a very specific and rigidly defined test. This is a remnant from school education, where it is important to compare pupils and to also make it easy to measure the success rate and effectiveness of the teacher. Overly simplified, our school systems are designed to create new professors, not people who use the knowledge elsewhere. Ken Robinson covered this nicely in his TED talk How schools kill creativity and Salman Khan (founder of Khan Academy) ran with it in his TED talk as well.

The problem with rigid tests is that they can be gamed. I knew quite a few students and interviewees who learned information by heart, aced tests and came out not remembering a single thing let alone being able to apply the knowledge in a different scenario. The learned the what, but not the why.

calvin finds a loophole in a test

Job interviewers make the mistake of having a fixed set of questions and then compare different applicants by how they fared. This is not only boring for the interviewer, it also doesn’t tell you much about how the person you interview ticks. And in the end you want to work with that person, see them grow and apply their problem solving skills in various different scenarios. At Yahoo we had a great way of doing this – we gave people a code exercise that encompassed creating a small web site from a photoshop comp. We told them what the thing should do and then let them decide how to approach it. We looked at the result they sent us and if it worked nicely, we invited them to an interview where the first half hour or hour was them explaining to us why they approached solving the problem in a certain way, what their frustrations were, and how they cut corners and why. We learned a lot about the people that way, because programmers who can explain what they did are people who can code.

This is why I am very happy to see that some people are creative enough to approach teaching to code differently than others. There are quite a few new resources out there that teach coding by describing problems and asking the learner to write code that then gets validated in a worker thread (in the case of JavaScript). Code Combat for example is a beautiful product using that approach.

Yesterday I was super happy to see that Mozillian Brian Bondy who took in onto himself to create a series of videos explaining how to contribute to Firefox at codefirefox.com added a series of small coding exercises to this endeavour.

Instead of telling you to “create variable a and assign the value foo to it as a string” the exercises on codefirefox.com are task descriptions like

Create a new variable declaration and initialize it with a literal value in one statement.

This teaches you the lingo (you might have to look it up to understand the question but you now what a declaration is afterwards) and allows you to choose what you want to do. You creatively code instead of answering a question. There is a text editor embedded in the page that analyses what you do and if you manage to get a task done, ticks it off for you. All you do is code instead of following yet another “next lesson” button navigation.

Even better is that Brian released the framework that allows you to create tests like that. Under the hood it uses Acorn by Marijn Haverbeke in a web worker to analyse the code and test it against assertions you defined in a simple API.

var c = new Codec();
c.addAssertion("x = 3;");
c.addAssertion("x++", { blacklist: true, otherProps: "hi" });
c.parseSample("if (x) { x = 3; }", function(err) {
  console.log('whitelist hit? ' + c.assertions[0].hit);
  console.log('blacklist hit? ' + c.assertions[1].hit);
});

The codefirefox exercise module code is available on GitHub.

I am very excited about this and hope that some people will take this on. Brian is doing a great job with this and more is to come.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)