This epic represents the work with determining if and how editing functionality will be implemented within the fixed sticky header on the desktop site (T283505).
The requirements that will guide the implementation of editing functionality within the sticky header have been moved to T296910.
- Are we trying to promote editing among logged out users? If "yes," we need to consider displaying the edit affordances within the sticky headers to logged out users.
Notes from the conversation @ovasileva and I had on 12 August about the above:
We also need to consider what to do if the page is protected. For example should the text be "view source", and show we show a padlock?
@ovasileva, we talked offline about it being helpful for me to offer more clarity about Requirement #4. [i]
Question for you: Does what I've shared below provide the clarity you were seeking and/or bring new questions to mind?
Next steps
Assuming you support heeding the ===Concerns documented below, it seems like the next step will be for us to decide how the Pre- and Post-deployment mitigation strategies will be executed.
Below is a description of the concerns we have about the sticky header's potential to negatively impact editors' ability to intuitively move between reading and editing and vice versa.
Also below:
Transitioning to and from editing: People need for the content that is visible to them to remain stable throughout the transition to and from editing mode [ii].
i. "Editors, across experience levels, can easily understand how the different modes (reading/editing) relate to one another so that they can intuitively move between the two."
ii. We consider the "transition to and from editing mode" in this context to mean: A) opening the editor by way of pressing any editing affordance, B) abandoning an edit by way of pressing Back in the browser or Esc, or C) publishing an edit by way of publishing a change/set of changes.
@MNeisler: No action needed from you at this time. Although, I am copying you on this comment so you're aware of the conversation happening about how we might evaluate the extent to which volunteers are finding the edit affordances within the Sticky Header valuable, as they are currently implemented.
Thanks for taking the time to write this up, this is super helpful! A few questions/comments below
Transitioning to and from editing: People need for the content that is visible to them to remain stable throughout the transition to and from editing mode [ii].
- I. Concerns:
- A) People will abandon edits at a higher rate because they will have difficulty locating the content they pressed an Edit affordance within the sticky header wanting to affect
- B) People will need to expel unnecessary effort confirming the changes they made had the impact they intended because they will have difficulty locating the changes they made once landing back in read mode.
- II. Pre-deployment mitigation:
- A) Converge on requirements for T293158 and verify they've been met
- B) Instrument the edit affordances within the Sticky Header (if they are not already being instrumented as part of T285749) so that we can compare edits initiated from within the Sticky Header to edits initiated through section edits links and the existing page-level affordances.
Clicks are instrumented as part of T285749: [EPIC] Instrument and analyze success of user links menu
- C) Once T293158 is resolved, share the Sticky Header with volunteers to learn how they find it impacts their ability to:
- Locate the content they clicked the "Edit" affordance within the Sticky Header wanting to affect
- Return to the content they were reading prior to clicking the "Edit" affordance within the Sticky Header
This looks good for us, although I did have some questions - I wonder if we can push back on this requirement a bit. Since we do not have another prototype round planned for the sticky header, it would take a significant amount of time for us to set up and would push our timeline even further back. Currently, we're planning on deploying by the end of the month if possible (or as soon as we can resolve the other blockers). My question here would be - do we think that the sticky header creates a different expectation than the section edit, and if so, why? Is the main concern that people would think that selecting edit should take them to the top of the page, and if so, could we potentially investigate this on some of our pilot wikis once we deploy? One way of doing this I think we can consider is starting with a couple of smaller pilot wikis and asking editors about this explicitly before doing a wider deployment. Another way would be testing this with our community ambassadors - it's a small group but we would be able to get detailed feedback from them. What do you think?
@sgrabarczuk - perhaps we can draft something the ambassadors can share with their communities over the course of this week. Potentially they can test from the transition prototype.
- III. Post-deployment evaluation:
- Evaluate how the edit completion and edit abandonment rates compare between edits initiated via the Sticky Header and edits initiated via the existing section- and page-level edit affordances
+1 on reporting this. While we are instrumenting clicks, I'm unsure if we can currently trace them back to the edit session initiated. @jwang - do you know if we need to add any additional instrumentation for this? @ppelberg - do you think we should set a target for this? My intuition says that initially we would see more abandoned edits as people are just trying out the new functionality, then these would level our in time as people begin using it to make edits.
I will partner with @MNeisler , to understand whether current schemas can answer below question.
III. Post-deployment evaluation:
Evaluate how the edit completion and edit abandonment rates compare between edits initiated via the Sticky Header and edits initiated via the existing section- and page-level edit affordances
@MNeisler and I had a sync-up. Both edit schema and sticky header schema have data field for session_id. The edit schema EditAttemptStep uses editing_session_id to capture session_id. The sticky header schema DesktopWebUIActionsTracking use web_session_id to capture session_id. We should be able to connect two schemas by the session_id. The one potential problem is that data logged in EditAttemptStep is heavily sampled with 1/16th rate. DesktopWebUIActionsTracking schema is current sampled with a rate of 20% for logged out users, and a rate of 100% for logged in users. @MNeisler suggested to use is_oversampled field on sticky header scheam DesktopWebUIActionsTracking , making sure all events are captured. The Growth team did something similar in 2019 to track edits that came from suggested edits on Special:Homepage https://phabricator.wikimedia.org/T238249.
@ovasileva responses to T287545#7441368 below. I appreciate we covered a lot of the below in the meeting we had on 21 October. Tho, I figured it would be helpful for this ticket to be updated with what we discussed offline.
Before getting in that, it seems like our next steps are as follows...
Next steps
Oh, excellent.
- C) Once T293158 is resolved, share the Sticky Header with volunteers to learn how they find it impacts their ability to:
- Locate the content they clicked the "Edit" affordance within the Sticky Header wanting to affect
- Return to the content they were reading prior to clicking the "Edit" affordance within the Sticky Header
This looks good for us, although I did have some questions - I wonder if we can push back on this requirement a bit. Since we do not have another prototype round planned for the sticky header, it would take a significant amount of time for us to set up and would push our timeline even further back. Currently, we're planning on deploying by the end of the month if possible (or as soon as we can resolve the other blockers). My question here would be - do we think that the sticky header creates a different expectation than the section edit, and if so, why?
In general, I think people expect to be able to quickly locate the content they pressed an edit affordance wanting to affect.
In this way, I think the edit affordance within the sticky header and section edit links have to meet a similar expectation although what's required to meet that expectation in either case is likely to be different.
Thinking...
Section [ edit ] links are visually related to a particular part of the document/content whereas the edit affordance with the sticky header are not.
The One way of doing this I think we can consider is starting with a couple of smaller pilot wikis and asking editors about this explicitly before doing a wider deployment. Another way would be testing this with our community ambassadors - it's a small group but we would be able to get detailed feedback from them. What do you think?
Olga and I have plans to talk this week to decide what testing we will do to learn how volunteers, across experience levels, expect the edit affordance within the sticky header to behave.
- III. Post-deployment evaluation:
- Evaluate how the edit completion and edit abandonment rates compare between edits initiated via the Sticky Header and edits initiated via the existing section- and page-level edit affordances
...@ppelberg - do you think we should set a target for this? My intuition says that initially we would see more abandoned edits as people are just trying out the new functionality, then these would level our in time as people begin using it to make edits.
+1, I think it's a good idea to set a threshold for what we do and do not consider to be acceptable changes in the edit abandonment and completion rates.
I also agree with the intuition you shared about expecting to see increases in edit abandonment and completion rates level off over time.