I noticed that the Recent changes page sends requests every 3 seconds (presumably to check for updates), even when "Live updates" is disabled. Verified with Chrome and Firefox.
Shouldn't this only happen when "Live updates" is enabled?
Topic on Talk:Edit Review Improvements/New filters for edit review
>Shouldn't this only happen when "Live updates" is enabled?
Nope, it uses it to detect when there are new changes, and show the "show new changes" link/ button. It would need to be psychic to know it otherwise.
"View new changes" button.
So it is always checking for updates, and enabled "Live updates" causes the immediate load + display of the changed content. Makes sense, but wasn't what I expected (Live update off = no polling – there's still some overhead for low frequency wikis).
Also maybe the "View new changes" button could be a bit more prominent (it looks too much like wiki links).
Live updates seems to still be a beta feature, so most users can't (or don't know how) access it anyway.
> Also maybe the "View new changes" button could be a bit more prominent
This feature should just be re-thought. A more reasonable implementation would be to make it into a "mode" of updates. Either live update or manual refresh / update. Then the same "update" button can be used either manually or automatically. Primarily because the two buttons are mutually exclusive, if live updates is on, then the "view new changes" button is off". This indicates a dependencies between the two features.
It is very likely that this same question is being asked dozens of times in various wikis because that button appears and disappears without any explanation.
The way it currently implemented is just confusing.
> A more reasonable implementation would be to make it into a "mode" of updates.
More modes = more confusion. My expectation was simply:
- old behaviour: I load the page, nothing happens in the background. If I want updates, I reload.
- I use live updates: I load the page + get constant updates. I'm fully aware that there update checks (as indicated by the pulsating button).
Refresh is just so much simpler (keyboard shortcut) thank looking for this "view new changes" button and clicking on it. plus it's not even that much faster at the moment.
> Also maybe the "View new changes" button could be a bit more prominent
Err. It is already a "pseudo-mode". One disables the other, and the user isn't informed that this happens.
> old behaviour: I load the page, nothing happens in the background. If I want updates, I reload.
Of course one will just waste their time reloading if there are no changes, especially if the filters are very specific. Live update fixes that, because if the filters are fine tuned, then one can easily make it catch specific types of vandalism, e.g. stuff easily detected by automated processes like abusefilter et al.
Also, it stops checking if it detects new changes. So it isn't really a big issue in practice.
> Refresh is just so much simpler (keyboard shortcut) thank looking for this "view new changes" button and clicking on it. plus it's not even that much faster at the moment.
Adding a keyboard shortcut, or even "F5" for it is pretty trivial, a userscript can easily do that. It is certainly much faster than reloading the whole page. Reloading the whole page will rebuild the whole interface, and because it is based on javascript this is considerably slower than the older recent changes. Maybe it isn't apparent for people with very high internet connection, but if one deliberate throttles their internet connection to something like GPRS or a bit faster, the huge difference is noteworthy.
I'm not against live updates. I'm just arguing against this "in-between mode" which is confusing.
Some other notifications might be handy (browser tab icon/counter?). This way I could just leave the tab open and see immediately if something has changed. Fastmail for example shows numbers (42) in the title, a nice & lightweight way of notifying users.
> I'm not against live updates. I'm just arguing against this "in-between mode" which is confusing.
Agreed, the magic like behaviour of this "show new changes" stuff is certainly confusing. Interface elements generally should not disappear unless there are very good reasons for it.
Anyway, modern browsers tend to disable javascript when the user navigates to a different tab. The liveupdate or "show new changes" polling also stops when tab isn't active. So unless people plan to always leave the tab active then that tab counter idea won't work. There are probably hacky ways to force the browser to maintain activity, but it is unlikely that they'll pursue it.
For me it keeps polling for live updates, even when the tab is not active. It's just around 100kb for 10 minutes, but still.
Are you sure about browsers suspending JS on inactive tabs? I've never heard of that.
Well, some browsers can certainly do things differently, but top browsers like chrome and firefox certainly do it, see:
- https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout#Inactive_tabs
- https://www.computerworld.com/article/3180754/web-browsers/chrome-makes-power-move-suppresses-background-tabs.html
- https://phabricator.wikimedia.org/T177718
This is especially true of mobile browsers.
Some people have probably experienced this when loading visualeditor. Although in that case it may be worse because of that animation.
Ah ok, thanks. It's not that they are completely disabled, just throttled. It would presumably still be ok to set up a timer to fire every few seconds to poll for updates.
Websockets could be another alternative to polling every X seconds. It would certainly save bandwidth on low-traffic sites. My watchlist sometimes has 30 minute gaps without activity.
Hi guys. Thanks for tis interesting discussion about Live Updates and View Newest Changes. As you surmise, they are linked. There are a lot of ideas here. What, bottom line, would you say you would most like to change, if anything? Are you seeing performance problems? Or are you mostly interested in improving the presentation?
Presentation seems to be the biggest issue here, there are a couple of threads here about how it is confusing. Primarily the problem is that the "view newest changes" button pulls a houdini act whenever clicked and also that it is completely superflous.
One can emulate the same behaviour by clicking live update (or simply F5) and then clicking it again to stop it once the new changes show up. It would also be pretty trivial to make the "live update" button change color or animate or do something when new change show up, rather than having an extra button that consumes a lot of white space for seemingly no good reason.
As far as performance is concerned, it would make more sense for it to use increasing intervals, e.g. if there isn't a new change within 3 seconds, try 6 seconds, 18, 48, 60, etc. There is simply no need to keep checking several times for something that might not happen for several hours on a very small wiki with little traffic.
I'm seeing performance problems with long lists (1000 items). The loading experience is not very smooth – you first see greyed out text, then it seems stuck, then suddenly the page relayouts, causing it to jump.
The presentation could also be improved, the list is displayed mostly unchanged from the old version and is very information dense; some extra whitespace there wouldn't hurt. But I'm sure that would cause new waves of protests.
If more modern technologies like websockets cannot be used I agree with the previous commenter that a exponential-type backoff would be appropriate in order to minimise network overhead.
In general, more powerful filters and highlighting are a welcome addition. What I'm missing is inline diffing (without extensions), as already mentioned in another thread here.
I'm pinging designer @Pginer-WMF, who will have thoughts about the presentation issues. I like the idea of having View New Newest Changes persist (instead of "pulling a Houdini"--I like that), instead changing it's display style in some way to indicate that changes are present.
It's not exactly an interface issue, but it's very close to this topic, so I'll ask it here. If LiveUpdate is off, the check is performed every 3 seconds for the button View New Changes only. So if the button already appears, does the check process cancelled, for performance? The check can be done once when the button clicked, to get all the data from the last periodic check.
@IKhitron it gets cancelled, I verified.
Good, thank you.