Match exercise layout

[merleschoen]

The containers of the L2 and L1 words are now centered along the main axis to prevent the layout jumping when clicking words. I've also added hyphenation, so long L2 words aren't cut off.

[mircealungu]

Nice! It does not jump around anymore.

But now it is too crowded on mobile :(

I wonder what could be a solution for that?

Maybe don't show the buttons while the solution is being constructed?

And then only show them once the whole solution is revealed:

Alternatively, when the solution is revealed we could be using the same rendering component from the History? More compact, and easier to review?

[tfnribeiro]

I also observed the same as Mircea:

As Mircea suggested, I think I would just add the Edit/Listen buttons onto a new line, to avoid the word getting squished, especially in smaller screens. That would already help quite a bit.

If then there is still over-wrapping with long words, maybe we can add a class that scales the font somewhat in smaller screens for words > 7 characters or so. I think introducing a "Solution view" like the Word lists might be too much of a change from the previous layout, so I don't like it as much.

Another thing might be to compress the vertical space just a little bit and to center the solution words with their counterparts. Currently, it seems they are slightly mis-aligned (not sure if this is easy), but just an observation.

[merleschoen]

Ah, shoot! You are right, we can't have that. I like Mircea's first solution the most, it seems more intuitive. I'll try to implement that and send a new pull request your way once it's done. Thank you for your suggestions!

[netlify[bot]]

✅ Deploy Preview for voluble-nougat-015dd1 ready!

Name	Link
🔨 Latest commit	7209ac404124c27eacc2b37286638e633157aca6
🔍 Latest deploy log	https://app.netlify.com/sites/voluble-nougat-015dd1/deploys/65e7688850cd7700087e5b20
😎 Deploy Preview	https://deploy-preview-305--voluble-nougat-015dd1.netlify.app/
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[mircealungu]

they still jump :( and the final result is also too busy.

do you have any other ideas @tfnribeiro @merleschoen ?

[mircealungu]

@merleschoen - do we still need this PR? Or is this also fixed in the big PR with all the exercises and we should close it? It makes me unhappy to see it open for such a long time :)

[merleschoen]

Unfortunately, I haven't found a good a solution for this problem yet, so it is not included in the new PR.

[mircealungu]

Unfortunately, I haven't found a good a solution for this problem yet, so it is not included in the new PR.

ok, let's think about it also also @tfnribeiro and see if we find a solution.

Maybe for now, the simplest thing would be to not show the speaker, nor the edit button. And we can make the words on the LHS underlined as a suggestion for them being clickable? Then we do the speech on click.

And this approach would make sense for the other exercises too: makes the UI much less cluttered too. One other example (where I also transformed the Edit icon into a text link at the bottom) -- which might even be more understandable too. (Also the example here speaks for the importance of the Edit translation link...)

What do you think?

[tfnribeiro]

Overall, I do like the suggestion! We could add a little speaker icon, if we really want to make it clear that the user can click it. The only downside is that you can't edit words, but I am not sure if users do use that feature? Have you ever looked into that?

My suggestion would be that we just use the visibility CSS option, which means that the objects would be present in the layout, just not shown. this way it shouldn't jump when they are triggered because the flex container needs to move. I can see the code is a big conditional so I have to take a bit of time to visualize it, but I think it could work as well.

[mircealungu]

Overall, I do like the suggestion! We could add a little speaker icon, if we really want to make it clear that the user can click it. The only downside is that you can't edit words, but I am not sure if users do use that feature? Have you ever looked into that?

I see also another opportunity here, and that is, to unify this behavior also across the reader. Indeed, with Danish, it happened multiple times for me that I wanted to listen to the pronunciation of a word again, and then the only way to do it was to "untranslate it" and then translate it again. And that feels stupid.

If we visually separate the word and the translation as in the figure below (right) then we can implement the same thing:

• you click on the underlined word we pronounce it again (and again)
• you click on the translation we show the drop-down alternatives menu

Note that it also has the added benefit that it's more readable.

[merleschoen]

I like the idea of decluttering the UI a bit. Underlining a word for the pronunciation is maybe not as intuitive as a speaker button, but I think users will pretty quickly learn it.

One issue with moving the Edit Translation to the bottom actions is that it wouldn't be clear which word would be edited if we have an exercise with multiple bookmarks. Does it make sense to use the same dropdown pattern we are using in the reader for editing, basically unifying all the behavior? Or maybe that is what you are already suggesting, @mircealungu?

@tfnribeiro I did try using CSS visibility. It solves the issue of the jumping, but you potentially end up with really long word containers, essentially cutting words off.

[tfnribeiro]

To add to the discussion, at least in the reader when you click on the word, the UI does say that it will translate + pronounce the word, if you click again I guess there is an expectation of repeating the behaviour. I did see some users from my experiment, deselecting some translations that they weren't so interesting, so maybe the more important behaviour might be to allow to deselect words, maybe with a long click/touch?

Regarding editing, I have always wondered to what extent this feature makes sense besides using it when you get a translation in the text. I feel like at exercise time we shouldn't worry too much about editing, and maybe just leave that in the Words page if a user realizes something is off? Or maybe when they go to feedback, give them the option of changing the translation? I think the benefits of the UI simplification outweighs the functionality benefits.

[merleschoen]

@tfnribeiro That is a very valid point. I did that for a long time until I realized that clicking the word again doesn't actually remove the translation 😅

[mircealungu]

One issue with moving the Edit Translation to the bottom actions is that it wouldn't be clear which word would be edited if we have an exercise with multiple bookmarks. Does it make sense to use the same dropdown pattern we are using in the reader for editing, basically unifying all the behavior? Or maybe that is what you are already suggesting, @mircealungu?

Super good question, and super good idea. We could definitely use the same dropdown pattern for editing. I don't expect that to be a frequent use case so even if it's a bit more complicated, it's fine. One other alternative would be to only show the edit buttons near the words after selecting that bottom "Edit Translation". This might actually be the simplest implementation. One more state: "translationsEditable". When it's clicked, the edit button near each word is shown. They jump around, we don't care. This should still be a very rare event, and the jumping around is triggered by a user action, so it is less surprising/upsetting.

[mircealungu]

we should restart this discussion at some point @merleschoen @tfnribeiro :)

