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.

So if I understand correctly, the users who haven't confirmed their email addresses see the following message:

Thanks @ifried and @MusikAnimal 🤩

I am not familiar with some of the standards around the current NPP design, so, I had two queries:

1. What is the difference between the red text that shows up after the title like "No Citations", "Orphan" etc. and Potential issues like 'Copyvio'? I don't understand the conceptual difference between the two.
2. I see a few different icons before the title: , , . Should this change if the username is in the article?

Ah, that makes sense. I think lets keep it as is for now and figure out what needs to be done once we have results back from the usability tests.

The text wrapping looks good, I think we can go ahead with it. Thanks for posting the screenshot 👍🏽

In T231583#5494687, @Samwilson wrote:

Note that the existing messages include a help paragraph underneath (or in a popup/hover, in some skins I think)

In T231485#5480229, @ifried wrote:

1. I'm glad we agree regarding ambiguous instructions. I've written up a ticket (T232512) that includes this instructional language. Also, do you think it would be possible to update the mockup with the new language? If so, I could add the new mockup to the ticket.

In T231595#5482078, @Samwilson wrote:

How about links to edit sections (the ones next to section titles)? They still work at the moment.

In T231485#5477312, @ifried wrote:

• What do you think about including a more vague message at the top (which gives less information to harassers). For example, at the top of Special:PasswordReset, we can display a message like, "Both username and email address are required." That way, the harassers don't know (or are less likely to know) that a particular user is actively trying to curb harassment. Meanwhile, good faith actors will still get the information they need.

In T231115#5476249, @aezell wrote:

I would agree with Leon here. Simplicity seems a smart tactic. Personally, I'd always show the loading indicator even if it disappears as soon as it's there. In my opinion, that's bomb-proof for those requests that might take a long time and much simpler than trying to guess how long something is going to take.

In T231116#5444276, @ifried wrote:

Regarding the chrome idea: I'm inclined to think that we shouldn't dim the rest of the chrome. Users may prefer to fully access all links and content on the page, without having to first disable Who Wrote That. What do you think? We can discuss it tomorrow in our meeting.

@cscott would you be able cut a new release? Happy to do it myself if you can add me on NPM.

1. Form states

The way to enable/disable this preference would be a checkbox in Special:Preferences. It'll only show up if the user has confirmed their email. I can think of two places where this setting could be:

Given that the edit summary could in some cases could load very fast (less than 100ms) we don't want a case where we flash the animation for a very small amount of time. I am taking some inspiration from the font-display browser behavior here.

In T231508#5470148, @ifried wrote:

Despite the jump in the sidebar, do you still feel that option #1 is preferable? Thanks!

@Samwilson, I think it would also be alright to increase the width of the pop-up enough to fit IPv6 addresses. There are currently two popups sizes in the Zeplin—250px and 320px. Which one is being used screenshot above?

The WhoColor tool currently uses the tabs on top-right, and is represented as a text item (in the same hierarchy as Read and Edit). As you mentioned, we have a few options on where to put this tool:

1. Top-left tabs (Article | Talk | Who Wrote That)
2. Top-right text tabs (Read | Edit | View History | Who Wrote That)
3. Top-right icon tabs (Star icon | WWT icon)
4. Tools sidebar
5. User menu on the top right (I don't really think this is an option, but still noting it here)

In T194439#5455236, @Niharika wrote:

@Prtksxna
Which initial design changes are you referring to? I seem to be missing something.

Here is the example I had in mind — https://en.wikipedia.org/wiki/User:Prtksxna/citation-test.:

Should we regenerate the OOjs documentation to test before closing this task?

In T187992#5014862, @Aklapper wrote:

@Prtksxna: Is there a task for this / any references for that statement?

From the description:

When VisualEditor is toggled on, do not allow WWT to be opened (checking on how to best represent that with product)

@ifried, I agree. Always having a full stop . would also be better when there is no edit summary to show.

If the edit summary is the only thing that we'll be waiting to load we could use a content placeholder with an animation, and then switch it out with the summary once we have it - https://codepen.io/prtksxna/pen/OJLmVXZ (data will load after 3 seconds)

In T230567#5439829, @ifried wrote:

@Prtksxna We would do the average or median in the past 30 days. If the article was created less than 30 days ago, we would calculate the average/median based on the number of days since the article creation. In terms of placement, I also think that it could come next to "Categories" (perhaps right afterward) in the following manner: "X page views per day (average)" or "X page views per day (median)," depending on what we choose. What do you think?

In T230436#5437015, @MaxSem wrote:

Investigate the work required to have a default opt-in for new users with an associated email address (while old users remain default opt-out as default)

This is gonna be ugly no matter how we decide to implement this because MW currently assumes that all users have the same default settings:

• If we want to change this setting based on account creation date, we would need to wrestle with this assumption and bugs it might potentially cause. Also, we'll need to plug in global account creation date into this because using local dates would result in different wikis behaving differently, which is not good.
• If we hook into account creation and set a global option for all new accounts, we would create a lot garbage rows in the database for users who would never use their accounts (we've had 4M new global accounts in 2018).

In T230436#5439203, @MaxSem wrote:

Is this correct?

Yes.

Yeah, so the current loading state doesn't have the close icon. If we suspect that the tool can be in this mode longer than a few seconds we should definitely add a close button here as well.

So, will we need both partial and full loading states? What all would have already loaded in the partial state?

Ooh, thanks for this @MaxSem 🤩So the proportion of no(~¼), unconfirmed(~½), and confirmed(~¼) emails looks something like this:

Will the average (or median) be calculated since the page was created? Or will it be the average of that week or something?

In T226760#5426900, @Samwilson wrote:

What colour should the 'contact us' link be? It's blue at the moment…

I can see how in its current form the target can be confusing. I see two main reasons for this:

1. The hover state only changes the background color and the change isn't drastic so is easily missable.
2. Since the button for the diff (the area we clicked to open the diff) and the revision target are touching each other its not clear if they're connected or separated. I clicked on it a bunch of times accidentally thinking that it'd close the diff.

In T207485#5419052, @ifried wrote:

4. "pagetriage-enqueue-confirmation": "Add this page to new pages feed?"
   • Potentially change to: “Add this page to the New Pages Feed?”

@ifried, does this still need any design work?

@MusikAnimal, I didn't know about preload parameters, yeah that is exactly the kind of thing I was hoping for.

Based on T229714: Spike: Investigate Possible Errors for WWT [4 hours]:

Thanks for all this information, @MusikAnimal 🤩

I don't really need this any more, so no need to help me debug 😊
Happy to provide more info if you'd like though.

Yup, the .env file is correct, and I am not trying to log in. When I try to navigate to - http://localhost:8042/File:Speech_bubbles.svg I get an error. Here is the stack trace:

This should get deployed automatically in a while. Thanks for spotting and closing the issue, @Ammarpad 😊