Визуален редактор/Пътна карта/Обновление 23.06.2016

До всички,

Мислех, че ще е полезно да изпратя актуализация за редактиращия софтуер. Измина повече от година от последната и нещата се промениха (и е лесно да се изгубят следите). Поставихме някои високи цели за редактирането в годишния план на Фондация Уикимедия за следващата финансова година. Актуализацията дава малко повече подробности за това, със специален акцент върху екипа, работещ по инструмента за директно редактиране на съдържание. Ако се интересувате, има и кратка, по-съсредоточена върху достъпността, пътна карта на MediaWiki.org.

Статут

В редактирането, продължаваме да работим по нашата поръка от стратегията на общността за 2010 г. да се създаде богат визуален редактор, който да даде възможност за редактиране на цялото ни съдържание, и да участва в работните ни потоци, без да се знае или да се налага да се учи уикиформатиране. Това е работа в процес; както при всички наши подобрения на софтуера, ние никога няма да бъде "готови"; и се надяваме да забелязвате подобренията с течение на времето. Всяка седмица излизат нови функции, подобрения или корекции на грешки, често водени, променяни или подкрепяни от нашите разработчици на доброволни начала и обществени пионери; моите благодарности на всички ви.

До момента изминаха около пет години от работата по визуалния редактор и има добър напредък по съдържанието му при работата на много потребители, спомагайки на редакторите да прекарват повече време върху това, което редактират вместо как да го редактират. Първо и преди всичко, не се налага да мислят върху капризите на уикитекста. Инструментът за автоматично цитиране прави добавянето на нови препратки към сайтове или DOI много по-бързо и внимателно, подобрявайки качеството на съдържанието. Визуалните инструменти за търсене на медийни файлове улесняват намирането и добавянето на по-голямата част от изображенията и другите медийни файлове в Общомедия и добавянето им към страница. Редактирането на таблици спомага да се правят промени в таблици, като например преместване на колони или редове, много по-лесно отколкото в уикитекст, като спестяват време на нашите доброволци които да се съсредоточат върху работата си по-добре.

Визуалният редактор поддържа много (но все още не всички) от езиците, и благодарение на подкрепата и ангажирането на общността, редакторът е достъпен по подразбиране за над 235 Уикипедии (и като опция в останалите 55), включително и почти всички най-големи Уикипедии. Тя е включена по подразбиране за излезли от системата потребители и новорегистрирани на 233 от тях, и на 2 за нови сметки (но все още не за излезли от системата потребители), на английски и испански език. Към тази седмица, това включва представители на всяка една страна от "CJK" езиковата група, с четири различни скрипта за китайски език (класически, кантонски и Ву, както и Мин Нан), корейски и японски. В момента работим с всяка от останалите общности с молба, ако за тях е добре също да преминат; следващите групи ще бъдат тринадесет Уикипедии с арабски скрипт и 23 индийски Уикипедии. Ако се интересувате, можете да видите конкретните подробности в таблицата за внедряването.

Работихме и със сродните проекти на Уикипедия. Както може да си представите, всеки проект има различни нужди, работни процеси и проблеми и е важно за нас, да гарантираме, че инструментите, които предлагаме, са променени в зависимост от случая. По молба на общността, визуалния редактор е вече достъпен за всички потребители на няколко различни сродни проекта, но смятаме, че има още какво да се направи за други, преди да насърчим по-широко това. Неотдавна работихме с общностите в Уикипътешествениците, които са доста подобни на Уикипедиите относно нуждите се от визуален редактор; нашите благодарности на търпението и помощта на Уикипътешествениците. Работим също и с User:tpt и други доброволци, които създават и поддържат софтуера, използван от Уикиизточниците за адаптирането на визуалния редактор за работа с тези функции.

Работа по основния код и поддръжка

Despite this progress, there are still several areas in which the core functionality of the editing software needs extensions, improvements and fixes. In many places within the visual editor software we have to work around browsers' bugs, missing features and idiosyncrasies, and nowhere is that more problematic than the critical areas of typing, cursoring, and related language support. There continue to be irritating, occasionally serious bugs related to these, for which we continue to partner with browser vendors and experts around the Web to try to develop workarounds and improvements.

