Topic on Extension talk:RevisionSlider

New version does not work

28
Summary by Lea Voget (WMDE)

It does work, but not the same way that was appreciated here in the old UI. The upcoming version is going to support click behavior again:

https://phabricator.wikimedia.org/T172092

IKhitron (talkcontribs)

Hi. Could you, please, rollback to the old version? It does not work in mobile. but you created a patch, so I belive it will work after deployment. But it does not work at desktop computers too, so can't be used anywhere. Thank you.

Lea Voget (WMDE) (talkcontribs)

Hi @IKhitron, thanks for the feedback! Could you give us a bit more detail into what you mean with "does not work"? If you could show us a screen video or annotated screenshot, that would be great. A detailed lists of all things you did and what happened would be appreciated, too :)

Thanks!

Lea

IKhitron (talkcontribs)

The screenshot will not help.

  1. I open hewiki diff in firefox windows 7.
  2. I try to move the bolls with a mouse - it works.
  3. I try to click some bar so the boll will move there - does not work.
  4. I try to move the bolls so they will exchange (old over new or vv) - does not work.

Thank you.

Lea Voget (WMDE) (talkcontribs)

Thanks for the clarification! The behavior you explain there is actually something we deliberately changed to work that way. The old behavior (click on a bar and one of the pointers moves there / move one pointer past the other pointer) had the problem, that it is very difficult for users to predict what will happen when they move a pointer. It was not intuitive that one pointer reacted to activity above the line, while the other to activity below the line. Therefore we decided to make the behavior more clear: You now have slider which show you exactly where you can move a ball to, and you know that the blue ball will always be associated with the one revision and the yellow ball with the other. Of course this comes with drawbacks, too (the ones you described). However, if you prefer to click rather than drag, you can still click on the slider area to move the ball without dragging it.

IKhitron (talkcontribs)

Thank you. It's wrong, but at least it's not a bug.

The problem is that "you can still click on the slider area to move the ball without dragging it" does not work.

Lea Voget (WMDE) (talkcontribs)

Hi @IKhitron,

does clicking on the slider line also not work for you? Thanks for specifying :)

IKhitron (talkcontribs)

What do you mean in "slider line"? I click on the bar, as always.

Lea Voget (WMDE) (talkcontribs)

I mean the blue and yellow lines that the knobs navigate on - very much in the middle where the upper and lower bars meet. Does that work for you?

IKhitron (talkcontribs)

Yes, it does. Please do not tell me that it should work there only.

Tobias Gritschacher (WMDE) (talkcontribs)

@IKhitron see https://phabricator.wikimedia.org/T160410 for the specification how the new interface should work. The area to move the pointers by click was reduced to a clickable area around the yellow and blue horizontal lines. Reasoning against making the whole bar clickable is especially outlined in https://phabricator.wikimedia.org/T160410#3157264 and https://phabricator.wikimedia.org/T160410#3157497. If you have suggestions how to further improve the experience for users that prefer clicking, please don't hesitate to share.

IKhitron (talkcontribs)

I see. Thank you. It's too late. So, until there will be a possibility to choose between the old slider and the useless one, if any, I turned it off. A pity, because I used it a lot of times every day, but I have no choise. Thank you for the wonderful months.

Lea Voget (WMDE) (talkcontribs)

Hi @IKhitron, one thing to add to the reasoning above: We decided against using all bars as a clickable area, because on touch screens, there is no hovering. Therefore, users cannot hover, and see the tooltip, and click, and change the revision. Therefore on mobile, you see the tooltip in the upper part of the bar and and can change the revision on the lower bar.

However, we are in discussion how to improve the clickability of bars. I'll add you to the phabricator ticket once we decided how, maybe it will make you reconsider :)

IKhitron (talkcontribs)
Lea Voget (WMDE) (talkcontribs)

Of course! Please share :)

IKhitron (talkcontribs)

Well, there are 2 X 2 cases: 2 for desktop vs mobile and 2 for between bolls vs outside of them. Let's check these cases one by one, sorted by ascending problemacity.

  1. Mobile outside the bars - no problem at all.
  2. Desktop outside the bars - not so convenient, because the user should click in much smaller area, so it increases the time needed to open some diff, more or less to the time needed to do this in history page. But load the history page takes much more time, so it's not so bad.
  3. Desktop between the bars - very bad, because you should be very precise to click on the right line, when they are very close each to other. It's possible, but will take a lot of time - at least a second and maybe even more. So the advantage from the previous paragraph disappears, the diff opening using the history page is much faster.
  4. Mobile between the bars - extremally bad, because you can't touch at all the screen on one line without touching the other, as the distance between the lines is less than the finger diameter, and it should be at least 1.5 such diameters.

Summary - there is no sence to use it on desktop, and it's absolutely impossible to use it on mobile. If even one of these was working, I would use the slider, but if noone - I can't.

197.218.90.114 (talkcontribs)

<blockquote>Therefore, users cannot hover, and see the tooltip, and click, and change the revision. Therefore on mobile, you see the tooltip in the upper part of the bar and and can change the revision on the lower bar.</blockquote>

It was not particularly intuitive, although the help menu clearly notes this. Perhaps it could work if instead of single click to move the knob or ball, it could happen on double click. On mobile, double tap might be designed to do the same.

Alternatively, it might make sense to increase the size of the yellow / blue lines, to about maybe 2 mm (more or less) to highlight the "slideable" area. It isn't particularly obvious that the lines "highlight" when the pointer is hovered close to them (indicating that something could be done). It is not often the case that such a big object is a attached to a small rail, so it can be a bit surprising considering that this isn't a standard interface design that people are used to.

This is generally an interesting interface to keep experimenting with until a solution that works reasonably is found.

IKhitron (talkcontribs)

The tooltips never worked right for me in mobile. But I understood that there is nothing to do, and just suffered. The diff, in opposite, are very important.

197.218.90.114 (talkcontribs)

One idea might be to have a translucent / transparent (ghost like) knob showing on the rail where the pointer is as a way to indicate that someone can click there and move easily, e.g.:

-------◯---------⬤----------

^

On mobile devices this could be made bigger so that it is easier to click, or the default knob / ball could be enlarged (to a reasonable size) to ensure it works without any mobile specific changes.

197.218.90.114 (talkcontribs)
The tooltips never worked right for me in mobile. But I understood that there is nothing to do, and just suffered. The diff, in opposite, are very important.

Yes, designing for multiple devices requires tradeoffs. That's why some experts suggest starting with designs for mobile and then creating designs for desktops. Mobile devices always have limitations, so it is tends to be better to make features limited, and then enhance them when making the "full" mobile version.

This is especially a problem because the term mobile isn't well defined at all. There are too many things that can be mobile, e.g. a "gameboy" with internet (https://www.extremetech.com/extreme/54188-gameboy-owners-will-surf-the-web), portable tv, (http://www.dx.com/p/fulljoin-nmp001-2-4-lcd-portable-internet-tv-radio-multimedia-av-player-w-wi-fi-tf-black-176527) and so forth. Most people think "phone" when they think of mobile, but many mobile devices don't even have a touchscreen or a "normal" way to interact with a site.

I really don't envy anyone who decides to design (or support) anything for mobile devices.

Lea Voget (WMDE) (talkcontribs)

Thanks for the detailed information what you are looking for, and ideas how to solve this! I will get back to you as soon as there are news from our side :)

Lea Voget (WMDE) (talkcontribs)
IKhitron (talkcontribs)

Hello. Thank you! It looks good in desktop. I'll try in mobile later. But there is a bug: If you use the side arrows, and then play with a slider a little, the clickability stops. I tried a couple of times, it's always the same.

IKhitron (talkcontribs)

Tried on mobile. Works the same, has the same bug.

197.218.82.231 (talkcontribs)

Seems to work rather well (apparently it has been deployed on this wiki), and it is back to being quite intuitive.

After testing it out for a few minutes it showed this (https://www.mediawiki.org/w/index.php?title=Topic:Twefqgbk9m7u4jrz&action=history) console error. However, it still seemed to work despite the error.

The only thing that might be related to IKhitron's report is when the the two knobs are pushed out of the revision bar area after the side arrows are clicked. In this case, this seems to happen because only one knob can move. Either the blue one if knobs are on the left hand side, or the yellow one if the knobs are on the right.

In either of those cases, one has to either click the top revision bar area , or the bottom revision bar area, depending on which knob has a ownership (a line) over all revisions.

IKhitron (talkcontribs)

Yes, most of the times. But sometimes both can't move.

Lea Voget (WMDE) (talkcontribs)

Thank you both for the fast feedback!

197.218.82.231 you wrote:

>The only thing that might be related to IKhitron's report is when the the two knobs are pushed out of >the revision bar area after the side arrows are clicked. In this case, this seems to happen because >only one knob can move. Either the blue one if knobs are on the left hand side, or the yellow one if >the knobs are on the right.

Did you perceive this as an error or is this just an observation? How do you feel about this behavior and why?

197.218.83.153 (talkcontribs)

> Did you perceive this as an error or is this just an observation?

It seems like an error.

> How do you feel about this behavior

It is not particularly intuitive because it breaks the expectation of the user. The user is expecting some action when any bar is clicked.

> and why?

If only one knob can move, then it doesn't really matter if one clicks the bottom or top.

This is similar to how the old history page works. If both radio boxes are at the end, e.g. (https://en.wikipedia.org/w/index.php?title=Main_Page&action=history) then clicking any remaining radiobox makes the relevant radiobox highlighted, and also makes it clear that one can now click any of the other checkboxes.

Lea Voget (WMDE) (talkcontribs)