Forum:SMW-Based Replacement for Category Tree

Forums: Index > Project Discussion > SMW-Based Replacement for Category Tree

SMW-Based Replacement for Category Tree

Something I've been working on back-burner is figuring out how Semantic MediaWiki properties could be used to replace {{Category tree}}. Any case where we use use "programmatic" Categories is ideally suited to be replaced by a Property. Property:Gains is already rolled out. I have ideas for our other current uses of {{Category tree}}, which are primarily Losses and Uses. SMW can provide a handful of benefits, but I want some feedback on several of the design trade-offs. - PSGarak (talk) 15:00, 11 February 2022 (UTC)

Proposed Benefits

• Maintenance. Every time we add a new item, someone also needs to go in and click the buttons to make the "Category:X Sources" and "Category:X Uses" pages. If uses are added after the fact, sometimes these categories are missing for a while.
  • Is it a burden on the wiki to have all these pages? There's a ton of items that only have one source.
• Customizability. The mw:Extension:CategoryTree extension kinda just does what it does. A ground-up replacement would give us more opportunity to change the appearance.
• Enhanced functionality. One topic that came up frequently in the recent survey was wading through the dozens of "source" actions for an item, half of which are Ambition-specific or retired, to find the few "useful" ones. I have some ideas for adding additional information which will vastly help with this. - PSGarak (talk) 15:00, 11 February 2022 (UTC)

Personally, I'm VERY into improvements to how we display the list of actions. I was excited to see people bring that up in the survey, because I've been thinking about it, too. I do a lot of manually browsing the category pages for "(Item/Quality/etc) Gain", and it's definitely frustrating that all you can see is a list of the actions themselves with no other information, and have to open every page individually. I think adding location info, card vs. storylet, and restrictions would certainly help.

Are there ways to dynamically generate item source tables based on certain criteria? Because this has got me thinking about things like our item grinding guides, and whether there's an easier way to aggregate and display that kind of info. For example, could we specify criteria like "Glim sources within a certain challenge level range" and output a table that shows the kind of info we tend to include in grinding guides (quantity, challenge level, storylet title, location)? It would save anyone having to manually go find all those sources, nevermind maintaining all those lists. And if *that* is possible, I wonder, is there any way to implement search functionality for item sources where the user can specify their own criteria and get a list of sources? Fynnkaterin (talk) 22:54, 14 February 2022 (UTC)

To your question about generating tables: Yes, with some caveats. Edge-cases get difficult to handle. Content which is dynamic, e.g. variable challenge difficulties, may not get handled well. So consider it a 90% solution at best. Quantity, sadly, is something I don't have a reasonable approach to. Ranges, dynamic values, etc get out of hand quickly. I've previously shied away form just storing the full text of the gain amount, but perhaps that's worth pursuing if you think you would use it.

I haven't considered user-provided query ranges. I suppose it should be possible with Forms. I think there are SMW extensions to allow more interactive querying, but I haven't explored that very much. E.g. smw:Semantic Drilldown.

To your more specific example about "Glim sources within a certain challenge level range," yes, that's something we can do right now. And I mean "now" quite literally, I updated the Challenge templates two days ago and the data was still refreshing yesterday, so today is probably the first time we can run this query! Arbitrarily choosing "within a certain challenge level range" to mean between 50 and 100, inclusive.

	Has challenge	From	Card or Storylet⠉	Located in⠉
A cat's wager	Dangerous (97, Broad)	Walter the Greater One-Horned Rhinoceros	Storylet	The Labyrinth of Tigers
A lack of entanglements	Shadowy (75, Broad)	Smuggle glim across town	Storylet
Assist the neddy men	Dangerous (64, Broad)	Strike!	Storylet	Wolfstack Docks
Blackmail 1	Shadowy (84, Broad)	Memoirs of a butler	Card	Fallen London
Defend yourself!	Dangerous (72, Broad)	Ambushed by Pirates!	Card	Fallen London
... further results

From the "further results..." link, next to the word "Results" if you squint closely there is ^{baaaarely visible} a link that says "Code" which will show the Wikitext that generates the table. This one happens to be a bit gnarly.

Of course, I'm sure that was just an example to ideate on what could be done. Another idea instead of using Challenge is to filter on Location to delineate early-game, mid-game, late-game. There might actually be a clean and maintainable way to do this, using smw:Concepts to have a re-usable definition of what is mid-game (if we could ever agree).

