Ticket
improve rule navigation+issues
The general problem here is that rule lists are currently overwhelming; we show all of the settings at once in most circumstances, even when many don't apply.
improve rule navigation+solution
Proposal:
1. get rid of unnecessary settings
- *comment - see commenting overhaul
- *table of contents - should be a view and handled with "show" syntax.
- *accountable - handle with +*account permissions (see add traits interface)
- *thanks - should be handled by *on create and the like.
2. improve settings groupings
These seem clearer:
- templating: structure, default, autoname
- webpage: layout, style, script
- permissions: create, read, update, delete, captcha
- editing cues: help, add help
- events: on create, on update, on delete
- pointer: options, options label, input
- other: follow (plus anything from #1 above that we haven't yet gotten rid of). this might evolve into preferences or something else...
- (secret): default html view, follow fields
3. add rules toolbar navigation
- see all settings listed alphabetically
- see most common settings (create, read, update, delete, structure, default, style)
- see any given group of setting (see above)
- see field-related settings (default, help, add help, all pointer settings...)?
4. keep setting list in session
- it's a bit more typical to want *structure rules when you're working with types and *default rules when you're working with fields. Would be nice if this interface steered folks to discover that.
- in this proposal, pointer rules are available all the time.
- we need a clear indication when no rules are viewable (eg for permissions reasons)
Things that should not (imo) be settings/rules much longer:
- *comment - see commenting overhaul
- *table of contents - should be a view and handled with "show" syntax.
- *accountable - handle with +*account permissions
- *thanks - should be handled by *on create and the like.
I like the secret group. Is that something long-term? It suggests you don't what the typical cardist to find it.
well, it might be a long-term pattern, but I would hope none of its members are there for the long term.
It's sort of the opposite of deprecated. (anteprecated?) It's something that we've implemented but we're not really sure we want to support; we still want to be able to change it without being responsible for fancy migrations.
We should formalize this, but there is a general idea that some bits of wagn functionality are "use at your own risk; they might disappear, and we won't promise to fix it for you". Not that we've promised to fix anything for everyone, but there's a general expectation that if we break folks' sites, we've misbehaved. Here we don't want to set ourselves up for getting in trouble :)
Are you sure about the table of contents change? Might be ok that we loose the option "show toc if count of headers exceeds a certain number" but not be able to turn it on for a certain set of cards feels like a serious loss.
I probably say "I'm sure" about as often as you say "I'm excited" :)
Can you think of an example of where you might want this? It seems like you would need to have a configurable set of unstructured cards. (If they're structured, you could specify to have the table of contents in the inclusions). For example, if I created an unstructured cardtype "Report".
As Wagn has evolved, unstructured cardtypes have become pretty rare. And it's also fairly rare to navigate directly to plus cards (unless they themselves are structured, as with Analyses on WikiRate).
Another approach might be something a bit more like how we handle comments: the view is always there but could be shown or not. Actually, I would like it more if both of those views were attached to the original view after the fact like events. something like:
view :table_of_contents { blah }
view :table_of_contents, :before=>:open_content
view :table_of_contents, :before=>:titled_content
Isn't it more likely that you want a table of contents in an unstructured card (like a report (of cardtype "Report") or for example a self set like wagn.org/wql_syntax) than in a structured one (like a Ticket)?
For any single card, you can just add {{_|table of contents}}, right? So that's not lost.
It does come up a lot that there's a structured page with one or two main areas of long unstructured comment. On Conversations on the docs site, for example, I can see adding {{+workspace|show:table_of_contents}}.
The loss, I suppose, is the case like Report. I don't see a ton of that, but it could certainly happen. I can think of several workarounds if this came up (eg "MyReport+with_ToC") that would give Wagneers a lot of control over how things appear.
Do you know of any sites that use the Report-like pattern?
Even so, the {{_|table_of_content}} could be in a *default rule for unstructured types (and other sets).
You could set that up if you wanted, right. Doesn't make much sense for standard installs, though. It puts wagneering in editor space.
we should probably move the ToC discussion elsewhere. We ended up improving the rule navigation without getting rid of all the settings we want to phase out.
Right, drifted to related topics, and this one is complete.
I see what you mean about editor space, *default rules become content, so the editor could ask "what's that", but that might be ok if it isn't default or common use case.
In a way, the issue is simplifying the mod developer's interface to rule navigation. How it is done for core modules, and how new rules and rule groups would be handled by developers. Some light Waneering of this stuff might be wanted, but mainly the remainder is a dev issue.