Beyond the Pile of Knobs
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Wagner, Eileen
This case study of NoScript’s UX redesign showcases tried and true design principles that make security tools usable to a wider range of audiences. Open source security tools are often associated with customizability and transparency: users are given many options (configurations, self-hosting), and system states are more often than not visible to users (detailed connection info, logs). Sometimes, that means bulky user interfaces and technical language, making an otherwise useful and recommended tool less usable for non-technical audiences. This presents a distinct design challenge: is it possible to build tools that are more usable without compromising on customizability and transparency? In this talk, we will present some UX design principles based on our work with NoScript, a browser extension that allows users to fine-tune their script blocking in Firefox and Chrome/Chromium. We will focus on 1) understanding the value you add for your users, 2) choosing sensible default options, and 3) updating interface language for a wider audience. In the course of that, we will also present our process of human-centered design for improving security tools. (Outlined here:-we-do/usable-security-audit/ )
 Welcome to the next talk. This next talk is going to be in English, but the next talk is going to have a French translation. So, the next presentation will have a French translation. So especially if you're watching the live stream or the recording later on, feel free to switch the audio track to French. A couple of announcements before we start the actual talk is please don't steal the toilet brushes. They are needed on the toilets and the worlds. Additionally, please don't smoke in any of the tents. Smoking is strictly prohibited in all of the tents. All right, since we're right on time to start this next talk, I'm going to keep this introduction short. I'm very happy to introduce to you Molly Wilson and Eileen Wagner, who are going to talk about beyond the pile of knobs redesigning NoScript UX. It's always very interesting to see these security tools evolve when it comes to usability and user experience. So I'm very happy to see this progress in that area. So I'm very much looking forward to see what Eileen and Molly are going to talk about. Please welcome them with a one round of applause. Thank you. Hi. Thank you so much for coming. We're really excited to present what we're calling beyond the pile of knobs a design case study. We're going to talk about how we redesigned the UX of NoScript, browser, content blocking extension, but we're not just talking about NoScript. This is a case study that we hope points to design tools and processes that are useful for a lot of different open source projects and particularly projects that are really complex and are geared towards power users. So hi, I'm Molly. I'm Eileen. And this is our teammate Lorraine. She can't be here with us. She's in Toronto. Hi, Lorraine. Hi. Hi. We, first question you may have when we redesigned NoScript is what about that logo? The NoScript logo is famous. It's an icon. It's been around for a while. Well, ladies and gentlemen, new NoScript logo. Hey, yeah. Same S, new facial expression. I don't know. This is how the NoScript UI used to look. Very small text. Looks a little bit outdated. It's not super consistent. New UI. Whoa. Great scale. Consistency. Rounded corners. You might call it clear, clean, kind of modern, right? Wow. Looks good. Yeah. We're very pleased with ourselves. This is the least important part. When we talk about design, making it look nicer is not what we are talking about. That's the icing on the cake. That's what you can do once you have done all of the other steps that we're going to talk about. We're not talking about the UI changes. We're talking about the deep methods and processes that you need to use before you can even embark on doing that. So we're going to show you really how we got there and present tools and methods that you too can use for designing open source projects. Right. But before we do that, just a couple of words about why we're doing this. The first answer is no script is great. No script is awesome. No script today. It's been around for some time now. It was born in May 2005. So it's one of the older browser extensions out there. It currently has 1.5 million users on Firefox, 50K users on Chrome growing, plus of course all of the poor browser users, which last time I checked was around 2.5 million officially. Of course, a jamming key. Here we go. Can you help me out there? Thank you. It's not just used by what we think of privacy advocates, activists, researchers. It's actually used by governments and corporations alike. A lot of the people that we reached out to during our testing phase, for example, were working for governments. Of course, what also happens is the clicker doesn't work. Should we just do this instead? What also happens is no script has actually contributed to a lot of other security browser extensions, such as HTTPS everywhere. It was the first and is now, in fact, also the only protection, the client side protection you have against cross site scripting attacks. And the last thing I want to mention here is Douglas Crockford, who is a main contributor to JavaScript itself, who actually invented the JSON format, also recommends using no script. So no script is not something that people who hate JavaScript use. No script is something that people who love JavaScript also use. The things that... Maybe not that. Yeah. Let's just... The challenges for no script that we see are not just challenges for no script. They're actually pretty common for a lot of projects we see in the free and open source software scene. No script is run by one developer and a whole community of enthusiastic users. So it's one person who built this at some point and then a lot of people start talking about it and giving feedback. It also is started by someone who mainly built it for himself. He says, I built it for myself and I will always make it work for me first. That's where a lot of the projects we work with actually come from. What they also think is, I want everyone to use these tools. Everyone deserves the privacy and security that I have. So a lot of fast projects want to be there. But of course there is a tension, right? Because if you're always building for yourself first, then how can you make sure everyone else is using it when everybody else has very different needs and is not necessarily a developer? So what happened a lot is there were a lot of feedback and future requests. There's things that came in over the years that were really unstructured. And no script changed based on these unstructured feedback and was adapting to it very quickly. Over again, 14 years, it has developed into a huge project that has many different aspects to it that don't necessarily connect as smoothly as you would want it to. So what it actually leads to is something that Molly called it. So they called it McMansion design. I'm from the US and in the US we have this genre of house called a McMansion, which is basically a house with design feature creep. It's like, I want this feature. I want this one. I want this one too. And you end up putting all of these features on, making your house as big, ostentatious and feature rich as possible. But the whole thing together doesn't look good and maybe isn't even that usable. There's this great blog called McMansion hell that points out how exactly this works in architecture. Here we got, pretty sure this window opens up to either nothing or a very short and tiny room. Hey, we have some space left over. Why don't we attach a smaller, yet uglier house? If you also are a fan of good and bad architecture, definitely check out McMansion hell. So there's not an option not to design whatever you're working on. There is no such thing as no design. When you are building it, you are also designing it. So what we'd like to introduce is the process, the methodology, the method behind the madness that we use to make design make sense overall. Here's what our process looks like in four big steps. First we research. We learn about the problem space. We learn about the existing tool, about the community, about the people who use it. What do they need? What's going on there? And then we synthesize that down to a statement that clarifies what is it we're actually going to do, what are the core problems we're solving, and what is not so important to solve right now. This is also about prioritization. Then we prototype. And that prototyping is often rough, quick, dirty. We want to do this as cheaply and quickly and iteratively as possible, and then usability testing, test with users. So it's really important that this goes fairly fast. It's important that this is not actually super expensive. And it's really important that this is centered on the community. It's centered on the users. So we focus on user needs by conducting user interviews at the beginning, by doing usability tests at the, as soon as we have a prototype to test, and getting rich qualitative feedback throughout. Our goal is that this tool makes sense to people. Why are we building it? Because we want people to be able to use it. We want to know what do people want, what do people need, and what can people actually use. So for example, in our interview phase, we interviewed two novice users and four power users. Our classification, not theirs. And we got rich qualitative feedback. Ample, one of our novice users said, if I hadn't found the right thing to try to turn off after the second try, I am just going to turn no script off. One of our power users described how they rely on no script. No script is the last line or defense in my browser. I trust it to be working in my interest at all times. This is a lot more than we would have found out from asking people, do you like no script? Yes, no. Giving them a survey, collecting some kind of data, which no script doesn't do and will never do. This is why we chose to focus on this rich qualitative feedback with actual people. We then analyzed that by collecting these quotations and putting them on a virtual post at Noteboard. We organized them by theme. We figured out what we thought where we did some prioritization, talked more about that in a bit. And we built rough prototypes going from paper to wire frames to sort of a click through prototype that gives you an idea of the interaction. We tested this with four people in total at different stages. We gathered feedback. And that's how we did it. How we want to dive more into what we did and specifically how this looks for no script. If you're thinking, yeah, user-centered design process, I've heard that before, but it's not applicable to us. This is too complicated. This is too technical. This is for power users. This is exactly what no script is. So we're going to show you how this works in that context. First we're going to talk about framing. So what does this tool do and who does it do that for? First it was important for us to understand what kind of content blocking actually exists already. The landscape of browser-based content blocking is pretty big, pretty crowded, which is a good thing. We think that, you know, should be the case. This would have looked very different 10 years ago. So we've got ad blockers where the goal is to deliver a cleaner, like end user experience without ads. We've got privacy where the goal is to have less tracking of your personal web browsing behavior. We've got security where the goal of these tools is preventing malware. And we've got reducing cruft, which is sort of a more efficient experience, making, for example, just faster load times and, yeah, eliminating unnecessary, loading unnecessary scripts. Something like privacy badger is in a very different space from no script. No script is kind of alone in this area of it helps with security and also just helps make a more efficient browsing experience. Once we realized that was what it was doing as opposed to a lot of the other things people might conflate it with if they didn't know too much about it, we put together three different personas. And these personas are like aggregates of people that we talk to. The reason we're not using actual people? Well, first of all, we promised them confidentiality. This lets us aggregate the data and not, and protect the actual details of the folks we talk to. Some of them work in rather sensitive places. But also it gives us an idea of the kinds of people who might somehow be attracted to no script. We didn't include anything for no script. What's that? I don't even care. Everybody can see everything. Like, that's just, that's not relevant here. So starting with Rose, the super user. Rose is somebody who uses no script because it makes her feel safe online and not using no script makes her feel exposed online. She's a security trainer as well and recommends no script selectively to people who can cook and cope with having this much control. For many people, she says it's just too interactive. It's too much. Emil, the privacy advocate. What about his use of no script? He advocates tirelessly for no script. He tells everybody to use no script. But he does not use it all the time himself. He does not use it if pages break too frequently. He turns it off and then leaves it off for a while. And he really, really wishes it were easier to use because he's going around telling everybody else to use it. He knows it's the best. His words. Next. Chris the curious. Chris the curious is kind of generally paranoid, does not trust big tech, really does not like the idea that he's being tracked online, really does not like seeing ads. However, he tried no script once. He could not figure it out and he uninstalled it. He would love no script to decide which scripts are unsafe and block them automatically. He doesn't like having to make this decision every time a page loads. So who do we prioritize? It might be important to know that no script is never, ever going to provide a block list. That's just not something this tool does. No script is absolutely not interested in collecting user data and really not interested in using any kind of machine learning on aggregated data to be smart. No script is going to be dumb. No script, that's part of its DNA and will always be the case. So who is no script for? No script is for Rose the super user. It's not for everybody. And we made the decision fairly early on to de-prioritize these other users. Next. So what is, what is no script really doing for whom? It keeps you safe. Nah, not really. Not if you don't know how to use it. What about no script makes safe browsing easy for everyone? For those other two personas, probably no script is not actually the way to keep them the safest because of their knowledge and behavior. Next. Does it make safe browsing easy for power users? No, I wouldn't say no script makes anything easy. What does no script do? It buys power users time to make informed decisions about who they trust. You really need to know this in order to do a good job designing it. So no script is a tool for power users. It's a tool for creating friction rather than removing friction. It is strict by default. And it is a tool that you have to interact with every time from the beginning. It's not a set and forget kind of tool. This makes it basically the Sven Markhart of content blocking. Mic is off. Switch mics. Should we switch mics? Yes. Wonderful. We have another microphone already, I think. It's number two. Yes. Wonderful. Thank you so much. So now that we know who no script is for, our next step in this process was asking the question what does Rose, the power user, actually need? And this part, it's kind of funny. People always think, oh, it's a power user. So transparency. We need to know all the things. Information needs to be there and visible. Customizability. All the things need to be able to be changed. Because we have a power user here. Well, that may be true, but it's really no excuse for this. This is what our friends Susan Farrell would call a pile of knobs. When I am trying to configure something, I don't want to be confronted with a pile of knobs. And let's just take this idea of customizability kind of to the logical conclusion, which is offer everybody all the options. So let's think about what these options are. So here's what a person needs to understand, a power user needs to understand to use no script. Look at those red words. Those are the things, the elements of this tool. When you visit a site, it can load a script. These scripts can be from the site you visit or from a different source. We call these different sources the script owner. That's number three. With no script, you can decide on what gets loaded into your browser. You can block or allow scripts. Deciding about what to block, how to block it, that requires a lot of knowledge about scripts and their owners. So you have three kind of base elements, and then you have two action verbs on top of that. And then you have a bunch of background knowledge. So let's say we're visiting the New York Times. This is actually from the New York Times. I picked out seven scripts that you could actually load into your browser when you visit the New York Times. You can see there's NewYorkTimes.com, static01.NewYorkTimes.com. That's the first-party scripts. Scripts actually owned by New York Times. Note that NYT.com is also owned by New York Times, but the URL is actually not exactly the same one. And then we have some Google products. We have news.google.com. We have Google tag manager.com. Again, not the same URL. And some people might know that DoubleClick is also owned by Google, right? So that's all the Google infrastructure you see. But then there are also types of script. You know that the first three might probably be content. And then after that, we probably have some trackers. DoubleClick is definitely an ad-serving script, and optimistically does A-B testing. Again, things you could know if you looked it all up, but you wouldn't actually know it if you're just looking at the interface. All right. That's the background knowledge we all need. But then there's also different ways of thinking about scripts, right? No script itself comes with eight different types of script, right? It categorizes normal JavaScript, and then you have all the media contents, the video is on, and audio files, object, frame, font, WebGL, fetch, other. These are all the different types of scripts you can actually load into your browser. Well, and not all of the script owners might have them, right? So perhaps you want to say, oh, I kind of want to block scripts from news.google.com, and WebGL coming from New York Times.com, whatever. I have all the options. Now if you think about these eight different types of scripts, and let's say you have n scripts on a site, you actually have eight n options, right? That's a matrix. That's a matrix of eight n options. And in fact, if you think about the possible combinations of those, again, taking block and unblock as the two dimensions you can work in, you have two to the power of eight n. That's like all the different combinations you can have of blocking scripts. Again, New York Times doesn't have just seven scripts. It has 27. So you have 260 options just going on a site. That's not what we want to be confronted with. Of course, some of these options are going to be more salient than the others. So maybe I only want to block everything coming from news.google.com. Maybe I only want to block frames. Maybe I only want to block things that are not first party or affiliated. Maybe I want to block or allow everything or nothing because I trust New York Times completely. There are many different ways to carve out this logical space. And it's not clear at all what are the most salient ways to do that. All right. On top of that, it's not just blocking and non-blocking. We can do blocking by location. We can have blocking for this tab, for this whole window. We can have blocking time-based blocking for this session only, for the next five minutes, for this week, forever. We can have other things. It's on my work device. So I'm going to block. I'm going to be a little bit more careful about what I allow on my work device. Perhaps I want to say only these sites get blocked with those scripts. And those sites I don't care about. Possible too. So before you know it, you're just visiting a site and you're just trying to see some content. And before you know it, you're playing a game of set. I don't know how many of you know the mathematical game. But you're calculating five, six, seven different dimensions of blocking. And really what you want is you just want to see the site. And that's not even fair to our power user. So what we did here, instead of thinking about possible options, is we started thinking about scenarios. Scenarios of using a tool like NoScript. So we identified five different scenarios for when NoScript could come into play. One is normal browsing. So you're just, again, reading a new site. One we call quick browsing. So say you're making a payment online and things have to happen right the second and everything just has to work, you don't care about scripts or whatever. The other one being we call dirty browsing. You're visiting a streaming site and you know everything on that site is going to be really, really evil. So you just want to be most careful about everything. Social media use. So there is a case where let's say you want to block Facebook on all the sites you visit, except for, of course, when you are visiting facebook.com where you need content from facebook.com. So kind of like a site-based blocking scenario. And then the last one is visualization itself. This is also something we found out from user research. So a lot of people use NoScript just to see how many scripts are on a site. That's something we didn't know before and we realized that, oh, actually the visualization component is just as important as the blocking function. Now based on those scenarios you can kind of think about different task flows. So this is how NoScript wants you to use the tool. You go to a site. Does the site work? Yes. Yay. Awesome. No, it does not work. Okay. Well, you have to enable individual scripts. Start with one, go with another, reload, see if it works. Does it work? Doesn't work? Try it again. Of course, what most people do is either they say, well, whatever, I really trust this site. Just load everything. YOLO, it will be fine. Or they go to the other extreme, which is I never wanted to see this site anyway. I'm just going to close it. So basically kind of a defeat position, right? Another thing we found out in our user research is that people actually have a shortcut, which is trust affiliated scripts. You hope it works. When I say affiliated, I mean kind of everything that's first-party-ish. Can we just go back one? I want to say, nowhere in this process, right, do you actually appreciate NoScript? Because when a site works, you say, yay, good site, no weird JavaScript stuff. When it doesn't work, you say, no script is blocking everything. No script interaction is by default frustration, right? There's just no way around it. It's always going to bad, like, damn you, no script. And thank you, no script, but damn you, no script, right? There's always going to be that feeling. And how can we design something that makes the feeling just a little bit less awful? Well, we tried. So if you look at the old UI, it has a bit, you know, you have the list of scripts, and then you have the options to the left. And then on the top right corner, you kind of have, like, quicker global options, but they're not very prominent because, really, you know, NoScript doesn't want you to do all that. So what we did is, ta-da, new UI, has a couple of things that we added. So first of all, we want to appreciate the kind of quick and dirty scenarios, right? So we have the quick and dirty options. Allow affiliated scripts just means allow first party scripts. And if you have some affiliated scripts that you have saved before, you can do that. Fine tuning happens in the second part, right? There are script settings. You can still see all of the scripts that are loaded here. You can configure the scope. This is something we wanted to do and wanted to make more visible. We have a new feature for site settings. So that means you can save settings for a site that you're visiting. So the whole scenario we were talking about, about Facebook, that's possible now. You can save specific settings for a site that you visit, especially those sites you visit frequently. We wanted to keep the panic button, the power button on the bottom left, because it felt like people sometimes just get too frustrated and wanted to quit everything. So panic button is there if you need it. So that's kind of the core of what we did. We really thought about what are the options, what are the tasks, and what are the things that people really needed to do. But then we also looked at the interface and realized that a lot of the confusion just came from the visuals and the words that were being used in the old interface. So first of all, I should say that's a very common problem. A lot of software has that, right? There's a lot of technical jargon, inconsistent use of language, super ambiguous icons. This is from a classic Apple design, you know, have a little bomb and then next to it you say, sorry, bomb, sorry. So what's the message here, right? It's very unclear. So these are all things that we see in a lot of projects, and again, NoScript is no exception. But I want to point to some specific and I find interesting issues that we came across with NoScript's interface language. The first one is colors. So here's a design question. Should blocking be green? Good. Do that, go, right? Or should it be red, which we associate with bad? Don't do that, stop. Well, if you go with the intuitive gloss, it should be, let me go back one. It should be go is green, right? So allow is green. Stop is red. Block is red, right? Go stop, allow block. If you think about scripts, though, well, good scripts you want to allow. Bad scripts you want to block. Hmm, okay. I guess block should be red maybe. But then NoScript also really wants to recommend usage. A good security practice means block everything. Don't allow anything. That security practice means allowing everything. And now you're in the position where block is red for some people and green for other people. And that's just not a good place to be when you're trying to use colors here, right? It's only going to confuse people. No matter what you think the color means, people will always think it means something else. So here's a situation where we said, okay, we don't want the red-green combination at all because that's only going to confuse people. I should also say, of course, color shouldn't be the only indicator when you're designing things, right? We want to make things accessible. So color is always going to be used with caution when you're designing things. Okay. The other thing that we found with the language is also really interesting. So a lot of interface language had double negatives in it. So something like disable restrictions globally. And that really, that's what I mean with the mental model, right? You're computing again. Disable restrictions globally. So there are restrictions first, which is already kind of a negation. And then you can enable or disable them. Okay. So you have to kind of do two logical operators there. Okay. Well, that just requires some thinking. But then there's also technical and social concepts that kind of get conflated. And I was talking up until now about blocking and allowing, but no scripts interface actually uses trusted and untrusted. And again, this is the same issue, right? You're actually there's the blocking and allowing on the technical level and the social thing is the trusting and not trusting something. And the question here is, well, if I'm allowing something, do I really mean that I trust it? Maybe not. But maybe I just need to allow it for now because I need to make an online payment. Are you making me feel bad? Right? So there's a lot of technical and social things that may or may not overlap. And sometimes, especially when you're designing for power users, it's probably better to just stick to the technical concept. The last thing I want to mention here is the tone. This is something we found out in the user research. So again, we're looking at disabled restrictions globally. Parentheses dangerous. Now this novice user we had just installed NoScript. And they looked at us and were like, five minutes ago I was browsing without it. Putting dangerous here makes it sound like it's life threatening. Yeah. You want to be a parent sometimes, but sometimes you just got to let people do their own thing. So what we did instead, we changed the tone. We wanted to keep this idea of NoScript is making security recommendation and is also sufficiently warning you when you are in a bad place. But we wanted to do it a little bit more tongue in cheekly. It was supposed to be, it's not, don't do this. You're in a dangerous territory. But NoScript has turned off. Good luck. You're on your own here. So yeah, I think that concludes my part about language. And Molly. Yeah. So if you would like to do any of these things for any project that you were working on, no matter how logically inconsistent or complex or power user driven, that tool might be. We want to provide you tools so that you can also go through a design process and hopefully make that tool that you have poured so much energy into the community, the development actually makes sense to the people that you need it, that you not just want, but like need it to make sense to. We have put together a lot of different templates, resources, methods that you can use. And in the spirit of FOSS, we want to put it online, make it available for free. So this is a persona template that we've developed that's particularly geared around privacy security and human rights protecting technology. That's on our website. There's also another template that is geared towards tech tools, but not necessarily privacy and security. What you put in a persona does kind of depend on the sort of tool that you're designing. So we have a few different templates. Another thing that we have, that we've posted is a value proposition generator. I know the word value proposition sounds really businessy. But this means is what is your thing do and for whom does it do that? It can't do all of the things for all of the people that doesn't exist. What are you actually trying to do and who is it for? And this can help you focus, prioritize, and make sense of all the like constant feedback, feature requests, whatever that you are, I'm sure getting. And you know what? There's a lot more, but we're not going to use the talk time to walk you through all of them because first of all, you can ask us. And also, we hope some of it's self-explanatory. This is the website, simplysecure.org slash ux minus starter minus pack. And we'll also be, I'm sure, adding to it in the next few days as well. Remember, there is no such thing as not doing design. You can't say, no, no, no, we don't do design, whatever decisions you're making, our design decisions. So make them with some kind of system, make them with some kind of method. We also wanted to be transparent about how much this costs. We really like the human-centered design process that we use because it can be really lightweight and really cheap and available to a lot of people. We don't think you should have to hire a fancy-ass design agency to do this. But this was not easy. This took some time. And here's what it took. About one month of full-time work for two people, Eileen and Lorraine. I helped two. So maybe month, month and a half. Lorraine is a visual designer, the UI and the icon that you saw that was Lorraine's work. I'm not a designer. Eileen's not a designer. So don't you be saying, I'm not a designer. I can't do this. Additional costs. We use the tools we use. Sketch is a, we use that for making drawing wireframes that's like a vector drawing software. Whimsical, we used for online collaborating on wireframes. Notion, we used, Whimsical was also for like collecting all of these sticky notes. We tried some open source tools. They did not have the features that we needed for this project. So hi, somebody please make an open source tool that has the features that Whimsical has. We would love it. We would use it and we would talk about it all the time. Notion we use for our internal collaboration. JITSE we use for remote user testing and also internal collaboration. And tons of paper sticky notes. Those are not cheap. There's also research compensation. We thought it was really important to at least offer compensation to everybody who helped us. A lot of people did choose to donate that given the nature of the project. But we, it's really important to us that we were able to offer that. CASEY Well I should also say this work was not possible without the support of the Open Technology Fund. But more than, more than anybody else we need to thank Giorgio for letting us play around with no script. Giorgio. It's really hard when you've been working on a tool for 14 years and it's your baby and just to give it to someone else for like a month and a half to work on. That's really hard. And thank you so much for being open and letting us play around with it. CASEY This presentation is dedicated to you. Thank you Giorgio. Giorgio. Yes. And yeah, I think that's it. I think, so we're going to be here the rest of the week. If you have any questions about design about this work or about our work in general, you know, just ping us. Yeah. CASEY We will help you with design, whatever that means to you, whatever that means to your project. Giorgio. Yes. CASEY Yeah. All right. All right. Thanks so much already Eileen and Molly. We have a couple of minutes left for questions. So if you have a question for either one or both of them, please come to one of the microphone angels at the front or in the back and ask your question. I think we will start with the lovely person in front. Giorgio. Thank you. Thank you so much for the presentation. I was just wondering like, because I feel like lots of people's first interactions with NoScript came through like using Tor. So I was like, at what point in the process do you think about sort of how different tools interact with each other and do you have to create like a special persona for that or how does that go? CASEY For control in general or for Tor? Giorgio. No, for like tools that interact with each other, for example NoScript and Tor. CASEY Right. Because it's yeah. Giorgio. So that was super important because we know that. CASEY You might restate the question. Right? Was that in the microphone? Can we? Giorgio. Was the question captured? Yeah. Okay. Okay. So that was a really good question because a lot of NoScript users are involuntary NoScript users because they're using Tor. We started the whole process by actually interviewing people on the Tor design team. Shout out to the Tor design team. Awesome work by the way. Yes, exactly. So we interviewed them and we talked about some of the issues that might come up. There is a whole project that is integrating NoScript into Tor and they're actually thinking about not showcasing any of the UI at all, which I think is a totally reasonable solution to the thing. You're going into the background settings and changing very detailed things. Maybe things are going to be different depending on the new UI and how it's implemented. But yeah, that's going to be a real project. CASEY In general, you absolutely should find out what other tools fit in people's workflow. You want to ask people what browser they are using. You want to find out what OS they are using. And if you find that it's like there's a huge chunk of people who use Chrome, then you need to take that into account. How it interacts with the other Chrome extensions they're likely to use it with. I would absolutely work that into a persona. All right. Then let's just continue with the question from the front. So, this is a technical question in the UI. I saw allow affiliated sites button. How does that work without any lists? Because for example, the static01.New York Times isn't really connected to the New York Times domain. How does that work? CASEY Yes. That's a good question. Nice catch. So, what we're going to do is by default, affiliated scripts are first party scripts. So, those things that you can definitely read based on the domain. And for the other ones, you can't do it automatically. So, what we're going to do is most likely offer some background. So when you install the next NoScript, it's going to have the affiliated scripts of the 10 most visited sites so that people have less breakage on very basic browsing experiences. And for the rest of them, what we have imagined is actually people being able to import and export their own settings a lot. So when you actually do want to mark something as an affiliated script, you can share that with a wider community of people. So there is that future built in. But the rest of it is all by hand. As we said, NoScript is not a smart tool. It just does what you tell it to do and it does it reliably. Yeah. I was also interested what site specific actually means. Probably the same. It's related to subdomains. Right. So, subdomains of the site, you mean? Okay. Because I think there's also another question about the site specific scripts that are block or not block. So, another way of looking at affiliated scripts is also these are, this is the kind of profile of scripts that I want to allow or block whenever I visit a site. So that's kind of a different but related feature. So another question. You actually had it on the list of related projects. You matrix, I think it actually fits in a kind of similar niche as NoScript does. Have you evaluated like how their user interface is? I mean, it's probably the matrix of a thousand switches that you were mentioning. But to me, it's actually the one I use. And have you checked how you could integrate maybe something like that into NoScript? Yes, you're absolutely right. I think the matrix is what got me thinking about the matrix to begin with. Like the eight N options I was mentioning before. It is super interesting. They're totally similar extensions. I think NoScript does a couple more things than you matrix. But in general, they're the same category of script blockers. To me, the takeaway for me was that, so our job wasn't to evaluate you matrix. But to me, the takeaway was that was actually a little bit too fine-grained for most people, even for power users. Sorry. I was very unspecific with my question. I meant the new feature that you added to save for the site. Or what you called it? Per site settings. Per site settings. Yeah, what it actually means in terms of a URL. Is it like a top level domain, sub level domain, or is it like the full path of the URL? I think right now it's a full path of the URL. So whenever I am on Facebook.com or any sub domain of Facebook.com, things are going to be implemented. Yes. So yes for subdomains. I think right. But these are things that probably, like some of the default options, we're going to like leave up to George to make the decision on that. But the idea, so the funny story behind that, if I can comment on this, is this whole feature is supported by the back end and has been for a long time. The only reason it wasn't implemented was because George couldn't figure out what the UI should look like, given how complicated everything else already is. So this is something we were really excited that we were able to implement. Okay. I think if we hurry up, we have time for one more question in the back. Thanks. Yeah. I was, you mentioned the color. And I was wondering, of course, there are colorblind people that have a disadvantage if you use color for your design, but then there's a whole bunch of people that greatly benefits from colors. And I was wondering if you have some sort of rule of thumb that you use. For example, I don't use colors at all. It's probably not what it is. But maybe there's something like if I use colors, I also use tool X or Y. You always want to be showing necessary information with color in one other dimension that can be positioning, that can be words, that can be icons. You just need to make sure that color is not doing all of the weight. You don't want, for example, to click on a red circle or click on a green circle. Because people don't have the like, in real life, we know that in a traffic light, if the top thing is lit up, it's probably red. If the bottom thing, it's probably green. The interface is new. They've not seen it before. They don't know that the left thing is going to be okay and the right thing is going to be canceled or the other way around. Oh, my God, apps are always switching where okay is versus cancel, where yes is versus no. So just color is great. Do use color and usually green for yes, red for no. That didn't quite work in NoScript because the yes and the no, the bad and the good, the good and evil, the trust and block, like that just didn't, it didn't match up. So we actually didn't use this red, green pairing anywhere. You should feel free to use red, green pairings only when you're sure it makes sense and always use also text or an icon. All right, that concludes the talk. So thanks again, a bunch, Eileen and Molly for the super interesting talk and I'm sure a bunch of people are going to give NoScript another try once they see the new UI. Thanks. Goodbye. Andashi, may you be with us.
 Welcome to the next talk.  This next talk is going to be in English, but the next talk is going to have a French  translation.  So, the next presentation will have a French translation.  So especially if you're watching the live stream or the recording later on, feel free  to switch the audio track to French.  A couple of announcements before we start the actual talk is please don't steal the  toilet brushes.  They are needed on the toilets and the worlds.  Additionally, please don't smoke in any of the tents.  Smoking is strictly prohibited in all of the tents.  All right, since we're right on time to start this next talk, I'm going to keep this introduction  short.  I'm very happy to introduce to you Molly Wilson and Eileen Wagner, who are going to  talk about beyond the pile of knobs redesigning NoScript UX.  It's always very interesting to see these security tools evolve when it comes to usability  and user experience.  So I'm very happy to see this progress in that area.  So I'm very much looking forward to see what Eileen and Molly are going to talk about.  Please welcome them with a one round of applause.  Thank you.  Hi.  Thank you so much for coming.  We're really excited to present what we're calling beyond the pile of knobs a design  case study.  We're going to talk about how we redesigned the UX of NoScript, browser, content blocking  extension, but we're not just talking about NoScript.  This is a case study that we hope points to design tools and processes that are useful  for a lot of different open source projects and particularly projects that are really  complex and are geared towards power users.  So hi, I'm Molly.  I'm Eileen.  And this is our teammate Lorraine.  She can't be here with us.  She's in Toronto.  Hi, Lorraine.  Hi.  Hi.  We, first question you may have when we redesigned NoScript is what about that logo?  The NoScript logo is famous.  It's an icon.  It's been around for a while.  Well, ladies and gentlemen, new NoScript logo.  Hey, yeah.  Same S, new facial expression.  I don't know.  This is how the NoScript UI used to look.  Very small text.  Looks a little bit outdated.  It's not super consistent.  New UI.  Whoa.  Great scale.  Consistency.  Rounded corners.  You might call it clear, clean, kind of modern, right?  Wow.  Looks good.  Yeah.  We're very pleased with ourselves.  This is the least important part.  When we talk about design, making it look nicer is not what we are talking about.  That's the icing on the cake.  That's what you can do once you have done all of the other steps that we're going to  talk about.  We're not talking about the UI changes.  We're talking about the deep methods and processes that you need to use before you can even embark  on doing that.  So we're going to show you really how we got there and present tools and methods that  you too can use for designing open source projects.  Right.  But before we do that, just a couple of words about why we're doing this.  The first answer is no script is great.  No script is awesome.  No script today.  It's been around for some time now.  It was born in May 2005.  So it's one of the older browser extensions out there.  It currently has 1.5 million users on Firefox, 50K users on Chrome growing, plus of course  all of the poor browser users, which last time I checked was around 2.5 million officially.  Of course, a jamming key.  Here we go.  Can you help me out there?  Thank you.  It's not just used by what we think of privacy advocates, activists, researchers.  It's actually used by governments and corporations alike.  A lot of the people that we reached out to during our testing phase, for example, were  working for governments.  Of course, what also happens is the clicker doesn't work.  Should we just do this instead?  What also happens is no script has actually contributed to a lot of other security browser  extensions, such as HTTPS everywhere.  It was the first and is now, in fact, also the only protection, the client side protection  you have against cross site scripting attacks.  And the last thing I want to mention here is Douglas Crockford, who is a main contributor  to JavaScript itself, who actually invented the JSON format, also recommends using no  script.  So no script is not something that people who hate JavaScript use.  No script is something that people who love JavaScript also use.  The things that...  Maybe not that.  Yeah.  Let's just...  The challenges for no script that we see are not just challenges for no script.  They're actually pretty common for a lot of projects we see in the free and open source  software scene.  No script is run by one developer and a whole community of enthusiastic users.  So it's one person who built this at some point and then a lot of people start talking  about it and giving feedback.  It also is started by someone who mainly built it for himself.  He says, I built it for myself and I will always make it work for me first.  That's where a lot of the projects we work with actually come from.  What they also think is, I want everyone to use these tools.  Everyone deserves the privacy and security that I have.  So a lot of fast projects want to be there.  But of course there is a tension, right?  Because if you're always building for yourself first, then how can you make sure everyone  else is using it when everybody else has very different needs and is not necessarily a developer?  So what happened a lot is there were a lot of feedback and future requests.  There's things that came in over the years that were really unstructured.  And no script changed based on these unstructured feedback and was adapting to it very quickly.  Over again, 14 years, it has developed into a huge project that has many different aspects  to it that don't necessarily connect as smoothly as you would want it to.  So what it actually leads to is something that Molly called it.  So they called it McMansion design.  I'm from the US and in the US we have this genre of house called a McMansion, which is  basically a house with design feature creep.  It's like, I want this feature.  I want this one.  I want this one too.  And you end up putting all of these features on, making your house as big, ostentatious  and feature rich as possible.  But the whole thing together doesn't look good and maybe isn't even that usable.  There's this great blog called McMansion hell that points out how exactly this works in  architecture.  Here we got, pretty sure this window opens up to either nothing or a very short and tiny  room.  Hey, we have some space left over.  Why don't we attach a smaller, yet uglier house?  If you also are a fan of good and bad architecture, definitely check out McMansion hell.  So there's not an option not to design whatever you're working on.  There is no such thing as no design.  When you are building it, you are also designing it.  So what we'd like to introduce is the process, the methodology, the method behind the madness  that we use to make design make sense overall.  Here's what our process looks like in four big steps.  First we research.  We learn about the problem space.  We learn about the existing tool, about the community, about the people who use it.  What do they need?  What's going on there?  And then we synthesize that down to a statement that clarifies what is it we're actually going  to do, what are the core problems we're solving, and what is not so important to solve right  now.  This is also about prioritization.  Then we prototype.  And that prototyping is often rough, quick, dirty.  We want to do this as cheaply and quickly and iteratively as possible, and then usability  testing, test with users.  So it's really important that this goes fairly fast.  It's important that this is not actually super expensive.  And it's really important that this is centered on the community.  It's centered on the users.  So we focus on user needs by conducting user interviews at the beginning, by doing usability  tests at the, as soon as we have a prototype to test, and getting rich qualitative feedback  throughout.  Our goal is that this tool makes sense to people.  Why are we building it?  Because we want people to be able to use it.  We want to know what do people want, what do people need, and what can people actually  use.  So for example, in our interview phase, we interviewed two novice users and four power  users.  Our classification, not theirs.  And we got rich qualitative feedback.  Ample, one of our novice users said, if I hadn't found the right thing to try to turn  off after the second try, I am just going to turn no script off.  One of our power users described how they rely on no script.  No script is the last line or defense in my browser.  I trust it to be working in my interest at all times.  This is a lot more than we would have found out from asking people, do you like no script?  Yes, no.  Giving them a survey, collecting some kind of data, which no script doesn't do and will  never do.  This is why we chose to focus on this rich qualitative feedback with actual people.  We then analyzed that by collecting these quotations and putting them on a virtual post at Noteboard.  We organized them by theme.  We figured out what we thought where we did some prioritization, talked more about that  in a bit.  And we built rough prototypes going from paper to wire frames to sort of a click through  prototype that gives you an idea of the interaction.  We tested this with four people in total at different stages.  We gathered feedback.  And that's how we did it.  How we want to dive more into what we did and specifically how this looks for no script.  If you're thinking, yeah, user-centered design process, I've heard that before, but it's  not applicable to us.  This is too complicated.  This is too technical.  This is for power users.  This is exactly what no script is.  So we're going to show you how this works in that context.  First we're going to talk about framing.  So what does this tool do and who does it do that for?  First it was important for us to understand what kind of content blocking actually exists  already.  The landscape of browser-based content blocking is pretty big, pretty crowded, which is a  good thing.  We think that, you know, should be the case.  This would have looked very different 10 years ago.  So we've got ad blockers where the goal is to deliver a cleaner, like end user experience  without ads.  We've got privacy where the goal is to have less tracking of your personal web browsing  behavior.  We've got security where the goal of these tools is preventing malware.  And we've got reducing cruft, which is sort of a more efficient experience, making, for  example, just faster load times and, yeah, eliminating unnecessary, loading unnecessary  scripts.  Something like privacy badger is in a very different space from no script.  No script is kind of alone in this area of it helps with security and also just helps  make a more efficient browsing experience.  Once we realized that was what it was doing as opposed to a lot of the other things people  might conflate it with if they didn't know too much about it, we put together three different  personas.  And these personas are like aggregates of people that we talk to.  The reason we're not using actual people?  Well, first of all, we promised them confidentiality.  This lets us aggregate the data and not, and protect the actual details of the folks we  talk to.  Some of them work in rather sensitive places.  But also it gives us an idea of the kinds of people who might somehow be attracted to  no script.  We didn't include anything for no script.  What's that?  I don't even care.  Everybody can see everything.  Like, that's just, that's not relevant here.  So starting with Rose, the super user.  Rose is somebody who uses no script because it makes her feel safe online and not using  no script makes her feel exposed online.  She's a security trainer as well and recommends no script selectively to people who can cook  and cope with having this much control.  For many people, she says it's just too interactive.  It's too much.  Emil, the privacy advocate.  What about his use of no script?  He advocates tirelessly for no script.  He tells everybody to use no script.  But he does not use it all the time himself.  He does not use it if pages break too frequently.  He turns it off and then leaves it off for a while.  And he really, really wishes it were easier to use because he's going around telling everybody  else to use it.  He knows it's the best.  His words.  Next.  Chris the curious.  Chris the curious is kind of generally paranoid, does not trust big tech, really does not like  the idea that he's being tracked online, really does not like seeing ads.  However, he tried no script once.  He could not figure it out and he uninstalled it.  He would love no script to decide which scripts are unsafe and block them automatically.  He doesn't like having to make this decision every time a page loads.  So who do we prioritize?  It might be important to know that no script is never, ever going to provide a block list.  That's just not something this tool does.  No script is absolutely not interested in collecting user data and really not interested  in using any kind of machine learning on aggregated data to be smart.  No script is going to be dumb.  No script, that's part of its DNA and will always be the case.  So who is no script for?  No script is for Rose the super user.  It's not for everybody.  And we made the decision fairly early on to de-prioritize these other users.  Next.  So what is, what is no script really doing for whom?  It keeps you safe.  Nah, not really.  Not if you don't know how to use it.  What about no script makes safe browsing easy for everyone?  For those other two personas, probably no script is not actually the way to keep them  the safest because of their knowledge and behavior.  Next.  Does it make safe browsing easy for power users?  No, I wouldn't say no script makes anything easy.  What does no script do?  It buys power users time to make informed decisions about who they trust.  You really need to know this in order to do a good job designing it.  So no script is a tool for power users.  It's a tool for creating friction rather than removing friction.  It is strict by default.  And it is a tool that you have to interact with every time from the beginning.  It's not a set and forget kind of tool.  This makes it basically the Sven Markhart of content blocking.  Mic is off.  Switch mics.  Should we switch mics?  Yes.  Wonderful.  We have another microphone already, I think.  It's number two.  Yes.  Wonderful.  Thank you so much.  So now that we know who no script is for, our next step in this process was asking the  question what does Rose, the power user, actually need?  And this part, it's kind of funny.  People always think, oh, it's a power user.  So transparency.  We need to know all the things.  Information needs to be there and visible.  Customizability.  All the things need to be able to be changed.  Because we have a power user here.  Well, that may be true, but it's really no excuse for this.  This is what our friends Susan Farrell would call a pile of knobs.  When I am trying to configure something, I don't want to be confronted with a pile of  knobs.  And let's just take this idea of customizability kind of to the logical conclusion, which is  offer everybody all the options.  So let's think about what these options are.  So here's what a person needs to understand, a power user needs to understand to use no  script.  Look at those red words.  Those are the things, the elements of this tool.  When you visit a site, it can load a script.  These scripts can be from the site you visit or from a different source.  We call these different sources the script owner.  That's number three.  With no script, you can decide on what gets loaded into your browser.  You can block or allow scripts.  Deciding about what to block, how to block it, that requires a lot of knowledge about  scripts and their owners.  So you have three kind of base elements, and then you have two action verbs on top of that.  And then you have a bunch of background knowledge.  So let's say we're visiting the New York Times.  This is actually from the New York Times.  I picked out seven scripts that you could actually load into your browser when you visit  the New York Times.  You can see there's NewYorkTimes.com, static01.NewYorkTimes.com.  That's the first-party scripts.  Scripts actually owned by New York Times.  Note that NYT.com is also owned by New York Times, but the URL is actually not exactly  the same one.  And then we have some Google products.  We have news.google.com.  We have Google tag manager.com.  Again, not the same URL.  And some people might know that DoubleClick is also owned by Google, right?  So that's all the Google infrastructure you see.  But then there are also types of script.  You know that the first three might probably be content.  And then after that, we probably have some trackers.  DoubleClick is definitely an ad-serving script, and optimistically does A-B testing.  Again, things you could know if you looked it all up, but you wouldn't actually know  it if you're just looking at the interface.  All right.  That's the background knowledge we all need.  But then there's also different ways of thinking about scripts, right?  No script itself comes with eight different types of script, right?  It categorizes normal JavaScript, and then you have all the media contents, the video  is on, and audio files, object, frame, font, WebGL, fetch, other.  These are all the different types of scripts you can actually load into your browser.  Well, and not all of the script owners might have them, right?  So perhaps you want to say, oh, I kind of want to block scripts from news.google.com,  and WebGL coming from New York Times.com, whatever.  I have all the options.  Now if you think about these eight different types of scripts, and let's say you have n  scripts on a site, you actually have eight n options, right?  That's a matrix.  That's a matrix of eight n options.  And in fact, if you think about the possible combinations of those, again, taking block  and unblock as the two dimensions you can work in, you have two to the power of eight  n.  That's like all the different combinations you can have of blocking scripts.  Again, New York Times doesn't have just seven scripts.  It has 27.  So you have 260 options just going on a site.  That's not what we want to be confronted with.  Of course, some of these options are going to be more salient than the others.  So maybe I only want to block everything coming from news.google.com.  Maybe I only want to block frames.  Maybe I only want to block things that are not first party or affiliated.  Maybe I want to block or allow everything or nothing because I trust New York Times completely.  There are many different ways to carve out this logical space.  And it's not clear at all what are the most salient ways to do that.  All right.  On top of that, it's not just blocking and non-blocking.  We can do blocking by location.  We can have blocking for this tab, for this whole window.  We can have blocking time-based blocking for this session only, for the next five minutes,  for this week, forever.  We can have other things.  It's on my work device.  So I'm going to block.  I'm going to be a little bit more careful about what I allow on my work device.  Perhaps I want to say only these sites get blocked with those scripts.  And those sites I don't care about.  Possible too.  So before you know it, you're just visiting a site and you're just trying to see some  content.  And before you know it, you're playing a game of set.  I don't know how many of you know the mathematical game.  But you're calculating five, six, seven different dimensions of blocking.  And really what you want is you just want to see the site.  And that's not even fair to our power user.  So what we did here, instead of thinking about possible options, is we started thinking  about scenarios.  Scenarios of using a tool like NoScript.  So we identified five different scenarios for when NoScript could come into play.  One is normal browsing.  So you're just, again, reading a new site.  One we call quick browsing.  So say you're making a payment online and things have to happen right the second and  everything just has to work, you don't care about scripts or whatever.  The other one being we call dirty browsing.  You're visiting a streaming site and you know everything on that site is going to be really,  really evil.  So you just want to be most careful about everything.  Social media use.  So there is a case where let's say you want to block Facebook on all the sites you visit,  except for, of course, when you are visiting facebook.com where you need content from facebook.com.  So kind of like a site-based blocking scenario.  And then the last one is visualization itself.  This is also something we found out from user research.  So a lot of people use NoScript just to see how many scripts are on a site.  That's something we didn't know before and we realized that, oh, actually the visualization  component is just as important as the blocking function.  Now based on those scenarios you can kind of think about different task flows.  So this is how NoScript wants you to use the tool.  You go to a site.  Does the site work?  Yes.  Yay.  Awesome.  No, it does not work.  Okay.  Well, you have to enable individual scripts.  Start with one, go with another, reload, see if it works.  Does it work?  Doesn't work?  Try it again.  Of course, what most people do is either they say, well, whatever, I really trust this site.  Just load everything.  YOLO, it will be fine.  Or they go to the other extreme, which is I never wanted to see this site anyway.  I'm just going to close it.  So basically kind of a defeat position, right?  Another thing we found out in our user research is that people actually have a shortcut, which  is trust affiliated scripts.  You hope it works.  When I say affiliated, I mean kind of everything that's first-party-ish.  Can we just go back one?  I want to say, nowhere in this process, right, do you actually appreciate NoScript?  Because when a site works, you say, yay, good site, no weird JavaScript stuff.  When it doesn't work, you say, no script is blocking everything.  No script interaction is by default frustration, right?  There's just no way around it.  It's always going to bad, like, damn you, no script.  And thank you, no script, but damn you, no script, right?  There's always going to be that feeling.  And how can we design something that makes the feeling just a little bit less awful?  Well, we tried.  So if you look at the old UI, it has a bit, you know, you have the list of scripts, and  then you have the options to the left.  And then on the top right corner, you kind of have, like, quicker global options, but  they're not very prominent because, really, you know, NoScript doesn't want you to do  all that.  So what we did is, ta-da, new UI, has a couple of things that we added.  So first of all, we want to appreciate the kind of quick and dirty scenarios, right?  So we have the quick and dirty options.  Allow affiliated scripts just means allow first party scripts.  And if you have some affiliated scripts that you have saved before, you can do that.  Fine tuning happens in the second part, right?  There are script settings.  You can still see all of the scripts that are loaded here.  You can configure the scope.  This is something we wanted to do and wanted to make more visible.  We have a new feature for site settings.  So that means you can save settings for a site that you're visiting.  So the whole scenario we were talking about, about Facebook, that's possible now.  You can save specific settings for a site that you visit, especially those sites you  visit frequently.  We wanted to keep the panic button, the power button on the bottom left, because it felt  like people sometimes just get too frustrated and wanted to quit everything.  So panic button is there if you need it.  So that's kind of the core of what we did.  We really thought about what are the options, what are the tasks, and what are the things  that people really needed to do.  But then we also looked at the interface and realized that a lot of the confusion just  came from the visuals and the words that were being used in the old interface.  So first of all, I should say that's a very common problem.  A lot of software has that, right?  There's a lot of technical jargon, inconsistent use of language, super ambiguous icons.  This is from a classic Apple design, you know, have a little bomb and then next to it you  say, sorry, bomb, sorry.  So what's the message here, right?  It's very unclear.  So these are all things that we see in a lot of projects, and again, NoScript is no exception.  But I want to point to some specific and I find interesting issues that we came across  with NoScript's interface language.  The first one is colors.  So here's a design question.  Should blocking be green?  Good.  Do that, go, right?  Or should it be red, which we associate with bad?  Don't do that, stop.  Well, if you go with the intuitive gloss, it should be, let me go back one.  It should be go is green, right?  So allow is green.  Stop is red.  Block is red, right?  Go stop, allow block.  If you think about scripts, though, well, good scripts you want to allow.  Bad scripts you want to block.  Hmm, okay.  I guess block should be red maybe.  But then NoScript also really wants to recommend usage.  A good security practice means block everything.  Don't allow anything.  That security practice means allowing everything.  And now you're in the position where block is red for some people and green for other  people.  And that's just not a good place to be when you're trying to use colors here, right?  It's only going to confuse people.  No matter what you think the color means, people will always think it means something  else.  So here's a situation where we said, okay, we don't want the red-green combination at  all because that's only going to confuse people.  I should also say, of course, color shouldn't be the only indicator when you're designing  things, right?  We want to make things accessible.  So color is always going to be used with caution when you're designing things.  Okay.  The other thing that we found with the language is also really interesting.  So a lot of interface language had double negatives in it.  So something like disable restrictions globally.  And that really, that's what I mean with the mental model, right?  You're computing again.  Disable restrictions globally.  So there are restrictions first, which is already kind of a negation.  And then you can enable or disable them.  Okay.  So you have to kind of do two logical operators there.  Okay.  Well, that just requires some thinking.  But then there's also technical and social concepts that kind of get conflated.  And I was talking up until now about blocking and allowing, but no scripts interface actually  uses trusted and untrusted.  And again, this is the same issue, right?  You're actually there's the blocking and allowing on the technical level and the social thing  is the trusting and not trusting something.  And the question here is, well, if I'm allowing something, do I really mean that I trust it?  Maybe not.  But maybe I just need to allow it for now because I need to make an online payment.  Are you making me feel bad?  Right?  So there's a lot of technical and social things that may or may not overlap.  And sometimes, especially when you're designing for power users, it's probably better to just  stick to the technical concept.  The last thing I want to mention here is the tone.  This is something we found out in the user research.  So again, we're looking at disabled restrictions globally.  Parentheses dangerous.  Now this novice user we had just installed NoScript.  And they looked at us and were like, five minutes ago I was browsing without it.  Putting dangerous here makes it sound like it's life threatening.  Yeah.  You want to be a parent sometimes, but sometimes you just got to let people do their own thing.  So what we did instead, we changed the tone.  We wanted to keep this idea of NoScript is making security recommendation and is also  sufficiently warning you when you are in a bad place.  But we wanted to do it a little bit more tongue in cheekly.  It was supposed to be, it's not, don't do this.  You're in a dangerous territory.  But NoScript has turned off.  Good luck.  You're on your own here.  So yeah, I think that concludes my part about language.  And Molly.  Yeah.  So if you would like to do any of these things for any project that you were working on,  no matter how logically inconsistent or complex or power user driven, that tool might be.  We want to provide you tools so that you can also go through a design process and hopefully  make that tool that you have poured so much energy into the community, the development  actually makes sense to the people that you need it, that you not just want, but like  need it to make sense to.  We have put together a lot of different templates, resources, methods that you can use.  And in the spirit of FOSS, we want to put it online, make it available for free.  So this is a persona template that we've developed that's particularly geared around privacy  security and human rights protecting technology.  That's on our website.  There's also another template that is geared towards tech tools, but not necessarily privacy  and security.  What you put in a persona does kind of depend on the sort of tool that you're designing.  So we have a few different templates.  Another thing that we have, that we've posted is a value proposition generator.  I know the word value proposition sounds really businessy.  But this means is what is your thing do and for whom does it do that?  It can't do all of the things for all of the people that doesn't exist.  What are you actually trying to do and who is it for?  And this can help you focus, prioritize, and make sense of all the like constant feedback,  feature requests, whatever that you are, I'm sure getting.  And you know what?  There's a lot more, but we're not going to use the talk time to walk you through all  of them because first of all, you can ask us.  And also, we hope some of it's self-explanatory.  This is the website, simplysecure.org slash ux minus starter minus pack.  And we'll also be, I'm sure, adding to it in the next few days as well.  Remember, there is no such thing as not doing design.  You can't say, no, no, no, we don't do design, whatever decisions you're making, our design  decisions.  So make them with some kind of system, make them with some kind of method.  We also wanted to be transparent about how much this costs.  We really like the human-centered design process that we use because it can be really lightweight  and really cheap and available to a lot of people.  We don't think you should have to hire a fancy-ass design agency to do this.  But this was not easy.  This took some time.  And here's what it took.  About one month of full-time work for two people, Eileen and Lorraine.  I helped two.  So maybe month, month and a half.  Lorraine is a visual designer, the UI and the icon that you saw that was Lorraine's work.  I'm not a designer.  Eileen's not a designer.  So don't you be saying, I'm not a designer.  I can't do this.  Additional costs.  We use the tools we use.  Sketch is a, we use that for making drawing wireframes that's like a vector drawing software.  Whimsical, we used for online collaborating on wireframes.  Notion, we used, Whimsical was also for like collecting all of these sticky notes.  We tried some open source tools.  They did not have the features that we needed for this project.  So hi, somebody please make an open source tool that has the features that Whimsical  has.  We would love it.  We would use it and we would talk about it all the time.  Notion we use for our internal collaboration.  JITSE we use for remote user testing and also internal collaboration.  And tons of paper sticky notes.  Those are not cheap.  There's also research compensation.  We thought it was really important to at least offer compensation to everybody who helped  us.  A lot of people did choose to donate that given the nature of the project.  But we, it's really important to us that we were able to offer that.  CASEY Well I should also say this work was not possible  without the support of the Open Technology Fund.  But more than, more than anybody else we need to thank Giorgio for letting us play around  with no script.  Giorgio.  It's really hard when you've been working on a tool for 14 years and it's your baby  and just to give it to someone else for like a month and a half to work on.  That's really hard.  And thank you so much for being open and letting us play around with it.  CASEY This presentation is dedicated to you.  Thank you Giorgio.  Giorgio.  Yes.  And yeah, I think that's it.  I think, so we're going to be here the rest of the week.  If you have any questions about design about this work or about our work in general, you  know, just ping us.  Yeah.  CASEY We will help you with design, whatever that means to you, whatever that means to  your project.  Giorgio.  Yes.  CASEY Yeah.  All right.  All right.  Thanks so much already Eileen and Molly.  We have a couple of minutes left for questions.  So if you have a question for either one or both of them, please come to one of the microphone  angels at the front or in the back and ask your question.  I think we will start with the lovely person in front.  Giorgio.  Thank you.  Thank you so much for the presentation.  I was just wondering like, because I feel like lots of people's first interactions with  NoScript came through like using Tor.  So I was like, at what point in the process do you think about sort of how different tools  interact with each other and do you have to create like a special persona for that or  how does that go?  CASEY For control in general or for Tor?  Giorgio.  No, for like tools that interact with each other, for example NoScript and Tor.  CASEY Right.  Because it's yeah.  Giorgio.  So that was super important because we know that.  CASEY You might restate the question.  Right?  Was that in the microphone?  Can we?  Giorgio.  Was the question captured?  Yeah.  Okay.  Okay.  So that was a really good question because a lot of NoScript users are involuntary NoScript  users because they're using Tor.  We started the whole process by actually interviewing people on the Tor design team.  Shout out to the Tor design team.  Awesome work by the way.  Yes, exactly.  So we interviewed them and we talked about some of the issues that might come up.  There is a whole project that is integrating NoScript into Tor and they're actually thinking  about not showcasing any of the UI at all, which I think is a totally reasonable solution  to the thing.  You're going into the background settings and changing very detailed things.  Maybe things are going to be different depending on the new UI and how it's implemented.  But yeah, that's going to be a real project.  CASEY In general, you absolutely should find out what other tools fit in people's workflow.  You want to ask people what browser they are using.  You want to find out what OS they are using.  And if you find that it's like there's a huge chunk of people who use Chrome, then you  need to take that into account.  How it interacts with the other Chrome extensions they're likely to use it with.  I would absolutely work that into a persona.  All right.  Then let's just continue with the question from the front.  So, this is a technical question in the UI.  I saw allow affiliated sites button.  How does that work without any lists?  Because for example, the static01.New York Times isn't really connected to the New York  Times domain.  How does that work?  CASEY Yes.  That's a good question.  Nice catch.  So, what we're going to do is by default, affiliated scripts are first party scripts.  So, those things that you can definitely read based on the domain.  And for the other ones, you can't do it automatically.  So, what we're going to do is most likely offer some background.  So when you install the next NoScript, it's going to have the affiliated scripts of the  10 most visited sites so that people have less breakage on very basic browsing experiences.  And for the rest of them, what we have imagined is actually people being able to import and  export their own settings a lot.  So when you actually do want to mark something as an affiliated script, you can share that  with a wider community of people.  So there is that future built in.  But the rest of it is all by hand.  As we said, NoScript is not a smart tool.  It just does what you tell it to do and it does it reliably.  Yeah.  I was also interested what site specific actually means.  Probably the same.  It's related to subdomains.  Right.  So, subdomains of the site, you mean?  Okay.  Because I think there's also another question about the site specific scripts that are block  or not block.  So, another way of looking at affiliated scripts is also these are, this is the kind of profile  of scripts that I want to allow or block whenever I visit a site.  So that's kind of a different but related feature.  So another question.  You actually had it on the list of related projects.  You matrix, I think it actually fits in a kind of similar niche as NoScript does.  Have you evaluated like how their user interface is?  I mean, it's probably the matrix of a thousand switches that you were mentioning.  But to me, it's actually the one I use.  And have you checked how you could integrate maybe something like that into NoScript?  Yes, you're absolutely right.  I think the matrix is what got me thinking about the matrix to begin with.  Like the eight N options I was mentioning before.  It is super interesting.  They're totally similar extensions.  I think NoScript does a couple more things than you matrix.  But in general, they're the same category of script blockers.  To me, the takeaway for me was that, so our job wasn't to evaluate you matrix.  But to me, the takeaway was that was actually a little bit too fine-grained for most people,  even for power users.  Sorry.  I was very unspecific with my question.  I meant the new feature that you added to save for the site.  Or what you called it?  Per site settings.  Per site settings.  Yeah, what it actually means in terms of a URL.  Is it like a top level domain, sub level domain, or is it like the full path of the URL?  I think right now it's a full path of the URL.  So whenever I am on Facebook.com or any sub domain of Facebook.com, things are going to  be implemented.  Yes.  So yes for subdomains.  I think right.  But these are things that probably, like some of the default options, we're going to like  leave up to George to make the decision on that.  But the idea, so the funny story behind that, if I can comment on this, is this whole feature  is supported by the back end and has been for a long time.  The only reason it wasn't implemented was because George couldn't figure out what the  UI should look like, given how complicated everything else already is.  So this is something we were really excited that we were able to implement.  Okay.  I think if we hurry up, we have time for one more question in the back.  Thanks.  Yeah.  I was, you mentioned the color.  And I was wondering, of course, there are colorblind people that have a disadvantage if you use  color for your design, but then there's a whole bunch of people that greatly benefits  from colors.  And I was wondering if you have some sort of rule of thumb that you use.  For example, I don't use colors at all.  It's probably not what it is.  But maybe there's something like if I use colors, I also use tool X or Y.  You always want to be showing necessary information with color in one other dimension that can  be positioning, that can be words, that can be icons.  You just need to make sure that color is not doing all of the weight.  You don't want, for example, to click on a red circle or click on a green circle.  Because people don't have the like, in real life, we know that in a traffic light, if  the top thing is lit up, it's probably red.  If the bottom thing, it's probably green.  The interface is new.  They've not seen it before.  They don't know that the left thing is going to be okay and the right thing is going to  be canceled or the other way around.  Oh, my God, apps are always switching where okay is versus cancel, where yes is versus  no.  So just color is great.  Do use color and usually green for yes, red for no.  That didn't quite work in NoScript because the yes and the no, the bad and the good,  the good and evil, the trust and block, like that just didn't, it didn't match up.  So we actually didn't use this red, green pairing anywhere.  You should feel free to use red, green pairings only when you're sure it makes sense and always  use also text or an icon.  All right, that concludes the talk.  So thanks again, a bunch, Eileen and Molly for the super interesting talk and I'm sure  a bunch of people are going to give NoScript another try once they see the new UI.  Thanks.  Goodbye.  Andashi, may you be with us.
camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_0_167.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_168_2543.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_2544_2591.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_2592_2951.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_2952_3455.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_3456_3827.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_3828_3923.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_3924_5975.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_5976_25055.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_25056_25247.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_25248_46979.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_46980_47147.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_47148_47447.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_47448_50939.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_50940_53315.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_53316_53447.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_53448_53519.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_53520_53591.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_53592_55319.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_55320_55703.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_55704_55991.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_55992_56411.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_56412_56495.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_56496_56555.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_56556_56735.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_56736_57431.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_57432_57611.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_57612_57719.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_57720_57779.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_57780_59447.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_59448_60683.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_60684_60887.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_60888_61415.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_61416_61775.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_61776_62207.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_62208_62411.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_62412_64007.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_64008_64127.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_64128_64511.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_64512_64583.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_64584_65771.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_65772_65891.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_65892_68123.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_68124_69011.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_69012_69095.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_69096_69179.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_69180_69335.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_69336_69635.png camp19-10368-eng-fra-Beyond_the_Pile_of_Knobs_hd_69636_69988.png