As you mentioned elsewhere, big-huge tables have some issues. Assume that once we have the data, presentation is more-or-less infinitely flexible if you're willing to put in the work.

- PSGarak (talk) 02:42, 15 February 2022 (UTC)

That's actually REALLY cool and I love that we can do tables like that. That might be really helpful for the guides.

Gain amount: might not be that big a deal. I'm not sure if that's what anyone else is searching by, anyway. I feel like, if you're e.g. an early-game player just trying to figure out where you can get some Glim, the other info (location, challenge, whether it's a storylet or card, etc.) is more important.

User queries: Just spitballing on that, really. I can't say if that's anything anyone would use. It might be worth considering if we weren't meeting people's needs with the other options.

Early-mid-late game: I think it might be worth coming to a consensus on this, if only because I *have* seen people mention (not just in the survey, but fairly often in wiki comments) that they're looking for x information for [early/late] game players specifically. So it might help to have that as a variable, to in some way separate out things like item sources by game stage so people can more quickly get to the info that's relevant to them. Fynnkaterin (talk) 11:11, 15 February 2022 (UTC)

Regarding Early-mid-endgame: I've been working with a definition on {{Audience}} meant for guides, which seems to work alright (at least so far). Aximillio (talk) 21:07, 22 February 2022 (UTC)

Design

I have a work-in-progress sitting around at {{Property listing}}. I've changed my mind about a few decisions therein, and haven't fully updated it yet.

Phase I goal is just to get parity with the behavior of Category Tree. This means an expandable/collapsible list of actions that meet a certain criterion, plus links to something that looks like a Category page that might have some programatic content.

Phase II goal is to add extra information. My two main ideas:

• Where/how the action is accessed. So e.g. picking a random Action from the list of Shard of Glim sources: the action An Innocent Fictional Scene would have the additional information "(from Show your Film!, a Storylet in The Empress' Court)." We have the Properties currently in place to pull this information: Property:From Card/Storylet, Property:Located in, and Property:Has Game Type.
• Restrictions. Attaching annotations like FATE, HALLOWMAS, or to lists of actions. I'm starting some work on making this information accessible, see {{Restrictions}} for a current work-in-progress. My current thought is that Action pages would store the rendered text in Property:Has restrictions. - PSGarak (talk) 15:00, 11 February 2022 (UTC)

I am very much in favor of this. My question is whether Property:Is retired is completely superceded by the Restrictions. To expand on that, I hope to at some point automatically have that property assigned to true or false to each item, action, etc. The idea of course is to be able to query SMW for "Is not retired" specifically.

Currently, the idea to set this property via "check if something like {{Retired}} or Item|Access = Retired sets the property to true; if it doesn't, then it's empty. Set property to false."

The problem is that the attempts so far have been problematic:

• using @annotation has been refreshing pages over and over - It has therefore been removed from the big templates like {{Action}}, but is still in some templates with <100 uses like {{LivingStory}}. I suspect it just refreshes once for every property that is set on the page and then once that is done, it won't happen so often anymore.
• the SemanticDependencyUpdater basically ground the site to a halt last time we tried it, I believe.

I have asked Alan to look into these issues, but that of course takes time. -- RagCall (talk) 08:37, 15 February 2022 (UTC)

Property:Has restrictions does not supercede Property:Is retired (in fact, it currently relies on it). Is_retired is structured data useful in queries. Has_restrictions is formatted wiki text intended to be directly used for display to the user, and isn't easily query-able itself. The data sources that {{Restrictions}} relies on are better-suited for other queries.

I wasn't aware of the results of the performance tests @annotation and DependencyUpdater. The current use of {{Restrictions}} uses @annotation, and it's deployed on {{Action}} on staging and {{Fate}} on live (<1000 uses).

Dependency Updater's behavior surprises me, since the docs give "this page depends on itself" as an explicit example. I remember that Alan said he configured it to run asynchronously instead of the default--perhaps that's the issue? Each page update re-enqueues itself, infinitely.
- PSGarak (talk) 14:35, 15 February 2022 (UTC)

Trade-offs and Decisions

First and foremost, this would mean that a lot of Category pages cease to exist as permanent pages and become dynamically-generated. They would only be accessible via links from their respective Item/Quality/Whatever pages. They would not appear in auto-completes from the search bar, they wouldn't be bookmark-able. Personally I never try and access those pages directly, but I don't know if anyone else does.

