 All right. Hello, everyone. My name is Olga and I am a product manager at the Wikimedia Foundation. And I am here with Alex and Shuman who will introduce themselves in a second. And we're here to talk to you about the new desktop experience. Hey, I'm Alex Hollander, also from the foundation. I am the designer on the web team. And I've been with the foundation for almost five years now. And I am Shuman, a community relations specialist, working with the web team. I'm an experienced Wikimedian and I've been working with the foundation for five years. All right. We are very glad to be here with you today. I have some slides for you that we will go through and present. And then after that, we welcome you to a separate call on Zoom to be able to do a Q&A. All right. Well, as we mentioned, we're Alex, Olga and Shuman from the web team at the Wikimedia Foundation. And we are here to talk to you about the new desktop experience. So for the past three years, we have been working on a new and improved desktop experience, focusing specifically on making sure that our interfaces are welcoming to all readers and editors, especially those who are new to our sites and who have come from diverse backgrounds and geographies over the past 10 years. Right now, we are in the process of finishing this work. And we are focused on working with communities, building up consensus, and doing all of the work necessary to bring this new experience as the default to all of our Wikis. We're very excited about this. So for today, first, we will give you a quick introduction to the project overall and to our need to create a new experience. After that, we will show you a quick demo of what we've built and give you some extra information on the individual features that we've made. Then we will discuss our process for working with communities and affiliates and bringing this change across all of our Wikis. And finally, as I mentioned earlier, we will have a question and answer meeting in a separate Zoom call. You are welcome to join us. We really hope that you do. You can find the link for the Zoom call in the etherpad for the session. So before we get started, I wanted to give a quick summary of everything that we will talk about. So basically, our team, the web team, has built a new look or skin for Wikimedia Wikis. Our main goal for this was to make Wikis be more welcoming to new users. Right now, this new skin is the default across 32 Wikis. About half of them are Wikis that are in the top 20. We hope to bring this new design as the default on all Wikis starting next month in September. We are currently working on talking to communities to make these changes and gathering consensus prior to deployment. We are also working with readers and on spreading the word amongst readers via blog posts, a separate website for the changes and other media. So first, we will start with a quick history of our desktop interfaces. And I will hand it over to Alex, our designer, who will walk you through this. Thanks Olga. Yeah, so basically, the first thing we did when starting this project was to take a look at how the interface has changed over the past 20 years, sort of trying to understand, you know, where we've been and what changes have been made and why. And a few things that we noticed, you know, starting from this kind of 2002 interface, which was almost pretty skin. The concept of skins didn't really exist yet. We see a super dense and kind of text heavy interface. And as we progress to monobook and then eventually to vector the interface, both starts to get more organized with sort of like sections and menus and things like that. And also it starts to get a little bit less dense. So you'll see in a second when we look through the screenshots, monobook has a little bit more space and then vector also has a little bit more space. Another thing we noticed is that, you know, since 2010, of course, there haven't been any major updates to the default skin. Our team was very much focused on mobile. One of the things specifically we were focused on was making it easier for people to edit on mobile. But during that time, that sort of 10 year gap there, there was a ton of activity from the community in the form of gadgets and user scripts. Also in terms of proposals for new skin, like winter and actual new skins, like timeless. And so a lot of the time we spent was looking through all of these customizations and all of these modifications that users and community members had already made over the past 10 years. And there are actually not a ton of new ideas in the work that we've done. It's mostly bringing together ideas that we saw or features that we saw that have already been developed. So on the next slide, you can see the sort of original interface. Again, it's extremely minimalist and mostly just uses text and that was back in 2002. Then on the next slide, you can see a screenshot of Mono Book, which again starts to sort of put things in specific areas or menus and has a teeny bit more breathing room to it. On the following slide, you can see a screenshot of Vector, which is what we're all familiar with. And again, there's a little bit more white space there. And then we also included a screenshot of Winter, which was a proposal from 2014 developed by a staff member at the time, Jared Zimmerman. And we included this because it's got a lot of great ideas. Again, many of them coming from community developed user scripts and gadgets, like a sticky header and collecting the user items in a user menu, and a few other things. So yeah, we kind of looked at all of this history. Oh, sorry. Next slide. And started to articulate reasons for why we needed to change. So I can't see the slides on the screen anymore, but we should be on slide 14 at this point. So yeah, we started to articulate reasons for making changes to the interface, which is always a difficult thing to do. Change is difficult, but it's also necessary. And some of the reasons or the top four reasons why we decided that change was necessary right now. Number one is diversity and inclusion. So more people are using Wikimedia projects from all over the world. And we want to make sure to support all of them. Specifically, welcoming new readers and new editors from all different kinds of backgrounds on all different sorts of devices. Mobile and desktop. You know, for many people, their first experience will be on a mobile device. But desktop is still very important with over 50% of the age views coming from desktop devices. And so we want to aim for consistency between mobile and desktop, and maybe even eventually a single skin across both. And then we also know that there are a bunch of new patterns and new capabilities that are available to us like responsive websites and other CSS and HTML features that give us the ability to do things with the interface that weren't possible. And we know that when Vector was designed, you know, nearly 12 years ago now, for example, the range of screen sizes that people used was much more limited. And there weren't such large screens. And there also weren't so many different types of tablets and things like that. So a bunch of things have changed. And we are responding to all of that change and trying to find the best way forward so we can include as many people as possible in the movement and provide the best possible reading experience for everyone. And yeah, as I said earlier, a huge part of our work has been looking at what the communities are already doing. So for example, on Korean Wikipedia, and others, there is already a collapsible sidebar on Hebrew Wikipedia. There is a gadget that makes the header sticky as you scroll down the page. One of our colleagues here at the Foundation Pratik developed a gadget to make the table of contents sticky as you scroll down the page and then sort of plug-in developed by another user called Wikipedia rehash increases the font size and introduces a maximum line length as well as many other sort of Wikipedia reader like apps and experiences do. So yeah, this stuff is the inspiration and sort of the building blocks that we've been working with. And a sort of metaphor that we have talked about throughout the project and is sort of a theme in our presentation is the need both for a dense interface kind of like a cockpit of an airplane, which is what editors and power users often want, and then a sort of more minimal focused interface like a library for reading and learning, which is what a lot of readers want and trying to figure out how we can provide both interfaces. And then on the next slide, we're kind of asking the question, will we ever be done? And no, there is no kind of finish line here. We are at this stage of the project sort of reorganizing or almost resetting the interface. But as we know from working with community members along the way, there's always more changes, always more considerations. So the interface will continue to evolve and we will continue to work on it after this project. Okay, and with that overview of sort of our research and some of the framing, I will pass it back to Olga. Thank you. All right. Thank you all and apologies for the technical difficulties. So I will talk over what we mean when we say improvements and how do we know that the things that we build are actually improvements. So starting with the goals of the project, as Alex mentioned, we really wanted to focus on new people that are coming to our wikis and especially to make sure that they feel welcomed and that they feel welcomed in a sense that they know how to use our sites. They are curious about exploring more of our sites, whether that means reading more or maybe even becoming involved in our communities and becoming editors. So our main goal for the project was to make the wikis more welcoming to new readers and editors. Our secondary goal was thinking about the usability of the site and making sure that the site becomes more useful for everyone, not just only for the new people, but also to make sure the standard of quality and the ease of use is the same for existing editors and other power users that have been around for years now and been involved in the project for a long time. So when we were thinking about this idea of welcomeness, we understand that it is a very open concept. So we wanted to make sure that when we start the project, we give ourselves measurements that will reflect the reality of what we want, both the kind of softer side of the idea of being welcoming as well as the harder side of data and making sure that we are not building anything that is not proven to be better than what was there before. So for our targets and for what we defined as success, we had two sides. The first side was qualitative, so looking at things like trust and positive sentiment, looking at different surveys for how people use the site and doing a lot of research. The second part was a little bit more direct. Basically, for every feature that we built, we compared its usage directly to the feature previously and made sure that usage went up or that usage and usability improved for the new feature over the old one. We did this through something that we call AB testing or multivariate testing, where we basically show both versions to people and see which one performs better. So for example, if we're looking at something like search, we want to make sure that if search is, we want to make sure that we compare the new version of search to the old version of the search and that the new version of the search performs better and has more searches, which is something that we were able to prove. So a little bit more detail on what this project actually is. We've given a lot of this kind of higher mindset type stuff, but we wanted to also get into the detail. So the main thing that we wanted to do is bring the content into more focus. We also wanted to make sure that tools that people use frequently are available on the page and are in places where people can find them easily, in places where they are next to tools that are similar and potentially further away to tools that they're not alike at all. We wanted to make sure that things that people use more frequently are more easy to get to on the page than things that people maybe use a little bit less frequently. And also, we just kind of wanted to do some cleanup. So over the years, we know that a lot of different tools have gotten added into places a little bit haphazardly. We wanted to make sure that everything is a little bit cleaned up and organized. At the same time, we wanted to set some principles for what this project was not. So from the very beginning, we understand that the content belongs to the communities. So we made the commitment to not change anything in the content area, which is that gray area that you see in this image. We also wanted to look at all of our different tools. The same way we know that our content is important, we also know that our tools are very important to our communities. So we wanted to make sure that we don't actually remove any tools. So tools might be in different places, they might look a little bit different. But everything that you saw on the page before we started making the changes, you will see on the page after we made the changes. And finally, we didn't want to drastically change anything. We know that Wikipedia is very distinct that it has a certain style, a certain feel, and we wanted that to stay the same. We wanted to make sure that we're not introducing a completely new project with a completely new design. We wanted things to still feel familiar and still feel welcoming and comfortable. So that's a little bit about how we looked at the project. From there, we started doing a lot of different research, and we began entering into this process for the way that we actually built things. The first part of this process was the research that we did. So here, we worked both with readers and editors across multiple countries and multiple locations to make sure that we identify what the trouble was and what the problems were with the current interface. So with editors and communities, we worked in in person meetings, such as Wikipedia, such as the hackathon, we also talked to people on wiki. With readers, we made sure that we test globally in different countries, such as India, Ghana, Argentina, and Indonesia to make sure that we have a group of multilingual users of a variety of different wikis, and to make sure that we talk to them specifically about what issues they were having with the site. Based on this research, what we do is we identified problems that people were having, and then we went into the prototype stage. This is the stage where we start trying to solve some of the problems. The way that this works is we built out potential solutions to some of the problems that we had identified. Then we begin testing these solutions. Similarly to the research stage, we made sure that we tested these solutions across multiple languages, and both with readers and communities of different sizes. So with communities, we tended to use central notice to tell people about our prototypes. And through this way, we were able to actually test on more than 30 languages. And for each prototype testing, we had between two and 300 replies from community members. For readers, we did more focus testing once again in different countries, focusing specifically on the way people were using the previous version of the feature and the new version of the feature. Once we do all this research on the prototypes themselves, we begin collecting the feedback and then changing the prototype based on what the research tells us. So once that prototype is changed, based on what we have learned, we are ready to go to the next stage, which is actually building the feature. Here, our developers build out what we have settled on, while we still kind of continue the conversations with readers and the communities to get more feedback. Once the feature is built and ready, we go into the stage of quantitative testing. So here, we most frequently do AB testing, and also other types of quantitative testing. So what we do is we ship the feature that we have built to about 50% of the users on a given pilot wiki or partner wiki, and I will talk about those in a second. And then we compare whether it performs better than the old feature or not. If it performs better than the old feature, that's great, we're very happy. And we begin giving it to more people. If it does not, we go back, we look at the feedback, and we look at the data to make sure what the issue was. And then we began fixing those issues until we can prove that the features performing better. So we did this with all of the different features that we touched. And now we're in this last part of the process, which is scaling where we are ready to talk to more wikis, have a lot of these conversations around deployment and bring these features to everybody. So I mentioned that we were testing on our pilot or partner communities. What a partner community means is we have been working for the past three years with a set of communities who volunteered to have the new skin as on by default. What this meant was that everyone on that skin was able to see the skin. If you were logged in, you could opt out whenever you wanted and switch to one of our other skins. If you were logged out, however, that was the skin that you were using every day. For other wikis, we wanted to make sure that we are still able to get feedback. So what we did is instead of making it the default, we included it as a preference. What this meant that is that if you were logged in, you could try out the skin and you could see and give us feedback. However, if you were logged out, you were not able to have access to it. What we want to do right now is basically bring access to the skin to all people who are logged out. This is the this is the focus of the conversations that we are having right now. If you are currently in one of our partner communities or not in one of our partner communities, we encourage you to check out the skin. You can turn it on from your preferences in your skins list. So I mentioned that we work with these communities and something that was really important for us is that we really had a good representation of our movement when we were building out the skin. So we really wanted to make sure that we work with communities that are both very large, like French Wikipedia, Portuguese Wikipedia, for example, as well as quite small. We wanted to make sure that we have a good distribution of different languages that we have languages from every continent, that we have a good distribution of scripts, and that also we have scripts that go from left to right, as well as right to left. And finally, we also wanted to have a good distribution of projects. Many times we focus excessively on Wikipedia when we build, which is really good because it is our most popular project. However, it causes the problem of things not being built well enough to the standard of other projects. This time around, we wanted to make sure that we started building with different projects from the very beginning to make sure that all of the use cases and the needs from these projects are considered from the very beginning rather than retrofitted based on something that was built for Wikipedia. So as I mentioned, we are now almost wrapped up with all of our changes, and we hope to begin bringing these changes as the default starting in early September 2022. Right now, we are focusing on discussing the changes across communities and gathering consensus for deployment across communities both large and small. We are also working on having meetings such as this and discussing the project, updating our documentation, as well as taking in consideration the feedback and the needs that we're getting from the communities and making sure that we are meeting those by fixing any kind of bugs or working through new requests that we are getting in. Okay, so all of that said, I think it's finally time for us to do a little bit of a demo for what we have built. And I will quickly change my screen share. So here it is. So we started our changes once again by focusing on the content. So in order to do that, we made sure that the sidebar itself is collapsible so people can use it when they want to and collapse it away when they don't. We focused on limiting the width of the text to make sure that people can focus a little bit more and also to improve readability. After that, we built out a new search, which includes context on the different search items by adding descriptions and images. We began collecting a lot of the tools that were available here at the top of the page on a single menu. And this is because during our research, we saw that people were struggling, especially new editors were struggling to distinguish which of these tools were their personal tools and which of these tools belonged to the global navigation. For example, people were getting confused between the personal talk page and the top page of the article itself. After that, we worked on languages. We moved the language list from all the way here at the bottom of the sidebar to the very top of the page to make it easier for multilingual people to switch from one language to another. Then we began focusing on providing better access to frequently used tools, starting with the sticky header. So as you know, certain tools such as access to the history page or access to the talk page were previously only available at the very top of the page. By adding these to a sticky header, we're making them available as you scroll down the page. And this makes you a lot easier to access these tools, and this also saves a lot of time spent in scrolling. I have a separate slide on this later on, but I would like to mention that we were actually able to decrease the scrolling to the top of the page by 16 percent by doing this. After that, we focused on doing something similar for the table of content. So as you know, before the table of contents was only available at the top of the page, we were able to also add it to the side of the page. And that is my very, very quick demo. Right now, we are focusing on the visual styles of the of the page and making sure that the look and the feel is cohesive. Okay, so I will stop sharing the quick demo and then focus on a couple of the changes that we have made. And apologies while I switch back to the slides. Okay, so as I mentioned, our new table of contents allows people to immediately understand the shape and context of the article and makes navigations between sections easier. We actually saw in our AAB test that this increases clicks to the table of contents by 50 percent. In terms of language switching, the language switching change was designed for multilingual users. However, as I mentioned, sometimes our initial way of building the feature does not work out. This is an example of that. When we first tested it, we saw that while new readers and readers in general had an easier time with the new language switching, we saw that this was causing problems for editors. So what we did is we iterated on the feature and we made the necessary changes to make sure that logged out and logged in users did not switch languages less than before and to make sure that the feature is a success. We also worked with the language engineering team at the Wikimedia Foundation who focused on languages to ensure that the new functionality included entry points for translations and wiki data entries. Our new search, as I mentioned, makes it easier to find the correct result by including contexts such as images and descriptions for each result. And we're very happy to say that when compared to the previous search in an AAB test, we saw that more than 30 percent of people, sorry, we saw that people started more 30 percent more search sessions within, with the new search than we did with the old search. Finally, our sticky header, as I mentioned before, decreases scrolling to the top of the page by 16 percent and that is saving a lot of time, mostly for editors in different communities in scrolling. Another change that we made and that we're focused on is the line length and increasing the font size. These changes allow people to read a little bit more comfortably and research has shown that limiting the width of this text, of the text, leads to a more comfortable reading experience and better retention of the content itself. Okay, I will go a little bit more quickly because I see that we are running out of time. So something else that I want to mention is we know that no skin can be perfect and that developing our desktop experience is a process. So we wanted to highlight some trade-offs and challenges that we have come across. The first one that we have looked at is that of an improved reading experiences that focuses on the content and tools that are used more frequently and this we tried to balance with the preference some editors have for a denser experience which we have tried to support as much as possible. So as in previous skins, communities and editors can customize the skin through user scripts and gadgets. Through the two years of the new skin's existence, many editors have built such gadgets and scripts that augment the skin in various ways. For example, here you can see a gadget which stretches the text to width larger than the default. We have collected a library of these gadgets and scripts in the repository of our documentation, the link for which is in the slides. If you're interested in checking out the existing customizations or adding a customization that you've built yourself, we welcome you to check this out. Another one of our goals is to move to a more customized menu system. Once the new skin is available by default everywhere, we look forward to moving towards such a system. This would include the ability to pin certain menus such as the tools menu or gadgets such as the twinkle menu to the sides of the page. Currently we're talking to different communities and exploring possibilities. For example, we recently met with Russian speaking editors. One of the concerns they raised was immediate access to multiple language links at the same time. This screenshot provides an idea of how we can set up a customized menu for switching languages. And finally, we would like to admit that not every skin is perfect for everyone. We support our editors who choose to continue using the current version of the vector skin or the mono book skin and we would just like to confirm that we will continue maintenance for these skins and are not planning on any changes to them as a part of this project. Okay, with just a little bit of time left, I will hand things over to Shimon who will walk you through how we're working with our communities going into deployment. Thank you Olga. So let me do a quick reminder. I am the community relations specialist and my role in the team is to ensure that the team with the communities. Next slide. So we want to get many different groups and communities informed and included in their decision-making process. We post announcements on the central discussion pages on weekies such as village pumps, forums, cafes, but we also go beyond that using banners organizing office hours, sending updates via our newsletter and joining the events organized by the communities. We contact the affiliates as well. Here I'd like to express my gratitude to three groups of Wikimedians. Firstly, volunteer translators with home, without home, we wouldn't be, we would be limited to just a few languages so they practically enable us to communicate with the movement at large. Secondly, to product ambassadors who liaise between the team and the communities, predominantly the partner communities that Olga was talking about earlier. And I would also like to thank the interpreters. Thanks to them, people who do not speak English can talk to us at the office hours that we organize. Next slide. Soon we will begin informing logged out users about Vector 22. Banners will appear on selected pages. The readers will be able to preview the new skin and take part in a satisfaction survey. Next slide. In the banners, there will also be a link to a dedicated web page with basic information about the changes. That web page, as you can see, is targeted to readers, logged out users, and if you are interested in the details about the project, we would like to invite you to mediawiki.org and you will see the link in the next slide. So I would like to ask to skip to the next slide. Here you can see the link, previous one. Here you can see the link to the relevant page on mediawiki.org. If you'd like to contact us, see this page or send an email to any of our addresses. Now next slide. Now we would like to invite you to a session for questions and answers. This will be a separate event. It will take place on Zoom. It will be in English only and will not be recorded. On this slide you can see the invitation links. The first one is for online connections and the second one is for phones. I launch the meeting directly after this presentation. Thank you. Thank you all so much and thank you all for coming and hopefully we will see you in the Q&A session. Thank you. Thank you.