Scolded and judged
I don't know anyone who has genuinely changed their mind as a result of being scolded and judged.
tech
Governor Parson, apologize to the St. Louis Post-Dispatch, which responsibly disclosed data leak
Last week, I read the bizarre story of Governor Mike Parson of Missouri vowing to prosecute local journalists who notified his office of a data leak in a state website. In a press conference, he claimed that the reporters “decoded” the site's HTML in a “multi-step process,” struggling to pronounce the unfamiliar abbreviation and testing the credulity of his technologically-literate audience. (Does clicking View source involve more than one step? Perhaps among those who find mice to be confusing.)
Leaving Mozilla
I was laid off last week. Officially, I was impacted by “significant restructuring”. I never expected to become so conversant with corporate lingo. It's one of the lesser skills I acquired during my 8 years at Mozilla, mostly after Firefox OS was announced as a priority. Another lesson: companies change.
Gradually reducing the number of ESLint problems in your codebase
I have come to appreciate ESLint very much in recent years. A robust and reliable JavaScript linter, ESLint can be used not only to detect common programming mistakes, but also to enforce a consistent code style. Its utility cannot be overstated. Your teammates and your future self will thank you for using it.
I recommend that ESLint be enabled before any code is written, but what about existing projects? A developer who runs ESLint on an existing codebase will certainly be overwhelmed; it will warn about scores of issues which had not been noticed until that point. Is there any way to gradually adopt its recommendations? More importantly, is there any way to prevent the number of problems from growing? Running the linter on CI is no solution. It will simply fail and annoy others.
When a README accidentally becomes a manifesto
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.
Using the Optimizely API to avoid flashes of unstyled content in A/B tests
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.
Determining whether users are logged into Twitter
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.
Context menus and the design of design
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:
The user agent may… provide access to its default context menu, if any, with the context menu shown. For example, it could merge the menu items from the two menus together, or provide the page's context menu as a submenu of the default menu. In general, user agents are encouraged to de-emphasize their own contextual menu items, so as to give the author's context menu the appearance of legitimacy — to allow documents to feel like “applications” rather than “mere Web pages”.
— HTML 5.1
The specification shows examples where custom menu items appear above default menu items, and Firefox has taken this lead. But there is a problem with this approach. Usually, the most commonly used default menu items appear at the top of the list. Open Link in New Tab, View Image and other useful items are placed here. As a result, users can become so accustomed to clicking these that they stop consciously thinking about their actions. They habituate to clicking the first item in the menu. When that item is replaced with something new, users can find themselves accidentally making the wrong selection.
Jef Raskin discusses habituation at length in The Humane Interface. One passage even speaks to this problem directly (emphasis mine).
Most attempts to make interfaces adaptive are ill-advised; whenever a system changes automatically, even if the change is as small as, say, a reordered set of items on a menu, your expectations are upset and your habituation is frustrated.
Raskin is correct. Like moving the Windows Start button or changing the Mac global menu, reordering the browser's context menu is likely to impede useful habituation and frustrate users. I have even experienced this first-hand. When Firefox swapped the positions of Open Link in New Window and Open Link in New Tab a few years ago, I found myself frequently making the wrong selection. As it turns out, I was not the only one.
What would be a better approach? I would like to see a submenu dedicated to custom menu items. Perhaps we could label it This Page. When a website provides custom items, they would appear in this submenu. When no items are provided, the submenu would be greyed out. The size and order of the menu would be constant, whether or not custom menu items are provided. Useful habituation would not be disturbed.
It might be tempting to blame web developers for using this feature, but we must remember that web developers are themselves users — users of web technology — and we should not blame users. Instead, we should lobby browser vendors to address this by building design constraints into their products that lead web developers, without their knowing, to build usable interfaces.