Do we know if people made their Kommentar öffentlich? If yes, we could just have

good idea to reuse the same icons, though.

Remark: the split is easy to analyze if 10h16 and laika have the same elements on the respective two pages. (I assume they do)

@Lucas_Werkmeister_WMDE could you point me to the current constraint violation icons? I think we should use them.

it should be

@raja_wmde here the discussion so far.

no obvious problems found in quick design check.

seems fine. Accordions still have minor design issues (slightly jumping lines, but not serious)

Font seems to be fixed now. It was "normal" indeed, but it was normal for a thin cut of the font.

looks like

looks like

looks like

see above the corresponding form in the figma sub-document "flow"

agree.

afaic "Addressangabe" is the postal, physical address. Mail is treated separately.

IMHO we could improve the accordion behaviors regarding left-padding and borders…

Thanks. Let’s close it for now. It is still "off" in its shape but the prio is not so high.

so it has all bold fonts?
If that is the case, just close the ticket.

for the historical records: It gave me peace of mind that the rendering of fonts is not as off as I assumed.

Is this life (somewhere) or do I need to run the branch?

we aspire to have at some point a vue-js component library that is in its mission similar to OOUI. Such a thing would clearly need ownership and ideally right from the start.

Are we afraid that different hikes using/working on the library will have conflicting ideas as to what the library should contain,
or how specific component interfaces should look like? I would hope that our usual code review processes are enough of a solution.

Worth mentioning that the resulting package will be, in contrast to the APIs which stable interface policy notoriously applies to, versioned.

Isn't that confusing in case their server is slow or something?

This is the mockup: (sorry, was a bit hidden)

However, in that case we might as well just scroll up to the topmost empty input field rather than first scrolling the user up to a redundant box telling them to scroll down again.

From issue description:

reuse the messages that are displayed near the fields? (they could be too long)

Using something like storybook would probably ease it for PM and UX to join such conversations and it might also be a useful place to store/view component documentation.

I assume the purpose of the error summary is to make it easier for the person to identify the wrong fields.

It is the same style as :active , however it remains such after the click. The text "Überprüfen"+the icon are centered (as if the icon would be a character). The icon is not right-attached to the centered text (then, both as visual unity would be off-center).

I'd say having a text/icon near the submit button makes most sense.

The problem of people missing the error entirely can only be alleviated by showing where errors are. Suggested behavior is jumping to the top of the page and listing the problems there, so you get an overview and go past the problematic fields by scrolling.

Are there plans to show spinners or other indicators while smth. is going on in the background?

can be closed

it does, thanks!

Choosing "Firma" disables the membership type option "Aktive Mitgliedschaft".

thanks, that worked.

did so – T227774

@elukey I see – will you create the nda group task, or shall I do create it?

Sadly, it does not work, still get

@Nuria I tried and got a 401 after username/password.

yes, this is fine. It should look like the donation confirmation page.

@Nuria sure – ldap: WMDE-jand

Still in analysis phase, I hope for it to be published in the next month.

I was expecting one box for all the info, in yellow, because it is a revertible error message, thinking this was mediawiki standard behavior. Do you know what the standard behavior is?

sounds fine to me if you know where to append the text (probably at the very end to not mess up anything)

@kai.nissen told me that the current labeling suggestion would be problematic, since they are not composed of parameter name and value.
In case the current suggestions are too difficult to implement, a variant which would allow this would be:

If Graphana can create them reliably, last-[n]-weeks histograms would be nice for time, MB, revisions. (if people want something really fancy: Kernel density overlayed)

A colleague was pointing out that

Header: Haben Sie 3 Minuten Zeit für uns? (it really does not take longer than that)

We kindly ask you …

You're trying to import a file with the extension <extension name>. This file type is not allowed in this wiki.

Also, + 1 for active wording (e.g. "Sie können uns Ihre aktuelle Adresse auch mitteilen, wenn Sie keine Bescheinigung erhalten möchten."). Remember we want them to add their address even if they do not need a Zuwendungsbescheinigung.

I assumes it is form-language-standard, but yes, we should make this easier by getting rid of "optional".