Samples Blog contact support
improve rule navigation



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.




1. get rid of unnecessary settings

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

Not sure exactly what this looks like, but there should be a way to navigate between different settings lists:
  1. see all settings listed alphabetically
  2. see most common settings (create, read, update, delete, structure, default, style)
  3. see any given group of setting (see above)
  4. see field-related settings (default, help, add help, all pointer settings...)?

4.  keep setting list in session

The  idea here is that when we are wagneering (cardworking?), we are often revisiting the same given settings over and over again.  (Perhaps we're working on permissions and setting 7 permission rules.  Or working on forms and going between structure and default all the time.  Or messing with html/javascript...)  I would suggest that we should keep our latest settings list in the session, and then go back to that list the next time we open rules.   Folks with nothing in the session (including brand new users) would default to the "most common" list.
Other ideas to work in:
  • 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)



expand_less +discussion

Things that should not (imo) be settings/rules much longer:

--Ethan McCutchen.....2015-03-17 20:41:35 +0000

I like the secret group. Is that something long-term? It suggests you don't what the typical cardist to find it.

--Gerry Gleason.....2015-05-03 11:44:40 +0000

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 :)

--Ethan McCutchen.....2015-05-04 04:51:47 +0000

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.

--Philipp Kuehl.....2015-05-19 11:58:39 +0000

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
...or something.  That's not quite right, but you get the idea.
I do really like the idea, though, that you would be able to choose *not* to show the table of contents.  
--Ethan McCutchen.....2015-05-19 16:26:11 +0000

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 than in a structured one (like a Ticket)?

--Philipp Kuehl.....2015-05-19 17:23:09 +0000

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?


--Ethan McCutchen.....2015-05-19 17:57:13 +0000

Even so, the {{_|table_of_content}} could be in a *default rule for unstructured types (and other sets).

--Gerry Gleason.....2015-07-29 17:38:46 +0000

You could set that up if you wanted, right. Doesn't make much sense for standard installs, though. It puts wagneering in editor space.

--Ethan McCutchen.....2015-07-29 20:44:48 +0000

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.

--Ethan McCutchen.....2015-07-29 20:45:43 +0000

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.

--Gerry Gleason.....2015-07-30 16:46:31 +0000