Extension talk:RevisionSlider

Jump to: navigation, search

About this board

Edit description

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!

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL
VQuakr (talkcontribs)

I think the vertical scale needs tweaking. When reviewing a page history, someone is unlikely to care whether a diff was +1 or +2 characters but the difference on the bar height is quite noticeable, while the difference between a +200 and +800 diff is barely discernible unless they are next to each other. I would suggest that +1 through +10 be identical at a pixel past zero, smoothly transitioning to logarithmic (which I assume it is now) somewhere around +100?

Christoph Jauera (WMDE) (talkcontribs)

Hey @VQuakr!

Thanks for your feedback. You are right, at the moment it's a logarithmic algorithm taking into account what the overall maximum change size in the visible changes is. I agree, that this could be improved to better fit reviewers needs. I created a ticket for your request in Phabricator, so we can consider it for further improvements:




VQuakr (talkcontribs)

Similar further thought on maximizing the usefulness of the vertical scale - I won't much care if someone blanked 25% or 100% of a page; either way it's the diff I am looking for if I wonder where a chunk of content went. So the maximum end of the scale maybe should be the greater of either the largest edit in the visible range or some value less than 100% of the page size (I suggest 25%) with anything larger being off scale high/low ie, the largest magnitude.


Reply to "Vertical scale"

Suggestion: Make it possible for the revisionslider to stick to the top of the page even when scrolling (sticky)

3 (talkcontribs)


As a user, I want to navigate through revisions without always scrolling to the top of the page.


Currently the only way to slide to another revision is to scroll to the top of the page and click one of the buttons / knobs. This is a particularly cumbersome when navigating a very long page with few changes in the same area (e.g. middle of a page). Also, with the new VisualEditor/Diffs it is possible to see most of the context without scrolling back up.

Possible solutions

  • Make the revision slider toolbar sticky as the user scrolls; or
  • Make a simpler smaller toolbar that follows the user while scrolling, and contains back and forth buttons (maybe at the bottom of the page).

Using keyboard shortcuts to navigate revisions(using a userscripts) made it clear that this is useful.

Christoph Jauera (WMDE) (talkcontribs)

Hey hey,

thanks again for the feedback. I created a ticket for your proposal an Phabricator https://phabricator.wikimedia.org/T169865 so we can keep track of it and consider it for future developments.

Since you mentioned it: Would adding keyboard navigation be a sufficient solution for your usecase? Or would you still want to see/access the bars and tooltip-summaries while on the middle of the page?


Christoph (talkcontribs)


> Since you mentioned it: Would adding keyboard navigation be a sufficient solution for your usecase? 

>Or would you still want to see/access the bars and tooltip-summaries while on the middle of the page?

