No nested menus or extra clicks for submissions comments or suggestion buttons

[comradekingu]

Original

Buttons Buttons are now the same for all fuctions. One concept employed for a range of things. Two fields was meant to save time when doing a translation and then commenting that.

[dwaynebailey]

@comradekingu a little history about this decision might help and might help you think of solutions.

Some rationale:

1. Only show what users can action
2. Show what is needed now

At play. The user is translating, they're likely to want to keep translating. So one uncluttered button. This means also that if they want to suggest from the keyboard its still the exact same keystroke to submit a suggestion.

It does lead to multiple keystrokes, yes. However, someone always suggesting has that button exposed all the time, not a choice they need to make about which button. Someone translating is very infrequently making a suggestion.

Someone adding a translator comment is doing that very infrequently (maybe because we make it hard). Looking at PO files its very very low occurrence of adding these comments. So we're dedicating quite a bit of translation space to something we mostly never using :(

But suggest, like with the last one, if you can try PR these changes and then actually look at them at work in the real world.

[comradekingu]

While fewer, suggestions are very helpful. To the point where having more of them, is to the benefit of user and project alike. Their functionality gauged against submitting translations is though not mutually regressive.

Given a use-case of always suggesting, even then it should be a separate hotkey, lightening the load on actual use, which is predominantly a mixture of both.

It can't be so infrequent that it is always, because those aren't the people doing it. Unless there is a suggester-class of privilege. And for case of argument, they shouldn't have a button for submitting translations anyhow. If only sending suggestions otherwise, I would argue it is done by seasoned translators only. Where it is still subordinate to mixed contributions, and as a whole, a system to the detriment of novices over an expert use-case.

When the default hotkey for submitting anything right now is Ctrl+Enter, you are actually saving nothing over doing nothing. Tab+Space, Tab+Return or Tab+Enter does the exact same thing, and in doing so, is not exclusive to pootle.

For mousing over and clicking, with my suggestion that would be the required course of action to make the suggestion. It has the added benefit of not encouraging the idiosyncrasy of mousing over to change mode, panning back again to write something, and then hurdling over to submit the suggestion.

Whereas with the current implementation, not only is it an additional click, and then having to Ctrl+Tab or mouse back to "Send in", there is also the burden of switching it back for when the translation continues. At which point of course stopping the whole process entirely is likely.

Not only that, what you are presented with when clicking the toggle-switch is a field that says "send in", which actually just toggles you back to translation-mode. There is no need to teach or learn this counter-intuitive behaviour, unless you are using or making vim. Which is not the goal, nor a tangible approach to attracting a user-base of neurotypicals.

It is hard to do both, translating and suggesting, even with my approach, as one would do marking things as fuzzy, going with the best guess, and leaving the other as a suggestion. That could however be solved by having three fields, which is where one can start to argue over diminishing reward.

The only thing you could potentially save, (less clutter for a potential suggestor-class), could be achieved onto itself just as easily by taking said functionality away. This teaches the most novice user a different system at the beginning of their foray into pootle, when it is not incomprehensible to go the full route right away. It also begs the question of what the old systems brings over the new?

Commenting, is right now always what is for the current method of suggesting, the worst case scenario of clicking back and forth described above.

So by doing separate buttons, none of which are dangerous to press, functional simplicity is gained. It is the exact same amount of buttons, and the same steps to carry out three distinct ways of doing the same thing, are the same across the board.

Having one unfettered button, stops being a point of argument once there are two others. Not making them buttons, is only making them less functional, but albeit still (dual-issue) buttons.

I would say that maybe "submit" was not a reasonable choice for what the green button should read, over what I think is originally, or at-least in translation: "send in". It encourages the same non-functional behaviour of clicking that button, for when one wants to submit something another button does. "Translate" would work to this (non-dead) end.

Rationale

1. Only show what users can action

This is the point to be made, rather than hiding it away. Only under the assumption that users are at the peril of not, prevented from, or always wanting to make a direct translation, is the current scheme preferable.

1. Show what is needed now Same as the above.

[dwaynebailey]

@comradekingu lets pause a bit. I honestly think this is a massive UI change. I'm not seeing the benefit particularly since this is a mockup not a PR. So nobody can test and demonstrate, rather we're all just discussing and we won't get very far.

