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 (as does everyone else):

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 😊

Disable clicking anywhere on the page while content loads from the WhoColor API

In T228610#5352276, @Samwilson wrote:

It looks like maybe the wiki container isn't set up properly. Can you view the wiki at http://localhost:8043/, edit pages and upload files?

I agree the link icon would be misleading, and so would linkExternal. @Esanders, is it going to link to the template’s documentation? If so, then yeah, the helpNotice makes sense here.

Good idea @Mooeypoo! I've updated the screenshots above.

In T228610#5352234, @Samwilson wrote:

You do have a local wiki! :-) It's the 3rd docker image; try http://localhost:8043/

Thanks @Samwilson, that worked. Also, is there a workaround for the WIKI_URL if I don't have a local wiki?

This seems almost fixed now. The starting of the leaflet box and the input are off just by a pixel.

I see now, thanks @TheDJ! The ratio of the screenshot threw me off and I assumed it was a mobile.

In T213451#5339352, @dbarratt wrote:

In T213451#5336212, @Prtksxna wrote:

Wow, strototime is quite versatile. Could we add a placeholder text there with a few examples — 1 week or 10 August 2019

We sure can. But I would rather get rid of it. Since strototime() is English-only, the placeholder text would also have to be English-only.. See: T190449

I took @Samwilson's help to understand this navigation a bit better. I now understand that the icon currently represents two states:

Blue bar to show up under the top tabs and should be sticky.

The maximum character limit for edit summaries is 500 characters, I think we'd be able to fit that. I am also considering making the popup wider if we do that.

We can choose whether or not to show the extra user information. With the visual representation of highlighting everything that the user has written I don't think its necessary.

In T213451#5317674, @dbarratt wrote:

I think this is because it's only available to privileged users (i.e. not every admin that can see this page will get this option). Similar to the way pages are listed in bold if they are for privileged users on Special:SpecialPages.
See T219931 & T213981

@Niharika @dbarratt I had a couple of questions about the page:

Something like this?

In T227199#5309479, @dbarratt wrote:

I think a better solution might be to rename "Editing their own talk page" to "Their own talk page" and move it under "Editing". That way it is clear that it needs to be enabled.

https://github.com/wikimedia/svgtranslate/pull/125

I am hoping that we can use the same blue bar to show different states of the tool. Ottawahitech had suggested that we don't cover the View History and Edit tabs, and I think that makes sense. We should however make it sticky so that its visible even when the user has scrolled down.

Thanks @Mooeypoo! Quick question, is it possible to have markup inside OOUI popups like headings and stuff, as is the case with GuidedTours?

In T226774#5302410, @Mooeypoo wrote:

If not, I recommend the most simple popup possible, to reduce effort here.

@Mooeypoo I wanted to confirm that this wont be the actual GuidedTour since the code is outside of MediaWiki. Will we be able to style it however we like?

No, it is resolved now. Sorry, I forgot to close it.

Thank you!

@Niharika Do we want to support mobile screen sizes for the translation page too?

Lets add a label on top of the dropdowns ( "from:" and "to:")

How about we scroll the page down (enough to hide the header) as soon as an input gets focus?

Could we please get tracking snippet that we can include in the page, thanks!