Thu, Nov 22
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.
Apr 3 2018
Mar 27 2018
Mar 26 2018
Superb! Thanks a lot!
Mar 22 2018
Thanks for the very valid and helpful suggestions. I updated the mock in the task description which now has improved messages as well.
I updated the Mock in the task description to the current version. Please be aware to change the text in the red message box regarding the error messages collected in T189570.
Mar 17 2018
So, this is a version working for 16:9. As said before, you would need to open the svg in some kind of application like inkscape, then delete the text and add the text you want insert. The typeface is called Lato (the official typeface regarding the styleguide of the Foundation for the mobile app; it's free to download).
Mar 12 2018
Feb 26 2018
Will be handled as part of the current term box redesign/restructering in T180368.
Feb 19 2018
Hi @Volker_E! Thanks for the feedback. I'll comment in line:
Feb 15 2018
Here's a kinda final diagram. Please check if there are any mistakes in it. I'll change it to an editable file when it's ready to go from your side, so you can change text, colors and so on...
Feb 14 2018
Feb 12 2018
Sorry for the confusion. If I remeber right, this note was meant for the tutorial overlay, not for the tour we introduce here. To clarify:
- The popups should show up, one after the other (This also helps prevent overlapping). This is also meant for now (the MVP). I think later on, we might introduce the glowing blue points
- the first popup opens automatically after the introductional overlay was exited.
- If one popup gets closed, the next one should open up automatically
- To prevent the user from being scared of hundred more popups to come, we show the "n/3" next to the headline.
Here is the image for the overlay
- in small size
Feb 5 2018
Feb 1 2018
Here is the doc
Jan 31 2018
Thanks for the insights. At the moment this is not an urgent task. We will get more insights in the upcoming user tests and may have more clearance on this topic afterwards.
This came up, because in the user testing we did with unexperienced users, most of them expected some kind of button to "transfer" text from one side to the other. Some of them then used the ctrl+c / ctrl+v feature, but they were insecure about doing so.