I recently started work on a project at Mozilla which I’m calling Ensemble. Ensemble will be a minimalist data-sharing platform. It will allow data scientists to quickly and easily create public dashboards with no web development experience.
In the process of writing a project README, I realized I had accidentally written something like my software development manifesto, the distillation of my thoughts on creating valuable software. The document does discuss some specifics of this project, but the broader points apply more generally.
When writing software, we should approach our own ideas with skepticism. We have more ideas than users have needs.
Features do not guarantee success. If they did, we would line up to trade smartphones for punch cards. Myspace would acquire Twitter. Picasa would be the new Instagram. This doesn’t happen. The history of software is the history of simplicity and elegance winning. We succeed when we attend to what really matters, not when we build every feature imaginable.
We use Optimizely on the Mozilla Developer Network to build and analyze split experiments. We find that the tool helps us move forward with confidence, understanding how changes affect user behavior. We care about accuracy and user experience, so we were concerned when we discovered a problem in a recent experiment that could have affected both.
Update: This technique no longer works because the Twitter favicon is no longer hosted from the twitter.com domain and the ?redirectafterlogin query parameter only works with resources on the twitter.com domain.
In Detect if visitors are logged into Twitter, Facebook or Google+, Tom Anthony explains how to determine what social networks your users are logged into. The approach Tom recommends still works today, but the Twitter code needs to be modified to work as expected.
I often recommend that software developers become familiar with the fundamentals of usability — we are all designers, whether we know it or not. But this takes time. When we are not able to design usable interfaces ourselves, then, it can be wise to rely on frameworks, conventions, and other resources that make design decisions on our behalf. What happens when those resources lead us astray?
The HTML5 specification allows developers to add new items to the context menu. This ability can be useful, especially as the line between web application and native application becomes blurred. But the specification is silent on one very important consideration — placement of custom menu items. Only the following guidance is offered to implementers:
