All posts in Mozilla

Looking Ahead: Challenges for the Open Web

Mozilla at the 2008 Summit in Whistler.  Mozilla Community at 2008 Summit. Taken by Gen Kanai

At the end of this week, I’m moving on after six amazing years at Mozilla. On August 25, I’ll be joining Reddit – another global open source project – as their first user experience designer. I’m ecstatic to help shape and design the future of another incredible community.

In looking back at all that’s changed in technology and the web since I joined Mozilla, I find myself humbled at the trials we’ve met and overcome. When I joined in 2008, we were smaller and scrappier. Fellow designer Alex Faaborg and myself stood before whiteboards, explaining how tabs on top of the URL bar were more efficient. The bug backlogs of Firefox 3 kept us up at night, but when we launched in July 2008 we made the Guinness Book of World Records for most software downloads in 24 hours ((Mozilla sets new Guinness World Record with Firefox 3 downloads)). Chrome didn’t even exist yet!

Of the challenges in Mozilla’s future, many are nearly universal for open source communities and largely unsolved. Here are three I find myself often returning to:

1. How do we protect users’ data when users consistently choose utility over privacy?

You can package it any way you like, but if your privacy-centric product even slightly hinders user enjoyment of the web, it won’t see wide adoption.

When prompted, users overwhelming cite online privacy (referring to data being shared with companies and governments) as a concern. A recent poll ((Right To Be Forgotten: Do Users Even Care?)) showed 26% of people were “extremely concerned” about privacy when using a search engine, with nearly 90% expressing some level of concern. And yet, 92% of those use Google and only 3% use DuckDuckGo, an explicitly non-tracking search engine. In the developing world and younger markets, users are even less concerned. Mozilla’s research team is currently investigating attitudes towards privacy in Malaysia and the Philippines, and most people they’ve spoken with don’t even have a concept “online privacy” aside from not wanting their friends and relatives to see all they’ve posted to social media.

Those of us who care about online privacy are increasingly at a values impasse with our users. The solution is not to simply inform, coax, or frighten users into taking security measures.

Most importantly, a world without the practical technological possibility of privacy is much scarier than one where users can choose, either actively or passively, to share their information.

2. How can global communities accommodate incompatible values?

Philipp asks if this is good for the company

Championing inclusiveness and diversity is an easy decision for most organizations. But when push comes to shove, members of any large community will still disagree fundamentally on many important values. The need to bridge fundamental divides is an inevitability.

As an example, open source contributors disagree vehemently when it comes to DRM. Is it better to follow the content industry and implement extensions so content owners can control how users share content? Or, is DRM’s current instantiation so harmful to an open web that it’s worth limiting user’s access to content to avoid supporting it? Both these views and many others exist amongst Mozilla contributors, yet ultimately decisions about what ships in Firefox must be made. When this happens, the community cannot simply shrink by the number of people opposed to the decision.

To successfully cooperate, global communities have to form a sustainable plurality. The key is allowing members to operate in a context of known responsibilities to each other, yet also generalized freedom to hold, express, and act on their views. Freedom of expression should exist by default, but the community will collapse if members don’t understand that they also have responsibilities that are defined and understood.

Furthermore, the balance of power between the community at large and its leadership is best when it is understood and predictable. Major organizational decisions are often be made by a few executives or benevolent dictators for life. Where and how these decisions are made as well as what was decided needs to be widely available for a community to cohere. The community must also know the difference between the organizational values which guide decisions and the personal values of leaders which do not. Realistically, the two are never wholly separate.

The question over “public vs. private” values in leadership has been addressed frequently at Mozilla. Perhaps the lines that separate public and private views cannot be entirely explicit, but acknowledging and engaging openly about differences bring strength to a community. Again, this is best where the role and position of leaders in making decisions is clear.

3. How can design culture embrace open source?

Affinity Diagramming with Firefox in Toronto

Within design communities, open source is still met with disinterest at best and derision at worst. This is hurting both open source and design.

