Lately it seems, CSS3 rollover showcases are getting a new revival. The massive collection of effects here made quite the rounds on Twitter the last weeks. As I wanted to play with 3D transforms a bit more, I thought I do a quick demo of how to use them to create a lovely rollover effect on a kitten photo cause we all know this is what the web is about. You can see the effect in action here and get the source code on GitHub. And here is a video of how the effect looks on Firefox 7 which does not support 3D transforms and on Firefox Aurora (or Safari, or Chrome) which do:

Now, how is this done? Here is a step by step example. We start with simple HTML that works on all the browsers (Step 1):

<ul>
  <li class="image3d">
    <figure>
      <img src="mittens.jpg" alt="Mittens the cat">
      <figcaption>
        <p>
          <strong>Mittens</strong> loves to play with yarn and stuff.
        </p>
      </figcaption>
    </figure>
  </li>
  <!-- repeated -->
</ul>

Then we style the caption to overlay the image by giving the LI dimensions and positioning it relative and giving the caption dimensions and positioning it absolutely. We set the opacity of the image to 40% to make the caption more readable (Step 2):

.positioned {
  list-style: none;
  width: 300px;
  height: 200px;
  position:relative;
}
.positioned figcaption {
  position: absolute;
  background: rgba( 0, 0, 0, 0.7 );
  color: #fff;
  border-radius: 5px;
  left: 65px;
  bottom: 10px;
  width: 230px;
}
.positioned img {
  opacity:0.4;    
}
.positioned figcaption strong {
  display: block;
  color: lime;
  font-weight: normal;
  font-size:22px;
  padding: 5px 0;
}
.positioned figcaption p {
  display: block;
  color: white;
  padding: 5px;
}

This works in almost any browser. Now we can make it interactive by adding a rollover style. We set the overflow of the list item to hidden and position the caption outside the list item. On rollover, we move the left position to the one inside the LI (Step 3):

.interactive {
  overflow: hidden;
}
.interactive img {
  opacity: 1;
}
.interactive figcaption {
  left: 300px;
}  
.interactive:hover img {
  opacity: 0.4;
}
.interactive:hover figcaption {
  left: 75px;
}

To make this smoother, all we need to do is to use CSS transitions on the images and the captions (Step 4). This transitions smoothly between the states without us having to do any calculations. In order to play nicely across browsers, we repeat the instructions with all browser prefixes and fall back to the non-prefixed version.

.smooth img {
  -webkit-transition: all 1s;
  -moz-transition:    all 1s;
  -o-transition:      all 1s;
  -ms-transition:     all 1s;
  transition:         all 1s;
}
.smooth figcaption {
  -webkit-transition: all 1s;
  -moz-transition:    all 1s;
  -ms transition:     all 1s;
  -o-transition:      all 1s;
  transition:         all 1s;
}

Lastly, we do the 3D effect for browsers that support it (Step 5). For this, we give the list item a perspective of 800 pixels. This is like putting a cube into our document where we now can position elements in. In our case, we move the image on rollover 80pixels in the X axis, -20 pixels in the Y axis and -100px in the Z axis. We also rotate it 50 degrees in Y and 10 degrees in X.

.threed {
  -webkit-perspective: 800px;
  -moz-perspective:    800px;
  -ms-perspective:     800px;
  -o-perspective:      800px;
  perspective:            800px;
}
.threed:hover img {
  -webkit-transform: rotateY( 50deg ) rotateX( 10deg )
                        translate3d( 80px, -20px, -100px );
  -moz-transform:    rotateY( 50deg ) rotateX( 10deg )
                        translate3d( 80px, -20px, -100px );
  -o-transform:      rotateY( 50deg ) rotateX( 10deg )
                        translate3d( 80px, -20px, -100px );
  -ms-transform:     rotateY( 50deg ) rotateX( 10deg )
                        translate3d( 80px, -20px, -100px );
  transform:            rotateY( 50deg ) rotateX( 10deg )
                        translate3d( 80px, -20px, -100px );
}

That’s it! Smooth kittens in 3D space without any JavaScript or hard calculations on our end.

I am currently at MozCamp in Berlin and my job was to entice all the contributors to the Mozilla project to get out of their shell and start speaking at events about all the great stuff they do. It seems people liked what I had to say, so here are the slides and the audio recording. I will cover this topic more in the next few months, as I think the way we do information sharing in the web development world right now is not really scalable.

The slides are on Slideshare (this time)

Be a kickass speaker – Mozcamp 2011

The audio recording is available on archive.org

I just got back from Berlin where I spoke at Velocity Europe as a Mozilla representative about browser performance. Instead of smothering and boring the audience with browser internals and numbers that will be outdated within a few nightly releases I took a more holistic approach to performance. Browsers should make everyboby perform better and so far we haven’t quite done that for developers yet. Check out the talk materials here.

Slides and Audio

You can see the slides here (left+right to go back and forward, down for next bullet point and N to toggle notes) or read them as an HTML page:

There is also an audio recording of the talk on archive.org:

And here are the full notes I wrote for myself before “sliding” them up:

Notes

We’re here at a performance conference where we talk a lot about how to make the web perform faster. Yet I was invited here to talk about a browser and why it is cool to use it.

You know what, that doesn’t get us anywhere. As publishers of web-based content and applications it is not our job to make browsers compete against each other on pure technical numbers and criteria. These change every few weeks and actually are not a depiction of the reality out there.

Whatever you hear here today about different browsers will not change the decisions of your end users.

If you want numbers, they are out there. Go to http://arewefastyet.com and go nuts. It shows you all the performance numbers of Firefox in the current test suites and it has pretty graphs to boot.

A browser is much more than a performing piece of software. It is the interface between our end users to the web. It is also the thing we as developers use to test what our end users see and this is where things go severely pear-shaped.

Our end users have browsers that are different to ours. No matter what we do to keep the browser fast and snappy people will find a way to mess this up.

As a Mozilla employee I get a lot of feedback on Twitter about the performance of Firefox. The first thing is always “it is too slow”. Upon investigation as to the why it is slow you do get interesting results though.

Almost all of them are based on developers doing incredibly complex things that are not meant to be. A lot is based on misunderstanding of web technologies as a necessary evil rather than really learning them.

End users on the other hand have a lot of gripes that are based on people customising their browser to the n-th degree or using the browser in a fashion that hints at superhuman powers. My favourite so far was someone who complained that startup of Firefox was annoyingly slow when you have 140 tabs open!

Analysing our user’s behaviours with their consent is a very insightful exercise. We found for example that the average usage time of private browsing mode is 5 minutes. What does that say about performance?

It means that travel web sites are very well optimised! Because we all know that this is what private browsing mode is about: booking that surprise holiday for you and your other significant half.

Seriously though, let’s talk a bit about best practices in development. Starting with Yahoo’s exceptional performance web sites and Google’s page speed and webmaster resources we threw out a lot of great documentation and solutions for developers to make their sites behave better. Do people take it on? Yes, they do. To a degree. If they can trust the information. Allowing the tools we aimed at those people to deteriorate over time doesn’t help there. I see a lot of outdated truisms making their rounds on mailing lists and forums as the original people building YSlow moved on to solve other problems.

Check web sites built with out-of-the-box CMS installs. Some of them have CSS files for every single module that just keep getting added to the document. This was the only way we learned that IE can only load 31 style sheets before giving up. Nobody would ever code this by hand and think it a good idea. That systems out-of-the-box don’t concatenate the files is ridiculous seeing that we’ve been advocating that as a best practice for years now. So I see a disconnect between the people preaching best practices in performance and those building real products.

Take a look at Github. A great web resource and probably the number one resource for open source projects these days. Let’s take a look at their CSS.

Boom! 22212 lines in 3711 selectors. We use that right now to stress test our developer tools.

Talking of which, let’s take a look at one of the main reasons why people say Firefox is slow: Add-ons that don’t perform well and complex add-ons that interfere with the rendering of the browser.

Debugging can be an incredibly disruptive thing. The other day Zynga released a great piece of software for HTML5 app development: a scroller routine that allows you to scroll and zoom a playing field or document. They announced it to be incredibly performant. Joe Hewitt released something similar before that and claimed immediately that Zynga’s code actually performs terrible on an iPad. Investigation showed that the only reason why it performed badly was because of the debugging information being shown in form fields. Turning that off meant great performance.

