The Mozilla User Experience Research team is looking for developer who have experience writing mobile Web apps in the Bay Area to participate in a paid research study that will have a significant impact on making our developer-focused efforts even better.

To qualify for the study, please take this 10-minute survey.
If you’re eligible, a member of our team will contact you to tell you a little more about the research and schedule time with you. Developers who qualify for and fully participate will receive an honorarium of $250.

We’re looking for developers who are:

• willing to participate in a 2-hour in-person interview at their workplace or home
• available for the interview the week of March 10 to 14 (the weekend before / after may also be possible)

The interview will be recorded, but all materials will be used for internal research purposes only.

You DON’T have to use Mozilla products or be part of our community to participate (in fact, we’d like to hear your voice even more!).

Your feedback has the potential to improve the experience of other Web app developers and influence the direction of our products and services, so we would love to get a chance to talk with you! Please feel free to share this opportunity widely with your own network as well.

Beginning of last week I spent three days in Oslo, Norway, with Jan Jongboom (@janjongboom) and Sergi Mansilla (@sergimansilla) of Telenor Digital recording screencasts for an upcoming series on Firefox OS aimed at developers in Asia. These will be dubbed and localised, which is not only super exciting, but also very powerful.

Here’s a quick recap how we managed to create ten different screencasts and six intro/outro videos in two and a half days. It was taxing, it was tiring, but it was also amazing. Many factors played a role, but probably the most important one was a Scandinavian “hands-off” attitude by the video production crew and PR and trusting in the abilities of people involved.

Preparation

Before meeting to record, we shared a Google Doc and created an outline of all the different things we want to cover in the screencast series with scripts for each section. These didn’t have to be detailed scripts as we all knew what we are doing. Just “show app xyz in the emulator, connect phone, push to it” – this sort of thing.

Heads up: I’ve recorded other screencasts that had very defined scripts like “go to the input box, enter ‘fiddlesticks’ and press the button labeled ‘submit’, explain the viewer that this sends the form to the server”. These can work and are important if the person recording is not familiar with the matter or the script needs review by 8 managers and 5 random people from the legal department. We were lucky to have a much more freedom as these screencasts were meant by developers for developers.

We agreed what to show and wrote the code, sharing it on GitHub.

This is immensely important: the code needs to work and be done. You can of course fake to write it live in the screencast using the AppleScript by William Bamberg and me or Stuart Langridge’s Sublime Text plugin. You will not have any time to re-code much (I did clean a few things up) and you will lose time with technical issues as it is (we lost an hour to an appcache problem and another with some problems with the Marketplace submission process). This is not the time to be a coder ninja – this is the time to be an educator, so make sure your stuff works, is documented and understandable before hitting the record button.

Technical set-up

All in all our setup was simple:

1. A dedicated room that is sound-proof-ish with a large table. Adding a thick black tablecloth to it prevented both unintended “knock” sounds on the recording and made for a good background for recording the mobile device
2. A good USB microphone that can be easily handed over from presenter to presenter (we used a Yeti).
3. Three computers, one being the dedicated recording machine, the others for writing and editing. The main machine was a Retina MBP, as you can never have too high a resolution of your original material (downsampling is easy, blowing up video makes it blurry). It is also important to have one machine to record on as this means all the editor settings and the look of the Desktop is the same in all videos. It also means that only one of us had to clean up their machine and start a whole new, clean profile without embarassing autocompletes and history entries (we chose Sergi’s – he is by far the most grown-up and organised amongst us).
4. An external HD (500GB, USB3) to store all the videos and transfer large files from one computer to another
5. Screenflow to record and edit the screencasts
6. A small HD video camera with a Gorilla Tripod to record on-device actions that needs to show hands

Recording and editing

Once all was set up, we divvied up the different screencasts amongst us and got started recording them. We spent the first two days only recording screencasts and left the “talking heads” video shoots for the last day. That way we could work without having to have the film crew around which is a good thing as they tend to be paid by the hour.

People have different ways of working and it is important to allow them to apply their strengths if you want to create a lot in a short amount of time. Us three, for example, learned that I am most comfortable when I speak and show what happens in the screencast at the same time (a running commentary of my own actions). I am not happy reading from a script, as I did that as a job for far too long before escaping to the web (I worked as a radio newscaster).