The main barrier towards design culture embracing open source is a chicken-and-egg: few open source projects appear to value usability and design. Scratch-your-own-itch hacker culture assumes the creators of technology are its users, which deemphasizes the need for usability and accessibility. Additionally, feedback in open-source is heard mainly from a few power-users, and the temptation to appease them can thwart designs that would appeal to a wider audience.

Another reason design culture hasn’t embraced open source stems from designers’ wariness over being taken advantage of. I remember Mark Mentzer, one of my Carnegie Mellon design professors, warning his students to “never work for free!” This attitude runs deep in design circles, and for good reason: we’ve become used to requests for work where the only payment will be “another piece in your portfolio.” Honoring those requests devalues design work as a whole.

But, open source is different from free labor. Just as developers do, designers love their work and often consider it a hobby as well as an occupation. The transformative potential of open source projects excites designers as much as developers. By insisting on excellent user experience, open source projects can show designers that they are communities that value design.

Another reason design culture hasn’t embraced open source is because code contributions fit more easily into open projects than design contributions. Any developer can jump into an open source project by taking and fixing a bug. Little context is needed beyond what’s provided in the ticket: current behavior, expected behavior, acceptance criteria. Patch written, reviewed, done, boom.

In design, more context and background is needed to “fix a problem,” which hinders potential community contributions. A design “bug” is harder to identify than most engineering bugs. Simply diagnosing them requires user research, collaboration, and context. Providing well-scoped design problems with dedicated mentors can help bring on contributors.



Mozilla Heart

To Mozilla, thank you for six amazing years. You’re my allies, my friends, and the most incredible people I know.

Try Out Fira Sans: a Free, Open Source Typeface Commissioned by Mozilla

As designers in open source, we’re constantly looking for opportunities to bring the principles of universal access and redistribution to new areas. While the term “open source” may still be mainly associated with code, the value in free collaboration benefits every discipline – particularly design.

In that spirit, the Mozilla Foundation commissioned famed typographer Erik Spiekermann to create a completely free, open-source typeface in 2013. Thus was born Fira Sans, a gorgeous san-serif font that looks great on the web. So great, in fact, that we’ll be using it in Firefox’s in-content pages such as Preferences and the Add-ons Manager.

fira sans preview

If you haven’t tried out Fira Sans, now’s a great time: version 3.1 introduces 16 different weights, a huge character map, and extensive language support. Also available is Fira Mono, a monospaced version of the original. Give it a spin on your next project!

Download Fira Sans 3.105 (3.6mb .zip)

Firefox’s Redesigned Preferences Feel More like the Web

Another great Firefox improvement is releasing soon!

Firefox’s Preferences, until now, have required navigation through a cumbersome floating window where it’s nearly impossible to find what you’re looking for. This window is a classic example of a common software problem: settings are slowly added onto the interface as new functionality is introduced, and eventually it sags under the weight.

The mess that is current Firefox Preferences

The mess that is current Firefox Preferences

Until now, that is!

The Firefox UX team is excited to announce that brand new, beautiful Preferences are now the default in Firefox nightlies and will soon be in release Firefox. In this redesign, the interface is visually consistent, the information architecture is improved, and the whole thing is rendered in content space rather than as a separate window.

Firefox’s new in-content preferences

Why is it important that Preferences are in the content space rather than a separate window?

  1. Consistency across devices. By using the content space, we no longer have to rely on the ability of a device to draw separate windows and dialogs. This is particularly important on tablets and phones, where window management is more difficult. Now, users of mobile Firefox will see a familiar interface when move to desktop Firefox, and vice versa.
  2. Consistency across operating systems. Windows, OSX, and Linux all create windows and dialogs differently, which means the user’s experience with Preferences was different depending on the OS. Now, as we draw this interface within Firefox, we can make it look and feel identical across systems.
  3. Consistency with the web. Ultimately, the browser is a doorway to the rest of the web. For the browser to behave like a dialog-heavy desktop application rather than the web itself was jarringly anachronistic. Beneficially, rendering like a website also means users won’t need to find and manage a separate window in addition to their open tabs.
  4. Space to grow. Not being bounded by a small, floating window means we can create richer customization experiences. The Add-ons manager has already  moved to content space, and we’ve been able to explore richer use cases as a result. Similarly, expect to see innovative customization experiments as well as the usual Firefox settings.

