Better know a WebDev: Jennifer Fong

Andy McKay

Featuring Jennifer Fong, also known as ednapiranha.

2013-05-23-09.45

What do you do at Mozilla?

I am on the Developer Ecosystem team and work on the Developer Hub, build reference apps and help developers build apps for the Firefox Marketplace.

Any fun side projects you’re working on?

Yes – let’s see:

  1. Recently created meatspace, a node module that supports decentralized microblogging functionality and subscriptions. Think of it like RSS as JSON feeds packaged with CRUD on posts.
  2. As a result, I made generaltoast, which is a Node/Express app that uses meatspace and Persona to exemplify a web interface for meatspace. You can check out my current microblog – left side are my posts, right side are my subscriptions to other posts.
  3. For a reference app in the Firefox Marketplace, I made generalnotes which is a note-taking app that syncs to the server when the user is online and logged in. Check out the accompanying blog post.
  4. As an attempt to create an interactive fiction game engine, I created generalstore, which allows a user to create a game with text files, images, audio files and CSS.
  5. I am also organizing the remote-friendly NoodleConf, which is an atypical one day conference where speakers talk about whatever they want. Likely relating to technology. Or possibly what they ate for breakfast.

How did you get started in web development or programming?

High school – Watcom Basic and Turing if we really want to be technical about it. Web development was during my later years. Something something PHP something – Aphex Twin may or may not have been playing in the background.

How did you get involved with Mozilla?

I was riding this unicorn across the great Canadian forests and a rainbow appeared in the sky. I followed to the end of the rainbow and saw a job application to join Mozilla. The unicorn touched the application with its horn. The rest is history.

What’s a funny fail or mistake story you can share?

On my first week at Mozilla, I accidentally did a git push -f to master for http://mozillians.org. I felt so bad, but I got over it pretty quickly.

What’s something you’re particularly proud of?

Having some really weird friends. And ideas.

What’s coming up that you’re excited about?

NoodleConf 2013!

Favourite Rob Ford moment?

Firefox Marketplace: May 3rd – May 16th

Andy McKay

1

This is a regular post focusing on the status of the Firefox Marketplace.

  • Total bugs open: 552
  • Total bugs opened: 298
  • Total bugs closed: 218

Some specific changes of note:

  • APIs added for payment status and users permissions (868030 and 868252)
  • API to allow the setup of payments for apps (869572)
  • Allow a submission flow that checks app permissions (858306)
  • Enable the German and Polish translations (868888 and 868594)
  • Signing in after logging out fixed (869664)
  • Submitting reviews multiple times fixed (871871)
  • Webfighter demo gained payments (858289)
  • Forced issuers for payments re-enabled (867729)
  • Senior Themes reviewer group created (868053)
  • Move from pyes to pyelasticsearch (857156)
  • Scroll positions preserved between tabs in the marketplace (868249)
  • Stop Marketplace reverting to US after a phone reboot (865132)

The new Marketplace consumer user interface was pushed. The Marketplace is now a packaged app that uses the REST API to populate the app. This was a huge change and makes the site faster and more awesome. To checkout the packaged app see the Fireplace app on github.

The Marketplace was also moved out of Aurora status.

A few UX changes. A single page. Millions of new downloads.

Holly Habstritt Gaal

1

We recently designed, tested, and released a new version of our our primary download page for Firefox for Desktop. In our tests, we improved the download conversion rate of the top 3 non-Firefox browsers by over 12%! This alone results in millions of additional downloads annually.

Focusing on the entire funnel leading up to a product download and not just the product itself, is as important as the efforts taken to improve retention of a product. This is one of the approaches that the Websites team at Mozilla is taking to improve and support our products.

 

What is the /new page on Mozilla.org?

This is where the majority of our desktop browser downloads are initiated. For instance, if the user searches for “Firefox”, “Mozilla Firefox”, or “download Firefox” from a desktop browser, the /new URL is the top search result.

 

What did we change?

Though a relatively simple page, we were able to make number of changes across visual design, interaction, technical improvements and overall user experience that had substantial results. How did we do this?

  1. reduced the number of steps to download
  2. simplified number of actions displayed on page and reduced distractions to funnel user directly to download (ie: no link to Fx for Android or other products displayed)
  3. focus on our product – the last page design did not display visuals that focused on the product, but focused more on Mozilla community.
  4. significantly faster page load time
  5. updated style to our responsive Mozilla style guide
  6. inline page interaction that responds immediately to the user’s request for download, resulting in no page refresh for confirmation and installation instructions.

