Suggested additional fields on content

[drusepth]

Lets start compiling these in a single location so we can make sure they all make it out in the next release:

For characters:

• Motivations
• Flaws

For locations:

For items:

For universes:

• Rules

[sh0nuff]

Curious as to why these fields have to be concrete. Can't they just be created as custom fields that are then able to be assigned or linked to other pages?

[drusepth]

@sh0nuff The primary reason is planning for future improvements to AI and functions that use these fields. It's a lot easier for an AI to understand hardcoded fields/relationships we define than it is to parse out what fields are about on top of parsing their content.

A concrete example is the family relations -- if we allowed custom relations, people could definitely add brothers, sisters, mothers, fathers, etc., but it'd be much harder for us to, for example, detect all the family relation fields a user has when building a family tree visualizer. A similar argument goes for fields, but less so: we might want to, for example, parse out specific flaws/motivations for characters to compare and contrast them to others. Having to parse out the field name adds processing that's a bit too unwieldy to handle.

We may eventually want to add custom fields (and just not do anything with them AI-wise), but I think for the time being the best move forward is to keep structured fields in place and just provide mechanisms for people to enable/disable the ones they want / don't want.

[sh0nuff]

@drusepth makes sense now I understand.. I guess I see value in making the field be named "Relationships" vs "Family" so there's more flexibility..

Perhaps allowing users to hide or show tabs/tab contents would keep the interface simple while still providing choice of hard coded fields would address your needs and still keep it clean

[Cantido]

We could allow arbitrary custom fields, but then build the app to match certain words like "sibling," "mother," etc, and automatically enrich that particular field. This has the upside of allowing future enhancements to affect existing custom fields.

[drusepth]

After giving it some thought, I think "enhanceable" custom fields is the right move forward. There's not really a great way to design fields that fit everyone without requiring people to spend time enabling/disabling fields. I think providing a set of default fields (that we could make disable-able, or just pare down and rely primarily on custom fields) that can be enhanced if they match words is a nice fix for everyone, because we can still define relations for the AI and people can add the fields they most care about.

The only downside is we'll need to do a bit of fuzzy matching on field names to match into the AI (e.g. matching "sister", "sisters", "female siblings", "sistrs", "sistas", etc), but I think that's okay. Worst case we can either 1) ask them to map their own fields to sisters/brothers/aunts/uncles/etc, or 2) just dynamically create feature-needed fields for them when they use a feature (e.g. creating a personality_type field when they take a personality test for a character) and either filling in data for them or just let them know so they can fill it in themselves.

Looks like @mwerner laid the groundwork for this in #108, so hopefully we can move forward with that and get this very-frequently-requested feature in for everyone sometime soon. 👍

[Cantido]

I agree that custom fields with fuzzy matching is probably the way to go. We might make things easier for people if we offer to auto complete field names, so users are guided towards fields that we recognize.

[sh0nuff]

Heh. Beat me to it. I was going to suggest autocomplete to fields you had already coded, then allow for users to add their own custom "nameplate" for any world-centric spellings or terms. Glad we're all on the same page!

[drusepth]

Given that we've added the fields above and added custom attributes, I think it's safe to close this :)