The learning from this is that when you give access to debugging information you are always likely to skew the results you get. Which is why a lot of performance gripes on Firefox are actually based on Firebug.

When Firebug came out it was a revolution and a refreshing warm summer rain for web developers out there. For the first time in history of web development we had a chance to see what is going on and how to inspect the document after it has been modified by JavaScript. It was also a great opportunity for quick changes and previewing changes without needing to rebuild an app or transfer it to the staging servers.

Firebug became the de-facto developer tool in browsers and all the others copied it. I remember Opera coming to Yahoo and asking the web developers there what they expect from a good debugging tool. We all told them to simply to copy Firebug. So Dragonfly started looking like a clone of Firebug. The Safari developer tools and the Chrome ones did the same. So did the ones in IE.

As with any piece of software that gets a lot of excitement people started adding feature after feature as “developers want that” and nowadays all the developer tools sport lots and lots of features and become quite a confusing piece of UX. This makes the tools fatter and less performant and is counterproductive to the cause.

This is why Firefox now comes with built-in developer tools that are not Firebug. Instead of copying the Firebug way we decided to keep it simpler and let the developer choose what debugging tools they need. The very simplest is the console – something you will always need to debug and find issues in your code. JavaScript error consoles were probably the first thing people wanted.

On top of that we have a CSS style editor. This is a performance hog and will interfere with any testing. But it is pure magic for finding out why a certain style has not been applied. The new thing in the style editor is also that you see the settings the browser applied to the elements that might cause a display issue.

ALl of the features we have for developers in browsers now are debugging tools. What if we take that further and aim for developer tools in the browser?

One of those we have right now is the scratchpad. This is a simple editor in the browser that allows users to write more complex JavaScript to test on the current page and run it against it. Instead of writing a JS and setting breakpoints you can highlight parts of the script and run only those. Once done, you can save the file to your hard drive.

As a developer, this saves me a lot of time trying out new things. I don’t need to use a development server or local machine and insert a JS I need to remove later on and I don’t need to build a project to try out some new functionality. Think of it as Greasemonkey on steroids.

All of these tools are meant to make the developer perform better. End users don’t have to have these and they shouldn’t interfere with their surfing experience. It is very likely that our web sites and applications are constantly changing, which means that by giving developers the right tools to build faster and test more easily we can deliver faster and better.

We do this by separating the development tasks out into specialised tools to help debugging and developing in the browser rather than for it.

As said before, the main entry point to developing and debugging is some kind of command line. Instead of just having a JavaScript console we extended its reach to allow you to control the developer tools themselves with a series of commands. So instead of having to go through the menus or having to memorise a lot of shortcuts you can turn the different tools on and off with a set of commands.

A lot of what we do on the web these days is to replace the web native languages with more specific ones and use build scripts to concatenate and minify files.

This makes us less effective as debuggers. Most developer tools will undo these to display the code in a readable manner but won’t report you the correct location of the erroneous code.

Source Mapping will solve this. For now, our developer tools will for example allow developers to write in Coffeescript and report both the error line in the generated JavaScript and in the source. This could in the future be extended to LESS or SASS or whatever other language we will come up with to fix the inadequacies of the native ones or make it easy to write a certain CSS effect without having to repeat a lot of code with different browser prefixes.

It is also time to give people different ways to realise what they are doing wrong when it comes to making the web fast for the web. Almost every browser allows you to inspect the DOM and find issues with the structure of your document but it might not be obvious just how much your templating skills create in terms of HTML cruft.

One great new feature for that is that the next Firefox versions will show HTML5 parsing errors already in the source view. That way developers can simply find issues. With templating the source we edit is not the one the browser creates.

Tilt is a unique new way to make this more obvious to people. It displays the page as a 3D model and you can easily see where your nesting went overboard even when the HTML is minified.

All in all we aim with Firefox to be a browser that brings the web to the end user and keeps them in control of what they do on the web. This spans much further than browser performance. The performance of the base browser becomes a given, not a goal.

Instead of looking simply at how the browser behaves we are part of some much more interesting ideas how to turn the web into a development and app platform. Mozilla’s open apps for example allow you to distribute apps with any web site by adding a meta tag.

