Background
This fiscal year, the iOS team is seeking to increase unreverted mobile contributions. One of our hypotheses to achieve this growth is by introducing Suggested Edits to the iOS app. We anticipate an increase in edits on iOS as a result of introducing Watchlist and Suggested Edits. If this occurs, it increases the importance of our in-app editor performing as close to expected as possible. Our current editor is not native and as a result we experience bugs that are very challenging to overcome. The iOS Wikitext section editor is an in-app web view that uses a bundled version of the javascript library Code Mirror 5 to support wikitext formatting, syntax highlighting, line numbers, undo / redo, and find and replace.
The purpose of this task is for us to ensure our editor is native and that we have more control over its performance. We also want to ensure that editors have the tools they need to meaningfully contribute to articles from their mobile devices without relying on Mobile Web.
Problems
Today’s problem
We want to support full-page article and talk page editing in the iOS app. After allowing for full wikitext to go through our current editor, we noticed significant lag times on lower powered devices with first initial load, find, and text size changing. These issues are captured in this video of an iPhone 7 loading the Barack Obama article on EN Wikipedia.
Past problems
In general, the Code Mirror editor has been difficult for us to maintain. It is written in a language that the iOS engineers are not accustomed to working with, and we lose a lot of our tools for native development, like Xcode breakpoints for debugging and instruments for performance analysis.
Because of this, the app has many bugs in the backlog that are difficult for us to fix.
https://phabricator.wikimedia.org/T259763,
https://phabricator.wikimedia.org/T265442,
https://phabricator.wikimedia.org/T285282,
https://phabricator.wikimedia.org/T216174,
https://phabricator.wikimedia.org/T265442,
https://phabricator.wikimedia.org/T287257,
https://phabricator.wikimedia.org/T244917,
https://phabricator.wikimedia.org/T285282
We are doing some method swizzling for some portions of this editor as well. Method swizzling is an ill-advised technique that involves swapping out the implementation of an Apple method to one of our own, so that our version is used if it is called at any point by the system. From looking at the linked comment/reasoning, a single native line (textView.becomeFirstResponder()) can replace this brittle web view workaround.
Must haves for proof of concept
- Editor is native
- Users can edit a full article
- Icons, text formatting and Fonts are updated based on our component library
Nice to have
- More consolidated and modern edit menu
- Syntax colors have parity with Android
User stories
- As an iOS app user, I want to edit a full page article, so that I can add and edit templates in ways that are not easy to do through section editing
- As an iOS app user that only has access to mobile devices, I want access to full page editing for a talk page, so that I can delete or modify a typo in a talk page reply
Primary target audiences
Quant:
- KR: 2% decrease in edit abandonment
- KR: Engagement with full page editing is comparable to Android
- KR: Increase in unique user edit rate
- Guardrail: Passes review from accessibility users
Qual:
- No reports of reasonably fixable bugs with the native editor through the app store or our support email in a 30 day period post release
Measurement Plan
- AB test if we see a higher rate of edits per person that engage with the new editor
References