Hi! Is it possible to make the last small updates? 


1. The copy for the inline message for the survey ->
“This is an early version of this page. Share your feedback to inform future improvements via this survey.”



Design updates: 


1. moved bytes in front of the edit summary text. 

2. got rid of side borders for the cards. 

3. I added a hover state on Friday for the cards in the acceptance criteria.

In T402780#11378620, @OTichonova wrote:

Hi! Is it possible to make the last small updates? 


1. The copy for the inline message for the survey ->
“This is an early version of this page. Share your feedback to inform future improvements via this survey.”



@OTichonova
Yep, totally possible. Do we have a link to the survey yet?

Design updates: 


1. moved bytes in front of the edit summary text. 

2. got rid of side borders for the cards. 

3. I added a hover state on Friday for the cards in the acceptance criteria.

Thanks, I'll make the changes.

Survey link can wait for T405757: Display a link to the dashboard survey in Special:Dashboard, it's not part of this module :)

@Kgraessle another small change recommended coming out of planning today: let's fall back to not filtering on rcscores if they aren't available. That way we can easily demo in patchdemo once we're added. I suggest just doing a check to see if the filter has been registered by ores. If it's not too much of a hassle, I'll add it as a criteria here; otherwise I can add it as a new followup.

In T402780#11379811, @jsn.sherman wrote:

@Kgraessle another small change recommended coming out of planning today: let's fall back to not filtering on rcscores if they aren't available. That way we can easily demo in patchdemo once we're added. I suggest just doing a check to see if the filter has been registered by ores. If it's not too much of a hassle, I'll add it as a criteria here; otherwise I can add it as a new followup.

@jsn.sherman
Sounds good! Right now we're just returning an empty list if wgOresUiEnabled is false, but we can easily return the results instead- that shouldn't be a problem to add to this ticket.

@OTichonova

A few follow up design questions for you:

1. The cards in codex don't have the option to remove the side borders by default so this would be introducing some custom styling- are we ok with that?
2. The hover color interactive-hover-subtle #EAECF0 doesn't look great in dark mode, is there a color for dark mode you'd like to use?

Dark mode:

1. The cards in codex don't have the option to remove the side borders by default so this would be introducing some custom styling- are we ok with that?

Thanks for sharing this. I think for the MVP we don't need to introduce custom styling.

2. The hover color interactive-hover-subtle #EAECF0 doesn't look great in dark mode, is there a color for dark mode you'd like to use?

Sorry, I think I mistyped the color. It is interactive-subtle-hover, in Figma it turns from #EAECF0 --> #27292D

light	dark

@Samwalton9-WMF

Hi,
It looks like right now this check user info card is being added via the UserLinkRendererUserLinkPostRenderHandler which will not won't work for our use case as we're adding the links client side and don't have access to data that is required to fire this hook from the client side.

It has been suggested that we create a clientside implementation in the Extension:CheckUser that can then be reused by other extensions (including Extension:PersonalDashboard), but before creating and marking those tickets as a dependency of T402632: WE1.3: New moderator homepage I wanted to check in with you around how crucial having the check user info cards are for MVP? Do we want this to be a dependency on our MVP?

Thanks for uncovering this snag! I think this can be a post-MVP project.

@Samwalton9-WMF @jsn.sherman

I have uncovered another snag while implementing the FlaggedRevs "review" filter using the RecentChanges API. I naively assumed in my spike that this was another filter like unpatrolled .
However, the logic for the filters is being added server side in the Flagged Revs extension. There's currently no API that exposes this data for us on the client side and we'd have to introduce it.

There is an API that FlaggedRevs exposes that lists unreviewed pages with revision ids, but as far as I know there's no way to filter RC changes by revision id in the API.

We could implement something similar to what ORES does to return oresscores, but this would require making changes to FlaggedRevs extension.

In T402780#11390433, @Kgraessle wrote:

@Samwalton9-WMF @jsn.sherman

I have uncovered another snag while implementing the FlaggedRevs "review" filter using the RecentChanges API. I naively assumed in my spike that this was another filter like unpatrolled .
However, the logic for the filters is being added server side in the Flagged Revs extension. There's currently no API that exposes this data for us on the client side and we'd have to introduce it.

There is an API that FlaggedRevs exposes that lists unreviewed pages with revision ids, but as far as I know there's no way to filter RC changes by revision id in the API.

We could implement something similar to what ORES does to return oresscores, but this would require making changes to FlaggedRevs extension.

A short term solution would be to grab the revs from the unreviewed pages and filter out old + low risk edits client side; eg:
https://tr.wikipedia.org/wiki/%C3%96zel:ApiSandbox#action=query&format=json&prop=revisions&generator=unreviewedpages&formatversion=2&rvprop=ids%7Ctimestamp%7Coresscores&rvdir=older&gurlimit=max

