Add Token Labels to extensions

[SeamusFinlayson]

Make sure that your submission has the following:

• A link to the raw github markdown file with a YAML front matter definition containing:
  • The title of your extension
  • A description of your extension
  • The author
  • A hero image
  • An icon
  • Tags (these will help with your extension's discoverability)
  • A link to your extensions manifest

Please, go through these steps before you submit a PR.

• You have done your changes in a separate branch.

• You have a descriptive commit message with a short title (first line).

• You have only one commit (if not, squash them into one commit).

• Your pull request MUST target the main branch on this repository.

• Your pull request puts your extensions details as the last entry in the extensions.json file

[Several-Record7234]

Validation script and image URLs check out fine. Extension functionality and API usage not checked.

[nthouliss]

This should probably be a context menu rather than a tool. A tool shouldn't open a popover, it's not great for accessibility.

You should probably add a character limit to the input as well.

Having the extension be a context menu should help with some of the interactions as well. For instance, I can delete a label while I have it selected and then keep adding the label

[SeamusFinlayson]

I have now added a character limit to the input.

Labels can currently be deleted while the tool is open, I think I could change the cursor behavior when they are hovered to make it more obvious.

One of the things that I really wanted to do with this extension was to build an alternate workflow for creating labels, there are already extension that use a context menu to attach labels to tokens, I find those quite difficult to use. I tend to get lost in context menus when managing multiple tokens, often opening and closing the menus several times to attach the labels I want and forgetting what I was trying to do in the first place. Additionally, the context menu blocks the view of the tokens being edited so it's difficult to tell what conditions still need to be applied without having to close the menu and reselect the tokens that need to be edited. This problem is worse on mobile where a long context menu can block out most of the scene. I added the minimize button to help keep the tool usable on mobile, based on your suggestions when I submitted Token Auras.

The automatically opened popover seems to me to be a better fit than a popover opened by tool actions because there is no way for the user to tell what the current state (the typed label) is when the popover is closed. I would have anchored the popover to a tool action at the top anyways but I couldn't get the popover to open automatically with that anchor, and without being able to provide feedback to the user about what to do next when the tool is activated, it leaves them unsure of what to do next and the tool has no functionality until they find and click that second button.

[Several-Record7234]

(Unsolicited opinion incoming! As a user, I like the way that this extension allows you to select one or more conditions and then apply them to multiple tokens just by clicking on those target assets one after another - this worked very smoothly in my game last night when I had to apply a condition to four affected creatures. It's an unconventional approach, but operationally it can be very slick, especially for multiple targets.)

[mitchemmc]

I can understand the benefit of having a richer tool menu to allow easier customisation of tool settings.
It's something I have thought of before but haven't got around to formalising so I can push it up the list if there is a great user benefit.
For this specific use case however I don't think I can let an extension on to the store that opens a popover on tool activation as it breaks accessibility guidelines and prevents that tool from interacting with the rest of the tool system (e.g. another developer couldn't extend your tool with a new tool mode).
I think this is a similar case to when we added embed support to context menus where by formalising this approach to a tool we could make the UX better while also preventing the failure cases by doing it without access to the internals.

[SeamusFinlayson]

Okay, I think I'll just leave this for now then. I'm not really in a rush to get this added to the store, I'm working on other stuff right now, I still need to give feedback on branches. I was looking at building a similar menu for Segmentable Ruler, but I'll hold off on that until it can be done right.

In terms of feedback for eventual richer tool menu, I'm quite happy with the workflow I've built in this extension and Token Auras if I could do that with proper accessibility that would be great. I would say that having an extension add a mode or action to a tool that another extension has added seems quite precarious, like, they would need to both be able to create that exact same tool and icon independently, I don't think that's something that has been done, I could be wrong there.