Old Experience – includes page refresh:

New Experience – inline interaction, no page refresh:

* To experience the inline page interaction yourself, visit the Firefox for Desktop download page.

 

Design Decisions & Testing

We could infer that the outcome of changes such as updating this page to a consistent style as our other Mozilla.org pages and improving page load time alone would have a positive result. However, some of the other changes were more subjective and required testing and validation before releasing to 100% of our users.

Based on common interaction patterns, what we know about how users respond to pages that “feel” responsive to their actions, as well as minimizing distraction, we were able to make many initial design decisions.  To validate the more subjective changes, such as button placement, button style, and animations, we ran A/B tests using Google Analytics Content Experiments.

​An important part of testing is not just validating our work, but exposing interesting facts about our users and issues that may need further attention. For instance, we learned that large percentage of users downloading Firefox already have Firefox for Desktop. This could mean that the user is not aware that we run silent updates, that they are not aware that their version of Firefox is already up to date, that they wanted a fresh copy of the browser, or a number of other possibilities. This is just one of the interesting things we learned that we are looking into for further improvements.

Given the success of these tests, we were very confident in releasing the new experience to all of our users. Our initial improvements to the /new page and download funnel are just the beginning. We will also continue to test improvement possibilities, such as the style of the download button, to learn more about our users and improve the performance of the download funnel.

 

A few stats:

Across the top 3 browsers, we saw a 14% download conversion improvement.

Across all browsers and operating systems, we saw an average of a 4% improvement.​

​Considerable improvements to page load time:

  • ​Time to be able to interact: 46% decrease
  • Time to load page content: 71% decrease
  • Time to execute JavaScript: 35% decrease

Next Steps:

Testing download button styles and placement, translate page for non-english languages, add logic and conditional messaging for all platforms to move towards a unified Firefox download page, improve other touch points within the onboarding funnel by using a similar process of testing and validating with real users.

 

Categories: UX

Avoiding Dependencies

Andy McKay

1

Guest post on behalf of Matt Basta.

Avoid code duplication and reusing code is always an admirable goal. However, in some occasions, it’s not a bad idea to duplicate a little bit of code in order to make your software better.

An Example

When writing a Node app, accessing a directory listing is fairly simple: the fs.readdir command provides a list of objects in a directory, and a call to fs.stat will tell you whether each object is a directory or a file.

That’s fairly straightforward, but recursing (especially when using callbacks) can require some mental yoga. Each directory needs to keep track of how many subdirectories it expects to receive callbacks for and results need to be aggregated in pieces rather than sequentially.

When I needed a recursive directory listing this past week, I was tempted to use a library: why solve a solved problem? The glob library provides this functionality with very little effort:

Why would you use anything else? Here’s what I saw when I did an npm install glob:

  • glob
    • minimatch
    • lru-cache
  • sigmund
  • grafeful-fs
  • inherits

Simply by adding glob to my project, I’ve added a total of six modules. That’s not unexpected, though, since glob does a whole lot more than I need it to do. In the end, I ended up simply writing my own, and including it in the single file that requires the functionality:

Why are dependencies not good?

First, and most importantly, is the security of those packages. If the SSH keys of the developer of those packages are compromised, an attacker could provide an “updated” version of the library which includes malicious code. At Mozilla, we use internal mirrors of PyPi and NPM to make sure we’re not installing arbitrary modules. Avoiding dependencies helps to avoid requiring a solution.

Second, there’s a performance hit for libraries. If you’re building a one-off fix for a simple problem, using a library increases the overhead of your app’s load and use. If you’re building a web app on Node or Django, you might use an auto-reloader to restart your local server when script files change. In many projects, this takes an imperceptibly small amount of time to reload. As your codebase and dependency list grows, your auto-reloader can take precious seconds to run (we have projects that take almost five seconds to reboot).