Also a few of those pages have non-trivial content which would need somewhere else to live. Mostly item grinding guides, I believe, so there's a place to move those pages. The current iteration of {{Property listing}} supposed that those content + category pages could be replaced by smw:Concepts; I no longer believe that's a good solution, because it's not compatible with my Phase II goals above.

Is the loss of these pages a problem? I view a lot of those pages as effectively dead weight. Even the pages that do have content, that content might not get viewed often if wiki-readers are conditioned to assume that Category pages are usually content-free.

Next-up: How do we want these lists of actions to be represented, actually? The default for Category Tree is that the on-page collection of items is basically an UL, and Category pages have their own thing which is a multi-column alphabetic layout. This is reasonable, I guess, but we could change either or both of them. These can be wholesale replaced, or customized to various extents. The Category-looking pages can at least be made to include some header material in the vein of {{Item Sources}}. In particular, I wonder if Category-ish pages serve well on mobile.

Down to smaller things:

• Limits and pagination. The recent survey had a few responses commenting on the length of some lists. SMW lets us paginate the results to cut down on the size. Current iteration of {{Property listing}} cuts off at 25 entries, which is completely arbitrary.
• Lazy-loading. Current iteration of {{Property listing}} uses the SMW feature where the list gets loaded onto the page via Ajax after page load, so as not to slow down the rest of the page. I like it, not sure if that's universal, and I also don't know how robust it is across browsers. Yea or nay?
• Wording, and customization of wording, obviously.
• While I'm leaning away from Concept pages, there's still a way to get this to point automatically to guides that might exist.

- PSGarak (talk) 15:00, 11 February 2022 (UTC)

Update: I've removed all of the Concept-related shenanigans. Now it just links to a Category-page look-alike. Added functionality for putting some intro text at the top of said Category-ish page.

Example available at User:PSGarak/Sandbox/Shard of Glim, specifically for the Item Sources stuff. (The Uses category tree has not been replaced yet.) This is using the existing {{Item Sources}} as the header for the category-ish page. PSGarak (talk) 20:56, 11 February 2022 (UTC)