And before you ask, yes, the next step is absolutely a search field in Preferences to summon the exact setting you’re looking for. This is needed particularly so users won’t have to “learn” our interface, but can instead focus on their task.

A special thank you goes to Senior Visual Designer Michael Maslaney, who’s been spearheading Project Chameleon, the style guide behind this redesign. Another thank you goes to MSU students Owen Carpenter, Joe Chan, Jon Rietveld, and Devan Sayles for creating the award-winning first version of Firefox’s in-content Preferences in May 2012.

Firefox and Flux: A New, Beautiful Browser is Coming

Tomorrow, on April 29, something amazing is coming to Firefox.

It’s not an interface adjustment or tweak.  It’s not a bug fix.  It’s a complete re-envisioning of Firefox’s user experience, and it’s been brewing for the past five years.

Firefox on Linux, OSX, and Windows

Firefox on Linux, OSX, and Windows

Good to Great

This new Firefox, Firefox 29, was borne out of a series of incredible, detail-obsessed designers and engineers understanding that taking products from good to great requires more than a series of incremental improvements.

Good can be achieved through incrementalism.  Great requires, at times, overhaul.

Firefox 29 contains extensive improvements that were planned back when Alex Faaborg, Madhava Enros, and myself were the only designers at Mozilla.  Back then, Firefox was beginning to buckle under the weight of its inconsistent code and interface.

Realizing the Need for Overhaul

It’s common enough for large codebases maintained across years to develop inconsistencies.  But, Firefox’s nature as an open-source community project contributed to idiosyncratic user experiences.   Menus and dialogs used different tenses and tones.  Add-ons behaved unpredictably.  Customization was handled differently throughout the browser.  Over the past few years, we’ve been working to improve many instances of inconsistent behavior, such as replacing modal dialogs for tab-modal ones, standardizing notifications, and using a uniform tone-of-voice.

Making improvements here and there is often what user experience designers at an organization are expected to do: fix what’s broken, slightly improve what isn’t, and generally don’t get in the way of engineering effort.  But, this method can only make an existing product slightly better, and the gaps it causes reveal themselves in time.

A sinking ship can’t be patched endlessly when it needs a new hull.  This is when user experience design is most effective: when it envisions the system as a whole.  When it steps away from the trees and sees the forest holistically.

Firefox needed a new hull, and the bulk of that hull is arriving on Tuesday.

Others have been blogging about Firefox 29’s beautiful redesign, so I’ll just mention the highlights.

Consistent Customization

Customizing Firefox is now entirely predictable and much more fun.  Rather than digging into Preferences windows and dialogs, you can make Firefox the way you like via dragging-and-dropping buttons wherever you want them.

A Customize panel – itself customizable – displays the tools you want available in a single click but don’t want cluttering your interface.

Firefox Customize Menu

Firefox Customize Menu

Simple and Streamlined

Gone are the bulky angles and edges of tabs and menus.  In Firefox 29, you’ll see streamlined, almost aerodynamic, curves giving emphasis to your current tab and subtly understating the rest.

Streamlined Tab Shape

Streamlined Tab Shape

Themes and Personalization

Making Firefox visually your own is not only easy, but gorgeous.  Lightweight themes look fantastic in 29 with a light interface overlay on whatever image inspires you while you browse.

Lightweight Theme Applied to Firefox

Lightweight Theme Applied to Firefox

Obsession with Details

It’d be hard to describe all the changes coming to Firefox in a single post, but I hope you’ll find that we left no stone unturned.  Firefox 29 is all about details: the glows, the colors, the animations all reflect our desire to make the entire experience seamless.  A special hat tip to our visual designer, Stephen Horlander, for his painstaking eye for detail.

It's All About the Details

It’s All About the Details

Tomorrow’s launch day will, perhaps, be our biggest yet.  It’s certainly an emotional day for myself and the others who have worked on this release for years.  I can’t wait.  I hope you love it.

MozCamp EU: Mobilize Mozilla

Admittedly, a few days have passed since the September 8-9th 2012 MozCamp EU in Warsaw. But, I wanted to say a few words about the incredible experience.

