We could. My proposal would be to change the link name to something user understandable (a verb preferably) than the direct tool name. For SVG we can use 'Translate SVG' if it makes sense.

@Doc_James Here is a proposal for the new section on the right side toolbar after discussing a couple of different options with @mikez-WMF.

Added the design

@Doc_James What will be the workflow if the user selects the checkbox to request Commons admin to delete previous versions of the file? How will the admin be notified?

My proposal will be to include a clear button to delete this info.

@TTO I did some more digging and saw that licensing attribute on the Commons map data page is always "Data available under Creative Commons Attribution 4.0." same as any Wikipedia article due to multiple authors editing an article.

Would it ever be necessary to remove or edit a redirect? E.g. A broad topic article exists today but tomorrow someone writes another article that is more specific to the topic and therefore is a more suitable redirect.

long-term it makes sense to look at some metrics (such as click through rates and anything the tools are using to track engagement) to justify getting into core.

I propose we create another section in the toolbar for these editing tools and show them under that. @mikez-WMF do we need to indicate which are suggested and which are integrated tools?

When would the mobile scenarios arise in the live environment? This looks like a desktop version of the page was requested on mobile.

Thanks Sneha! When we rolled out the watchstar dialog initially, we got a suggestion from a community member to make it dismissable by hitting Esc key. Could that be added in the list too?

Thanks for the solution proposal! While this should solve the problem, from UX perspective having a button with such long text is not advisable. It could cause several problems in terms of displaying the text in certain languages that are longer than English, showing it on smaller screen and in general being visually heavy and verbose. I propose we keep the current button text and add the option to remove location information through a checkbox. Some proposed designs are attached below. I have taken a pass on simplifying the text so both technical and non-technical users understand it.

Thanks for pointing that out. Both fonts are set to Codex - Caption Regular so have been tested for accessibility standard by the design system team.

Very good points! I have another design proposal based on the scenarios you mentioned. Having a link on the expanded map view to trigger the pop over. That way even if it's a line still the user won't have to click on it. Please see the example below:

Thanks @TTO. That was my first thought too. But after doing a quick investigation internally, I was told that Open maps doesn't use CC-BY license. So putting the CC-BY information on the map canvas wouldn't be right as per my understanding. I included the licensing information on the overlay because that is the actual user generated content that needs licensing.

The green is intentional to keep it consistent with other suggested items (e.g. suggested username). I do agree that it should be tested and I am happy to take any feedback into consideration and adjust the design accordingly. Can it be released as an opt in feature so users can test it out?

Thanks for your feedback. While I also agree and prefer the solution proposed above of keeping an action close to the failure, my thoughts initially were to address the use case of multiple upload failure. If let's say there are 10 files that failed to upload, user needs to click retry 10 times. Having a single Retry all could solve this problem. But as we have this action at the bottom of the page already, happy to proceed with item level Retry action.

Do we or can we get some statistics on how many total edits have happened only on the lead section of an article within a given amount of time? Say last 6 months. The tools menu already has a lot of links depending on the wiki so adding more actions will only crowd it further.

Yes that's great! Please use the error colors when available. Thanks for noticing this.

Can we use the existing MediaWiki notification and scroll the page up to the first point of failure?

Here are the screen mocks used to create the prototype. If the prototype doesn't load on your browser or takes too long. Please refer to these.

As it's a simple click through prototype, I have only created the adding and removing items from watchlist. The prototype wouldn't work like the current implementation and have limited features. You can click on the watchstar, see the pop-over display, click on the label field to apply a mock label. You can also unstar an item.

Thanks for your patience and working with us on resolving this!

Very strange. I tested it before but you're right it doesn't work now. I have updated it again. Hope it works.

Hello all, thanks for all your feedback on this feature. @KimKelting we tried several versions of design and one of them was what you suggested, with a separate dropdown next to watchstar. It had some implementation challenges.

I’m challenging the need to have 2. If a page is already watched it is
evident from the star.

Makes sense. Why would we need a grey state in that case? When the pop up first opens it should also show green success that page has been added to watchlist.

Do we have any possibility of this action failing? e.g. DB writing error, connection error, timeout etc. If so then keeping both the success (green tick) and failure (red exclamation) icons make sense. But if there are no fail states then no need to show green tick on anything.

That's a good idea. Let's include that. Also, let's not use the success case rather keep it neutral with message case (not use green tick icon instead use grey exclamation icon). Otherwise when user clicks on red unwatch button, a message confirming the unwatch action will appear with green tick that may cause confusion.

For non JS existing design is fine.

Yes please move the page limit drop down within the main search form and have one Go button.

Here is the design that was discussed in the standup and was aligned with the reading list team.

We can show the non CCBY video rows on the table in disabled/greyed out state and include a toggle button at the page level to show hide them. Like file browsers where unsupported files are shown but are greyed out and can't be selected.

