Talk:Community Tech/RevisionSlider

Let us know what you think of the RevSlider prototype...

+1

This is definitely cool and worth continued development, in my opinion. Currently, the interface is very barebones. I don't think novice users will know what to do since many wouldn't think to hover over the blocks and move the sliders around.

One idea would be to display the revision summary and timestamp of the two selected timestamps just above or below each slider. This way it's more obvious what the slider is providing.

Another thought that might be difficult to implement would be to scale the positions of each timestamp along the timeline in true chronological scale instead of a flat spacing for each position. In this way, you would get more visual cues about when the pages was edited over time. For example, you might have a cluster of 5 edits in June 2014 followed by a couple months with no revisions, then more edits in September 2014 (and so on).

I'd also like to see the watchlist incorporated into this interface. So if a user goes to a page that has been revised since their last visit, it should highlight the revisions they have not yet seen. For example, if a page was revised 5 times since I last visited that page, then the 5 latest timestamps should be highlighted or otherwise marked to differentiate them from the rest. It should probably default to show me everything that has changed since I last visited (compare the most recent timestamp to the 6th most-recent).

--Darenwelsh (talk) 23:01, 30 October 2015 (UTC)

The timeline is a really interesting idea; it's another way to visualize the page history. I think having a visual model of the history would help me parse a history page -- do other people feel that way?

Also, good point about making the slider more discoverable. A real version needs to provide clues about what it is, and how it works. Thanks for posting your thoughts. DannyH (WMF) (talk) 18:41, 4 November 2015 (UTC)

might want to look at how internet archive does timelines (hashmarks for year with pop up calendar detail) or histropedia [1] (infinite zoom). Slowking4 (talk) 01:07, 10 November 2015 (UTC)

192.168.1 128

Context

So this was chosen because it's the ~30th most used Gadget on Wikipedia? What were the goals, does the original gadget have some deficiency you wanted to fix? Nemo 08:43, 31 October 2015 (UTC)

One of the requests that came up in the All Our Ideas survey was to build an extension that has the same functionality as Revisionjumper.

It's a helpful (and possibly underused) gadget -- it saves time and pageloads if you don't have to keep going back to the history page -- but there are some potential deficiencies that we were looking at. Revisionjumper allows you to go back 10, 50, 100 and 150 revisions, and similar jumps in time. But it doesn't have fine-tuning, and there isn't a signal on the page that helps you figure out which revision you're aiming at.

When we were talking about Revisionjumper, we came up with an idea that could give people more fine-tune control. It was easy to make a quick prototype that we could show to people, which helps us find out if that's an option worth exploring as a way to respond to the request for a Revisionjumper extension.

But, naturally, I forgot to put that rationale on the page here, so I'm glad that you pointed it out. I'll post this on the page as well. Thanks. DannyH (WMF) (talk) 18:35, 31 October 2015 (UTC)

Inspiration from other implementations

I like the idea of a better way to navigate revisions. Put me down for a +1. While not a 1-for-1 comparison there might be some inspiration to gain from looking at how other systems implement such an interface. Not that long ago WordPress revised their interface for navigating revisions. Here's a short little demo showing how their implementation works. youtu.be/G6-raJCevBY or https://www.clkoerner.com/documents/revision-slider-wordpress.mov

Personally, I like how they've organized some of the information (time and editor as a hover state while you drag sliders) to make it approachable and easy to use. Ckoerner (talk) 15:43, 4 November 2015 (UTC)

Yeah, WordPress was definitely an inspiration for this prototype. The RevisionSlider does actually have that hover state with time and editor, and it took me a minute to figure out why you hadn't noticed that. In the prototype, you can see the hover state when you move the slider, but only if you keep your mouse in the narrow strip of the slider itself. On WordPress, once you've started moving the handle, it keeps showing you the hover state when your mouse drifts above or below the line. That's something we'll have to fix here. Thanks for bringing that up! DannyH (WMF) (talk) 18:24, 4 November 2015 (UTC)

Other history visualization tools

There's a massive list at w:de:Benutzer:Atlasowa/edit history visualization that has always inspired me. Might be something in there, that triggers a good idea.

