Okay, a summary of the issue so far:
I wanted to create a new cardtype that would give users a template for filling in new character information, but would also not limit them to ONLY the fields that I thought to add.
My first attempt was to create a new cardtype, then go to Advanced and Structure and add the inclusions for certain headings that I thought every card should have, like Age:, Parents:, and each season of the show I'm building the site for. This worked, however, when I then went to make a new card of this type, I discovered that I could ONLY fill in those inclusions. I couldn't add new headers or text outside of what had been defined in the structure.
So that wasn't going to work. Because there's no way to predict 100% what every card of that type is going to need.
Then it was suggested that I move the inclusions that I had come up with to the Default setting instead. This would create new cards of my new type and populate it with the fields I had come up with.
This seemed to do what I was after, but now the debate is whether or not this is a correct use of Wagn structure, because it means that someone adding a new card will see the underlying inclusion code, rather than just a WYSIWYG editing box. They will have to submit the card before being prompted with the links that will create the Age:, Parents:, Season 1, Season 2 inclusions, and this is not ideal user experience.
I get that the Default method is a less than awesome user experience. But I actually find editing inclusions the way it's currently done less than awesome, even though I grasp what's going on. I would like the option in the editor to open an editing field for the inclusion rather than just see the code that's calling for it. That's another issue, though, I suppose.
There was also the suggestion that Structure was the correct way to start, and that the way to get around the fact that users are presented with finite number of fields to edit is to create a catch-all field. Or two, I guess, depending on where in the overall layout of the card I would expect users to want to add in non-standard sections of text. I am guessing this would be an inclusion whose name is hidden, so that I doesn't appear when the page actually renders?
So I'd start with, say,
Age
Parents
Biography
Season 1
Season 2
Season 3
Additional-Field-With-Hidden-Title
I guess that would work. But it also means that a new character who doesn't have any season 1 or season 2 info because they didn't exist would forever have these links on their page that editors couldn't get rid of. Whereas if it was done with a Default card, they could just erase the inclusions that didn't actually apply in their instance.
This is a great inquiry, and I appreciate that you're putting such good energy into thinking about it.
Re the inclusion editor, as I mentioned in the autodetect ticket, we do plan to build link and inclusion editors for 1.13.
Re *default vs *structure, the issue isn't as cut and dry as correct v. incorrect; it's more about designing things to fit your community. Our intent is to empower Wagneers as high-level designer/developers, and that means providing them with options.
Gerry, who suggested the default rule, is not wrong by any stretch. He is one of Wagn's main creators and knows what he's talking about. He does not, however, do a lot of wagneering of sites intended to be used by non-expert users. My point, which I believe you heard and understood, was just that using inclusions in *default rules will expose them to folks who may be confused by them. Most wikis are ok with this kind of exposure; look at wikipedia and you'll see all kinds of crazy syntax all over the place. Wagn strives to bring wiki patterns to more people by tucking the syntax away whenever possible.
There is one alternative I'm not sure I've explained well yet, and that is that you can have a different *structure rule for different Biographies. *default rules are intended ONLY to affect initial content (and therefore don't trigger a structured editor). If you want a structure rule that applies to just one card, however, that is easy to do, and that may solve your problem. You could get rid of season 1/2 cards in the structure rule for each card. And you would still keep inclusion syntax out of the way of content editors.
The downside of this approach is that you can't then instantly add a field to all Biography cards by editing the "one true structure rule", but, of course, the *default solution denies this possibility, too.
In the future there will be other solutions, where, for example, you might tag a given character with the relevant seasons and then have those fields show up. Those, however, are not yet designed or scheduled and are challenging enough that they may require direct funding.
"that is that you can have a different *structure rule for different Biographies."
I'm not understanding what it is you're suggesting.
I think the inclusion editor, if it works as I imagine it, would make it simple enough for non-experts to work their way through using the *default method. At some point some syntax is necessary if you're going to usefully crosslink things anyway, so you can't remove it entirely.
The tags would be awesome.
re structure, if you go to a specific biography that needs a custom structure, you can go to advanced and create a structure rule for just that card. given current functionality, this strikes me as the best fit.
re the editor, imo the question is whether you want non-wagneers editing your structure. most editors don't want to deal with that, regardless of the interface. (and most site managers don't want them to). if you want that, then the default rule might not be that bad, though it does mean you can't ever alter content patterns across many biographies at once.
Presuming someone other than me decides to add a new character, wouldn't I be asking them to edit the structure rule for just the new card they're setting up in order to add the person anyway? This doesn't seem markedly different than them deleting an inclusion rule that they think doesn't apply from the *Default template.
rules apply to sets of cards, and those sets can be very broad or very specific.
I was suggesting you'd have a broad rule for "all biographies", and you could override that with a specific rule for individual biographies as needed. So someone creating a new card would get a familiar-looking form, not an editor full of inclusion syntax.
So you're talking about going back once it's been created and cleaning it up with an override. Because I wouldn't know before they made it which fields weren't going to apply.
yes, exactly.