Alias editing is under way in T216987. To not fall for recently discovered T219499 we should pick this story up soon.

Three UX specifications came in via figma comments - adding them here to make them searchable (verbatim @Hanna_Petruschat_WMDE):

• “when entering the alias field, a "new" line with placeholder text will be visible and in focus (a blinking cursor in this position)” (link)
• "as soon as the user starts typing, a new line appears under the currently typed in alias to allow to add another one" (link)
• “the new line can be reached by either pressing return, clicking/tapping on the line or using the arrow keys (this is possible on some mobile keyborads as well)” (link)

I went through this and thought about some possible edge cases and questions.

• What is the expected backspace behavior? Am I supposed to move to the line above if I press backspace in an empty alias input field? backspace can only remove one line, won't go over one alias
• Why arrow-keys for navigation? As far as I know the arrow keys on mobile (at least in iOS) function similar to tab / shift-tab and not as arrow keys. tab, not arrows! :)
• (already in the open questions) What do long aliases / line wrapping look like? solved. See open questions in the ticket.

Question

• should the initial bordered box behave like an actual input field or is it ok to just look like one (i.e. give it a border) part of T219997
• should there be two different input field placeholders - one saying "add another alias" given there are existing aliases, and another saying "add an alias" given there are none? it should always say "enter an alias"

Interpretations / assumptions

• alias editing happens in two stages: showing an "input" with pipes, then turns into the multi-line text field on click / touch / focus T219997 is a separate story
• we are not considering wrapping behavior of alias input fields for now

Leaving this here: https://vuejs.org/v2/guide/components.html#Using-v-model-on-Components

Updated the task description to have all acceptance criteria in there and not also mixed into the comments

updated again, removing the mentioning of placeholders, so there is no doubling with T217000: Show placeholders for label, description and alias

Hello @Hanna_Petruschat_WMDE,
one more question about the individual alias input element - given that the focus (blue border) is illustrated "one level up" from the individual alias (on the aliases), should the individual alias really not signal focus at all beyond containing the cursor? Outline comes to mind which, in some browsers (see chrome), is used with e.g. an orange color by default - depending on which browser they use, people may or may not be accustomed to it.
If there is no strong argument against it I'd like if we could - explicitly - add some visual indication. http://www.outlinenone.com/

Thanks

@Pablo-WMDE Thanks for the heads up. I totally agree to commit to this especially looking towards accessibility (tab and highlight...)

I'm not 100% sure what it would look like and if it has implications on the label and description being in focus as well? Would you have some way to screenshot an example?

Hello @Hanna_Petruschat_WMDE,

please find a screenshot of what chrome does by default in case of a sneak peek into alias editing. The aliases component has a blue border (as defined) because it has "focus within", the individual alias has the chrome default outline because it has actual focus. So far the individual alias focus style is not explicitly modeled. I advocate to a) explicitly model it [i.e. not leave it up to the browser] b) when modeling it to please consider the previous link.

Thanks

@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)

This will keep up with WCAG color contrast criteria and define the focus independent of browsers and so on.

One question regarding the screenshot: The input field is way narrower than the outline. Does the width automatically adjust to the content? In my understanding the input field should always be almost as wide as the outline surrounding the aliases.

@Lea_WMDE you might want to look at this as well.

@Hanna_Petruschat_WMDE I guess we can do that. The outline helped in bringing individual alias width challenge to light; cool. => T221219

Change 504896 had a related patch set uploaded (by Pablo Grass (WMDE); owner: Pablo Grass (WMDE)):
[wikibase/termbox@master] MonolingualFingerprintView: grow despite little content

https://gerrit.wikimedia.org/r/504896

Change 504896 merged by jenkins-bot:
[wikibase/termbox@master] MonolingualFingerprintView: grow despite little content

https://gerrit.wikimedia.org/r/504896

Change 506133 had a related patch set uploaded (by Jakob; owner: Jakob):
[mediawiki/extensions/Wikibase@master] Update termbox

https://gerrit.wikimedia.org/r/506133

Change 506133 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Update termbox

https://gerrit.wikimedia.org/r/506133

This can now be product tested under https://wikidata.beta.wmflabs.org/w/index.php?title=Item:Q11&useformat=mobile

@Hanna_Petruschat_WMDE thanks for reporting the missing feature yesterday. There was indeed an accident and our code got rolled back. It's there again, ready to be tested!

Hi @Jakob_WMDE
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.

1. the border of the alias fields are higher than the other entry fields, probably because there is padding between the entry fields and the outline indicating a fake field. Can we make it work that everything has the same size?
2. the borders of the entry fields should have a 2px border-radius
3. when hitting the x to cancel, the entries are being published. This is for all entry fields (label, descriptions, alias)
4. at breakpoint 3 (all entry fields next to each other), the entry fields are not aligned at the same heights. the description fields are 1 px lower.

I'm not a 100% sure if one of this is related to that ticket. If not, I'm more than happy to put this to done and copy/paste the above to a new "bug" ticket.

Update to the "publish when clicking cancel" issue: It only shows the entry directly after clicking cancel. When reloading, it's gone...

Change 506703 had a related patch set uploaded (by Jakob; owner: Jakob):
[wikibase/termbox@master] Fix input styles

https://gerrit.wikimedia.org/r/506703

Change 506703 merged by jenkins-bot:
[wikibase/termbox@master] Fix input styles

https://gerrit.wikimedia.org/r/506703

Change 507025 had a related patch set uploaded (by Jakob; owner: Jakob):
[mediawiki/extensions/Wikibase@master] Update termbox

https://gerrit.wikimedia.org/r/507025

Change 507025 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Update termbox

https://gerrit.wikimedia.org/r/507025

@Hanna_Petruschat_WMDE this can now be retested: https://wikidata.beta.wmflabs.org/w/index.php?title=Item:Q11&useformat=mobile

looks perfectly fine to me \o/

Interestingly enough, the OS adjusts some styling (see screenshot).
the label and description boxes haves inside shadows noe and the alias focus field has rounded corner inside the rounded corners of the outline. BUT I think this should not stall this task any further. There might be valid reasons to not totally kill any styling coming from the user(s OS).