Page MenuHomePhabricator

MinT MVP: Improve perceived performance when showing machine translated contents
Closed, ResolvedPublic

Description

As part of the work on the MinT for Wikipedia Readers MVP (T359072), machine translated versions of a wiki page are shown at the Translation view (T359801). There, the lead section is shown initially and the translation for the different sections are requested as the user expands them.

Translating the contents of a whole section can be a time-intensive task and it may take a few seconds for the translated section to show to the user. This is not an ideal experience.

This ticket proposes to explore ways to reduce the waiting time for the user. Some initial ideas:

  • Show contents as they become available. Instead of waiting for the translation of a whole section before showing it, we can show the translation of each paragraph as they are obtained. We may need to show a placeholder to communicate that additional contents are loading (see video below)
  • Pre-load contents. Some contents can be requested in advance, before the user tries to expand a given section (even at the Confirm step). We can consider loading the first 2-3 paragraphs of the next 1-2 sections to have contents ready to show immediately as the user expands the section.

Additional ideas can be explored considering the balance between reducing the waiting time and avoiding too much waisted computing capacity (i.e., obtaining translations that users won't read)

Event Timeline

Pginer-WMF triaged this task as Medium priority.May 3 2024, 9:44 AM
Pginer-WMF created this task.
Pginer-WMF added a subscriber: abi_.
ngkountas changed the task status from Open to In Progress.Jun 20 2024, 11:43 AM
ngkountas claimed this task.

Change #1048058 had a related patch set uploaded (by Nik Gkountas; author: Nik Gkountas):

[mediawiki/extensions/ContentTranslation@master] AX: Split lead section to translate it simultaneously

https://gerrit.wikimedia.org/r/1048058

The robot icon and the ellipsis together do not effectively convey that content is being loaded. Animating the ellipsis would better indicate that content fetching is in progress.

Change #1048058 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] AX: Split lead section to translate it simultaneously

https://gerrit.wikimedia.org/r/1048058

The robot icon and the ellipsis together do not effectively convey that content is being loaded. Animating the ellipsis would better indicate that content fetching is in progress.

If the placeholder is going to be visible for a few seconds, it makes sense to convey better that it is active. We could make the ellipsis to be pulsating. Either adjusting the opacity for the ellipsis icon in a transition (0% → 100% → 100% → 0%) or using the standard loading indicator which is based on three dots. Whichever is simpler to implement.

@Pginer-WMF if you notice the background of the loading indicator (the one with the robot ellipsis icon) is changing (ripple effect) to indicate that something is loading. Do you think this is enough or we should proceed with a different option? In any case, I think this is a minor adjustment and can be captured in a separate task - especially if you don't plan to work on this, right now.

@Pginer-WMF if you notice the background of the loading indicator (the one with the robot ellipsis icon) is changing (ripple effect) to indicate that something is loading. Do you think this is enough or we should proceed with a different option? In any case, I think this is a minor adjustment and can be captured in a separate task - especially if you don't plan to work on this, right now.

It seems good for now. I think that in the video the template placeholder was competing with the paragraph one. Checking it live will be helpful to define follow-up adjustments if needed.

@Pginer-WMF The patch for gradually fetching the translated contents have been successfully deployed on AutomaticTranslation special page. For now, we do not intend to explore more opportunities for perceived optimization, so this task can be closed as done:

Great. Nice improvement. Trying this in a long article such as Tokyo helps to see the usefulness of the approach. I think we can resolve this and consider future improvements as follow-up tickets as needed based on future observations and feedback.