+Community Wishlist (please add project tags to allow filtering by codebase - thanks!)

samwilson opened https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/179

Remove 'Edit with form' link from tab bar

samtar merged https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/179

Remove 'Edit with form' link from tab bar

@JSengupta-WMF @Samwilson note this means that when viewing an action page other than view, you'll see "Edit" and/or "Edit source" which you might click, but it will take you to the respective editor instead of the intake form. The "Edit with form" tab was useful as a means to edit the wish from other views.

Examples:

• View history https://wishlist-test.toolforge.org/w/index.php?title=Community_Wishlist/Wishes/Not_enough_chocolate_in_the_house&action=history
• Page information https://wishlist-test.toolforge.org/w/index.php?title=Community_Wishlist/Wishes/Not_enough_chocolate_in_the_house&action=info

I also think the "Edit with form" tab is beneficial because it's placed next to the buttons normally used to edit, thus promoting use of the form.

You can almost think of the intake form as a an editor of its own. You have VisualEditor ("Edit" tab), wikitext ("Edit source"), and the form ("Edit with form"). In this regard the tab makes it more obvious there is a different means of editing the page. The "Edit wish" button meanwhile isn't redundant because it's aimed more towards the reader or the content-focused user. So it's like "Edit wish" is the call to action, and "Edit with form" is there to satisfy interface requirements (the different ways of editing the page have their own tab). Just my 2c!

Note we will be implementing edit notices throughout the wishlist pages. When someone edits a wish without using the form, we can have an edit notice letting them know that the form is the preferred method.

I just added gifs of what MusikAnimal was explaining from his examples.

Test Result - Wishlist-test.toolforge

Status: ❓NMI
Environment: Wishlist-test.toolforge
OS: macOS Sonoma 14.5
Browser: Chrome 126
Device: MBA
Emulated Device: NA

Test Artifact(s):

Test Steps

1. View history https://wishlist-test.toolforge.org/w/index.php?title=Community_Wishlist/Wishes/Not_enough_chocolate_in_the_house&action=history
2. Page information https://wishlist-test.toolforge.org/w/index.php?title=Community_Wishlist/Wishes/Not_enough_chocolate_in_the_house&action=info

View history	Page Information

See also T369878: VisualEditor doesn't understand the wish template when editing as a full page which would I guess necessitate us reviving the "Edit with form" tab.

@MusikAnimal @GMikesell-WMF thanks for the detailed explanation. Agreed after seeing the use case that the link can stay. When I tested it earlier, the link wasn't showing up from anywhere else except from the wish detail normal view. An I feel in that view it's least important cause advanced editors will probably not use the form anyways to edit. I was going with the UX best practice of not having the same entry points multiple times on a page. If you think strongly it will help users access the form from different views, it can stay.

I'll add it back in. I liked having it too.

samwilson updated https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/185

Revert "Remove 'Edit with form' link from tab bar"

musikanimal merged https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/185

Revert "Remove 'Edit with form' link from tab bar"