 Hello, welcome. Welcome to December's edition of the Lightning Talks. So before we get started with our first talk, let me tell you about why we're here and how it works. Hello, welcome. Welcome to December's edition of the Lightning Talks. So, okay, that was weird. So we're here, so engineering teams and product teams have a chance to showcase a significant milestone that they've reached or a goal that they've achieved this quarter and Lightning Talks are also open to the community to present something. So the way it works is you have 10 minutes total to present, and that includes time for questions. So once the speaker calls for questions, if you're here, there's a microphone stand over there, so please use a microphone. Otherwise, you can also ask your questions on IRC. The channel is hashtag, Wikimedia-tech. So, Brendan is our timekeeper. So once there are two minutes left in your talk, he'll give you a little notice on the speaker, two minutes. Following a one minute and then a time's up. So with all that done, let's begin with our first Lightning Talk, Layla. Hi, everyone. My name is Layla. I'm a research scientist at the Foundation, and today I'm going to talk to you about a research that we are doing in collaboration between the research team and the reading team at the Foundation and two of our collaborators at Stanford University. So the title of the talk is why are you reading this article today? So I don't know why these look like this. It didn't look like this on my slides, but okay. So the goal is basically for us to build two taxonomies. One is a taxonomy of readers, and for that, this is basically a general category of research. We want to understand what our readers, where are they coming from? Why are they coming to the website? What kind of content they read? Do their reading behaviors differ in the morning, at the end of the day, during the weekends? So we want to have basically a full story about our readers. And then we also, thank you, want to have a taxonomy of our articles. This is not from basically an article in a static sense taxonomy, but we want to look at the readers and see how they read articles and build a taxonomy of articles based on how they're consumed by the readers. So this is less of categories and such that we have been looking at in the past. So in order to do this, we started very ambitious, but then we learned that we actually do not know why people come to Wikipedia at all. Basically, we have some imaginations based on the way we use Wikipedia, but we have never really systematically at scale asked users, asked our readers why they come to Wikipedia. So we started with this first step to learn during the past three months and read Wikipedia articles. We ran three surveys. These are basically all up until now, they have run on English Wikipedia. The way they have been run is that quick survey was shown to the user. And then if the user accepted that quick survey, the call by quick survey, the user was taken to an external website, in this case, Google Forms. And there the user basically was asked one, two, or three questions. These are the three surveys we ran. The first two were ran on desktop, were run on desktop and mobile. Although in retrospect, we learned that actually both of them were run on both platforms. They were free form and I'll explain that a little bit more further. And then the last survey was multiple choice. So I'm going to be talking to you about these three surveys and what we have learned from them. So survey one and two and I'm bundling them because they ended up being same surveys in retrospect. The goal for us, basically, ideally, we wanted to learn at the end of the session, we wanted to ask the reader, why were you here? Now this from the technology standpoint, it's a little bit hard for us to do this for a variety of reasons. We basically don't know when the reader wants to exit. So that ask them that question at the exit point, unless we do fancier things on the website, which we didn't want to do during the past three months. So we changed our goal slightly to basically answer this question. Why are you here to read this specific article at this point of time? So instead of talking about the session, we focused on the article. So we went to the reader and we sampled basically readers during the first survey during the span of three days. The quick survey widget would pop up. And for some people, the sampling rate I think was five out of 100,000 requests. And we would tell them that the reader that they can answer one question and help improve Wikipedia. If they would click on visit survey, they would go to a Google forum, which would ask them, why are you reading this article today? The reader then would have 100 characters to explain to us why they were there. These are some sample responses we got. I'm here for entertainment, thought candy, because today is bird watchers day in India. I don't know, bored, I guess. So these are the kind of responses that we got. What we got, what we did is that we did three rounds of hand coding. There are five of us. And we identified four dimensions that readers communicated with us through that free form text. So basically, readers talked to us about their motivation. Some of them said, I'm here for school or work-related projects. Some of them said that there were people saying, I want to decide about the medication. I want to buy a car. So there were personal decisions involved. There were personal interests. I'm just curious to know what's going on. They also talked to us about their information, how much information they were going to get out of that article. Was there a quick lookup? Was there an in-depth study of the subject? They talked to us about the current or immediate real-life context they were in. They were sitting with friends. They were in a movie theater. They were in a museum. And they also talked about where, some of them talked to us about where they have come from. So whether they were watching something offline and then they decided to come to the web, Wikipedia, were they on Google, were to us, or were they reading another Wikipedia article coming then to the article that we showed the question on. So we also potentially learned a couple of other things. One was that we expected a lot more spam or responses that were not useful for us. And this is usually the pattern when you put free form box in front of people on the internet. We saw very few spam responses. And this was really incredible. It was a very beautiful surprise for all of us participating in this research. And the other thing we have noticed, and this is something we need to look into more, is basically comparing the actual numbers we received, the number of responses, and what we expected to receive during that period of time. These two numbers are very close to each other. And when we computed what we expected to receive, we didn't take into account that some people may not respond to the survey. So we are speculating that the majority, maybe all of the people who saw the survey actually participated in the survey. If this has happened, this is fantastic. We need to look into it. So with the four dimensions that we identified in surveys one and two, we went to survey three. For us, the goal for survey three was just to identify basically any missing dimensions or any missing categories that we did not capture in the first hand coding, rounds of hand coding that we did. So in the case of survey three, we basically showed again the same widget to the user. We said to answer three questions and help us improve Wikipedia. If the user would accept, they would come to this form. This is a multiple choice form. The user would tell us prior to visiting the article, whether they were familiar with the topic or not. They would tell us how much information they wanted to get out of it. And we would give them, we basically gave them the other option to tell us more. And if you are missing basically a category that they could express, but we didn't capture in our hand coding. And the first one is capturing some of the reasons people come to Wikipedia for like, I'm bored. I'm in a conversation with others. This was mentioned on media. So we ran the survey on basically 10,500 people roughly participated. And please don't take these numbers. Don't look into them with too much trust because that survey was run on the week of Thanksgiving and there may be bias on the actual distributions. What we were interested in to see whether this other tab is filled by many people or not, and it's not. So it's a good confirmation for us that the categories we identified were correct. The actual numbers we need to look at them in more details. But basically we see that basically one third of the people come for look up one third for overview, one third for in-depth, and very few chose the other option. We also see that basically half of the people are not familiar with the concept and half are when they come to Wikipedia to read an article. And then we also learn about the reasons that they come. Many people come, 30% of the people express that they come to Wikipedia because they are bored or they are just randomly exploring content. I'll save some time and I'll skip on what else we can learn. Please look it up in the slides. And what's next is for the next quarter we want to basically look at other languages. So this was an English Wikipedia and we are curious whether the dimensions we identified actually are robust when we go to other languages. And the other thing is that we want to run a larger scale survey next quarter and basically connect the responses from the survey to web request logs and then go deeper in understanding who the readers are and what the articles they're consuming are. With this I close. The documentation is here. Feel free to ping us there and ask any questions you have there because I think I'm running out of time here. Thanks. Thank you Leila. Just one quick question. So can you give us some hints as to some of the applications of the knowledge or the insights you're getting here? Right. So are you asking about like product? Yeah. So it depends what you want to do and what the product teams are curious about, right? One thing we can do for example is we can look at rabbit-holing. We can try to characterize rabbit-holing, understand when it happens, why it happens, on what articles it will happen, at what times of the day it will happen. So I think we have a lot of opportunity to ask many questions and answer many questions. It really depends what the teams are interested to know and we would be happy to hear those questions. Right. Cool. Thank you. Thank you very much. Let's give Leila a round of applause. Thank you. Right. Up next we have Joshua with an update on the Wikipedia iOS app. Everybody I'm just going to take a second to get set up. So I'm going to try to juggle the microphone and the vice somewhat simultaneously. So you're my clumsiness. So I'm here today to talk about the new version of Wikipedia for iOS that we've been working on. If you are on the WMF all list or the mobile list, you saw yesterday an announcement about entering a beta. So we've submitted the beta to Apple. We're basically waiting for Apple to approve our distribution to test flight. We're definitely looking for participants. We already have a pretty good response rate from yesterday's emails. But if you're interested in participating, there's a link on our team page on the wiki. There's links in the email yesterday or you can email me at jminer at media.org. We'll sign you up. But today I just wanted to do a quick introduction to the new app and a walkthrough of some of the main features that we've added or changed. I don't have any slides. It's mainly just going to be streaming from my phone. I apologize if any personal messages come up during the talk. By way of background, I just wanted to give a little context about why we are making so many changes to the iOS app. So the Android app team has been pursuing incremental improvements on features and additional new features on the existing app. The iOS team took a different strategy, kind of a let's start from the ground up strategy. And our main motivation for that is because although the iOS app has been pretty well reviewed and even featured by Apple several times, we never have been able to build a consistent and regular audience in the app. So people come into the app, they like it, they give us four stars on the app store, and then a week later they never use the app again. So we felt like we needed to kind of go back to the drawing board in terms of the way people interact with apps and Wikipedia on apps and think about ways that we can kind of suck people into being regular Wikipedia users of the app and to provide app specific value that goes above and beyond just looking for something on Google or Siri or looking at the mobile website, just great usage of Wikipedia, but not a very app specific. So I'm going to go ahead and launch the app. One of the first things that is we created a new first time user experience. So one of our feelings was that potentially retention issues are around just kind of not onboarding people well into the app. The existing app, we immediately ask you to log in when you start up the app. That's a pretty unwikipedia type experience. People aren't used to associating Wikipedia and logging in, and also it doesn't kind of set up what the app is for or explain any of the features of the app. It's just, hey, log in to Wikipedia. So we start with a screen that kind of explains some of the main new features, and I'll dive into these as well during this walkthrough, but the top one is a new Explorer screen, which is kind of a feed-like mechanism for finding interesting and relevant articles on Wikipedia. And then second is kind of highlighting our major new design changes. So you'll see there's a lot of look and feel changes and navigational changes. So I go ahead and check it out. And then we have two setup screens. So we chose to focus on two kind of core features for Wikipedia or core brand associations. So the first one is multilingual support. So basically this shows you that Wikipedia is available in multiple languages. I happen to be a French reader and writer, although my spoken French is awful. And so on my phone, I already have French setup as a language, and the app picks that up and shows me that I have English and French, and then I can order them or add additional languages and then obviously privacy is an important value for our movement. In the existing app, we have analytics, but it's hidden under the settings. You have to go into the settings screen and then either opt-in or opt-out. Here we kind of up-fronted kind of a call to participate in the movement a little bit by being a volunteer and sharing information about how you use the app, and we up-fronted the option to turn it off or on as part of the onboarding. So once you're all set up, get shown into the Explorer screen. So I've actually been using this beta for a couple days, so my Explorer screen is a little more populated than when you would first start the app, but you see right at the top here there's recommendations based on reading that you've done. So I was reading an article about Joanne H. Morgan who was a astrophysicist at NASA for many years, and so I get articles like recommended to me like Cape Canaveral, Texas Tech where she went to school, and Antarctica which was one major area of study for her. These are using the more like function built into the search backend. So we're not building user profiles or doing anything on the server to keep track of what you're reading. We're just actually asking them straight Wikipedia search for more articles like ones that you've read. I also read about the little prints. You can see there's some recommendations related to the little prints. In addition to things that are personal, the Explorer feed is focused around also pulling in things that are global to Wikipedia and then local. So we I have my Pithy global local personal. So we have personal things which are recommendations based on what you've read. For global, we pull in articles like the featured article of the day from the main page. So this is today's featured article of the day. It's a really nice article about a bat. Unfortunately, the picture is just a map of Madagascar where the bat comes from. I wish they had a nice picture of the actual bat, but anyway. Today on Wikipedia, that's a quick link just to get to the actual main page if that's what you really love to do. We pull in the picture of the day from Commons. So oops, it's rotated. So this is today's picture of the day. It's a nice picture of space. A random content. So random is kind of a naive way of recommending things to people. If we don't know anything about you, there's always a chance to spin the wheel and get a random article. One nice feature that we added to this is also just ability to spam the random button. So I didn't find I didn't think that initial random article is very interesting and I can just sit here and go next. Thanks. That guy doesn't have very much content. And then last but not least, I mentioned local. So we have moved a lot of them nearby content. So articles that are tagged near you into the feed as well. So this space said you get a mix of things from various sources that are relevant to you based on what you've read, based on where you are physically or based on what's going on on Wikipedia and the Wikimedia sites as a whole. So that's kind of the basics of the explore feed site. I think one thing to a couple of things that are really highlighted about the explore feed as a concept is it is very different for Wikipedia, but it's not that different for mobile apps. This is a paradigm that's used pretty widely across lots of different kinds of apps. And it's really great for discovery. It's great for serendipity. It's also great for retention. If you are interested, there's a lot of stuff in our project documentation and slides that are on our wiki about how feeds drive habit forming loops, basically making it possible for you to have that serendipity moment of discovering cool, something cool on Wikipedia that you didn't even know you were looking for. And then by reading it, you're kind of populating the feed in the future. So it's this loop of you finding interesting things, us presenting interesting things to you, and then you finding more interesting things. And so we're hoping to kind of drive retention and daily usage of the app through this kind of discovery mechanism. Two minutes. Some other features of the app to highlight are a new tab based design. So in the existing app, we used what's called the hamburger menu in the trade, which basically means a single menu that contains all of the navigation. We've now split that out. A lot of the stuff that was navigational is now in the feed, but also basic lists of articles that are personally relevant to you. So articles that you've saved. So if I save Cape Canaveral, I get my saved articles that I can read offline. And then your recent history. So here's my history and nicely organized by day. And then last, but certainly not least search, as you'll notice was available on every screen with one tap. And one thing that we've added to the search is again, multi-lingual support. So just emphasizing the availability of content in lots of different languages. So you can easily switch your search right from the search screen or even add additional languages. And that covers it. There's a lot of other stuff. A lot of looking field changes. But that does it. I have one minute. I guess I'll open up for questions. Oh, I should show the actual articles too. This is the article view. Do we have any questions locally for Joshua? Let me check out the RRC. There were some questions like, are these features available for mobile web or on the web? No. So the goal with this was to create an app specific experience to basically to try whether to put these, these concepts in front of users. Some of them are Apple would only ever be on the app like the tab based browsing. That's really not something that we would ever build into a browser because it's just not the way browsers work. But some of the concepts like the explore feed, depending on how users like them, the idea is that we would then, you know, experiment with them on other platforms including Android or mobile web potentially. Okay. And I have a question. I don't think I saw link preview on this. Is that something? Yeah, that's a good question. Unfortunately, I have an older phone. So what we've done is implemented link preview using Apple's new force touch mechanism where you can, or you can touch and hold an object and you get a nice preview window. We chose to do that because it was built into the operating system and it's a little more future proof than if we built our own custom solution. So we have a form of link preview, but it's not, it's not as prevalent as on Android where it is supported on all devices for every type of link. Cool. Thank you. That sounds cool. Yeah. All right. Let's give Joshua a round of applause. Thank you. Next we have Rob. Great. So yeah, thank you for attending. This is about the Wikimedia Developer Summit that's happening January 4th through 6th for the first couple of days at the Mission Base Center. And so the first two days are going to be meetings, which are actually more discussions, really, where we modeled the Developer Summit more after big collaborative meetings like the IETF and that sort of thing. And so it is less about sort of education and presenting and marketing and much more about big group decision making. So, and then the next day, then we, the third day is when everybody who's an attendee, even not a Wikimedia Foundation employee, is invited to come back to the office. So that's, that we don't have explicit plans for sessions during that time, but this is going to be an opportunity for people to collaborate based on their first two days of discussion. So the agenda is rather chaotic right now. It's coming together. And if any of you, so how many of you, I guess maybe I'll just ask some questions here. How many of you are planning to attend the Developer Summit here? Okay, so practically everybody here. How many of you actually have session presentations that you are hoping to be on the agenda? So there's three or four of you. So basically what's going on right now is we're in the process of discussing the, finalizing the agenda on Fabricator. And so you'll see there's been a lot of discussion there about how the agenda will be put together. We have the main track pretty much settled out, but we don't, but we have five parallel rooms or five rooms that could be used in parallel. The big room, which everybody should theoretically be able to fit into, and then four smaller breakout rooms. And we're still, two of those rooms we've specifically reserved for unconference style planning, and two of them technically are conference, are sort of more scheduled, but it's really going to be kind of unconference on Fabricator up until the point of the summit. So the way that we're evaluating the various proposals is we've broken things up into areas of expertise and sort of areas of problem solving. And that is where we are asking, we have area leaders that we've been asking to take a look at what sort of trade-offs they would like to make in terms of the discussion process that they would like to see. So, and I guess one of the things that I, one of the things I want to add is that these areas, I think are areas that will hopefully exist well beyond the summit, like there's no reason why we need to disband these areas when we're done scheduling for the developer summit. So, the first area is collaboration. How do we scale up our editing and how do we scale up our software development to the size of our editing population? Or, you know, maybe that's a little bit too ambitious, but certainly how do we make it so that everybody can edit Wikipedia right on down to the source code itself in the same way that we try to make it easy to edit the articles? So, a lot of the focus of the collaboration area is about how we deal with the social dynamic of getting this many people together, trying to agree on a single thing. So, the next area is software engineering, which has a big, has a big collaboration component to it as well, but it's much more, how do we make the system make sense to people so that when somebody comes in as a new developer or maybe they want to learn how to do software development, how do we make sure we're not wasting their time that we make it so that it's easy to understand how this thing's put together and how to potentially change pieces of the system? The next area is about how do we make user interface presentation. I didn't have a good, you know, it's like I could have called this user experience whatever and nobody's pushed back on my naming, but the idea is basically how do we make our sites beautiful and joyful to use and once again make sense. And so, the, and so this is basically in some ways a proxy for what the, there's, we've already had a front-end standards group that has been meeting off and on for the past few years. This is, this is basically their area more or less. Content access and APIs, how do we, this is about how do we get at the data? How do we distribute it? You know, we're generating a whole ton of information. How do we, how do we get, how do we make it so that it's easier to get at all of that information? How do we do analytics on it? How do we do offline reading of it? All of that is covered in the content access and APIs area. And you'll see by the way, there's, at the top of each of these slides, I have a fabricator task number. That's where we're in the process of discussing each of these areas. And then finally content format. So the previous area, content access, that was more about getting data in and out of the system. Regardless of what format the, the, the data is stored in, content format is really where, what format are we going to store the data? What's the canonical authoritative source of the data? What is that going to, how is that going to be structured? What should that look like? So this is basically the wiki text problem in is, is maybe central to this, but I, but is not the only problem. It's also another way, another way to look at this is, you know, what, what audio and video codecs should we use? For example, is another area that, that falls into content format. It's basically anything that we are currently doing now, where we're asking people to edit the data, like we want to make sure that the data is stored logically and that it makes sense. And once again, that we're not wasting people's time by, by the way that we store the data. So those are the big areas there. And there's, like I said, there's still a ton of work to do. We're, we're, we're very busy trying to make, trying to make this all fit into the schedule some way, somehow we've, all of those five areas that I talked about, each of those has a slot in the big room. And so that's going to be each of those areas, that'll be where we talk about some of the specifics. But the other thing is, if you've submitted a proposal, check and make sure if it's on the must have list, if it's not on the must have list, and you're really, and you really believe that it needs to be on the must have list. That's one of the things to ping me about, ping everybody else about. But at the same time, you know, we've got, I think, something like 50 some odd proposals, and we definitely don't have time to get through 50, 50 some odd proposals in, in a two day span. So, so there's going to have to be some amount of unconference ad hoc work to get to move forward on the things that if, you know, if you care about something and it doesn't get scheduled in one of the sessions here. One minute. So, and that I think is everything that I had. Any questions? Yeah, let me relay a comment from my RC and it was regarding making it easier for anyone to edit the code. So, were there thoughts on switching to GitHub instead of requiring people to learn Garrett and fabricator? So, basically, so, like, I'm not going to answer that one, that is definitely something to, to raise at the developer summit. One of the things that the release engineering team is going to, is planning to talk about there is a move from Garrett to the fabricator code review system differential or diffusion, differential diffusion. I can't, I can't, there's so many of the fabricator names. I don't have them at the top of my head anymore, but they, they would like to move to differential. So, so really, as far as like being able to move to GitHub, yeah, that's, that's a whole other thing. It's a good discussion for the summit. Any other questions? No? Right. Thank you, Rob. Let's give him a hand. Right. So, our next speaker is remote Yuri, and Yuri, hang on. Hello. Can you see me? I see you now and I can hear you. You can hear me? Yes. Wonderful. All right. Let me now try to share the screen. This is the tricky part. Sometimes it breaks. And I hope you can see everyone can see my screen. Yeah, we see you now. Yeah. Excellent. All right. So, I am part of the discovery team, and my personal passion lies with content. I'm a firm believer in rich content. So, I even created this big page about I dream of content that some of you might have seen. It discusses various aspects of how we might progress is in terms of my first perception, of course. But I try to make good on that perception. And one of the things I've been working on, and it's all life and in production on all Wikipedia is graphs, but not just regular graphs. They are interactive graphs. You can click on the play button, and the graph becomes interactive. And you can drag things around. You can see things like what cities, what air airports are connected in which way. So, see, you can see the different airports, and you can do things like zoom in and zoom out. Or whatever else you do. This is a Vega graph, a Vega grammar. It is fairly complex, but most people do not need to know that grammar because most of the time you simply will use a template. You can take graph chart and you specify some data to show, and it will plot it for you. People have been creating a number of very nice templates. This one is concentrating on popular articles and article ranking in different areas, or maps, and how to draw stuff on top of maps and customize them. Also, I've created recently another graph. This is thanks to the wonderful analytics team that created PageView API. And these graphs actually dynamically show the current, this is the last 30 days of this current article. As you can see, as more people started being interested in graphs, the PageViews went up. This is the main page. I guess no one is interested in Wikipedia's main page around December, simply because everyone is going into partying. So, as you can see, graphs can do much more, and we can fairly easily add these graphs automatically to every talk page, for example, so that a person can see what the popularity of the current article is. And now I'll switch to something I've been working on for the future. This is the maps. My other rich content, open goal. And it basically will allow WikiVoyage or eventually Wikipedia's themselves to not only see the maps, but also to draw additional things on top of them. And not just draw them, you can click on them. Oh, it's a fun zone. And you can click on that. Oh, that's Exploratorium. Or how about this? You click on that and you see a cat video. I think cats are extremely important. All right, I'll hide that. Other interesting things about that is that you can, right there in the articles, you can simply add additional pieces of information to the map via some templates. For example, you can say, oh, here I want to add a museum. Or I want to add a gas station. And as you can see, it adds little icons that you get to see. And it's all grouped. So you can actually see, oh, and here show everything. And here only show the museums. Or here just show the gas stations. That kind of stuff. And you can highlight certain areas on the map, highlight whatever items you want. This is WikiVoyage style usage. And I am done. I would love to hear some questions. May I stop the presentation? This is difficult. All right. Always I have a question. And I remember a few months ago, there was a Google Summer of Code project. I think it was Frederick Bulldoch who wrote a nap to make it easier to create a chart because the Vega grammar is complicated. How has there been any more progress on that to make it easier to make a graph? Actually, there has been. It is actually surprisingly, not surprisingly, it's wonderfully, it's in production. You can click insert and insert chart. The problem that I see with it is that now we're like slowly, as we learn to interact with the graphs and use graphs to the fullest, graphs are fairly complicated. And yet they contain a lot of repetitive parts. If you want a line chart on a thousand articles, you don't want to really duplicate those thousand lines to draw that only differ in the data portion. So it would be better somehow to design graphs as templates and then insert them as templates, just like I showed in that example. So even though this functionality is working, I have seen a lot of people inserting very rudimentary graphs without spending too much time customizing them. And as a result, they were not perfectly calibrated. The axes were off. The labeling position was not very good. And all these things could have been fixed with one template. But instead, we end up with many different instances of that graph. And I think it's a dead end. We should really switch the templates for that. So his work should probably be concentrated on designing the templates using that extension and then inserting them very easily inside the other pages. Well, thank you. And just for the people watching this video, what's the easiest way to add a graph? Like how do you, where would they look to get started? The absolute easiest way I found is the German Wikipedia wrote this amazing template called graph chart. It's a template graph chart. You simply, if you go to the its documentation, it shows like 15 different types of graphs that you can generate. And you just supply parameters like the data points, and then it will draw whichever graph you want. If you want to really get deep into Vega grammar itself, that would be wonderful. And that's, but for that, you will need to go to Vega website and see how Vega grammar is constructed. But yes, that is more complicated route. The easiest is graph chart or any other template that uses graphs. Cool. All right. Thank you very much, Yuri. Let's give him a hand. Thank you. All right. Our last speaker is Dan. Hello. That's me. Where are my slides? All right, great. Hi. So I'm here to talk to you about a better search for Wikipedia. So how often have you been on Wikipedia and you've wanted to read about the unieted states? Fortunately, we have an article about the unieted states. So what's actually happened here, this is the search box at the top right of every article. And what's actually happened here is the search uses a prefix search. So it looks at the start of the title of all of the different articles. So if I make that typo and put one character in the wrong place, then in principle, I should actually get no results at all. We don't have an article called unieted states. As all good Wikipedians do, they worked around the limitations of the system. They started creating redirects. So there is an article called unieted states. It simply consists of a redirect to United States. So in this case, I click on that. I made a typo. It's fine. It's a bit of a confusing experience because I now think I'm actually going to read about something called the unieted states, but it works. There are cases where this doesn't work though. So in this case, I'm looking for Strasberg, but I typed a D instead of an S, the right next to each other on the keyboard. Turns out Wikipedians haven't anticipated this particular typo. So in this case, I actually get no results. And I can search for articles containing this term that in that case, what will probably happen is there is a kind of, did you mean functionality built into the full text search? It's not displayed here. So I would probably eventually find the right thing here. And in here, I just pressed the E key once too much. And instead of looking for electric eels, I looked for electric eels. And again, it's the same problem. I didn't get anything. So this kind of may lead you to wonder why we have this prefix search at all. And it's fast and it's scalable. So it's fast in the sense of the user. So they type and they get results really fast. The scalability is because it's really computationally cheap to just check the start of an article's title. So that's why we use prefix search there. But I've kind of suggested that there's a lot of problems with it. So why don't we just have something nicer? So I'll tell you what this is in a minute. But here, I've entered with the something nicer, I've entered the same query I got before, and I've actually got a load of results. You'll see the typo has been corrected. So I don't think I'm actually going to be reading about the United States anymore. I have a load of other suggestions. With Strasberg, I accidentally corrected the typo in the screenshot. So you don't actually see what happens. But it corrects the typo and you'll see that here. So in this case, same thing, the typo, you can see that the results probably aren't ordered the correct way. Like electric eel shop probably isn't what you want. You probably want electric eel. So the point I'm trying to make is this new thing that I've just mentioned is called the completion suggestor. So it's actually live as a beta feature on all Wikimedia wikis. So if you go, if you're logged in, and so that's accept data. So if you're logged in and you go to any wiki accept wiki data, go to the beta features tab at the top right and click completion suggestor and turn it on, then you will see these new results. And it's really good at detecting slight typos. So it can it can typically detect two typos. So if I type in electric, that's actually a typo. I've got one extra character in there that shouldn't be in there. If I type the D instead of an S, it can find Strasberg. If I have unieted states, it not only detects the typo, but it corrects it and then shows me the right results rather than showing me results for the typo. So it's really nice. And it's limited to the main namespace right now, purely for technical reasons. So it will only work if you're searching articles. If you turn the feature on in beta features and then search outside the main namespace, you get results from prefix search. So it will still work, but it doesn't have the we've not built a search index for those other namespaces. So we've also got a lot of work to do before it's ready for a full roll out. So we've really like the agile philosophy of release early release often we've really done that here. There's a lot of technical stuff that needs to be taken care of first. The API for this isn't very well put together at the minute we've like really tried to get it out super fast so that people can test it. So we need to improve that. We're hoping to do a more full roll out of this in early to mid 2016. But that really depends on how long it takes for us to improve the API integration. Depends on user feedback. If everyone tells us they hate it and there's all these things that are wrong with it that it doesn't do, then obviously rolling it out wouldn't be a good idea. So that's the timeline we're looking at here. We love your feedback on what's missing. So this points to a page on mediawiki.org the talk page for the completion suggestor. So if you don't want to use the short link, if you're in the click on the beta features tab and click discussion for the completion suggestor, you can add some comments there. There have already been a couple of good comments including in what I think is an Indian language which I don't speak. So I would appreciate if anyone wants to translate some of the comments in there and that would be nice. And so there's some further reading here. Technical documentation, user documentation, a few of the announcements. And in particular, the fifth one there is a report. We did an AB test of this completion suggestor and it actually reduced the zero results rate quite significantly. And you can kind of see why with some of the screenshots that I showed you where I typed in electric eel and got nothing before but get something now. But that test was highly limited though in that it didn't tell us whether the results were good or not. It simply told whether the user got something. So while we like qualitatively and intuitively believe that we are actually giving users better results, we don't have the scientific confidence in that. So that's why we're putting this out as a beta feature for people to try. I think the clicker isn't working because that's my last slide. So yeah, thank you. Any questions? So will there be a new dashboard on search data which lets us know how this is doing for zero results, etc? So right now, we don't have a separate data collection. So the main purpose of this test was for qualitative reasons, as I said, so we're going to add in some more quantitative collection. We've got all of the standards like data collection that we have, but it's not tracked separately right now. We do want to do that. Yeah. So and that's searchdata.javaflabs.org is where all of our dashboards are. You can also get there by going to discovery.javaflabs.org. So there's search data and there's, so when I say R, I mean the discovery department. So we've got a dashboard for Wikidata query service, dashboard for maps, dashboard for wikipedia.org. We've also got an experimental dashboard where if anyone wants to just push a load of graphs there and like check them out and like get more familiar with data collection, they can do that. So that is useful, for example, for something like Yuri, if he's working on graphs, then he can push some graphs about graphs to the dashboard. Yeah. Any other questions? And since we've got two apps guys in the room, there is an API for this. Don't use it. It's like I said, it's really early right now. So it doesn't do things like page images. It doesn't do Wikidata descriptions. There's basically no parameters. So I think you probably only gonna get 10 results. But in the lot, like one of the things which I alluded to that we need to do is we need to integrate it with things like generators so that people can use it and they can add in page images and like hopefully with other API modules, it's really like quickly put together in the minute for the purposes of the test. So yeah, if you want to try it out, it is there. It's on the API. All right. Thank you very much. Let's give Dan a hand. And that concludes December's lightning talks. It's possible there will be no lightning talks on January because of all the things going on that month. So stay tuned for the next one. Thank you.