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.
Oct 16 2019
So, if I understand correctly, the banner would:
- start with a the usual vertical, right-hand-form
- on making the browser smaller, switch to the full-width form
- 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 :)
Oct 15 2019
As for getting the relation of clicks:
Oct 14 2019
Oct 9 2019
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?
Oct 2 2019
Sep 30 2019
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.
Sep 18 2019
I added the mock. I can add the spec details if it helps, but I would just pick them via dev tools from the constraint violation popper, too, so I guess me writing them here is more tedious and more error prone. If not, just tell me.
Sep 12 2019
Sep 10 2019
Sep 5 2019
Do we know if people made their Kommentar öffentlich? If yes, we could just have
Sep 3 2019
Sep 2 2019
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.
Aug 30 2019
it should be
Aug 29 2019
@raja_wmde here the discussion so far.
Aug 27 2019
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.
see above the corresponding form in the figma sub-document "flow"
afaic "Addressangabe" is the postal, physical address. Mail is treated separately.
IMHO we could improve the accordion behaviors regarding left-padding and borders…
Aug 23 2019
Aug 22 2019
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?
Aug 21 2019
Aug 15 2019
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.
Aug 1 2019
Worth mentioning that the resulting package will be, in contrast to the APIs which stable interface policy notoriously applies to, versioned.
Jul 31 2019
Isn't that confusing in case their server is slow or something?
This is the mockup: (sorry, was a bit hidden)
Jul 29 2019
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.