7

We have a web application for correcting automatically-detected mistakes in translation documents. Those are split into sentences and their amount can be up to hundred thousands (its not even closely the usual case, but can happen), which causes todays browsers to lag a lot (actions take seconds instead of milliseconds). The whole document is preloaded, so network operations are not the problem, it is the rendering itself.

In the original design, we had one scrollable area with all the items. It is convenient, because the user has to go through all the items eventually and he often needs to see the context of the translations, i.e. be able to scroll a few sentences back or forward.

When discussing the performance issue of rendering so many items, pagination come to mind. But I consider it an UX fail in this case, since every switch to next page would break the users workflow of checking from top to bottom using just his keyboard. The scenario when looking for the context would be even worse.

The "infinite scroll" is also not a solution, because after some time the performance issues would raise, too. Besides, in this use-case, scrollbar position is important for the user - he would like to know that he is e.g. in the middle of the document.

Can you please suggest some other options for dealing with huge numbers of items, which the user must go through?

Screenshot from current design, user always has only 1 item to edit, and works from top to bottom through all items: enter image description here

Improve this question
3
  • 2
    Please, give us more info on how it's really used with some examples. I.e. users just picks a sentence from the top one by one or scan through them to find something, etc. Currently, I think it's rather technical issue and not a UX problem.
    – alexeypegov
    Dec 7, 2012 at 8:19
  • The users scans the sentences one by one and sees the detected errors. If the sentence needs correcting, he changes the texts and continues with going trough the sentences.
    – Tomas Grosup
    Dec 7, 2012 at 8:32
  • The performance problem is technical. But to solve it, we have to come up with some different which does not need to display all the items at once and still provide a good ux.
    – Tomas Grosup
    Dec 7, 2012 at 8:34

4 Answers 4

Reset to default
2

I'm not sure all your assumptions are correct.. You say that one of the problems with pagination is that users can't go on with their work process using just the keyboard - but there's no reason for the keyboard not to control the pagination as well. Also, infinite scrolling doesn't necessarily mean that all the loaded pages remain loaded - you can use virtual scrolling, meaning that basically the current page, the next one and the previous one are loaded, but pages N+2 and N-2 will load only when you reach page N+1 or N-1 respectively. So it doesn't necessarily mean performance issues. It's basically continuous vertical pagination, instead of discrete horizontal pagination (the "classical" approach). Google Images uses vertical pagination. It's perceived as infinite scrolling, but it's actually split into pages which even have titles.

And in terms of the scrollbar - I don't think it's a problem in this case, since you already know the size of the document. It's a problem with infinite scrolling where new content keeps coming in and the length keeps growing. In your case the length is fixed and you just use infinite scrolling to reveal more parts of it. So the scrollbar can have its size and location related directly to the length of the document, it doesn't need to be dynamic.

Improve this answer
4
  • It seems like your answer is more about technical details of the implementation. You're right, infinite scrolling may be done the way it will work quickly, but the original question was about other ways of representation of huge number of items.
    – alexeypegov
    Dec 7, 2012 at 13:19
  • The original question ruled out the solutions for the wrong reasons (imho), so I'm pointing out that there's no need to reinvent the wheel here.
    – Vitaly Mijiritsky
    Dec 7, 2012 at 14:47
  • +1, The virtual scrolling is very promising. We could have loaded e.g. +-1000 items, so in most cases the user would not even notice the difference. Could you please provide a link to some example implementations, so I could see how hard it would be to do this?
    – Tomas Grosup
    Dec 7, 2012 at 15:58
  • Tomas, unfortunately I'm really not the person to talk to about implementation :). But it's a really well-known method, so any search or a question on StackOverflow should provide you with plenty of examples.
    – Vitaly Mijiritsky
    Dec 7, 2012 at 19:23
5

As soon as there is no need to have all the items loaded instantly, it seems like dynamic loading of the next bunch of sentences may help you. It should work like pagination, but instead of updating the whole page, I suggest to give users an ability to walk through sentences and choose how much they would like to see in every bunch:

sentences

You may also show the relevant part of the original document if needed so editor will be aware of the full text. Note, that page is not refreshed completely, but only a sentences block and possibly context part of the document.

You may also try to perform some kind of semantic analysis and link similar sentences together so user will be able to even quickly review previous sentences (this also may work as grouping thus reducing the number of items shown).

Search with instant preview may also help users to review the previous sentences and minimize pagination or scrolling.

Improve this answer
4
  • Thank you for an example. The problem is that it would be uncomfortable if they suddenly want to go about 5/60/200 sentences back to look for a similar sentence a look up how the translation looked like. It still has the bad UX of Previous/Next.
    – Tomas Grosup
    Dec 7, 2012 at 9:00
  • 3
    +1 for the idea of showing the original document, I really like it.
    – Tomas Grosup
    Dec 7, 2012 at 9:01
  • @TomasGrosup I think that instant search with the preview may be handy in this case. So user will be able to quickly find a similar sentence by a couple of words and overview the changes in place.
    – alexeypegov
    Dec 7, 2012 at 9:02
  • That would be good and would eliminate the need of scrolling, if we could provide them things they might look for in form linking them. However this ends to be a technical issue, because sementic analysis for a bunch of languages like Japanese,Korean,etc. would take a lot of time.
    – Tomas Grosup
    Dec 7, 2012 at 9:22
1

Not sure this is possible, but I think the best solution is to keep the UI as you have it and break the work unit up into chapters if necessary. The breaking-up-into-chapters wouldn't be visible to end users, it would be performed by the process that produces the work unit.

I fully appreciate the negative aspects of pagination and infinite scrolling and agree they should be avoided if possible.

Improve this answer
1

Could you just have vertical pagination? Or a combination between pagination & infinite scrolling?

Say you have have a page full of sentences and scroll down. With infinite scrolling it will load more questions. What if instead it loaded page2 and unloads page1? Scroll up enough it goes back to page 1 - scroll down it goes to page 3.

Does that make sense?

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.