How to write a talk

Hey Sole, you have spoken on a lot of places and go to a lot of conferences, so maybe you have some advice on how to write a talk?

Yes, indeed I do! In fact, this question comes up so often that I figured it would be super useful to share my method with more people, rather than just individually 🙂

Before we start, allow me to highlight that this is my method, and it might not suit you. Talks come in many formats and shapes depending on their content, the audience and many other factors. I usually talk about technical stuff, and this guide is about writing that type of talks.

Also, if you’re the TL;DR type, I made you a flow chart (using draw.io):

how to write a talk flow chart

Continue reading How to write a talk

Article about the MediaRecorder API in .net magazine

MediaRecorder article picture

I wrote an article on the MediaRecorder API for .net magazine issue 283.

This isn’t an exhaustive article, just a little advance on what the API can do, as part of the Standards section that tracks new and upcoming APIs. If you want to learn more about the MediaRecorder API, there’s the way more detailed Hacks article I wrote: Record almost everything in the browser with MediaRecorder, or maybe you can watch one of the talks I’ve given on the subject, like this one.

dogetest.com

This summer, Sam and me are exploring Servo’s capabilities and building cool demos to showcase them (and most specially, WebRender, its engine “that aims to draw web content like a modern game engine”).

We could say there are two ways of experimenting. One in which you go and try out things as you think of them, and another one in which you look at what works first, and build a catalogue of resources that you can use to experiment with. An imperfect metaphor would be a comparison between going into an arts store and pick a tool… try something… then try something else with another tool as you see fit, etc (if the store would allow this), versus establishing what tools you can use before you go to the store to buy them to build your experiment.

WebRender is very good at CSS, but we didn’t know for sure what worked. We kept having “ideas” but stumbled upon walls of lack of implementation, or we would forget that X or Y didn’t work, and then we’d try to use that feature again and found that it was still not working.

To avoid that, we built two demo/tests that repeatedly render the same type of element and a different feature applied to each one: CSS transformations and CSS filters.

CSS transformations test

This way we can quickly determine what works, and we can also compare the behaviour between browsers, which is really neat when things look “weird”. And each time we want to build a new demo, we can look at the demos and be “ah, this didn’t work, but maybe I could use that other thing”.

Our tests use two types of element for now: a DIV with the unofficial but de facto Servo logo (a doge inside a cog wheel), and an IFRAME with an image as well. We chose those elements for two reasons: because the DIV is a sort of minimum building block, and because IFRAMEs tend to be a little “difficult”, with them being their own document and etc… they raise the rendering bar, so to speak 😉

All together, the tests looked so poignantly funny to me, I couldn’t but share them with the rest of the world:

and Eddy Bruel said something that inspired us to build another test… how many doges can your computer render before it slows down?

I love challenges, so it didn’t take me much to build the dogemania test.

It can ridiculise my MacBook retina very quickly, while people using desktop computers were like “so what’s the fuss, I get 9000 doges with no sweat?”

It was also very funny when people sent me their screenshots of trying the test on their office screen systems:

Servo engineers were quite amused and excited! That was cool! We also seemed to have surfaced new bugs which is always exciting. And look at the title of the bug: Doges disappear unless they are large and perfectly upright. Beautiful!

To add to the excitement, this morning I found this message on my idling IRC window:

7:22 PM <jack> http://dogetest.com
7:22 PM <jack> we all love it so much i thought it needed it's own domain :)

So you can now send everyone to dogetest.com 🎉

Thanks, Jack!

Web Animations: why and when to use them, and some demos we wrote

There’s been much talk of Web Animations for a long time but it wasn’t quite clear what that meant exactly, or even when could we get that new thing working in our browsers, or whether we should actually care about it.

A few weeks ago, Belén, Sam and me met to brainstorm and build some demos to accompany the Firefox 48 release with early support for Web Animations. We had been asked with very little time, but we reckoned we could build at least a handful of them.

We tried to look at this from a different, pragmatic perspective.

Most graphic API demos tend to be very technical and abstract, which tends to excite graphics people but mean nothing to web developers. The problem web developers face is not making circles bounce randomly on the screen, it is to display and format text on screen, and they have to write CSS and work with designers who want to play a bit with the CSS code to give it as much ‘swooosh’ as they envision. Any help we can provide to these developers so they can evaluate new APIs quickly and decide if it’s going to make their work easier is going to be highly appreciated.

So our demos focused less on moving DIVs around and more on delivering value, either to developers by offering side by side comparisons (JS vs CSS code and JS vs CSS performance) or to end users with an example of an style guide where designers can experiment with the animation values in situ, and another example where the user can adjust the amount of animation to their liking—we see this as a way of using the API for improving accessibility.

You can also download all the demos from the repo:

git clone https://github.com/mozdevs/Animation-examples.git

And should you use CSS or should you use JS? The answer is: it depends.

Let’s look at the same animation defined with CSS and JS, taken straight from the CSS vs JS demo:

CSS:

.rainbow {
    animation: rainbow 2s alternate infinite;
}

