@Tonina_Zhelyazkova_WMDE and I made a suggestion/change to the button, making the invalid state look very much like the invalid state of the other fields (No black border, dark red border at the bottom, font inside field dark red, too)

IS DONE ↓

Yes, I think we should close it and open particular ones for each feature.

I see that points

the proposals are for the two different pages,

@tmletzko yes – I was assuming the link should be permanently in the sidebar. Misunderstanding.

My suggestion is to put the link in the top menubar:

@kai.nissen: Yes, though it is really hard to get it in the schedule for us.
@Tobias_Schumann_WMDE @kai.nissen : What is the result of the Piwik Tracking?

…This also might resolve the problem of using the same code to cater to two different usecases: Searching for an item to look at it and searching for an item to use it in another item.

Closing for now, feel free to reopen.

The behavior will be more consistent once we don't use a custom search box anymore (the current one is patched "on top" of the original one). I need to see if there is an issue for that. EDIT: it is T189490 : Solve search inconsistencies (which I just created)

@Lucas_Werkmeister_WMDE Is that done (I mean in general, we could still file subtickets for further improvements)? I close it for now.

For reference, here a screen shot of the example:

Depends on FLESH OUT but: Did they™ already try the standard solution of setting a (no-)JS class on the html so that the page can be "prepared" for how it will look after JS is loaded.

Depends on FLESH OUT but: Did they™ already try the standard solution of setting a (no-)JS class on the html so that the page can be "prepared" for how it will look after JS is loaded.

Yes, go ahead!

Would you add the icons to the “status” column (after the text) or replace the text?

If the things in "status" are the same we signify with the icons in the item-UI, we should reuse the icons here, too, to make them easier to learn and give people who learned them already the benefit of using their knowledge.

From looking at at (and there might be things I don't understand/misinterpret) the new version also looks better to me, design wise.

For exploration, we could design for:

• UX looks for a place to put this
• UX will suggest a improved wording (since "mehr" is not best practice)

It could make sense to put the IBAN in the footer as Amnesty, and Unicef are doing it. Brot für die Welt has a kind of "soft footer" which is at the bottom of the viewport.

Before clicking the button and after. Our framing of it is that people want to know how much time they need to spend.

The error page should not display a form prompting you to change the name of the file, as no file name will be valid, the extension is the issue.

@thiemowmde Fine with me. I would assume that the search function might have quirks, but I am unsure if this issue is one that needs to be tackled to improve search.

This seems relatively doable to me – I am only a bit concerned about the architecture of the selector, as far as I am concerned it is used both in search and in the item UI, so an improvement in one might decrease usability for the other usecase.

@Lydia_Pintscher which priority does this ticket have and how likely is it that this is build after a design is provided?

UX Team currently does not know how to improve this, since we don't know which:

According to @Charlie_WMDE UX work is done from UX team side, so we unsubscribe.

…one could also think about doing this more notification (so non-blocking) than modal style (depending on how essential this is)

…"up to"… is a good practice to provide, as long as it is in orders of magnitude (so if you say 30sec if it is still OKish if it is 10 times more of less so – it should not be 100 times more)

@GoranSMilovanovic We are still preparing the templates… But I think magic infoboxes and signed statements should be OK for preparing an evaluation strategy – @Lydia_Pintscher ?

Is this task still ongoing? I could help on the document.

Maybe this is something we can ask the community for feedback on — before making any decisions — and average out the responses?

I think @Verena, @Franziska_Heine, @TheDJ might be interested.

That's the safest option you can go with, without having to spend a lot of iterations.

Many things like "structured discussions" might be less a problem of building them but more of acceptance in communities. So I wonder how we can bring this dimension in. It seems very non-dev first, but I think many technology decisions are strongly influenced e.g. by not needing to cut old ties because it will make people unhappy (for plausible reasons).

strategic planning is, IMO, deciding where we want to arrive first and on the route to get there only after that

Do we have assumptions that we like to test? (not as in usability test, but more as find out about the possible context)

Improve Gadget Infrastructure: Gadgets could be

Cleaning up preferences: Yes.

Some scenarios with realistic show-rates (how often one will, without any muting, encounter a survey) could be helpful in planning this, e.g. one for a person of a group that might be asked relatively often, one for a less frequently asked and another one for readers or so.

@thiemowmde @Lydia_Pintscher Is that a task we shall pick up in the next weeks? – this would make only sense if it could be programmed on in foreseeable time after we have a design/behavior.

I wonder if "What general purpose they serve" is answerable by a quantitative study.

Seems like a useful feature to me.

So I feel like the choice here is really between not supporting free-form answers at all, or support storing them privately for researcher-only access.

Update: we might also use a mass message with signup (https://www.mediawiki.org/wiki/Extension:MassMessage) OR a "newsletter" (https://www.mediawiki.org/wiki/Extension:Newsletter)

But apart from these details, my big question is – how do we educate our users about these new features?

This "?" would be a keyboard shortcut, not something I type in some box or so?

@Jonas @Lucas_Werkmeister_WMDE Do we have have any criteria/method to evaluate if a stages rollout is needed and if, how much stages it needs?

It does not look nice, indeed. On the other hand, I assume it was never designed systematically (in the sense of "If we put IDs in the header, where else do we use this element?"). So I would frame it as a bit of (non-wicked) design debt. Like with technical debt, we might want to refactor it.

Yes. For the sake of clarity, let’s assume the schedule @Lea_Lacroix_WMDE suggested initially (if we think we can make it) OR suggest a new date. (Both being fine, I just don't want loose it in unclarity about the "when")

@Whatamidoing-WMF: Thanks, the explanation makes sense. Remark regarding the alternatives: I looked at the Feedback-Ext, it seems to be stopped.

For most questions I can think of, the just-record-the-namespace idea is fine. One could also think of an abstraction layer that could potentially extract some other information like article length, number of editors etc. in chunks (like percentiles, S/M/L/XL or so) and put it into a structured format (JSON or so), resulting into data like

Why are free form fields excluded? (a link or so to a discussion on this or so would be nice)

Yes, the latter would be much better. It is not a unbreak-now, but neither the under-the-data-headline nor the huge whitespace are good enough for not changing it to a better version.

I think it does semantically not belong under the "Daten" headline.

I don't know where we currently have/need an error icon. In case it is needed, take this:

@JeroenDeDauw @kai.nissen Looks good to me.

I thought is is done for me and I did not tidy the tasks yet.

I don't get what c) means, but I think that a) and b) make sense. They are not mutually exclusive options but cases to consider, is it?

I suggest to add (Optional) to the field's label/placeholder

I do agree to disallow decimal points (and I don't think, we should add this feature at all).

OK, I see 3 points on order of urgency: