search

aclist / kbin-kes

Add-on manager and scripting framework for kbin
MIT License
24 stars 8 forks source link

[MOD] Alternate Spoilers #295

Open Pamasich opened 3 months ago

Pamasich commented 3 months ago

Explanation

Spoilers on kbin/mbin work a bit differently than I'm used to from other platforms. Instead of kbin's <details> approach, they're usually displayed as obscured blocks that show their contents when hovered or clicked on.
This mod aims to switch out kbin's spoilers with ones closer to the ones seen on other platforms.

With this mod, spoilers now display as blocks with only their title visible, which reveal their content when hovering or when the title row is clicked (they can be hidden again by clicking again). Both of these means of interaction can be toggled by the user in KES.

Images

image Native spoilers (expanded)

image New spoilers when not hovered or clicked

image New spoilers while hovering over them or after they're clicked on

Todo (before 1.0)

Edit: I probably should eventually improve the design, like making it more different from code blocks. But for now this should be good enough for a 1.0.

aclist commented 3 months ago

Is it possible to spoiler individual words inline, or only chunks of text? (Sounds like the latter for now?) For example, see this page as a reference: https://steamcommunity.com/app/2458980/discussions/0/6811212011865688045/

Pamasich commented 3 months ago

Is it possible to spoiler individual words inline, or only chunks of text? (Sounds like the latter for now?) For example, see this page as a reference: https://steamcommunity.com/app/2458980/discussions/0/6811212011865688045/

No, sadly kbin doesn't have support for inline spoilers. Which is a shame. But ernest essentially just added support for Lemmy's spoiler syntax, and they happen to not support inline spoilers either.

Inline spoilers could be added using the old trick used by some subreddits (before Reddit added their native spoilers) of doing a custom link syntax like [spoiler title](/s "spoiler content"). But I doubt that would be super useful if only KES users could read those spoilers.

aclist commented 3 months ago

I see, I see.

aclist commented 2 months ago

Getting around to testing this now, but spoiler creation seems to be undocumented and not provided OOTB in the (k|m)bin text editor. Do you have a link to a post with spoilers, or have some additional instructions on the invocation to use to create them?

Pamasich commented 2 months ago

Getting around to testing this now, but spoiler creation seems to be undocumented and not provided OOTB in the (k|m)bin text editor. Do you have a link to a post with spoilers, or have some additional instructions on the invocation to use to create them?

::: spoiler BUTTON TEXT
HIDDEN TEXT
:::

is the spoiler syntax used on lemmy (and adopted by kbin/mbin).

I forgot if the spoiler is upper or lower case and whether it's case-sensitive. But it has to be there for the spoiler to work.

aclist commented 2 months ago

I am wrapping up another project and will be reviewing/approving these this week.

aclist commented 2 months ago

Tested it and the implementation looks really nice.

I think there is an unintended interaction between the "hover" and "click" actions when both are enabled. The click action takes precedence and hovers stops producing any effect on a clicked spoiler.

Example, a spoiler with content that is not currently visible (Firefox 127.0):

Pamasich commented 2 months ago

It was actually my intention that that's how it works. But I can see how it's confusing. I'll think about how to make it more clear how things work.

Like, clicking and hovering are currently presented as two different methods of showing the spoiler, but they actually have different purposes. Clicking isn't actually supposed to show or hide the spoiler, but rather to toggle whether it should be hidden in the first place.

With both actions enabled, hover the spoiler and then click the title once

  • The content shows on hover, and clicking triggers no action, because the spoiler is already shown and the initial click action is supposed to "show" the spoiler
  • The expectation here (I assume) is that clicking on an already hovered spoiler title would hide it

When you hover the spoiler, it's still set to the default behavior of hiding again as soon as the cursor leaves it. Clicking it is meant to toggle that behavior, not whether the spoiler is shown. So considering that behavior is still active, clicking it disables it, causing the spoiler to be shown permanently.

I think this could be better explained in the mod itself, and I should add to my post-1.0 plans to add some visual feedback to clicking so people know it actually does something. Maybe add an icon that shows the spoiler is set to show at all times. But I probably won't add that one to this version yet.

Tl;dr: This is intended behavior, but I'll think about how to make it clearer.

aclist commented 1 month ago

It seems like these should have their own (separate) heading labels and not be grouped in the same category, then, and the label for the click action be clarified as being a toggle that applies to the hover action.

I think a radio button might be the better choice in order to indicate that these are independent actions, rather than a multiple choice.

