Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make "Deleted puzzles" section less intrusive #2278

Open
jpd236 opened this issue Oct 1, 2024 · 2 comments
Open

Make "Deleted puzzles" section less intrusive #2278

jpd236 opened this issue Oct 1, 2024 · 2 comments

Comments

@jpd236
Copy link
Contributor

jpd236 commented Oct 1, 2024

We noticed a couple of quirks with the "Deleted puzzles" section that made it more visible than we felt it should be:

  • The contents of the section are expanded by default. Since deleted puzzles are meant to stay out of view (otherwise, why delete them?), this seems like an odd choice.
  • JR doesn't remember the expanded/collapsed setting, so even if you go and collapse them, they expand again upon reloading the page.
@zarvox
Copy link
Contributor

zarvox commented Oct 1, 2024

Non-operators don't see deleted puzzles at all. For a little context: we've historically been willing to tolerate things being a little more potentially-confusing for our operators, who have mostly been expert users and are willing to deal with a little more jank or information overload to avoid missing things. During Hunt, we generally expect our operators to keep abreast of if there was a duplicate-puzzle-creation mishap, and to be aware of this enough to help explain the situation or extract any data from the deleted spreadsheet, so between wanting the existence of deleted puzzles to be visible to operators by default for awareness and wanting to be consistent with the other groups on the puzzle list page (which are all expanded by default in their initial state), and because the default state doesn't matter until there are actual deleted puzzles in the section to be aware of, I'd still lean towards leaving the deleted puzzles expanded by default.

All that said: it is weird that we don't remember the expanded/collapsed state, and I would totally accept a PR that made sticky expand/collapse behave correctly, which would make it one click away to hide deleted things and keep them hidden.

Of course, this all becomes somewhat moot if we do a good job of avoiding duplicate puzzle entries that need deletion in the first place 😅

jpd236 added a commit to jpd236/jolly-roger that referenced this issue Oct 15, 2024
As best as I can tell, this was a typo. Regular puzzle groups have their
state stored as long as there is no active search query. This makes
sense - as commit 2e09393 notes, it
would cause confusion when searching if we paid attention to collapse
state when showing search results. However, the deleted group behaves
the _opposite_ way - the state is _only_ persisted during searching. I
can't imagine why persisting the state in this case would be desirable,
but not during the no-search case. So this change makes everything
consistent.

See deathandmayhem#2278
jpd236 added a commit to jpd236/jolly-roger that referenced this issue Oct 15, 2024
As best as I can tell, this was a typo. Regular puzzle groups have their
state stored as long as there is no active search query. This makes
sense - as commit 2e09393 notes, it
would cause confusion when searching if we paid attention to collapse
state when showing search results. However, the deleted group behaves
the _opposite_ way - the state is _only_ persisted during searching. I
can't imagine why persisting the state in this case would be desirable,
but not during the no-search case. So this change makes everything
consistent.

See deathandmayhem#2278
@jpd236
Copy link
Contributor Author

jpd236 commented Oct 15, 2024

I think #2289 should make expand/collapse behave correctly. I'm curious to know if I've missed a reason it behaves the way it does.

This raises another question. Is it intentional that when you search for puzzles, the deleted section isn't filtered at all by the search? I would expect it to only show deleted puzzles that match the query. But I'm not sure if this is intentional under the reasoning that operators should be aware of everything for some reason.

jpd236 added a commit to jpd236/jolly-roger that referenced this issue Oct 16, 2024
jpd236 added a commit to jpd236/jolly-roger that referenced this issue Oct 16, 2024
jpd236 added a commit to jpd236/jolly-roger that referenced this issue Dec 21, 2024
As best as I can tell, this was a typo. Regular puzzle groups have their
state stored as long as there is no active search query. This makes
sense - as commit 2e09393 notes, it
would cause confusion when searching if we paid attention to collapse
state when showing search results. However, the deleted group behaves
the _opposite_ way - the state is _only_ persisted during searching. I
can't imagine why persisting the state in this case would be desirable,
but not during the no-search case. So this change makes everything
consistent.

See deathandmayhem#2278
jpd236 added a commit to jpd236/jolly-roger that referenced this issue Dec 21, 2024
jpd236 added a commit to jpd236/jolly-roger that referenced this issue Dec 21, 2024
As best as I can tell, this was a typo. Regular puzzle groups have their
state stored as long as there is no active search query. This makes
sense - as commit 2e09393 notes, it
would cause confusion when searching if we paid attention to collapse
state when showing search results. However, the deleted group behaves
the _opposite_ way - the state is _only_ persisted during searching. I
can't imagine why persisting the state in this case would be desirable,
but not during the no-search case. So this change makes everything
consistent.

See deathandmayhem#2278
jpd236 added a commit to jpd236/jolly-roger that referenced this issue Dec 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants