 So hi and welcome. My name is Volker Echel. I'm Senior User Experience Engineer on UI standardization matters using the phase standardization matters here at the Wikimedia Foundation and I would like to present to you together with my colleague Jonathan Morgan the study findings of our research on Wikimedia contributors front-end needs. Jonathan will Jonathan would you introduce yourself? Sure I'm Jonathan Morgan I'm a design researcher on the design research team which is part of the overall research team here at the Wikimedia Foundation. Jonathan will tell you later more about the methodology used and the sorry Brendan there's a technical issue. I can still hear and see everything fine if that information is useful. One little moment people remotely he used that little break more more time for that gesture. Thank you. So one more time Jonathan will tell you later more about the research goals and the methodology used for the first few minutes I would like to set the field for for our I would like to set the field for UI standardizations topics that we are facing and would give you a little overview of different different things that we've different issues that we've been running into and thinking about. So we've started with looking at the internals in the it looks as though San Francisco is freezing came to my knowledge about the libraries that and the shared styles that are currently used so we have media wiki style sheets for general and common course styles which are the most ancient and most dredged ones we have jQuery UI still in use in media wiki we have Agora styles left over we have media wiki UI we have OGS UI which is the modern and agreed on approach we have pure library which is used in parts on the media wiki media portal we have semantic UI one and two by analytics we have bootstrip two and three on older versions of analytics and we have custom styles used in mobile front-end echo universal language select and so on. So there's quite a diversity in UI styles internally I've made a nice little collection of buttons and nice inventory of just surfing 15 minutes on English Wikipedia and this was the outcome so consistency as you all might know and I will I will be here to put the focus on it is one of the most fundamental design principles without consistencies people have serious problems in the mental models going for tasks on resolving the tasks on interfaces we have another contemplation slide here fonts we use different font stacks for the same type for serif font stacks we have we have two different implementations for sound serif font stacks we have three different implementations across currently in use products so why did we speak with with our users foundation employees and volunteer with media contributors we've been reaching out to Wikimedia Foundation employees and to contributors on various platforms and to Wikimedia Germany developers are designing and implementing the user interfaces in all different ways trying to resolve their challenges I want to give you some examples this is the evaluation portal it was it was in large brought in place by with Galvez and Maria Cruz of the Foundation having several needs like multi-column layouts like a special focus like a special highlighting sections special needs on their links we have Wikidata which uses and big parts own styles based on vector it is from an editing perspective a complete very strong challenge we have things like the resonator a tool that make Wikidata capabilities by Magnus Manske it shows related significant data through simple reasoning therefore the name resonator it has it has an interface that is based on bootstrap because he is aware of bootstrap the murder for that later we have bet scan a powerful querying tool again by Magnus Manske it's used just a tweet yesterday by him it's used on average once every 23 seconds so it's quite a popular tool out there and his last example wiki project wiki project was brought into place by contributors is our eyes well known on and as we see here complete different layout again complete complete different challenges for for the users and the most amazing thing and we talked about font stacks before the let's take Wikipedia to the moon banner it uses text which has been the font about a few years ago and it's now here in place again so far for the for the introduction and the field setting challenge please sure so when I joined this project Volcker may had already started doing research on current users and potential users of Wikimedia's UI resources particularly the OHS JS UI library and and one of the things that I saw as I was looking through that initial research I was struck by the wide variety of different types of design and front-end development that were occurring throughout our movement among staff members of the Wikimedia Foundation and then more broadly among the designers and developers who are building content and building tools on wikis and then off wikis as well to support the movement so as we started to explore further and talk to more people we set our research goals variable broadly we wanted to learn more about the the direct stakeholders of front-end UI resources or tools so think about that as people who build stuff or people who build stuff for other people in the wikimedia movement whether they're building for readers whether they're building for other contributors and we started to develop a set of questions to ask them about what they're building currently what they've built what workflows they follow as they design new tools or new pages or new types of user interfaces the specific tools that they use to to build to build what they're working on and then what are the benefits and potential shortcomings that they see in the tools that they're using what are the challenges they face and what are the reasons they would select one set of tools over another and finally we were also obviously interested in to what extent they were utilizing the front-end UI resources that the wikimedia foundation had created and was interested in evaluating so overall the rationale for this for taking a broad approach in this research is that we we realize that terms like front-end UI and design and tools are very very broad terms and they can mean a lot of different things to different people and describe their work and we didn't want to artificially exclude anybody from from the conversation because because we didn't consider what they did to be UI work or because we just hadn't considered the kind of work they did and we thought that this was an excellent opportunity to take a broad approach to research here because there was we we'd reached a decision point around how the wikimedia foundation was going to support UI standardization moving forward next slide so our overall methodology and this this includes research that was conducted by me before I joined the project as well we conducted focus groups and some semi-structured interviews with an overall with 19 people who are members of our movement in one way or another seven of them were staff at the wikimedia foundation three of them were staff at wikimedia Deutschland and nine nine of them were volunteers who contributed on their own time so as we were as we were talking to these contributors we we started to characterize the work they did in in in two broad categories we found that there were there was a group of people who did UI work at the at the page level on on wikimedia websites we call these people page designers I had I had direct experience with this through work I done previously with the tea house and the ideal ab and other other spaces on wiki that are curated by foundation staff and that and that provide an interface with the community for outreach or communication education coordination you could also think potentially of wiki projects as these types of user interfaces the second group were people who fit more cleanly into what we what we in in on the product side of things tend to think of as front end developers people who are building the basic interface for media wiki who are designing extensions but also people who are working on different types of of user interfaces that that may not necessarily be considered developers in the in the kind of traditional sense of the word or at least rather rather not are often not included in the set of people we consider to be developers and those are people who are developing user scripts or gadgets or even standalone web applications that work with with wikimedia content or are used by wikimedia movement contributors to get their work done so they could be building things to support readers or or contributors or even researchers thank you very much so within our within our research and in our interviews and focus groups we found common patterns of needs answering to our questions about their workflows about their libraries that they are using as Jonathan mentioned and those comments that comment patterns we want to share with you here they have to be aware of an existing solution if a UI library does not exist on their radar it's not non-existent the more people talk about it the better for it's applicability the quote by community developer no one ever talks about it and he meant he referred to OHS UI it's not on on his radar it's not on wikitec L documentation has to be easy and easily accessible when it comes to looking to a documentation I want to see examples again a community developer with his quote community is a strong indicator for finding answers people were referring to there was also the the term support network if the support network is available another quote if you run into trouble you find something on stack overflow if this is not true for the front end solutions that their solution it might not be their solution easy learning curve ease of use it felt intuitive for me to use OHS UI quite close to bootstrap wikimedia Germany developer so you have those those opinions on both sides we collected a whole bunch of opinions and I would be happy to share those accotations with you afterwards modularity fewer dependencies as few dependencies as possible in modern development I want to take tiny pieces and fit them together into big elements rather than using complex elements and customizing them from wikimedia Germany so a different a different perspective a little different perspective for a specific questions bias on what contributors how contributors are choosing is mobile support a deal for them yes in parts they would like to see that it is not it is not the biggest issue they want to they want to have it solved as a side by functionality accessibility measurements again a broad field how much can how much can you provide as a user interface library on that that already solves my problems no JavaScript support was mentioned by several people we were talking about sorry I had to I have to say the mobile support this was a big topic among the page designers group as well mobile support is for them a big a real big thing that they want to have accomplished when they are when they are grabbing a solution internationalization and localization and translation challenges this was the most named asset from page designers and also in parts from wikimedia Germany developers the more library solves that for me the better it is I have I run into problems every time when I try to localize my my front end so I want to I want to have this address very early on especially in our environment of wikimedia foundation with our global outreach what are the primary barriers some of the points are clearly just mirrors of the first two slides time is cars resources are limited this is this is like them this is like the main title for people and the main concern they are contributors they don't have lots of time to spend they want to get things done steep learning curve hinders them in getting things done missing or unclean documentation same topic missing community to find answers the anti the antidote to the to the quote before about stack overflow adaptability or extensibility of the framework and together with adaptability the process the process to request new features process for adding to just UI or core it was meant as we don't know about the process at all is not clear to us OJS UI team really wants people to use it they want feedback from the media Germany again so so it's it's clear it is seen that it's a welcoming thing but the process has issues and and needs to be addressed so what are the conclusions for us for us talking with with our group with me with Jonathan from the outcomes in general community community involvement for long-term success of our work that we're investing we we should try to to address community needs and include them in the development early on that is that is a long that is a long-term success factor from the communications we have it's not necessarily that the so one of the questions that came up is is encouraging more community ownership something that would make sense we are not quite clear about that but still without without having a community behind its development it's hard for a long-term sustainability open development and establishing support support on documentation support on the process for us in the decision embracing technological pluralism and the diversity that we have out there in the in the different solutions people are using different solutions and we as US and decision with US and decision matters address people we have to we have to embrace this diversity and kind of get people using still our designs to make it across the products working collaborative process to documentation something that I that I've tried and may start has been taking lots of measurement on that started to to put people to reach out to people to help us with the documentation points all of the before said things about the general approach on making a successful front-end library is also clearly true for us and the station so inclusive process inclusive establishing collaboration channels and so that were the conclusions thank you for your attention and I would like to invite you to post questions if you have some Jonathan anything from your side before going into the nothing here nothing here so how many how many people did you survey that were software engineers I seem like a lot of quotes for from wick community Germany developers for instance were there any wikimedia foundation developers interviews as well wikimedia foundation developers we have not asked for a specific reason because within the foundation it is it is clear that we have this one thing to to draw on and to push forward and which we wanted for exactly that reason having emerging developers like wikimedia Germany asked for to see what what they are facing right now in their workflows and also we were reaching out to community developers for exactly that reason so no we did not ask wikimedia foundation developers may do you want to ask a couple but not that many so we have we I think we went around there was to developers from the foundation and page designers that were from the foundation well in terms of developers only to yeah the developers were part of your interviews we were focusing on the presentation on the focus results that the two developers were if to make that correct from the interviews that you've taken back then mm-hmm hey I'm speaking now and it's like cool so thank you thank you for this it strikes me as interesting to get such a broad spectrum of sample quotes for example about OUI and it kind of speaks to maybe more of a need for kind of communication and leadership around that I would say that there's also a need for that inside the foundation as well I think there's a bunch of different technologies and honestly I don't care which we use as long as it works but some people care a lot more and I think we need to do both not just they kind of make sure that our communities of people are able to to do what we recommend but that everyone is clear of what we're recommending and hopefully why and as part of that a hey I think this is wrong and this is why conversation process I think that'd be great I completely agree and we also wanted to present it in a very open way this these are learnings that we have from a few different very very pronounced people but a few different people and the more we can we can learn about their pain points the better work becomes clearly yeah I just record like a I think it was maybe a year or two years ago the release engineering team ran a survey around vagrant to look at pain points and that was internally just as a follow-up to this it might be interesting to do something similar because I think vagrant I improved dramatically after the survey because it was very clear like what people's pain points worth in speed was one of them no lots of improvements that came afterwards it just like a form like a way we could take this forward briefings would you give me as this was before my time would you give me was it more a technical survey or what were the constraints to this I'm sure I can dig it out there I don't think it was technical it was mostly like I mean what is like your main pain point right now with using vagrant like if you could change one thing would it be like they're kind of open-ended questions but I feel yeah I think I think it's been great that you've gone under some people outside the foundation to get their opinions but also you could check in town as well okay thank you one thing that I also want to mention is I've seen this by Florian Schmidt well so so when we're talking about community about support networks I found it very interesting and a little nugget that they were putting out the conversation from a patch set to stack overflow they were they were taking the the conversation put it on stack overflow and let it respond let put a response response there which gives visibility and it's also nice it's a nice I don't know how successful this is but just as a just as an idea a nice way to involve a community and and have more outreach on certain levels all right hello I don't quite have a question more like well maybe it's a question so volunteer developers how I guess how do you see this work getting carried forward will you be working more with foundation staff on it will it be more of a volunteer community initiative like what's where what's next I'm not what you're referring to would you would you say that again or or try to reformulate that for me which work to carry on question mark UI standardization is it something that foundation owns is it something that comes from the community set something about like you know taking in mind the communities you know the diversity of the community and what they develop because I'm again I'm not a developer so I'm trying to like understand though like how could the community support this work in the future is maybe a better thank you Edward this is a very good question as it comes down to a lot of different things support within the foundation resources clearly because community as we all know is it's not a community is not growing on its own it needs it needs constant interaction and it needs to to have early being early addressed and being involved in it in a very time intensive way to prosper from my experience for sure when I when I started here I thought I want to I want to address all the needs very soon it became clear that I have to be very picky about what needs I tried to address first that way that we've we've been starting me has a big part in that is involving community early with design guidance and I would like to continue that but again this is a this is a one-person show right now that is embedded in a in a very powerful team so we are we are on the way of finding out how to put the priorities right how to make that the priorities right and go from there on your question how to involve community in our first development I have a question or so but what like what's next after this presentation so for example at the beginning you had like a list of a lot of UI libraries or a lot of UI terms that people may read online and don't know exactly what it's about like do we officially basically like document and recommend a way like some libraries or do we officially recommend to use UI for example and like then then we saw in in the comments that people may use bootstrap because they want something that is like easy to use and has a lot of support and and and for all those reasons to get started quickly and and bootstrap like provides some very quick templates to be the bootstrap page with like a navigation bar and and for example if you look at reasonator it's not much complicated it's it's pretty much just a navigation bar on the top and and then some some like basic styles that that he was that he needed to be the application to make it a beautiful so and and and if we look at the OUID demos we we don't have I don't think we have like some examples of like a bootstrap page that people could start off you know like people could just download and and start like like quickly quickly out of that page with just a navigation bar and like some navigation drop-downs and other stuff so is there anything that is like being done or being designed in the background to potentially like say hey if if if you're a community developer and you want to build any sort of application just use that bootstrap page and and you can start from that and and and you can like use all those which it's from the UI library and all that thing and I don't know how complicated that would be might not be that complicated and enable a lot of people to start using OUI. Thank you Trudin for your comment. I'm definitely not the right person to give answers on all those this is a this is a thing there are questions and we should prioritize on the questions and think about how we can how we can address them with our limited resources time resources. The one point that we've been coming up before I've joined editing was the agreement on making a base CSS for the basic style sheets that can be used then with whatever technical implementation OJSU is the main consumer but the technical implementation that you're using and I think this is this is we will we will in the short term not convince anybody to use just one library that is my personal conviction that that I'm not quite sure how other people here think so if if I'm coming from a US organization standpoint I have to say I want to I want to make clear that the basic style sheets can be used with whatever technology is out there because this is a foundational this is a foundational decision and should be and should be a part from any technical from any strict technical implementation because there's fans of all kinds of limitations for a good reason every implementation has its pros and its cons and as a US organization folk I have to say okay how can I how can I bring them together and BCSS is this approach from my perspective we will see out how it plays how it is how it is working but I'm I'm looking forward to that actually to your other question that is more a foundational question I don't as I said I think I'm not the right person to answer it here okay any more questions here people are getting a little little slow by the blinds down I guess missing sunlight and vitamin D thank you remote participants thank you Jonathan okay I think this is thanks as well thanks everybody say two more two more words thank you Abby for supporting our interview facilitation Leon and the process user research has done a great job here thank you May for all the hard work with the interviews and with the iterations and yeah it was it was great talking to you