@ifried spotted a typo in one of the screenshots, here is the updated file.

@Samwilson and I did some digging and it turns out Chrome supports screenshots in multiple languages (its just a very complex process). We are trying to see if we can use SVG Translate to get these translated by our volunteers 😊

I was looking at T229714: Spike: Investigate Possible Errors for WWT [4 hours] and it isn't completely clear to me in which cases it is helpful to Contact Us. We could decide to always give them that option. From that point of view the language you suggested, "Error: Refresh or try again later. If the issue persists, contact us." sounds perfect. However, it is a bit awkward to have the whole sentence be a link, but, I do understand that we might need to do this for i18n reasons.

Full resolution and retina images on Google Drive.

I'd say 0.5em for the sides and 0.75em for the top and bottom.

Was this an intentional design decision? Should the placeholder behave like other widgets, that is disappear as soon as there is something entered?

In T237034#5809605, @Tchanders wrote:

The acceptance criteria don't quite match the screenshot in the description - could you confirm that we're working to the acceptance criteria rather than the screenshot?

In T239938#5790885, @ifried wrote:

I think it makes sense to show it at all times. There are other features that always display, regardless of whether they're available to the user (such as email options before email is confirmed), so we should follow the general standard of always displaying potential options in Preferences. Do you agree, @Prtksxna?

How about something like this:

Would this be easier if only the word 'contact' was the link?

In T238782#5774466, @dbarratt wrote:

@Prtksxna or @Niharika is "Edits using this IP" the "Public" IP edits or is it the "Total" edits from that IP (Public and Logged-in Users)?

@Niharika, based on the information on each page this how I am thinking of splitting the filters

In T240530#5749286, @Niharika wrote:

Let's go with the cross.

In T241371#5772539, @ifried wrote:

@Prtksxna What do you recommend as the updated language? Perhaps something like: "Hover over text to see contributions by the same author. Click to see the author and more details."

Thanks for tagging me @ifried :)

I didn't know how to force an API error so I switched off the Wifi to get a generic error, is that the same?

The IP column currently has four pieces of information:

• IP
• Number of edits by this user using the IP
• Total number of users using this IP
• Total number of edits using this IP

In T239938#5748742, @ifried wrote:

However, if we receive feedback that users are confused, we can change the placement of the message at a later date.

In T237299#5728988, @Niharika wrote:

Yep, that would be great. :)

In T238961#5729041, @aezell wrote:

With that in mind, what if we swap the order?

@Mooeypoo, I like your suggestion of keeping the effect the same but showing it only on hover. This will still tell the user if something isn't interact-able, even if it is after they've hovered on it.

I think we should add the PRU setting right before the Email confirmation label. I had a few thoughts around this:

1. If we add it right after Email confirmation we'll have to update the message in the yellow box. While this is doable, it groups this setting incorrectly with others that actually do depend on confirmation.
2. Since we only need the presence of the email for this setting to work, it is better for it to be closer to the Email (optional) label. As removing an email will actually disable this setting, it makes sense for it to be right after it.

Feel free to re-open if we need more assets.

Feel free to re-open in case we need to reassess this.

In T238961#5722380, @Samwilson wrote:

What should this page be called? Help:Reset_password?

In T237299#5685324, @Niharika wrote:

@Prtksxna We also talked about the sticky highlights showing up in the filters at one point. Are you still planning to add that in?

I think Special:Block would be better with placeholder text too. Any field that can take two types of inputs is confusing, the one in Special:Investigate can take a combination of both which makes it even more so.

In T237034#5705040, @Tchanders wrote:

@Prtksxna I notice the requirements have been updated since the patch, hence the discrepancies in some of the placeholder text found by @dom_walden in T237034#5696564. Should we correct these?

In T236702#5709718, @MusikAnimal wrote:

The diff size fades in only if it has a summary to go with it. This can seem a tiny bit weird, because at quick glance some popups having content that fades in, and others don't. Maybe it makes sense to fade in .mw-diff-bytes in addition/separate to the full summary? That might look a little weird, and also dirty up the code.