I don't think it should be a problem making the category pages dynamic and removing the static content. I agree that that content belongs in guides instead. Generally, when I access a category page manually, it's for only one of two reasons: either looking for that static content (which isn't standardized between pages anyway, so you never know if anything will be there), or to tediously go through a list of pages in "(Item) Gain" to find a suitable action. But that gets into the issues with those lists so I'll speak about that in the relevant section. Fynnkaterin (talk) 22:24, 14 February 2022 (UTC)

Updates

Initial support has landed for adding "From" data to {{Property listing}}! This is a substantial piece of enhanced functionality.

See an example at the Item Sources part of User:PSGarak/Sandbox/Shard of Glim, in both the expanding list as well as the linked category-styled page. Feedback welcome.

Does this look... busy? It seems like kind of a lot of info to display, but it also seems like most of it is useful and I don't know what might be cut. I also spy a number of edge-cases which will need to be addresses, including "universal" cards which don't have a Location, and probably Actions with multiple "From" properties.

- PSGarak (talk) 21:12, 17 February 2022 (UTC)

Going to bed now, so sorry that this is haphazard: I don't know if it's already implemented: could we get some CSS classes assigned to the "from" information?

Also, a headsup: I know the Template:Card states a "Universal" value for locations as default, but afaik this isn't actually used anywhere, instead defaulting to not showing that information at all in those cases.

But I definitely like where this is going! -- RagCall (talk) 21:28, 17 February 2022 (UTC)

Classes/styling are easy. Line items are generated from {{Property listing/Item}}. We can stick some HTML in there easy, although I don't CSS good myself.

- PSGarak (talk) 21:31, 17 February 2022 (UTC)

Further updates.

HTML spans around the "from" text, which I used to make it smaller & italicized. This is about the extent of my CSS abilities, but I think it's an improvement. The "bonus" info is now properly de-emphasized from the main info.

Also made some technical updates so that it works on Record types, which means it can now also fill in for "Uses" category trees in addition to "Sources." The data for this is still populating. But one of the first dozen pages to get updates was, by chance, a Fate-locked action which uses Glim! This is good because it means that User:PSGarak/Sandbox/Shard of Glim now shows off how "restrictions" are highlighted. Look at that, there's a FATE tag in there!

Still to do is roll out {{Restrictions}} into {{Actions}} so we get more Restriction data, and add a bunch of wording around the various places that actions can take. But the meat of this is starting to shape up.

- PSGarak (talk) 20:28, 22 February 2022 (UTC)

Release Candidate 1

There's still room for improvement, but we've reached the point where I'm happy with the current state, think it would be a welcome improvement over the status quo, and think the remaining improvements are Ok to wait til later. Mostly I want to make this happen, rather than give into my natural urge for endless tinkering.

Personally I've found in my own use in the Wiki, the extra value from these templates means it's actually worth my time to cobble together a Template call on my sandbox rather than using the existing category pages.

So, I'm declaring the current status of things to be a Release Candidate, and am inclined to start rolling things out into the greater Wiki unless I get feedback otherwise.

What Works

The original proposal has been broken into two pieces.

{{Property category}}

Creates a link to a dynamic page that looks like a Category page. Each link in the "category" has additional game info.

{{Property listing}}

An expandable list of actions, like {{Category tree}}. Calls {{Property category}} to create links where Category tree had a link to a category page. The expanding list of actions contains the same additional game info as Property Category.

The former is intended to replace current Category links, e.g. the links on {{Quality}} pages for actions that Gain or Lower the relevant quality. There's a decent long tail of these, not all of which have SMW properties yet. The biggest one that's missing is Loss; another decently-common one is Moves. The latter is intended, of course to replace Category tree, of which the primary use cases are Gains, Uses, and Challenges; the SMW data for all of these are in place.

The "additional game info" is: Game type, the Card/Storylet it's from (if Action), the location of either the action itself or it's From Card/Storylet, and the list of applicable Restrictions. Plus an option to pull in one more property (e.g. Use type for Uses, or Challenge difficulty for Challenges).

Known Issues

Sometimes SMW doesn't always return all of the additional data on the first try. My experience is that usually a refresh solves the issue. Personally think the extra data is worth sometimes having to ctrl-R, but if we don't want a janky roll-out I'm sympathetic to that.

Restrictions data is not as complete as it could be. E.g. not all actions about an Ambition are actually tagged with that category. You'll find often that a Storylet is tagged with a category, but it's individual actions are not. Still something is better than nothing. Retired, Fate, and Festival tags have better coverage. And the From & Game type information fills in a lot of the gaps. I have plans about how this could be improved using Concepts, but that's basically a whole additional project.

Presentation probably could be better. I can barely CSS. Constructive criticism is appreciated, someone else Taking Charge and Doing It would be fine by me. The HTML is generated by Template:Property category/Item, the CSS is at Template:Property category/styles.css.

The Property Category links open in a new page. SMW seems to do that when you pull more than about four properties into a query. I wish it didn't, but I'm kind of ok with it. First usages would be the Gain link in {{Quality}}, and the Sources & Uses category trees in {{Item}}. - PSGarak (talk) 19:56, 2 March 2022 (UTC)

"You'll find often that a Storylet is tagged with a category, but it's individual actions are not." <-- if someone gives me the go-ahead, I can fix it in both directions via bot. (That should probably also include changing the Spoiler type on all of those to Major, and/or adding a new spoiler type for each Ambition; I am willing to hold off on that until that is decided). As you noted, finding those articles via Property:fcs is easy enough. -- RagCall (talk) 20:08, 2 March 2022 (UTC)

I wouldn't fix it in both directions. There are tons of regular cards/storylets have Festival or Ambition content on them.

There's also a bunch of additional special cases. Storylet 1 unlocked by an Ambition, has an Action which redirects to another Storylet which isn't categorized. Complete a Jaguar Blade Wailing with Hunger 2 requires a SMEN-locked item and is the eventual conclusion of an Ambition-locked Experiment, but is not directly connected to either SMEN nor A:N and has neither category. All sortsa things.

But yes, a simple "pull categories from storylets into actions" would increase the coverage. Although come to think of it, I could also go in the other direction, and pull the fcs restrictions in the same way I pull game type & location. PSGarak (talk) 20:23, 2 March 2022 (UTC)

I just encountered mildly confusing behaviour.
This query correctly displays Ambition:HD on Offer your congratulations on their upcoming nuptials, because the cards are categorised. However, it does so twice (presumably because there are two cards).

Moreover, Examine the daguerreotype and Examine the daguerreotype...with help do not have the label, because their parent storylet does not have Category:Ambition: Heart's Desire!, but Category:Ambition: Heart's Desire - the Topsy King. -- RagCall (talk) 12:47, 14 March 2022 (UTC)

You are correct on the first point: if I pull Restrictions from the parent FCS, and there are two such restriction lists, then we'll get two potentially-duplicated restriction lists. Pulling restrictions from FCS was a bit of a stop-gap to begin with. One option is to stop pulling in FCS tags, but for now I'll just #explode the list and grab the first.

The second issue affects a whole slew of content. It's more prominent for Ambition-related stuff, but also some Festival content. One option for addressing this is sticking Categories everywhere. The other option is using Concepts instead of Categories. Either of those will take some time and hand-curation to shore up, and I would tend slightly towards the latter.

In any case, my attitude is that gaps in the Restrictions lists are not blockers. They're nice to have, and even partial info is an improvement from the status quo. Plus naming the FCS can often clue readers in. PSGarak (talk) 14:56, 14 March 2022 (UTC)

Oh, absolutely - I mean, it sure helped me! (I also now first-hand experience much more helpful this kind of output is than the categories, having to find some items for my church...) Just wanted to note it down somewhere. -- RagCall (talk) 15:04, 14 March 2022 (UTC)

Okay, here is definitely something still weird with caching or something similar:

This lists things that lose Society Favours. At the time of writing, Gain an audience with the Duchess in that list shows the Ambition: Light Fingers restriction (of its parent), while its sibling branch Send the Duchess a charming letter does not.

However! If you change the query to FCS::Light Fingers: A Word to the Duchess so that these two are the only two results, they both show the restriction.

Some more tests:

• combined with Loss of Incendiary Gossip reproduces the inconsistency
• combined with Gain::Knowledge of Thine Enemy, they both show the restriction.
• selecting via icons both show the restriction, even when there is a third result.

Moreover, even the broadtable doesn't acknowledge them having the same FCS.Has restrictions [1]. However, it does if you add a sort by From message.

I have the sneaking suspicion that the bug happens if there is something with a different FCS.Has restrictions between the two results in question when they are returned by SMW, but don't feel like diving into it too deep right now. -- RagCall (talk) 22:07, 19 March 2022 (UTC)

It sounds like you honed in on the same issue that @Alan did, with the non-consecutive items with the same Property value. He said it's something to do with the Prefetch cache, but hasn't find the details. I assume anything to do with caching is incredibly difficult to debug. PSGarak (talk) 00:52, 20 March 2022 (UTC)

Ah, I thought that was already fixed, my apologies. -- RagCall (talk) 08:12, 20 March 2022 (UTC)

To continue this line of conversation: Concept:Ambition: Heart's Desire! as far as I can tell now lists everything exclusive to HD. At least it is a strict superset of Category:Ambition: Heart's Desire!. It is also a proof of concept, as the approach should more or less be transferable to other Ambitions and possibly to SMEN. (Although I am not really happy with the mix of top-down and bottom-up I had to implement.) -- RagCall (talk) 13:59, 2 April 2022 (UTC)

@PSGarak Is there any way we can use the concept to implement missing restrictions on existing HD content?

Also, could you please take a look at the concept and see if you can come up with some more efficient ways? I really don't like how I had to separate "Actions reached from storylets" and "actions reached from storylets which are reached from other actions", as well as how it relies on the category to pull the list of qualities. -- RagCall (talk) 12:41, 26 May 2022 (UTC)

Sadly not, at least in the current iteration of things. I experimented with using Concept:Whitsun for adding Festival tags. It seems that Concepts cannot be used in Printout statements the way that Categories can! Seems like a rather big miss to me. In fact I might even file a bug report with the SMW project. At least Concepts can be used for auto-guide links, so the work isn't wasted.

I'll take a look at HD, but my imagination might be limited by not having played that Ambition. I have a poor sense of Concept efficiency (beyond tree depth), but since that content is "done" I also don't think it matters as much? I had at some point imagined structuring a Light Fingers concept series around story segments, but since I haven't actually tried I don't know if it's feasible or maintainable. PSGarak (talk) 13:13, 26 May 2022 (UTC)

The question would essentially be if this is the manner of doing things we are going to go forward with for other large chunks of content (Ambitions, SMEN, possibly Affair of the Box, etc), or if there is a neater way to do it. The approach I initially wanted to do was the following:

• take the relevant qualities (i.e. thos exclusive to the ambition). put them into the QUALITIES list.
• find the actions that require or raise qualities in QUALITIES. put them into the ACTIONS list.
• find the stories that require qualities in QUALITIES. put them into the STORYLETS list.
• find the actions that are available from storylets in STORYLETS. add them to the ACTIONS list.
• for all actions that redirect to a storylet, find the storylets they redirect to, add them to the STORYLETS list.
• repeat above steps until none of the sets change.

The problem is that the wiki cannot handle this kind of recursive update/circular dependency between actions and storylets, so I ended up separating the "storylets which are accessed via redirect from an action in the ACTIONS list" into their own thing :/ the downside is that currently, you have no way to account for "redirect chains" of abitrary depth short of manually adding such storylets. That is, my approach cannot really capture a thing like "slet 1 has action 1.1 which redirects to slet 2 which has action 2.1 which redirects to slet 3 which has action 3.1 which redirects to..." to an arbitrary depth - everything after and including slet 3 would have to be added to the list of STORYLETS manually, which is prone to error. -- RagCall (talk) 13:56, 26 May 2022 (UTC)

Take it for a spin

Examples of how it looks and how it works:

{{Property category}}

• a list of actions that increase Shapeling Arts: Fairly standard use, has Ambition & Festival tags.
• a list of uses of Experimental Object: Heavy use as both Unlock and Text.
• a list of Glasswork challenges: with challenge difficulties.

{{Property listing}}

• User:PSGarak/Sandbox/Shard of Glim: Sources and Uses
• User:PSGarak/Sandbox/Searing Enigma: Sources and Uses

Both these templates have their full Docs pages written. If you want to try them out somewhere on your own, summary of usage is as follows:

• {{Property category|<Object=item or quality>|<Property=property>|<Description=link anchor text>|<Header=Header text on category page>}}, with Extra and Record optional
• {{Property category|<Object=item or quality>|<Property=property>|<Description=used in several pages>|<Header=passed to Property category>}}, with Extra and Record optional

- PSGarak (talk) 19:56, 2 March 2022 (UTC)

Someone should teach me how to make a forum post with sub-headers that doesn't get split into pieces, because for the life of me I can't seem to figure it out. PSGarak (talk) 19:57, 2 March 2022 (UTC)

If you don't want each section to be reply-able don't use sub-headers to separate them (use some different formatting or we could make a fake heading template). The fact that this forum works using Convenient Discussions has some peculiarities (as it relies on headers). Sorry about this, it initially didn't cross my mind that anyone would want to use multiple headings but it does seem useful for longer project threads. And if you Do want multiple reply-able sections you have to sign each of them to display correctly! I still don't think many people would use more than one but I'll include this info in the new topic instructions to be safe. Also you can ping folks for extra notice! @PSGarak. CarrONoir (talk) 12:46, 8 March 2022 (UTC)

The list of Glasswork challenges currently lists the respective actions as "in Fallen London" - I assume because they themselves have no location set. -- RagCall (talk) 20:30, 2 March 2022 (UTC)

That's the "doesn't always return data" issue. Refresh the page and you should see real locations.

You're right that "Fallen London" is the default for when location data is missing. But in this case it's in the storylets, just got lost in transit. PSGarak (talk) 20:50, 2 March 2022 (UTC)

Release Candidate 1.1

Under-the-hood updates only. There should be no user-facing changes, except that data ought to be more reliable now, and certain links are no longer styled as exit links.

Major re-architecture of the "From message" (like "an Action from Epistolary Matters, a Storylet in Your Social Engagements"). Previously five Properties were queried and a Template cobbled the result together. Now this value is created on the relevant Card/Storylet/Action page and stored in Property:From message. Logic was added to {{Card}}, {{Storylet}}, and {{Action}} to generate these values. The stuff added to {{Action}} was somewhat complicated, since it appends to the From message of its Property:Fcs. This new property might be useful elsewhere, hopefully.

There is probably a long tail of primary templates that need updating. The addition to {{Action}} actually happened in {{SetSMW/FromField}}, which ought to catch some of those. These results are still percolating in for Actions.

- PSGarak (talk) 03:13, 6 March 2022 (UTC)

*nosepinch* we really should get on merging those social action templates, huh. Thanks for the update! -- RagCall (talk) 06:11, 6 March 2022 (UTC)

I'm happy with the current state of things. And for whatever reason, I don't need to refresh the page to get the SMW data to show up (I assume Alan fixed some cache something). Unless I hear otherwise, I'm going to roll these out tomorrow. Updates pieces will be the raise, lower, use, and challenge links in {{Quality}} and the gain and use links in {{Item}}.

- PSGarak (talk) 02:59, 18 March 2022 (UTC)

For documentation purposes: The FM is used in the new {{From}}. -- RagCall (talk) 08:38, 18 March 2022 (UTC)

Feedback

My biggest complaint is that I'd expected all the different use types to be listed separately by default. IMO text and math uses aren't looked up that frequently. It'd also help with the additional information listed by each entry, which I think we could trim somewhat. TFF (talk) 19:02, 18 March 2022 (UTC)

I'm not sure I understand. Right now there are separate line-items for Text, Unlock, and Math uses. In fact, the same action will get listed twice if it's both an Unlock and a Text Use (which I'm not overjoyed about, but I can live with it).

Are you saying you want them sorted by use type? Or different pages for the different use types?

I agree the additional information gets a little busy sometimes, but I feel like everything there is something I want at least some of the time. Perhaps the presentation could be changed to make it feel less cluttered? I'm open to suggestions. (Or hack away yourself, that part is isolated into Template:Property category/Item.) PSGarak (talk) 19:20, 18 March 2022 (UTC)

Yes, I would prefer if all the use types were grouped separately. For example, you'd start with unlocks, then the math and text uses if applicable, so we could avoid listing the individual types after each entry and just have subheadings instead. TFF (talk) 19:34, 18 March 2022 (UTC)

Ok, I see what you mean. I agree that would be an improvement on the Category pages.

I tried something quick, and it only halfway worked. The "Category" results format is kinda all-or-nothing, and lacks some customizability, so I'm not sure that custom headings are supported. I'll need to poke around more. But if it does work, I agree it will be an improvement. PSGarak (talk) 20:14, 18 March 2022 (UTC)

Noticed that manually added categories don't seem to show up on any of the linked pages anymore. TFF (talk) 09:35, 21 March 2022 (UTC)

Manually-set categories will have to be replaced with manually-set Properties via calling #set. I.e. [[Category:X Gain]] will need to be augmented/replaced with {{#set:Gains = X}}. Hopefully the need for manual annotation will drop significantly, now that we use {{Gain}} on Fate pages. PSGarak (talk) 17:05, 21 March 2022 (UTC)

Echoing views expressed on the wiki discord, I'd strongly support abbreviating some of the tags used for restrictions in category pages. Chthonic Scrip was used as an unseemly example. The easier targets at the moment imo are ROSE, GCO and FRUITS for festivals and HD, LF, BaL and Nem for ambitions. TFF (talk) 07:12, 23 March 2022 (UTC)

Yes, that makes sense to me. Those are some big tags.

The appearance of the tags is set by {{Restrictions/Formatter}}. Abbreviating the Ambition tags is easy enough, since those are just {{IL}} calls.

It looks like shorter versions of the Festival tags will require modifying {{Font}}. I could probably copy-paste something functional, but I'll defer to @Asarta if they want to take lead on it. Alternatively, if some front-end wizard thinks this can be solved by using CSS to make them display differently, {{Property category}} always puts some span classes around those tags.

I would prefer to make all the updates to {{Restrictions/Formatter}} in a single batch, since changing it will probably make the Wiki grind for a bit.

- PSGarak (talk) 14:30, 23 March 2022 (UTC)

Smol bug

It seems that items whose image names include spaces (or underscores, as the case may be) break the "list of all results" link - Chthonic Scrip, uses section. Alan (talk) 22:19, 25 March 2022 (UTC)

It resembles a bug I saw before in some functionality which has since been removed, which is fortunate because fixing that bug took a month and a half the first time around. Fix is pushed, and it looks like it doesn't break anything else (famous last words).

When links are passed as intro/outro text to #ask, they get encoded in a way that's apparently idempotent. If you pass an #ask into an #ask, then a link the intro of the inner #ask will get decoded by the outer #ask, resulting in spaces where there should be underscores. Then Wikimedia's parser treats everything after the first space as anchor text instead of part of the URL.

The solution is to percent-encode underscores at the inner or middle level. Note that the urlencode Magic Word won't do this because underscores are not reserved URI characters. You need to use #replace (or in this case, Module:String for length reasons) to swap _ for %5F. PSGarak (talk) 01:18, 26 March 2022 (UTC)

nasty hacks and fixes

I've added a few nasty hacks to Mediawiki:Darkcosmos.css to hopefully make everything play nice with dark mode, and added a few plainlinks to various places. Note that said plainlinks are in {{Quality}}, not the underlying templates, so further changes will need to add them seperately --Asarta (talk) 19:06, 18 March 2022 (UTC)

Re:plainlinks, it looks like you're just wrapping the calls to {{Property category}} in a span, right? We can change Property category to including the wrapping span itself. PSGarak (talk) 19:15, 18 March 2022 (UTC)

I tried that, but I ran into weird issues, and its too late for me to debug now --Asarta (talk) 20:01, 18 March 2022 (UTC)

Peeking in the edit history, it looks like you were missing a closing doublequote character in the HTML? Definitely a 10pm kinda thing. PSGarak (talk) 20:07, 18 March 2022 (UTC)

That is entirely possible. Considering my brain tried typing <class="plainlinks"> three times before realising that is not in any way valid html I am not trusting anything I do right now. --Asarta (talk) 20:23, 18 March 2022 (UTC)

What to do with existing categories

This has been rolled out for a while on quality and item pages. This means that those pages no longer link to category pages. Also categories for new qualities/items moving forward will have no links encouraging people to fill them out with {{Item Sources}}, {{Quality uses}}, etc. Links to categories still exist in the sidebar/gutter of actions belonging to those categories, but not in the main content of any articles (except for perhaps a few stray guide articles).

So, what are we gonna do with these categories?

I think we should at least review which categories have non-trivial content, and move that content elsewhere (or delete if outdated). I expect that most such content will be in {{Item Sources}} pages, which can get merged into item grinding guides. Where these guides existed, they weren't very discoverable, so I think migrating them is a net benefit.

The pages themselves, I dunno. I don't find myself often looking at the list of categories on an action page. To me it seems a lot of noise, redundant with (and less structured than) the in-line results. I am in favor of removing the category annotations entirely in favor of the semantic searches accessible from quality/item pages. But that is a rather extreme measure, and if those category pages still get used by anyone then of course we should keep them.

- PSGarak (talk) 20:30, 15 April 2022 (UTC)

I agree that categories are in a bit of an odd spot now. Wouldn't mind moving anything still in the category pages to dedicated guides, but probably wouldn't support visibly removing them entirely from most pages on the site. They don't usually take up much space, and I find it convenient to see if something I'm editing/planning on editing is in a maintenance category. I'd also be wary of replacing them entirely with semantic searches, considering last time people reported being significantly more comfortable using them than SMW.

On that note, I've been thinking of putting together a new survey to assess responses to the work that's gone into dealing with feedback from last time, perhaps also collect some more detailed usage data that'd help us moving forward. TFF (talk) 10:26, 16 April 2022 (UTC)

Sorry if I wasn't clear, I wasn't suggesting the removal of all categories, or the listings. Just the gain/loss/use categories set by {{Gain}} & friends. But as you say, there's not much need to remove the links either. It also just occurred to me to wonder whether properties can be displayed on a page the way categories are, I'll spend some time reading smw:Factbox and pondering.

A new survey would be useful, there have been some meaningful updates since the last one. I believe at the time of that survey, "using SMW" basically meant "writing queries by hand in Special:Ask" as no template-built queries existed. Feedback on the replacements, including criticisms, would be much appreciated.

Let me know if you want concrete suggestions about collecting or analyzing "detailed usage data." My Surface job is web analytics. I assume privacy & regulatory concerns preclude the use of Google Analytics; there are a number of self-hosted alternatives, or even logfile parsing (to the extent that's not completely trashed by caching).

- PSGarak (talk) 18:58, 16 April 2022 (UTC)

Sure, if we can display relevant properties similarly to how categories are shown now, there's not much use keeping everything that's been superseded.

As for the usage data, I meant some questions in the survey that ask in more detail how people use the wiki. There were some last time, but I want more info on what people find helpful or not, so we can adjust accordingly if needed. The BDFL has occasionally shared data you might find useful though. TFF (talk) 20:37, 16 April 2022 (UTC)