BrowserID allows end users to log into sites without usernames and passwords. For developers, you can have a verification system that uses one HTTP request and works smoothly in the background.

I think it is time we look at performance in a much larger way than just fixing what others do wrong. We need to empower web developers with good tools and systems to do things right and keep them maintainable rather than translating their work to machines for them.

My life lately revolves mostly about going to conferences and presenting. This gives you an interesting insight into how they are run, how other people present and what impact it has on the audiences.

I’ve done this for a while and I think I am pretty good at it. I also see other people who are incredible at it, I see a lot of potential in others and I see a lot of failed presentations.

I also see problems with the way we distribute presentation content on the web afterwards and this is what I want to discuss today.

Powerpoint hell is just not us

Presentations on web technologies (and generally covering our market) are a very strange beast. We are in a “new media” environment where we despise all the things that IT and office life was before we started linking documents with each other over the world wide web or load cool apps onto our smart devices.

A sure-fire way to fail presenting at a web-related conference is to use old school power points with headings and bullets and reading them out to the audience. Therefore we go to other extremes: the “inspiring pictures with a single word”, the “typography heaven with awesome transitions” and the “I have no slides, let’s get to live coding on the CLI or in my editor” are the most common ones.

What we lose by doing so is the context. Our presentation materials become part of the talk and not an information resource. This is good – it means you as a speaker get the attention. But it can be a problem further down the line.

Our “new media presentation style” is very different to what we did before. I use a lot of humour and comparisons with the real world in my talks. Some of my slides seem totally disconnected until I explain their angle. Aral Balkan does similar things. A lot of times he explains the usability of interfaces by showing ticket vending machines at airports. This is great. Real life frustration makes it easy to remember not to do that online.

Slides are backdrops

The gist is: our slides are not the talks, our slides aid the talks we are giving. They are a visual catalyst for the things we talk about. When you see something and you hear about it at the same time it is more likely to stick. It is as simple as that.

The dangers of re-use and distribution without context

Once the talk is over you can bet your life that the first question (unless you covered that already) is “are the slides available for download?”. And this is where it gets interesting.

For the people at the conference it makes a lot of sense to get the slides and check them later on reminding themselves of your talk. Conferences are jam-packed with talks and it is good to have a reminder to re-focus after the party. This is also a very human trait – we are hoarders and want to get our hands on everything we get offered. Free stuff never stays behind – people take it. Wether they need it or not is not the question. Better to get it in case we need it later than not have it.

I’d love to think that people download my slides and read them and all that (which is why I share them) but I am quite sure that this is very rare occasion.

It really breaks when the slides are just that – slides. The aid to support the talk that without the talk lacks a lot of context. If I look at the PDF of a talk a few weeks later and only see pretty images without remembering what they meant at that time I get confused and frustrated.

Even worse, if you distribute slides of that ilk, people will find and watch them when they haven’t seen your talk at all. And this is where it gets dangerous as people can make their own assumptions as to what you tried to achieve.

Attention getting devices can backfire

In our quest to be different to the dreaded talks we had to endure in school and office life we tend to push the boundaries of presenting.

People in web tech swear on stage, make outrageous demands in a ironic manner, and show things that are very much the direct opposite of what you expect. These are attention getting devices that – paired with a good speaker – can be very effective and also very entertaining. They can also cause controversy and misunderstanding.

The other day I had quite a back and forth with a presenter on Twitter about a slide deck he published. I’ve seen the speaker talk and respect him for what he does. I am very much sure that in the context of his talk the slide deck brought the point home and made a lot of sense.

But, as it is right now on the web without notes or any other information, a NSFW picture of an almost naked tattooed lady with taped nipples and massive breasts as your first slide is likely to cause more trouble than it is worth.

He had his reasons for using it, no doubt about that, but with the distribution being disconnected from the rest of the talk, what are the effects of this?

Why shock when you can convince or show?

There is a lot of talk about gender diversity at conferences and in IT. I am not going to poke this hornet’s nest, but I am sure that a slide like this one is a great way to keep an endless discussion with continuously mounting emotions going for months instead of concentrating on solving the issue.

