@schoenbaechler - What should the date string be for following dates? should we keep it like the feed card? mmm dd,yyyy [ Apr 20, 2020]?

@Sharvaniharan Yeah let’s go with Apr 20, 2020 for now. I’m still refining this today and tomorrow – I will update the tasks with designs and descriptions then. Also it needs to go through design review so do not invest too much time yet in tweaking.

May I ask, what options do we have for the dates kicker? I’t be great to output something like: Today , Yesterday` and then the actual dates.

@Sharvaniharan FYI made some visual tweaks and added a menu to filter edits by type at the top (details see task’s description). Thx.

@schoenbaechler can you please give me an image for the gradient icon at the top of this screen :https://app.zeplin.io/project/57a120b91998d8977642a238/screen/5eb0309f4913f81a5fb9b31f

@schoenbaechler what is the size of the thumbnail image? here it looks ~60dp and here: https://app.zeplin.io/project/57a120b91998d8977642a238/screen/5eb040b03307521d51ff79ab looks ~40

@Sharvaniharan the zeplin one is the one that counts! thx... :)

hi @schoenbaechler some questions that came up when @Dbrant reviewed my PR.

1. When we query the user contributions, we get one response per tag added. i.e., if you have added 2 tags, there will be 2 entries in the list. I have grouped them into one , and when they click on that contribution, to details screen, there at the top it shows "You have added %numberOfTags tags".

Please let us know which way to proceed on this.

2. Can we use the standard progress bar that appears below the toolbar instead of at the bottom of the screen [like explore feed] while lazy loading is in progress?

Thx @Sharvaniharan for checking on this and @Dbrant for consulting.

@Dbrant is proposing a code change, to not manipulate the list and have as many entries in the list, as the # of tags the user has added. Also, reduces code complexity. However, in this case, we would have to decide what the string on the details page should read, on T250191.

May I ask about the reasoning for this proposal? Imagine yourself as a new editor. From a new editor’s perspective, grouping tags in the list and on the detail screen is the way to go. If tags aren’t grouped, the list is going to be unneccessary bloated. This is one of these cases in which we specifically design for new editors, not for existing/experienced users of Commons or Wikipedia.

Can we use the standard progress bar that appears below the toolbar instead of at the bottom of the screen [like explore feed] while lazy loading is in progress?

Yes, the same behavior as in the Explore Feed makes sense to me.

Can I suggest that this is not the time for us to redefine what a "contribution" is.
What we're building is a list of the user's contributions. Whether we like it or not, in the world of MediaWiki, each image tag is a contribution.
The "total" contributions statistic that we show to the user already counts each tag as a separate contribution.

I totally understand the design aesthetic of treating multiple tags as one edit, but that's simply not how it works, and if we start papering over these inconveniences of MediaWiki, it will have unintended consequences, both for ourselves and for the user's understanding of how things work.

Maybe, eventually (in v2 or v3 of this feature), we can think about "grouping together" edits that were made to the same article in quick succession, e.g. "Yesterday -- 6 edits to Big Momma's House II -- 3 tags added to Bissel.jpg", but the complexity of that is far too great for an MVP.

In T250190#6218949, @Dbrant wrote:

Can I suggest that this is not the time for us to redefine what a "contribution" is.
What we're building is a list of the user's contributions. Whether we like it or not, in the world of MediaWiki, each image tag is a contribution.
The "total" contributions statistic that we show to the user already counts each tag as a separate contribution.

I totally understand the design aesthetic of treating multiple tags as one edit, but that's simply not how it works, and if we start papering over these inconveniences of MediaWiki, it will have unintended consequences, both for ourselves and for the user's understanding of how things work.

Maybe, eventually (in v2 or v3 of this feature), we can think about "grouping together" edits that were made to the same article in quick succession, e.g. "Yesterday -- 6 edits to Big Momma's House II -- 3 tags added to Bissel.jpg", but the complexity of that is far too great for an MVP.

I agree with this. It does not make sense from a user perspective to count each image tag as 1 edit for purposes of calculating their number of edits (which we have to do because of MW limitations) in one place, and then counting multiple image tags as one edit in another place. That is liable to lead to confusion. So for now, we will have to live without the grouping. By all means @schoenbaechler, do please make a ticket for grouping them in a later version, and we will revisit the problem with the counter as well.

Ok, this turned into e legitmate debate! 👏

I agree with this. It does not make sense from a user perspective to count each image tag as 1 edit for purposes of calculating their number of edits (which we have to do because of MW limitations) in one place, and then counting multiple image tags as one edit in another place (...)

Yeah @Charlotte, contribution count on Suggested edits home is a whole other story. We’re now building features based on a broken foundation. I truly believe that users perceive adding a set of image tags to one file, as one edit, regardless of how MediaWiki is processing this or how it’s been done before.

However, I see that there’s a middle ground, e.g. by going with a solution as @Dbrant is suggesting.

Maybe, eventually (in v2 or v3 of this feature), we can think about "grouping together" edits that were made to the same article in quick succession, e.g. "Yesterday -- 6 edits to Big Momma's House II -- 3 tags added to Bissel.jpg" (...).

Source → grumpy_kitzia → https://www.instagram.com/p/B9XGmwRFNPG/

In regards to ...

(...) and if we start papering over these inconveniences of MediaWiki, it will have unintended consequences, both for ourselves and for the user's understanding of how things work.

I’d like to quote Steve Jobs: «You've got to start with the customer experience and work back toward the technology - not the other way around.» At some point we need to challenge the current state (of MediaWiki et al.), in order to progress and attract new type of users / editors.

Long story short, I did what you suggested @Charlotte and created a separate task for our longer term contributions history vision: T255275

Not to fuel the confusion... but I have already grouped them while building it based on the many discussions @schoenbaechler and I had, and because I completely agreed with it, from the user's point of view despite the code complexity.

@Dbrant 's follow-up ungroups it. However, if we are going to write a fresh ticket to "Group-it" again, I am assuming that we are planning to display them differently? some additional UI, suggesting that they belong to the same article/image? Because if we are just suggesting grouping it by 'show it only once in the list', that is what my code does now.
cc @Charlotte

Because if we are just suggesting grouping it by 'show it only once in the list', that is what my code does now.

To be clear, your code does indeed do this, and it works perfectly well.
However: you're grouping together only image-tag edits, and not other types of edits. (and the way it's presented, it's not obvious that these are multiple grouped edits.)
And therein is the point: if we're going to make a UI for grouping together edits, it should apply to all types of edits in a uniform, consistent, well-thought-out way.

Here are just a few scenarios that will make things super confusing if we proceed this way:

• Suppose we allow the user to add a tag to any image in an article, randomly (a perfectly valid continuation of our current work). You add one tag, then a few minutes later, come back and add another tag. Should that count as one edit in our contribution screen? What if you come back a week later and add a third tag? Is that still part of the same edit? Because it will be.

• Suppose you add a description to an article, then immediately realize you made a typo and correct it. Is that one contribution or two?

• Suppose you add an image tag, but then a vandal reverts the edit, so you add the tag again. Should that be shown as a single edit or two?

I hope I'm convincing you that grouping together edits without some amazingly smart logic and heuristics is not the way to go for the first iteration of this feature. The nuances are so numerous as to make one's head spin, which is why I would estimate this kind of work for v2, if not v3 of this feature.

@Dbrant that is exactly what I meant. If we are going to take care of all these scenarios and design suggestive ui for all the scenarios mentioned, yes, it totally makes sense to a separate ticket for that improvement. But meanwhile, 'to group or not group'?

When you observe the 'contributions list' screen, and then the subsequent 'details' screen together, I think we are just trying to choose the lesser of the 2 evils here. Neither is accurate:

1. Seeing duplicate entries, with absolutely no difference either in their appearance, and when clicked, there is no difference in their detail screens is more confusing
2. Seeing only one entry, remembering that they edited it multiple times, and then clicking on the details screen, which might somewhat explain to them, when it reads "You added n tags" or in case of articles they will hopefully see the final version of all their edits [universe-willing, because someone might have changed it again]. This is also confusing, but less so.

We must also remember that all those scenarios are still broken even without grouping, because:

• We show the latest state of descriptions or captions, we don't show "their" edit like a diff. Many things might have happened after their edit.
• As far as grouping only the image edits goes, I felt that people most often remember their multiple edits to articles as multiple edits, but their multiple selection of image tags as one edit. But makes sense to either group or not group for consistency.

In T250190#6220174, @Sharvaniharan wrote:

@Dbrant that is exactly what I meant. If we are going to take care of all these scenarios and design suggestive ui for all the scenarios mentioned, yes, it totally makes sense to a separate ticket for that improvement. But meanwhile, 'to group or not group'?

When you observe the 'contributions list' screen, and then the subsequent 'details' screen together, I think we are just trying to choose the lesser of the 2 evils here. Neither is accurate:

1. Seeing duplicate entries, with absolutely no difference either in their appearance, and when clicked, there is no difference in their detail screens is more confusing
2. Seeing only one entry, remembering that they edited it multiple times, and then clicking on the details screen, which might somewhat explain to them, when it reads "You added n tags" or in case of articles they will hopefully see the final version of all their edits [universe-willing, because someone might have changed it again]. This is also confusing, but less so.

We must also remember that all those scenarios are still broken even without grouping, because:

• We show the latest state of descriptions or captions, we don't show "their" edit like a diff. Many things might have happened after their edit.
• As far as grouping only the image edits goes, I felt that people most often remember their multiple edits to articles as multiple edits, but their multiple selection of image tags as one edit. But makes sense to either group or not group for consistency.

I think @Sharvaniharan makes an excellent series of points here. Actually a good question for @dchen to ask, if we have a version of this screen where they are totally ungrouped and so have multiple entries looking very similar, does that make more or less sense than seeing some types of edits grouped and some not?

I'm hearing some confusion around seeing "duplicate" entries.

Of course we shouldn't be showing "duplicate" entries. If we're displaying duplicate-looking entries, that's a problem with the information we're showing there,. The answer is not to group them together, but to show more meaningful information for that edit. (information which we have, in the edit comment or the edit body itself)

• If the user makes two separate edits to an article description, the edit history should absolutely show the description that they wrote at the time of the edit. (We have this information as part of the edit comment.) Clearly if we only show the current description of the article, the edit entries will appear as duplicates.

• If the user makes two or more image tag edits, the edit history should absolutely show the specific tag added for each of those edits. Clearly if we only show all the "current tags" for that image, the edit entries will appear as duplicates.

I was under the impression that we would, in fact, show the specific content that the user actually added for each edit, instead of the "current state" of the edited article?

Agree with the image tags @Dbrant. My next change will reflect the exact tag for that edit, so not confusing.
However with article descriptions and image captions, we made this compromise long back during design review, that we will just use the latest description rather than parsing the comment.
But to wrap this up, I am all for parsing it. I guess then that will make the two options equal.
@Charlotte @schoenbaechler should we then ungroup and make the necessary changes for parsing descriptions?

@Sharvaniharan @Dbrant

• If the user makes two separate edits to an article description, the edit history should absolutely show the description that they wrote at the time of the edit. (We have this information as part of the edit comment.) Clearly if we only show the current description of the article, the edit entries will appear as duplicates.

• If the user makes two or more image tag edits, the edit history should absolutely show the specific tag added for each of those edits. Clearly if we only show all the "current tags" for that image, the edit entries will appear as duplicates.

Yes, this is exactly how this should work.

However with article descriptions and image captions, we made this compromise long back during design review, that we will just use the latest description rather than parsing the comment.

I think there was a misunderstanding @Sharvaniharan. It was always about showing the user’s edit in the list and details view, not the latest article description or image caption. On the details page, we’re providing a link for users to get to the article or file page itself. That’s where users will see the current article descriptions/image caption.

This aside, I completely agree with your statement here @Sharvaniharan

As far as grouping only the image edits goes, I felt that people most often remember their multiple edits to articles as multiple edits, but their multiple selection of image tags as one edit. But makes sense to either group or not group for consistency.

Also, I mentioned earlier that...

I truly believe that users perceive adding a set of image tags to one file, as one edit, regardless of how MediaWiki is processing this or how it’s been done before.

Again, technical constraints aside → Image tag editing is just different than usual editing on Wikipedia. For instance, if a user is editing multiple article descriptions in a short amount of time, I’d still argue to list these edits separately in a list instead of grouping them. Why? Because the user has edited multiple / different instances (articles). When a user is editing tags for a specific image/file and hits publish, it’s always going to be one instance (image/file), therefore we can group it.

Long story short, I think it’ll come down to the technical edge cases that @Dbrant mentioned earlier. If he evaluates that grouping should be considered in V2/V3, I’m ok with tackling it later in T255275.

hi @schoenbaechler, with the ungrouping , do we need to add the tag count, and have the list item text '+%numberOfTags tags' on each item of tag contribution?
cc @Dbrant

Hey @Dbrant, correct me if I’m wrong: simultaneously publishing tags (as you nicely demonstrated last week), does now allow us to show multiple tags in a list item, right? More or less 1:1 of what Commons is showing, here’s an example edit: https://commons.wikimedia.org/w/index.php?title=File:KCON_JEJU_2015,_stadium_concert,_SPICA_4.jpg&diff=prev&oldid=428282653.

@Sharvaniharan

with the ungrouping , do we need to add the tag count, and have the list item text '+%numberOfTags tags' on each item of tag contribution?

If the above is correct, I suggest to go with this design for all image tag contributions. Means yes, please show +%numberOfTags tags if users added multiple tags, respectively +%numberOfTags tag if users only added one.

In T250190#6244206, @schoenbaechler wrote:

Hey @Dbrant, correct me if I’m wrong: simultaneously publishing tags (as you nicely demonstrated last week), does now allow us to show multiple tags in a list item, right? More or less 1:1 of what Commons is showing, here’s an example edit: https://commons.wikimedia.org/w/index.php?title=File:KCON_JEJU_2015,_stadium_concert,_SPICA_4.jpg&diff=prev&oldid=428282653.

Correct!

@Sharvaniharan, not bad for a first pass at this – the experience feels pretty native and you interpreted color appliance well! 👏

To optimize:

01) Change label to `All contrib@Sharvaniharan, not bad for a first pass at this – the experience feels pretty native and you interpreted color appliance well! 👏