I do honestly think there are simpler UI changes that can make it into Pootle quickly, choosing the one we struggled with the most in terms of design is one way to ensure we don't land anything.

So can we please try focus on something simple first? Lets see a PR related to a simple one and we are then able to guide you to stage a PR on our infrastructure for real click review.

Less talk, more clicking and seeing and quick landing of changes.

[comradekingu]

Row of buttons Buttons are now ordered by importance. Fuzzy strings in red available in UI, reflects "Assert"-button. Suggestions in yellow, reflecting "Suggestions"-button

• What to label the buttons is an area of uncertainty

[dwaynebailey]

@comradekingu quick response to latest example:

• What is Assert?
• How do you mark something fuzzy and know that that is only relevant to Translation?
• Why is Comment next to the textarea that has nothing to do with commenting?

[comradekingu]

Good questions, we are on the same page.

• A level of assuredness lower than ascertain. "Assume" would perhaps work. -You wouldn't know, unless reading the mouseover. Contextualizing "marking something fuzzy" is tricky.
• It follows a natural level of commitment. Also has a "Yes, no, maybe, other" flow to it.

Submit ✓ - (save, confirm) Translates, or reviews Assert 😕 - (assume, claim) Leaves a translation left for someone else to fix, or brings into question. Suggest ? - A mere guide for someone to follow when trying to translate Comment 💬 - Leave a piece of text behind, to talk to others.

Save is used on other platforms for ✓, confirm for would work if trying to review what someone else has done. There is a translated string, you confirm it, now it is reviewed👍 . Similarly, if there is a translated string, making a claim against it by pressing "assert" would fuzzify it. Then you comment to explain why.

Edit: I dressed it up a bit Visual languages

Flags now adorn the different languages String number is now on the left Saved a lot of space by doing the wiki, bug and copy pictograms inline Lines are much closer together for additional savings Dotted lines are gone

[comradekingu]

Trail of thought

1. Background is now gray
2. String number and location is now inline with source string
3. Terminology lines up with translation field
4. Terminology is ordered in a list
5. All languages condenced to save space, language name has space available for name of longest language
6. Action pictograms, wiki, bug and copy, are inline with languages to save space
7. No dotted lines anywhere

Less colour

1. Action pictograms are now gray to not steal attention, and to match wiki

Less clutter

1. "Terminology" field removed because it is self-explanatory, and cant be anything else
2. "String removed" because less visual clutter

Ordered

1. Alignment work on everything on the left

Minimal

1. Tried doing without Wiki and Bug and use the + as a dropdown
2. Tried doing without labels on the translation/assert/suggest/comment buttons

• The idea here was to dual issue them for voting on suggestions. Green is confirm, red is no, yellow is unsure.

Spacing

1. More air in between the strings, and matching alignment of elements with equidistant horizontal spacing
2. Tried fixing the copy pictogram by making the + into an arrow

[comradekingu]

After peer review, and largely coinciding with my thoughts, most things work, these are the contested and important points:

Less clicks are great, it means something repetitive has a little bit of turmoil removed for each repetition. Example: Either you flip from page to page in a book, or you unscroll a new pergament for each page. For a whole book it adds up.

Needs fixing

• Translate/Assert/Suggest/Comment needs to be labelled
• Pictograms need to be bigger
• Text needs to be bigger
• Versals on the terminology do not match "row" and "Rad", should be "rad" unsure why this is.
• The copy pictogram is broken. It is for the case of argument not functionally superior to a picture of a horse, or a dot. Adding an arrow did not do the trick. from launchpad is good.
• Shortcuts need to be made visible, clear, and the translation hotkey should be one button.

Possible:

• Having it say "string" serves a purpose greater than removing it
• Blue background is more pleasant
• Blue Bug/copy pictograms are easier and more declarative. A possible way to solve this, while matching the wiki pictogram, is to have a blue line under the Wiki pictogram/logo.

Suggestions:

• Mouseover wiki link gives "simple wikipedia" textbox
• Similar googletrans mouseover for translation field

Edit: Comfy

• Bigger text, bigger input bar, all languages align. From a UI perspective, editing multiple languages makes more sense now, even source if one has the permission to do it.
• Shameless placeholder theft of launchpad pictogram.
• String number now in gray to not grab attention.

[comradekingu]

The multi-line waste is described in #5578