Shock slides and campaigns can work. They also have been done in the past and are to me a cheap way of getting attention. Web sites like rotten.com and ogrish were a very successful thing in the past and Benetton in the 80ies had massive success with their controversial campaigns in magazines. Heck, every boulevard paper has some nudity on their covers to sell issues. Page 3 girls appeal to the audience they try to reach.

So, in essence, this is an old hat. It only works when all you want is attention and your product doesn’t have much to do with the shock content. Benetton sells clothes, something very personal that people buy and own for themselves. They wanted to get their name talked about and expected people to find out about their products on their own. We can not assume people to do the same about our slides, design ideas or code tricks as they are not as excited about our them as we are.

The question we should ask ourselves is what we achieve with this. You get attention quick and you probably get talked about a lot. What people talk about though is that there was “some guy on some conference showing a naked lady (run over puppy, open wound, vomiting child, whatever…)” and not what you wanted to bring across in your presentation.

Using shock slides is the equivalent of kicking someone in the shins and then asking for the way to the station. Yes, you have their undivided attention, but you are not likely to get out of them what you wanted.

By all means, if you want to keep using them – do so. But be aware that when you fail to provide context you will not get your message across. If you use nudity or sexist material you will also contribute to an already existing problem.

If you publish things you are as responsible for their content than when you are on stage presenting them.

Saying that “nobody complained” is not an excuse for offensive material. Not all people who are offended say so and confront you. Actually most are intimidated and will not say anything but tell others how they felt and what your behaviour did to them instead. This is how discrimination and bullying works – you shock and intimidate by coming from a position of power. And you being on stage is a position of power that can be used to inspire others or for personal satisfaction.

So, to me at least, we should stop using any shocking materials in our slides as an attention getter. We are better than that. Our messages should be the “a-hah!” moment, not the packaging they come in.

The best of all worlds

As to the overall distribution of our talks, I think it is time to reconsider our ways.

If our slides are only a backdrop to our talk and we don’t even have notes or a transcript, let’s not give them out. Let’s wait for the video to come out and distribute them together with the video – even if it means that people have to wait. In essence this is a good test to see if people really care about them or if they just want them right on the spot for hoarding purposes.

If you want to release them immediately, try to give them more context. Have notes on your PDF or presentation document. I tend to record the audio of my talk while I give it and publish it along the slides. I always want to sync the slides with the audio but it is a lot of work so most of the time I forget about it so I am not sure just how effective this is. If you use keynote you could do that automatically as it records a movie of your slides if you ask it to. In any case, I can point out what was said and debunk accusations that way.

I also started to go the other way around. I wrote my Fronteers 2011 talk as an article, then split it up into paragraphs and created a slide for each. That way I could publish it as a blog post that makes sense and with accompanying slides.

The new HTML slide format I use based on DZSlides allows me to have the talk as a searchable, printable page with support for old browsers and as a slide format at the same time. I am cleaning this up and adding some new features to release soon.

Let’s be professionals

In essence, it boils down to one thing: if you want to be inspiring and an educator, don’t leave things online that lack context or cause controversy. It confuses people, causes misinterpretation and helps neither you nor the people you try to reach. This is about the people you talk to – not about you.

Comments? Questions?

Discuss this on Facebook or Google Plus

Last week I was in Krakow, Poland to attend the Frontrow conference delivered a presentation on attitude towards new technology and inspiration in the tech community.

Frontrow was interesting as it was a mixture of Barcamp and conference. On each day you had a few talks, followed by lunch and 2 hours of “open sessions” with breakout rooms where people were asked to discuss hot topics and share their experiences. Think of it as longer Q&A after the presentations with a moderator.

As you can see in the conference schedule there was a lot to be learned and a lot of great speakers (local and a lot of UK folk) shared their info and ideas with the audience.

My presentation revolved around the issue of getting inspired at conferences and then frustrated when you can’t use what you learned in your job. A lot of that frustration is home made and what really is needed is having the stamina and drive to simply use and explain what you found out about to your company. Without people using what speakers talk about conferences become a stage play, and a bad one at that.

You can read the slides as a simple document available online or embedded below (cursor keys to navigate, press N to show and hide notes and cursor down to proceed on slides with bullet points):