Re: RE[2]: New maintainer, plans for the future of XBoard

--0000000000007a036805d0a1ebd8
Content-Type: text/plain; charset="UTF-8"

Discoverability is always a challenge. Back when I was working on
xboard/WinBoard, I would get a lot of mail from people with suggestions and
questions, and those gave me some hints on what features were hard to
discover. For instance *I* really liked that in board edit mode, middle
click would bring up a menu of white pieces to drop and right click would
bring up a menu of black pieces. But I got a zillion "bug" reports from
people who only tried the right-click menu because menus aren't normally on
the middle button, saying that edit position could only drop black pieces.

I also learned that most people don't read the manual -- but I tried to
make it complete anyway, of course, at least for old timers like me who do
read the manual.

Discoverability is partly about guessing what people will expect. The UI
pros talk about "affordances," which (as I understand it) basically are
things that are obvious on the screen such that people will expect them to
do something if clicked -- and preferably what they expect is what will
actually happen.


On Tue, Nov 9, 2021 at 3:07 AM <[email protected]> wrote:

>
>
>
>
> Op di., nov. 9, 2021 om 01:07, Simon Scatton <[email protected]>
> schreef:
>
>
> H.G.: do you want me to push your changes to the actual repo or will
> you be able to recover your password and push them?
>
>
> Well, let us first try to somehow revive my account on the git.sv.gnu.org
> machine.
> I discovered that I still had another patch (in another git branch) that
> should be
> added to the v4.9.x branch, and that I still have uncommitted changes in
> that
> other branch (not existing on Savannah).
>
> My developing activities were cut off abruptly because my desktop let me
> down
> beginning this year: if I could boot it at all, it crashed with a blue
> screen after
> a few times per hour. I solved that problem only recently.
>
> The Janggi implementation should be more or less finished, though. I had
> created
> a new branch for rewriting the code that handles probing the opening book,
> presumably because it did not work well for Janggi (which is special
> amongst
> chess variants in that it allows turn passing at any time). The current
> book code
> is an absolute mess, which initially started as a simple hack. But then it
> turned
> out to fail in many special situations, which were then fixed one by one by
> adding more patches testing for these situations. The basic problem was
> that
> XBoard does not keep track of the actual 'player state' the engines are in
> (playing white, playing black or force mode). The gameMode variable only
> keeps track of what state the engine should be in. But when using the book,
> XBoard is selecting the book moves on behalf of the engine that has to
> play,
> while the engine itself has to be put in force mode to feed it the book
> (and
> opponent) moves. The problem is to recognize when the engine should leave
> force mode (when it gets out of book) and receive a 'go' command. Keeping
> track of true engine state at all times would make this conceptually
> simple,
> but the current code does not do that.
>
> As to the look of XBoard:
>
> I will eagerly await the screenshots for the suggestions you have for this.
> I am not sure what people mean when they say that XBoard looks obsolete.
> The main window basically only shows a chess board and clocks.
> Is it that people don't like pull-down menus? What some of the newer
> commercial software uses instead of those (e.g. MS Paint) strikes me
> as absolute garbage...
>
> I often get the complaint that XBoard/WinBoard has a poor
> 'discoverability'.
> There are many features that people apparently completely miss, because
> they would rather die that read a manual or tutorial. This might be the
> most
> important aspect that could be improved. Except that I am not sure how.
>
> Regards,
> H.G.
>

--0000000000007a036805d0a1ebd8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Discoverability is always a challenge. Back when I wa=
s working on xboard/WinBoard, I would get a lot of mail from people with su=
ggestions and questions, and those gave me some hints on what features were=
 hard to discover. For instance *I* really liked that in board edit mode, m=
iddle click would bring up a menu of white pieces to drop and right click w=
ould bring up a menu of black pieces. But I got a zillion &quot;bug&quot; r=
eports from people who only tried the right-click menu because menus aren&#=
39;t normally on the middle button, saying that edit position could only dr=
op black pieces.</div><div><br></div><div>I also learned that most people d=
on&#39;t read the manual -- but I tried to make it complete anyway, of cour=
se, at least for old timers like me who do read the manual.<br></div><div><=
br></div><div>Discoverability is partly about guessing what people will exp=
ect. The UI pros talk about &quot;affordances,&quot; which (as I understand=
 it) basically are things that are obvious on the screen such that people w=
