All posts tagged open source

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.

That Pesky Design Process

Lead Ubuntu designer Ivanka Majic has been taking some flak for her recent blog post about redesigning buttons in Ubuntu’s window manager. And, rightly so; she opens by asking several vague questions, says analysis happened in the form of a sketch, and then reveals that Ubuntu’s window manager buttons will be redesigned. “Is it better or worse? It is quite hard to tell,” she writes.

Unfortunately, Aza Raskin was right when he Tweeted that this kind of “wishy-washy design speak” hampers the fledgling growth of design in open source. We’ve heard criticisms that user experience is just “change for change’s sake,” or that it’s all subjective opinion with no structure behind it. When user experience decisions fail to follow a design process or are described poorly, it does resemble arbitrary change for the sake of change.

However, there’s no excuse for design decisions, in open source or elsewhere, to be arbitrary. While good user experience design does involve creativity and risk-taking, it is not art: it is not left up to the particular tastes of the creator. The goal of user experience design is to solve problems and improve how people interact with technology. The path from a design problem to a solution is one that designers handle differently, but at its core should always resemble the scientific method: a deliberate process that improves and changes based on data. Hugh Beyer and Karen Holtzblatt refer to this as the contextual design process. I’d like to outline the basics of this process as they describe it in their book, Contextual Design. While many variations on this system can be formulated to adapt to various problems, it’s a solid way to approach a design task with a well-defined structure that prevents arbitrary decisions.

Step 1: Contextual Inquiry

In this step, the designer’s goal is to understand the users of the system they are designing. This can be accomplished by interviewing people in the environment they will use the product in to discover who the users are, what problems they face, and what goals they wish to accomplish.

Who are Ubuntu’s users? What kinds of tasks do they use Ubuntu’s window manager for? What do we know about their current usage of Ubuntu’s window manager? What problems are they currently facing? Why are they facing these problems? Let’s sit down with users and find out who they are and what their current experience with Ubuntu is like.

Step 2: Work Modeling

At this step, the designer analyzes what he has learned in the Contextual Inquiry stage. Now the users and their world are known, but this information is often intangible; creating data models that represent the users’ world help identify its structure, successes, and failures. In practice, the most important part of modeling this information is identifying “breakdowns” – places where users encounter problems or frustrations. At Carnegie Mellon’s HCII, we identified these on our models with big red lightening bolts: they are the key towards successful redesign, because they show where the current system is failing the user.

Now that we know Ubuntu’s users and have modeled their work, what breakdowns do they experience? Where in users’ workflow do inefficiencies and frustrations occur? What slows users down and makes their window management a poor experience?

Step 3: Work Redesign

It’s tempting in tech to jump to a technical solution to a problem, but this misses the mark. It is the user’s workflow where problems were identified, and this is the first place to look to solve them. The designer should now identify how the workflow can be improved structurally to avoid breakdowns. Shelley Evenson recommends making storyboards at this stage; drawing the user a new workflow that fixes the structural problems identified.

Now that we’ve identified how Ubuntu’s users’ workflow is impeded by the current design of the window manager, how could this workflow be improved? How could particular window management tasks be improved?

Step 4: User Environment Design

Now that the designer knows how users’ workflow can be improved, it’s time to look at the function and system that he’s designing for. At this stage the designer must decide how the parts of the system work together from users’ point of view. While a system will have a defined technical structure, what users mentally model the system to be is different and more relevant to them. How the system is presented to users should be explicit and distinct from the system’s technical structure.

From the point of view of users, what are the relevant parts of Ubuntu’s window manager and how are they related? How will users understand the various control and window functionality within the system of their Ubuntu desktop?

Step 5: Mock-up Solutions and Test Them

At this point, how users’ experience can be improved structurally has been identified. It’s time to apply that understanding to actual design solutions. This should begin as rough sketches which should be tested with users at very early (or low fidelity) stages. Some designers even begin testing when all they have are paper sketches, having a participant pretend they are using an actual system while the designer moves paper to simulate one. In this way, problems and successes are identified early. That information should guide the design as it becomes higher and higher fidelity. At each stage, user testing should refine the design, and the design should respond to this data and become more solidified at each pass.

Here’s five sketches of how Ubuntu’s window manager can be improved: time to test them with actual users. With these results, perhaps quick prototypes can be banged together in JavaScript, Flash, etc. Once we’ve done user tests with those, it should become clear which design directions are performing best.

Step 6: Ship it! But Consider your Community

The designer has now done the research, the design, the testing – it’s time to get this thing implemented and out the door. But now the designer must carefully consider their organization, community, or company. Every change to a system that people use will create pain, anger, and force users to relearn their habits. It should never be done lightly or curtly. In open source, we have the advantage of transparency. Rather than waiting until Step 6 to debut the design, we can and should be talking openly about it all along. But it’s especially at this stage, when the decision is made, that being respectful of the community is crucial.  A designer can expect that a design won’t be popular just from a screenshot, so explaining the process above – the rationale, the research, the work, the decision-making – is the way to show the design decision is far from arbitrary. A designer in open source can follow the most rigorous and careful design process imaginable, but if they blog saying “Here it is, you’re welcome,” the community has a reason to be upset.

Knowing what I do about Ubuntu users and the Ubuntu community, how can I explain the design decisions that have been made? How can I talk about the relevant points of my design research and process so the users know that this decision has been made in a sincere attempt to improve their workflow? How can I argue successfully for my design, knowing that users will be upset at having to change their work habits?

So, that’s the roughly contextual design process as Beyer and Holtzblatt describe it. Yes, this process is highly formal and structured, and few designers out of school follow it exactly to the letter. However, serious user experience designers use variations on this process for their work. The decisions they make should never be or appear arbitrary.  Designers should be constantly trying to understand users, design for those users, and determine if a design is successful through testing with users.

I hate to call out Majic in particular here, but I did want to highlight that more goes into successful user experience design than her post suggested. And indeed, this might just be a problem of communication: a rigorous design process may have been masked by sloppy language. Given that (in my opinion) Ubuntu’s user experience has been blossoming and improving by leaps and bounds over the past few years, I suspect that Majic and the rest of her team do indeed follow successful design practices. But especially in open source, designers need to carefully consider the implications of what they publish. I should know this, because I’ve said some stupid things in my blog and have been rightly called out on them. Designing in open source is a new animal, and we’re only starting to find effective ways to harness the incredible power of open source communities towards improving user experience. But if a designer makes a decision that appears arbitrary, you have every right to call them out on it. It’s not enough to design well: designers must successfully argue for their designs and the rationale behind them.