Each dependency increases the time it will take to install your application. Zamboni (the code behind addons.mozilla.org and marketplace.firefox.com), for instance, takes 12 minutes to install libraries and dependencies. What starts out as a small number of libraries can very quickly grow out of control and become a serious nuisance. time npm install glob, to reference my earlier example, tells me that glob adds four seconds to my install time. Some simple and unscientific benchmarks from popular node libraries:

  • socket.io: 33s
  • mongoose: 9.5s
  • connect: 5.7s
  • jade: 5.3s
  • express: 4.4s
  • glob: 3.9s

And some from popular Python libraries (run with time pip install <module>):

  • numpy: 110s
  • django: 96s
  • pycrypto: 18s
  • flask: 14s

Third, you’re taking the gamble that the libraries that you depend on don’t have conflicting versions. A great example of this can be illustrated by a web app that I was building: the HTTP requests that I was creating with Python’s requests library didn’t have a .json property, as the docs state. An hour of hair-tearing later, I discovered that another library that I was using had already installed a much older version of requests which lacked the property. Unfortunately, the library wasn’t compatible with the latest version of requests and I had to settle for the old version.

The consequences could have been much worse, and this is a not-well-solved problem (for the Python community, at least).

Last, if your project is used as a library, including dependencies decreases the re-usability of your code. If your code uses a third-party library when it could have taken advantage of some slightly-gnarly standard library tools, all of the above reasons make it that much more difficult for a developer to justify using your tool.

Now hold on just a minute.

Does this mean you should never use an external library? Not at all! You should use libraries whenever it’s appropriate. Sometimes the effort required to perform a task correctly and thoroughly (or at all) is simply too much work to do on your own. OAuth? You’ll probably want a library. Database work or ORM? Use a library. But what if you need to serve a single static HTML file over HTTP? You can probably use Node’s http or Python’s SimpleHTTPServer without too much heartache.

Sometimes it’s just irresponsible to write code yourself: would you trust a developer’s one-off method or a mature ORM’s SQL sanitization code? What about code to generate secure random numbers for encrypting sensitive data? Or code that protects against XSS attacks? There are a lot of instances where it’s in your users’ best interest to use a trusted solution rather than your own solution.

A double-edged sword.

Another reason for choosing libraries is the community: if there are bug fixes to a third-party library, dependents can relatively easily update to the latest version of the library and take advantage of the improvements immediately.

That can be a good thing and a bad thing, though. Libraries without a community around them can contain bugs that don’t get patched in a timely manner. Fixes may be difficult or impossible to upstream.

TL;DR

  1. If you can easily get by without a dependency, you don’t need the dependency.
  2. If you’re building a library, you should avoid dependencies.
  3. Don’t avoid dependencies if it means potentially putting your users at risk.

Firefox Marketplace: April 19th – May 2nd

Andy McKay

2

This is a regular post focusing on the status of the Firefox Marketplace.

  • Total bugs open: 538
  • Total bugs opened last two weeks: 237
  • Total bugs closed last week: 159

Payments testing was conducted in the field and that caused a large number of bugs to be filed.

