Make new puzzle entry easier

[ebroder]

Instead of requiring operators to enter details about puzzles by hand, we should try to do something smarter. There are a few options:

• We could assume that there will be a puzzle list page (a la http://web.mit.edu/puzzle/www/2019/puzzle.html) and try to scrape it somehow. (It might be hard to make assumptions about what the structure of that markup looks like. Maybe we need some hunt-time inputs as to what portions of the page to crawl, like a CSS selector?)
• We could provide a bookmarklet or Chrome extension or some other client-side mechanism for operators to use when they have a puzzle page opened.
• ???

[zarvox]

Another light automation idea here: we could make the puzzle entry form start out with the URL input at the top, and when that input is changed, attempt a fetch() on the URL, and attempt to autofill the puzzle title field with a suggestion by extracting the <title> or a plausible <h1> from the loaded puzzle page, which could potentially reduce copy-pasting/typing.

I imagine operators would still probably need to do some amount of trimming of excess content from autofilled titles, since I suspect they may wind up being like "Puzzle title -- Maybe round title -- Mystery Hunt 2018".

[ebroder]

I could see that working, although I will note that it could break flow for the operator a little bit, as basically while I'm entering a puzzle, I have to sit while I wait for JR to fetch and process the URL, during which time I can't do anything. I can see that coming up especially when there are multiple new puzzles released - today there aren't any delays from JR, just delays from me going back and forth between tabs and copy/pasting things.

[zarvox]

After poking at it briefly, I think CORS means my idea (doing the fetch() from the user's browser) isn't viable in general, and doing it server-side would require the server to keep credentials/cookies, which I think exceeds the complexity budget I'd given myself.

A bookmarklet might still be worth investigating. We could make it so that if your URL had a particular pattern in the fragment we auto-show the add puzzle modal and fill it with other values from the fragment, and then we just make the bookmarklet stuff the title & location in there?

[jimsug]

fwiw I did a bit of a naive implementation of this in jimsug/feature-guess-puzzle-name, where it tries to guess the puzzle title from the URL, but it assumes that the puzzle name will be sluggified in the last part of the URL path, which might not always be the case.

No delay, though.

[jpd236]

FYI, I am working to put together a rough browser extension to allow adding a puzzle from the current page. It would infer the puzzle title and URL from the page itself. Not sure I'll be able to get the whole thing done in time for this year, though.

Starting point is in #1948 which adds the needed server-side APIs. Remaining work is to expose the API key in a slightly friendlier way and then build a quick and dirty extension.

[jimsug]

I like it, and if it's ready and merged before Hunt then that would be amazing!

I just didn't feel like writing My First Extension™ for this, though I guess you have to start somewhere.

Did you have thoughts on what the best way to infer puzzle title? I haven't baked that into the bookmarklet logic, but perhaps that's something that can live in the app code.

[jpd236]

I've been assuming that the page title (in the <title> tag) is the puzzle title in most cases and was going to use that as a baseline. Looking back at the last 3 MIT hunts, it looks like that works, although in 2022 there was some boilerplate at the end of each title. For other hunts it may take a custom rule.

We could start with some hardcoded heuristics. I could imagine either exposing editable rules in the extension options page, or making it a setting in the server-side configuration that the extension could then read from.

[jimsug]

That seems reasonable to me.

For what it's worth, I was considering having a per-hunt configuration for both "URL pattern" and "Puzzle title", both being a regex-like expression.

This would let us match URLs with a regular expression to determine whether it should be added as a puzzle, and if so, what parts if the puzzle should be added - maybe it could define placeholders for title and group:* tag, for instance, and those could be populated in the puzzle modal automatically.

The puzzle title pattern could be used to extract the title of a puzzle, when that's passed as a parameter, and it would work with the current hash/bookmarklet thing I've got going as well.

[jpd236]

#2392 has an initial implementation of an extension. It should work as a standalone PR if patched in, though it includes a few other commits that are also available as separate pending PRs.

Demo video here, if you want to see how it works: https://www.youtube.com/watch?v=kvUdRjqiar8