Fri, May 24
Hi @Pablo, sorry for the late reply. Also: I cannot really get this discussion to a farther point I asssume. If I look at the initial fonts on my machine, they appear all way heavier than the ones represented in the OOUI demos. I played around with the font weight to get to the numbers mentioned above. So maybe it's okay to not see a difference on your device?
Mon, May 20
Hi Jakob. Thanks a lot for the link. It mostly looks great. I have a few picky remarks.
@Pablo-WMDE Thanks for the input. I was under the assumption, that the input field will be in focus if there is no pop up. I remember discussing it earlier but I do not remember when and under which task. @Lea_WMDE Do you remember if there has been a concious decision made?
It probably does not make T205608: Floating button to collapse „All entered languages“ go away. The design may change, but the sticky element at the bottom of the screen should remain.
I wonder how that interacts with the focus of input fields. I would assume, that the first text input field is focused rather than the publish button?
Thu, May 16
Thu, May 2
looks perfectly fine to me \o/
Successfully tested and happy. \o/
Mon, Apr 29
Thanks @Pablo-WMDE. This is exactly what I was going for.
Fri, Apr 26
Update to the "publish when clicking cancel" issue: It only shows the entry directly after clicking cancel. When reloading, it's gone...
I tested and found some issues. Some are not 100% related to this task, but I'll note them all here to not forget them.
Apr 25 2019
Note to myself and you: What happens, if users do not check the accept line? Will the pop up be shown over and over again?
I believe that's what is currently happening on desktop, right?
Follow up question: Does this action need to be accompanied by a cookie pop up? Do we actually have stuff like that for Wikidata at all?
Apr 17 2019
@Pablo-WMDE I've the following suggestion:
Use the background highlight and define it like this
- have the background set to Accent90 (#EAF3FF)
- have the text entry in the focused input set to Base20 (#222)
I will check back with @Hanna_Petruschat_WMDE , but my vague memory tells me she was against newlines, and we wanted to have text wraps anyways, so sounds great to me.
Apr 16 2019
@Pablo-WMDE Thanks for the heads up. I totally agree to commit to this especially looking towards accessibility (tab and highlight...)
Apr 15 2019
Find the asset here. Color to be applied is Base 20. I'll update the description...
Apr 10 2019
Yes. That's right, @Tarrow. I try to move over to these "accent50" color codes step by step.
I adapted the task description regarding the font-family and the color.
I'm not sure what to think of the position block.
Nope. This is my missing ability to define this as needed in tech tongue (I was even googling a "correct" term and apparently didn't come across one)
Apr 8 2019
Apr 5 2019
Apr 1 2019
My 2 cents:
I like the borderless approach. Makes sense to keep the attraction at the content itself.
Feedback I got for the circular ! icon is it looks too similar to an info-i. I could see the stop sign icon showing the significance an error message needs.
Mar 19 2019
find the specs for Editing fields below:
- The input filed has the text heights plus 8px padding to each side
- it is depicte by a 1px inside border in Base50
- it has 2px radiuses
- between text fields we have 8px padding
- it contains placeholder text when no input exists (see specs for that in the parent task)
- the input field allows line breaks and adjusts in heights according to that
- the input field spans over the defined width of the "content" column
From a UX perspective that sounds wonderful!
Thanks @Pablo-WMDE for the summary. To add a little to the latter...
Mar 18 2019
Mar 15 2019
@Pablo-WMDE Thanks for looking into it. There are two things:
Question: what was the language (code) we tried to display in that row? mw.uls.getFrequentLanguageList() executed on this user's browser would make for an interesting read - any chance to get to this?
Mar 14 2019
to get a better understanding I could see things work like the following examples
the edit pen could behave like the "Spenden" button on the right side: 1. fixed position, 2. scroll and stick/float, 3. scroll out
Mar 13 2019
Does the current termbox always has a focused form field? Therefore will there always be the possibility to cancel by pressing esc?
And for the sake of consistency: If this is a common action to use, I would keep it. I don't see an obvious reason to not have this as "a feature".
I would go with one growing text field, no matter if this is a line or an actual field aka a box. This makes it clear that we are talking about one thing while a lot of lines would make the destinction harder to figure out where an element starts and where it ends...
Hi @Volker_E. Thanks a lot for building up on the earlier mocks. My two cents:
- Checking Color Contrast I think we might be in muddy waters by putting red50 on red90.
- This also applies to the yellow icon on fff background unfortunately.
Mar 6 2019
Feb 28 2019
As just discussed, here are the adjusted icons:
Feb 27 2019
Feb 26 2019
Thanks @Jakob_WMDE! Looks goood...
I checked of the "no hacks"-acceptance criteria as well.
Feb 18 2019
Thanks for sharing. I've one tiny remark, which will make a difference in the future, when more interactive elements will be introduced:
Could you please adjust the minimum width of the content box from 260px (current) to 244px (as defined).
Feb 14 2019
Feb 12 2019
Feb 11 2019
The specs for the "In more languages" Text are the following for
Feb 7 2019
Agreed. I created an extra ticket to cover that issue. You can find it here T215538
Ah, thnaks for pointing out the other two tickets.
Sorry, I tested in English, apparently it does what it's supposed to do in German...
@Jakob_WMDE Currently if js is disabled, you only see the devider with "In other languages" but no entries at all. Shouldn't this section be expanded? Otherwise there would be no need for this, right?
Thanks for the Update. I found one functional remark, one question and two minor style notes.
Feb 6 2019
Feb 5 2019
Regarding the icon size: The specs for the icons are meant to go along with the base text size of 1 em (eg 16 px). The base font size at wikidata is only 0.85 em (14 px) which is why the icons look too big.
Based on the feedback of the heaviness and an unclear reading of the lightbulb, my suggestion for the "Suggestion constraint" would be a flag. A flag only highlights a fact conveniently enough it is already in the OOUI collection. I adapted the icon to be an outline icon and therefor be a bit more subtle, similar to the existing ones.
I also adjusted the "potential issue"/exclamation mark to slowly adapt to the notice icon from the OOUI collection. The mandatory-icon should remain as is.
Feb 4 2019
Feel free to open if I falsely merged this. For me that seemed to cover the same as "T214898: Adjust termbox break points to minerva skin breakpoints"
Jan 30 2019
Please check the Figma File. I updated the specs on how things should behave in the comments underneath the screens. Simplification regarding transition was part of it. The transluscent mocks are old ones and no longer to be considerable but still there for orientation.
Jan 21 2019
Just to clarify:
Dec 20 2018
Dec 19 2018
Dec 10 2018
Nov 22 2018
It was said in the story time yesterday, that a ticket should in the best case cover js and non js and not have completely diffeent requirements for the two . Please correct me if I'm wrong @Pablo-WMDE