@keyframes rainbow {
    0% { background: #ff004d; }
    20% { background: #ff77ab; }
    50% { background: #00e756; }
    80% { background: #29adff; }
    100% { background: #ff77ab;}
}

JavaScript:

let el = document.querySelector('.rainbow');
el.animate([
    { background: '#ff004d', offset: 0 },
    { background: '#ff77ab', offset: 0.20 },
    { background: '#00e756', offset: 0.5 },
    { background: '#29adff', offset: 0.80 },
    { background: '#ff77ab', offset: 1 }
], {
    duration: 2000,
    direction: 'alternate',
    iterations: Infinity
});

As you can see, this is fairly similar.

CSS’s syntax for animations has been with us for a while. We know how it works, there is good support across browsers and there is tooling to generate keyframes. But once the keyframes are defined, there’s no going back. Modifying them on the fly is difficult unless you start messing with strings to build styles.

This is where the JS API proves its worth. It can tap into live animations, and it can create new animations. And you can create animations that are very tedious to define in CSS, even using preprocessors, or just plain impossible to predict: imagine that you want custom colour animations starting from an unknown colour A and going to another unknown colour B. Trying to pregenerate all these unknown transitions from the beginning would result in an enormous CSS file which is hard to maintain, and would not even be as accurate as a newly created animation could be.

There’s another advantage of using the Web Animations API versus animating with a library such as tween.js—the API is hardware accelerated and also runs on the compositor thread, which means incredibly smooth performance and pretty much perfect timing. When you animate DOM elements using JavaScript you have to create lots of strings to set the style property of these DOM elements. This will eventually kick a pretty massive Garbage Collector, which will make your animations pause for a bit: the dreaded jank!

Finally another cool feature of these native animations is that you can inspect them using the browser developer tools. And you can scrub back and forth, change their speed to slow them down or make them faster, etc. You cannot tap into JS-library-defined animations (e.g. tween.js) unless there’s support from the library such an inspector, etc.

Essentially: Web Animations cheat by running at browser level. This is the best option if you want to animate DOM elements. For interpolating between plain values (e.g. a three.js object position vector x, y, z properties) you should use tween.js or similar.

If you want to know more here’s an article at Hacks talking about compositors, layers and other internals, and inspecting with DevTools. And with plenty of foxes!

The full API isn’t implemented in any browser yet, but both Firefox and Chrome stable have initial support already. There’s no excuse: start animating things already! I’m also excited that both browsers shipped this early support more or less simultaneously—makes things so much easier for developers.

With mega thanks to Belén for pushing this forward and to Sam for going out of his internship way to help us with this 🙌🏼

Why I won’t talk about being a woman in tech (and neither should you)

I won’t do talks on “being a female in tech” for a number of reasons.

First, because they prevent me from doing talks on tech, which is what I would actually like to do, because that’s what I am best at. If someone approaches me to talk somewhere just because I’m a woman, they haven’t done their job of finding what my expertise is. Therefore, I am going to insta-decline.

It not only is very insulting and distracting, but also pigeonholes you into “talking about being a woman in tech”, instead of “woman who knows her tech”. It feels like, once again, we’re delegating on women and other vulnerable collectives the “caring for others” matters, in addition to their normal job. That is not OK.

Second, it devaluates the job of diversity and gender studies professionals, as it is implied that just by virtue of me being a women, I not only can talk for all other women, but also know how to fix things for all other women (note: I don’t).

That, in turn makes me the “token woman”, where everyone assumes that I represent all other technical women. This is a handicap on my abilities to actually do my job and be an excellent technical person, as it puts an additional pressure on me to be “perfect or go home” (ref: tokenism).

And it also makes me lose precious opportunities to be a good role model for other women. If they see that women in tech are relegated to “speaking about being a female in tech” instead of building and talking about solid technical stuff, they’re going to be discouraged and uninspired. Why try hard at tech if people are just interested in you because of your physiognomy? It is, once again, focusing on women physically, instead of highlighting their work and personal achievements.

Finally, I really dislike that it so often feels like either…

  • a really lazy attempt to solve the lack of diversity in conferences by organisers that didn’t do their work, but also do not want an internet storm rightly complaining about their all male line-up
  • or a feeble attempt at having a “trendy” topic in your conference, because “diversity is the hot new thing everyone is talking about”

No! The answer to an all male line-up is not a talk on women on tech by a woman. The answer is diverse people in the line-up, talking about tech. And if they want someone to cover that “trendy topic”, they should reach out to qualified people. They need to do their homework, instead of reaching out to the first “tech woman speaker” they can think of, and asking her to do a talk on something she’s not qualified on (which again, puts her in a vulnerable position).

This doesn’t mean that I do not care about other women in tech. Of course I care! I dream of the day we stop having these conversations because “being in tech” has become the normal default, but in the meantime I will contribute to pave the road to equality by talking about tech, inspiring other women and normalising the presence of women in these environments. Which is tiring enough, with all the sexism already present in our industry/society.