Some specific changes of note:

  • API for the simulator to create app receipts (865498)
  • Users languages are now persisted for Marketplace and AMO so emails can be localized (833049)
  • API now works correctly with geo location (863775)
  • App locale listings improved in the developer pages (866287)
  • A whole bunch of payment fixes from Bango.
  • Product icon API makes payment pages so much prettier (864451)
  • Fireplace shows new apps (867272)
  • Review queue for themes improved (841185)
  • A parser for the new app feature detection (862459)
  • New design for the details page (860384
  • If users abort during PIN, make them start again (867727

Payments with an icon:

Screen Shot 2013-05-03 at 4.14.27 PM

Web activities are coming to the Marketplace.

Check out the documentation for more.

Mozilla Webdev “Beer and Tell”, April 26, 2013

Jennifer Fong

So what’s a Beer and Tell?

A Beer and Tell is an event web developers at Mozilla hold every third Friday of the month. We share emotional and uplifting stories about projects we’re hacking on to the group. Usually open source projects. Likely with a reasonable license. Today your Beer and Tell post is written by Edna Piranha of Noodle Industries fame.

Last Friday, we experienced the following dramatic and exciting worlds:

  • Michael Kelly’s text-based adventures in JavaScript!
  • Absent Erik Rose’s clickable traceback stack frames in Python!
  • James Long’s scalable cloth simulation in LLJS/asm.js!
  • Chris Van’s “because my original project name was taken on Github” project GltHub!
  • Edna Piranha’s (that’s me!) interactive fiction game engine thing!
  • Matt Basta’s graphicsBC!

Text-based adventures in JavaScript

Reporting from hills surrounding a Martian colony, Michael Kelly shares his latest project – an ode to the time when we were young children (or possibly still unborn) – text-based adventure games in JavaScript. You can play a demo, as long as you promise to avoid viewing the source and cheating.

Text adventures in JavaScript

Text adventures in JavaScript

Clickable traceback stack frames in Python

While we weren’t looking, Erik Rose’s body was replaced by Mike Cooper and he presented in Erik’s voice about nose-progressive. You can click your stack frames to open your editor – view a demo or call your local representative!

Scalable cloth simulation in LLJS/asm.js

Like a hawk from the night sky, James Long swooshes into the Mountain View office through a wormhole and opens his high-performance laptop. He presses the space bar and an open source browser opens with a cloth simulation. He plays Gary Wright’s “Dreamweaver” while we are slowly possessed by the silky smooth cloth simulation. You too, can be possessed by the dance of the cloth.

cloth simulation

cloth simulation

GltHub (a.k.a. because my original project name was taken)

Chris Van takes us on a spaceship to Jupiter and tells us about GltHub, a site that reminds you of the guilt you should feel for not closing bugs fast enough. If you want to contribute more guilt, check out the rocket engine that made this.

GltHub

GltHub

General Store

Edna Piranha (wait, I’m talking about myself in the third person – weird) presents an interactive fiction game engine called General Store that causes post-post-post modern, post-deconstructed encounters with the fourth kind – absurdist fiction. Also known as Lovecraft meets Kafka. Do not attempt to adjust your television, just click around and breathe slowly.

General Store

General Store

graphicsBC

We finally land back on planet Earth and sit comfortably in a circle around a campfire. With a flashlight under his chin pointing upwards and him staring straight at us, Matt Basta talks about graphicsBC, a microscript for code golfers and hobbyists to create graphics. Suddenly, Tofumatt shows up in a flying motorcycle and throws his helmet into the fire.

And that’s it for now! See you again next month.

Kanban for MDN development

groovecoder

3

MDN Kanbanery

MDN workflow was a formless void

When I first joined Mozilla there was no workflow for MDN; in fact, there were no full-time developers for MDN! To push my first bug fix to the site, I had to negotiate a mess of mdn bugs, wiki pages, and IT bugs, strung together with email. It took a couple weeks to get a simple fix into production, and worst of all – I had to interrupt at least 3 other peoples’ regular workflows.

Let there be Scrum

MDN Sprint Burndown

I had done Scrum for a few years at SourceForge so I naturally started to work in some “scrummy” things for MDN – first I added some agile/scrum features to the Bugzilla JS addon. Then we got another couple of developers on the team and we used more agile practices in our MDN workflow. So we did user stories, standups, retrospectives, planning poker, and sprints on top of Bugzilla with Paul McLanahan’s fantastic ScrumBugs tool. We used it to run our sprints for over a year; to migrate MDN from MindTouch to Django. Sprints helped us prioritize, plan, and commit to release batches of bug-fixes, enhancements, and features at regular intervals.

Continuous Deployment

MDN Staging Chief

On our new Django platform, James and Jake hooked chief up to give us continuous deployment to MDN; our “regular intervals” went from weeks to hours. Our flexibility and adaptability with continuous deployment is awesome. Pushing frequently caused a series of effects on our workflow, though:

  1. We naturally prioritized things by hours or days. So, during our sprints, we would
  2. remove and add items between planning meetings. This had knock-on effects like
  3. making it hard to see what we’re actually working on between meetings, and
  4. making our sprint-based estimates totally inaccurate.

A ban came, it’s name was Kan

Around this time, I read Kanban, by David Anderson and some of Kanban and Scrum. A couple things stood out to me:

The Kanban feature I most liked was lead time – i.e., the clock time between when a request is made and delivered – and cycle times – i.e., the clock time between when a cycle of work begins and ends. These clock times seem more valuable to plan and prioritize than fuzzy estimations. Because really – who doesn’t like data and numbers, right? So, of course, I wrote code – kanbugs – to help visualize our MDN workflow and calculate our lead and cycle times.

Kanbugs

Kanbugs ScreenshotKanbugs used data from our bugzilla product and our GitHub pull requests to visualize our workflow. In general, the workflow was:

  1. We select a bug and add ‘p=<estimate>’ to the whiteboard
  2. We implement a bug and submit a GitHub pull request with “fix bug <id>” in the commit message
  3. We review a bug and merge it to master, which automatically marks the bug ‘RESOLVED:FIXED’ in bugzilla
  4. WebQA tests the bug on the MDN dev integration server
  5. We release the code to production, and WebQA marks the bug “VERIFIED:FIXED” in bugzilla

By visualizing the workflow and calculating both lead and cycle times we learned a couple interesting things. Most prominently, of our 39-day lead-time, 19 days were spent in triage and 14 days were spent waiting for testing! 85% of our lead-time was happening outside the development team. This kind of data helps us more effectively improve our workflow. E.g., rather than improve our estimates, we worked with WebQA to change from mandatory to as-needed exploratory testing.

Kanbugs was good for passive, read-only visualization and calculation, but (like Scrumbu.gs before) it wasn’t made for active management. It lacks:

  • Quick visual scanning for action items – who’s blocked? who’s too busy? what should I work on next?
  • Work-in-Progress limits – Kanban enforces small batch sizes by setting limits on how many things can be in the board at a time

Kanbanery

MDN KanbaneryKanbanery is good for these features. So, a couple months ago, we started an MDN board on Kanbanery. Kanbanery’s visualization is great. On a typical morning, I check emails and then

  1. quickly scan the board for any cards with green check-marks that I can pull to the next step of development.
  2. quickly scan the work-in-progress limits to see if I can help un-block cards that are piling up at a certain step
  3. quickly scan the board for my cards to resume my main dev task(s)

Of course, now that we’ve used Kanbanery for a couple months, we’ve hit drawbacks:

  • Yet Another Tracking Tool – we already have to keep up with email, bugzilla, and github. Scrumbugs had the same drawback, but Scrumbugs doesn’t micro-track through the sprint, and it automatically marks bugs fixed using bugzilla data.
  • How to incorporate contributors – we don’t want to make contributors use Yet Another Tracking Tool, so we don’t include them in the board. That means the board doesn’t show contributors’ work, which can be considerable.
  • General process churn – we went from no process through multiple forms of agile and scrum practices to Kanban in the space of about 18 months. I really like to continuously improve dev practices, but even I’m getting tired of changing things.

What’s next – maybe Kanbuggery?

Rather than change things up again, what I’d really like to do is automate Kanbanery – to update the board based on bugzilla and github actions, like we had done with Kanbugs. Then Kanbanery could give us its great visual features without needing active care and attention. Kanbanery has what looks like a fully-featured API, but I haven’t had time to explore it. Has anyone else?

How are other Mozilla, open-source, or website teams using Kanban for development?

Firefox Marketplace: April 5th – April 18th

Andy McKay

This is a regular post focusing on the status of the Firefox Marketplace.

  • Total bugs open: 485
  • Total bugs opened last two weeks: 150
  • Total bugs closed last week: 110

The API documentation has moved and is now separate from the rest of the marketplace code. The marketplace has adopted the status code 451 to describe an app we can’t display.

The migration over to the Add-ons site is now complete. Go check out themes.

Some specific changes of note:

  • OAuth has been turned on for all internal services between marketplace, solitude and webpay (858813)
  • Changes to the receipt specification to allow different kinds of receipts (858610)
  • Three legged OAuth has landed for the API (827948)
  • API submission is now throttled, but you can apply for access to submit more apps (848869)
  • Did we mention themes are migrated, oh yeah (858276)
  • Fireplace now has a featured page (860410)
  • Receipt verifying now checks the verifying service URL (770666) and type of receipt
  • Fireplace now has abuse pages (857685)
  • Unit tests galore (851582) and more for Fireplace
  • Apps filtered on adult and child flags (852567)
  • PIN user interface awesomeness (842861)
  • Charts, charts and more charts using monolith (843046)
  • Where in the world is Carmen Sandiego? I don’t know but our new geo location might tell you (851192)

And finally… odd add-on of the day whimsy.

Firefox Marketplace: March 8th – April 3rd

Andy McKay

1

This is a weekly post focusing on the status of the Firefox Marketplace. Because of holidays, PyCon and then more holidays, this post is a little delayed and covers a few weeks.

  • Total bugs open: 464
  • Total bugs opened last two weeks: 232
  • Total bugs closed last two weeks: 233

Most of the changes revolve around the API. There are endpoints added for the homepage, login, ratings and more. For more information on the Marketplace API, please check out the documentation.

The primary consumer of the API right now is fireplace the packaged app for the Marketplace. There have been a lot of changes in fireplace including search results, ratings and more.

We are currently migrating the existing Get Personas site over to the Add-ons site. For more information read our blog post.

Better know a WebDev: Wil Clouser

Andy McKay

Featuring Wil Clouser.

5865658769_1fa4436ecc

What do you do at Mozilla?

I’m the Engineering Manager for the Firefox Marketplace and Add-ons. I spend most of my day trying to remove roadblocks for developers and coordinating with other teams to make sure there is a steady stream of work. The spice must flow!

Other parts of my job are day-to-day team operations (HR questions, career development, etc.), spec reviews, architectural design input, any shady negotiations for project priority, and crisis management in the rare case when something goes pear shaped.

Any fun side projects you’re working on?

I’m a hobbyist photographer these days and have started experimenting with writing short (fiction) stories to go along with the pictures. Something that is still in its infancy for sure.

How did you get started in web development or programming?

I took a C class in high school and thought it was fun, then I suffered through Java in college and started doing PHP work part time for the university. I flipped to python a few years ago and have enjoyed it although my coding these days is mostly minor tweaks to other peoples’ code.

How did you get involved with Mozilla?

Mike Morgan and I worked in the same place while I was in college. He was doing volunteer work with Mozilla and it looked like he was having a good time so I started volunteering too. At that time we were maintaining Add-ons which was a mix of hard-coded add-ons and smarty templates. It wasn’t pretty.

What’s a funny fail or mistake story you can share?

We used to maintain mozilla.com in SVN as a bunch of static files in a hierarchy. I may have gotten a little carried away with the flat files – we had about a dozen files we duplicated for every version of Firefox (at the time we had 4 levels, eg. version 2.0.0.1) and for every locale (about 60 locales). That, combined with the locale specific CSS and images added up to a ton of files on disk and SVN would soak up all the disk I/O trying to do an update or a commit.

Anyway, when we launched Firefox 3 we were aiming for the Guinness World Record and we put on a big show of it to get lots of downloads including having people talking live on Air Mozilla about how awesome the new browser was. Due to the high traffic everything was responding slower than usual, but we were in decent shape, except that I had to push one last thing to SVN and I did an `svn up` first and it was just sitting there thrashing and – SVN doesn’t have any output when it’s parsing through your directory tree – I just had to sit there and wait. It ended up taking about 20-30 minutes which wasn’t unusual (sadly enough), but not being able to give an estimate was rough. I remember watching Mike Beltzner talking about random things on Air Mozilla trying to fill time and he’d ask me on IRC for an update every couple minutes and I’d reply with “real soon now.” I felt bad for him.

So, I contributed to us being late to launch in a high-profile kind of way, but we still made the record and I was happy about that. :)

What’s something you’re particularly proud of?

When the Marketplace team gets in its groove it blows productivity estimates out of the water. We work so well together I’m just proud of my whole team. The entire Firefox Marketplace was just an idea a year ago and look where we are now.

What’s coming up that you’re excited about?

We’re going to be merging Get Personas into Add-ons. For real. We’ve been talking about it for, like, 2 years and every time it comes up it gets bumped for something higher priority but it’s finally close enough that we’re just going for it.

What question do you wish you’d been asked?

Q: If I typed “youtube” into your awesomebar would you be embarrassed at what showed up?

A: Nope! First hit: Macklemore’s Thrift Shop. Second hit: LMFAO’s Sexy and I know it. Third hit: I clicked it and it says it has been removed because it violated Youtube’s TOS. So, that one might have been embarrassing, I’m not sure.

Favourite city that’s not Portland?

The easy answer is wherever my friends are, but as I’m staring outside at the cold wind and the looming rain I’d say somewhere warm like some anonymous fishing town in Mexico.