Just paraphrasing below for the sake of example:

Description: shows spoilers in block format

Hover to show/hide spoiler:
⦿ ON  ◯ OFF
Clicking on spoiler toggles visibility (always show/auto hide):
⦿ ON  ◯ OFF

Also spitballing here, the second option could maybe be a permanent setting that doesn't require clicking? Just set ahead of time with this radio button whether spoilers are perma visible or auto-hide when hovered off. Just an idea.

Pamasich commented 1 month ago

I've rewritten the description a bit, hopefully this makes it clearer.

I've decided to remove clicking being a setting, instead it's now always enabled. It doesn't really make sense for it to be optional as, unlike hovering, it shouldn't be harmful to anyone's experience. Though I did keep in the code, in case someone requests I add it back for some reason.

aclist commented 1 month ago

Thoughts on the following cosmetic changes?

a

b

Pamasich commented 1 month ago

Thoughts on the following cosmetic changes?

  • Change spoiler title color on hover (just picked a generic color, should use kbin internal theme vars)

a

  • Show lock icon (<i class="fa-solid fa-lock"></i>) when spoiler is set to perma visible (sticky). Hopefully this ameliorates the ambiguity of whether the option is on, and avoids the need for fancy status animations

b

Thanks for the suggestions.

The design here isn't meant to be final, there's still quite some work to do on it. I've just pushed them to after a first release, as in my opinion the functionality is more important than having it look perfect. And design tends to drag things out for me.

I was personally thinking of displaying a transparent eye icon on hover that becomes solid when clicked. Your suggestion of a lock does make a lot more sense especially when hover is enabled, but I think it's less clear when hover is disabled. Do you think using both an eye or a lock depending on whether hover is enabled or disabled would be confusing to the user?

As for the color, I'm not sure if that would be the best idea. I feel like that would draw unnecessary attention to the spoiler title. Making it clearer that it can be clicked is one of those areas where I was planning to improve the design post-release. But I'll want to think of other options before implementing color.

Pamasich commented 1 month ago

Before I'll make these changes though, I need to do some work on my third mod that currently has a pull request here, before I forget what I wanted to do there.

aclist commented 1 month ago

I was personally thinking of displaying a transparent eye icon on hover that becomes solid when clicked. Your suggestion of a lock does make a lot more sense especially when hover is enabled, but I think it's less clear when hover is disabled. Do you think using both an eye or a lock depending on whether hover is enabled or disabled would be confusing to the user?

I rewrote a reply to this like five times but couldn't come to a definitive conclusion about what I was thinking. It seems like the main problem to be solved here is that you have multiple modes the state of which isn't always obvious:

Overloading these states with too many different icons might be confusing if they don't really relate to each other or don't have a clearly-defined, widely accepted meaning.

It seems like maybe keeping the original close/expand arrow in the new style might solve this issue, for the most part? I feel like some clarity was lost by removing it. It has a universal meaning for closed/open content. If the content is already visible AND the arrow is set to expand (downward pointing arrow), it should be clear at this point why hovering off does nothing--the spoiler is open.

Revisiting the patterns above:

The only minor ambiguity this leaves is not knowing at a glance whether hover is turned on in the options. On the one hand, isn't that something the user would have already checked at setup time in the KES settings modal? And it can confirmed by hovering.

On the other hand, if this ambiguity needs to be resolved, then I see two options:

As for the latter, it seems weird that you would have to hover to get an icon indicator of whether hover works. And if the expand arrow is restored, this would probably be superfluous.

As for the icon itself, not sure if eye is the right play here, because if the spoiler is already manually expanded by click but hover is off, then a disabled eye icon seems out of place if the content itself is visible. Maybe some kind of hand pointer? Or maybe just a stylized "H"?

As for the color, I'm not sure if that would be the best idea. I feel like that would draw unnecessary attention to the spoiler title. Making it clearer that it can be clicked is one of those areas where I was planning to improve the design post-release. But I'll want to think of other options before implementing color.

I was just talking about a rollover effect so that the title looks more like an interactive button/link, because currently it's a bit hard to notice that the cursor changed to a clickable pointer and the title is liable to look like it's part of the content.

Pamasich commented 1 month ago

I'll swap the pull request back to draft until the changes are made.

Pamasich commented 1 month ago

I likely won't be working on this or my other mods this week. Not sure how next week looks like yet.

aclist commented 1 month ago

I'll be active again starting on 2024-09-05 and wil merge the completed PRs.