Wikimedia Engineering/Product Strategy Offsite
2 Day Product Strategy Offsite
[edit]
Participants: Howie Fung, Erik Moeller, Ryan Kaldari, Matthew Flaschen, Steven Walling, Maryana Pinchuk, Jared Zimmerman, Vibha Bamba, Tomasz Finc, James Forrester, Trevor Parscal, Ori Livneh, Jon Robson, Terry Chay, Brandon Harris, Dario Taraborelli, Fabrice Florin, Kenan Wang, Erik Bernhardson
Meeting Notes, Day 1
[edit]Howie: Thank you everybody for taking the time to be here. I wanted to kick things off by talking a little bit about why we are doing this. This past year was a really big year for us, please take a look at the chart on page 2, the chart basically shows the number for features that we’ve collectively, as a team, have released this past year and I think that everybody should feel really good about the work that we’ve done - it’s really awesome.
At the same time, I don’t think that we’re operating as a team, people generally know what their teams are working on and why they are working on them - we don’t have a shared goal across all of our teams. I’ve read feedback that people don’t really know what the big picture is, so part of what we wanted to do over the next 2 days is to create that big picture together.
In terms of the agenda, we’re going to spend the first hour reviewing some material, this is to give us some base of knowledge on our projects. We’re also going to have each individual team share what they have in mind for next year, keep in mind that these are not firm plans for next year... In the afternoon we are going to have conversations around interdependencies... Tomorrow morning, we’ll talk about the next 2-3 years out, so ask ourselves, what types of things need to be in place, how are trends that are affecting the internet impact us and how do we as a team and a movement respond...
...Part of what I think we don’t do well is describing our work internally (to the foundation) and externally to the community, so we’re going to go through an exercise in describing our work. Any questions?
Erik M.: I think you said the important stuff already, Howie, is that we now have a lot more things in play than ever before. I wanted to ask here in the room who was there during the vector roll-out either as a volunteer, or as a staff member? So that’s like a third or less of the room here. Part of what’s happened in the foundation is that we now have vector-sized projects in play in multiple departments at the same time. Vector was a big deal in 2009/2010 and it actually meant that all of mediawiki core and the other parts of the development community needed to be aware of what was happening and we did do an okay job with that and over time managed to embrace it as part of the mediawiki technology ecosystem, but now we have a lot of things in play and our capacity to grapple with that is pretty poor. Particularly, as Howie mentioned, if you think about Flow, Flow is about discussions and discussions are an extremely important part of collaboration, collaboration in our context means working on articles, so we really have to figure out what discussing an article should look like in 2013/14 instead of necessarily just copying the model of the talk page or even copying models of other sites. So we have to examine things in context, in the context of these many vector sized projects that we have in play....
---Team Introductions---
Howie: ...when we look across our projects, there are four key disciplines involved with our work - there’s product, engineering, design and data. When I look at our projects, I can think of us doing any one of our projects without those four disciplines, so that’s why we have the people that we have here. I do want to emphasize in terms of how we work that these four disciplines are peers... we’re a collaborative organization and the spirit of collaboration needs to be present in how we work... Any questions on this notion?
Terry: ...we do a lot of stuff like Howie mentioned and there’s a lot of us... what I’d like to come out of our conversations is that if we could come-up with principles/habits/frames/patterns - whatever, to describe the things we do and the reasons we do them, so that even if I was about a project that was in Mobile, I could answer the same answer Tomasz would answer because I know we’re operating from the same playbook as each other... whenever we do things, I think we’re really good at focusing on small things and we’re very good at talking about the vision, but we’re not good at bringing those things together... I think this would be an amazing outcome.
Howie: Alright, let’s start it then. Let’s go to page 3... some of you are pretty new and I’m not sure if you have seen this information, so I’m going to walk through this pretty quickly and it’s broken out into forces that shape our existing community, drilling down to our first edit, talking about the edit-reversion system, and finally the career path of Wikipedia. As I go through this, I’m probably going to skip through a lot of slides, but I wanted everyone to this information in one place so you can hopefully take a look at it in your spare time.
So let’s go down to page 4, I hope everybody has seen this graph, this is the graph of active editors on en wikipedia, and what I did here is I’ve broken this up into 3 phases: start-up phase 01-05, hyper growth phase 05-07, maturity phase 07-present... this is kind of a retrospective... If we go to the the next page, let’s drill down into this hyper growth phase because I think a lot of what’s happened in our community, has been a result of what happened between 2005’ish and 2007.
So what we saw during that time period was an increase interest in Wikipedia... a lot editors were entering the system and what ended-up happening, was to deal with the onslaught of new editors, the community put down a lot of processes to basically ensure that the content would be of high quality.... during this period, there was a lot of focus on increasing the quality of the encyclopedia. Another thing that happened during this period was we started to see the introduction of bots and automated tools, and again, part of this was to deal with the onslaught of new users and a focus on quality. So Twinkle was introduced in January 2007, Huggle was introduced in January 2008, so as you can see, during this hyper growth period, there was a lot of things that happened in the Wikimedia community and a lot of these things actually exist today. This is kind of the legacy of this time period.
And if you go to the next page, this is the retention rate of users and how that retention rate dropped during this period......
Jared: Do we have any understanding of how this looks against other online communities? ...like these same patterns, same numbers?
Brandon: The wiki-verse, others tend to have the exact or very similar growth graphs. The one exception is actually wikiHow and that’s just because they started turning it around, so they actually have an uptick.
Steven: So did they see a similar dip happen?
Brandon: Yes, they did see a similar dip happen, but they actually were, interestingly, in a position where they could start experimenting with gamification with their software in ways that we and Wikia cannot, or have not...
Ori: ...looking at edits made by new editors gives you a sense of their quality along one dimension of quality, but there could be other factors like general computer savviness and things like that may influence retention that isn’t necessary reflected in the substance of the edit itself.
Steven: There’s also standards...it’s really obvious just from looking at policy and how experienced editors react to new editors that a large degree has to do with increasing standards for quality....
James: ...the first response you’d likely get as a new user is, “Hey, I see you made this change, this is not allowed, this is not the policy, read the policy first please.” Even if it was nice, it was still bad...
Howie: ...last year at Wikimania, there was a session on wiki culture...where there was kind of resounding agreement in the room that of those people that had been editing Wikipedia for a long time that if they made their first edits today, they probably would have not gone back. There’s a recognition that the system is not as encouraging for experimentation and as encouraging place as it used to be.
Jared: When you talk about the quality of a new users edit...?
Brandon: ...when we were stuck in ACTRIAL and we were having a serious problem, the ACTRIAL was this thing that happened two years ago where the community came together and they decided that in order to create an article, you had to have auto confirm status which was a high bar for a new user, and the people who were claiming were saying that all the new articles that were created by people that don’t have auto confirm status are really low quality, and by that they mean no references, or one sentence stubs...
Maryana: So by high quality, you just mean that it wasn’t vandalism, it wasn’t a test edit, it wasn’t malicious, it was fairly legitimate...
Jared: Quick question, can someone define the exact meaning of this retention rate graph?
Howie: Yeah, it’s users that have joined Wikipedia. So let’s take a look at January 2004, so that’s a cohort of users that created an account in January of 2004 who had at least 10 accumlative edits, the subset of which ended up making at least 1 edit in January of the following year.
Let’s move on to the next page which gives a list of bots and automated tools...some of these are actually helpful...most of these I think are bots that have helped the community deal with the onslaught of new work, but may have had unintended consequences when it comes to how the community treats newcomers. For instance, when you think about Twinkle, it’s a very helpful automated tool, but the way the interface is, it actually lends itself to some pretty harsh interactions which we’ll actually walk through.
James: I just wanted to jump in here “unintended consequences” -- possibly assumed too much good faith. [point here is that some of the tools had the intention of, for example, pushing users away]
Erik M.: To be fair, we are really dealing with an increase in vandalism...there is inexperience like if you’re in the process of being a new page patroller or a recent changes page patrol, you do see a lot of spam, vanity biographies, conflict of interest edits that puts you into this (frustrated) mentality...
Brandon: Huggle keeps a kill tally as you go, it literally gamifies destroying pages
James: And users
Howie: The next page shows the percentage of messages to new users split up between actual human messages and bots...and what you can see that the rise of automated messages increases dramatically between 2006 and 2008...I think it’s something like 80%’ish of all new user messages are delivered by either a bot or some kind of automated tool...
Siebrand: I think this is exactly the same graph we saw last year; is there an update?
Howie: No, it hasn’t been updated
Erik M.: A lot of this data came from the Summer of Research - a one time fundraising effort that Zack organized....
Siebrand: ...it would be interesting to see what the current situation is...
Brandon: ...Mako released a paper yesterday that says that our gender gap is completely different - closer to 33%
Howie: So page 9 summarizes these forces...(policy proliferation, rise of bots/automated tools, change in mentality from fun/creation to protection)...Let’s move on to the first edit...look at some of the work the E3 team has done...(review of page 10, 11, 12 and 13)
Terry: What’s the other 14%?
Maryana: Probably other tools, I mean there are a bunch of other surrounding tools...
Howie: (page 13)...if a newbie gets reverted, they typically go back and find that the article is missing...so that pointed to the absence of notifications...revert is off by default for new users, is that right?
Fabrice: Yes, we took it off because it was a slap in the face of the new user...
Dario: ….
James: I think that not telling them that they’re going to be reverted is more of the slap in the face...
Howie: ….users don’t necessarily know that talk pages exist...that points to the need for a discussion system....and even if they do find their talk page and see that there are messages, there’s a lot of ambiguity on who these messages are from - are these from bots or users...this points to the need for profiles that users can understand...so this type of analysis led us to the next page (page 14)
Erik M.: Do you want to speak briefly about affiliations? ….
Howie: Yes, so affiliations is the last piece.... Wikipedia doesn’t do a good job of giving you other things to do...we know that when users move through the life cycle, they tend to edit based on a topic area...if you are actually interested in say wine, there’s no way that the system reaches out to you and draws you in. What ends-up happening today is somehow you have to find a wiki project, so the notion around affiliations is that users have an interest rout whether they express it explicitly or whether we can infer it...the notion of affiliations is matching that interest rout with work that needs to be done on the wiki. (review of page 15 and 16)
Tomasz: Are majority tools usually English based?
Howie: Yes
Tomasz: So purely English, no other languages use these tools?
Maryana: Yes, they do actually...German, Portuguese...
Siebrand: It takes significant community effort to actually make these tools work.
James: There’s also a tool you can’t use on en wiki because of a preference change we agreed to in 2005 called …
Howie: (review page 16 and 17)
Matt: What does the playbook actually do?
Howie: It starts the whole thing. I actually have a computer with Huggle loaded in the back (of the room) if you guys want to take a look at it...the next page is the interface and the resulting message... So you can see that as a new user, if you got these messages, you’ll be like, “What’s going on?”
Brandon: In the user tests that we ran about this, we actually used the nice template and it 50/50 whether or not a users can detect if a human left it or a robot.
Kaldari: Isn’t this a little bit outdated though because on en wiki we have a page creation tool now which about half or less of the page curators are using now, we actually built that with a lot of this in mind to try to improve it, where we put a lot more options for positive feedback like wiki love, and then we also tailored the warning messages to be more personalized and less verbose...to hopefully improve the experience for people who were creating the articles...
James: …
Kaldari: Yes, it’s only for article creation and it’s only on en wiki
Fabrice: Also the number has declined greatly, it used to be at 56% and it’s down to 15%....
Brandon: Do you know why?
Fabrice: No, no yet.
Howie: The next slide gives you another piece of analysis...what we see over the past couple of years is that the percentage of templates that involve criticism has been growing quite a bit and the ones that involve praise is rather sad. The next page gives you reversion rates... The next page shows that many editors end-up leaving because of conflicts with existing editors...
James: It’s also the number one troll complaint on news articles...
Tomasz: What’s the date on this?
Howie: 2010
The next page if about finding the right kind of contributor and this is just more food for thought...
Brandon: ...this speaks to a philosophical question I know we had for several years about the distinction between whether wikipedians could be created or if they are found...and this reads to me that we find them, we can’t make them...
Howie: My position is that if we really believe that Wikipedians are made not born and we think the interface is good enough to attract the ones that are born, then what are we doing here?
Brandon: What my view here is that Wikipedian is kind of a mindset...and I think our software is a barrier to have most of those people willing to join...
Steven:...I think the things Wikipedians are saying that motivate them we could map that …
Howie: (review of page 22)
Kenan: Despite the fact that the software is the same?
Howie: Yes, despite the fact that the software is the same and that was Joel’s main point....
Fabrice: ….for the past decade we’ve basically assumed that anyone can edit is the right thing to do and I’m getting growing concerns that the basic principles may need to be revisited. A lot of the negativity that we get is in a large part do to the fact that anyone could edit that our editors are so focused on dealing with vandals that perhaps having some small barriers to entry, very minimal ones, ... could potentially be beneficial.
Howie: We’ll talk about that more tomorrow morning. We’re running 5 minutes over, so I just want to point people to a couples of things (review of page 46, then to page 24) ...when we take a look at users involved in the meta spaces, a lot of them are class of 2007 and before...(review of page 28)
--- Break---
Howie: ...the goal of this is for each of the areas to describe what they had in mind for next year and kind of why, so that we can hear as a group what everybody is working on. … The spirit of this this is really for understanding.
James: So, VE goals for 2013/14, so we are now the default editor on one wiki right now out of 900... We are not the best editor we can be; we do not cover all content, we do not enable all users to make preview edits without having to worry about wiki text and these are things we want to fix. We’ve got the here as continue to develop VE features; fixing bugs and stability; improving scalability and performance. … We’ve kind of broken up the year in kind of a bunch of these we’d like to do - a lot performance improvements and bug fixing, so that things that are meant to work should definitely work even if you’re using an iPad... And things that aren’t meant to work should consistently not work in the same way depending on whether the article is in French, Hebrew, English and things like that. Performance is a big pain point for our users and thus for us right now. VE is necessarily quite heavyweight and necessarily more heavyweight, and it’s getting rid of the unnecessary weight both in terms of processing, speed, for loading but also for execution....
So for the first half of this year, we are focusing on scalability and performance. …throw-in a much better set of workflows around templates and references…table editing….file uploading….meta data editing … explore concept on VE as a platform versus a mode…
Trevor: …what we produce is like this minimum viable product…we just got something out there because we knew this progressive enhancement model which we’re using where a lot of the content isn’t editable was going to be superior to building up this huge tower and releasing it…tons of features have very little review of way interactions happen and we’ve started engaging with designers to fix a lot of the stuff...a lot of the processes of doing various tasks are very inefficient and we’re working on improving those…we just tried to make sure we could make it work before we fussed about how easy it is...
James: Erik said a couple of times that what we built is a visual explosion of wiki text editing concept. it’s not so much that now it’s data graphics, but we haven’t rethought the workflow...
Erik M.: …as we start thinking about these user interfaces, we probably want to think about just adding a category on the page - you don’t want to go into an edit….
Trevor: …we have begun abstracting certain things, like when you reuse a reference, we automatically name both the new reference and the other one - we’ve completely abstracting that...with categories, we preserve where categories are located on a page, but we put them all together in one piece…people have a mental model of the way the markup works...we have to transition them.
Erik M.: …regrets that we don’t have C. Scott or Gabriel here because that’s the other big component of VE …we’re changing the way wiki text is translated into html and back, but we are also potentially changing the way content is stored in the first place... so might ultimately move to html 5 as the native storage form...that’s a really big deal...and we change from wiki text to html 5 as the model for templates, that really changes everything...we need to think about what does it actually mean if we move to html 5…
James: ...so why wiki text sucks is not just because people have to learn it, but we are restricted by how it works...and there are things in VE that we could not build based on wiki text...
Howie: Can you give us an example?
James: For example, inserting an image pulls-up gallery images …. In terms of what we learned about our users, we’ve learned or rather witnessed that how users are attached to the tools that have brought them to where they are right now and they are unlikely to change graphically unless we make it compellingly obvious as to why they should do that... new users are flocking to use VE...
Brandon: Have we published these user tests anywhere?
James: I think so, it was done 2 months ago
Trevor: …we’ve actually gotten a lot of advance users to spend a significant amount of time failing on our product and giving us good bugs and stuff like that, so that’s been kind of an upside.
Kaldari?: Do we know anything about the impact of total number of edits yet?
Trevor: ... we don’t really have great data yet, but hopefully will have that soon.
Ori: Not hopefully, it won’t happen unless there’s a commitment to it.
James: (talks about visual diffing, edit complex)
Brandon: Is cut and paste on here?
James: That should be next week …
Howie: Let’s move on to Mobile…
Kenan: At a high level, what we’re looking to do is to make it easier to contribute through Mobile. In the past couple of years from a readership standpoint, we’ve gotten mobile to a good point and now we’re looking to open it up to make it easier for people to contribute, last that that was through uploads, uploads of photos now we’re looking at it more broadly ...editing text, making contributions through gnoming...goal for team is to get more contributions…Mobile presents a different opportunity for us to get users through a different workflow… James and I have been talking a little bit about what it means for VE to go to Mobile…feature parody in terms of Echo, talk pages...
Maryana: …when and if we do figure out the VE/Parsoid piece, we’ll actually be able to start identifying certain pieces of wiki text that we’re interested in, so highlighting things for people to do on a touch interface rather than having to go into the editor and do mark-up stuff…add links, add category...also open-up photo upload stream...identifying sections....figure out what kinds of small easy things we can get users to do in a really structured way… People are really excited to try our stuff out…we can get a bunch of new people in, but we’ll have to be really careful and give them really structured workflows to work off of and not just tap everything...
Tomasz: In apps we’ve really been focusing on our power users. Last year we looked at photo uploads, multi-file uploads, refining the upload process. This year we’re going to be doing more, but what we’ve noticed that that while we can acquire a lot of new users, retaining them is hard, so we’ve started looking at campaigns…we want to build-out and we’re currently exploring what the costs are for a generic infrastructure...where we build it for the community as a whole so that campaigns can be build year round...focused contributions within designated areas...meet our 6000 contributor mark across web and apps. For the second half of this year, we’re having open discussions about what it means to start retooling some of the native Wikipedian apps...how they’ll tie into VE...there’s some technical hurdles will have to solve...
James: Are we currently based on PhoneGap for the apps?
Tomasz: Were based on PhoneGap for all apps except for the commons app. The commons app in our native application and it was our first big dive to see if this makes life easier for us and the answer is yes it does.
James: Unless you want to integrate a bunch of javascript in VE.
Ori: Have you guys seen graphs of Android share of new computing platforms?
Tomasz: ...2.2...2.3 is plummeting as well...
Ori: ...computing platforms that people have is pushing out everything else...
Tomasz: ...exciting to see 4.X take a much larger part of the market...
Vibha: Why are we focusing on photo upload campaigns to meet the 6000 contributor mark? …
Howie: We can dig deeper this afternoon. … These campaigns will require a lot of support… we need to think about what an MVP could be…
Siebrand: ...In last year's discussions, we spoke about how the design for our site for mobile and our desktop design could or should converge.
Trevor: I think we’ve pretty much decided that we’re gonna do that...
Siebrand: But I don’t see it stated explicitly anywhere on the major projects for either of these two teams.
Howie: I think that’s a part of this exercise...
Jared: ...I think that just kind of doing my own audit of all the historic, very successful projects...they’ve formed organically, they’ve solved the needs of a particular set of users and stakeholders of the project, but because of that, they aren’t holistic in any way both visually and with interaction patterns. So I think for us (design team) the goal this year is that we need to renew that audit and figure out where things differ, figure out the best of each of these and codify those to the visual design and interaction patterns that we can then distribute to everyone...which will hopefully cause future projects to use that tool kit of patterns and visual design assets...to look consistent...we gonna accomplish that by starting to socialize inneractive change with users, people are very averse to that...beta experiments framework...
James: ...all our current skins will have to be burnt to the ground and start again...if you are going to make the big rewrite work, we should probably work with you...
Jared: There’s definitely going to be some slight of hand change at some point...
Maryana: E2, really just one feature: Flow. The goal is to modernize user talk...we gonna start with really basic user to user messaging… Second half of the year…concentrate on user to user piece...wiki projects collaboration piece….letting users follow projects and things they are interested in and continue to receive information in things that they are interested in without relying on crazy copy and pasting templates...
Vibha: What’s the validation? …
Maryana: ...I don’t think we’ve talked about what kind of metrics we’d use to measure the success of something like Flow, but a big part of the first release is figuring out what do we actually want to achieve with this product...
Howie: We have a good model for evaluating linear flows...but we don’t have a good model for things that fall outside of that, so Echo and Flow are examples of that...
Steven: What E3 does is that we built features that grow that active contributor base... the goal for the team this year is to gain 2400 additional active editors to Wikipedia in any language…categories of experiments…increasing conversion rates...internationalizing...in terms of retention, that’s an area we haven’t spent a huge amount of time on...reverts...reactivation...we have to build a robust experimental tool chain to go along with our features that we build, that includes event logging, navigational timing...
Jared: ...E3 does a really good job of instrumenting things for analytics and then actually using that data in a very quick way, and I know that’s a lot of overhead, but do you think that their could be some kind of sharing of that learning and how other teams could more effectively use data as quickly as you have? Or do you think it’s something that’s particular to what you’re doing?
Steven: No, I don’t think it’s something that’s special to E3, it’s a way that we work and I think there are aspects of it that any team could use...good example is user metrics api user metrics...
Ori: …there’s a lot of mistakes that we’ve made that I think that we can spare people the cost of making the again...I think we’re doing well, but I don’t think we’re there yet in terms of being data driven...there’s a while to go still.
Erik M.: There’s also the fact that data is still an underrepresented discipline in the organization today compared to Product, etc...The way I think Toby thinks about it is that he’s trying to grow this team of analysts with Dario who will be essentially consulting to the highest priority product teams in the organization and accompanying the development process throughout...
Fabrice: ...Kaldari has been kind enough to step-in and represent an engineering perspective as far as multi-media is concerned...muti-media is actually spread-out across a range of different areas starting with improving the viewing experience to enabling more contributions to helping curation of new content and most importantly publishing that content on the articles where most of our readers can come to, so we’re looking to make some incremental progress in all of those areas...readers expect richer media experience...For the first half of the year, we plan to focus on viewing and contributions...file notifications...improving upload pipeline...encourage people to add file categories...batch uploads...In the second half of the year, we’d like to turn our attention to the important topic of feedback and or curation...we hope to able to work with the VE team to expand the insert media tool...maybe introduce the concept of tags...
Siebrand: Are these in order of priority....
Fabrice: It’s not so much priority, it’s more that you got to pick a few things first...this quarter, we can have the most bang for the buck by improving the viewing experience, it’s not a difficult problem to solve, curation is difficult and so are search and meta data, which is why we plan to tackle these in 2014 ...
Siebrand: So two big time boxes and you’ll see how far you can get?
Fabrice: Exactly. I should also say that we have a lot of technical debt...for a long time there was no multi media team, so we did hack after hack after hack...
Siebrand: LE – We do a lot of the plumbing that allows our software to be available in many languages, there are also parts of making software available in other languages that are not part of our core activities, and then it comes to something that Steven mentioned earlier as in localizing the workflow - we ensure that it can be done, but we are not actually doing it, that something that either the features team has to facilitate, or the community has to do by itself. …we have to ensure that the core content creation and delivery platform of Wikimedia remains able to provide a localized user experience. What are we going to do this fiscal year…we want to develop a tool for translating main namespace content. We want to use the latest technologies for that, things like VE and that’s also a risk here because we had actually planned to start developing this feature this week, but given some of the very severe internationalization related issues in VE at the moment, it may delay for a few months. We want to provide onscreen keyboards…things like key mappings, users have to be able to find out how to use them…we provide help links….a gamification of the translation process…we assume that adding these features might encourage people to translate more… improve security risk…in scope the features we have in media wiki, we want to untie them…
Ori: Just want to express appreciation for the huge amount of support you guys provide to other teams...
Siebrand: You’re welcome. And to all product and development managers, please don’t hesitate to ask our opinion in advance, even before code is being written because it may help you do less rework.
Breakout Session: Interdependencies in upcoming year
- Performance & impact on user experience; Consistent use of data
- VE on Flow
- VE on Mobile
- Geodata
- Cross-device Design and Development
- Inter-team process
- Unified i18n planning
- First-time UX
1. PERFORMANCE AND IMPACT ON USER EXPERIENCE
- we need to have better way of handling the data and plugging it in (graphite)
- want to standardize collecting data on browser capabilities (javascript, user agents)
- detection and notifications when events cause issues
- discussed need to standardize instrumentation of edit funnel
- more user testing for browser testing- testing for time to add templates, etc. for VE
Next Steps: Dario/Ori
2. VE ON FLOW
Participants: James, Gabriel, ErikB, Maryana
Outcomes:
- Source mode required (parsoid parses what it can)
- Faster storage mechanism that can write directly into HTML; coordination with Parsoid team
- API access
- Mini VE (subset of VE features)
- Freeze templates (TBD?)
- Selectable templates (e.g., 5 welcome templates)
*** TBD: separate namespace for these?
7. Support limited number of workflows (e.g., blocking)
Next Step: Flow team to take this and determine minimum viable product (Maryana)
3. VE ON MOBILE
VE on Mobile Web. Outcomes:
- redirect tablet to mobile site will happen sometime this year (maybe first half)
- Port existing VE with lots of UX mods so that it works on tablets. This will need to happen before redirecting tablets to mobile.
- The overall idea here is to get functional set of VE features out, and then measure and determine build-out (either editing or other features such as GettingStarted) as a function of what people do.
3. Measure:
a. Performance
b. What types of edits people make
c. What types of editors edit via tablet
Next Steps: * Incorporate these ideas as part of mobile roadmap (Kenan) * UX audit of VE and appropriateness for touch devices (Jared)
Approach to Native apps. Outcomes:
- No to editing on Native app (at least in the short term) as this will involve basically recreating VE in a native app
- We may want to look at specific workflows (e.g., Watchlist --> revert)
- Two paths forward (not mutually exclusive?)
a) Do pilot apps (e.g., Watchlist reverting, disambiguation tool), and if there is enough interest, consolidate. Issue here is marketing --> what's the effort required in reaching editors who would find these tools useful?
b) Port Reader app and use as a distribution mechanism. In this model, there would be basic read functionality, specific workflows, but editing would direct user to the web (which will have VE!)
Next Steps:* To be incorporated into Mobile Apps roadmap (Tomasz)
4. GEODATA
Map information is part of the sum of human knowledge, it should be shared with everyone
"Discover content based on location"
"Categorize, organize, and make content findable with geodata"
Toolkit
- Nearby (articles and images)
- (Geolocation Api (for Articles)
- exif data on images
- Standard geolocation template
- user location
- OSM integration
- Wikidata geo properties, qualifier (Add history, multiple locatons, granulatity, scope)
- Apply map location to images with Geotagger
- gerrit.wikimedia.org/r/#/c/12353
Contribution Concepts
- Add geodata to articles and files
- Flag incorrect geodata
- Correct scope/scale of current geodata (ex. put point on map when should do region)
- Set geolocation "ontology" if isn't obvious/automatic
- Use maps/geocoords to facilitate campaigns
- Embed dynamic maps + rubbersheeting of existing map content (svgs, images)
New types of contributions, and ways for new users to make edits
Partners
- Flickr
- Foursquare (ex. venue API for suggestion of articles for geolocated people)
- OSM (Open streetmap)
- Youtube
Find relationships with other organizations so that we can focus on what we do best
Projects
- Map namespace (ex. localwiki, facilitate of maps of city linking [OSM would be the place for creation], and overlay restaurant articles, and embed that). Wikivoyage integration, integrate in wikidata.
Map data is part of the sum of human knowledge and should be shared like text and image tool.
Did summary of current toolkit (see above)
Next Step: Create page with all existing, tools, code, and resources, so that all teams and partners can use these resources
5. CROSS DEVICE DEVELOPMENT
# Cross-device development (unified UX, vector, design)
Participants: JamesF, Tomasz, Siebrand, Fabrice, Brandon, Kaldari, Jared, Jon
Mostly outlined by JamesF and Kaldari.
- jQueryUI: E2 (Timo and Trevor did it, and regret it)
- "Agora" into MWUI: E3 ->
- VEUI: VE (agora design in vector)
- Mobile has their own (some agora inspired)
- Site as it is
Historically, different designer for each area. Making these libraries coherent and shared.
Topic of the conversation: Mobile and MW core: Coherence and convergence.
- Look the same? Most achievable (Jon) but repetition of work.
- Use the same?
- Behave the same?
- Be the same?
Brandon: Is it more work to use different libraries or to maintain it? (Exception VE: because it is a standalone library.)
The easiest thing to do is pick one of the three libraries, and then the other two elements. And cataclysmically, others would add rules on top if it.
Vision statement => motivations.
- Consistency of user experience (from "every single human being"): reduce user conversion, increase user retention. the priority.
- Reusability thing (from "freely share"). (nice to have, how you get there). Looking the same is the priority and reusability is how you get there.. Cannot achieve look the same unless you do it.
Discussion on css class names.
Mobile is a skin, and it does what a skin should do. But mobile skin should have same class names as Vector's class name.
We're doing multimedia. What should we do (Fabrice). New set of controls within agora control library for dark skin. Lightbox. put in mw.ui: mw.ui.lightbox and have a process how it makes it in.
MW will have a skin going forward (appearance) but that appearance may or may not be separate from the control library.
Where does VisualEditor fit in this? VE has specialized widgets at this point (JamesF), should widgets live in core even if only used in one extension.
Is there a null state for VE when deployed outside VE and is there a different state when used in VE (Jared). Ex. text input widget. it works a certain way and is styled a certain way (VE has its own input widget and 2 sets of CSS).
Obvious selling point: We will serve way less CSS and javascript if we have to serve less client (Kaldari).
People we have to convince first are development teams (features + platform - brion vibber and tim starling).
We're basically talking a MW UX group on determine code quality, good enough, etc. Is it Wikipedia-worthy? Code review: Why aren't using standard compliant.
If we did have one library, developers start enforcing.
- Build an extension that use a code library with guidelines. So people can see the design [sandbox extension]
- Big F--king patch that will deploy with MW core
- Do in parallel build patches that will land at the same time.
Who is going to do it?
(Jon) 80% of CSS on page is not being used on main page. What about ??? rule JamesF: It's hieroglyph related extension.
Siebrand: Why not in Resoureloader? Because it was written before resource loader.At what point does it support i18n? animation? etc. Do we need to decide it now? Nothing is happening until September.
Here are the use cases that we need to support "today"? Then open for discussion and a lot of stuff comes rolling in that we didn't consider. Add them in as long as we know what they are.
We will eventually arrive at the best checkbox. Ex. VE checkbox, Hover on mobile (doesn't work). By using in different context we learn it.
Historically: Standard way to beta test is to deploy on MW. VE has plan in place with accepting this
Next Steps:?
6. INTER-TEAM TEAM PROCESS
Participants: Siebrand, Maryana, Trevor, Jon Robson, Steven
- Identify resource needs from other teams early as possible (Siebrand)
- VE model: has own design, i18n person, etc. Individuals participate. Have one person who specializes participates
- Embedding: Guess: better to have VE with mobile than reverse. Already have a product that works on desktop. They don't need to make a lot of changes-> majority of work is UI/UX so questions will mostly to mobile.
- Tit-for-tat (Maryana): If you lose a team member, there needs to be reciprocity. {ex. Rob Moen}. PM's need to agree on prioritization (Siebrand, Maryana, Jon). Pm's might be protective: If engineers are trapped into projects you get burnout and not cross-pollination.
- Jon Robson: Starts with shared vision which decide what to work on. For example VE has a target and Mobile has the same need. But make 100% focus ("not on the side"). Actual mechanism and staffing determined by organically
- Two types of hires (Trevors): Existing project and others take two things and mash them together (dangerous). New people brought in work on existing project and become expert. When expertise and move between. {Ex. Kaldari is good example.} {Ex. VE instrumentation, could have been protective of Ori}. Also perk of seniority is you get to bounce around.
- Engineers should be able to choose their area (Stephen). May lose Ori to platform basis, but get Vibba from design
- May be an issue because people leave a team unless assigned (Siebrand). The key is to limit to senior engineers (unless PM approves - see flexibility above). And also must be co-ordinated things.
- Can't do this on a month-to-month, probably quarterly schedule. (Siebrand). Applies equally to everyone.
- People are grabby of senior Engineers but also some projects need more resources => Management shuffles engineers {ex. Mark Holmquist}. That only happens to junior engineers. (Stephen).
- WikiEditor and Vector {horrific experience} => Caused us to do ResourceLoader to eliminate problem permanently. Wouldn't have known system unless you can work that thing.
- Need to give people to make the primary purposes. 20% time assignment doesn't work effective.
- Are we going to embed someone & length of time? Depends the project (nature of the work) and priority.
- Who should we embed? No new hires, must be a subject matter expert. Given them a freedom to decide. Or… PM can decide based on needs. If junior, then that person needs to become a subject matter expert.
- How? Who wants to work on it first, source on something like quarterly schedule worked along with PM for scheduling purposes.
Most interesting in talking about was the nuts and bolts about how we share processes between teams. At some point we have to work between teams, and not talk about it. How would this work>
- We shouldn't be so protective of resources, should do that with skilled people (not new hires), great way for people who put in their dues to have mobility between teams
- If there is a problem, then its because mission isn't aligned. Shared mission between the two teams.
Next Step: Have someone from the VE team work with the mobile team
7. Unified i18n Planning
- Offer from i18n you can call of us when you need advice
- design and i18n: conclusion is pseudo-localization, made longer so impact of longer translations are made longer for designers
- need context information before strings if translators (where is string used, is it a button?). the process involved (add to messages files and check it in, so not everyone knows gerrit, so improve process)
- how to get more translators/translations? without sacrificing usabilities (add context-dependent "translate-this"). Lots of JS and PHP and user-role accessibility, very product specific (mediawiki)
- mediawiki agnostic i18n in mediawiki. Framework should not depend on mediawiki. Ex. Visual Editor, ULS is using right now. Changing back end format (to JSON?). Make an RFC to start it.
Next Steps: Siebrand
8. FIRST TIME UX
Challenge this year: consistent or at least complimentary first time UX on mobile and desktop in terms GettingStarted.
* i18n of GettingStarted and other onboarding closely tied to this.
* Mobile probably needs a simple API from CategoryRoulette
enwiki, gettingstarted task (task type), number of tasks
Consistency between mobile
http://www.mediawiki.org/wiki/Mobile_web_projects/GettingStarted
* Could we use Nearby on desktop as a source of suggested tasks. GeoData API allows for this.
* Issues tagging and database as a requirement?
* Echo as a pre-requisite for full GettingStarted on mobile
* Page creation on mobile is an open design question that needs to be solved cross-team
* Inconsistent UI (Vector, VE, Mobile)
* MobileFrontEnd using medaiwiki.ui
Tied to UI audit?
Next Steps: Steven
Meeting Notes, Day 2
[edit]
Breakout Session: Wikipedia in 2016
Sessions
- IPs
- API
- Re-imagining WP on Mobile
- Diversity
- Search
- WikiProjects
- Real-time Collaboration
- User Identity and Data
- Re-imagining WP Design
1. No IPs / Require User Registration
Originally proposed by User:Binkersternet to 'require user registration' at the June 2012 Editor Engagement Roundtable (see photo)
Participants: Dario T., Steven W, Matt F, Erik M., Maryana P., Fabrice F., James. F., Jared Z., Vibha B.
Notetaker: Fabrice Florin (please pardon any errors or omissions : )
* Experienced users don't want IPs because they view them as more spam, low-quality edits
* One goal could be to start by giving more humane labels for users, instead of IP addresses
* Simplify login process to encourage more people to sign up
* Letting people edit anonymously doesn't allow persistent identity or accountability
* Anonymous editing encourages vandalism, which requires a lot of negative tools
* Persistent positivity would be a benefit of more registrations
* Don't shove IP addresses in your face
* Progressive disclosure of IPs so they disclose more over time
* Start with 'anonymous 1234' - or better yet, use random names (e.g. blue leopard) instead of numbers
* There is a lack of being able to recognize individuals
* Account encourages accountability
* The fact that we cannot contact anonymous users is the biggest issue, because we cannot contact them
* Having cookies and a proto-account would make it possible to start the process of identification
* E3 should test whether saving session information is a compelling reason to sign up
* These are your edits: would you like to save them to your profile?
* Explain to people why they should log in
* Have more calls to action about why you should log in
* We would expose login prompt on watchlist, create page, upload file or other requirements
* Get rid of View source and have call to action* We should automatically create proto-account, without asking them to log in.
* Proto account maybe an entry point towards people having accounts
* Why not associate donations with your account* Facebook Connect is another way to help people login
* We should support the identification standards (e.g. Google, Facebook or Twitter)* Link to privacy policy so people understand any changes
* Do a proper assessment of privacy policies for all social networks to find out if in fact this is still an issue
* What should we do about notifications and discussions for IPs?* This is an opportunity ot encourage them to sign up
* At what point does persistence matter for editors? As soon as people start editing? later on?
* There are substantial numbers of anonymous editors who want to continue doing it that way* If they can edit but not post on talk pages, that would be too weird
* Experienced users want to send messages to anonymous users and do not know how to contact them
* Some anonymous users do not want to get messages from the community
* Pseudonyms give you the same freedom, you don't have to be anonymous to have that freedom
* We're considering 3 different possibilities:
- a lot more calls to action to log in (CTA before)
- automatically create a 'proto-account' with a cookie
- automatically create an account and immediately ask them to register (CTA after)
* Let's A/B test these scenarios: call to action before or after
* Click here to create your account, you will not lose your work
* Even with calls to action and other tools, there will be lots of people who will not want an account. They will continue to make bad edits, and get messages on their user talk page.
* We don't know what next edit to expect from that IP, so notifications and messages could be sent to that user, then be archived after a while.
* We would also keep track of how many times this IP address has been warned, but can't take any hard action on it.
* Do we have any data as to whether or not IPs look or act on their messages? Are these even worth it.
* Why are we spending so many cycles to accommodate anonymous users in this day and age? It seems like a waste of resources, both for the community and the foundation.
* The reason we want to keep supporting anonymous edits is because any barrier to entry could reduce the amount of productive contributions
* Does this change what our vision of 'the sum of free knowledge' and what it means to share it?
* after edit, ask it to pseudonym to create account
* proto accounts: partially logged in (IP + local storage)
* 3rd party authentication provide: allow other options that allow 1 click log in without privacy issues to arrive. OpenID
How we show anon user to other users. Not hide IP entirely, but progressive disclosure.
Next Steps:
- make a list of all calls to action we could give to help users log in (and where they would go)- decide how to display anonymous users to others?
- research issues related to using third-party login systems like OpenID (security, legal, community)
- basic user research on what new users want
- campaign links to understand how anonymous user log in today
- decide how Echo and Flow should deal with this issue
* encourage people to log in or sign up
* explain things in context instead of separate signup page
2. API
run into issue with existing API. Identified as a problem but not work. Big deal because it affects mission as reusability and accessibility (people give up). We have advantage because we have Roan and Max int he WMF. The process to work out what to do is difficult.
1. Getting semantics right (to understand how to get info)
2. Information that returned (we minimize payload, but multiple api requests: ex. all language versions of article, one to work out language code meanings)
Stuff:
1. Focus on semantics. Set up service somewhere where new API could be sandbox, and rewrite old API to new API.
2. Make them aware that API semantics would change.
3. Come up with user stories and create API that serves API
REST: people take it too far, but good idea. Concern of ease of use and less about religion of REST.
Next Steps: Roan get us a server on tool labs to set up.
Change the mission? The design of the API reflects the perspective of the people working on implementation rather than people who want to work with the data. Ensuring global access ensures better interactions that are more comprehensive.
App keys for Data on API? Find out who is using what methods.
3. Reiminaging WP on Mobile
Strengths of mobile vs. desktop.
* primary source based rather than secondary (ex. WikiNews like)
* location based layer
* consume wikipedia on mobile differently. Semantic interface on wikipedia (NL searching, search using voice)
* how do people edit? lost search could be pipeline for edits
* push vs. pull model: (For example nearby interesting things that are pushed to you)
Question: What if Wikipedia was consumed exclusively through mobile and tablets? What would it look like.
It is realistic that 80% might be on mobile. How to make most tasks mobile friendly and merging to desktops.
How do we take this stuff and bring it into other platform to desktops
Next Steps: open up thought exercise on "What if…" to the mobile mailing list (Tomasz)
Vision statement: The ideas discussed push the boundaries and evolve what the encyclopedia is by expanding the view of content (notions around primary content)
4. Diversity / More women!! / Better consensus, less toxic culture / 5% mean messages
Participants: Dario T., Erik M., Maryana P., Fabrice F., Keenan, Vibha B.
Notetaker: Fabrice Florin (please pardon any errors or ommissions : )
* 50% of readers are women, but only about 9% of editors are female
* Competitive nature of getting content to stick discourages women
* Don't underestimate the reputation of Wikipedia as a contentious site
* Why do fewer women edits?
* Nobody helps you on Wikipedia
* The typical Wikipedia user is more aggressive
* Women are not as likely to want to figure all this out
* Why is Pinterest so attractive to women?
* Women feel they are in a contentious space
* The user interface is poor, not clear how to participate
* Wikipedia is like a dark room where you don't know who's there, what they are like
* Wikipedia doesn't surface human personalities, we hide who the contributors are
* How do we make Wikipedia more inviting to more users?
* Provide a 'clean, well-lighted space' ... where people know you by name
* Men have assumption that if they can do it, it's OK, not so worried if they break things
* Women are more concerned that they might break something
* Should there be a photo on your profile, links to where you can find people?
* People don't value what Wikipedia offers them as editors, not clear what the point is
* What does identity mean to us, and what identity do we acquire when we join community
* We now show peopole on the page, invite people to join Wikipedia
* Why do we want more women to contribute?
* Because women know about topics that men don't , we want to include that knowledge
* We want to attract people who will be useful to the encyclopedia, no matter what their background
* Qualities associated with women are that they are nurturing, low on vandalism
* Knowing that there are women there make people more comfortable
* We have a lot of 'frat boys', 20-yr. old males, who are a turn-off for women
* You can play a role that others cannot fulfill
* A lot of women started as copy editors, didn't change facts, but corrected errors, which is very valuable to Wikipedia (many of them were teachers)
* Many women left because it was contentious, spelling conventions are arbitrary, so you get yelled out and shouted at if you change things
* We have identified the main building blocks already: Identity, affiliation, getting people into projects
* Make project pages look more inviting, with featured photos, meetups
* We throw all the tasks in one big box, rather than having separate spaces for collecting facts, etc.
* Constantly worrying about people saying you did something
* Add a thank you button at the end of every message makes people more civil
* Women are more socialized to want to be helpful
* Anything you do that makes you think that you helped Wikipedia, so you know your contribution matters
* Women say their articles are like babies, they try to protect them from being vandalized, etc.
* 'Adopt an article' might be a way to invite women to care for particular articles
* There are many expert communities out there that we should recruit for Wikipedia
* Can we get some selective CTA that invites them to adopt a particular set of articles?
* Encourage members of the same cohort to know each other, get to know the people who signed up at the same time as you did
* Invite article communities, where people can socialize a bit more around shared interests
* What articles are disproportionately male-heavy -- even female articles are written by males
* New paradigm of the Internet is identity, but Wikipedia has a very rudimentary form of identity, that's more conducive to angry conversations
* What if we created spaces where you can collect references or images for a page separately from the article, so you wouldn't have to fight so much about every edit?
* Wikipedia only has tools for voting things down, not for voting things up, unlike Facebook or other popular sites
* All Wikipedia actions are written from a male, robotic voice
* Wikipedia feels like the Wild West, mostly male, very few women -- eventually, more women joined and it became more civilized
* Women seem to have a stabilizing effect in communities that is valuable, from a social standpoint
* People perceive that a community with women is healthier -- and makes it easier for women to join
* Friendlier quality assessment tools
* Provide naive progress bar to show how you are doing
* Test adoption of article: (tamagatchi, farmville) people can get involved in articles and turn it into tomagatchi. Show progress. "Adopt an article" and be reminded to its needs. No visual representation (current system for quality classes is robotic or compelling).
Next Steps:
-'Adopt an article'
- live 'wiki-tree' visualization of article quality, like tamagotchi
- simple way to represent that help is needed
- make templates prettier and friendlier
- making discussions easier
- improving the user interface
- make the experience more inviting
- test gender bias on mobile
(Many of the next steps are captured in the discussion about Civility and Diversity)
* Simple way to represent help is needed, templates prettier, prettier UI
* Test for gender bias in mobile
Values? Values of 25 year old white males. Showing reputations (caught up to person's representation) vs. credit on articles.
Next steps? Interface is not inviting. Make it more inviting (copy editing tag actually encourages it).
5. Search
Participants: Jared, ErikB, Siebrand, JamesF, Matt Flaschen, Ori
* multi-lingual search
* seating for answers within articles ("Where are the nuclear power plants in India"
* Natural language search
(Jared) Thought about fact that other people arrive at projects from other search engines (Google). Having metadata on articles with search query referral. (Privacy of the users.) With SSL site gives direct link. Build better understanding and question and answer pairs based on data.
Discussion on dog, get answers in other languages and other projects. "If I search for puppy, I want puppy!" Therefore implies we want to move dictionary into wikidata, to make these contents.
Could we have disambiguate search on search results page? How to resolve that?
How do other places do it? Hardware? $$$? PhDs?
Don't see alternative to structured storage of labels. Ijames) That gets into back end infrastructure i.e.
Solr (ErikB), Solr vs. ElasticSearch. Language support in ElasticSearch?
We need a search tool that understand links between human language terms.
Replace all categories and all metadata on everything with structured data (possibly based on wikibase) and integrate it with search. Current and next infrastructure (ElasticSearch) doesn't support it.
Discussion on facets: Meta has translation search.
IN VE someone does "search Barack Obama" and looks a primary ID of each, not the string, and show me. The concept of "Barack Obama" and search across all media, and then apply filters.
Barack Obama has a category on Commons, but not want democratic politicians.
Category vs. tagging. Tabled. Folksonomy.
Commons metadata would be moved to wikidata. for faceting.
"Provenence chain model
"Wikidata has a property. Dog is a category but it as a concept. For instance, show me things that are about dogs or all a dog.
The NLP can be done better that others, so provide the API. We can do simple queries on our end "photos of black politicians.
**Wikidata:** item has labels, aliases, descriptions, and relationships
dates, locations, ontological structure (person, human), relationships between any two facts (spouse, child, inventor, manufacturer)
Types: geographic data, time data, string data (to be used careful), commons media file (canonical), commons category.
Media search and cross language search. These are problems: don't go anything for chien (french label for dog) because not of it altered. Put wikidata structure into commons. So that labels are done. Other metadata to articles etc.
Using filter search and schema (Solr) to pull out things to "dog"=>gives different stuff "Did you mean?"
General talk on natural language. Decided hard and funded well outside organization. WE can seed that well with well curated structured content. And Make it popular. We can take popular pre-saved search. "Ex. Who did Barack Obama serve with in Law Review?" Maybe we can save it as a search that wasn't found and allowed it people to add metadata.
Harvesting incoming search query traffic. A log of organic search results to give data on.
Vision? Cross-language, multi-lingual, share
Next steps:
- commons file page data moved to wikidata and display on commons from wikidata (keep local text if necessary)
- categories do the same all wikimedia wikis
- hook this into "search"
- type in one word and suggests in drop down
- search on concept
6. WikiProjects
Discussion on few questions:
1. Why are WikiProjects important?
Meet other people
share interests
getting help from people as noob
quality assessment (could be more in the future if high data)
what needs to be done (cleanup lists)
2. What are the current problems in WikiProjects?
Hard to know what is going on.
Hard to know how active it is.
Difficult to find WikiProjects.
Methods of leaving and joining are notn intuitive or consistent
Better association (than templates)
better quality assessment of articles (besides templates)better ways to surface community and talking to other members
Semi standard identity and ways to create
Most tools are bot-based and not known: move into software and surface them
how do we get new people to join?
Data that exists is unstructured and surfaced by bots
not used by sister projects (e.g. Commons) or implemented differently
3. What are the solutions/next steps?
* Prerequisite: Provide structured data related to wikiproject to associate users, pages, and attires of projects to the projects
* Providing analytics about wikiprojects
* Easy ways to join or leave. CTA to people.
* Adapt flow and echo to wikiprojects
* Form based modular article lists, etc. Profile page for wikiprojects
* send invitations. run campaigns, and on boarding
Next Steps: ?
could be done before profile work. and bring profiles out of affiliations.
Vision? Increases high-level collaboration (what are the areas that still need work?). Invitation culture (invite your friend who is a doctor to wikiproject medicine), scale in a manageable way.
7. Collaborative, real-time editing, annotating & chat / with support for assistance, affiliation
Participants: Erik M., James F., Tomasz, Maryana P., Fabrice F., Dario T.
Notetaker: Fabrice Florin (please pardon any errors or ommissions : )
Includes:
* Document (# session/article, edit attribution)
* Annotation
* Who's online?
* Playback changes
Use cases:
* mentoring
* topic of the day
* edit conflict resolution
* New user needs orientation to guide them through edits they are making
* Bulleted list of things that need to be done before next batch of edits
* Meta-notepad of things to do during a session (goals of the session)
* How to work on multiple articles in a single session (e.g. city of London and its neighborhoods)
* Need the equivalent of recent changes features for this & other sessions
* List of 'edit parties' in your watchlist
* See what Wikipedia is really like, join one of our editing parties
* Provide 'look' mode so you can watch someone as you edit.
* Provide voice backchannel so you can talk while you edit (Fab always has Google Hangouts during IRC chats)
* How many people can join an editing party? Up to 20 at a time? The rest could 'watch', but not paticipate.
* Like seeing a newsroom in action (during important current events)
* Moderation piece is really tricky
* You actively invite a person to join the group
* Watching is only useful if there is a way to chat (text, audio or whiteboard sketches)
* Session management tools to split sessions
* Can have multiple systems for who is the moderator:
- first come, first serve
- auto-confirmed users get certain shiny buttons
- anarchy
* Do we want to support this for logged out users? They can watch, in real-only mode
* You have to log in to edit or comment, but not if you are logged-out
* What if a vandal wants to screw things up? Do we provide a blocking tool?
* Mute a person that misbehaves (and/or lightweight kick out users from the session)
* Notification: an article on your watchlist is subject to an 'edit party'
* Go to the article, there is a flag that says: 'join edit party in progress'
* Would have a 'Start edit party' button in toolbar
* Real-time events are hard to manage, because people have a lot of edit conflicts -- could we have an edit party last 24 hours?
* The idea is that one user click 'Save' for all of us, under my user account.
* You could save at each step of the way, incrementally.
* If there are multiple edit parties per article, it's more complicated.
* Legal model is only when you click 'Save' -- people consenting to have someone save for you
* We need a draft mode anyway, so we could save the group's edits as drafts.
* If someone wants to edit without joining the party, can they edit?
* Instead of having a 'main editor', could you have multiple editors?
* Only one real-time edit session per article initially.
* The minimum viable product could start by giving the credit to the person who clicks 'Save'. Future versions could give attribution to other editors.
* If we don't do individual editor credit, you can't find out who inserted the objectionable edit ('Prince of Belaire' incident)
* Drafts are really important, both for users and articles.
* Personal drafts vs. collaboration drafts* If you host an 'edit party' and noone comes, will it be considered a personal draft or collaborative?
* Auto-draft feature for unsaved edits in progress.
* Do drafts expire after a while?
* You can continue to have a draft in your personal user space forever, we're just talking about article auto-drafts here.
* Drafts should work across platforms, so a draft you started with one device would be available
* Echo notification: 'you still have four outstanding drafts, that will go away'
Next steps:
- revive Trevor's old Drafts extension and start testing it
- validate the idea with users before we invest a lot into this
- still a lot of design work is needed (see below)
- how many people can join an edit party? 20?
- how long can an event last? 24 hours?
- how do you start a session and list it?
- how to invite users to join the party?
- who can join the party? (logged out users can only watch)
- how to provide chat (text only? voice?)
- how to provide to-do list?
- figure out tricky moderation issues (who is a moderator? can they mute or kick out users?)
- how often would we save? who gets attribution?
- drafts would be saved automatically, how often and how long?
7. Collaboration
When we think of real-time collab in VE: google docs, and current events. There is more potential than that.
Dynamically start "edit parties". Imagine a dynamic list of "edit parties". Different idea?
Anyone can join a session: so moderation. Therefore only one real-time article collab per article. Must be tied in some way: call an admin to help out. Blocked users can't participate
Attribution: MVP: attribute to user who hits save and add people to edit comments. Rollabout
Drafting? What if session is abandoned? Should design notion of drafts in the system. May revisit drafts extension. Adam Wight has a branching idea.
Meta document that have a set of goals of the document for the edit party.
Next Steps: Drafts stuff, revision data model, UX questions on moderations, list of 10 design questions
What is the validating the ideas with the users? Fundamental shift.
Vision: creation of knowledge. Nurturing of newbies (where parties are happening also)
8. User Identity + Data
There are two consumers for ID stuff:
1) viewing someone else's profile (evaluate person)
2) getting value from one's own profile (things that I might be interested in)
Force specific styles vs. personalization?
Hurdles: mostly social hurdles
Devil's advocate on Facebook Profile.
For other people: Who they are and who they see themselves as in to community, summarize work, type of contribs, what does the user care about.
Implementation: Modules (file uploads, user page, avatar module, interests)
Next Steps: Mobile was interest in module idea and profile side
Connection with Vision: empathy increases collaboration, people can find like-minded individuals , identity-reputation-gratitude
Profiles are meant to convey who a user is and how they want to be seen by other usersIt should convey a sense of personality and the make-up of their contributionsIt should work to communicate this at a glance so a new user does not have to read pages or dig for another users intent.
We need to understand all the areas (Watchlists, page history) from where you may want to view the profile for another user.
Profiles are social, but they are social from the point of view of promoting collaboration.
9. Reimagine WP Design (Evolving Vector, MobileFrontEnd, and the skin system)
Participants: Trevor P. Ori L. Jon R. Siebrand M.
Note taker: Steven W.
Problems
- The transition between skins is really hard. We never properly did change management in the Monobook to Vector switch.
- We still have too many skins to maintain in the long run, it is big part of our technical debt and design/testing lag in Features
- Multiple skins creates fragmented UX and increases the distance between readers, new/anonymous editors, and experienced editors
- The skins we have are fragile and inflexible
- We're the only ones developing skins for MediaWiki (it's hard, others don't yet have incentives necessarily) which means that any default skin we make is used everywhere else, which dilutes our brand
Solutions
- A standard library of controls, icons, etc. that is in line with a comprehensive style guide backed by rigorous research and testing.
- One skin to rule them all on Wikimedia projects, using that library and behaving by that style guide. Au revoir Monobook et al.
- Theming support for the core/default skin LESS and/or SASS support in core
- Make Wikimedia's skin (Vector 2.0?) responsive and the same between devices
- Design on a grid OM_MF_G
- MediaWiki's default skin (on desktop and mobile) is not the same as Wikimedia's skin.
- Adding content layout functionality (e.g. how to style the lead and references differently)
Identify problems
1. transition between skins is hard
2. too many skins - tech debt
3. fragmented user experience (increased distance between editors)
4. fragile, inflexible, too hard
5. new default for us and wikimedia
1 skin to rule them all
* have them behave according to stylbook
* better theming support* less sas support in core
* across devices
* grid full of shit -> responsive
* content layout functionality (ex. section 0 look different)
Next steps: Do all those things.
Visions: Can't build features if we don't have a platform toolkit and support.
--- Afternoon Discussions---
Howie: are we supporting increase diversity in our editing communities through these features?
Fabrice: improving user interface in general would go a long way
Erik M.: would like to have a conversation with the E3 team, approaches that’d like we would like to test, think about UX experiments, CTA type experiments
Steven: makes sense, include diversity as a metrics?
Maryana: Teahouse has impacted diversity
Vibha: would be interesting to study
Brandon: Siko offered to help
Erik M.: should consider
Howie: problems with toxicity with our existing community, are we supporting improvements in environment and culture of our products?
Erik M.: things in Flow that we can build in that are supportive to culture
Steven: measure revert rates
Erik M.: design is really important to the culture piece - how it impact the user
Jared: Invite design folks to weigh in on decisions that may seem very technical
Erik M: UX take some ownership of culture problems, consider role of design to view our culture and make things welcoming and inviting to every interface, don’t think that is current understanding in the organization today
Kaldari: part of Teahouse success; implement profiles, good interpersonal dynamics
Brandon: they have a code of conduct
Trevor: a lot of interdependencies, assign resources across teams
Erik M.: you have a blank check to ask, don’t wait for managers, shared responsibility, need to get these conversations started informally and casually all over the place
Trevor: not get greedy on who’s working on what, look at greater good
Brandon: resource constraints, where’s the tradeoff?
James: be aligned in priorities across all projects
Kenan: prioritize, something we collectively point to that fits with principles we’ve agreed to
Erik M.: we have a goals document, tradeoffs can be made one week before the deadline, don’t worry about that stuff, we need to do the right thing.
Brandon: we have a lot of technical debt
Siebrand: I put maintence in my goals
Fabrice: if we don’t take two sprints to fix all the bugs in page curation, tool will be used by fewer people
Erik M.: this is not an easy problem to solve, you always want to move to the next shiny thing, but we can’t assume maintenance, maintenance is something that has to be negotiated, maintenance is something is either taken on by a team as part of it’s continued development cycle, or allocate 20% of your time, or reaching out to platform engineering
Trevor: VE has a pattern, after we have a major release, we plan to have 2-3 months of maintenance and technical debt cycle
Howie: what should we take away as a group?
Trevor: that you plan and include that explicitly in your roadmaps
Erik M.: yes, that is every team’s job
Jared: use Zen model - when you add, take an equally sized thing away
Erik M.: Ori, once approach I’m thinking of is to raise and elevate importance of continuous integration of automated testing
Vibha: not easy to follow Zen model, we can introduce things and not validate them, but you can’t touch something without having data approve that it’s not working
Dario: there’s always some data to attach to projects
Erik M.: make decisions based on existing research (search box example)
Howie: is templates something we want to serious about?
James: Lua makes it much harder for us to do wiki text
Erik M.: 2 different problems: how do make them, what do we use them for
Maryana: templates are also a sign from the community that we have not built software
Erik M.: we have to figure out where templates make sense and where do they not make sense
Trevor: we figure out small incremental ways where the most common uses are more convenient and solve some problems
James: with VE it’s much easier to put one template in then 10
Howie: Maryana, Matt, Ori, James, Erik M., Trevor, Jon R., Kaldari - folks wanting to continue this discussion
Howie: (Wikimania) we’ll need to describe our work, not just individual team’s work, but the overall engineering departments work.
Terry: if someone asks you about an area you’re not involved in, can you actually explain what the other team is doing? You should be able to not just explain what you’re doing, but be able to explain what everyone else is doing. This is really important.
Howie: (from list) we have diversity, civility, collaboration/participation
OVERALL ROADMAP REVIEW
Product Areas:
- Discussions
- Activation/Retention (E3)
- VE: Continued feature development bug fixes, performance, internationalization, et.
- Mobile Contributions
- Tablet: Editing via VE
- Apps: photo upload + contributions (not full scale native editing)
- Content Translation + Machine TranslationMultimedia:
- Viewing and contributions; curation
- Design: beta experiments, mobile profile