As noted in previous team discussions, I don't believe that "Articles translated" is a valid term in this context. Page collections are just lists of articles, we should not suppose that these lists are created for the sole reason of translating the articles from one language to another. Additionally, even if these collections are just list of articles for translation, we do not (anymore) support a specific target language for translation, which means that a given article may exist already in the selected target language (inside CX dashboard), without having been translated. For these reasons, I suggest to rename this to "Articles present in target language" or something similar. This kind of information is also straightforward to retrieve and display to the user.

In a similar way, "Translators participating" should be entirely dropped as there is no way to retrieve such information, and it's also probably contradicting with the definition of page collections that we have adopted. Page collections do not (and should not) have translators.

Finally, regarding "Days left" field, this is also out of scope of page collections. However, in case that we get to relate page collections with events like campaigns at some point in the future, we could also support it.

A successful career QA software testing course provides comprehensive training in manual and automated testing, equipping learners with essential skills for

This looks good. Sharing some thoughts:

1. Information provided and structure seems logical: what the collection is about, which are the contents, and which community activities I can join to contribute to these topics along other editors.
2. For the "Context description with article count" we can consider providing access to two actions that help connect the collection with related activities;
   • We can provide a prominent action to select this collection to be used in the filters view. In this way, users can adjust the suggestions further by selecting a language pair or filter further (when multiple selection is available). Possible names for the action: Select the collection, Work with this collection, Explore...
   • We can provide a less prominent action to the wiki page where the collection was defined. In this way, editors working on the collection definition (or interested in doing so) can access the wiki page to, add/remove articles, make proposals to the talk page or remove the marker (i.e., remove the collection). This is an option that is expected to be used with lower frequency (compared to using the collection to translate) so a lower prominence may be useful when representing it. Possible names for the action: View collection source, Edit collection...
3. It is not completely clear how this will work for a collection with more articles. The description mentions lazy loading when scrolling. However, it is not clear how the different parts of the UI will move (or float) when scroll happens. For example, what would happen to the collection context info and the collaborations panel when the user scrolls past "Guerrilla Girls" in the example?
   • Being the list content in the middle, there may not be immediate clues about the contents being scrollable. That is, users may intuitively interpret the above mockup as having just 3 items, needing to read and process the text about having "150 articles" to understand there may be more. An option to "View all" that expands the list in place could be a simple approach to consider.
4. For the ongoing collaborations part, the description could be improved. On the one hand, the activities listed may not be specifically "translation projects". On the other hand, we may want to use this opportunity to encourage people to join. We can consider something along the lines of "Editors are collaborating to contribute to these contents. You are welcome to join the following community efforts."
5. The action for the different collaborations it makes sense to link to the corresponding wiki page, and it could be just "Join", since there are many types of events (campaigns, editathons, contests, etc.) and adjusting the label to match may add some unnecessary complexity.
6. For time-based events, we may want to provide information about time in a more meaningful way for the user. For example, if the event is starting soon, we may consider indicating the event starts soon (e.g., starts in 3 days). If the event started, we may want to signal it is active and ending in X days. These are just examples, we may wan tot analyze which is the most useful way to surface time in this context, and consider that users can always access the event page for all details if more information is needed.
7. For cases where there is a particularly relevant collaboration, we could consider adding an element at the collection context section on top to signal that there is a relevant collaboration. For example, in the example, a chip indicating the collection is used by "Women's history month 2024" could be helpful to increase visibility to the campaign and direct users to the Ongoing collaborations section at the bottom for more details when taping on it.

In T379273#10396761, @Pginer-WMF wrote:

This looks good. Sharing some thoughts:

• We can provide a prominent action to select this collection to be used in the filters view. In this way, users can adjust the suggestions further by selecting a language pair or filter further (when multiple selection is available). Possible names for the action: Select the collection, Work with this collection, Explore...
• We can provide a less prominent action to the wiki page where the collection was defined. In this way, editors working on the collection definition (or interested in doing so) can access the wiki page to, add/remove articles, make proposals to the talk page or remove the marker (i.e., remove the collection). This is an option that is expected to be used with lower frequency (compared to using the collection to translate) so a lower prominence may be useful when representing it. Possible names for the action: View collection source, Edit collection...

I like these suggestions and propose we create a separate tasks(T383761) to consider these points.

