Lexeme Sense selection UI design exploration
I understand that Lexemes and sense are not exactly the same thing as words and definitions, permit me to use them interchangeably. When a word has multiple definitions and you want to find it, you will first of all think of the word then think of the definitions like in the dictionary. Also definitions/senses are phrases or sentences and not 1 word so it is going to be more difficult to search directly for them. As a result, a direct search for lexeme senses may not be the best experience.

A side note on Lexeme forms @DSmit-WMF : unlike senses, for forms one doesn't need to think of run before ran or running and since they are one word (instead of phrases) it can be searched for directly. So we can keep the currently Lexeme form implementation except there are specific use-cases that require a change.

Back to Lexeme senses. Searching for the lexeme before selecting a sense is a better approach. Here are the suggested design patterns to use for this (I created a live prototype using Codex components to try them out):

Idea 1 - Two-step selection	Idea 2 - Grouped Direct Selection
First select a lexeme, then choose from its available senses.	Search for a lexeme, the lexeme and its available senses are shown then you select a sense.

Analysis
Idea 2 has the advantage of a single selection but when you search for a word, often there a multiple lexemes that match same word. For example when you search for bank lexeme in Wikifunction you would see about 13 results that match this (shown in the first image below). In idea 2, this would mean that all the 13 lexemes and their corresponding senses would be shown on the list ( shown in the 2nd image below or the gif above). This is a lot of information that would be shown to the user at once. In idea 1, when searching for a lexeme (e.g. "bank"), you see 13 lexemes only and when searching for the senses, you see only the senses for the Lexeme you chose earlier.

Searching in Wikifunctions	Searching in Idea 2

Proposed solution - Idea 1
My proposal would be to go with Idea 1 as @DSmit-WMF suggested but make the lexeme sense dropdown always visible but disabled by default and enabled when the user selects a lexeme as shown in the first gif above. This is will enable the user understand the complete task scope upfront and know that they need to make two related selections.

Next step
Since most of you have already shown approval for idea one as Daphne proposed, I will go ahead with this. Next, I would explore some edge cases like how to deal with the languages of different senses.

Edge cases

lexeme does not have senses

Notify the user and still allow them to select it and if they do, show them the CTA to add to wikidata hyperlinked to the Lexeme page

@DSmit-WMF can we know before lexeme selection whether they have senses or not?

long or verbose sense texts

Normally we can truncate this but since they are not many senses that are very long and since it will be important to read the full sense description to make the right selection and if truncated the only way to do that would be to go to wikidata, I propose displaying it in full.
If a long sense is selected the dropdown is truncated to 1 line

Identical or Very Similar Sense Descriptions.

We would show them

suggestion show additional metadata:

• Sense ID or Wikidata link - This would be some what useful but it would be good to show only the necessary info needed to keep the UI simple

• Lexeme Has Many Senses (10/20+) - We would show them

• can we know before lexeme selection whether they have senses or not?: no , because you havent selected a lexeme. a sense belongs to a lexeme so you need to select a lexeme first. but that shouldnt be a problem right, we show the message afterwards?
• If a long sense is selected the dropdown is truncated to 1 line: have to see if thats possible in the codex component with css, otherwise we need to adjust codex

thank you!

Thanks a lot for the proposal @gonyeahialam

What would be your suggestion for Lexeme Sense component in view mode?

With lexemes, items, lexeme forms, and properties, because their label is one or a couple of words, the view is pretty simple, consisting on:

<wikidata icon> <label of the wikidata entity linked to its page>

For lexeme senses, is this enough?

Proposed design

Default view	1. Lexeme selection	2. lexeme sense
You have 2 input fields. One for Lexeme selection and the second for lexeme sense selection which is disabled by default and it is enabled when a lexeme is selected	You first select the lexeme	Select the lexeme sense
		If a lexeme has no senses the dropdown remains disabled and a message is shown informing the use of this with a link to the lexeme as a CTA

Edge cases

Lexeme Gloss language:
We show the lexeme senses gloss in the selected language of the page.
If a lexeme sense does not have a gloss in the page language we follow this fallback:

1. Gloss in language of page
2. Statement of the sense in language of the page (label: item description)
3. Gloss in another available language

long or verbose sense texts:
Display it in full.
If a long sense is selected the dropdown is truncated to 1 line

Identical or Very Similar Sense Descriptions:We would show them

Lexeme Has Many Senses (10/20+) : We would show them

View mode

For view mode would display Lexeme senses like this:

Lemma: Sense gloss in the language of the page (following the same fallbacks as above)

Out of scope

Lexeme ID and language
Many lexeme senses seem to have glosses only in a few languages and it is usually the first sense that has this, other senses hardly have glosses in a multiple languages and in some cases statements. With fallback 3, it is very likely that when you open a lexeme sense dropdown you will see senses in different languages. This situation makes it useful to have the language and lexeme sense number be specified to provide clarity.

Re Geno's question:

In view mode, I would take the lemma of the lexeme, followed by some delimiter (a long line -- or a :), followed by the gloss or the fallback (also when it's long).

This should happen quite rarely that we will see senses in view mode.

In T398801#11033610, @DVrandecic wrote:

Re Geno's question:

In view mode, I would take the lemma of the lexeme, followed by some delimiter (a long line -- or a :), followed by the gloss or the fallback (also when it's long).

This should happen quite rarely that we will see senses in view mode.

@DVrandecic any particular reason why you propose this format for the lexeme senses

run: move forward quickly on foot by alternately making a short jump off each foot

when other data like forms just show the form without the lexeme lemma

@gengh So For view mode would display Lexeme senses like this:

Lemma: Sense gloss in the language of the page (following the same fallbacks as above)

Regarding the question why include the lemma: because the sense can be outside the context of a Lexeme, in which case it would be very difficult to figure out what the sense refers to.