Another important area related to language support is coming up with a solution for the nine languages in the Wikimedia family which use content language variants, biggest amongst them Chinese, which poses some very large challenges as it is fundamentally incompatible with a visual editing method. If you're interested in discussing how this might work we would love to discuss with you what possible options you think would work out, even more so if you wish to work on support for this.

The performance of the software is not yet as good as we would wish, in terms of speed, network use, and load on users' browsers. This is a usability issue for all users, but is especially critical for users of lower-powered devices (like older machines) and more powerful but limited-resource ones (like most mobile phones and tablets), where in some cases it can be not merely awkward to use, which is disrespectful of volunteers' time, but prohibitive, excluding community members from volunteering their time. We have several strategies lined up to tackle this basket of issues, from editing only small parts of a document at once – sometimes called "sentence-level editing" – to loading smaller bits of the editor at first and then larger, less-used bits as needed whilst retaining a consistent interface without changes in interface which can be confusing and distracting. More widely, working to let the software include as many possible volunteers in the community if they wish to join also covers accessibility in all its forms, making sure editors who have learning impairments or physical disabilities are supported as much as possible.

Many of our communities have put in significant effort over the past fifteen years to come up with specialised workflows on their wikis. Sometimes these efforts have involved complicated extensions and gadgets, like the use of the "inputbox" button to start a new article based on a template, as used on several wikis. Others provide additional tools inside the wikitext editor, like the English Wikipedia's tool to automatically created references based on a link, some of which we provide inside the visual editor now, but many of which are not yet there, and which we at the Foundation can never scale to provide the individual attention for each of our hundreds of wikis. For the visual editor to be successful, pleasant and as un-confusing as possible, it is vital that we help communities provide gadgets as appropriate, and duplicate or extend the integration with the various other editors. We look forward to helping you help others.

A big technical change we're hoping to achieve this year, as we set out directly in the annual plan, is to re-engineer how MediaWiki supports content. We want to allow multiple "parts" of content, of different parts, to be stored as revisions of pages. This is a much-needed feature already, most obvious with file pages – each file's upload history is shown separate from its description page, and videos' subtitles are stored in a different namespace rather than shown on the page. This also is an issue in other areas, making workflows more complicated, like the common documentation sub-page of templates rather than having a combined template and documentation page needing two edits to improve a template and document how it now works. With Wikimedia Deutschland's work on moving Commons' file meta-data into a proper structure linked to Wikidata, addressing this need is now acute. We look forward to driving forward the technical discussion and implementation of multi-part content revisions in the back-end, and we have some hopes with how it can be used to do new things which we discuss below.

Finally with regards to core work, our intent right from the beginning of our work on the visual editor has been to operate as the core 'platform' for all kinds of editing in MediaWiki, and not just to be another single editor. Depending on how you count them, there are currently six pieces of editor software beyond the visual editor installed on most of our wikis, which gives us six different interfaces by which to confuse users, six different sets of bugs to track down, and six different places where features can interact in unexpected ways and which need to be tested. Our goal is to gradually reduce the number of pieces of software with equivalents based on the single platform. This has already been done for example in Flow, where it uses the visual editor for rich content editing rather than re-inventing its down, and we are planning to work with our colleagues in the Language Engineering team to do the same for the Content Translation tool. We are experimenting with providing a more modern wikitext editor which can provide a consistent experience between the visual and wikitext editors, and between desktop and mobile; there's a video of our work to date on this, still incomplete, which some of you may have seen. Naturally, any new wikitext editor would have to be not just change for its own sake but better for users to be worth switching, so we're cautious about how quickly we would introduce this; certainly, a beta feature test of the initial version for the intrepid will be necessary before we make any plans as to wider availability.

Бъдещи задачи

As well as our core work, it is important to us that we also spend some of our time to explore ways in which new features can improve the experience of the site for users, helping them improve quality, breadth and depth of content more effectively and efficiently. Not all of the ideas below are ones on which we're actively working right now, but we should have some progress this coming year on at least most of them.