ill expect them to do something if clicked -- and preferably what they expe=
ct is what will actually happen.</div><div><br></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Nov 9, 2021 =
at 3:07 AM &lt;<a href=3D"mailto:[email protected]">[email protected]=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<u></u><div><div style=3D"font-family:Tahoma,sans-serif;font-size:16px;dire=
ction:ltr"><div style=3D"font-family:Tahoma;font-size:16px"></div><br><br><=
div></div><br><br><div>Op di., nov. 9, 2021 om 01:07, Simon Scatton &lt;<a =
href=3D"mailto:[email protected]" target=3D"_blank">simon.scatton@ou=
tlook.fr</a>&gt; schreef:</div><blockquote><div><br>H.G.: do you want me to=
 push your changes to the actual repo or will<br>you be able to recover you=
r password and push them?<br></div></blockquote><div><span><br></span></div=
><div><span>Well, let us first try to somehow revive my account on the <a h=
ref=3D"http://git.sv.gnu.org" target=3D"_blank">git.sv.gnu.org</a> machine.=
</span></div><div><span>I discovered that I still had another patch (in ano=
ther git branch) that should be</span></div><div><span>added to the v4.9.x =
branch, and that I still have uncommitted changes in that</span></div><div>=
<span>other branch (not existing on Savannah).</span></div><div><span><br><=
/span></div><div><span>My developing activities were cut off abruptly becau=
se my desktop let me down</span></div><div><span>beginning this year: if I =
could boot it at all, it crashed with a blue screen after</span></div><div>=
<span>a few times per hour. I solved that problem only recently.</span></di=
v><div><span><br></span></div><div><span>The Janggi implementation should b=
e more or less finished, though. I had created</span></div><div><span>a new=
 branch for rewriting the code that handles probing the opening book,</span=
></div><div><span>presumably because it did not work well for Janggi (which=
 is special amongst</span></div><div><span>chess variants in that it allows=
 turn passing at any time). The current book code</span></div><div><span>is=
 an absolute mess, which initially started as a simple hack. But then it tu=
rned</span></div><div><span>out to fail in many special situations, which w=
ere then fixed one by one by</span></div><div><span>adding more patches tes=
ting for these situations. The basic problem was that</span></div><div><spa=
n>XBoard does not keep track of the actual &#39;player state&#39; the engin=
es are in</span></div><div><span>(playing white, playing black or force mod=
e). The gameMode variable only</span></div><div><span>keeps track of what s=
tate the engine should be in. But when using the book,</span></div><div><sp=
an>XBoard is selecting the book moves on behalf of the engine that has to p=
lay,</span></div><div><span>while the engine itself has to be put in force =
mode to feed it the book (and</span></div><div><span>opponent) moves. The p=
roblem is to recognize when the engine should leave</span></div><div><span>=
force mode (when it gets out of book) and receive a &#39;go&#39; command. K=
eeping</span></div><div><span>track of true engine state at all times would=
 make this conceptually simple,</span></div><div><span>but the current code=
 does not do that.<br></span></div><div><br></div><div>As to the look of XB=
oard:<br></div><div><br></div><div>I will eagerly await the screenshots for=
 the suggestions you have for this.</div><div>I am not sure what people mea=
n when they say that XBoard looks obsolete.</div><div>The main window basic=
ally only shows a chess board and clocks.</div><div>Is it that people don&#=
39;t like pull-down menus? What some of the newer</div><div>commercial soft=
ware uses instead of those (e.g. MS Paint) strikes me</div><div>as absolute=
 garbage...</div><div><br></div><div>I often get the complaint that XBoard/=
WinBoard has a poor &#39;discoverability&#39;.</div><div>There are many fea=
tures that people apparently completely miss, because</div><div>they would =
rather die that read a manual or tutorial. This might be the most</div><div=
>important aspect that could be improved. Except that I am not sure how.</d=
iv><div><br></div><div>Regards,</div><div>H.G.<br></div></div></div>
</blockquote></div>

--0000000000007a036805d0a1ebd8--