• It is not completely clear how this will work for a collection with more articles. The description mentions lazy loading when scrolling. However, it is not clear how the different parts of the UI will move (or float) when scroll happens. For example, what would happen to the collection context info and the collaborations panel when the user scrolls past "Guerrilla Girls" in the example?
  • Being the list content in the middle, there may not be immediate clues about the contents being scrollable. That is, users may intuitively interpret the above mockup as having just 3 items, needing to read and process the text about having "150 articles" to understand there may be more. An option to "View all" that expands the list in place could be a simple approach to consider.

Thank you for raising these important UX concerns. I think this is how we can address these.

1. Scrolling behavior and UI layout:
   • Collection context info stays fixed at top
   • Collaboration panel anchors to bottom
   • Article list scrolls in between
   • Clear visual separation either through space or shadow

2. List expansion & visibility
   • Initial view:
     • Show first 3-4 articles fully
     • "Show all X articles" button prominently displayed

Interaction Option:
a. "Show all..." expands full list-in place
b. Smooth animation for expansion
c. "Collapse" option when expanded

Some of the items from this part can be addressed as this ticket whereas for "Show all X articles" button we can have a separate task.

• For the ongoing collaborations part, the description could be improved. On the one hand, the activities listed may not be specifically "translation projects". On the other hand, we may want to use this opportunity to encourage people to join. We can consider something along the lines of "Editors are collaborating to contribute to these contents. You are welcome to join the following community efforts."

Make sense. We can change it to "Editors are collaborating to contribute to these topics. You're welcome to join these community efforts".

• The action for the different collaborations it makes sense to link to the corresponding wiki page, and it could be just "Join", since there are many types of events (campaigns, editathons, contests, etc.) and adjusting the label to match may add some unnecessary complexity.

sure, we can go with just "Join" here.

• For time-based events, we may want to provide information about time in a more meaningful way for the user. For example, if the event is starting soon, we may consider indicating the event starts soon (e.g., starts in 3 days). If the event started, we may want to signal it is active and ending in X days. These are just examples, we may wan tot analyze which is the most useful way to surface time in this context, and consider that users can always access the event page for all details if more information is needed.

Thanks, we can divide the time in different states here. Future events(not started yet), Current active events, Past events(I am assuming we wont need anything for these).

Representation ideas:
a. Future events

• Very soon(within 24 hours): "Starts in X hours"
• Near future(1-7 days): "Starts in X days"
• Medium future(1-4 weeks): "Starts in X weeks"
• Further future: Show actual date(if > 1 month away)

B. Active Events:

• Just started: "Recently started"
• Ongoing: "Active - ends in X days/hour"
• Almost ending: "Ending soon" (e.g. last 24 hours)

• For cases where there is a particularly relevant collaboration, we could consider adding an element at the collection context section on top to signal that there is a relevant collaboration. For example, in the example, a chip indicating the collection is used by "Women's history month 2024" could be helpful to increase visibility to the campaign and direct users to the Ongoing collaborations section at the bottom for more details when taping on it.

Thanks Pau, we can certainly think of it as a further improvement to Collection view part.

Change #1113173 had a related patch set uploaded (by Nik Gkountas; author: Nik Gkountas):

[mediawiki/extensions/ContentTranslation@master] SX: Introduce page collection view dialog

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

This is a well-structured and user-focused design approach that clearly prioritizes usability and scalability. The seamless integration of scrolling behavior, compact headers, and contextual descriptions enhances the overall user experience, especially for content-heavy platforms. The collapsed collaboration panel is a smart move to maintain focus without sacrificing important information. It's great to see UX practices that align with industry standards often followed by leading mobile app developers in USA, ensuring intuitive navigation and responsive design. Looking forward to the future enhancements like smooth list expansion and improved collaboration visibility.

@SGautam_WMF, before development starts, we may want to include a link on the collection view to the page where the page was tagged as a collection. For example, the Wiki99 sustainability collection view would link to https://meta.wikimedia.org/wiki/Wiki99/sustainability

In this way, users finding an article is missing/wrong in the Collection view can access the source data behind it to edit it.

@ngkountas I am assuming you are working on this one. Just a heads up - we're adding a small enhancement to the Collection View based on @Pginer-WMF feedback. We've included a "View collection source" link(mockup updated in task description) (styled with #3366CC, 14px text) below the collection description that will direct users to the wiki page where the collection was defined.

This is just a minor addition to the context description section and shouldn't impact the core functionality you're working on. The link will hide when scrolling to maintain the compact header view. Let me know if you have any questions!