Here are the latest design proposals for the impact module improvements based on community and design user testing feedback. The leftmost image shows the design that was used in user testing. The other images show three possible levels of design improvements I propose we could make...

The suggested changes (with reasoning) are:

A.

• Remove ‘Quality’ metric and replace with ‘Thanks’ metric.
  • We decided that the ‘Quality’ metric should be removed as we can currently only measure this by reverted edits which we decided was not a robust measure of the quality of someone’s edits
• Run text in stats counter onto new lines – do not truncate.
  • User testing showed that cutting off text caused some confusion.
• Remove colour coding from activity stats
  • I propose to remove the colour from the activity stats as I don’t think the colour meaning is obvious and it adds additional complexity to an already busy page
• Make bar chart colour fills #3366CC to be more consistent with other data vis.
  • Other data vis on the page uses the accent blue colour to highlight data. I propose doing this for the bar chart too for consistency and better readability.
• Change ‘Top 5 most viewed articles’ to ‘Most viewed articles you’ve edited’
  • User testing showed some confusion over what these articles were – some participants didn’t realise it was articles they had edited. This may not be an issue with real users and real content as people should be familiar with articles they have edited but this simple change of wording should make it clearer.
• Remove links from article list
  • User testing showed that some people were confused by the links in the article list and why they only appeared on some items and not others. I suggest removing these to remove this confusion and simplify the amount of information on the page.

B.

• ‘Your recent activity’ heading becomes a drop down allowing users to configure the timescale of data shown.
  • Options include 30 days (default), 60 days, and last year. This is being explored in more detail on T220143.

C.

• Consider removing the ‘last edited’ and ‘best streak’ stats.
  • Some feedback from user testing highlighted that the page was very busy and could be overwhelming. If we wanted to simplify the page further then I would suggest that these stats could be removed as they are possibly the least valuable on the page. We could consider re-introducing these to the page for newcomers who reach a specified level of high activity, as this would indicate they are more engaged and may find the additional statistics more valuable

Removing the "Add references" etc links simplifies things as we don't have a straightforward way of identifying task types. Otherwise I think the changes are neutral from an engineering POV (apart from T220143: Impact Module: Provide an option to show pageviews earlier than the 60-day limit from the PageViewInfo extension which has its own task).

The "Suggested edits" label in the top box is likely to span to three or four lines for other languages. Maybe that top part should be two rows?

‘Most viewed articles you’ve edited’

Should this label also include the time period? E.g. we want to show the user the most viewed articles that they edited in the last 30 days, or in last 60 days? Or is it most viewed articles ever? What if the user sets the time limit 30 days, does some edits, goes away for several weeks and comes back. Would they see an empty list?

Along the same lines, is there an "empty state" we can refer to for each of these components?

In T313271#8187935, @kostajh wrote:

The "Suggested edits" label in the top box is likely to span to three or four lines for other languages. Maybe that top part should be two rows?

I agree that three items on small viewports is a bit tight. I think there are two possible solutions to this:

1. Simplify to ‘Total edits’ and ‘Thanks’ (as per @KStoller-WMF’s suggestion), or
2. Display ‘Suggested edits’ until the user has completed the target amount (or until a specified time) and then replace ‘Suggested edits’ with total edits. This would answer @KStoller-WMF’s point about what we do when someone exceeds the 50 suggested edits

In T313271#8187935, @kostajh wrote:

Should this label also include the time period? E.g. we want to show the user the most viewed articles that they edited in the last 30 days, or in last 60 days? Or is it most viewed articles ever? What if the user sets the time limit 30 days, does some edits, goes away for several weeks and comes back. Would they see an empty list?

Along the same lines, is there an "empty state" we can refer to for each of these components?

On reflection I actually think this requires a bit more design work. Currently we have two select components on the page:

1. the recent activity timeframe selector, which changes all the data on the page, and
2. the articles list selector which only changes the article list

This is a bit confusing as both are styled in the same way but one affects the whole page and the other only affects a part of the page. I’ll do a bit more exploration on this and update soon.

In T313271#8187935, @kostajh wrote:

Along the same lines, is there an "empty state" we can refer to for each of these components?

