search

serokell / xrefcheck

Check cross-references in repository documents
Mozilla Public License 2.0
55 stars 3 forks source link

Discuss UX of progress bar #101

Open dcastro opened 3 years ago

dcastro commented 3 years ago

Clarification and motivation

At the moment, the progress bar's behaviour is simply this:

This can create some, IMO, somewhat awkward UX.

Say there's 2 links you need to verify. The 1st returns a 200 immediately, the 2nd takes 5 seconds and then returns a 429. This will happen:

  1. The 1st link is verified immediately, and the progress bar will fill with 50% yellow (y) [yyyy____]
  2. After 5 seconds, the 2nd link will return a 429. The progress bar is updated, we fill the remaining space with 50% blue (b) [bbbbyyyy]

The problem here is that, in step 2, the new content was inserted on the left, and the existing content was pushed to the right.

IMO, we shouldn't be shifting cells around when updating the progress bar. This makes it harder for the user to create a "mental diff" of what changed since they last looked at the progress bar.

So I'd like to propose an alternative.

We keep cells grouped by color (reds next to reds, blues next to blues, etc), but the groups are displayed in the order that they first appear in.

Say you have 5 links, and they return in this order [200, 500, 429, 200, 200]. Eventually, the 3rd link is retried, and it returns a 200. Then the progress bar would look like this:

But if they return in this order [500, 429, 200, 200, 200], then it would look like this:

Acceptance criteria

We have discussed the pros and cons of all suggested approaches and have decided on a path forward

Martoon-00 commented 2 years ago

Thanks for raising this issue :+1:

I agree with this concern. Ideally it would be nice if all groups strictly grew without shifting when the respective count increases, but while we try to fit them all into one bar this does not seem to be possible.

Let's concentrate on the smaller issue you are aiming to address (as far as I understand it): that a group can appear and grow out of nowhere at the left of an existing group, thus potentially causing lts big shift.

I quite like the the solution with displaying groups in the order of their appearance, it should nail the issue.

However, it has a hidden but relatively significant drawback (as to me):

At least for some people, the mind tends to remember not only the meaning of color but also the meaning of the order (e.g. 1st - failed, last - passed), relying on that in the future to recognize groups even more than on colors. And if the order changes randomly from time to time, this may cause some confusion.

Other than that, the solution seems good to me.

One another approach that seems viable to me to reduce shifting: keep the order of the groups fixed but glue them to both edges of the bar.

For instance: yellows are always stick to the left, reds are always stick to the right; this way they never shift, only grow. Placement of blue items can be approached differently; the smoothest shift is probably achieved by placing them centered in the empty space between yellows and reds.

On your first example from above: 5 links returning in [200, 500, 429, 200, 200] order. Eventually, the 3rd link is retried, and it returns a 200.

Another example where most of the links are retried:

@dcastro What do you think on all this?

dcastro commented 2 years ago

@Martoon-00 I agree with your concern, colour positions should indeed be fixed.

I like the idea of gluing y to the left and r to the right! The blues in the middle seems a bit odd... I don't remember ever seeing a progress bar growing from the middle :sweat_smile:

How about if we place the blues right after the yellows? So instead of [yy__bb__rr] we'd have [yybb____rr].

This does mean that we might sometimes go back to our original problem, i.e. if the first link is blue and the second is yellow, it'll look like the first blue link is being "pushed to the right" to make room for the yellow one. But then again, I don't think this very specific scenario should happen very often. Blue cells should be rare enough - but a situation where you get many blue cells before you get your first yellow cell should be even more rare.

Martoon-00 commented 2 years ago

I fully agree that making the bar grow from the middle is kinda weird, and taking all the probabilities into account, making blues stick to the yellow seems the best.

There might be also one improvement which, I think, could work perfectly in this case.

When the yellor bar is empty, we could still display it but as having a width less than 1 - this way the original issue gets away completely. Maybe · character would suit for this purpose of showing width = < 1 square in a bar.

As far as I can tell, this trick wouldn't work for reds and blues because in their case "fraction of a square` is ambious - does it indicate nothing or some small number of links? But in case of yellows we don't care - there is no big difference in having zero valid links or a couple of valid links, I only care about how many invalid links I'll have to fix. For this reason the trick works only if we move reds to the right.

The main downside of this approach - we either have to find some suitable character for this "part of a square", but it will likely be not supported on many systems. Or we have to go with a wide-spread character, but I'm not sure if this will look beautiful.

I won't be able to participate in discussions for quite a while since now, leaving the final decision on this last consideration on you. Thank you for this discussion )

I'm personally fully satisfied with the [yybb____rr] solution. But if you think any improvement could fire here, I would be glad to try it implemented once back :smile_cat:

dcastro commented 2 years ago

I fully agree that making the bar grow from the middle is kinda weird, and taking all the probabilities into account, making blues stick to the yellow seems the best.

Great, we're in agreement :D

When the yellor bar is empty, we could still display it but as having a width less than 1 - this way the original issue gets away completely. Maybe · character would suit for this purpose of showing width = < 1 square in a bar.

Hmm, I'm not sure I fully understood, are you suggesting we have a single yellow · at the far left, as a "placeholder" for future yellow bars?

I dunno, this seems like it would introduce other complexities (e.g. what if it turns out all links are invalid? do we then delete the yellow dot and replace it with a red bar?).

It might also confuse the user further (e.g. "why does the progress bar show dots and bars?")

Personally, I don't think introducing this new concept would be worth the trouble and potential confusion :/

I would be glad to try it implemented once back :smile_cat:

Sure, sounds good :smile: