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).
Thu, Feb 14
Tue, Feb 12
Mon, Feb 11
The specs for the "In more languages" Text are the following for
Thu, Feb 7
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.
Wed, Feb 6
Tue, Feb 5
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.
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.
Mon, Feb 4
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"
Wed, Jan 30
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.
Mon, Jan 21
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
Here is another spec file to support the styling. The rule of thumb for spacing of the text is: heights of the text plus 8 px, eg. for a one line text that means:
font: 24 px
plus 8 px
makes a text box of 32 px height
font is centered in that box
Nov 5 2018
I have two remarks:
From earlier discussions I thought this would not be possible. So I'm confused. Do I understand it right, that simultanious scrolling of two boxes without scrolling the whole window is indeed doable? And if so: I do not really see a huge benefit against keeping the original heights. Also: see comment to solution 2. What happens if there are changes in the beginning and the end of the paragraph. Will they be hidden then?
Oct 22 2018
Back to the original consern...
Oct 10 2018
Sep 27 2018
Sep 24 2018
Hier eine Alternative zum besseren Kontrast mit unterschiedlichen Auswahloptionen. Außerdem der Unterschied zwischen Arial und Montserrat (WMDE-Hausschrift). Ich fände es sehr sinnvoll, von Arial wegzukommen.
Sep 10 2018
I'm a little uncertain. On one hand I totally agree to keep the patterns from other widgets for the sake on consistency. nd for now we can go with this behavior.
BUT: This is a very different use case compared to the other ones we see in the linked tickets (Thanks Thiemo for gathering them and linking them here!) In this case the arrow is at the bottom of the field and will stay there when the box expanded. I would find it very confusing to click the arrow, scroll to the end of the box and see the arrow facing down again, now having the feeling there is still more to see. Clicking the arrow again would then collapse the box? Keeping the arrow in one direction is a common bahvior if the arrow itself is part of a header section and in the best case being made visible as active. This use case here is as explained above a slightly different one.
Yes, it should. It is greyed out in in this mock because the box is in edit mode. Still, thanks for your eagle eye.
Sep 6 2018
Thanks for pointing this out. These are very valid usability issues. I made a mock to adapt your suggestion to the current edit conflict layout in development. I'd appreciate your feedback if I understood your concerns right:
Aug 27 2018
The pulse is great.
The disappearing works as expected. One remark to the interaction though: When closing the popup, we enter the conflict handling page. If you don't know about the pulsating buttons it's relatively likely to not notice them or identify them as clickable. In a former version we had the behaviour of the first tour tip automatically being open when entering the page and when pressing "Okay, got it" being shifted to the next tour tip. Is that conciously being disabled?
Aug 16 2018
Here are svgs for the english and an example for arabic (as a RTL-version) for the tutorial pop up.
Jul 26 2018
I don't think we need an extra mock, but thats also up to the dev developing it. If required we can prepare something. Otherwise your linked exapmle is fine.
Jul 25 2018
In general I try to be consistent with the diff view as seen here:
Jun 13 2018
When checking/unchecking different filters (label, description, alias) the filter selection should always stay in place and not jump according to how much content is shown in the core list. Only the content is changing and therefor probably jumping. Ideally the filter selection should stick to the bottom part of the screen. In case the content between the termbox header and the filter selection is too few to fill the screen, the floating behaviour of the filter selection overrides the floating beaviour of the termbox header as the user is focused on that part of the screen.
e.g. if a user unchecks aliases and descriptions the header is pulled down with the collapsing core. If the user confirms tghe filter selection, the tab bar (with the filter confirmation button/tab and the show more languages tab) will stay in place and only the expanded section will collapse.
Jun 4 2018
May 27 2018
May 14 2018
Apr 26 2018
Apr 17 2018
I'm not certain on which page exactly you are right now. I assume you mean the "Cancel" button below the edit summary next to the "Import file" button? Then this "Cancel" button should end the importing process and presumingly bring the user back to where she/he start (back to the original file). If this is not what you meant I'd ask for a screenshot for clarification.
Apr 9 2018
This is a usual thing for MediaWiki input boxes—the direction of the wiki's content is forced on input boxes by default.
I guess this line made me think you're talking about Mediawiki in general not just the FileImporter in specific. I'm glad, it's not a general concern. Phew!
We'll take another look into the issue after figuring out how to handle the summary field.
I can adjust the size of the icons rather quickly-ish. How urgent do you think this is?
Apr 5 2018
Thanks for testing! Regarding the input fields I'm not sure I understand your issue described correctly. When I tried to reproduce it by changing the interface language to arabic, I found the placeholder in the search field in the following (as I assume correct) position:
@Lea_WMDE Is this the ticket we would bring back to the MVP?
Oh boy! Sorry! I'd say the priority is rather low to retouch it specifically.
Maybe some hope: We're currently setting up a structure to prevent things like that in the future...
Changed the text in the button from "Return to Original File" to "Return to original file". Only the first word is capitalized in buttons.