So if I understand correctly, if a user had made no edits then they would simply see the current empty state (left screen on the image below). If a user had made at least one edit (with no views) then they would see the screen on the right, where I would suggest we do not display anything for which there is no data (apart from ‘Thanks’ in the activity scorecard. Do let me know if I’ve missed any other scenarios.

In T313271#8197906, @KieranMcCann wrote:

In T313271#8187935, @kostajh wrote:

Along the same lines, is there an "empty state" we can refer to for each of these components?

So if I understand correctly, if a user had made no edits then they would simply see the current empty state (left screen on the image below). If a user had made at least one edit (with no views) then they would see the screen on the right, where I would suggest we do not display anything for which there is no data (apart from ‘Thanks’ in the activity scorecard. Do let me know if I’ve missed any other scenarios.

Ah, right, that makes sense.

Do we want a "loading" state for pageview data, since it might be too slow to fetch on the PHP side?

In T313271#8201134, @Tgr wrote:

Do we want a "loading" state for pageview data, since it might be too slow to fetch on the PHP side?

Yes, I think it makes sense to add a loading state. Is there a standard skeleton state or standard that is known, or will we need a mockup of this from @KieranMcCann ?

I don't think there is an obvious standard look to use. The two affected things would be the pageview timeline and the top5 area (including the article list itself, I think we'd have to fetch pageview data for each of the user's edited articles one by one to find the top, although this depends on which options we want to support for T220139: New Impact Module: Filter/Sort options to customize the top edited articles of the impact module).

In T313271#8204003, @Tgr wrote:

I don't think there is an obvious standard look to use. The two affected things would be the pageview timeline and the top5 area (including the article list itself, I think we'd have to fetch pageview data for each of the user's edited articles one by one to find the top, although this depends on which options we want to support for T220139: New Impact Module: Filter/Sort options to customize the top edited articles of the impact module).

I had been thinking that the maintenance script would be responsible for fetching page view data and caching/storing that, so that on the server-side render it would be relatively inexpensive to know what the top 5 articles are for a particular chunk of time.

Right, but what happens if the data is not there for some reason (e.g. relatively recent registration)? We'd either need to recalculate on the fly and show a placeholder, or show some kind of error page.

Hi @Tgr @kostajh. In terms of loading state I think there are a couple of options:

• Load an image of the empty state charts before the data loads in. To do this nicely though I think we would want to animate in the chart data once it loads which I’m guessing would make it much more complex. For the article list we could show stylised blocks to indicate content is loading i.e. something like this...

or

• Use an existing loading pattern. To my knowledge there are two. The Progress Bar which exists in OOUI, or the bouncing dots (cx-spinner) pattern which is not in the design system but has been used in Content Translation and I belive Growth have used it in the past. There is some discussion about it here. My preference between these two would be the bouncing dots.

One issue about the recent changes I’ve made to the impact module that has been bothering me is that since we have introduced the option to select a timeframe (30 days, 60 days, last year) at the top of the page, it has introduced a bit of confusion as we also have a drop down menu/filter further down in the article list. This raises two questions for me:

• If you change the timeframe in the top menu does this also impact the article list? My assumption would be yes but I don’t think this is clear as both drop downs are styled the same so there is no clear hierarchy between them.
• Is there much value in being able to change the article list by most edited / least edited / latest edited, or is this adding unnecessary complexity. If this is about your impact then seeing the most viewed is arguably this most important metric?

I’ve created a graphic which shows Rita’s last iteration beside my latest iteration, and then two additional options for how this could be refined.

Option A changes the timeframe drop down menu style to make it feel more like it will affect the whole page
Option B is the same as A but removes the drop down from the article list and simply shows the articles with most views

Any thoughts, or preferences between A and B?

cc @KStoller-WMF

I lean towards option B in order to reduce scope/complexity, although I'd also go further and support removing the timeframe selection option for this iteration. If we could split those features out into follow-up tasks, we would be able to release something sooner.

I tend to agree on removing the filtering from the article list and simply showing this list based on ‘most viewed’. I presented this to the design team yesterday and feedback was along the same lines – start simpler and identify cases where more options are needed later.

Also very happy to split these features out to help us release sooner.

From a backend complexity POV, "most viewed" is the comlicated one, all the others are fairly simple.

From a user POV, I don't feel "most edited" and "least edited" particularly useful. (The latter would also be fairly random, people typically have a long-tail pattern with many single-edit articles and we'd have to pick five from those.) Most viewed shows me my biggest impact; most recent shows me the impact of the work I'm doing right now. I don't feel most/lease edited really communicates anything about my impact. (Maybe most edited could mean something like "the articles most important to me", but that's a very imperfect correlation, especially for a new user.)

Just to confirm the latest Impact Module design incorporating user and community feedback have been updated and can be found in Figma. This link will take you to the latest desktop and mobile example mockups. More detailed breakdowns of each element can be found on that same Figma page.

Image of mockups for reference:

The only detail that we still need to confirm is how many/and which items we want to display on the activity scorecard. This decision might need to be discussed with the ambassadors? I’ve included designs for 2, 3 and 4 items.

cc. @KStoller-WMF @kostajh @Tgr