Submissions/Editing in the year to come – what the Foundation's Annual Plan means for editing tools/notes
SESSION OVERVIEW
- Title
- Editing in the year to come – what the Foundation's Annual Plan means for editing tools
- Day & time
- Aug 11 11:30
- Session link
- Submissions/Editing in the year to come – what the Foundation's Annual Plan means for editing tools
- Speakers
- James Forrester
- Amir Aharoni
- Dan Garry
- Joe Matazzoni
- Notetakers
- User:Catrope
- User:Slashme
- Attendees
- Mary Mark Ockerbloom, WIR, Chemical Heritage Foundation, Philadelphia, PA
SESSION SUMMARY
[slides about annual plan]
Q&A
Q: John from WMUK. Is there a plan to help out the Commons application that has progressed quite a lot this year through the hackathon in Vienna? I did a couple videos about it because I think it's really important. Talked to Dan about it in Vienna, wondering if there is some capacity for WMF to helping to progress that project. It's got to a point where you can see what's around you on Commons, but no support for editing in the app yet, or uploading straight from the app.
A (Dan): The Commons app has done really well. Mobile apps team had to drop it to focus, has been picked up by volunteers, really pleased with that. Biggest changes that will help is Structured Data on Commons project. That wil make it easier to ask someone "what's in this image?", ask them to put in tags, without having to write wikitext. That's not going to happen for a while, but we're interested in helping out with that. Native app development is not something we normally do in our department, but I'm keeping an eye on this project. [Give them more money] That's not me. [The grant has been renewed for it] I ensore the grant renewal
Q follow-up: Grant?
Dan: Endorses it.
Q: Carol form Gamepedia ?? Our wikis tend to be highly customised for various games. Interested in skinning: can we make the wikis more universally skinnable. Mostly anchored in whiteness right now, and games are mostly black.
A: Skinning is more reader-side than contributors. 3rd-party use ouf our tools is important to us. The Mediawiki platofrm team (interested in 3rd party uses). No current plans to rework the skinning system more generaly. Make it more variableisde? Making it blend in, not have to be hacked by each sysadmin, but not currently working on anythin in that area. Visual-editor in particular and 2017 wikitext editor: work has been done by ?volunteers? to hard-??? Might be in improvement for the sysadmin, but ???
Q: (CScott) How about that image roles stuff? Is there any work on that?
A: James: Folow up to previous question - change wikitext interface for image transclusion. The Gallery slider mode already occupies the width of the "page", automatically. Your phone will get a full-width images, as will your desktop/laptop. This feature is not widely used. Little feedback aobout it. The ocumentation isn't updated to encourage people to use it, and there are conversationas about whether it's the right way. Re-doing wikitext so that image transclusion is role-based is scary. This is a post-usemod (but not very post-usemod) feature of wikitext, and if we were to start over, we'd do it differently . Images are used as icons; some pages have over 400 images, e.g. Barack Obama. Not currently planning to work on that, but if there's an RFC, that would be a good time to start. Ask the users: danger of design by committee. Wikitext has been built piece by piece by various people with very little connection, so it's a bit of a confusing mess. The concept of "three kinds of pictures - pick one" would be a difficult discussino to have.
Q follow-up: More limited to the management side of the feature. Do you feel this is in your remit? Is there still a multimedia team?
A: Yes, there is still a multimedia team in Readers. They're quite occupied with Structured Data on Commons, huge amount of work both in engineering and engaging the Commons community. We signed a grant saying we'd do that work. Don't think image roles is on their list of things to work on but it might be.
Q: (?) There are lots of different wikitext editors out there, what are you going to do about that? Problem for help pages and documentation
A: JDF: We have a lot of editing interfaces; too many. That 's bad and confusing. Bug reports may be unclear; it's confusing to users who click edit and don't know which editor they will get. The start of the editing session is a multiple-choice quiz. We do work with users to see what works for them, but then we give them something that doesn't work so well. Program 3 covers consolidation of our editor experiences. The experience should be consistent between destkop/moblie and various languages. Users who don't have JS can't get the same rich experience. We do the best we can then. Other than that, we're trying to consolidate. We don't want to kill off all the editors, but if an edtior has 2 dozen users, it's not reasonable to spend donor funds and slow down our servers to support it.
A (Dan): At last count, there were 16 editing experiences you could have. There are more that don't have an eidting box in them, e.g. HotCat. To solve this problem ,we will be introducing a new standard, and then we will have 17 wikitext editor. I'm talking about the "New Wikitext Editor" / "2017 wikitext editor". Shares a lot of code and tools with VisualEditor, so you'll be able to use Citoid for generating citations etc. As far as getting rid of the 2006 wikitext editor, some people are upset that we're removing it but their screenshots aren't even that editor, which is part of the problem. So we want to consolidate and have less confusion.
A (Amir): Who uses ContentTranslation? It will gradually transition to using VisualEditor as its editing component. Currently it's yet another editing interface. The general design is two columns side-by-side, that will remain, but the area where you type the translation will switch to using VisualEditor. Which will give translators access to all the same tools that VE provides. So that's another step towards unifying all this stuff.
Q: (Deryck Chan) The 2017 source editor seems to require you to load the entire page in one go, which almost defeats the purpoes of using the source editor, which is editing only one section. At the same time you want to do mobile editing more efficiently. Where are all these tools headed.
A: JDF: Can do section edting with 2017 source editor. You can't switch back and forth between section and visual mode, because VE requres knowledge of whole page, and we don't ahve a way to extract that. We could build that, but not soon. Section editing should work fine, and it didn't from day one, but should work now. In terms of mobile wikitext editor: we haven't finished that work. Some performance testeing needed. There's this part of htl called image-set, for example on mobile high-res screens, allowing you can zoom in. on high-res thumbnails We switch that off on mobile, because most mobile users are more concerned about bandwith and speed than glorious images. The reading team have done some great work on soft-loading images; only ship that on desktop.
Q: (Michael) People not from Wikimedia movement will come up with grand new designs for what Wikpeida should look like, people from the movement will respond that it's not that simple, first and foremost because it affects how you edit. James introduced the annual plan for 2017-18, I wonder how often you were approached with suggestions/questions about "what about the future of editing in speech, dictation". How much do futuristic questions like that shape your thinking when preparing for an annual plan?
A: Trevor Parscal: Want to share hwo we come up woth the annual plans. We had to find the overlap between what can be accomplished in a year; what the most pressing issues are; aling with pressure from executives; what's the valuabe thing we can do for communit. Come up with list of community liaisons, make sure we're intouch with the community aspects (e.g. wishlist). The really amitious exciting things don't get a lot of attention. THat's a reality we've sen for some years now. The way that we tend to do that is, if there's a will in the volunteer community or staff, they start off at grassroots, and maybe later look viable. This is areasonable way to set up an annual plan, but it only looks 2-3 years out. Maybe movement strategy will make us think a bit further out. The best way to get this going is therefore to start working on it; prove viability, and then staff can maybe latch on to it. For example, VisualEditor. I was part of group taht evaluated how bad wikitext was. We were told to build a visualeditor, but we didn't think it was obviously possible. In 2010-wikitext editor project development, in my spare cycles, I was able to demonstrate that VE was possible. Many were concerned, but could build a team. After a lot of advertising, we were able to build something that served many people's use cases. I get excited about things like "how to do video editing?" - prove it's possible, and then build on it.
Joe: ORES: started as a volunteer project under Aaron Halfaker, and now ?not sure what followed here?
RecentChages was a 10 year old interface, and the ideas to improve it were pretty wild. ?not sure what followed here?
Q: I'm a heretic: question on wikitext editor on 2017. What is the problem that it solves? VE solves some problems for some users. I tested the 2017 editor, and it blocks me in editing. Previous editors had a layer of javascript over the existing stuff. The new editor is (correct me if wrong), a massive JAvascript implementation, with a long loading time and high performace use. If it's rolled out that way (as I last tested it), it doesn't work for me, and there will be community outcry.
A: Need to look at performance. In some cases it's even faster, but many cases where that's not true, especially on large articles. In terms of what problems it solves: it's more of an integrated editing experience. Many experienced editors like VE for tables and templates, but not for everythig. This editor gives a more integrated experience in that sense.
Q follow-up: Even if the performance improves a lot, there's still a loading bar at the start, and many people like me prefer to use the visual editor for content work, but as soon as it gets complicated, we fall back to text editor. We need something rock solid for that kind of work. It would be a major usability issue if this rock-solid thing goes away.
A (JDF): You're right that the VE editing is not a text area, and that ha benefits as well as losses. In 2017 text editor, headings are larger: you can't do that in a textarea. Maybe later code folding etc, which we can't reasonably do in a textarea. The issues that it works like a visual editor, is that's by design. Same tools in the same positions to do the same work. Can't really do that piece by piece.
Q follow-up: When you activate 2017, you lose the fall-back textarea.
A: Yes, that is true, you have to opt-out at the moment, but that might change. The 2010 editor will still be supported,
Q: I welcome improvements on editing WP: too hard for newbies, but we have legacy editors (people) and we have to care for them as well, and if we switch to a new system, we shouldn't add something new knowing that experienced editors will sitll use the old interface: this makes a gap between new and old editors. Old editors on monobook can't talk to the new editors. Need to keep the performance and reliability of the option to have the really basic editor still available.
A: 2017 editor is stil in beta, still missing features.
A: Impressed that we have this kind of discussion - other communities don't really have this (e.g. tumblr)
Comment: Visionary response: tis will give great improvements in future, but it's a way from here. Long-term goal is that when you read the page it's loaded in parsoid, and when you click edit, you can edit even a tiny piece (e.g. paragraph). It's a long way to get there. When youopt into the beta feature, it's not going to be easy, but at the end we'll hae something that's significantly better than wha twe have now.
Comment: aSk about recent changes.
Q: Want to support the 3 options. You will never get rid of those users who only want the text. Great to have a slick intermediate option, but also need bare-bones.
A: There will always be a non-JS version The question is whther you present new users with three options is a different one. About the monobook user question: if we were not willing to make big changes, we'd never have had vector.
A: JDF: I was an original monoboook hater, but I accepted it in the end. THings like the 2010 wikitext editor aren't going anywhaere.
Q: Are you considering trying to find spam in Recent Changes? What about machine learning?
A: New beta for RC does include ORES machine-learning filters, and spam is one of the categories of damage that would e recognized. A bit of a black-box. Any recommendations?
Q-follow-up: Nothing beyond what has already been tried.
Q: RC question: I tried using custom JS/CSS for RC, and it didn't work. Any plan to change that?
A: Should work on RC, so please report bug. But with new beta feature, please think carefully about what CSS you want to override.
Q: One of the tings in the annual plan was things to help communities reduce backlogs.
A: Project that hasn't begun yet. Entering research phase soon. The goal of that project is to help direct volunteers where they can be of the most use. Not that there's nowhere to hlep, but too many, and some overlap, some contradict each other. The first step is to surveay what's going on, and come up with a plan. Will set up project page, and ask fo rideas.
Q Follow-up: SuggestBot gives you suggestions based on recent contributions.
A: Yes, will look at that.
Comment: for those interested in ?? imporvements, there is a session on Sunday about ORES, so if you're interested, come to the session. Looking for feedback.