GUI for building dataforged-compliant hombrew content

[rsek]

the MVP -- a bare-bones html form -- could be built from the json schemas (#59) with aid of the proper libraries, for instance:

• https://rjsf-team.github.io/react-jsonschema-form/
• https://www.npmjs.com/package/outperform
• https://github.com/jarvelov/vue-form-json-schema

more advanced implementations for assets can take cues from effortlessmountain's excellent work: https://github.com/effortlessmountain/ironsworn-asset-workbench

after assets, tables might be next on the list. some ideas for more advanced features:

• enter an unnumbered list, have it automatically create roughly-equal ranges on a standard d100
  • fancier version: or weighted ranges
• convert from csv
• import from google doc
• plain text? it could try to make an educated guess, maybe
• drag rows around to rearrange them
• sort by weight
• sort alphabetically

[edbrannin]

It sounds like the MVP would work like this:

1. Upload or paste a Dataforged-format JSON files
2. Make changes with the form
3. Download or copy the resulting Dataforged-format JSON

Is that about right?

Have you been using any other UI to work on datadorged since then, or has it mostly been editing by hand & with scripts?

[rsek]

It sounds like the MVP would work like this:

1. Upload or paste a Dataforged-format JSON files

2. Make changes with the form

3. Download or copy the resulting Dataforged-format JSON

Is that about right?

roughly, yeah. in the past i've investigated some "generate a form from JSON schema" libraries to do the job, but was never able to track down one that supported all of the JSON schema features i use.

currently, i'm focused on developing the new Datasworn format, which includes Starforged content and will replace this Dataforged package once it's stable; Dataforged is unlikely to receive further updates.

so while this package is unlikely to get a GUI, it's definitely on the table for the new Datasworn... though not necessarily developed by me. for now i'm concentrating on making the new format friendlier to authoring/sharing custom content like you describe.

Have you been using any other UI to work on datadorged since then, or has it mostly been editing by hand & with scripts?

i edit the source YAML files for Datasworn directly in VSCode; the Redhat YAML extension (with the Datasworn data entry schema) provides error checking, autocompletion, and inline documentation. i have a number of VSCode snippets i use to scaffold common objects, as well as dump and format text from the 'canonical' IS/SF/SI sourcebook PDFs with the help of Okular (which has a nifty table selection/extraction tool). these are included on the datasworn repo, though aren't always up-to-date as the format develops.

the source YAML files then get processed into the final JSON format (which also generates IDs and such) with a build script.

[edbrannin]

Thanks for the detailed reply! I hadn’t noticed Datasworn’s new focus.

To what extent is the current (v0.0.8) schema unlikely to change? Besides the issue about generating independent sub-schemas for the various top-level types.

my questions in this thread are mostly because I sometimes write little React apps while procrastinating, and this seems like it could be a fun/helpful one (no promises)

I’m not sure about how much UX polish it would need to compete with your current editor setup… but maybe the best audience would be “everyone who works on Datasworn except you”… whoever that is (or could be), I haven’t checked the commit history.

In a world with a half-decent React UI, it may not be too much extra lift to make it a PWA or Electron/Tauri/whatever app for open/save support. I imagine constantly copy-pasting or repeatedly using save-as would get old quickly.

[rsek]

To what extent is the current (v0.0.8) schema unlikely to change? Besides the issue about generating independent sub-schemas for the various top-level types.

here's the v0.0.9 branch. it's got some breaking changes, mostly to the schemata that live in oracles, but they're pretty simple ones (property/subtype renames to improve semantics/clarity, etc). it also deprecates some ID types (certain kinds of "secondary" IDs)

in theory, the whole schema is unstable until i mark it as v1.0. but some parts are much less unstable than others.

• npcs - pretty stable. if i add something, it would be a subtype (or simply making the schema less strict) to accomodate the short-form NPC entries that appear in some Sundered Isles tables.
• the atlas tree is also pretty stable. not a ton of mechanical heft to them.
• truths may see some revision to bring it in line with the other oracle changes.
• moves may see some changes that make Move#text property obsolete (or simply available as an optional override) by having all move text before the move outcomes live in its own property; implementers could then reconstruct the complete rules text by concatencating the "preamble" text with the ourcomes text. this would make it less exact to the original text in certain cases, but might be a cleaner experience overall.
• assets may see changes to asset move IDs (their format, and whether they exist).
• rules is experimental, and probably won't be stable until after v1.0. but that's something you only need to worry about if you want to design an ironsworn hack.
• tags (that appears on various primary objects) is also experimental (its present schema is a placeholder). it's intended as a way to express custom data that isn't practical to add to the main schema (e.g. "oracle X is the cursed version of oracle Y", useful in Sundered Isles but not relevant to non-SI content).

I’m not sure about how much UX polish it would need to compete with your current editor setup… but maybe the best audience would be “everyone who works on Datasworn except you”… whoever that is (or could be), I haven’t checked the commit history.

well, i guess it depends on how you want to define "works on Datasworn", hah.

i'm the only person actively working on the Datasworn standard/schema repo itself. partly because i'm a glutton for punishment, partly because i know the idiosyncracies of the original schema and want to build on it, and partly because i'm uneasy about accepting a lot of volunteer labor on a project i've been contracted for by Shawn.

really, any brave soul trying to implement this thing and giving feedback as it evolves is already contributing a lot ;)

on the other hand, part of the point of this new schema is to have a standard format the community can use to share custom content and drop it in to whatever VTT/app they like. but a format of interchange is only useful if it hits a certain threshold of adoption. a GUI for it -- even the most basic HTML form possible -- could go some way in making it more accessible to people wanting to author content, thus making it more attractive for devs to use in their own projects, and so on.