[merleschoen]

I've been playing around with the Match exercise and came up with a possible solution that avoids both the jumping and the unpleasant situation where words are cut off on a phone screen:

I was thinking we could reuse the dropdown we are using in the reader and put the editing und pronunciation there. I haven't really figured out the final design/styling of the dropdown yet, but I'd also like to hear your opinion on this first @mircealungu @tfnribeiro

[mircealungu]

It looks discrete @merleschoen but I can not run it because the branch started too far back in the history of the master and it has merge conflicts. I tried to rebase, but I can not solve the merge conflicts because I can not understand this exercise. We should burn it with fire and rewrite it from scratch!

Or

1. one of you @merleschoen and @tfnribeiro can merge the conflicts in MatchInput
2. you close this PR and create a new branch from master where you reapply your changs.

[merleschoen]

Oi, sorry for the confusion! I have started a new branch from master, but I haven't actually pushed anything yet. I still need to figure out how to make the actual dropdown look nice. I just wanted to know your opinion on the general idea before I spend too much time on it :)

And yes, we should burn the Match exercise with fire.

[mircealungu]

Oi, sorry for the confusion! I have started a new branch from master, but I haven't actually pushed anything yet. I still need to figure out how to make the actual dropdown look nice. I just wanted to know your opinion on the general idea before I spend too much time on it :)

And yes, we should burn the Match exercise with fire.

Regarding the look - it is a bit different than what we have elsewhere...

I wonder what's hidden below the little arrow: pronunciation and edit I guess? I would propose that pronunciation becomes underline, as it's now in the reader (did you see it? you can click as much as you like on a word :)) and for the edit it can just appear once the solution is shown maybe?

[mircealungu]

@merleschoen - given that you've started working on this on a new branch, i'll close this for now.