The 2nd video of the series (streamed live on August 19th) involves exploring options for what a potential living logo could look like. Based on these initial rough sketches, I’m very excited to say we’ll be working in partnership with Pitch Interactive to come up with data-driven visualizations as the main build of our logo system. More on that soon!
In addition, today on the Firefox Channel we released a small overview video of what we plan to achieve and how we’re going about making the project open. Enjoy!
The add-on review process on AMO is fairly complicated, and can get very overwhelming if you need to look at it close enough that you must understand file and add-on statuses. AMO admins, devs, and reviewers are usually the ones who have to worry about this stuff and there aren’t good docs for it.
Since the issue popped up again today, I decided to take a few minutes to create a chart that explains the AMO review cycle from a file and add-on status perspective. If you think this chart is pretty crazy, you should keep in mind it’s a simplified view of the process. It doesn’t take into account developers deleting versions of marking their add-ons as inactive, and a few repetitive connections were left out. Still, it should give a good idea of how add-on and file statuses interact during the review process, and should help admins figure out which status means what (to add more confusion to the mix, AMO has old unused statuses, as well as others that are only used in Marketplace).
Here’s the chart without the notes:
For the real deal, check out the doc.
Is this complexity necessary? Probably. We have two review levels because it allows us to list polished add-ons as well as experimental ones, giving developers and users more flexibility and choice. This in turn makes AMO more diverse and generally a better option than self-hosting.
We’ve made the decision today to postpone the Maker Party planned for Saturday 13th September at Campus North, Newcastle-upon-Tyne.
Although there were lots of people interested in the event, the timing proved problematic for potential mentors and attendees alike. We’re going to huddle next week and think about a more suitable time – perhaps in November.
Thanks to those who got in touch about the event and offered their support.
One of the hidden features of Firefox 29 was a unicorn that bounced around the Firefox menu when it was emptied. The LA Times covered it in their list of five great features of Firefox 29.
Building on the fun, Firefox 32 (released today) will now spin the unicorn when you press the mouse down in the area that unicorn is bouncing.
The unicorn is shown when the menu’s :empty pseudo-class is true. The direction and speed of the movement is controlled via a CSS animation that moves the unicorn in the X- and Y-direction, with both moving at different speeds. On :hover, the image of the unicorn gets swapped from grayscale to colorful. Finally, :active triggers the spinning.
Tagged: australis, CSS, firefox, planet-mozilla
At around 06:49 CEST on the morning of August 27 2014, Google deployed an HTTP/2 draft-14 implementation on their front-end servers that handle logins to Google accounts (and possibly others). Those at least take care of all the various login stuff you do with Google, G+, gmail, etc.
The little problem with that was just that their implementation of HTTP2 is in disagreement with all existing client implementations of that same protocol at that draft level. Someone immediately noticed this problem and filed a bug against Firefox.
The Firefox Nightly and beta versions have HTTP2 enabled by default and so users quickly started to notice this and a range of duplicate bug reports have been filed. And keeps being filed as more users run into this problem. As far as I know, Chrome does not have this enabled by default so much fewer Chrome users get this ugly surprise.
The Google implementation has a broken cookie handling (remnants from the draft-13 it looks like by how they do it). As I write this, we’re on the 7th day with this brokenness. We advice bleeding-edge users of Firefox to switch off HTTP/2 support in the mean time until Google wakes up and acts.
You can actually switch http2 support back on once you’ve logged in and it then continues to work fine. Below you can see what a lovely (wildly misleading) error message you get if you try http2 against Google right now with Firefox:
This post is being debated on hacker news.
the following changes have been pushed to bugzilla.mozilla.org:
-  changes made at the same time as a comment are no longer grouped with the comment
-  Only retrieve database fetched values if requested
-  add bit.ly support to bmo
-  Remove reporting of the firefox release channel from the guided bug entry (hasn’t been accurate since firefox 25)
discuss these changes on mozilla.tools.bmo.
Filed under: bmo, mozilla
After all the fun reading “Meanwhile in San Francisco”, I looked to see if this duo had co-written any other books. Sure enough, they had.
“Lost Cat” tells the true story of how an urban cat owner (one of the authors) loses her cat, then has the cat casually walk back in the door weeks later healthy and well. The book details various experiments the authors did using GPS trackers, and tiny “CatCam” cameras to figure out where her cat actually went. Overlaying that data onto google maps surprised them both – they never knew their cats roamed so far and wide across the city. The detective work they did to track down and then meeting with “Cat StealerA” and “Cat Stealer B” made for a fun read… Just like “Meanwhile in San Francisco”, the illustrations are all paintings. Literally. My all-time favorite painting of any cat ever is on page7.
A fun read… and a great gift to any urban cat owners you know.
We’ve removed the rsync modules mozilla-current and mozilla-releases today, after calling for comment a few months ago and hearing no objections. Those modules were previously used to deliver Firefox and other Mozilla products to end users via a network of volunteer mirrors but we now use content delivery networks (CDN). If there’s a use case we haven’t considered then please get in touch in the comments or on the bug.
What if, when giving a patch r+ on Mozilla’s bugzilla, you were presented with the following checklist:
- I have considered:
- Memory leaks
- Null checks
- Security implications
- Mozilla Code Style
You could not actually submit an r+ unless you had checked an HTML check box next to each item. For patches where any of this is irrelevant, just check the box(es) – you considered it.
Checklists like this are commonly used in industries that value safety, quality, and consistency (e.g. medicine, construction, aviation). I don’t see them as often as I’d expect in software development, despite our commitments to these values.
The idea here is to get people to think about the most common and/or serious classes of errors that can be introduced with nearly all patches. Reviewers tend to focus on whatever issue a patch addresses and pay less attention to the other myriad issues any patch might introduce. Example: a patch adds a null check, the reviewer focuses on pointer validity, and misses a leak being introduced.
Catching mistakes in code review is much, much more efficient than dealing with them after they make it into our code base. Once they’re in, fixing them requires a report, a regression range, debugging, a patch, another patch review, and another opportunity for further regressions. If a checklist like this spurred people to do some extra thinking and eliminated even one in twenty (5%) of preventable regressions in code review, we’d become a significantly more efficient organization.
For this to work, the checklist must be kept short. In fact, there is an art to creating effective checklists, involving more than just brevity, but I won’t get into anything else here. My list here has only four items. Are there items you would add or remove?
General thoughts on this or variations as a way to reduce regressions?
More than 20 years ago I first experienced virtual reality in one of those large-scale 3D rigs which was traveling the country, setting up shop in the local multiplex cinema and charging you a small fortune to step into a 4-by-4 foot contraption, strap on a pair of 3D goggles, grab a plastic gun and hunt down some aliens in an immersive 3D environment.
It’s funny - as unimpressive as the graphics were, as much as the delay between movement and visual update was puke inducing – I still have vivid memories of the game and the incredible experience of literally stepping into a new world.
Fast forward to last year: Oculus revived the whole Virtual Reality (VR) scene with their Rift headset – cobbled together with cheap off-the-shelf components and some clever hardware and software hacking. The first time I tried the Rift I was hooked. It was the exact same crazy experience I had some 20 years ago – I found myself in a new world, just this time with much better graphics, none of the nasty visual delays (which makes most people motion sick) and all delivered in a much more palatable device. And again, I can’t get that initial experience out of my head (in my case a rather boring walking experience of a Tuscan villa).
Since that experience, I joined Singularity University where we have a Rift in our Innovation Lab. Over the course of the last 8 weeks I must have demoed the Rift to at least 30 people – and they all react in the exact same way:
People giggle, laugh, scream, start moving with the motion they see in the headset… They are lost within the experience in less than 30 seconds of putting the goggles on. The last time I’ve seen people react emotionally in a similar way to a new piece of technology was when Apple introduced the iPhone.
It’s rare to see a piece of technology create such a strong emotional reaction (delight!). And that’s precisely the reason why I believe VR will be huge. A game changer. The entry vector will be gaming – with serious applications following suit (think about use cases in the construction industry, engineering, visualization of complex information) and immersive storytelling being probably the biggest game changer. In the future you will not watch a movie or the news – you will be right in it. You will shop in these environments. You will not Skype but literally be with the other person.
And by being instead of just watching we will be able to tap much deeper into human empathy than ever before. To get a glimpse of this future, check out these panoramic pictures of the destruction in Gaza.
With prices for VR technology rapidly approaching zero (the developer version of Oculus Rift’s DK2 headset is a mere $350 and Google already introduced a cardboard (!) kit which turns your Android phone into a VR headset) and software development tools becoming much more accessible, we are rapidly approaching the point where the tools of production become so accessible that we will see an incredible variety of content being produced. And as VR is not bound to a specific hardware platform, I believe we will see a market more akin to the Internet than the closed ecosystems of traditional game consoles or mobile phone app stores.
The future of virtual reality is nigh. And it’s looking damn real.
Kingdom Code is a new initiative to gather together Christians who program, to direct their efforts towards hastening the eventual total triumph of God’s kingdom on earth. There’s a preparatory meet-up on Monday 15th September (tickets) and then a full get-together on Monday 13th October. Check out the website and sign up if you are interested.
(There’s also Code for the Kingdom in various cities in the US and India, if you live nearer those places than here.)
This post is an attempt to capture some of the things we’ve learned from a few busy and exciting weeks working on the Webmaker new user funnel.
I will forget some things, there will be other stories to tell, and this will be biased towards my recurring message of “yay metrics”.How did this happen?
As Dave pointed out in a recent email to Webmaker Dev list, “That’s a comma, not a decimal.”
What happened to increase new user sign-ups by 1,024% compared the previous month?Is there one weird trick to…?
Sorry, I know you’d like an easy answer…
This growth is the result of a month of focused work and many many incremental improvements to the first-run experience for visitors arriving on webmaker.org from the promotion we’ve seen on the Firefox snippet. I’ll try to recount some of it here.
While the answer here isn’t easy, the good news is it’s repeatable.Props
While I get the fun job of talking about data and optimization (at least it’s fun when it’s good news), the work behind these numbers was a cross-team effort.
I think this model worked really well.Where are these new Webmaker users coming from?
We can attribute ~60k of those new users directly to:
- Traffic coming from the snippet
- Who converted into users via our new Webmaker Landing pages
I’ve tried to go back over our meeting notes for the month and capture the variations on the funnel as we’ve iterated through them. This was tricky as things changed so fast.
This image below gives you an idea, but also hides many more detailed experiments within each of these pages.
With 8 snippets tested so far, 5 funnel variations and at least 5 content variables within each funnel we’ve iterated through over 200 variations of this new user flow in a month.
We’ve been able to do this and get results quickly because of the volume of traffic coming from the snippet, which is fantastic. And in some cases this volume of traffic meant we were learning new things quicker than we were able to ship our next iteration.What’s the impact?
If we’d run with our first snippet design, and our first call to action we would have had about 1,000 new webmaker users from the snippet, instead of 60,000 (the remainder are from other channels and activities). Total new user accounts is up by ~1,000% but new users from the snippet specifically increased by around 6 times that.One not-very-weird trick to growth hacking:
I said there wasn’t one weird trick, but I think the success of this work boils down to one piece of advice:
- Prioritize time and permission for testing, with a clear shared objective, and get just enough people together who can make the work happen.
It’s not weird, and it sounds obvious, but it’s a story that gets overlooked often because it doesn’t have the simple causation based hooked we humans look for in our answers.
It’s much more appealing when someone tells you something like “Orange buttons increase conversion rate”. We love the stories of simple tweaks that have remarkable impact, but really it’s always about process.More Growth hacking tips:
- Learn to kill your darlings, and stay happy while doing it
- We worked overtime to ship things that got replaced within a week
- It can be hard to see that happen to your work when you’re invested in the product
- My personal approach is to invest my emotion in the impact of the thing being made rather than the thing itself
- But I had to lose a lot of A/B tests to realize that
- Your current page is your control
- Test ideas you think will beat it
- If you beat it, that new page is your new control
- Rinse and repeat
- Optimize with small changes (content polishing)
- Challenge with big changes (disruptive ideas)
- Focus on areas with the most scope for impact
- Use data to choose where to use data to make choices
- Don’t stretch yourself too thin
- We have some further snippet coverage for the next couple of weeks, but not at the same level we’ve had recently, so we’ll see this growth rate drop off
- We can start testing the funnel we’ve built for other sources of traffic to see how it performs
- We have infrastructure for spinning up and testing landing pages for many future asks
- This work is never done, but with any optimization you see declining returns on investment
- We need to keep reassessing the most effective place to spend our time
- We have a solid account sign-up flow now, but there’s a whole user journey to think about after that
- We need to gather up and share the results of the tests we ran within this process
Testing doesn’t have to be scary, but sometimes you want it to be.
From the Google Online Security blog:
Starting next week, we’ll be expanding Safe Browsing protection against additional kinds of deceptive software: programs disguised as a helpful download that actually make unexpected changes to your computer—for instance, switching your homepage or other browser settings to ones you don’t want.
I posted a comment asking:
How is it determined, and who determines, what software falls into this category and is therefore blocked?
However, this question has not been approved for publication, let alone answered :-( At Mozilla, we recognise exactly the behaviour this initiative is trying to stop, but without written criteria, transparency and accountability, this could easily devolve into “Chrome now blocks software Google doesn’t like.” Which would be concerning.
Firefox uses the Google Safe Browsing service but enhancements to it are not necessarily automatically reflected in the APIs we use, so I’m not certain whether or not Firefox would also be blocking software Google doesn’t like, and if it did, whether we would get some input into the list.
Someone else asked:
So this will block flash player downloads from https://get.adobe.com/de/flashplayer/ because it unexpectedly changed my default browser to Google Chrome?!
Kudos to Google for at least publishing that comment, but it also hasn’t been answered. Perhaps this change might signal a move by Google away from deals which sideload Chrome? That would be most welcome.