If you’ve been at Mozfest in London, you might have seen me stand next to a weird contraption of cables, tinfoil-covered squares and my computer. Here is what it looked like in action:
This was the so-called Interaction cam and here are the photos people took with it. This is how it works:
You put your hand on the pad on the left – this should stay there the whole time
You shoot a photo of yourself touching the pad on the right
If you like it, you touch the second pad from the right
Or you can discard it by touching the second pad to the left
You can also use the camera with more than one person. If one of you puts his hand on the left pad and the other on the right shaking hands, high-fiving or hugging would trigger the camera:
The camera stores the photos on the hard drive if you are offline or you can upload them to imgur.com immediately.
You can have the Interaction Cam for your event. All you need is a computer with a camera and one of the new browsers (Chrome, Firefox Nightly – Opera coming soon). Out-of-the box you can use the Space bar to take a photo, and the arrow right and left keys to upload or take another photo.
In order to make the pads work (and you can use anything that is an electrical conductor – fruit, water, vegetabless…) you need a MaKey MaKey and connect the appropriate parts of the MaKey MaKey (left, right, space and grounding) to the pads.
Your own cam – step by step
Here’s the step by step to have the camera for your event:
Have a laptop with a camera and Chrome or Firefox Nightly
Make sure to enable WebRTC in Firefox by typing “about:config”, saying yes that you want to make changes, finding the “media.navigator.enabled” entry and setting it to true
Make sure you have a PHP enabled local server if you want to keep the photos offline and not rely on uploading to the web (MAMP for Mac or XAMPP for Window – Linux folk know what to do)
Replace the mozfest.png file with your own event logo – this should be 600×104 pixels and use some transparency for more awesome (for other sizes you can alter the settings in interactioncam.js around “/* Branding */”
Go to your browser and open your install of the camera app – in my case http://localhost:8888/interaction-cam/
Grant the browser access to the camera – you should see it playing.
Press space to take a photo and store it by hitting the right arrow
On your hard drive, you should now have a file in the “copies” folder that is your photo
When all that works, add the MaKey MaKey:
Connect the MaKey MaKey via USB
Go through the recognition process of MaKey MaKey (like any other USB keyboard)
Lay out your pads/connectors and connect the cables to the appropriate parts of the MaKey MaKey (make sure they don’t touch)
Go back to your browser
Reload the Interaction Cam
Profit
That should do it – just upload the photos in your copies folder at your leisure later on and when you are connected to the web with a non-flaky connection.
Things that can go bump
Electricity, cables, computers and software are not natural and therefore hate humans. So things can go wrong. Here are a few things I found:
If the camera doesn’t start running make sure you have the latest Chrome or Firefox Nightly and have WebRTC turned on
If it still does nothing, you might need to reboot the computer (I had to a lot with the MacBook Pro)
If your computer has the power cable connected to it (which is a good idea as WebRTC is hungry to the battery) it can happen that just touching the “take photo” pad already triggers that. Just hide the leftmost pad then as it is not needed any longer. If someone doesn’t trigger the shooting, tell them to touch the left one, too.
Happy shooting! I am off to MozCamp Asia where I will put up the cam. And my friend Marc Thiele is planning on setting it up at Beyond Tellerrand, too.
Posted in General | Comments Off on A $40 photobooth for your event – powered by WebRTC and MaKey MaKey
Today I went to the Spotify office in Stockholm to test-run a training I’ll give at the MozCamp in Singapore next month. The topic was turning geeks into presenters, how to foster a culture of speaking and presenting in a company and tricks how to become a better speaker.
This is a quick introductory talk on how to foster a culture of presenting and speaking and a few tips on how to become a better speaker yourself.
Why present?
The first question to ask yourself is why you’d want to start presenting. There has to be a reason for it.
Geek barriers
It is not easy for geeks to start becoming a presenter. In a lot of cases our nature doesn’t lend itself to being an outgoing person that other people understand. There is a reason why we chose IT as a profession and not something where we primarily deal with people.Furthermore years of bad experiences with company presentations and boring lectures have us conditioned to dislike them. The other issue is that speaking and presenting is considered a task people do who do not code any longer. You know, those managers and the suits and the like. It seems we are more excited about people who write amazing code that never gets released than people sharing what they want to do and get input before we create it. And complaining that people don’t care about our issues without reaching out to tell them about it doesn’t sound too logical either.
Presenting is translating, not selling
The best presenters I know don’t sell with their presentations.They explain, share their excitement and point people in the right direction to find things out for themselves.
People listen if you talk to them!
Giving a presentation internally is a great way to get people up to speed with what is happening. We can have all the documentation and emails in the world – if we don’t know that people read them we can not assume people know what we are on about. Scheduling an internal presentation means people hear at least once about it. External presentations are of course even better, not only make they learn people about what you and your company does, they also give you internal leverage. You are known on the outside for knowing your stuff and the company can benefit from you being associated with it.
Starting a speaking culture
Many companies already do have a culture of presenting but in many this privilege is given to only a few people. Those are coached to be perfect pitch presenters and drive an even larger gap between the people who do things in the company and those who talk about it. Of course we need good professional presenters (and every manager should have some training) but the real success comes by sharing the fame and the responsibilities with everyone in the company.
A few tools
Just in terms to break down barriers and to get people out of the woodwork and start speaking there are a few things companies can do that proved effective in the past.
Powerpoint Karaoke
Powerpoint Karaoke is a great way to get the fear out of presenting. Here is how it works:
Download random powerpoints of the interweb
Pick a random person
The person should present the deck for 5 minutes
Seemingly just a silly thing, powerpoint karaoke can have a lot of positive effects.
It teaches you to not be a slave to your deck
It breaks down the initial barrier – everybody can look the fool for five minutes
You get to know what to avoid in your own slides
You start to learn speaking, not just re-iterating (you are not in your subject matter)
Lightning talks
Lightning talks are a great opportunity to discuss issues and solutions and get people to do their first talks.
15 minutes each week
5 minutes: a problem we encountered
5 minutes: a solution we found and applied
5 minutes: discussion if this is a good solution and should become a best practice
I’ve found lightning talks in the past a very good solution for people to get their first speaking experience. They are not scary and they give you a chance to say what you want to say. The reasons are:
The speaker knows his stuff
The speaker talks about a positive experience – fixing something
A Fixed time and duration means predictability which is less scary
Everybody gets to have a go
Content repos beat a slide repository
Instead of archiving slide decks and sending them around the company to present over and over again create a content repository much like a pattern library. This allows people to get information they need and assemble their talks from it rather than repeating someone else’s talk flow and fail at that.
Preliminaries – what to do yourself
There are a few things you can do before you start even thinking about speaking. These may sound weird, but they will save you a lot of time in the future and make you a much more focused and better presenter.
Forget about the slide deck
The first thing to consider is forgetting about your slide deck. Your slides are the backdrop to your talk, if you read them out you are redundant. Furthermore everything you can think of can go wrong about your presentation – be safe, don’t rely on them.
Find excitement
In order to really give good presentations, you need to be excited about what you present. If that naturally happens, good. Move on. If not, find an angle that makes the subject matter exciting for you and then tell a story around that angle.
Share pain and excitement
One big obstacle for a lot of new speakers is to move from human to expert that needs to inspire. This step is much less hard to take when you stay human and think of human ways to interact with the audience. Share that you are excited and/or afraid of being on stage and talking about this. Be human, be honest. Good stories on how you reached conclusions, how you bettered your ways and how a failure got turned into a success are a great way to give an inspiring talk. Use them.
Learn to endure and adore yourself
One big step to becoming a good speaker is to get used to yourself, to the sound of your voice and the person you appear to be. How other people see us is very different to how we see ourselves and this very much starts with the voice. Our heads vibrate when we speak which means we hear ourselves muchdeeper than we really sound.
Speak loud, clear and proud
Being understandable on stage is incredibly important. A lot of this is about breathing technique and timing yourself the right way. This takes practice and gets better the more you do it. A great little but also very goofy trick is to put a cork in your mouth and speak at the same time. Try to become as understandable as possible – that way you learn how to breathe correctly.
Record and playback
Watching videos of yourself is awkward but a very important partto becoming a speaker. This is how you come across, and this is the person you are – get used to it. You are your worst critic and that is good. Also have good friends watch you and tell you what can be improved.
Projection
Body language is a massive part of presenting or communication over all. There are many studies on the subject with at times scary findings. People do judge you by how you project, not by who you are. This takes time and effort and not many people are happy to go that far. Therefore you need to be aware of what body language works and what doesn’t. What you give the audience is how they react. You need to lead not only with your words but also with your body.
Practice your stage voice and manners
If you have kids – lucky you. If you don’t, get access to some. Then take a good children’s book and read to them. Loud and with lots of gestures and different voices for the different characters. The kid will love it and you break out of your shell and get more confident in projecting and speaking clear and loud.
An incredibly simple solution
Amy Cuddy’s “Your body language shapes who you are” is not only an amazing talk, but gives you a very simple solution to your projection issues. It turns out that you can make yourself more confident and outgoing by just using the same body language as confident and powerful people do. Sounds too simple, but our body chemistry shows proof.Amy Cuddy: Your body language shapes who you are
Learn from others
The first step to being a good speaker is to get inspired and learn by watching other people do it. A lot of conference videos are available on the web, so check them out there. TED is a great resource for seeing amazing talks – but be aware that this is the master class, don’t feel bad about these talks. A lot of rehearsal and work went into them and they only look very easy to deliver.
Go to (un)conferences and share afterwards
Going to conferences is a very good step, even better are unconferences as it means you have to speak, too. Whenever the company allows people to go to conferences it should be on the condition to give a talk (or at least send an email report) about the event afterwards. That way there is no jealousy amongst people and you can set up an archive of what conferences are worth while and which aren’t.
Do not copy!
The danger there though is to copy verbatim what other people are doing. This will not make you or the audience happy as it is a lie to yourself and them. You can find things that you like and start using them but it needs to be natural – don’t force it.
Would you like to know more?
There are a few online resources you can check out.
I right now feel the itch to write a book again. I see a lot of people buying books and making a living selling them and I feel that there is a space for what I have in mind. I also don’t see how I could cover all the things I want to cover right now in talks or blog posts. It is presumptuous to think you’d follow a series of them so using a book form with code and possibly a series of screencasts seems to be the right format.
I have a few outstanding offers by publishers but having my first publisher just hand over a second edition of my first book to someone else without waiting for my yay or nay makes it less interesting to me to go through the traditional publishing route. Whilst I am pondering other distribution offers (and if you have some, talk to me) here is what I am planning to write about:
The web needs a diet
Web development as we know it has gone leaps and bounds lately. With HTML5 we have a massive opportunity based on a predictable rendering algorithm across browsers. CSS has evolved from removing the underline of links and re-adding it on hover to a language to define layout, animation and transformations. The JavaScript parts of HTML5 give us a much simpler way to access the DOM and manipulate content than traditional DHTML and DOMScripting allows us to.
Regardless of that, we still clog the web with lots and lots of unnecessary code. The average web site is well beyond a megabyte of data with lots of HTTP requests as our desktop machines and connections allow us to add more and more – in case we need it later.
On mobile the whole thing looks different though and connectivity is more flaky and each byte counts. In any case we should be thinking about slimming down our output as we put more and more code that is not needed out, adding to a landfill or quickly dating solutions that will not get updated and fixed for future environments and browsers. We litter the web right now, and the reasons are:
A wrong sense of duty to support outdated technology (yes, OLDIE) without really testing if our support really helps users of it
A wrong sense of thinking that everything needs to be extensible and architected on a enterprise level instead of embracing the fleeting nature of web products and using a YAGNI approach.
An unwarranted excitement about technology that looks shiny but is not to be trusted to be around for long
Shed those kilobytes with the fat-free vanilla approach
In the book I’d like to outline a pragmatic and backwards compatible way of thinking and developing for the web:
We start with standards-compliant code that works without relying on hacks and temporary solutions
We improve when and if the environment our code is consumed in supports what we want to do
Instead of shoe-horning functionality into outdated environments, we don’t leave promises of functionality when it can not be applied
We write the right amount of code to be understandable and maintainable instead of abstracting code to write the least amount without knowing what the final outcome is
The book will be opinionated and challenge a few ideas that we started to love because of their perceived usefulness for developers. In the end though I want to make people aware of our duty to produce the best products for our end users and to write code for the person who will take over from us when we want to move on to other things.
The book will teach you a few things:
How to build with instead of just for the web
How to use what browsers can do to build without writing much code
How to avoid writing code that will fail in the near future
How to not make yourself dependent on code you don’t control
How to learn to let go of “best practices” that made a lot of sense in the past but are not applicable any longer
How to have fun with what we have as web developers these days without repeating mistakes of the past
How to embrace the nature of the web – where everybody is invited, regardless of ability, location or technology
This morning I gave the keynote at the Eclipsecon Europe in Ludwigsburg, Germany. Around 500 Eclipse and Java fans waited for some information about the latest and greatest in the web and here is what I gave them.
In terms of releasing code into the wild we live in terribly exciting times. Products like GitHub, Dropbox, online collaboration tools like JSFiddle, JSBin, Codepen and Dabblet make it very easy to show our code to the outside world. Furthermore, a lot of products are build in a modular manner which means you can simply participate by writing a plugin or add-on instead of coming up with your own solutions. jQuery and WordPress are living proof of that.
Quick release, moving on fast
One of the biggest dangers of a very simple infrastructure is the one of inflation. When it is easy to release something, a lot will be released. This means it becomes much harder to find good quality content and we are tempted to release more rather than releasing a few things we really care about and are ready to also care for in the future. Much like we write shorter, and less thought-out emails than letters we tend to get into a frenzy of releasing smaller, shorter and less documented products.
This is open source – or is it?
This is where we run a current danger of cheapening the term “open source”. Releasing an open source product is much more than making it available for free. It is a process, an ongoing commitment to nurturing something by sharing it with the world. Open source and its merits can actually be a blueprint of a much more democratic world to come as Clay Shirky explains in How the Internet will (one day) transform government.
During the Fronteers conference, David DeSandro gave a talk about monetising jQuery plugins and how to keep your sanity at the same time. His main concerns were that his plugins (mostly Masonry) cost a lot of his time and didn’t bring in enough to make a living off them. Several times during the talk he explained that he does have a job and that he has no time to answer every email. After all, there should be no need to ask questions or get support as the code is available and on Github and people could help each other and be happy that the code was released as open source. How come there was no magical community appearing out of nowhere that took care of all this?
Open Source is more than releasing code
Well, this wasn’t an open source project. The code was released in the open and is available on a repository, but it is not open source. Open source means – at least to me and a lot of people I talked to – that products are produced and maintained in the open.
This encompasses much more than just putting the code on GitHub. It means:
being ready to take on pull request and patches and communicate to the people who do them when and if they are released
helping people to get involved
communicate changes to the outside world
reacting to security issues and performance issues
answering feature requests
dealing with licensing issues
ensuring that the product evolves and changes as a reaction to new environments and market needs
encouraging people to contribute and help others
recognising people for helping out others and sharing the fruits of the labour with them
Open source is a lot of work and needs a community
This means a lot of work and it is the reason why a true open source project is not done by one person but from the very beginning should be planned around a group of people. People who are happy to share ownership and responsibilities as much as the benefits and the income from the project with others. People who are ready to hand over responsibilities should they get tired of them and to train their predecessors with that in mind. To be truly open source you should think about the maintenance and the future of the project before you release it. It is a group effort and the very tricky part is finding the group without hiring them.
A lot of what people call open source these days feels like “Tada-source” or “Pasture-source” to me:
Ta-da source – products that are released as a final commercial version as-is and get a source release to the world later. Instead of making the world part of the creation process it becomes maintenance staff to fix bugs and add the things they need to the product. This allows you to say you are open without having to deal with people’s needs and to stick to your own agenda when it comes to core functionality.
Pasture source – this is when products were financially viable and interesting but became a nuisance. Instead of maintaining them they go to the pasture of open source where kind shepherds without pay will ensure the products will live happily ever after. Pasture source happens either because of the workload of communication getting too much or because the business you work for doesn’t see the product as something they should pour resources into. A lot of times this is a PR exercise – “hey this product didn’t do well, but now that it is open it will be the next new cool thing for the open source community”
Brackets – a positive surprise
When Adobe said they’ll release their editor Brackets as Open Source and have it as Edge Code in their new set of tools for web developers I was not alone in being wary about this. It sounded like a closed source company trying to play with the rebel kids. Technically this is not new, as Adobe already did a lot of open releases with Air and even released the books under Creative Commons but it still felt “well, let’s see what is coming there”.
When seeing Adam Lehman talk about Brackets and their approach at the Adobe event in London I was very impressed to see how the project is run as an open source project. The code, of course, is available on Github, but that is not all. The project is following an Agile process using Scrum, pull requests are being reviewed every day, it has a 2.5 week release cycle and external contributions take priority. A detailed blog with release notes of each sprint is also available.
The project is managed in the open on Trello and a very clever way to get new contributers is to triage simple bugs as “quick wins” for new contributors rather than having more advanced developers spend their time on fixing them.
This is a great example of approaching an open source release of a product with the right tools and the right mindset. Yes, it is a lot of work, but I am quite confident that this means Brackets will be around for a long time, even if the Edge suite failed.
Don’t stop releasing
I am not saying that we should stop releasing things and making them available on GitHub and others. I am simply saying that open source means much more than that and that we shouldn’t be surprised if we get less contributors than we think if all we do is throw some code out and wait for magic to happen. Open Source means we get people’s time to build with us, not for us.
So when you release things, don’t call it an open source project, unless you are ready to go the full distance. Just put it out there and tell people that it is free and available, and that it is up to them what happens with it.
Posted in General | Comments Off on Don’t call it “open source” unless you mean it
