search

viresh-ratnakar / exolve

Online interactive crossword software in JavaScript
MIT License
73 stars 15 forks source link

For nodir clues without known cells, provide cell associations for reveal* #25

Closed viresh-ratnakar closed 4 years ago

viresh-ratnakar commented 4 years ago

This was originally framed by https://github.com/Antagony1060 like this:

It's just occurred to me that providing 'solved' answers in a puzzle is slightly problematic presently. Because, unlike with questions, there is nowhere to put the answers, except as part of annotations. Perhaps you could create a mechanism based on putting answers in curly brackets say, immediately after the enumeration – which, if present, enables the 'Reveal this' button and using that puts the answer into the input field? Just a thought…

And this:

I realise my earlier suggestion to somehow link matched answers with clues is probably a tall order and likely prone to user input errors, but I've been playing around with this new feature a lot – I've almost got a puzzle ready for publication – and the disconnectedness of the three main elements, grid, clue list, and the overhead clue bar, feels like it could be a little confusing for some users. In fact I was just thinking if only the latter two were tied together it might be enough to address that issue.

My current thinking is to allow (in a puzzle with solutions that has nodir clues without cell associations specified) cell associations for nodir clues to be provided (only for revelations through reveal-this and reveal-all) like this: [P 18d] This clue goes on ... (6) and/or like this: [Q #a14 #b15 #c16] Up and away blah... (3)

Then, once the clue has been "reveal"ed, we can grab the solution letters from the right cells, highlight them as well as fill them into the placeholder slot.

Antagony1060 commented 4 years ago

I like it! My first thoughts on the method is that entering cell locations into every clue would be a chore and likely prone to errors, so my preference is the clue number/s option. In fact funnily enough, a while ago I considered posting another feature request for an exolve-colour option to just use clue numbers, but I decided it was quite trivial and didn't want to bombard you with my ideas.

Just to be clear about the second quote: I was also thinking of unsolved grids from the user's perspective. I think the reason it feels a bit confusing as it stands is because you can select an item in the clue list, but then clicking in the grid changes the current clue panel overhead to show whichever clue was previously selected. I think if you could tie those two things together – so that the current clue is the same when going from the clue list to the grid or vice versa – it would feel more coordinated. I hope I've explained that well enough.

E: missing words.

viresh-ratnakar commented 4 years ago

Haven't really done this, but did revamp tab navigation substantially in v0.56. Also, you can now set a clue state as solved (or toggle to unsolved) by clicking on the clue number in the clues table.

Antagony1060 commented 4 years ago

Weird! I could have sworn I'd posted a reply about this the other day. I guess I must have forgotten to hit the comment button.

I like the manual toggle feature, but as I said in the other thread, it could kinda do with a tristate toggle for jigsaws, to distinguish between nothing entered, placeholder only entered, and entered in the grid.

By the way, I'm not sure if it's intentional or you are aware or not, but one of the recent updates has realigned the clue numbers in the clue lists and I think it's made them less clear when clues are linked. Here's a clue list for a recent Private Eye puzzle for v0.54:

image

And here it is for v0.58:

image

Neither of them are perfect – there doesn't seem to be as much space provided for the across clues so 9,17 has been split in both cases, for example – but I do think v0.54 was clearer nevertheless.

Edit: I think I've seen other puzzles where the space given to down clues seems reduced too. I feel it might be related to the length of the longest clue's text.

viresh-ratnakar commented 4 years ago

Re: allow manually toggling between three states in jigsaw puzzles: Hmm, I'm not quite convinced of this. I think the visibility of the placeholder text already achieves this to some extent (you can easily see which clues have filled placeholders and which clues do not). Having three states would mean more ways to things to get out of sync (if you add or delete or modify a filled placeholder, for example).

Re: display of linked clue numbers. So, around v0.57 or v0.58, I had changed the text alignment of the clue numbers column to be "right aligned" instead of "left aligned," to better mimic the nice/standard look in most printed puzzles, especially for the single-digit clue numbers. You're right though, linked clues with that change looked worse than before. Note that the slight difference in the space (width) given to down/across clues also came from the length of the longest list of linked clue numbers (not clue text), clamped to a maximum. You're also right that linked clue numbers did not look particularly great before the change either :-).

But now, with v0.59, I have fixed the situation by special-casing linked clue numbers, similar to their treatment in printed puzzles (eg, these Guardian PDFs: https://crosswords-static.guim.co.uk/gdn.cryptic.20200228.pdf and https://crosswords-static.guim.co.uk/gdn.cryptic.20200304.pdf). The comma-separated list of linked clue numbers now "spills over" into the clues column, pushing the start of the clue text.

Antagony1060 commented 4 years ago

Linked clue numbering is much better now, thanks!

As for the manual toggling: while you're right that entered placeholder text does identify itself to some extent, it's not so easy to pick out the unfilled ones at a glance due to their being pre-filled with question marks. I can see the utility of that, but perhaps it would help if you replaced them with something less obtrusive, like middle dots (·) say?

For comparison,
With QMs: image

And with middle dots: image

What do you think?

viresh-ratnakar commented 4 years ago

Yes, that (middle dots) looks like a nice improvement. Making it so, shortly!

viresh-ratnakar commented 4 years ago

Done: v0.60 uses middle dots. Thanks for the suggestion!

Antagony1060 commented 4 years ago

Excellent! It's a lot easier to see which placeholders are still empty now, thanks.

viresh-ratnakar commented 4 years ago

Please update https://antagony.droppages.com/potd/potd010 when you get the chance. I haven't tried it yet, and will do now, both for fun and to see how the jigsaw solving experience with Exolve is like now — whether any further tweaks are warranted. Thanks!

Antagony1060 commented 4 years ago

It's done. One thing to note if you're not based in the UK and haven't seen the reddit thread: one of the answers is spelled differently in the US and at least one of the clues is slightly UK-centric. Although I doubt either will pose too much difficulty for you.

Something you might want to look at is adding ‘reveal’ and ‘clear’ for the placeholders. I just cleared the grid to check how it looked and I see all the placeholders are still filled. That said, I can see a common scenario with jigsaws where the solver will want to clear the grid but not the placeholders, so maybe 'clear all' for them should be either a separate button or require the grid to already be emptied first – effectively making it a two click operation like the individual light clearing process.

viresh-ratnakar commented 4 years ago

Did the puzzle—was good fun! Posted a comment in the reddit thread too.

I think Exolve worked pretty well for the jigsaw stuff (thanks in large part to suggestions from you). I did find a couple of bugs/issues that I'll fix in the next release: (1) "Clear this" clears a light completely and immediately, including crossing letters, in this puzzle but not in regular puzzles. (2) When I click on the placeholder slot in a clue, I expect the focus to visibly stay there (it currently jumps to the clue on top, which is the same clue, and typing there types in the placeholder slot in the clues table too, but still, would be good to see the blinking cursor where it is expected).

Antagony1060 commented 4 years ago

Thanks! I'm glad you found the puzzle good fun.

Yeah, I'd noticed the focus jump from the clue list placeholders to the overhead one. I didn't mind it so much on my desktop computer, but I did wonder if it might be annoying on mobile devices.

viresh-ratnakar commented 4 years ago

Fixed the issues (1) and (2) that I had mentioned, with v0.61. Also added a way to clear all placeholders: when the grid has already been cleared, "clear all" will do it (after warning).

Antagony1060 commented 4 years ago

I'm having problems with Github presently as I can't seem to get notifications for updates. I switched the setting from 'Watching' to 'Release only' when it was on v0.59 and I did get notified for v0.60's release, but not for subsequent releases.

Anyway, thanks for the bug fixes and the placeholder clearing method. It works well, but perhaps the note about needing the second click could be added to the first click's message, as mobile and touch screen users will probably miss the hover text.

viresh-ratnakar commented 4 years ago

I've added the note about needing the second click to the first click's message, with v0.63 now.

Re: releases: I generally do not make each new "commit" a "release." I've been making a release every ten commits (at v0.10, v0.20, v0.30, etc.—the next release will be v0.70, whenever I get there). I've just made this convention up and have no idea if there is a better/standard practice that I could be following.

Antagony1060 commented 4 years ago

Thanks for the update.

Yeah, I just realised my assumption that any increment of the version number would be classed as a "release" was mistaken. I even contacted GitHub support because I thought there was something going awry with their notification system. :) I don't know if there is a better/standard practice, but my last message to support was to point out that a lot of work clearly gets done between the official release versions, so I requested they provide an option to receive notifications for every increment of the version number when 'watching' a repository. They've passed that feedback on to the 'notifications team', but of course there is no guarantee they will ever implement it.

viresh-ratnakar commented 4 years ago

FYI, with v0.66, you can now specify entire lights in exolve-nina and exolve-colour (I think you had asked for this at some point):

exolve-colour: green A3 D18 k2

(3-across, 18-down, and the k2 cell will all get coloured green). So, for the current state of AOTW12, you just need:

exolve-colour: #e9feff D19

