@Verena @Cirdan : We have two choices here – one is going with the Wikimedia Design Style, the other is using the Wikimedia Deutschland e.V. Styleguide. The advantage of the former is that is is made to be used in a digital context, whereas the Wikimedia e.V. is stronger in print application. We could also try to mimic the campagins, but they change(d) style over time a bit and are also specific – maybe someone else wants to adapt the tool, too and then the campaign colors do not make sense – so I would suggest going with the Wikimedia Design Style

I would see the suggestions mainly as a way to understand how the tool works – it is highly unlikely that a suggestion matches a special interest of the user (particularly for long, detailed category names). Thus, it is not essential to have a full name. We could either discard too-long-categories or we shorten them with an ellipsis (max-width and text-overflow: ellipsis; ). Bonus, if the title attribute has the full name, still, since it appears on hover in browsers.

What is meaningful to track depends on our concerns. I assume for now, it is

I like the idea. I would not do this via color due to accessibility and style reasons (quickly looks "too confetti"). The most solid seems for me to just add "schwierig:" or "einfach:" in front of the badges – something like this:

I think we should have a search button, either "search"/"suchen" or a magnifing glass-icon.

As for now, I would attach the * to the labels for required fields, even if that is a problem for the "placeholder-labels" in the new skin.

If we want people to use the form we should make it as easy as possible to use it. Thus we should have as few mandatory inputs as possible. It depends on the way such requests are managed which data is essential.

I would not put email in the "anonymous" part, since it is a "hacky" solution and thus hard to maintain and redesign in the future

I second Charlie here but want to highlight that the labels are indeed quite long due to their "Nominalstil". Kai’s change is in my opinion in the right direction, but it should actually be a UX, or better, a writer's job to go over the texts and make them terse and graspable.

Thanks! What I could use for the specs/design example is the linked coodepen which Pau created 4 years ago and on which I build a slight color change as suggested by you in the ticket comment.

@Volker_E Did the "moving dots" from T165286 get added to OOUI or component-ized otherwise?
I want to avoid to create another animation most likely not exactly able matching T165286.

I briefly talked to @gabriel-wmde. For the entry field, it would make sense design and code wise if the custom €-being-inserted-directly-after-number would be used and be consistent between the var/ctrl.

In our recent usability tests, we used this:

is it the case that the opt in page was always the same, in every campaign? Your posting of only two different solutions somehow implies that they were always the same?

So the outcome is: It is likely that there were not changes except for the opt-in.

@GoranSMilovanovic Thanks, I think it is fine how it is :)

@Jan_Dittrich what should it look like if there’s a line break in one of the labels?

@kai.nissen mentioned that non-DE-IBAN users would not get their BIC reflected.

CSS spec:

related: T89243

Is this online somewhere? Just I case I or some other dev might have an awesome idea :-) (Not a must, just in case it seems to be a good idea-exchange-thing)

Indeed, the frame is a bit tricky: It is not the same design as the text around it. That "almost like" is a problem (Think of a logo that looks "almost like Mercedes’ ")

A high-level-ish take on this:

• Currently many items have no citation and while it would be nice to have one for every item, it seems that people focus on the most pressing first. As I got told in user research interviews e.g. "date of death" should always be sourced, particularly if concerning a recent date. I assume that other (implicit?) rules exist for other properties too (And if you know more rules that seem to be de-facto-standard, please send me a message)
• This means that a general "all things need citation" would not work.

AND

• As in T195052 suggested, a constraint based on "especially the ones likely to be challenged," might make sense.

AND

• Since citation or not might depend on the context and modeling, I guess a "citation needed"-ish thing, like a "reference-tag"+comment or so (I know, if at all, it is future stuff) since it could reflect the reasoning of people editing and reading.

I would suggest using bar charts like this (but nicer designed):

I can suggest two solutions:

Relevant Research:

I created some inital designs

Shall we branch off the DSGVO-link discussion in a separate ticket?

Sorry – that got quite stuck. Let's sync on this in person in the next days and get it going again.

I would strongly suggest not to put it there (unless DSGVO related requirements require us to do so).

@kai.nissen: Is this the structure they come in usually? Aka if I or someone else™ writes a script to give it structure and proper data types is this an investment in the future?

To make mail and address independent, I treated them as separate sub-sections

Oha, that is a lot. It is 2MB zipped, and 20MB unzipped and it brings my spreadsheet down. Time for fancy tools… (oh no, GGobi is stuck, Jamovi too. Looks like a job for R…)

please elaborate – from my point of view ideally based on:

please elaborate – from my point of view ideally based on:

please elaborate – from my point of view ideally based on:

You you mean FAIR as defined in The FAIR Guiding Principles for scientific data management and stewardship ?

please elaborate – from my point of view ideally based on:

please elaborate – from my point of view ideally based on:

My stance is the following:

Here is my suggestion.

Are you referring to the examples on https://query.wikidata.org/ ?

Thanks for your suggestion. To consider your needs in future developments, it would be helpful to get some more context in the ticket. My understanding is, that currently, federated queries are possible via SPARQL-syntax, but not via an interface. Is there an interface you refer to (e.g. https://query.wikidata.org/ ?) Or are you referring to a possible future product?

Thanks for your suggestion. To consider your needs in future developments, it would be helpful to get some more context in the ticket. My understanding is, that sometimes you want to query a single instance, sometimes the ingle instance including federated instances. Could you give an example for these two situations?

@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.