Whetstone V1 Feedback

whetstone_v1_feedback.md

Whetstone V1 Feedback

From a UI Dev who's most likely to make character sheets.

Background

Here's how I imagine a "Theme Manager" being most useful for all parties involved:

Allow a total/partial UI overhauls of colors/fonts/etc without the UI Overhaul module having to specifically target individual modules.

Allow module creators to support total/partial UI overhauls without having to specifically target individual modules.

Rationale

UI Overhauls are amazing ways to add to the atmosphere of a particular style of game. Custom sheets excel at improving the usability of said sheets. Custom sheets are notoriously difficult to integrate with other modules because the ownership of that burden of integration is unclear. Is the sheet creator responsible for supporting every UI Overhaul? Is the UI Overhaul responsible for supporting every custom sheet?

This question is an impossible one as both sides of it are constantly changing. New Sheets are added and new Overhauls are added with frequency that makes this maintenance unsustainable. Not to even mention other, non-sheet UIs like LMRTFY and Soundboard.

Therefore the goal of Whetstone should be to provide a "standard" for UI integration which allows UI creators and overhaulers a dependable set of variables to use in their UI creation.

Sample Setup

1. MajorVictory creates a UI Overhaul: PurpleEverything in January and goes AWOL.
2. Calego creates a Character Sheet Module: FunnySheet in April but never sees PurpleEverything, also goes AWOL.
3. SomeUser666 comes along in May and loves both FunnySheet and PurpleEverything, so they install both on their machine.

The goal is for FunnySheet to implement PurpleEverything without either of them knowing that the other exists. Simultaneously, the goal is for PurpleEverything to be able to overhaul FunnySheet without ever knowing that it exists.

Assumptions & Problems

UI Design is as much about color as it is about layout. This thinking assumes that the Sheet Creator cares more about layout than color. I think this is a reasonable assumption to make, as any sheet creator implementing such a system is doing so knowing that the user might end up with a garish color scheme, but without touching the layout overmuch.

---

With all that background out of the way, here's my feedback:

Problem

The way I understand things, I have two options for making my custom sheet module work with UI Overhauls run through Whetstone:

1. Constantly update where I define my own sheet css variables to support as many Whetstone themes as I can:

--accent-text: var(--OceanBlues-text-selection-color, var(--PurpleEverything-light-purple, #4b4a44));
// etc...

This has obvious problems for me as the maintainer. If a new theme comes on the market, I have to update all my sheets to support whichever arbitrary theme variable I think works best for my use cases.

2. Register CompactBeyond5eSheet with Whetstone as a theme unto its own.

  game.Whetstone.themes.register('compact-beyond-5e-sheet', {
    // ...
    variables: [
      { name: '--accent-text', value: '#4b4a44', type: 'color', title: 'Accent Text', hint: 'Secondary Text Colors' },
    ]
  }

This however causes problems for the user. Going back to the scenario above, SomeUser666 now has to open Whetstone, activate both the PurpleEverything theme and CompactBeyond5eSheet theme. But the PurpleEverything theme presets aren't applied to the CompactBeyond5eSheet theme variables, so they have to copy/paste what they hope looks good.

Proposal

Establish a Standard Variable Set

These variables need a reliable set of names that won't change based on the activated theme.

Speaking from experiences, this is difficult as fuck. Considerations include: Main Typeface, Accent Typeface, Main Color, Secondary Color, Warning Color, Error Color, font-sizes, etc. It's also going to end up opinionated and some UI creators won't like that.

Example:

// default
--WS-main-text-color: black;
--WS-accent-text-color: gray;

Themes registered to Whetstone modify those Variables

In addition to whatever else is in the css/js for a Theme registered to Whetstone, it should have an opinion about what this standard variable set should contain.

// PurpleEverything then overrides the default to:
--WS-main-text-color: darkpurple;
--WS-accent-text-color: purple;

Modules can implement this variable set

Modules like character sheets, LMRTFY, etc, can implement this reliably named variable set, defining their own sensible defaults as fallback.

.compactSheet {
  --accent-text: var(--WS-accent-text-color, blue);
}

Endgame

I as a module creator can create as many character sheets as I want, implement a consistent, reliable set of variables from Whetstone, and trust that a theme override I've never heard of will look "respectable" when applied by a user.

I as a user can install as many character sheets as I want, find a UI overhaul that helps my game's themeatic sense, and trust that those character sheets with "whetstone integration" will look "respectable" when I turn on that overhaul.

I as a UI overhaul creator can create as many UI overhauls as I want, set some sensible defaults for whetstone to propegate to other modules I haven't thought of, and then trust that they will look "respectable" without my having to do anything.