I brought back the "do not show again" action in the design. This is the pattern Growth team follows for their onboarding as well so let's keep it consistent.
https://www.figma.com/design/CdyroPkkcT7GJA9bwno0Rq/WE1.4-Task-priotization?node-id=810-34755&t=PyQEgYAkpn0M2f6g-1

Yes either showing it once or including a "do not show this again" action. Let's discuss this further closer to the implementation date.

I don't think it should be removed entirely but only be shown to the first time special:watchlist users. Let's discuss the scope of this feature.

Looks good to me @GMikesell-WMF. Yes the design in Figma is up to date. I see that the screenshot you have shows the row numbers but that has been removed as per discussion with @Cparle. The implementation is correct.

They don't need tooltips at this point. But the "Manage watchlist labels" will be called "Manage labels" only.

I updated it with "and". Sorry it was a typo in the design. So to reconfirm
we are dropping the week. Day, Month and Year stays. Have removed the row
counter too. Here's the updated design

I had a look at case 2 and based on the confusion in column header and value related to permanent items, will propose the following change.

@GMikesell-WMF please use this updated version of the design for validation. We discussed this in a planning meeting sometime ago.

Ah yes I overlooked it sorry. It should say

Yes the CTA and the dialogue box titles should change from singular to plural if multiple items are selected. I think column name should remain singular because it's the header of the cells that each contain only a single page title. Thanks for catching this!

✅ 🙏🏼

Looks good to me. Only one I am not sure about is Edit raw watchlist. But if it's an existing term and the users understand it, I have no say.

Remove sounds better.

Should this be a task for design systems?

@Samwilson it should be fine to begin with. Surprised that Codex doesn't support this. I thought growth team was the first to use this component.

Wasn't aware of it. Ok then let it be in its original position. We can close this ticket.

"Why was this implementation chosen?" sounds more natural. Alternately "Why did we chose this implementation?" could work too. If it's an external link, please use the Codex icon LinkExternal next to the link.

Added a design update in https://phabricator.wikimedia.org/T358807

In T358807#11415115, @DSmit-WMF wrote:

A proposal for this. Perhaps should be checked/improved by @gonyeahialam or @JSengupta-WMF

Cancel button should take the user to the whichever they invoked the submit a wish form from. If it's from a focus area page, it will go back to that focus area page. If it's from the overview page it will go back there and so on.

From the acceptance criteria, I understood that automatic vote of the wish author won't be displayed (assumption here: not counted = not displayed) till the wish is in vote-able status. So the default wording can still work.

@MusikAnimal thanks for taking a pass on it proactively. I have now updated the designs so please follow the button style and the user flow as per https://www.figma.com/design/JcTMFwbEJPpCKBiZ16Jkel/Future-of-the-Wishlist?node-id=3797-150914&t=Lv3TuFAAJWBHd1Lf-1.

Looks good to me!

Go with View 0 wishes in this area. I don’t see this situation arising
easily as the staff won’t create focus areas till they find a common theme
between wishes.

Thanks! Otherwise looks good.

Quoted Text "The "View N wishes in this area" link should jump to the "Voting" section of the focus area page"

Yes let's go with Community Wishlist/W123

Sounds good. Does unassigned translate well? We can also go with just a hyphen (-) I have shown an example of what you recommended, below. If this seems fine, I will update the published design.

Use these updated designs to triage this request
https://www.figma.com/design/3PthdmimQ8FiuhGIsLhmZi/Multiblock?node-id=3827-16431&t=6dK3Bo6uxvMgtwVm-1

The option marked "After" on the table looks great. If what you mentioned on the Slack about the importance of wish ID to certain volunteers, you can keep the same font size <h1> for the wish ID within parenthesis too.

If we decide to block voting before a wish is accepted by us, the message should say

FInal slides: https://docs.google.com/presentation/d/13TQY7HAC9dQEgx9OXX9-Mx_NE8oEjjXj/edit?slide=id.g3668fed620f_1_3446#slide=id.g3668fed620f_1_3446

Why would wishes under review not be eligible for voting? It is a good
signal for us to see how the community prioritizes wishes.

No further explorations are required at this stage for this task.

We can do both. Message when the tab is empty and in the tooltip when there are items in that tab already.

For 2. I would rather go with an error message whenever there is an internet issue notifying user about the main issue i.e. your internet connection is poor/no internet connection. What would be a valid (and quite widely used) use case for us to allow user to enter something that we don't know about?

Reusing the same icon for now is fine while the design team works on a new icon for favoriting templates. We are not rolling this feature out on App anytime soon. Will revisit it.

Yes I confirm it from the design side. It has been decided keeping in mind scalability in the future and the proposal came from the Editing team. So the first acceptance criteria needs to be updated in the description.

Sure let's do that.

Let's drop the icon in that case.

Thanks for creating this task! This was long due. Please feel free to contact Julieta and me for more context and history of diff. From engineering side, Harumi Monroy was the last person to work on this.