Usability issues with Pootle TM

[friedelwolff]

I've just been using Pootle to update my Firefox translation. Here are some of the things relating to TM usability that still bothered me at the end of the session:

• having to click to reuse. I often didn't use simply because it didn't feel worth while. Tough one, and maybe not all that bad.
• The diff highlighting always emphasises the part I don't want to check.
• part of the highlighting in the source looks like the target (grey). When the source and target is short enough to be next to each other, at times I mistook the target as part of the source (maybe different background styling?)
• Lack of visual contrast between the background and the highlighted text (#CCCCCC vs. #F1F7E4)
  • The first suggestion is far from the main focus area (source+target). With short strings, the distance is about 3 heights of the suggestion away.
  • If I reuse a suggestion by clicking, and then proceed to edit it, it is a bit cumbersome to have to unfuzzy it (Ctrl+Enter doesn't seem to unfuzzy like in Virtaal), especially for 100% matches, although consistency here is probably worth more.

[dwaynebailey]

Replying here, they can spawn their own bugs if that is required.

(In reply to BZ-IMPORT::comment #0)

• having to click to reuse. I often didn't use simply because it didn't feel worth while. Tough one, and maybe not all that bad.

Are you wanting something like Ctrl+1, Ctrl+2?

• The diff highlighting always emphasises the part I don't want to check.

This has to be a matter of preference. The diff actually emphasises what is the same rather then what is different. When I'm checking TM matches I have always found it problematic trying to work our what is the same. Since we talk of 80% matches it makes sense that we focus on what is the same. The diff does actually emphasise what is different, but it is lighter and blocked. I suspect your proposal is more aligned to what a programmer would want when reviewing these text.

• part of the highlighting in the source looks like the target (grey). When the source and target is short enough to be next to each other, at times I mistook the target as part of the source (maybe different background styling?)

Do you mean when a change is at the end and it is light grey? They look sufficiently different to me. I wonder if there are issues of fonts that make this harder to see. A picture would help here.

• Lack of visual contrast between the background and the highlighted text (#CCCCCC vs. #F1F7E4)

I think I'd agree with this one. It does seem hard to read the differences part of the comparison since it is light grey background with slightly greyer text

• The first suggestion is far from the main focus area (source+target). With short strings, the distance is about 3 heights of the suggestion away.

There seems to be quite a lot of whitespace wasted here. Hard to balance readability with this distance issues.

The other ways to reduce this would be to:

• Move special chars somewhere else, to the right maybe. Or at least make it possible to show and hide them. I'm sure some people don't need them.
• Remove all things like 'Add comment' 'Show history'
• Allow switching on and off all things like comments, suggestions, history

• If I reuse a suggestion by clicking, and then proceed to edit it, it is a bit cumbersome to have to unfuzzy it (Ctrl+Enter doesn't seem to unfuzzy like in Virtaal), especially for 100% matches, although consistency here is probably worth more.

Seems we don't make this fuzzy anymore.

[friedelwolff]

(In reply to BZ-IMPORT::comment #1)

Replying here, they can spawn their own bugs if that is required.

(In reply to BZ-IMPORT::comment #0)

• having to click to reuse. I often didn't use simply because it didn't feel worth while. Tough one, and maybe not all that bad.

Are you wanting something like Ctrl+1, Ctrl+2?

I guess so, but it might just be having used Virtaal a lot. But the effect is the same: I often just retyped things. It might be about me typing fast and not wanting to use the mouse. Seeing the suggestion is probably already helpful. If shortcut keys can be added and are consistent with Virtaal, I think Virtaal users would love it. (And is probably what Virtaal users would try automatically in the hope that it works.)

• The diff highlighting always emphasises the part I don't want to check.

This has to be a matter of preference. The diff actually emphasises what is the same rather then what is different. When I'm checking TM matches I have always found it problematic trying to work our what is the same. Since we talk of 80% matches it makes sense that we focus on what is the same. The diff does actually emphasise what is different, but it is lighter and blocked. I suspect your proposal is more aligned to what a programmer would want when reviewing these text.

I was translating, so let's at least pretend that this is feedback from a translator. When I get a TM match and I want to use it, I need to know what I'll need to change if I reuse it. If it is a 99% match, I'm not interested in reading everything I've already read - I'm only looking to see where there is a single case difference or punctuation difference. I'm not sure why you are interested in what is the same, so please share. It makes no sense to me to emphasise the 80% or 95%, since it means emphasising almost everything, which means nothing truly grabs the attention.

I've used this highlighting schema quite a bit since it was introduced. At some stage I did the same on Virtaal to try to get my eyes more used to it. Maybe after a few more years I might get used to it, but it would be kind if you could at least take my comments on good faith. I've found that I look at a suggestion, and then always have a "second look" when realising that I'm not looking at the part I want to see.

• part of the highlighting in the source looks like the target (grey). When the source and target is short enough to be next to each other, at times I mistook the target as part of the source (maybe different background styling?)

Do you mean when a change is at the end and it is light grey? They look sufficiently different to me. I wonder if there are issues of fonts that make this harder to see. A picture would help here.

I think we're talking about the same thing, not sure. Screenshot to follow. I'm referring to the case where the target is shown on the same line as the source. In this case there is some grey text after the black text, which is a bit too similar to the grey text after black text that might be because of string difference at the end. In Virtaal this is solved by the source and target having different background colours, and the target always being below, so there is no chance of confusion. We don't need to do exactly the same thing, but I guess doing any one of these will already help.

• The first suggestion is far from the main focus area (source+target). With short strings, the distance is about 3 heights of the suggestion away.

There seems to be quite a lot of whitespace wasted here. Hard to balance readability with this distance issues.

The other ways to reduce this would be to:

• Move special chars somewhere else, to the right maybe. Or at least make it possible to show and hide them. I'm sure some people don't need them.
• Remove all things like 'Add comment' 'Show history'
• Allow switching on and off all things like comments, suggestions, history

This is tough, and maybe we'll only be able to improve this slightly without taking risks. At the moment we have this (on my system):

• The target has room for an extra row of text (so that autoexpand has time)
• the special characters at 20 pixels

• extras-container with top-margin of 1.8em (20 pixels)

• the heading "amagama server" at 12 pixels

I'm not sure if this is important enough to look into evasive things like UI redesign (moving things away). We might only be able to win a little bit of space with easy options:

• remove the heading (is there a bug already?)
• make the top-margin of #extras-container less (maybe 1 em). I guess this will be contentious anyway, so maybe it is ok for now.

• If I reuse a suggestion by clicking, and then proceed to edit it, it is a bit cumbersome to have to unfuzzy it (Ctrl+Enter doesn't seem to unfuzzy like in Virtaal), especially for 100% matches, although consistency here is probably worth more.

Seems we don't make this fuzzy anymore.

True. I think I missed the relevant commit.

[friedelwolff]

Created attachment 849

Screenshot of short strings

This is a screenshot showing the similarity between target and end-of-string diff (the third point in comment 0).

[dwaynebailey]

(In reply to BZ-IMPORT::comment #2)

I was translating, so let's at least pretend that this is feedback from a translator. When I get a TM match and I want to use it, I need to know what I'll need to change if I reuse it. If it is a 99% match, I'm not interested in reading everything I've already read - I'm only looking to see where there is a single case difference or punctuation difference. I'm not sure why you are interested in what is the same, so please share. It makes no sense to me to emphasise the 80% or 95%, since it means emphasising almost everything, which means nothing truly grabs the attention.

I've used this highlighting schema quite a bit since it was introduced. At some stage I did the same on Virtaal to try to get my eyes more used to it. Maybe after a few more years I might get used to it, but it would be kind if you could at least take my comments on good faith. I've found that I look at a suggestion, and then always have a "second look" when realising that I'm not looking at the part I want to see.

These are different approaches: 1) I look first at what is the same to get an idea if the suggestion is usable in context. I'm more worried about accepting something that looks right but isn't actually right. 2) Then my next step is I suppose the same as your first step. I don't trust myself to find the second occurrence of a 1 char difference because I was drawn to the single larger part of the diff. So in my second scan I see what is different and can see those as they are much lighter and I can quickly spot them.

By focusing on what is the same I can quickly discount changes that relate to variables or punctuation as I can see them more clearly.

So summary for me I don't care first what needs changing I care that first I evaluate the actually usefullness of what has been suggested and I think highlighting first what is the same is much better for that and aligns with the I have a 99% match notion.

[dwaynebailey]

(In reply to BZ-IMPORT::comment #2)

(In reply to BZ-IMPORT::comment #1)

Replying here, they can spawn their own bugs if that is required.

(In reply to BZ-IMPORT::comment #0)

• having to click to reuse. I often didn't use simply because it didn't feel worth while. Tough one, and maybe not all that bad.

Are you wanting something like Ctrl+1, Ctrl+2?

I guess so, but it might just be having used Virtaal a lot. But the effect is the same: I often just retyped things. It might be about me typing fast and not wanting to use the mouse. Seeing the suggestion is probably already helpful. If shortcut keys can be added and are consistent with Virtaal, I think Virtaal users would love it. (And is probably what Virtaal users would try automatically in the hope that it works.)

Can you report another bug then. My concern is that the shortcuts never actually align as we'd need something like Ctrl-Shift-1 (not bad though).

I wonder if live diff'ing would help in any way. So as you type your translation the diffs change. So while you may retype at least you can see if the match is 100%. <- this point is just me thinking out aloud.

[dwaynebailey]

(In reply to BZ-IMPORT::comment #3)

Created attachment 849 [details] Screenshot of short strings

This is a screenshot showing the similarity between target and end-of-string diff (the third point in comment 0).

Yes we where talking of the same thing. Slight background colour shift could help delineate between the source and target. I'd prefer that to always having them stacked.

[dwaynebailey]

(In reply to BZ-IMPORT::comment #2)

This is tough, and maybe we'll only be able to improve this slightly without taking risks. At the moment we have this (on my system):

• The target has room for an extra row of text (so that autoexpand has time)
• the special characters at 20 pixels

• extras-container with top-margin of 1.8em (20 pixels)

• the heading "amagama server" at 12 pixels

I'm not sure if this is important enough to look into evasive things like UI redesign (moving things away). We might only be able to win a little bit of space with easy options:

• remove the heading (is there a bug already?)
• make the top-margin of #extras-container less (maybe 1 em). I guess this will be contentious anyway, so maybe it is ok for now.

I think I've raised various bugs around these, you identify the culprits much better then me.

I think we can only really evaluate once we landed the history stuff.