Actually, I suppose there are some product questions there: should new reviewers be looking at these edits at all? Are they likely to have the user rights to do anything with such edits? On these wikis, the most recent visible revision will have already been approved, so I'm not sure if this exact workflow makes sense.

I don't think we should be trying to extend flagged revs since it's an unsupported mess. I would recommend that we exclude wikis running flagged revs over complicating the mvp to support it.

+1 on excluding wikis that are running flagged revs over complicating the MVP to support it. I'm guessing that this would reduce the number of wikis we'd want to deploy the revert risk model to as well.

Would be good to know how many on the list are affected.

@DMburugu

Here's a list of FlaggedRevs enabled wikis.
After going through it, it looks like the following wikis on our list have FlaggedRevs enabled:

• alswiki
• cewiki
• ckbwiki
• dewiki
• eowiki
• hiwiki
• iawiki
• kawiki
• sqwiki
• vecwiki
• zh_classicalwiki

kgraessle opened https://gitlab.wikimedia.org/repos/modtools/vitest-plugin/-/merge_requests/1

Add a mock for mw.util.isTemporaryUser

dhardy merged https://gitlab.wikimedia.org/repos/modtools/vitest-plugin/-/merge_requests/1

Add a mock for mw.util.isTemporaryUser

Patch Demo here

In T402780#11390719, @jsn.sherman wrote:

Actually, I suppose there are some product questions there: should new reviewers be looking at these edits at all? Are they likely to have the user rights to do anything with such edits? On these wikis, the most recent visible revision will have already been approved, so I'm not sure if this exact workflow makes sense.

Although newer editors wouldn't be able to positively-review these edits, they can still revert them. I'm not sure I follow why the most recent visible revision matters; a non-visible revision is still shown in the edit history and can be interacted with, it just doesn't have an impact on how the article content is displayed.

In T402780#11392062, @DMburugu wrote:

+1 on excluding wikis that are running flagged revs over complicating the MVP to support it. I'm guessing that this would reduce the number of wikis we'd want to deploy the revert risk model to as well.

Would be good to know how many on the list are affected.

Does this need to impact revert risk model deployments? The Recent Changes filter is still helpful for those wikis, and deploying Revert Risk doesn't force us to deploy PersonalDashboard.

If the two don't need to be coupled then we can go ahead and deploy revert risk to those wikis as well.

In T402780#11400165, @Samwalton9-WMF wrote:

In T402780#11392062, @DMburugu wrote:

+1 on excluding wikis that are running flagged revs over complicating the MVP to support it. I'm guessing that this would reduce the number of wikis we'd want to deploy the revert risk model to as well.

Would be good to know how many on the list are affected.

Does this need to impact revert risk model deployments? The Recent Changes filter is still helpful for those wikis, and deploying Revert Risk doesn't force us to deploy PersonalDashboard.

The ores filters can still be deployed. There's not really a wiki-wide technical problem here, just a ball of yarn to untangle with this dashboard module.

Change #1204983 merged by jenkins-bot:

[mediawiki/extensions/PersonalDashboard@master] Moderator homepage module: Recent activity

https://gerrit.wikimedia.org/r/1204983

Hi! Sorry, I updated the byte red and green colors, I just noticed that there are these for added/removed content - name: 'content added' #006400 & name 'content removed' #8B0000

@OTichonova

Hi, I can update the byte size red and green colors, I just had one comment about the colors in dark mode:

Current:

Proposed:

With the new colors, you lose a bit of contrast in dark mode; it occurs with the green as well:

Current:

Proposed:

Hi @Kgraessle, thanks for sharing!
In Figma (and recent changes page) the content added/removed colors are lighter in dark mode.
What I see them become below:

Light mode	Light mode
#8B0000	#006400
Dark mode	Dark mode
#FD7865	#80CDB3

Change #1214063 had a related patch set uploaded (by Kgraessle; author: Kgraessle):

[mediawiki/extensions/PersonalDashboard@master] Moderator homepage module: Recent activity

https://gerrit.wikimedia.org/r/1214063

Change #1214073 had a related patch set uploaded (by Kgraessle; author: Kgraessle):

[mediawiki/extensions/PersonalDashboard@master] Moderator homepage module: Recent activity

https://gerrit.wikimedia.org/r/1214073

@jsn.sherman @Dillon

There are two small patches ready for review:

1. Fix the change number byte size colors for light and dark mode. This also has the updated translations that have issues pointed out in T404444: Add the PersonalDashboard extension to translatewiki.net. This is the more urgent one to review.
2. Added unit tests for the ChangeNumber component and fixed a bug.

Change #1214063 merged by jenkins-bot:

[mediawiki/extensions/PersonalDashboard@master] Moderator homepage module: Recent activity

https://gerrit.wikimedia.org/r/1214063

Change #1214073 merged by jenkins-bot:

[mediawiki/extensions/PersonalDashboard@master] Moderator homepage module: Recent activity

https://gerrit.wikimedia.org/r/1214073

