Icon: It is the same way of displaying as on constraint violations, so I would for now leave it this way.

Seems fine to me – mockup above, screenshot below.

I'll just ask you – I guess it won't fluctuate widely from month to month.

Thanks! This is what I needed. In case I need precise numbers for area-under-curve or so, I’ll create another task (I "integrated" via cumulative sums in Excel by now, so I might be off a measurement or so, but it is still enough as estimates)

a column where each particular editor is represented by one row while the (pseudonymous) user column refers to some ID value which thus anonymizes the real user ID/username? I guess (2)?

"Heute ist der letzte Tag unserer Spendenkampagne" breaks the above definitions.

Depends… I guess this is still relevant and unresolved as long as the target groups have not been defined somewhere, yet.

What is also in vue’s favor but something that is not highlighted in the RFC is that the documentation is very good. This does not only mean comprehensive and not wrong, but also that there are different types of documentation for different usecases (Onboarding, General Learning, Reference). This was one of the key points when some colleagues and me were thinking about a new framework at WMDE. A lot of people come from PHP or OOUI rather than from other MVVM-frameworks. Thus, a good documentation which quickly shows people what the framework is about, is important. Since the js file of vue is sufficient, people can quickly try it out what the documentation tells them (there are also embedded examples, but maybe you want to try in a mediawiki-context or whatever)

{M290/985}

The usual color for this is #808080, the opacity is set to 50%. Hovering over it now changes the color to #747474, leaving the opacity as is. If you don't know that there is a hover effect, you just don't see it.

It could also be always in the center of the remaining area or at the 3/4part of the remaining area. It just is easier to build when it has a fixed position. Devs can also take this apart and estimate pointer position adjustment separately.

proposed solution in ticket.

I cant reproduce this. When I go to spenden… click "5€" and press ENTER, it does nothing.

thanks. updated…

It seems that keeping the value in the field is the standard, thus I would suggest also keeping the numbers. (or in general: Do whatever the standard input-for-numbers behavior on the device is)
The larger problem might be that we attach a €-Character directly to the input, which leads to confusing appearances and disappearances of the € and makes hitting the right spot with your cursor harder (since "after the number" needs to be in the small spot "before the €"). Biggest gain for the field is getting rid of overwriting the value and showing the € via CSS.

Text for message: "Die E-Mail-Adresse scheint nicht korrekt zu sein. Eine E-Mail-Addresse kann z.B. so aussehen: max@example.com"

@Jan_Dittrich I did not properly get the hover colors. Should all of them share the same hover color?

The radio buttons on "Spenden als..." should be vertically arranged

Calculations:

Is that intentional or an oversight?

The form should be responsive (e.g. label goes to the top of input fields) - This variant might also be used for the email campaign in the first week of Nov

See issue at https://phabricator.wikimedia.org/T236465
Different sizes (at least on Firefox)

Just for the sake of not loosing the information: I noted that there seems to be something like a standard pattern of how other web-tech-based projects deal with this, namely the pattern of:

final figma mockup is pasted in the ticket. It is to be found where the previous mockup has been.

it gets a bit cramped in this grey box with the 4 question columns.

We (WMDE SWE FUN Tech) do not know what our actions should be here. If this is a task for us, please speak with someone from the team @Christine_Domgoergen_WMDE

@JanJaquemot Thanks for the test – we found out that Safari for Windows is not updated 2012 and we do not support it (also the share of visitors is 0,…% on Wikipedia.de)

I wonder if it would make sense not to test against the old banner (which is what I would read from the description above) but against a copy of this new banner, but with the address switch hidden.

So, if I understand correctly, the banner would:

1. start with a the usual vertical, right-hand-form
2. on making the browser smaller, switch to the full-width form
3. when the browser becomes even smaller, the full width form would have another step where the Kontonummer etc. is below the form.

This is a layout that does not exist in this banner, since it makes the banner too high.

@Jan_Dittrich what about the vertical form of this design? We would need that too. Or is this provided somehow else?

It seems to be ready to go, they all have nice yellow batches, now :)

As for getting the relation of clicks:

I also show a static warning message. However, I find not having it dynamically problematic usability-wise since we do not use the word "value" in our UI, so it is likely that people do not understand the not-dynamic message using the term "value" (Except if they already know "Wikidata-speak", but this is something they need to learn from others, so it is not cool for new users).

The above mockup says "remove message" which is pretty much what it does. It does not say "the edit is fine" or an equivalent, since this would probably need more words than I can fit on a button. Also it currently has no fixed semantic meaning, so removing it for one user is what is happening. When we have the 3rd milestone we need a more elaborate UI which gives some explanation for the now shared assertion of fine/not fine, probably in a popup.

I suggest then
"The value changed, but the reference remained the same."

As far as I am concerned and according the the flowcharts I send around, this is milestone 2. Are we already there?

save space

As for the working mode: It should be the same red banner as we are used to, so no redesign or bigger changes. This would leave us with defining the responsiveness. However, this is something hard to do in our design tools because in frontend terms they work with "absolute positioning" (simply put). So I would suggest we would deliver more something like sketches for where to put the breakpoints and what to show and what not, since putting everything into figma for the one thing such tools are not good at does not make a lot of sense to me.

So, in our little meeting @Tim_WMDE we talked about:

As the task does not have a description: What is needed as input from UX? What are the current problems?

This is not a problem anymore, is it? @gabriel-wmde
In this case, lets resolve.

the golas are legacy, so I close this one.