Both Jan and Sergi struggled with showing and explaining at the same time and thus got much more effective when recording the screencast without audio, then writing a script and re-recording a video of the screencast and narrating the script over it.

The great thing about Jan and Sergi’s MO is that it allows for asynchronous creation of content: when recording and doing the live coding any distraction in the room is tricky to work with and you need to use the one machine to record. When de-coupling the recording of the audio, the editing of the screencasts and the writing of the scripts you can silently sit in the room and edit or write while the others are recording. The thick table-cloth and the quality of the microphone made sure you couldn’t hear any typing in the background. Swearing, yes, but that could and was cut.

The way we recorded worked the following way:

1. We recorded the screencast according to the script, one person recording and another making sure there are no issues with the recording (for example “learn Indian” as a To-Do List item in an app could be offensive, as there is no “one” Indian language). Make sure to leave some breaks in the screencast to allow for more detailed narration.
2. The person who recorded then can go and look at the screencast on another computer and write the script of it.
3. Meanwhile the other two can record the next section
4. Each script then got another peer review to edit for flow (active vs. passive language, adding the “what is in it for me” messaging, shortening of sentences and many other tricks – if you are interested I can do an own post about that)
5. Once the script is done, the presenter goes back to the main computer and records a screencast speaking over the old recording, taking breaks to cough and assemble thoughts as needed without endangering the quality of the recording – all you need to do is to stop the video part of it. You even don’t need to worry about the size of the video and you can resize Screenflow and have a text editor with your script side-by-side.

It is important to keep the recording going. Stopping every time you mess up and starting from scratch only increases the frustration. The same rules apply that apply on stage: you can mess up – just admit it, take a very short break and move on. You can always edit, and it is easier to cut out a single “shit!” than to have to make a very annoyed sounding start of a screencast palpable for viewers.

Editing

The final production of the videos will be done by the professional editing team, but, as they are paid by the hour and because of the way we already used Screenflow to record and separated audio and video we could do a lot of the editing ourselves, cutting the “uhms” and “errs” and heavy breathing and adding still images over longer parts of narration. Screenflow makes this super easy by hitting “t” at the place you want to split the audio or video streams and moving the chunks around.

Next steps

Currently the videos are in production and will be dubbed and we’re putting together the landing page on the Wiki where they will reside. We also clean up our outline and script to be the descriptions of the videos. Thus, nothing was wasted.

Before you go on a righteous rant about professional screencasting…

We are very much aware that professional screencasting and recording looks different and by no means we want to say that it should always be that easy. Professional learning materials need much more planning and more meticulous execution and you should pay people who do that well what they deserve – a lot.
However, for three geeks and a microphone, we’ve done quite well and this might inspire others to do the same.

Ahh, ads. The turd in the punchbowl of the internet party. Slow, annoying things full of dark interaction patterns and security issues. Good thing they are only for the gullible and not really our issue as we are clever; we use browsers that blocked popups for years and we use an ad blocker!

Hang on a second. Whether we like it or not, ads are what makes the current internet work. They are what ensures the “free” we crave and benefit from, and if you dig deep enough you will find that nobody working in web development or design is not in one way or another paid by income stemming from ad sales on the web. Thus, us pretending that ads are for other people is sheer arrogance. I’ve had discussions about this a few times and so far the pinnacle to me still was an answer I got on Twitter to posting an article that 40 percent of mobile ad clicks are fraud or accidents:

I believe people who intentionally click ads are morons

Don’t get me wrong: ads as a whole are terrible. In many cases they have the grace of a drunk guy kicking you in the shin before asking you to buy him a beer. They are very much to blame for our users being conditioned to things behaving in weird ways on the web, thus opening the door for the bad guys to phish and clickjack them. Ads may also be the thing that drives many of our users to preferring apps instead. Which is kind of ironic as an app in many cases is a mixture of a bit of highly catered functionality wrapped in an interactive ad.

We’re blocking our own future

So what does that make us? Not the intelligent people who know how to game the system, but people not owning the platform we work for and are reliant on. As people in the know, it should be our job to ensure ads we publish or include in our project are not counterproductive to the optimisation efforts we put into our work. We also should have a stake in the kind of ads that are being displayed, making sure they don’t soil the messages we try to convey with our content.

A lack of empathy and a lie to ourselves

This is uncomfortable, it is extra work and it feels like we are depriving ourselves of an expert shortcut. The problem with blocking ads ourselves is though that we are not experiencing what our end users experience. We get the first class treatment of the web with comfortable computers and less interruptions whilst our users are stuck in a low cost carrier where they get asked every few seconds if they don’t want to buy something and pay extra if they forgot to bring the printout of their ticket.

By blocking all the ads and advocating for “clever web users” to do the same we perpetuate a model of only the most aggressive and horrible ads to get through. We treat each ad the same, the “find sexy singles in your IP range” and the actual useful ones: we just block them all. Yes, I’ve had some deals by clicking an ad. Yes, I found things I really use and am happy to have now by clicking an ad. I could have never done that with an ad blocker. What it does though is cut into the views of ads and thus force ad companies to play dirty to get the figures they are used to and use to negotiate payments to the people who display their ads. In essence, we are creating the terrible ads we hate as we don’t allow the good ones to even show up. It’s like stopping people swearing by not allowing anyone to speak. Or trying to block adult content by filtering for the word “sex”.

The current ad model is too comfortable and can be gamed

You could say that people who expect everything to be free don’t deserve better. This would hold water if the paid experiences of the web without ads were better or even available. In many cases, they are not. You can not pay for Facebook to get rid of ads. Many providers are so comfortable in the horrible model of “plaster everything with ads and create as much traffic as possible” that trying a subscription model instead bears too much danger and extra effort in comparison.

A sign of this is the horrible viral bullshit world we live in right now. Creators of original content are not the ones who make the most money with it; instead it is the ones who put it in “this kid did one weird trick, the result will amaze you” headlined posts with lots of ads and social media sharing buttons. This is killing the web. We allowed the most important invention for publishing since the printing press brought literacy to the masses to become a glossy lifestyle magazine that spies on its readers.

It should be up to us to show better ways, to create more engaging interfaces, to play with the technology and break conventions. It is sad to see that all we have to show for about 16 years of web innovation is that we keep some parts of our designs blank where other people can paste in ads using code we don’t even know or trust or care to understand. This isn’t innovative; this is lazy.

There’s more to come here and some great stuff brewing in Mozilla Labs. It is time to be grown-up about this: ads happen, let’s make them worth-while for everyone involved.

Outside the Mozilla office in San Francisco stands a beautiful monument thanking all the people who did work with Mozilla to keep the web open, secure, inviting and beautiful.

Overall, this is 4536 names on four sides with two panels, which means your name might be hard to find. Fret not, for Chris More released a dataset with the names and their locations on the document. Using this dataset and some CSS 3D transformations, I am now happy to give you the Mozilla Monument Name Finder.

You can see how it works in this screencast.

• Try the Monument Name Finder
• Get the source on GitHub
• The light-weight, Firefox OS friendly mobile version – also works offline.

If you want to see the real images, here is another hack using the original images!

Again, a huge thanks to all the people who helped Mozilla become what it is! Here’s to you!

Imagine, if you will, sitting down to your morning coffee, turning on your home computer to read today’s newspaper.

This amazing news item from 1981 talks about an experiment of the San Francisco Examiner and other newspapers trying to offer their content in a digital format using a mainframe computer and a telephone connection:

Wired covered this gem in detail and had some interesting details around it.

What excites me most is the purity of the idea back then as mentioned in the interview:

This is an experiment, we’re trying to figure out what it is going to mean for us as editors and reporters and what it means to the home user. And we’re not in it to make money, we’re probably not going to lose a lot, but we aren’t gonna make much either.

The newspaper men tried to reach the two to three-thousand home computers owners back then printing full-page ads and got over 500 subscribers who “sent in coupons”.

The next big thing to me in here is the reaction of the subscriber – a man who waited two hours for the transfer of the newspaper text content at $5/hour call rate. He very much understood the implication that this means you can keep a copy of the paper for yourself and that you can only keep what you need without having to get it all and discard parts of it.

Isn’t it a shame that this amazing gift of publication and distribution and archiving by users of our services is now going back to closed ideas like paywalls and apps?