Change 685031 had a related patch set uploaded (by Ori.livneh; author: Ori.livneh):

[mediawiki/extensions/ChessBrowser@master] Remove auto-play feature

https://gerrit.wikimedia.org/r/685031

Change 685031 merged by jenkins-bot:

[mediawiki/extensions/ChessBrowser@master] Remove auto-play feature

https://gerrit.wikimedia.org/r/685031

several comments:

• "play" button for autoplay is expected in any interactive chess viewer, and it was a mistake to remove it. please visit any number of chess websites which provide interactive play (practically all of them do...)
• "faster" and "slower" can be removed. indeed, on ruwiki, the standalone is configured not to show them (in the standalone, passing a "delay" parameter for autoplay has a side-effect of not showing the speed controls) so i think the ruwiki wikipedians also think the fast/slow are not superfluous
• there is no need to modify the JS piece. it does not add or remove buttons, and if a button is not there, it will naturally not be hooked to any event.

IMO:

• roll back the JS change. leaving the fast/slow code has negligible cost - a couple of three-liners, and 2 additional lines to hook them to the buttons. i'd rather keep it there
• the back-end modification should be partially reverted, to restore the play/pause button.
• bonus points: add a "delay" parameter to the <pgn> tag, presumably in ms, and teach the JS to use it, so the editor (or the template) can set the autoplay tempo. it should not be less than the "transition" parameter in the css, so a piece will not start its journey before the previous move is completed.
• extra bonus: add another config item to add the speed controls anyway: some sites (wikibooks, wikiversity, whatnot, may find it useful.

peace.

In T281649#7064386, @Kipod wrote:

several comments:

• "play" button for autoplay is expected in any interactive chess viewer, and it was a mistake to remove it. please visit any number of chess websites which provide interactive play (practically all of them do...)

The most prominent one I know if is lichess. Lichess does have an autoplay feature — tucked away in a hamburger menu. The controls on the toolbar are the same four we currently enable.

Note that this is a full-screen chess analysis interface on a website dedicated to chess. I think simplicity and minimalism is even more important on wikis, where chess content will be most commonly encountered embedded in articles.

lichess is not the model.
look for any site which holds large library of games in PGN format, and look at the interactive game interface. first i stumbled on (from enwiki article) https://www.chessgames.com/perl/chessgame?gid=1129672
autoplay is useful feature. talk with chess aficionados. at the very least we should consult the authors. i asked on their talk page. (see enwiki:Wikipedia talk:WikiProject Chess ).

as to the "safety" of events coming from more than one source - it's not a real issue. this is how js works., and imo, it's a straw argument.

i'll be somewhat blunt (sorry): if i understand correctly, this is already merged into master. a bit hasty, isn't it? this story was created, like, five days ago. @Wugapodes, any thoughts? i suggest to revert it for now, and talk with the authors (of both the articles and the extension).

In T281649#7064204, @gerritbot wrote:

Change 685031 merged by jenkins-bot:

[mediawiki/extensions/ChessBrowser@master] Remove auto-play feature

https://gerrit.wikimedia.org/r/685031

peace

@Kipod: I reverted the patch, and I apologize for being hasty. In hindsight, I should have made my case here and waited for consensus.

In the interest of consolidating the discussion here, I'll paste my rationale from the commit message for If171cb4 below:

The auto-play feature complicates the extension's user interface.

• It makes the user interface harder to understand. The meaning of 'walking person' and 'bicycle' is not obvious. I am not sure that there is a suitable replacement icons that would convey how these buttons behave. I think this makes the extension less inviting to new users.
• It makes it harder to provide a good, consistent experience across a broad range of devices. The feature adds three buttons to the toolbar, bringing the total to eight. The recommended minimum size for touch-interface buttons is around 11mm[1], so 8 buttons = 88mm (with no spacing), which is already wider than many mobile phones.
• JavaScript code that uses timers is bug-prone. I don't have data for this, but that has been my experience.

The feature could always be added back if users clamor for it. For the initial launch, I think it's best to pare down features to the essentials. Features can become obstacles to further development and refinement of this extension because it is harder to take features away than it is to add them.

First, @Kipod I believe I merged the change since @ori had other changes that depended on it with the understanding that we could easily revert it if need be. But yes I agree with Ori that consolidating discussion here would have saved a lot of headaches.

I want to build off Kipod's suggestion of a "delay" parameter and suggest we make these optional features that each wiki can configure as-needed. There are a lot of use cases for this extension: not only on Wikipedias but also Wikibooks, Wikiversity, and quite possibly some non-WMF wikis. Some of those communities might find autoplay useful while others might prefer the simple interface. I think that's a decision we should leave to the wikis rather than deciding right now.

Similarly, the non-arrow icons are culturally-dependant (bicycles and yin-yang symbols not having universal meanings). I think allowing wikis to configure the icons would be the best way to accommodate various contexts without us having to sit down and decide the icons for every wiki.

W/r/t how that might all be implemented I suggest:

• Add an autoplay=BOOL parameter to the parser tag that lets users control autoplay on a case-by-case basis.
• Add a delay=INT parameter to the parser tag that lets users control the move delay on a case-by-case basis.
• Define the icons as system messages so that (interface) admins can modify the image files used by editing a page in the MediaWiki namespace.
• Define configuration settings that will allow server admins to enable or disable autoplay site-wide.

Thoughts?

bicycles and yin-yang symbols not having universal meanings.

If rotation was kept, could probably be something similar to (badly self-created)

If kept at all, Faster/Slower makes more sense as a slider nowadays I'd say. Or speed indicator style:

Thanks @Aklapper! I think the icon does a good job of indicating what the button does (and it looks good too!). A slider is also a nice idea as it sidesteps some of the icon choice issues. Fitting it into the UI might take a bit of reorganization to make visually appealing. My first idea was something like below where the play button and slider were below the board and the next, last, etc buttons were between the board and move list.

interestingly, the first implementation of the standalone introducing speed control used slider.
never got it to be satisfactory.
if i may, i think it will be better and more useful to have a single "speed control" button, which will allow the reader to enter the delay numerically.

several reasons: the slider ended up being cumbersome to use, did not give good control (might have been my fault), did not give feedback to the reader telling them _what_ delay did they just set, it takes too much real estate, while being rarely used, and has upper limit.

i also think the "natural" place for the "play/pause" button is the same place i found it in the philips compact cassette recorder 50 years ago or so, and saw it since on countless players: between "forward" and "backward".

back to speed control: maybe overload the play/pause, such that double-click will open the speed-control form. this will be the "cleanest" appearance, saving an extra button, at the cost of speed control being somewhat "hidden feature".
the feature can at least be exposed by a tooltip.
alternatively, add a button, maybe with hourglass icon or such, which will open a form (bonus points: form can have both slider and numeric input...)

bonus points: the "speed control" form can have both slider _and_ numerical input , doing double-duty as slider readout.

peace.

In T281649#7084227, @Wugapodes wrote:

....
suggest we make these optional features that each wiki can configure as-needed.
.....
Thoughts?

here are some thoughts:
in my view, it's best to have the extension contain "everything including the kitchen sink", enable "out of the box" what makes sense, and allow installations to define "defaults" (overriding the inbuilt defaults) via configuration file, and allow overriding the site defaults via parameters to the <pgn> tag.

one such configurable option is which buttons to display.
some others have to do with notation (use K or the unicode character for chess king? in hewiki we are using letters, in ruwiki they use icons), comment handling (and if comment are allowed, whether or not to have the "hide comments" button...), and maybe some other stuff.

this is a media-wiki extension, and with it, i can imagine more than one non-wikimedia wiki, maybe chess-dedicated, which may find it useful. we should try to predict the needs and wants of such sites, but we should not drop potentially useful features because we don't think we want them on wikipedia - we should leave it in the extension, and allow suppressing such "superfluous features" via config.

.......
Define the icons as system messages

i do not see real advantage in defining the icons as system messages: the natural place to define the icons is the CSS page, which is editable on each installation. this is where (whoever) wants to change any icons will look first. the extension should look for a local CSS page with a known name (say, Mediawiki:Extension:ChessBrowser/style.css), and load it if exists, if it doesn't do something like this already.
this is essential for sites if they are to have more control (trivia: on hewiki, the knight's movement is sort of in arc, which i thought is cute, and done entirely via css).

peace

peace.

In T281649#7084227, @Wugapodes wrote:

....
suggest we make these optional features that each wiki can configure as-needed.
.....
Thoughts?

here are some thoughts:
in my view, it's best to have the extension contain "everything including the kitchen sink", enable "out of the box" what makes sense, and allow installations to define "defaults" (overriding the inbuilt defaults) via configuration file, and allow overriding the site defaults via parameters to the <pgn> tag.

one such configurable option is which buttons to display.
some others have to do with notation (use K or the unicode character for chess king? in hewiki we are using letters, in ruwiki they use icons), comment handling (and if comment are allowed, whether or not to have the "hide comments" button...), and maybe some other stuff.

this is a media-wiki extension, and with it, i can imagine more than one non-wikimedia wiki, maybe chess-dedicated, which may find it useful. we should try to predict the needs and wants of such sites, but we should not drop potentially useful features because we don't think we want them on wikipedia - we should leave it in the extension, and allow suppressing such "superfluous features" via config.

.......
Define the icons as system messages

i do not see real advantage in defining the icons as system messages: the natural place to define the icons is the CSS page, which is editable on each installation. this is where (whoever) wants to change any icons will look first. the extension should look for a local CSS page with a known name (say, Mediawiki:Extension:ChessBrowser/style.css), and load it if exists, if it doesn't do something like this already.
this is essential for sites if they are to have more control (trivia: on hewiki, the knight's movement is sort of in arc, which i thought is cute, and done entirely via css).

and lastly, to the "which icons" question:
the yin and yang was just too cute to pass. i like it, and liked it enough to teach it to rotate when inverting VP.
regarding faster/slower: on the "prototype demo" those were replaced long time ago with deer/snail, but my current thinking is that there should be a single button, with hourglass icon (we don't really control "speed", but rather "interply delay", so i think it makes sense) which will open a "speed control" form. talked about it in previous comment.

peace

peace

looked at the beta.
saw for the first time how "flip" also rotates the board itself, not just the button. super cute.

some nitpicking regarding the css:

• the row and file legends are not aligned well. note that even if vertical align was defined as middle (as it should), it's not enough - the spans should have widths and/ or heights 12.5%.
• would be nice to "justify" the whole line or row of legends towards the board, with some controlled margin

to illustrate (actual css should prolly be a bit more clever, and treat each set of legends differently to control justification)

span.pgn-file-legend, span.pgn-row-legend {
    height: 12.5%;
    width: 12.5%;
    text-align: center;
    vertical-align: middle;
}

(side topic: not the controls, but still discussing the front-end script)

i'd like you guys to look again at the "prototype" - it still has some features not ported. basically, adding an arrow to indicate the last ply, and marking the "source/destination" of last ply by some css class, which can then be used to place markers or whatnot.
of course, they don't really make sense together (as in the prototype), but either one seems useful, and more than one chess site has one or the other.
my thinking is that this should be disabled in the "mainline" configuration, but still available in the extension, and may be useful to some wikis.

technically speaking, the markers can be imported and not even made configurable - all the tiny code does is toggle "source" and "destination" classed, so sites can control visibility by adding or modifying them.

The arrows are something else - they are implemented using canvas, so a parameter should be passed from the backend telling the js piece whether or not to draw them.
both can be found in the "showPly()" function. i think the cost is ~50 lines or so. some more code will be needed to interpret the configuration to decide which to activate (or more practically, whether or not to draw the arrow. the source/dest class toggling is practically for free)

here is the proto source: https://www.mediawiki.org/wiki/User:%D7%A7%D7%99%D7%A4%D7%95%D7%93%D7%A0%D7%97%D7%A9/chess-animator.js

peace.

I still need to look into a lot of what @Kipod suggested, but it looks like the button images are already implemented in CSS. This means that users and wikis can override them as they want using their local CSS pages, and I've tested that on the beta cluster. I also added documentation on the extension page on how users can do that.