Using images/graphics: develop guidelines

[lena-voita]

I believe we need graphics

One of the main goals of the website is to express high-level ideas very clearly to make people understand the content easily (https://machinetranslate.org/style). I believe good graphics are one of the ways to achieve this: in many cases, information presented visually (when done properly) is much easier to perceive/comprehend than reading text. I’m afraid that forbidding graphics would harm the website and make achieving our goal harder. Below I'll show some of the examples where I think graphics could help to illustrate the point and show what I have in mind.

But there are some concerns

Of course, there are some concerns regarding using graphics which Adam mentioned:

• hard to translate
  (content of machinetranslate.org will be machine translated, and graphics are hard to translate)
• hard to edit
• have to keep in mind how this'll look on mobile devices

Action point: discuss and agree on the guidelines

While I totally agree with the concerns, I still think that forbidding the graphics completely would make it much harder to achieve our goal. What I think we could do:

1. categorise the types of graphics that could be helpful for the site and give examples. I'll do this below and you can add other types/examples
2. propose some ways to address the concerns. I'll propose something and then we can start discussion from there
3. decide which types of graphics are allowed or not, and for those allowed which guidelines they have to follow

[lena-voita]

Types of graphics and use cases

Showing structure/logical order

Elements: mostly text and arrows

Such structures can help navigating and show the connections between different sections. For example, when talking about Quality evaluation, the figure below shows (1) the main difference between quality estimation and evaluation, hence (2) its place in the hierarchy of all the metrics and (3) shows the categorisation of the metrics inside the part we are going to talk about. With this, the structure is clear and the rest is much easier to comprehend. Without this, explaining the structure with plain text would require a person to read lot of text and build it in their head: create all the logical connections etc. I really think having such structures at the top of some of the pages would make it much more clear and would help a lot.

Schemes and animations showing how things work

In lots of cases, showing a clear picture/scheme/animation can save a lot of trouble trying to explain the same in text. And, after looking at the picture, it’ll be much easier for a person to comprehend the text explaining the same.

For example, we can illustrate the idea of beam search (just an example - can be updated!).

Or show how neural MT works: reads the input sentence with an encoder and and generates output one token at a time. The picture below can be simplified to be adapted for the site (e.g., remove the distributions and show only encoder, decoder and generating word by word).

When talking about attention, we can also give an idea of what it is.

Or what a model learns: showing an attention map to give an idea of how it works when trained.

The idea behind self-attention in Transformers:

Less formal: sketches giving intuition

This is the least formal type of figures, but sometimes they can be a good way to show the intuition behind some of the stuff. I don’t have yet anything for this project specifically, but below are some examples I did for other topics.

For example, when talking about evaluation of language models, perplexity might be hard for non-technical people. But the intuition behind can be made clear.

Or, when talking about transition from word-based representations to contextualized models, we can illustrate what different embeddings see in the data.

[lena-voita]

Three types of graphics

So far we have three types of graphics:
(1) schemes showing structures (mostly branching trees)
(2) pictures/animations showing how things work
(3) very informal sketches showing intuition behind technical stuff

Discuss concerns

Now let’s look at the concerns

Hard to edit

• types 2 and 3 (pictures) - not a problem since they are static
• type 1 (structures): might need editing

Ways to alleviate:

• put there only structure that is fairly static (e.g., in the example with Quality evaluation give the structure but not mention specific metrics that can change)
• along with the picture, put the source (e.g., .pptx) to let others update if needed

Hard to translate

• types 2 and 3 (pictures) - contain a couple of words, but maybe that’s ok. For example, Wikipedia articles also contain schemes and animations that do not change when switching to the same page in different languages.
• type 1 (structures) - more problematic, but maybe this is also not a big problem.

Ways to alleviate:

Since each figure illustrates some idea, the idea itself is discussed in the text. In this sense, figures help but if they are not translated, this does not stop from understanding the content.

Mobile devices.

We started discussing this here: #228

Summing up, Cecilia mentioned that the article content section has a somewhat fixed width, and anything that may exceed that width would require readers to left-right scroll. This would also affect phone navigability. I replied that what we could do is just set image width in percentage of the screen width rather than a fixed absolute width value - can we? In html, this works well.
Does anyone know if this can be done?

Action point: let's discuss!

I need your help to agree on the following:

1. for each of the graphic types, whether they are allowed or not
2. if allowed, what are the guidelines to alleviate the concerns

[bittlingmayer]

Fixed width or max width images - it can be done, we do it I think, but they're very small on mobile.

So we should try to make images more tall than wide, and not too detailed.

[bittlingmayer]

One way out of this is to use graphics from elsewhere and just clearly say that.

That's what I did on https://machinetranslate.org/hybrid-translation.

Then we don't need to worry about a consistent style, just like we don't worry that paper titles don't follow our style guide.

The examples you gave of type 2 and 3 would be covered by that.

e.g. we can describe it a slide from a 2020 presentation by Lena Voita.

Machine Translate is intended to be meta, after all.

[bittlingmayer]

Type 1 I am less sure about.

At least that example is a DAG so it can be perfectly represented with a Markdown list or YAML list with some nesting.

It's also text-heavy, so having it in Markdown means better translation, page search, site search, web search, better sizing on mobile...

(Whereas text input examples in a transformer example don't need to be indexed or translated.)

There are ways to do diagrams in HTML/CSS, but not sure it's necessary in this case.

In many cases, hierarchies like in type 1 can be implicit in the site/section/page nav.

[cefoo]

For the first graphic, we may use something like this:

---

Does the metric use reference?

- Quality evaluation

(A good metric correlates well with human judgements)

• Similarity between machine and human translations

  • N-gram matching
  • Embeddings similarity

• Correlation with human judgement (optimized directly)

- Quality estimation

...