Change #1214541 had a related patch set uploaded (by Kgraessle; author: Kgraessle):

[mediawiki/extensions/PersonalDashboard@master] Moderator homepage module: Recent activity

https://gerrit.wikimedia.org/r/1214541

@jsn.sherman
@Dillon

One more patch with a translation that was missed if you could review whenever you get a chance.

Change #1215713 had a related patch set uploaded (by Kgraessle; author: Kgraessle):

[mediawiki/extensions/PersonalDashboard@master] WIP:

https://gerrit.wikimedia.org/r/1215713

Change #1214541 merged by jenkins-bot:

[mediawiki/extensions/PersonalDashboard@master] Moderator homepage module: Recent activity

https://gerrit.wikimedia.org/r/1214541

One more code review on this ticket which pulls out the useFetchActivity composable to a new common module.

Change #1215713 merged by jenkins-bot:

[mediawiki/extensions/PersonalDashboard@master] Moderator homepage module: Recent activity

https://gerrit.wikimedia.org/r/1215713

@OTichonova

Latest patch demo here for design review.
Note that the double border issue on the card list

Hi @Kgraessle, thank you!

I got some small tweaks listed below:

Desktop

1. Info icon in top right of module color in subtle #54595D
2. View more edits in... text at the bottom of the module also in color in subtle #54595D
3. Bytes number not in italics (sorry I realized in Figma that when I was adding the ‘no edit summary text’ I accidentally made the numbers in italics too
4. Padding at top and bottom of module should be 16pts (right now it is 20ish)
5. Space between temp. account/username and edit summary - should be larger (in Figma it is 4pts with the text line height. When you look at it not considering the text lin heights its about 7 pts). This is also the same between the article title and the bytes.
6. There was some back and forth with the card padding. Can the text stretch out to the edges of the borders?

Design	Patchdemo

Design and Patchdemo

Mobile

1. In the initial card the space between the title and text seems large it should be 16pts. The button text feels lager than in the designs.
2. There is the title again below the header that shouldn’t be there.
3. Sorry my bad, I forgot about the info icon, but it should be in the header (right side) rather than beside the text.
4. Space between temp. account/username and edit summary - should be larger (in Figma it is 8pts. Space between the article title and description would be 4pts.
5. Same as on desktop (bytes - non italic, content extends width of border, color of info icon should be subtle)

Design	Patchdemo

Design	Patchdemo

@Dillon are you making the changes to fix the duplicated border, or should I just go ahead and fix that along with the design fixes @OTichonova found?

Change #1218823 had a related patch set uploaded (by Kgraessle; author: Kgraessle):

[mediawiki/extensions/PersonalDashboard@master] Moderator homepage module: Recent activity

https://gerrit.wikimedia.org/r/1218823

@OTichonova

Hi, I have the latest patch demo here. This includes fixes from this phab ticket along with T412053: bugfix mobile module card design so I will move both to design review.
I did fix two additional design bugs (the list card border color was incorrect on the Recent Activity module and there was no padding between the modules themselves).

Let me know if you have any other questions, thanks.

Hi @Kgraessle, great, thank you! I noticed a small thing with the spacing around the description text.

Desktop:
I noticed that the spacing between the title and the description is larger in the Patchdemo (around 35pts). In Figma, the spacing is 4pts (but that is in part because the space around the info icon is large -> 32pts). If looking purely at the gap between the title and description, it's around 16pts.

Design & Patchdemo

Mobile:
The padding above and below the text seems a little bigger than in the designs.

Design & Patchdemo

In T402780#11480830, @OTichonova wrote:

Hi @Kgraessle, great, thank you! I noticed a small thing with the spacing around the description text.

Desktop:
I noticed that the spacing between the title and the description is larger in the Patchdemo (around 35pts). In Figma, the spacing is 4pts (but that is in part because the space around the info icon is large -> 32pts). If looking purely at the gap between the title and description, it's around 16pts.

Design & Patchdemo

Mobile:
The padding above and below the text seems a little bigger than in the designs.

Design & Patchdemo

Done!

Change #1218823 merged by jenkins-bot:

[mediawiki/extensions/PersonalDashboard@master] Moderator homepage module: Recent activity

https://gerrit.wikimedia.org/r/1218823

The Info icon appears to have gone missing on desktop. It's still present on mobile.

Change #1223700 had a related patch set uploaded (by Kgraessle; author: Kgraessle):

[mediawiki/extensions/PersonalDashboard@master] Moderator homepage module: Recent activity

https://gerrit.wikimedia.org/r/1223700

Test wiki created on Patch demo by KGraessle-WMF using patch(es) linked to this task:
https://4097fa66e1.catalyst.wmcloud.org/w/

Change #1223700 merged by jenkins-bot:

[mediawiki/extensions/PersonalDashboard@master] Moderator homepage module: Recent activity

https://gerrit.wikimedia.org/r/1223700