Editing shouldn't be possible for any of the staff created pages. But I guess this is one of the limitation of building the pages in wiki?

@GMikesell-WMF @Samwilson the design does look different from the Figma file. Is it something we can align?
https://www.figma.com/design/JcTMFwbEJPpCKBiZ16Jkel/Future-of-the-Wishlist?node-id=2179-73651&t=VlFzwG3BWS1iOSs0-1

@MusikAnimal 1 column checkboxes look nice on mobile. This is what I would have proposed too.

Yelast updated will be more important that creation date in most cases so would make more sense to appear on top. If it's a small fix and easier to address under this task then let it be here.

Good catch @dom_walden! I didn't create an error state for that. It should be a standard error state with all the fields and submit button enabled again with error text "Looks like you don't have internet connection. Please connect to the internet and try submitting the form again"

@Samwilson I'm. not able to visualise how it will look and if it will add any extra benefit to the user. Would it be able to see a sample screenshot to understand where the ToC is required?

Also, can the last updated date be placed before the created date on the wish detail page? I feel this is more important than creation date.

@MusikAnimal @GMikesell-WMF thanks for the detailed explanation. Agreed after seeing the use case that the link can stay. When I tested it earlier, the link wasn't showing up from anywhere else except from the wish detail normal view. An I feel in that view it's least important cause advanced editors will probably not use the form anyways to edit. I was going with the UX best practice of not having the same entry points multiple times on a page. If you think strongly it will help users access the form from different views, it can stay.

In T369764#9971622, @MusikAnimal wrote:

cc @JSengupta-WMF regarding design/copy. I'll go with the above for now, which is the easiest to implement.

Looks good now @MusikAnimal! Thanks. The rest of your points make sense.

I would say in this case we can add a disclaimer/banner on the form that says you can submit wish in any language and not add another form field that user needs to select.

@MusikAnimal yes disabling the fields and the button while the form is submitting is fine. Do we have an existing loading state or do you need a design for that?

Looks good to me! Also, whoever fixed the spacing in the form, thanks to them!

The table looks good overall. Here are some minor comments:

@Samwilson @tstarling as far as I understood, we are going with the Meta style search for MVP, i.e. the search results are shown on a separate page and user can search based on wish title or description. Am I correct?

We can keep it "Publish" and "Save changes" respectively for submission and edit.

Also, button text should be "Publish wish". Field level validation shouldn't happen when a user jumps to the next field but only after clicking the Publish wish button.

Yes let's keep it all sortable in that case.

@JWheeler-WMF I am sitting with our DST designer Sarai and we discussed many scenarios. The more I tried to add different scenarios on the table the more I feel only sort option won't be enough. We will need a filter for at least project and status. For an even better and scalable UX we will need a filter on Focus area as well.

This is the first exploration of wish index.

Assigned this task to me as I will start exploring some design with the new table component which is now ready by Codex design team. I will assign it back to @MusikAnimal once the design is final.

@JWheeler-WMF We dropped aggregate rating from the focus area. The description should be updated I think.

I will update the table. Do we need all of the fields on the table though? It might reduce readability of the table.

General error states example here

@MusikAnimal that's totally fine. I think the current top 4 projects are just indicative by Glauco. We should show the projects under which most of the wishes are received. If the above are top 4, feel free to change the order from design.

@Samwilson where can I check the form?

Checkbox has been removed and copy updated.

Same design file. I will pop the link in here and add this task to the related task again.

I adjusted it. You can use 200 and 100 spacing.

@Samwilson yes. I have updated the button state to disabled in design when the checkbox is not selected.

I think the approach overall is good. Rather than blocking the user, providing them option. We can combine it with

In T362274#9704962, @MusikAnimal wrote:

I'm thinking this should probably be called "Type" or "Proposal type". "Category" is confusing because to people familiar with the Survey, they'll think of wishlist categories (i.e. "Admins and patrollers", "Bots and gadgets", etc.). Additionally, "Type" roughly translates to what it would be here on Phabricator (Feature request, Bug report, etc.). cc @GLima-WMF