To optimize:

01) Change label to All contributions

02) Move icons down (probably 2dp), so they’re aligned with the text.

03) Optimize loading behavior

• Always reserve space on the right with a square in paper_color to reduce text jumps when elements are loaded.
• To consider: Synchronize title and description loading → show it at the same time or replace it with rectangles in color_group_22 when text is not completely loaded yet

https://www.dropbox.com/s/dq5ric0g1dowunq/loading.mp4?dl=0

04) Change label color to themed_icon_color / color_group_2 – color contrast is not sufficient currently

05) Show number of tags added here. Also, prepare UI for removed tags.

06) Optional, wait on usability test findings with this → No graph 😢 Let’s add a static xml/svg graph to this screen. It’ll get the job done, for now ;)

Note that the following items will be fixed by my current PR:

01) Change label to All contributions

03) Move icons down (probably 2dp), so they’re aligned with the text.

04) Optimize loading behavior
Always reserve space on the right with a square in paper_color to reduce text jumps when elements are loaded.

08) Show number of tags added here. Also, prepare UI for removed tags.

Thank you for the heads up @Dbrant. Will fix the rest.

Almost there @Dbrant @Sharvaniharan, thx for the hard work 👇

04) Optimize loading behavior
Always reserve space on the right with a square in paper_color to reduce text jumps when elements are loaded.

I think we reduced scroll jumps to almost zero. They’re still noticeable from time to time filtered when there are article descriptions (with no images associated). To get to zero interface jumps, we should always reserve the space on the right for the transparent placeholder image (it currently shifts to full width when no image is available). I’m aware, that this is a bit of a trick, but I weigh no jumps over the fact that there’s a little less horizontal space for text to be displayed.

The last two things to be optimized 👇
01) Remove File: ... text in list items and detail screens (image tags and image captions), it’s unnecessary.

02) Text is cut off at the bottom from time to time, please optimize:

03) Use color_accent for both lightning icon and views number. Also, add views label after the number to make it more clear what it is 👇:

THX

Great changes @Sharvaniharan, especially scrolling feels way better now! 🎯

01) One thing left → the views label is still missing:

Implementation	vs	Design

THX

Looks good on 2.7.50324-alpha-2020-07-08