@Samwilson where can I check the form?

Checkbox has been removed and copy updated.

Same design file. I will pop the link in here and add this task to the related task again.

I adjusted it. You can use 200 and 100 spacing.

@Samwilson yes. I have updated the button state to disabled in design when the checkbox is not selected.

I think the approach overall is good. Rather than blocking the user, providing them option. We can combine it with

In T362274#9704962, @MusikAnimal wrote:

I'm thinking this should probably be called "Type" or "Proposal type". "Category" is confusing because to people familiar with the Survey, they'll think of wishlist categories (i.e. "Admins and patrollers", "Bots and gadgets", etc.). Additionally, "Type" roughly translates to what it would be here on Phabricator (Feature request, Bug report, etc.). cc @GLima-WMF

Great!

@HMonroy can the confirmation be on a popup instead of sending the user to a Special page? We can also include a setting on the same pop up saying "Do not ask me for confirmation in the future". But in that case we have to include the option to enable it again in the user preference. WDYT?

What are the implications of accidental logout? Do users lose any unsaved data? I can write the message according to that.

Looks cleaner. Can the boxes be of smaller size encompassing the text only?

Yes. Let's start with this and see if we get any insights when people start using this feature.

Yeah the pop up is really clunky. Is it a system component?

Unfortunately not.

There is also tooltips on all the highlights displaying "added"/"deleted" so now that I think of it, showing the legends at the bottom should also work.

Looks good. I wonder if we keep the legend at the top still under the buttons (left aligned and push the content down by another line, how would it look. My concern remains the same that if the diff is too long, it will be at the end of the page. But if users generally know what the colors mean then showing it at the bottom doesn't matter.

Hi, Am I looking at the mobile resolution? As far as I remember, mobile web was out of scope. when I look at it on mobile it shows different color and the feature is not available. However, if I open it on desktop and reduce the resolution to mobile, the legends go from top to bottom. I was wondering if it's possible to keep the legends still on the top. In case the diffs are too long, the user has to scroll all the way to the end to read them.

@Samwilson your first assumption is correct. regarding the second one are you saying the naming convention can be Page title --> Section?

Thanks for bringing this up. It's always hard to predict if entry point to a new feature at a prominent place on the UI is required or not as we don't have much analytics on how important this feature is. We try to estimate it based on how popular the wish is. If both of you (being much more experienced editors) feel that it is not necessary, we can launch it without a dedicated entry point from anywhere. I wouldn't be in favor of turning the feature on/off from user preference as it's just a matter of click to discard the saved edit and launch the current version. If we don't have a direct link to Special:Editrecovery, including this in the user preference might confuse users even more. wdyt?

Based on the discussion with @Samwilson on December 5th 2023, the following will be part of MVP:

Yes that is fine. The icon should be greyed out too.

@Samwilson in Codex there is a color called Content/disabled. You can use that grey.

As per our discussion on Slack, let's go with the following

@Samwilson thanks for thinking about this. Yes it should show only when there is anything to be recovered. The link looks good otherwise. I will propose using an icon (on the 3rd screenshot) to keep it consistent with the other menu items. For the time being you can use the history icon from Codex.

@MusikAnimal Is it possible to show the toggle on the next line when the screen size is too small or the text length is too long? Something like this

Done

Showing the error when user clicks the link is a better UX and less hassle for the user than letting them fill up the form and then throwing an error.

For MTP we can agree on a fixed number but for future versions, I feel we should revisit the one size fits all model. As @Tchanders mentioned, "I see that a new account might be less trustworthy, but wondering if they might also be more vulnerable..." this needs more thought.

Let's keep it in two lines so. Some examples -