My notes follow. I have attempted to present them in a stepwise manner, touching upon the different facets of the current edit request process, and my thoughts on the same:
-
The blue "Submit an Edit Request" button on the view source page for the semi-protected article I chose ("Adachi, Tokyo") was fairly obvious and prominent. However, I don't think it would be immediately obvious to newcomers that you need to go through "View Source" to make an edit request, unlike the more obvious "Edit Source" button on unprotected pages.
-
General note, not directly related to making an edit request — it doesn't seem like the best UX to have "If you have a user account, log in first. If you do not yet have an account.." or some variation thereof. It might be better to just show the relevant information based on if the user is logged in ("Make X number of edits and make sure your account is Y days old...") or not ("Log in, or create a new account..."). More of a site wide suggestion, but thought I'd point it out.
-
It is not immediately obvious what exactly the "Show Changes" button on the "Editing Talk:Adachi, Tokyo" page is showing — I only realised it was showing me the changes with respect to the talk page of the article I was making an edit request to, not the page itself.
-
In fact, the title of the page from where we make the edit request ("Editing Talk:Adachi, Tokyo") is somewhat disorienting at first, especially when contrasted to the more straightforward flow of an unprotected edit. Having a small section talking about how edit requests, once submitted, show up on the talk page of the article would be helpful since it would explain where the "Editing Talk" is coming from (I realise that there is a hyperlink to an article which explains what a talk page is, but stuff could probably be a little bit more accessible for the average user or wikipedia beginner). In short, the connection between edit requests and the talk page for that particular article could be made clearer.
-
There's a small but confusing amount of "boilerplate" text in the text field for the edit request ("{{edit semi-protected|Adachi, Tokyo|answered=no}}" and so on). This could be off-putting to some users, making them feel like the process is more complicated than it actually is. Not that big of an issue — the boilerplate will be reduced/abstracted while designing and implementing the edit request wizard.
-
Minor change, but the "Permanent" option in the "Watch this page" dropdown could be changed to "Until turned off/unwatched" or equivalent. This wording would probably seem less absolute, if that makes sense.
-
The preview page currently shows a preview of your to-be-added talk page section at the top, and the request form below it. It might make for a better UX if the request form wasn't shown like this, since a user might be confused as to if the form is part of the preview or not. Instead, we should show solely a preview of the request (and the existing "Go to editing area" button to head back and make further edits).
-
Once I had made the request (with a mention of it being for a GSOC microtask), I noticed that beyond maybe formatting there's not much difference between an edit request and a non-edit related section of the talk page (which brings us back to connection between talk page and edit requests). This doesn't directly impact the requester, but might still be something to look into.
-
You can view the edit request I made here (there’s really not much to look at): https://en.wikipedia.org/wiki/Talk:Adachi,_Tokyo#Semi-protected_edit_request_on_26_March_2022
-
Overall, the process took me around 30 minutes (it would be shorter if I weren't looking into all the aspects of the process and noting down my thoughts).
Summarising my overall thoughts about the process:
- Need to have error messages and feedback about the proper format to be used while making an edit request (perhaps by completely disallowing requests like “Please change XYZ” by having pairs of and fields in the to-be-made wizard.)
- An effort should be made to abstract away as much information/options as possible, in order to make the process more inviting for beginners. There’s no reason to overload the requester with things like the accepted parameter and other jargon which are irrelevant to them.
- The hardest/most confusing part for me was discerning what the Talk Page had to do with an Edit Request (in hindsight, the connection isn’t very tenuous, but considering I was left scratching my head while I poked about and read up on talk pages, I imagine beginners might also be similarly affected).
- Shift the “Submit an Edit Request” button to the top pane on the main article page (alongside “Read”, “View Page” and “View History”). I understand that this is outside the scope of this GSOC project which is concerned only with the process after the user navigates to and clicks the edit request button in “View Source”, but again, thought I’d point it out.
- The Edit Request Wizard should ideally live on a page titled “Making an edit request for/to ” or something to that effect, instead of just the editing page for that article’s talk page. As pointed out earlier, this will reduce beginner confusion.
- The Wizard could have different sections for different types of edits being requested (for example, grammar edits vs. moving the article or a section to another name/article, or adding redirects, etc).
- There needs to be proper feedback as to what appropriate and valid sources are.