I particularly like the usage of the purple/blue sparkline, in the top row of the WikiDashboard interface (better screenshots: one, two), and the entire thing was kinda fantastic, in my fuzzy recollections... Quiddity (talk) 06:56, 8 November 2015 (UTC)

Scaling past 50 revisions

How about having the left side represent the first revision and the right side representing the last. Then to move efficiently you can have the increment increase exponentially over time. That works good for people who'd like to move by dragging. However for people who just want to click around that makes granularity a problem, and maybe to tackle that you can show the +/-3 revisions closest to each slider. So the UI could show 3 discrete regions around each slider, and the rest as continuous regions. Opencooper (talk) 08:22, 8 November 2015 (UTC)

Agreed. Precision for 50 edits isn't necessary. I would go for precision on 5 in either direction, and then work logarithmically/exponentially from there so that the timeline ultimately shows the full edit history and you can zoom in on the two parts that interest you. -- 65.79.1.34 17:43, 9 November 2015 (UTC)

I agree. That was the initial implementation of the slider, but we couldn't find a good solution to spanning it out again, your solution of showing +/-3 revisions close to each handle is a good one. I'll keep this in mind when developing the actual extension if this gets sufficient positive feedback. :) Thanks! -- NKohli (WMF) (talk) 08:57, 17 November 2015 (UTC)

LivePreview

If this could work with LivePreview, then it would be even more awesome :) —TheDJ (talk • contribs) 20:39, 9 November 2015 (UTC)

Wait, does that mean you're saying its "awesome"? (Bear with me, I'm trying to find people who actually like this! :) -- NKohli (WMF) (talk) 09:09, 17 November 2015 (UTC)

Neutral/comments

I can see how it could sometimes be convenient, but I'm not sure I'd bother enabling it if it were an option/gadget. The history page makes the edit dates/names/summaries visible all at once, which is generally the fastest easiest way to locate what I want. Viewing revision info by mouseover is a bit like looking through a straw.

Comments if this does go forwards: Changing the slider behavior is an easy and important fix. Currently there is a left-slider and right-slider. When dragging one, the other acts like a troublesome wall.

Option 1: Let the sliders pass through each other. The "right slider" switches to "left slider" at the moment of crossover.

Option 2: I think I prefer this one. Let one slider *push* the other slider. The most common view by far is to look at two adjacent revisions, and it

would be nice if the push-mechanic works like that. You'd need to figure out some mechanic for setting both sliders to the same revision.

The current implementation randomly takes a half second to 4+ seconds to complete the page load, and when it does it gets "inserted", kicking the rest of the page down a few lines. I assume you can pre-allocate the space for the slider, avoiding the page-kickdown when it loads.

By the way, commenting on this reminded me of an annoyance on the history page. The history selection mechanism suffers from effectively the same issue as the "sliders-can't-cross" issue. Consider this history page illustration:

 o
 o
 y
xo
 o
 *
*
o
o

The * symbols are the currently selected diff-view. x y is the desired diff view. The fact that I can't click on x is a very common annoyance. y has to be clicked first to "unlock" x. Better solution:

oo
oo
o*
oo
oo
*o
oo
oo

Please fixy fixy that! :) That should be easy. Note that it opens the possibility of this stetting:

oo
oo
*o
oo
oo
o*
oo
oo

This setting would diff exactly the same as the last illustration. Alsee (talk) 05:43, 10 November 2015 (UTC)

Thanks for your input, Alsee. We'll keep this in mind when turning this into an actual extension. Since it's meant to be a quick and dirty prototype, we didn't bother fixing all the bugs and adding a lot of improvements. As a means to see if people do think this is worth continued development. -- NKohli (WMF) (talk) 14:56, 17 November 2015 (UTC)

Toggle

I'm missing a toggle functionality, i.e. a possibility to quickly activate or deactivate the RevisionSlider.
The RevisionSlider is really useful, but in most of the cases when viewing a diff, I don't need it. As it uses quite some space and takes time to load, I would prefer to have it deactivated as a default. But activation (for the displayed page) should be possible with a single click. --Leyo (talk) 10:27, 4 August 2016 (UTC)