 This next talk is going to be in English. But the next talk is going to have a French translation. So la prochaine présentation aura une traduction française. So especially if you're watching the livestream 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 nowhere else. 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 Knops 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 Knops, a design case study. We're going to talk about how we redesigned the UX of NoScript, a 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, Lorraine. 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, gray scale, consistency, rounded corners. You might call it clear, clean, kind of modern, right? Wow, it 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. But before we do that, just a couple of words about why we're doing this. The fourth answer is NoScript is great. NoScript is awesome. NoScript 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 NoScript 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 NoScript. So NoScript is not something that people who, hey, JavaScript, use. NoScript is something that people who love JavaScript also use. The things that maybe not that, yeah, let's just. The challenges for NoScript that we see are not just challenges for NoScript. They're actually pretty common for a lot of projects we see in the free and open source software scene. NoScript 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. 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 NoScript 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. Yes, something I call 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 gonna 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 wanna 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 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 wanna 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. For example, 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 NoScript off. One of our power users described how they rely on NoScript. NoScript is the last line of 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 NoScript? Yes, no. Giving them a survey, collecting some kind of data, which NoScript doesn't do and will never do. We, 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-it note board. 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 wireframes 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. Now we wanna dive more into what we did and specifically how this looks for NoScript. If you're thinking, yeah, yeah, 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 NoScript is. So we're gonna show you how this works in that context. First, we're gonna 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 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 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 eliminating loading unnecessary scripts. Something like Privacy Badger is in a very different space from NoScript. NoScript 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 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 NoScript. We didn't include anything for NoScript, 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 NoScript because it makes her feel safe online and not using NoScript makes her feel exposed online. She's a security trainer as well and recommends NoScript selectively to people who can 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 NoScript? He advocates tirelessly for NoScript. He tells everybody to use NoScript 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 NoScript once. He could not figure it out and he uninstalled it. He would love NoScript 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 NoScript is never, ever going to provide a block list. That's just not something this tool does. NoScript 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. NoScript is going to be dumb. NoScript, that's part of its DNA and will always be the case. So, who is NoScript for? NoScript 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 NoScript really doing for whom? It keeps you safe. Nah, not really, not if you don't know how to use it. What about NoScript makes safe browsing easy for everyone? For those other two personas, probably NoScript 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 NoScript makes anything easy. What does NoScript do? It buys power users time to make informed decisions about who they trust. We really need to know this in order to do a good job designing it. So, NoScript 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? Use. We have another microphone already, I think. It's number two. Yes. Wonderful. Thank you so much. So, now that we know who NoScript is for, our next step in this process was saying, well, 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, right? Because we have a power user here. Well, that may be true, but it's really no excuse for this, right? This is what our friend, Susan Farrell, would call a pile of knobs, right? I don't, 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, you know, it's logical conclusion, which is offer everybody all the options. Well, 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 NoScript, right? Look at those red words. Those are the things, the elements of this tool. When you visit a site, you 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 NoScript, 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. Could we just show, yeah, that's the first-party scripts, right? So, scripts actually owned by New York Times. Note that, you know, nyt.com is also owned by New York Times, but the URL is actually not exactly the same one, right? And then we have some Google products. We have news.google.com. We have googletagmanager.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, like, 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 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 like 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. Like, 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 not blocking, right? We have, 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, like 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. Or 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 like trying to see some content, and before you know it, it's, you're playing a game of set, right? I don't know how many of you know the mathematical game, but it's like 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 this 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, right? 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, right? 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. You 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'll be fine. Or they go to the other extreme, which is I never wanted to see this site anyway, I'm just gonna 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 and you hope it works. So when I say affiliated, I mean kind of everything that's first-party-ish, right? Can we just go back one? And I wanna 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. And when it doesn't work, you say, NoScript is blocking everything, I can't. NoScript interaction is by default frustration, right? There's just no way around it. It's always going to bat, like, damn you, NoScript. And thank you, NoScript, but damn you, NoScript, 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, we 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. It has a couple of things that we added. So first of all, we wanna 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, per 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 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 wanna 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 wanna allow. Bad scripts you wanna block. 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. Bad security practice means, well, 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. And so here's a situation where we said, okay, we don't want the red, green combination at all because that's only gonna confuse people. I should also say, of course, color shouldn't be the only indicator when you're designing things, right? We wanna 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. I was talking up until now about blocking and allowing, but NoScript's 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, maybe not. But maybe I just need to allow it for now because I need to make an online payment. Why 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 wanna 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, well, 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 gotta 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 and cheeky, right? It was supposed to be, it's not, oh, 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 heart 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 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 FOS, 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. Really what this means is what does your thing do and for whom does it do that? I 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 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-esque 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 wire frames. That's like a vector drawing software. Whimsical, we use for online collaborating on wire frames. Notion, we use, 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. Jitzi 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. Well I should also say this work was not possible without the support of the Open Technology Fund. But 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. This presentation is dedicated to you. Thank you Giorgio. And yeah, I think that's it. I think, so we're gonna be here the rest of the week. If you have any questions about design, about this work or about our work in general, just ping us, yeah. We will help you with design, whatever that means to you, whatever that means to your project. Yes. 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. 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 one 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? For control in general, or for Tor? No, for like tools that interact with each other, for example, NoScript and Tor. Right, because it's, yeah. So that was super important because we know that you might restate the question, right? Was it on the microphone? Was the question captured? Yeah, okay. Yeah, so Tor, that's 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 gonna be different depending on the new UI and how it's implemented, but yeah, that's gonna be a real project. In general, you absolutely should find out what other tools fit in people's workflow, right? You wanna ask people what browser they are using, you wanna find out what OS they are using and if you find that 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? Yes, that's a good question, nice catch. So what we're gonna 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 gonna do is most likely offer some background. So when you install the next NoScript, it's gonna 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 wanna 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. Yeah, I was also interested what site-specific actually means. Probably the same, it's related to sub-domains and so on. Right, so sub-domains of the site, do you mean? Or, okay. Because I think there's also another question about the site-specific scripts that are block or not block, right? So another way of looking at affiliated scripts is also, this is the kind of profile of scripts that I wanna 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, U-matrix, I think it actually fits in a kinda 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, right? Like the eight N options I was mentioning before. It is super interesting. There are totally similar extensions. I think NoScript does a couple more things than U-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 U-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 or something. 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 subdomain of Facebook.com, things are going to be implemented, yes. So yes for subdomains. But these are things that probably, like some of the default options were gonna like leave up to Giorgio 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. And the only reason it wasn't implemented was because Giorgio 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, 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 the 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 gonna be okay and the right thing is gonna be canceled or the other way around. Oh my God, apps are always switching where okay is versus canceled, 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 gonna give NoScript another try once they see the new UI. Thanks. Goodbye.