I was so excited to attend this MozCamp in particular. Eastern Europe, and Poland especially, have some of the oldest and strongest Mozilla communities, in existence for well over a decade.  And, Poland is continually at the top of our browser marketshare charts, with roughly half the population using Firefox. Having never been to Poland, I’ve always seen these numbers and wondered about the people and stories behind them.

I’d met many Mozilla Poland community members over the years and knew they were passionate for the open web – people like Marcin Jagodziński, who first translated Firefox into Polish, and Marek Wawoczny, who maintains Mozilla Poland’s active community site.  But, meeting these contributors together as a vibrant and enthusiastic community sheds light on Eastern Europe’s passion for open source. The communities here are healthy and growing.  They are directly involved in education, many regularly speaking at university campuses to get students excited about innovating in the open.  It was incredible to hear about the specific challenges that each community faces in their regions and the creative ways they step up to meet them, from hacking at meet.js events in Krakow to the Free Hugs from Firefox in Paris.

And, as at all Mozilla events, the talks and demos were incredible. As a gamer, I thought one of the most exciting projects was BananaBread, a fully 3D FPS built using only HTML5 by Anant Narayanan, Alon Zakai, and others.

[youtube=http://www.youtube.com/watch?feature=player_embedded&v=_HRiLIkzvFQ#!]

Wesley Johnston showed off some pretty exciting stuff coming up in Firefox Android, like smooth-as-butter scrolling and reader mode, which turns your ugly mobile site into something that will make typographers cream their pants.

Paul Rouget updated us on the latest developer tools hotness, including including tilt, which lets you visualize a site’s DOM tree in 3D, and the new command line.

Patryk Adamczyk gave a great run-through on the design principles that have guided the creation of the beautiful Firefox OS, including the “personality types” which guided its sound design (good news for anyone who owns a business suit and a skateboard).

Tim Terriberry and Anant Naryanana (yes, again!) gave an awesome demo of WebRTC working in the browser – live with a peer-to-peer video call!

I gave a talk on how to user test mobile apps (and other projects). It was a great experience, and people brought some excellent ideas and questions! I’ll blog more about this talk later.

Of course, I could never do justice to all the great talks, collaboration, and hacking that went on over two very short days, but thanks to everyone who made this MozCamp so awesome. Meeting the Mozilla community always leaves me feeling humbled to work on the Project, inspired by what’s coming up, and (in this case) hungover on buffalo vodka.

Enabling Real-Time Communication on the Web Platform

Mozilla’s manifesto describes the internet as an integral part of modern life and a key component in communication. However, communication on the web has far to go before it’s as rich as face-to-face communication. Real-time video communication on the web should be easy, rich, and readily available to developers in a way that proprietary formats can’t be.

That’s why a new project is spinning up at Mozilla called WebRTC (Real-Time Communication). WebRTC will allow developers to use the web platform to include video and audio conferencing as part of their websites and applications, both mobile and on the desktop. In its first phase, WebRTC will make webcam feeds a primary object in the browser, allowing sites to create rich interactions such as video calling and conferencing. In later phases, WebRTC will allow interactions like co-browsing, in which users can share their screen with a friend.

Privacy and Security

Privacy and security are major concern in enabling open video communication on the web. A face and voice are two of the most identifiable kinds of shareable data, and keeping users in absolute control of who has access to them is vital. As the IETF states in its WebRTC draft document, the ability for users to control access to their webcam, be able to cancel communication at any time, and not be eavesdropped upon are essential.

Some of the challenges we’ll face are in giving users the most accurate information possible about the site and caller who are requesting access to their webcam. Most requests for webcam access will simply be from a trusted site itself, but a malicious site could potentially try to gain access by embedding its call request within a trusted site. In this paper, Eric Rescorla outlines how potential “ad-hoc” calling attacks could come from ads in iFrames embedded within trusted sites.  Many other potential attacks need to be dealt with.  For instance, because WebRTC would be controlled by a web server rather than conventional real-time systems, web browsers might expose JavaScript APIs which allow a server to place a call. If access to such an API were unrestricted, sites could “bug” a user’s computer and capture video camera activity (Rescorla).

Even a trusted site could be compromised, both during a call or after. And, since the sites themselves would control and display the UI of the call itself, Firefox needs to give the user both constant indication that they are in a call and the ability to disconnect at any time.

User Interface

However, guarding against threats only goes so far towards keeping users in control of their webcam communication. Clear messaging, useful tools, and sensible defaults need to be in place for video conferencing to safely take root in the browser.

The first phase of enabling WebRTC will allow the most basic use case: giving a site access to a user’s webcam and microphone. The browser already serves as a mediator for other user data, such as location and access to cookies. Firefox usually asks for permissions using a door hanger notification. Door hangers stem from the URL bar to show the site is asking for a permission, and it extends past the content area to show that Firefox is the mediator of the permission request. Using a door hanger notification for WebRTC is both consistent within Firefox and correctly conveys visually that the site has requested access, and Firefox is asking the user for that permission.

Usually, these door hangers simply ask the user for a permission, and in a click the user can give it. However, webcam access requires a secondary stage: showing a preview of the webcam feed. This approach has three benefits:

  1. It gives users the ability to make sure their webcam and microphone work correctly
  2. If users had casually or accidentally accepted the webcam permission, nothing makes people more aware of what they’re about to transmit like showing them their own grubby mug
  3. It gives users the ability to fix their hair/put on a shirt/remove incriminating items from background before beginning call

In some ways, it’s unfortunate to ask users to pass through two dialogs to give webcam feed rather than one. After all, in most cases the site itself will be providing all necessary UI, and perhaps even a video preview before a call is initiated. So, this could all be redundant in many cases.  However, we cannot predict what purpose a site may be requesting webcam feed for, nor what UI will be in place for the user on that page. Even with all our efforts against security threats, any request for webcam access must be treated as potentially malicious.

Once a user has given a site access to their webcam and is likely engaging in face-to-face communication, that interaction should be given a heightened level of priority within the browser. For a user to lose that tab or forget they are broadcasting could range from mildly embarrassing to, well, use your imagination. If a user is actively sharing their webcam feed, they should be able to jump to the tab where data’s being shared or simply cut their webcam feed from anywhere within Firefox. This will require at the very least a toolbar-level Firefox control that appears once a user’s actively sharing.

Designing and implementing a new API is always a complex process.  If you’re interested in reading more or contributing to this project, here are some resources:

On Life

“No one wants to die. Even people who want to go to heaven don’t want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because Death is very likely the single best invention of Life. It is Life’s change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true.

Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma — which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.”

Steve Jobs
February 24, 1955 – October 5, 2011

Name Change (to Protect the Innocent)

Just some housekeeping: My name’s changed from Jennifer Lynn Boriss to Jennifer Lynn Morrow. I’ll still be using “Boriss” as a nickname, but only to friends rather than to everyone.

Research Spinning Up on New Tab Page

Whenever you open a new tab in Firefox, your goal is to navigate somewhere.  To aid your navigation, on this new tab Firefox currently offers you… nothing.  Just a blank page.  100% white, and 100% not useful.

Firefox has been displaying this blank page when users open a new tab for as long as there’s been a new tab.  And, partially, it’s deliberate.  After all, a blank page is guaranteed not to distract you from your current task.  It’s just clean and white, like a canvas, offering no suggestions for the next move and no distractions from it.  Alex Faaborg explains very well in his recent blog post the concerns we have with distracting users and the ways that data overload on a new tab page can be harmful.

This isn’t the case when you open a new tab in other browsers.  Opera was the first to offer a “Speed Dial” with giant thumbnails linking users to their most frequented sites.  Safari’s giant wall-o-televisions offers much the same.  Chrome has played around with different designs, first trying a speed dial like Opera’s and later integrating other content, such as apps.  Internet Explorer, the most unusual of the designs, offers you some options: reopen closed tabs and sessions, start private browsing, or use an “Accelerator,” which usually means do “something with Bing.”

What happens when you open a new tab in different browsers

So, which approach is best for our users?  Would presenting large thumbnail targets to direct people to sites they frequently visit save them time?  Could we present information to make it easier for users to navigate to their next destination?  Can we do so without being distracting and leading users away from the task they had in mind?

We realized that we couldn’t answer these questions without finding out more about our users.  So, a few people at Mozilla are heading up studies to find out how people use tabs and how different designs of new tab page effect how they browse and user the web.

Here’s what’s going down:

1. Quantitative study through Test Pilot on what users do after opening a new tab

Intern Lilian Weng is currently working on a quantitative study within Test Pilot to capture data on what users do after they open a new tab.  This should answer questions surrounding user intention when opening a new tab, and possibly how long users take to perform actions after opening a new tab.

2. A/B test of a new tab page vs. blank new tab

Interns Diyang Tang and Lilian Weng are preparing to do an A/B test using Test Pilot to determine how user behavior differs when presented with a new tab page vs. none.  They are attempting to answer questions such as:

– Does a new tab page slow users down (e.g., by distracting them), or speed them up (e.g., help them find the target site faster)?
– Does a new tab page discourage breadth in visited sites?
– How do users navigate to a website after they open a new tab in each scenario? (location bar, search bar, top sites, bookmarks, history, etc.)
– Are there users who are more mouse-based and some who are more keyboard-based? How does a new tab page affect them?

3. Cafe testing for current Firefox

Diane Loviglio and myself are preparing more qualitative “cafe” tests to gain insight into how people use tabs currently.  We’d like to know why and when users open new tabs in a more contextual perspective than Test Pilot data provides.  Our goal is to find a wide enough range of users that the most common new tab behaviors can be grouped and discussed in a more tractable framework.

4. Testing multiple new tab page designs

Once the research from tests 1-3 is available, variations on new tab pages will be implemented and tried out with real users.  There are multiple testing methods that could be useful here, such as a multivariate testing or even journaling to gain insight into how new tab pages effect behavior of a user over time.

5. Creating a contextual speel dial implementation

Not quite a research project, but intern Abhinav Sharma is designing and implementing an experimental new tab page which uses contextual information about a user’s current browsing session to offer suggestions.  His page makes intelligent recommendations about where you’re likely to go next based on where you’ve been.  The project’s still in alpha, but you can see the code he’s done already for a basic speed dial implementation on his github.

You’ll notice that a lot of this work is being done by our awesome new Summer 2011 interns!  It’s only early June and they’re already rocking hard.

I’ll post what we learn from these studies as results come in.  I predict we’ll gain some insight into user behavior that will inform not only Firefox’s new tab design, but many other features besides!

Making Add-on Updating not Suck

Updating software sucks.  For most of your software, you’d probably prefer to never think about updating.  Ideally, your applications  would stay current and fast on their own without ever requiring your input.

That’s why one of the important changes in Firefox 4’s add-ons manager is keeping add-ons up-to-date automatically.  This happens in the background without you even noticing.

Automatically updating add-ons does exactly what users have been telling us they’d like for a long time.  However, some users will want to manually update their add-ons, as they did before Firefox 4.  Other users will want to automatically update some add-ons but not others.

Hard as it is to cater to many use cases, we felt it was important to allow users to manually update add-ons if they prefer.  Add-on updates are essentially new software, and users should always have the ability to opt out of them.

Below is the basic use case of managing add-on updates I’m proposing for Firefox 5 (which is only a few weeks after the release of Firefox 4 thanks to our new shorter release cycles).  The user begins with completely automatic updates on by default.  By switching to manual updates in the advanced menu, the user can go back to installing updates themselves.  Each add-on shows, in its detailed pane, whether it receives updates automatically or manually.

However, there’s another kind of usage that needs to be supported.  What if a user wants all but a few add-ons updated automatically?  Or, all but a few add-ons updated manually?  Allowing users to switch any particular add-on between manual and automatic updating allows users to make one-off exceptions.

If a user goes to the detailed pane of add-on, they can see how an add-on is currently updating and switch it to the other method.  To change <i>all</i> add-ons to the other method, the user needs to select that option in the advanced panel.  This way, we allow users to make both blanket rules and exceptions as they go.  Here’s a more complete diagram showing updating preferences, with one-off exceptions included: