While I don't want to sound overly negative, I do a lot of editing and I have yet to find a need for this revision slider. This would normally not cause me any great discomfort, as there are many tools that I don't use for one reason or another, but in this case this tool is creating a problem for me. I use the Twinkle commands that appear on the first line of the two revisions that are being compared extensively. Frequently, but not always, the slider display overwrites this line (usually after I have moved to another version) and once it does this I can't recover those commands (collapsing the display does not help) without leaving the page and returning again. This is so annoying that I would like to disable this slider, but it does not appear that I can do that (or at least I can not find anything in my preferences that would do that). The slowness of the initial display and the fact that the cursor frequently opens a bubble by accident that takes forever to disappear are also definite drawbacks. --~~~~
About this board
This is the feedback page for the RevisionSlider extension.
Read about what we've learned about creating a RTL-accessible extension. Please report all RTL-related issues on this talk page!
Display overwrites Twinkle shortcuts, at times
As an addendum, a little more experimenting has given consistent results. The overwriting occurs after I use the previous edit or next edit arrows, even if the slider has been collapsed before I do so. --~~~~
thanks for your feedback! The good news is, in fact you can deactivate the RevisionSlider completely in the user preferences Special:Preferences#mw-prefsection-rendering. Just scroll down to the section "Diffs" and check the box "Don't show the RevisionSlider" :-)!
Nevertheless I created a ticket for the issue so we might be able to fix that for maintainers that want to use the gadget and RevisionSlider: https://phabricator.wikimedia.org/T180430
Thanks again and best,
Yes I eventually found it ... I was looking in the wrong places. It would be good to fix that little bug though.
Suggestion: Include tags in revision metadata popup
It is not possible to see which tags apply to a revision.
Include tags in popup when user hovers over a revision bar.
thanks for the feedback and suggestion. I created a ticket on Phabricator so we can consider it for the future. https://phabricator.wikimedia.org/T180429
Issue: Doesn’t support Flow history
Steps to reproduce:
- Go to https://www.mediawiki.org/w/index.php?title=Topic:Tx9pravihalnuu44&action=compare-post-revisions&topic_newRevision=tx9ybspnga76c31d
- Click newer edit
Being able to navigate using revision slider.
Normal revision navigation.
Notes: Generally, most flow discussions don't seem to be edited that often, so this may generally be a non-issue.
Clicking on bars to change versions (top/bottom for newer/older version)
Currently, a version is only selected if the lines (blue/yellow or top/bottom lines) is in focus/selected (when the mouse cursor is "on the line"). I suggest simply clicking top or bottom part of the column to select the version. This way it is more intuitive.
thanks for your feedback. In the latest version currently deployed (e.g. on English Wikipedia ), clicking the bars to move the pointers should be possible. Clicking the top should move the newer pointer, clicking the bottom moves the older pointer.
Could you recheck or specify your problem more? :-)
Thanks and best,
Popup doesn't always appear when hovering over "bars"
When the mouse pointer is just about 1 or 2 cm above the yellow line the hover doesn't show up.
Steps to reproduce
- Go to a page showing revisions (e.g. https://www.mediawiki.org/w/index.php?diff=2446749&oldid=2428873&title=Extension%3AFlow&type=revision)
- Move the mouse to the left side of the screen (out of the revision slider area)
- Move the mouse vertically 1 or 2 cm above the yellow revision line
- Move the mouse horizontally between different revisions.
The popup showing revision data shows up.
Nothing is shown.
Note: Moving the mouse a bit higher in the revision "bar" area will result in the popup showing up, but this is not intuitive.
Hi there! Thank you so much for your detailed reports :-) All issues are currently in work. We will let you know once it is done! Best, Birgit
Well, here's one bug the developers haven't likely noticed, when a revision pointer is dragged, and then moved back to its original location, the current revision reloads needlessly.
As Birgit mentioned your first post relates to one of the issues we were currently working on. The bug is fixed now and you can see the improved version of the RevisionSlider on beta: https://en.wikipedia.beta.wmflabs.org/w/index.php?diff=354925&oldid=276480&title=Main_Page&type=revision
Due to some maintenance on the Wikimedia servers the fixes for the version on mediawiki.org and test.wikipedia.org will not go live before next week. So if you like to test it a bit more please feel free to do so with the current version on the beta server above.
Thanks again for your feedback and don't hesitate if you have any more issues or questions. I will also take a look into the second thing you mentioned.
The first issue is fixed. The second one still exists.
Just to clarify, to trigger it, one needs to click and press the left mouse button over one of the revision pointers, then move it around horizontally over other revision "bars", and finally return it to its original position and then let go of the mouse.
Yeah, thanks. I looked into it and filled a ticket in Phabricator: https://phabricator.wikimedia.org/T163425
The slider is not showing up for quite a while now which I just realized when reading the latest Tech News. No, I did not tick "Don't show the RevisionSlider". I would like to use it.
thank you for your remark. To reproduce and fix the issue it would be great if you could give us some more information:
1) Do you mean, you don't see the RevisionSlider on this diff page?
2) What browser (e.g. Firefox, Chrome, Safari, Opera) and operating system (e.g. Windows, Apple, Linux) did you use when the issue appeared? Did you use a computer or a mobile device like an iPad?
Thanks a lot in advance!
Heiya Johanna, well, there I see it. To me it looks like that the behaviour must have changed severely. I expected to see the slider on the revision history from the start like it used to be in earlier versions. Thus I did not even get that far. Apart from that I was using Firefox on Linux on a computer, but it seems it is just my mere confusion that is the problem here. :( Thanks for you answer! Cheers
See: https://www.mediawiki.org/w/index.php?title=Topic:Ttqh7as4cz2b6kng&action=history. Chances are you just forgot about its entry point.
Yes, this indeed covers it. I am sure that this was easier to find in earlier versions.
Feature request length diff
I like this tool. Gut gedacht, WMDE! I'd like it even more if it could tell me what net effect the revisions between the knobs had on length. I'm doing a series of edits and I want to know if inching up the size, thus making the article to long. Thanks to everyone who worked on this. HLHJ (talk) 17:10, 23 August 2017 (UTC)
Hi @HLHJ, thank you for the nice feedback :-).
If I got you right, this is nothing that necessarily must be part of the RevisionSlider, but would be generally useful on the diffpage when comparing versions with several revisions in between, right? I created a ticket on Phabricator to track your request https://phabricator.wikimedia.org/T174010
Idea: Contribution slider
As a user, I'd like slide (navigate) to go through users (or my) contributions so that I can evaluate the nature and usefulness of the edits.
Revision slider currently caters for many use-cases but fails to allow a user to seamlessly go through a the edits of a user. This has many more use-cases such a future possibility to compare the edits of two individuals within a time frame, e.g. to evaluate conflicts between them.
- Make it possible to navigate through revisions on Special:Contributions
- For comparing differences - it would use the old revision of a page, and the immediate previous edits (e.g. https://www.mediawiki.org/w/index.php?title=Wikimedia_Apps/Android_design_guidelines&diff=prev&oldid=2533637)
- For new pages - it would just show the first revision, because there is no prior revision
Note: This may possibly be scope creep and perhaps this extension was specifically not designed to do that. So this is deliberately worded more as a brainstorming idea rather than a feature request.
New version does not work
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.
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 :)
The screenshot will not help.
- I open hewiki diff in firefox windows 7.
- I try to move the bolls with a mouse - it works.
- I try to click some bar so the boll will move there - does not work.
- I try to move the bolls so they will exchange (old over new or vv) - does not work.
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.
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.
What do you mean in "slider line"? I click on the bar, as always.
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?
Yes, it does. Please do not tell me that it should work there only.
@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.
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.
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 :)
Of course! Please share :)
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.
- Mobile outside the bars - no problem at all.
- 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.
- 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.
- 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.
<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.
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.
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.
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.
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 :)
a clickable revision slider version can now be found on beta:
Does it work for you? If there is something that works differently than expected, what is it and what did you expect?
Thanks and greetings :)
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.
Tried on mobile. Works the same, has the same bug.
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.
Yes, most of the times. But sometimes both can't move.
Thank you both for the fast feedback!
22.214.171.124 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?
> 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.
Issue: Console errors when hovering over revision line
Steps to reproduce:
- Go to https://www.mediawiki.org/w/index.php?diff=2285787&oldid=2285785&title=MediaWiki&diffmode=source
- Move the mouse pointer to the yellow line (or bar) right before the yellow knob
- Move the mouse pointer to the yellow knob
- Move the mouse pointer to the blue knob
- Move it to the blue line
- Move it to the empty area between the blue line and the slider button
- (Optional) Move the mouse pointer back to revision bars area.
No console errors
Uncaught TypeError: Cannot read property 'top' of undefined$.extend.showTooltipsOnMouseMoveHandler @ VM156:formatted:5849(anonymous function) @ VM156:formatted:5803jQuery.event.dispatch @ load.php?debug=false&lang=en&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin…:65elemData.handle @ load.php?debug=false&lang=en&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin…:60
This doesn't seem to cause have any immediate problem. It was simply something noticed while testing out the interface.
Simpler reproduction: repeatedly hover over the blue knob, the blue line, and the white space right in front of it.