Thanks for listing it @thiemowmde . The feature doc can be found here:

Thanks @JStrodt_WMDE for the proposal.

for a quick fix I would suggest to set the color of the disabled edit pen to Base50 (#a2a9b1). No matter which way we choose we always violate the style guide (Base30) or code suggestions (0.51). Our interaction pattern just doesn't fit in the use cases they consider, but I would not like to make it a necessary change for this task.

@thiemowmde Thanks a lot!

@thiemowmde Thanks for the investigation.

Nice!! Thanks Thiemo. And yes, you're eagle eyes are absolutely correct about the 2px radius. The box shall have it too

The mocks in the tickets show both options in terms of something above and all the text in between but the middle column is always the same width. I understand the concern of having a wider middle column but this will also allow for potential longer words in other languages without needing hyphenates.

pinging @JStrodt_WMDE @WMDE-Fisch and @thiemowmde to clarify that the text not being shown was a concious or not so concious decision? It seems to made specific in the code and I can't recall if not showing the text at each paragraph has a specific reason.

... but we only display once at the top.

I thought that was a mistake with an unintentional space before the page number. I would not leave this there. It's not clear what it should mean in my opinion and is definitely not obvious enough for an indentation. I also think, we don't need it.

We already designed a version for that when we planned the whole new UI. Here is a mock up

Closed as we are not able to repsorduce this issue anymore.

Do you think it would make sense to close the ticket then? If we cannot reproduce it, we might just have solved it during the past 1.5 years. If this will be an issue for someone else in the future, I would hope they'd let us know so we could look into it with some more background.

Do we know any background on this? Was it only one user asking for this setting or multiple ones? I would like to have UX conduct a bit of desktop research on issues like that in case we decide to pick this up. keywords: warning messages when discarding changes. I would believe there are differences between apple and android users for example. Also: I shere a way to get the warning back in case I would like to have that?

Are we following any standards here, e.g. using the color of OOUI (is this even used in monospace?). If this is a general problem, that is reproduced through our feature I would claim to not change anything but rather push for a global change of this issue then. If it is a problem that only occurs in our feature because we used different colors, then let's change it to a more accessible setup.

I couldn't duplicate this issue anymore and therefore put this task as resolved. Re-open if this still exists and specify the conditions of this happening, please.

After talking to engineers we decided to close this ticket for now.

@MichaelSchoenitzer Could you specify which text behaves how aka which text block is not affected by the user settings? I think it would help to see if we can somehow adapt this. If people enlarged their font size due to bad vision I would like them to see a fitting font size in allplaces of the interface.

Thanks for the investigation @thiemowmde . I believe there has been some concious decision made for choosing the arrow over the "x". But as the feature behaves now having the pop up warning that everything will be set back to the state when the edit conflict happened does actually allow to replace the arrow by an "x" to indicate a closing of this edit box.

rom what I can see in T237529 the numbers asked for here are already covered. So I'm closing this one.

Can one of the engineers please check if we chose the OOUI icons here and if they both have the same color? @WMDE-Fisch @awight @thiemowmde

I merged the two tickets. They are not the same, but follow a common wish which is not to loose your entries, when getting into the edit conflict.

I'll check the color of the icon and investigate if the edit pen needs to remain or can go away.

This ticket can serve as input for how to handle the discussion flow.

This should be considered and tested so I'll put it to before default.

I think it could still be of value, not only for the current version but also for the discussion pages and even other features so I would like to keep it in the backlog.

This refers to a prototype which is now outdated by the beta feature.

This issue has been solved by doing as the screenshot shows.

The mobile version of the termbox has some solution for that. I think it could be a good step into aligning mobile and desktop by picking up on that solution (see screenshot below).

This is interesting (especially the linked ticket with the overlap of the Q-Number).
Is there a way to mirror the changes made, in this instance add the label to the icon?
On mobile screens the label disappears again and only shows the icon, so it seems to be very similar to what we've done.

I just talked to Charlie and Sarai, but give a quick insight on the reasoning of the box shadow for termbox. There indeed is no box shadow in the OOUI doc, but if you look at the progressbar in use, then you'll notice one. From a design perspective that makes sense as otherwise the grey outline of the progress bar could be confusedwith something from under the white overlay. If you figured 3px in Termbox and maybe 2px in OOUI I wont discuss on the pixel. I think it's important to have it aligned in production. If that means taing away a pixel from termbox. Do it.

Sweet! Thanks. Looks all good to me now! \o/

I saw that as well already but am hoping that these gaps are filled little by little rather than making things more complicated on our side by trying to hide one of these buttons if there is no entry at all.

After reviewing it again I figured that it would be more consistent to use the same interaction behaviour as for the edit conflict. That means:

• we are showing a pop up the first time this special edit conflict happens.
• The pop up gives an explanation on what is happening.
• The user can click "Ok" and optionally set a checkmark to the "never show this again" option.
• After closing the pop up it only shows the preview and the option to swith to the "general edit conflict resolution page"

This means, the mock above is outdated. I'm working on creating a new one. The new one will not show the explanatory text and illustration but only a short intro to the situation and then directly the proposed resolution in a preview.

Thanks for the update, @alaa_wmde . I'm afraid the vertical spacing is still not fixed. There is no padding between the last alias of a fingerprint and the following toggle button.
And I can't find the right ticket for this so I comment here: The background of the textboxes is still transparent instead of white.

Let's talk about this one on Monday in person, I don't think I get the issue yet. Unless you are referring to the vertical spacing maybe? for which there's a fix in code-review atm.

You are totally right. This was referring to the vertical spacing. Sorry for the confusion.!

No apologies needed @alaa_wmde
I just like to explain UX decisions so everyone following or stumbling upon this task later has the chance to understand. Thanks for adding it to the AC!

I just discovered, that in the real mobile Wikidata the styling of the section "in more languages" already happened but also causes that this section cannot be expanded. See screenshot below.

@alaa_wmde I would really like to add the "jumping back to the termbox" after collapsing "all entered languages" by clicking on the lower "fewer languages" button as an AC. Otherwise the meaning of the lower button is redundant as it is meant to keep the user from endless scrolling.

Cool. Thanks a lot @alaa_wmde

Hi @alaa_wmde! Thaks for bringing this forward. I have a small remark. In the screenshot, the whole width of the categories have a background color, including the so called interaction column. In the mock up above you can see that the right side has a white strip. This will be important when the edit button will become a sticky button. It kinda gives the termbox editability a frame. To better understand the structure of the page, I put in a mock here.

Hi @thiemowmde, Could you provide a screenshot of the site you're talking about. I'm not certain in which state this comes up und therefore it's hard to make a valid suggestion. Thanks!

I agree to Raja. I would also choose option 1 as soon as both is out of beta. And then have the two options underneath each other, so the difference is clear.
I cannot see any other dependencies as of now.

Thanks for pointing it out. It definitely looks like it has been implemented incorrectly. I would vote to keep the dots and highlight the bars in a darker grey as well. As the second screenshot with brackt shows, it would be possible to only select one revision which is not really possible, afaik.
I'm happy to look at it together if you like. I'm currently sitting right outside the Rotundan hall at the "I {{}} templates" table.

@Aklapper Thanks for the heads up, sorry for the spam. In the very hidden corner of my brain this shows the unsuccesful attempt of using phabricator as a task manager for individual tasks. Hence: I'll delete it.

@Lea_WMDE I think it is fine. As the error message is that broad and the variations of errors very broad I guess we cannot get any more specific or give further instructions, warnings etc.

Tested. Looks fine! Now really looking forward for the error message.

Thanks! Is there a way to produce a failed publish action? @Tarrow (as Jakob is not available)

Sorry for the long wait but finally \o/

@Pablo-WMDE thanks for documenting this! I was going a bit further with it, trying to create a new account as well. Here is what happened:

1. click "edit pen"
2. click "Create an Account" in the overlay
3. create an account page in desktop version opens
4. created an account
5. get redirected to the item page I came from (now also in desktop version)
6. switch to mobile by clicking the "mobile version" link
7. checking, if I'm still logged in (I'm not)

Regarding the notice: When logging in I got redirected to the desktop version and needed to switch back to mobile. When doing so, I also got the the notice. I could click it away but got it back when reloading as it stated. @Pablo-WMDE if you like, you can test and reproduce on my machine.

I agree @Pablo-WMDE

I "messed up" with the IP overlay, not being aware that every other overlay in the Wikiworld works with 50% white and not with 25% black as I initially specified. So we might want to adapt to the white version here and make this small change in the IP and license overlay as well. I post it as a comment an will raise this question in the next team meeting (daily or sprint start?).

@Tarrow Thanks for the write up!
One more suggestion: Assuming that no one likes to see an error message and we already know, that hitting publish again could solve the issue: Could we automatically hit publish again in the background when we didn't hear back from the server and only if it doesn't work after 3 tries we then let the user know that unfortunately they have to reload because we didn't manage?

Checking back with other UX peeps I'd suggest having the tab set to the element before the CTA so you would only be one keyboard hit away from focussing it but not distract users by visual differences which are not made use of anywhere elyse.

Hi @Pablo-WMDE , 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?

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?

Agreed