In T234710#5710566, @ifried wrote:

Also, @Prtksxna, I originally wrote that we should remove "API Error" in the acceptance criteria. However, I just updated it so that we keep the word "Error." I think it's good to be explicit about the fact that there's an error, so users understand why we're asking them to refresh the page or try again later. The only part that was confusing to some users, in my view, was the word "API."

In T238961#5700503, @Prtksxna wrote:

I think the system already has an error message that shows up, but I am not able to see it. Will update this ticket once I figure it out.

@Mooeypoo good idea. Here is what it looks like on the Create account page:

Without JS	With JS

In T234537#5700964, @Samwilson wrote:

But this isn't true for requireemail; password reset emails are sent even for unconfirmed email addresses.

In T238961#5698703, @ifried wrote:

@Prtksxna What do you recommend as the message we display for exceptions #1 and #2?

Thanks a ton for this @nettrom_WMF!

If we are getting the bytes changed from the same API call we can't completely de-couple it. From what I understand, if the API returns no edit summary then our tool doesn't show the bytes changed either, though I suppose we do have that information (could someone confirm this?).

I am not against hiding the form elements that aren't being used, but, as Volker pointed out, if we do do this we should make sure that the ARIA mappings are correct and we're using aria-expanded and aria-controls correctly. We'll also need to test with screen readers to make sure its working properly. You can read more at — https://www.accessibility-developer-guide.com/examples/sensible-aria-usage/expanded/

From the description:

@Prtksxna should we give an error indicator perhaps?

@Aklapper, my understanding is that the legal team doesn't have the resources to do #2 at the moment, and not having #1 is already causing some confusions (people emailing asking where the latest report is etc.)

@dbarratt you're right we should try to reduce the cognitive load on the user on this page, especially with the all the tables and highlights that they're about to see. I was thinking of a few ways to do this:

