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

Add Column Selection #60

Open
kgar opened this issue Nov 21, 2023 · 3 comments
Open

Add Column Selection #60

kgar opened this issue Nov 21, 2023 · 3 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@kgar
Copy link
Owner

kgar commented Nov 21, 2023

From discussion in #14

Support column selection for all tables of data that are displayed on PC, NPC, and Vehicle sheets.
Column selection should be actor-specific and utilize actor flags so that the preference remains intact no matter which browser or user is interacting with a sheet.
Provide the option to reset to default.

Some things to determine before working on this:

  • Should this apply to groups of tables, e.g., "Column Selection for Spellbook Tables"?
  • Or, should it apply to each individual table?
  • Could there be a hybrid approach that is not confusing?
  • Should there be column selection on the PC favorites section? This would require column selection UI that targets sections (inventory, features, spellbook, etc.) and applies location context specific to the favorites view, so that it is differentiated from the full tab column preferences.
@kgar kgar added enhancement New feature or request question Further information is requested labels Nov 21, 2023
@crash1115
Copy link

crash1115 commented Nov 21, 2023

Some thoughts!

Groups vs Individual Tables
I'm feeling pretty strongly that applying it to groups of tables is not the right approach. On the Spellbook tab in particular, there's information that's important for some sections, but useless for others. For innate spells, or spells from items (perhaps from a section added by a magic item mod, or whatever), limited use information is important. That same info might be useless on every other section of the page for a caster.

Doing it per table definitely comes with its own set of challenges, but UX doesn't need to be one of them. You mentioned in #14 the idea of putting section headers on their own lines and having columns sit below that for the spellbook tables. If you apply that across the board, you can slap a customize button in the same row as the section header. Terrible mockup to demonstrate:
image

The Hybrid Approach
A hybrid approach is probably possible and maybe even warranted; Items are probably gonna have the same columns regardless of section. Features might wanna switch it up like Spells. So I could definitely understand a hybrid approach. Including the customization button (or whatever is settled on) for some tabs but not for others probably isn't horrendously jarring/intrusive in terms of UX, but the inconsistency might strike some as a little... odd? Like, if the framework is already built to handle cases like the Spellbook tab shenanigans, why not include it everywhere?

Favorites Section
I think there's two big concerns here. One is how the section is organized, and the other is space. Right now, #13 aims to create parity between the tab display and the favorites list. If that's a goal, then using the configs for individual tables to display columns for matching sections on the favorites list seems like a great way to go. But then you run into the problem of space. You've got maybe half the space in the favorites list that you do on a full tab, so things are gonna get squished.

I'm not really sure I have a solution for that. Maybe the best bet is to set fixed columns for the favorites list, and if you don't like them, oh well? Maybe worth gathering some community feedback for what they wanna see there. I'd guess name and limited use info at the very least. Maybe components for spells. Everything else seems secondary to me, but I also tend towards minimalism when possible.

@kgar
Copy link
Owner Author

kgar commented Nov 21, 2023

The way I envision the favorites upgrade in #13: Parity between favorites and home tabs is more about dividing the items into their proper sections, which opens up the favorites tab to work with CCSS and other section-based modules. Even without column selection, we'd still have a subset of the columns in favorites because of space limitations.

From a technical standpoint, having different default columns for Favorites versions of tables versus in their home tabs is achievable.

@kgar
Copy link
Owner Author

kgar commented Apr 5, 2024

Now that Native CCSS #507 is underway, it is now tuned so that individual tables are ready to be configured independently of each other, with the capacity to fall back to whatever is the default. Non-custom sections will have their defaults which are more curated, and custom sections have a generic default associated with their tab of origin (custom spell sections will have a generic set of columns by default).

And so, spell columns can be customized one way on the Spellbook tab and then another way on Favorites, and it'll be independently configured. And, those sections will have default columns which differ in favorites vs. tab of origin, so there's already some control over the chaos.

We could / should put QoL in place where you can pull the column config from the spellbook and then fine-tune for favorites. People who really want to customize like this will have some work to do in order to make their sheet perfect, but at least giving them the tools and potential to make it happen will be a tremendous gift as it stands. A future goal could be to add more world-spanning features like being able to export / import / download(?) template setups which configure a sheet to the Nth degree for a particular type of play experience. High-crafting game, gritty realism game, spell components required game, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants