*drums fingers*

The more I think about the idea of a display-name/alias for canonical tags, the more I think: it's going to have to be a new table.

I'm pretty sure that it would be faster to store any given story's aliases in a single field of the Story table as a string of key-value pairs. But those pairs would need delimiters that would not ever show up in the aliases themselves and that... that's not something I really want to bet on, when it comes to fandom, names, and the evolution of pairing syntax.

It would also be more accident prone during the canonizing of the tags. (I'm starting to feel like I should capitalize that phrase. Like the Running of the Bulls or something.)

So. Separate table, nice and simple, with columns for story id, canon-tag id, and alias. I'm thinking story id should be the primary key. The most frequent use is going to be producing story-blurbs, and I'm guessing this sucker is going to have to be partitioned. So, partition by story id range and crank that into the one extra query this will create per story (or at least prepare for it; it might not be necessary yet).

Putting aliases in their own table will also make them far more easily searchable. petronia pointed out that some fan cultures, for example the Chinese-language fans, will want and expect to be able to search for things like "Sasuke/Naruto" as distinct from "Naruto/Sasuke", and also search for things like "*/Sasuke" (that is, anyone/Sasuke). Putting a specific "search display names" option on the Advanced search, and putting the aliases into a table of their own with one alias per field, will make that a lot more feasible. It won't be perfect, because it will rely on authors to alias, but there should be some significant overlap between authors who will alias like that and authors writing the kind of fic members of that fan culture want to see.

Now the first step of the Canonizing of the Tags is a lot simpler. Relatively speaking. For each story, get the current tags; get the names and ids of those tags; write them to the alias table. That can run in the background as long as it takes, since it won't affect anything yet.

The new posting form has to be prepared next, so that it's ready to present canonicals and "talk" to the alias table. The new code to display story blurbs and pages will need to be done up, but that should be nice and straightforward. Incidentally, I quite like busaikko's idea of putting Additional tags, possibly labeled Author Tags, under the summary to make them clearly separated from the menu tags and more clearly part of the author's own meta-information about their work. That would prepare the way to possibly show Reader Tags, and make them clearly distinct from anything the author zirself put on the story.

And now the canonization query should run smoothly, as each child-tag id is replaced with the id of its final parent tag, including the ids in the alias table. Which will, after the query runs, match up with the changed ids in the Story table. And without needing any dangerous, and slow, additions like "match any number that comes before X delimiter in this long string". *dusts hands*

Best of all, as niqaeli points out, this can be considered an improvement in user control of their own content. Users would now be able to absolutely control what canonicals are associated with their stories, instead of being forced to leave that up to the wranglers. (Which must surely be less nerve-wracking for the wranglers too...). The user will still have control of exactly how all the text of their content appears and, since no user actually has control of how the navigation structure appears right now, no one will lose any control they had.

So there is an increase in user control, plus an improvement in searchability, a considerable improvement in stability and performance, and a huge improvement in the efficient use of wrangler time that might let them be more pro-active in populating new fandoms with suitable canonicals ready for author use. This should even, much as it disgusts me, let the OTW leadership avoid Step One from my previous post. So get cracking, people.

Okay, since the review process is clearly backed up, here is a copy of the skin I made to quickly fix the worst problems with the new Archive default. It's submitted to be public, free to one and all, have at it.

Go to Your Home, click on Skins in the first module of your sidebar. Select the Create Skin button at the top right of the Skins page. On the skin-creation page, paste the CSS below in, and name it something.

Now click on the Advanced button at the bottom. For "What it does", select "Replace an archive skin entirely". Down under Parent Skins, click "Add a parent" and type in Archive. From the dropdown that will give you, select Archive 2.0. (Yes, it's counter-intuitive.)

Save it! Lo, you have a new skin. Down at the bottom of the skin page or skin blurb there is a button for Use. Click on that and you're good to go.

( The CSS )

Here is bonus CSS, courtesy of annoted_em: a list of all the red, should you wish to change the accent color out for something different. Just replace all these reds with color-of-your-choice and add this to the bottom of the above CSS.

( The Reds )

Lo, I have finished (I think) my first skin for AO3!

( Check it out. )

I'm happy to offer the css to anyone who wants it, but I'm not applying to make it public yet because to make it really work requires an "auxiliary" style sheet in your browser styles for the handful of things the skin-maker spazzed over. Stylish is our friend.

But I'm really pretty pleased with this one. *basks in the happy glow of success*

So, the css. Unfortunately, the title will only look that spiffy if you're on a Mac. Windows users should look down to where it says #header h1 {font-family: Zapfino, cursive; }, and put your favorite large, pretty font in place of "Zapfino".

( This goes in the AO3 dialogue. )

( And this goes in Stylish et al. )