An idea I'm quite excited about in terms of possibilities is providing a system in the visual and wikitext editors that can prompt users as they edit. The range of different kinds of edit, from copy editing and improving references to a full up re-working of whole sets of pages, means that newbies can get lost in knowing where to start. There are lots of different kinds of improvements that we could provide, from simple static ones like "this article isn't illustrated yet" to very complex and specific ones like "this article's main wikiproject is about the USA, so wants you to write in American English". This work is aimed at reducing the burden on experienced users when they review new editors' changes, letting each wiki configure hints appropriate to that community. We also intend for these experiments to improve the "on-boarding" experience for new users, helping them learn what is wanted and valued by their wiki's community, and what makes for more constructive edits.

Once we have multi-part content streams (which I mentioned above as core work), there are several possible feature areas we think are worth considering.

A big one is that we think that there's a lot of potential in storing edits in HTML DOM as well as in wikitext. Firstly, this should allow us to help MediaWiki understand changes in edits more like the way that humans do. This would allow us to provide neat features like visual diffs and animated histories of pages. Showing clearly who wrote which parts of an article, or what parts of the article have been changed most recently, is not a new idea but hasn't been practical to implement at scale. It would be fascinating to see if this tool could assist in deepening the richness of understanding for readers of the staleness or volatility of articles in practice.

More importantly, it should allow much better automatic handling of edit conflict situations, and so reduce the occurrence of edit conflicts that need manual correction. Theoretically, it could let us remove edit conflicts entirely, though this would mean making some decisions about how edits work which we may decide are worse long-term than having manual resolution of edit conflicts; we're not planning to make a decision on that until we know more.

Storing pages in DOM could also allow smart partial document saving, splitting up your bigger edits into different chunks, each of which you can save as you go. Making smaller, simpler edits. This could also let us reduce edit conflicts by prompting people to save bits as they edit, and pushing those new versions "live" into the editor of others also editing at the same time.

The final thing I'll mention that DOM edits could do is allow DOM-based annotations to pages. With this, citations could be 'applied' to bits of the article showing which statements are (and aren't) backed up with a reference. Discussions could refer to a specific image, sentence or word choice to let editors have deeper, faster conversations, and understand when they're editing a potentially divisive section. Illustrations like diagrams and maps could highlight an area.

Another thing we're keen to explore with content streams is improving how page meta-data is edited, centralising the data about a page's name, protection level, whether it should show a table of contents, what pages redirect to it, and so on. Each of these examples is currently edited in a different place and with a different tool. We think it could help a lot to provide these controls together, editing a new "part" of the page alongside the wikitext block. Note that we're not planning on removing the existing mechanisms, which each work well enough – this would be an additional tool, at least at first.

A final item worth mentioning, because it comes up a lot as a technical/editor wishlist item from some editors and developers alike, is real-time collaborative editing. I wrote some details a couple of years ago about how this, especially the "full-throttle" collaboration system (like Etherpad or Google Docs, where there can be multiple users at the same time each with their own cursor) is a huge problem, not just a technical one but critically a social one. Despite this, I do hear quite often from people about how this would be very helpful, for mentoring new users and those doing something with which they're unfamiliar, and for content editing collaborating, like for edit-a-thons, breaking news articles where lots of changes are wanted at the same time, and themed collaborations of the day or similar. I'm keeping an open mind as to whether we will ever do this, but it's not something we're worrying about right now.

Резюме

As you can see if you have made it this far, there's a lot of different things we're working on in the department. I'm hopeful that the improvements we make have already made, and will continue to make, the editing lives of those reading this a bit easier.

I'm thankful for all the support we get from across the communities, be it in the form of clear suggestions, complaints and proposals, technical advice and volunteering, or anything else. If you're technical, and a current or prospective volunteer developer interested in working on some of these areas, we would love to help you.

I'll be at Wikimania this year. As always, I'll be happy to talk about anything in this update — or missing from it — in person there, online on Phabricator or IRC, on-wiki, or wherever else. Your thoughts and responses are what guide us, and what makes it worth doing. Hope this was interesting!

Препратки

Оригинал: [1]