1. Remove the placeholder text from the Reason input. Most people who come to this page know what they're doing and wouldn't need help filling this out. (per your comment T237034#5672684)
2. Improve the text of the checkbox label so that we don't need the placeholder text any more. (I'll also explore the options that @Niharika pointed out in T237034#5672832)

After a discussion with @LMixter, @JbuattiWMF and @Varnent we'd like to propose:

1. transparency.wikimedia.org (and all sub-paths) should redirect to wikimediafoundation.org/about/transparency/. This might result in some broken links but that is fine (technically not broken, just not as expected, everything should just redirect the the new page).
2. Create a new sub-domain transparency-archive.wikimedia.org that will serve the old website. This will be a temporary measure till legal (with the help of devs) figures out a way to move all the historical data onto the new website. AFAIK the internal links on the old website should continue to work fine.

@Tchanders, the default error state looks good, per your suggestion, let's keep it as is.

In T237034#5661181, @Tchanders wrote:

Should the placeholder be the default "Add more..." instead? Might make more sense since this is not just for adding users.

From the description:

@Prtksxna What happens when the user gets rid of all the rows in the table with the filters?

Is this something that we get from a separate API call or do we have it as soon as the popup loads?

The WWT bar should be on top of all the content (including the Good Article badge). I think currently the user would be able to click on whatever is on top, since the badge doesn't completely hide the close button, and since it can be scrolled away, it doesn't affect functionality in any way.

When the WWT has failed to load it cant show the WWT popups. The reason we disable the links when WWT is active is because clicking them should open the WWT popup, if that is not the case, we shouldn't be disabling the links.

In T234710#5616538, @ifried wrote:

Update: I noticed that Prateek did include recommendations to remove italicization from the guided tour pop-up in T234711

Yep, that was my hope too 😃. Anything that WWT does not work on, should have this effect — citations, images, tables, templates etc.

From the description:

If there's not enough real estate in the UI, we should at least make the "Who Wrote That?" header link to the documentation on Meta, and prominently display that the tool is powered by Wikiwho there

In T235196#5564200, @Mooeypoo wrote:

We've discussed offline but just for posterity here -- the biggest issue we have is that these percentages are calculated based on tokens and on wikitext. Essentially, the second author may have edited things like citations and thumbnails and templates that we do not "see" visually in the visual WWT tool, but make his edits correctly account for 2.1% of the page.

I think we can keep the placeholder as is, it is still helpful.

I've updated the codepen to add the usernames in the parenthesis — https://codepen.io/prtksxna/pen/aboXYbR. @HMonroy, would this resolve the issue we discussed during RTL?

In T233895#5545815, @Samwilson wrote:

No, I was right before: the promo doesn't go in manifest.json (or in the repo), it's a manual upload to the extension's profile at https://chrome.google.com/webstore/developer/dashboard

@HMonroy yeah moving it out of the label makes sense, in fact the label should be for the dropdown. I've updated the codepen to reflect this now. Thanks! 😊

Hey @ifried, this is what I had in mind for the Basic Information section. What do you think?

Thanks @Samwilson! Should we also add https://developer.chrome.com/webstore/images#promo?

In T231508#5542462, @Mooeypoo wrote:

[edit] There's also mw.hook( 've.deactivationComplete' ) for deactivation of VE (thanks @Esanders ) that can be used to reactivate the activation link.

I agree with the degrees of priority that @ifried shared 👍🏽. I do think that just a link on ChangeEmail might not be a good idea. This is because, when clicked by a user who didn't have an email address, they'll be taken back to Special:Preferences where this setting would still be disabled.

In T231583#5544208, @ifried wrote:

Thanks, @Prtksxna! Can you provide an explanation of the sub-text? When/how do you propose that it is displayed? I have also started writing a basic ticket here: T234537

In T231612#5541608, @ifried wrote:

@Mooeypoo In conversation with @Prtksxna, we have talked about the fact that (if possible) we would like WWT to be accessed from the tabs on top navigation as an icon (similar to Watchlist access via star), and the WWT icon would probably be next to the star. Would this be possible?

Based on the usability tests and feedback from the design team we've decided to keep this setting as the first checkbox in the Email Options section. We might add some text in the Basic Information section but from what I understand we'll have to check if that is possible.

Yep, based on our discussions:

In T233971#5541354, @ifried wrote:

However, it may be possible if the display is not dynamic (but only changes on refresh/new submission of info).

In T233044#5499553, @ifried wrote:

Perhaps we could also add in another sentence like, "You can also choose to turn on the Password Reset Update, which requires both a username and email address in order to generate emails such of these. It adds an extra layer of privacy for users, and it can often prevent emails such as these being generated by people other than you" (or something along those lines). What do you think?

When a user who doesn't have an email address sets one, or when someone wants to change their email address, they're taken to Special:ChangeEmail. On the Special:ChangeEmail page we'll add a section for Account recovery that explains how we use the email address for password recovery and introduce the PRU setting. The setting will be unchecked by default, unless it was previously checked by the user (for those who are changing their email address).

In T232776#5523768, @ifried wrote:

You proposed that we make the templates 30% opacity in general state and 80% in hover. From my understanding, this is so that users can still access/read the content. However, they will be informed (through visual cue) that is WWT is not actually enabled for the template if they try to apply any WWT functionality (such as hover or click). When these actions are performed, the template will become more opaque. Is this a fair analysis?

Looks good 👍🏽

@MaxSem, yeah, password reset preference doesn't really explain much, and we don't call it that on the settings page either.

This is what I had in mind for the icon and promo image:

In T232776#5519945, @ifried wrote:

Update: Here's some information that I have gathered on template display in VE. From Erica Litrenta: " I think that VE now can edit pretty much anything, so I don't seem able to provide you a live example.

Thanks for all the clarifications, @MusikAnimal!

I am thinking we should clearly mark the parts of the page on which WhoWroteThat won't work (Templates, Images, Tables?). A way to do that would be to reduce their opacity which would make them look disabled. We can choose to have no mouse events on them so that people don't accidentally click on them and navigate away when they actually expected to see the popup.