Also FYI, in v0.65, I got rid of all the boilerplate HTML from the .html file (it is now added by javascript, but backward compatibility is maintained—if the .html file already has the boilerplate, that's fine). This makes the html files simpler to look at, as it just looks like:


....
exolve-end
======REPLACE WITH YOUR PUZZLE ABOVE======
`;

</script>

</head>

<body onload="createPuzzle()">
</body>

</html>
Antagony1060 commented 4 years ago

Yes I mentioned the colour specifier earlier in this thread (here) when we were discussing a possible way to provide placeholder solutions and grid links for reveal operations in jigsaws. As you say, this will make highlighting the latest entry in the ongoing AOTW puzzle a lot easier, so thanks for that.

Removing the boilerplate HTML from the puzzle files seems like a good idea that will hopefully make them seem a bit less daunting to non-coders. I'll give that a try later today.

viresh-ratnakar commented 4 years ago

Finally got around to addressing the actual goal of this bug, with v0.75 (which also now lets you customize the colour scheme).

Summary: exolve-nodir: [A] Some clue (5) [1a] Anno etc..

Details and subtle issues described at: https://github.com/viresh-ratnakar/exolve/blob/master/README.md#jigsaw-puzzle-clues

viresh-ratnakar commented 4 years ago

Closing, as the functionality seems to be working OK so far.

Antagony1060 commented 4 years ago

Sorry, I missed this until today. My GitHub notifications were being spam filtered for some reason – probably due to something inadvertently done by me – and I've only just noticed it.

To be honest I was hoping the placeholder text would also be completed by the ‘Reveal’ functions. In my ‘Alphabetical’ puzzle I've included the answer in bold at the start of each annotation, but I think it would be better if it filled the placeholder instead.

viresh-ratnakar commented 4 years ago

I can probably make this change, but I'm a bit conflicted. I see those placeholders as scratch pads owned by the solver. You could have wrong entries in those, but right entries in the grid, and your solution would be considered correct (for, eg, "Check all" does not check their correctness). Also, there would be some inconsistencies in appearances of revealed answers if a grid has some clues with placeholders and some without (eg, my Wormholes grid). Finally, if a jigsaw clue does not provide the enum but has word breaks or hyphens, the software can at best string together the solution letters from the grid, to reveal in the placeholder slot. One possibility that comes to mind for this last issue is to standardize the way one can provide the solution at the end of a clue. Like "Clue without enum... (?) [ABC-DE'S] (extensible to [ABC-DE'S 12a] for providing jigsaw-light associations).

Let me think a bit more and/or you can try to convince me a bit more. :-)

When you get the chance, please do update to the current version and play a bit with "Reveal this" after adding the associations as described in https://github.com/viresh-ratnakar/exolve#jigsaw-puzzle-clues (essentially like this: [A] Some clue (6) [12a] ANSWER Anno etc.). If you have any thoughts on that, would appreciate them too.

Thanks, Viresh

On Fri, Jun 19, 2020 at 6:49 AM Antagony1060 notifications@github.com wrote:

Sorry, I missed this until today. My GitHub notifications were being spam filtered for some reason – probably due to something inadvertently done by me – and I've only just noticed it.

To be honest I was hoping the placeholder text would also be completed by the ‘Reveal’ functions. In my ‘Alphabetical’ puzzle https://antagony.droppages.com/potd/potd010 I've included the answer in bold at the start of each annotation, but I think it would be better if it filled the placeholder instead.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/viresh-ratnakar/exolve/issues/25#issuecomment-646647194, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJQ562GCXUN7DHZP2PXLFMLRXNUGZANCNFSM4LFEF3FQ .

Antagony1060 commented 4 years ago

Thanks for the response. I've updated the POTD site now, although I had already been testing it with a local version.

First, there seems to be a small glitch with it: if a light is selected in the grid, clicking on a clue then clicking on ‘Reveal’ doesn't work, you have to click on a black square to deselect the light first.

I take your points about the placeholder's function and other complications, I was just thinking it must seem a bit odd to a solver that reveal shows the answer alongside the placeholder instead of in it: image

How about this: since you've employed two-click logic elsewhere in the UI, might it be used again here? So click once to reveal the grid entry and again to reveal the placeholder entry. Perhaps you could issue a warning, contingent on there being any existing text in the affected placeholder/s, that it/they will be overwritten.

As for the problem of enum-less clues, I think a clean method that avoids confusion from a user's perspective would be to have a second square bracket for the placeholder text, thus: [T] The clue (3,6) [10a] [THE ANSWER] Anno etc.

What do you think?

viresh-ratnakar commented 4 years ago

On Sat, Jun 20, 2020 at 10:41 AM Antagony1060 notifications@github.com wrote:

Thanks for the response. I've updated the POTD site now, although I had already been testing it with a local version.

First, there seems to be a small glitch with it: if a light is selected in the grid, clicking on a clue then clicking on ‘Reveal’ doesn't work, you have to click on a black square to deselect the light first.

This was kinda by design. There are two modes internally: whether you are navigating in the grid or in the clues list. The modes generally do not conflict, but in cases like this, they do. I had taken the easy way out for the flow you described. However, I have now (I think and hope!) thought through the possibilities and made it work the way you expect. So this would get fixed in the next version.

I take your points about the placeholder's function and other complications, I was just thinking it must seem a bit odd to a solver that reveal shows the answer alongside the placeholder instead of in it: [image: image] https://user-images.githubusercontent.com/26671658/85207168-dd374880-b31e-11ea-8e67-0dfc5e857833.png

How about this: since you've employed two-click logic elsewhere in the UI, might it be used again here? So click once to reveal the grid entry and again to reveal the placeholder entry. Perhaps you could issue a warning, contingent on there being any existing text in the affected placeholder/s, that it/they will be overwritten.

As for the problem of enum-less clues, I think a clean method that avoids confusion from a user's perspective would be to have a second square bracket for the placeholder text, thus: [T] The clue (3,6) [10a] [THE ANSWER] Anno etc.

I agree with the separate square bracket (in fact had arrived at the same conclusion myself too, after my last email :-)). And with the issue of enum-less clues going away, I think I will just do the simple thing and overwrite the placeholders. If there is no placeholder (i.e., for a regular clue), if the setter has provided a [SOLUTION], it will be rendered after the clue upon "reveal this"/"reveal all," but without the square brackets.

Will let you know when I have pushed the changes.

What do you think?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/viresh-ratnakar/exolve/issues/25#issuecomment-647025493, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJQ562BNHJSC6J33XKPK7ELRXTYDTANCNFSM4LFEF3FQ .

Antagony1060 commented 4 years ago

That's great, thanks.

Now, I'm sorry to throw a spanner in the works, but another thought has just occurred to me: I think filling the placeholder if a ‘Reveal’ is performed in ‘Grid’ mode is absolutely the right thing to do, but I'm wondering whether it should maybe not work the other way around – i.e. when in ‘Clue List’ mode only fill the placeholder and don't enter it into the grid – as solvers may want to still do the ‘jigsaw’ part of the puzzle themselves, if you see what I mean. Or… maybe I'm just overthinking it! :-)

Antagony1060 commented 4 years ago

By the way, I've been meaning to post about another completely unrelated annoyance I've noticed, but it's so minor it's hardly worth opening a new issue for, so I hope you don't mind me mentioning it here: I think backspacing should stop at the first square in the light rather than jumping to the previous light (when there is one). That would make its behaviour consistent with typing in stopping at the last square.

viresh-ratnakar commented 4 years ago

I've uploaded the new version (v0.77) that takes care of most of what we discussed, I think. I am pasting the release notes below, please do read.

A couple of extra notes:

  1. I hear you about the idea to only reveal the solution and not its location when "reveal this" is clicked from the clues list. But I think that complicates the meaning of "Reveal this," giving it different semantics in these two situations. Some situation-specific semantics are inevitable, but in this case I'd prefer to go with the simplicity of consistency. However, what we can do is add a separate feature (perhaps governed by an explicit option) to do this. Pls create a bug and I will get to it.

  2. I started to dislike the italics rendering of annos after looking at your styling :-). So this release also changes the styling (but I went with monospace instead of your sans serif). But do take a look at some of my files (https://viresh-ratnakar.github.io/gussalufz-19-solved.html with "Reveal all" for example).

  3. I think it's getting harder for me to keep track of all possible combinations of scenarios in the code :-). I'll probably spend the next two updates just simplifying the code logic to make it easier to make future changes.

Version: Exolve v0.77 June 20 2020

On Sat, Jun 20, 2020 at 3:01 PM Antagony1060 notifications@github.com wrote:

By the way, I've been meaning to post about another completely unrelated annoyance I've noticed, but it's so minor it's hardly worth opening a new issue for, so I hope you don't mind me mentioning it here: I think backspacing should stop at the first square in the light rather than jumping to the previous light (when there is one). That would make its behaviour consistent with typing in stopping at the last character.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/viresh-ratnakar/exolve/issues/25#issuecomment-647050117, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJQ562GZOSUR63EAU3WDEITRXUWVFANCNFSM4LFEF3FQ .

Antagony1060 commented 4 years ago

Thanks. I've downloaded and had a quick play with it locally. I'll try to look at it in more depth this evening, but so far I'm very happy with the way it's working. It feels like there's a proper connection between the grid and the clue list in jigsaw puzzles now.

I completely agree with what you're saying about the reveal process's behaviour constancy, so I'll only post a request for the restriction option after I've played with it some more and if I still feel it's necessary.

I started to dislike the italics rendering of annos after looking at your styling :-).

Yeah, I like to use italics to indicate fodder omissions/subtractions within the anno, so it made sense to override it. I went with sans serif as an alternative way to make the anno more distinguishable from the clue text, but it does tend to make individually italicised letters quite hard to read sometimes, and monospace improves that. It also makes it a bit more distinguishable I feel, so I will probably drop the font override.

I think it's getting harder for me to keep track of all possible combinations of scenarios in the code :-). I'll probably spend the next two updates just simplifying the code logic to make it easier to make future changes.

I'm not surprised and you do right. It hurts my head just thinking about all the possible usage scenarios, so heaven knows how tough it must be to also have to code it. :\^)

Backspace now does not go back beyond a light boundary (except in linked clues).

Excellent, thank you!

Antagony1060 commented 4 years ago

Okay, I've played around with it further and I think I'm happy with the way it works with jigsaws as it is, so I won't be posting a new issue. On balance I think consistency in the reveal operations is more important than the ‘jigsaw’ element being spoiled by reveal operations. In the unlikely event that any users decide they don't like it, I say let them request a change for themselves. :\^)

One thing to note: I occasionally add very brief annotations to the newspaper puzzles I transcribe into exolve for my own personal use, so I've been checking through those and I've found a small problem: instead of italics I tend to just use square brackets to indicate omitted/subtracted strings, which is fine unless they come at the start of the anno, in which case exolve now interprets them as the answer – e.g. [t]WITTER gets annotated as t. WITTER. This isn't a problem for any of my published puzzles, so I'm not really bothered about it, but I thought it was worth bringing to your attention as it may affect others.

BTW, I don't think it really matters, but you forgot to change the date for the v0.77 release. :\^)

viresh-ratnakar commented 4 years ago

On Mon, Jun 22, 2020 at 11:12 AM Antagony1060 notifications@github.com wrote:

Okay, I've played around with it further and I think I'm happy with the way it works with jigsaws as it is, so I won't be posting a new issue. On balance I think consistency in the reveal operations is more important than the ‘jigsaw’ element being spoiled by reveal operations. In the unlikely event that any users decide they don't like it, I say let them request a change for themselves. :^)

sg

One thing to note: I occasionally add very brief annotations to the newspaper puzzles I transcribe into exolve for my own personal use, so I've been checking through those and I've found a small problem: instead of italics I tend to just use square brackets to indicate omitted/subtracted strings, which is fine unless they come at the start of the anno, in which case exolve now interprets them as the answer – e.g. [t]WITTER gets annotated as t. WITTER. This isn't a problem for any of my published puzzles, so I'm not really bothered about it, but I thought it was worth bringing to your attention as it may affect others.

Good point, thanks. I can add and document some heuristics to stop this misinterpretation. Or I can just add to the documentation that this can happen but can be avoided by preceding with the actual solution, even if it can be inferred from the grid and the enum. Like ".... (6) [WITTER] [t]WITTER ..." (Probably the second approach would be good enough here).

BTW, I don't think it really matters, but you forgot to change the date for the v0.77 release. :^)

I thought I set it to June 20 everywhere... must have missed somewhere.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/viresh-ratnakar/exolve/issues/25#issuecomment-647690823, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJQ562GSN74DBYAW5OCCHWTRX6NIRANCNFSM4LFEF3FQ .

Antagony1060 commented 4 years ago

… must have missed somewhere.

I mass update my files based on the version number and date given in exolve-m.html, so it must be in that.

viresh-ratnakar commented 4 years ago

Ah, I've now uploaded some typo fixes. Fwiw, I had a typo in my bulk command to update the date (sed 's/Jun 13/June 20/' instead of sed 's/June 13/June 20/' :-))

On Mon, Jun 22, 2020 at 12:10 PM Antagony1060 notifications@github.com wrote:

… must have missed somewhere.

I mass update my files based on the version number and date given in exolve-m.html, so it must be in that.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/viresh-ratnakar/exolve/issues/25#issuecomment-647719582, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJQ562CYLDJWQXTG5EQKSWLRX6UDDANCNFSM4LFEF3FQ .