The bars are not necessary, only the tooltip summaries related to the current and the prior revisions. With the Visual history diff, this is would be simple, since they could just add that to the sidebar that shows up alongside most revisions (see https://en.wikipedia.org/w/index.php?title=Handball_at_the_2012_Summer_Olympics&diff=473592443&oldid=472329262&visualdiff)

As long as there are keyboard shortcuts and a short summary of the current and prior revision there should be no problem. It worked that way for years after all. The difference is that revision slider reloads sections of page on the fly, while the default diff page reloads the whole page, and forces the user to start from the top again.

Reply to "Suggestion: Make it possible for the revisionslider to stick to the top of the page even when scrolling (sticky)"
Summary by Christoph Jauera (WMDE)

Problems with the Modern skin should be fixed now.

Nikkimaria (talkcontribs)

I've encountered a few display issues in using this tool. First, when I first opened the tool from a diff page the tutorial box popped up; however, the slider displayed over top / overlapping with the tutorial, so I actually couldn't close or move through the tutorial at all. Second, if I hover over a diff-bar and then close the tool, the popup showing information about the diff (username, size, etc) remains on my screen, and actually follows my view as I scroll down the page.

Christoph Jauera (WMDE) (talkcontribs)

Hey @Nikkimaria,

thanks for your feedback. To reproduce and fix the issue it would be great if you could give us some more information around the issue:

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 again and best,


Nikkimaria (talkcontribs)

Windows computer, Firefox53

Christoph Jauera (WMDE) (talkcontribs)

Hmm, sorry but it seem that I can not reproduce the issue with that configuration alone. :-/

I assume that some specific setting on your machine or with your account interferes with the extension. To better understand what's happening I guess I need a few more things, it would be the best if you could provide me additional input on:

- what specific wiki the issue appeared on ( e.g. en.wikipedia.org / en.wikivoyage.org ... )

- gadgets you have activated there ( see Special:Preferences#mw-prefsection-gadgets )

- other user scripts you might have installed

If you could post a screenshot with the issue it would also be super helpful.

Thanks in advance,


IKhitron (talkcontribs)

... Add ons of Firefox.

Nikkimaria (talkcontribs)

This screencast demonstrates the second issue (the tutorial no longer appears so I can't reproduce that): https://www.screencast.com/t/Rxd5inB4G

It occurred on en.wikipedia.org. I use the Modern skin and a number of gadgets and scripts, including nav popups, Twinkle, reference tooltips, HotCat, WikEd, and RefToolbar.

Christoph Jauera (WMDE) (talkcontribs)

Ok I could reproduce the issue with the help dialog. It seems to be related to the Modern skin. I created a ticket for that: https://phabricator.wikimedia.org/T166209

I will further investigate whats happening with the tooltip. Thanks so far for your input!

Issue: Revision slider doesn't display the yellow lines properly when current revision is older than the one being compared

Summary by Christoph Jauera (WMDE)

RevisionSlider breaks when revision ids do not increase in time. See ticket: https://phabricator.wikimedia.org/T164455 (talkcontribs)


Revision slider displays the yellow pointer outside the "revision bar area" when current revision (diff=) is numerically smaller than the one being compared (oldid).

Steps to reproduce

  1. Go to https://en.wikipedia.beta.wmflabs.org/w/index.php?diff=158491&oldid=172031&title=Main_Page&type=revision
  2. Click the button to load the revision slider

Expected Blue and yellow lines showing properly and not going off screen.

Actual Yellow line appears outside (to the right) of the revision bar area .

URL shows: https://en.wikipedia.beta.wmflabs.org/w/index.php?diff=NaN&oldid=NaN&title=Main_Page&type=revision

Notes: While this is a contrived example, because it isn't really easy to cause using the revision slider (unless one clicks the arrow as reported previously) it can still happen on live wikis because users can paste these links, or type them incorrectly. So the interface should fallback gracefully, switch them around, or reject such revisions. (talkcontribs)

Here's a priceless image after causing this layout issue, and then clicking the left arrow :) :


Christoph Jauera (WMDE) (talkcontribs)

Hey there,

from the link you provided I can see, that the numbers of the revisions are a bit strange. I think this is something that can only happen on beta. It seems the slider gets confused if the revision ids are not ascending the newer they are. This should not happen on any normal wiki.

Since most fixes for the bugs reported in the new UI should be deployed now you could as well do tests on https://test.wikipedia.org . I assume the above error won't appear there.

Thanks again for the great feedback,


IKhitron (talkcontribs)

Told you. (talkcontribs)

>  I assume the above error won't appear there.

You're too trusting of MediaWiki. It has huge hacks everywhere, and it is quite easy to replicate the problematic part of this even in test.wikipedia.

Steps to reproduce

  1. Go to https://test.wikipedia.org/w/index.php?title=User:Rocket000&action=history
  2. Click radio button of revision :" 15:43, 26 January 2008‎" -comment : "(making me blue)
  3. Click radio button of revision:  01:41, 20 January 2008‎  - (Undid revision 185552525 by Rocket000 (talk))
  4. Click compare selected revisions
  5. Click button to trigger revision slider


  • Yellow line showing properly and not going off screen.


  • Yellow line appears outside (to the right) of the revision bar area .

This can even be replicated on live wikis easily:

Select these two revisions in the radioboxes of (https://www.mediawiki.org/w/index.php?title=Extension:ExpandCss&action=history), and repeat steps 4 and 5 in the list above.

(cur | prev) 16:54, 27 November 2006‎ HappyDog (talk | contribs)‎ m . . (3,033 bytes) (+32)‎ . . (ExpandCss moved to Extension:ExpandCss: Moved to Extension: namespace.) (undo)
(cur | prev) 16:15, 27 October 2006‎ Lcarsdata (talk | contribs)‎ m . . (3,001 bytes) (+20)‎ . . ({{MoveToMediaWiki}}) (undo)

Or try this link ( although the steps above can reproduce it):

Christoph Jauera (WMDE) (talkcontribs)

Wow, we really did not thought that something like that could happen. The RevisionSlider assumes in parts of its logic, that revision ids are increasing in time but if thats not always the case we definitely should take care of it. I will file a ticket right away.

Thanks again for all your effort, we really appreciate it. :-)


TheDJ (talkcontribs)

The most important reason why this would not be the case, is when edits have been imported and then get merged into an existing page. This is quite common on english wikipedia, where some pre 2002 revisions have been retroactively imported from nostalgia.wikipedia.org because they got lost during the initial import.

Note Graham's notes on this procedure: https://en.wikipedia.org/wiki/User:Graham87/Import point 7 specifically :) (talkcontribs)

Indeed, that's how those revisions were "easily" found . All that was needed was looking at pages using the import logs. Anyone who has used mediawiki import would be aware that it uses a very strange hack, and causes all sorts of inconsistencies in revisions.

You might want to use the timestamp (API:Revisions) instead:

  • rvstart: Timestamp to start listing from. (enum)
  • rvend: Timestamp to end listing at. (enum)

When two timestamps happen to be the same, then the revision id could be used as a tie breaker. Of course this may require more work than just adding a small hack when the "diff=" is smaller than the oldid. Alternatively just wait until this is solved by mediawiki developers (https://phabricator.wikimedia.org/T4930#3210154).

This comment was hidden by IKhitron (history)
Christoph Jauera (WMDE) (talkcontribs)

Just a small update here:

The RevisionSlider does not assume that revids increase in time since some time now. The issue shown in https://www.mediawiki.org/w/index.php?title=Extension%3AExpandCss&type=revision&diff=50164&oldid=51766 should be fixed.

For the issue of users sharing links using the parameters wrong ( putting the "oldid" into the "diff" parameter and the other way around ) as shown in https://en.wikipedia.beta.wmflabs.org/w/index.php?diff=158491&oldid=172031&title=Main_Page&type=revision there's a ticket for that so we have it on or monitors. https://phabricator.wikimedia.org/T168609

Reply to "Issue: Revision slider doesn't display the yellow lines properly when current revision is older than the one being compared"

The new revision slider does not work at all on mobile devices

IKhitron (talkcontribs)

Hi. It's the first time I saw the new interface, in mediawikiwiki. I can see the summaries, but the bolls do not move at all. Not by clicking on different area, and not by drag and drop. The slider became unusable. Help!

Android 6.0, inner browser, desktop view. (talkcontribs)

It is not clear what you mean. Revision slider is a tool designed for desktop users not mobile devices, so it is not clear why you're asking for "help". That is probably why it doesn't show up in the normal mobile view. This might require significant work. For it to work in a mobile device they need to change the interface to work with touch (and non-touch) based events and possibly reduce the number of revisions fetched due to smaller screen sizes and generally lower bandwidth.

Even then, it would probably still not work well using the desktop view. Although the older version kind of works, it still has issues, e.g. popups can't appear until clicked because there is no hover in most mobile devices, and having two diffs in a tiny screen makes it hard to read either of them.

This could be a feature request rather than a bug report ... (talkcontribs)

It might be a good idea to disable it fully on mobile devices, even using the desktop view until they decide if they want to support it.

IKhitron (talkcontribs)

You are wrong. It works very well in desktop view on mobile devices in the old version. There should not be any difference, because desktop view is the same, doesn't matter if some event is triggered by a mouse or by a touch screen, they are equivalent. Some regression code change in the new version made this.

Jan Dittrich (WMDE) (talkcontribs)

Thanks for your feedback. We look into it and see what can be done. A college created an issue for that on phabricator: https://phabricator.wikimedia.org/T164249

Tobias Gritschacher (WMDE) (talkcontribs)

I've compared the "old UI" and the "new UI" on (1) Chrome on an Android 6 phone and (2) Chrome on a Windows 10 Notebook with touch-display.

Outcome: For both UIs (old and new) touch-drag-n-drop does NOT work (I guess it never worked and this is probably limited by the draggable-library we're using) but clicking on the bars WORKS for both versions though it got slightly more difficult with the new UI since the clicking-area got smaller (you have to touch the colored, horizontal lines in order to move the pointers).

IKhitron (talkcontribs)

So, it looks like browser depended. I work on Android 6, inner browser, and the ood RS always works perfect, d&d and bars.

IKhitron (talkcontribs)

I change my mind. It does not work by d&d now. But I'm sure it worked earlier. (talkcontribs)

Someone, help...No. no! Somebody's, LOST IT ALL, For the Evaluative @RE DO PURPOSE.

Reply to "The new revision slider does not work at all on mobile devices"

It is now on English Wikipedia and it is great!

FeralOink (talkcontribs)

Today is the first time that the Revision Slider showed up when I was looking at a revision history on my home Wikipedia, en. It is great! It works perfectly. The instructions overlay was helpful although the tool is so well-designed that it is almost self-explanatory. The RevisionSlider is delightfully precise because of those nice end points in yellow and blue. The slider moves smoothly, and supports some of the accessibility features that I have enabled in my browser due to my minor vision issues.

This tool is actually better than those that I have seen for similar purposes offered on for-profit websites. The German Wikipedia developers and UI designers who created this tool did an EXCELLENT job! Thank you for taking care of us so well. I just noticed that you are taking care of ALL of, as this is a RTL accessible extension!

Birgit Müller (WMDE) (talkcontribs)

Hi @FeralOink, thank you so much for your great and detailed comment! This is really encouraging feedback :-)

Have a nice day! Birgit

Perhaps it is time to move this feature out of beta?

Summary by (talkcontribs)

Just curious, but is this feature still beta in certain wikis?

Based on Beta Features, such features aren't meant to be left there indefinitely. Given that it seems as this extension is now stable in certain wikis, it should probably get an announcement and removed as a beta feature, see :

So either this needs to become an optional full feature, or yanked from every wiki that doesn't want it. If nothing else, it might drive individual wikis to ask for it to be enabled by default for casual editors, instead of become a gravestone in "graveyard of discarded ambitions".

Considering its popularity [1] chances are that it may become a default wikimedia extension and encourage volunteer developer improve its feature set due to widescale usage ... (talkcontribs)

*instead of becoming

Addshore (talkcontribs)

Feature rollout is currently being planned :) (talkcontribs)

You mean more feature rollout as a beta, or as a full optional feature?

Anyway, hopefully it won't beat Gmail's beta period record(http://www.slate.com/articles/news_and_politics/recycled/2009/07/why_did_it_take_google_so_long_to_take_gmail_out_of_beta.html) :).

Thanks for the update.

Tobias Gritschacher (WMDE) (talkcontribs)


RevisionSlider is a beta-feature on all wikis since September 2016, see https://phabricator.wikimedia.org/T143421#2632809. We're currently still testing a slightly different UI based on past user feedback (see https://phabricator.wikimedia.org/T160410) and after giving us some time to receive some feedback on the implementation of this we're aiming to leave the beta-feature-status on all Wikipedias soon after.

IKhitron (talkcontribs)

Unfortunately, there is still a hook bug. It looks like it should be fixed before the move.

Christoph Jauera (WMDE) (talkcontribs)

Just a small update here:

The hook bug mentioned by IKhitron was fixed in the meantime.

As Tobias mentioned we are currently in the process of testing a different UI. You can find the newest version of the alternative UI on Beta, test.wikipedia.org and here on mediawiki.org.

- Please note, that the version on test and mediawiki has some minor issues with the tooltips right now. The fixes for that should be deployed during next week though.



IKhitron (talkcontribs)

Hi, Christoph Jauera (WMDE), I checked just now, it still doesn't work. Partially. Some problems disappeared indeed, not all of them.

Christoph Jauera (WMDE) (talkcontribs)

Hey, @IKhitron that's sad to hear. Could you create a new ticket or comment in the existing one with the problems you still get? - That would be great!

Thanks in advance,


IKhitron (talkcontribs)

Where is the ticket, I don't remember, Christoph Jauera (WMDE)? The problem I can see is that after usage of RS, for one revision, thanks action opens thanks page, in place of regular inline question.

Christoph Jauera (WMDE) (talkcontribs)

Here you go: https://phabricator.wikimedia.org/T142636 :-)

IKhitron (talkcontribs)

Thanks, Christoph Jauera (WMDE). Looks as it will be deployed next week, because of the switch. So, I'll just wait. (talkcontribs)

> As Tobias mentioned we are currently in the process of testing a different UI. You can find the newest version of the alternative UI on Beta, test.wikipedia.org and here on mediawiki.org.

The new UI is definitely more intuitive than the older one. Dragging and dropping with the old one was a bit confusing and hard to get used to. So this will likely be a welcome improvement.

Great work!

Yeryry (talkcontribs)

How can I get the old one back? The new version is significantly inferior, IMHO. I probably could have just used a userscript to emulate the old version easily enough before, but now that it's out of beta that isn't so easy.

Lea Voget (WMDE) (talkcontribs)

Hi @Yeryry thanks a lot for your feedback! Is what is troubling you the fact that you can't click on bars anymore? We are currently working on getting this back - without losing the metaphor we introduced with the new design. If you want, you can follow https://phabricator.wikimedia.org/T165831 to be up to date of our current plan. But if you are missing something else, please let us know!

Yeryry (talkcontribs)

Yes, being able to click above and below (not just on the bars) was much quicker and easier than it is now. Also (from T160410) "Pointers cannot be moved further than where the other pointer is" this was very useful, and while users would have needed to get used to how it works, they still do for the new version, which needs more effort to achieve the same results. I also feel the visual design of the old version was much better, but that's another question...

Lea Voget (WMDE) (talkcontribs)

Hey @Yeryry, thanks for specifying. I can see that moving the pointer past the other pointer is a shortcut once you understood the system. When testing the revisionSlider with people who were no experts yet, though, this was one of the things that was the most confusing. In their favor we decided to take that option out, and the new design is understood by far better if people have not trained a lot with the old design. However, I created a ticket ( https://phabricator.wikimedia.org/T166541 ) so we have a place to gather ideas how to allow expert users to use the function without making it more complicated for people with less experience.

Thanks again for your feedback!


Reply to "Perhaps it is time to move this feature out of beta?"

New version does not work

Summary by Lea Voget (WMDE)

It does work, but not the same way that was appreciated here in the old UI

(closed until there are more news from WMDE about bringing back the clicking on bars)

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 :)



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)

Are you interested to know my reasons, Lea Voget (WMDE)?

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. (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. (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. (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 :)

Bultro (talkcontribs)

When the tool has just been opened, in its initial range, the blue dot (newer revision) is placed at the far right of the slider. Previous revisions are shown, but later revisions are not, until the user presses the forward arrow. Basically, I have to press the forward arrow every time... It would be better if dots were initially placed towards the middle of the slider, instead of the far right (unless, of course, the user started from the last revision).

Christoph Jauera (WMDE) (talkcontribs)

Hi @Bultro,

thanks for your post. The issue you describe is already known to us and there is a ticket on Phabricator: https://phabricator.wikimedia.org/T145645 for it. Improving the situation there without increasing the loading time for every use is not trivial that's why we - for now - do not work on it. You can look the conversation up in the ticket. If there are any new developments around the topic we will keep it updated.

Best and thanks again,


Reply to "Initial range of slider"
L3X1 (talkcontribs)

This new tool is awesome and will save on many frustrasting trips back and forth in the history. Barnstars for all involved!

Lea Voget (WMDE) (talkcontribs)

Thanks @L3X1! We are very happy to hear that :)