Towards a new AO3 Posting form
Jul. 10th, 2012 05:27 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
So, let's think about the Archive posting page.
(Background for anyone just joining: I am strongly in favor of ditching the tag-synonym structure and selecting from the pool of canonical tags for fandom/character/relationships posting fields. Menus can then be far more simply generated, and malformed tags or wrangling accidents will not make stories un-searchable. This would involve some fairly simple modifications to the current database, and the addition of a few forms and form fields.)
The posting page really does feel like the keystone of the idea. That is the page where workflow would have to change most. So! Let us consider how it might work.
For one thing,
troisroyaumes had a fascinating idea: what if there were a few columns added to the Story table of the database, to hold, not tag synonyms, but alternative link text for the canonical tags? That would require a little more complexity in preparation for the change-over, to create those fields and populate them with the current synonym names, but it wouldn't be all that much more work and would preserve the possibility of user-chosen tag text while not interfering with or complicating (or breaking) navigation. That strikes me as a far more workable middle ground than the current system.
Those fields would definitely require some significant revision to the post-form, though. Here's what I'm imagining so far:

What I'm imagining is that the first part of the posting form should be divided into sections, visually and by text labels. First come the required tags, Fandom/Rating/Warnings. Then come the optional tags, Character/Relationships/Tropes/Additionals. The form is further divided into what I have, for the purposes of the mock-up, called "menu tags", the tags to be drawn from a pool of canonicals, and which will appear in the various filter-menus. These would include Fandom, Character, Relationships, and Tropes. Then there are the "freeform tags", which is, in this revision, limited to the Additional tags, which would be linked but not wrangled in any way--that would be the pure folksonomy section.
The prompt-as-you-type function for Fandom/Character/Relationship/Tropes tag fields should draw on the canonicals pool for each field type. (Needless to day, names of new things are all placeholders, here.)
So far, so simple. Now we come to the modifiers. Some are on-demand. Down the right side, along with the distinction between Menu and Freeform tags, there are two 'buttons'. One is for when the pool of canonicals does not yet contain a required tag. Maybe you're the first poster in that fandom. You should not have to interrupt your posting process more than absolutely necessary, to request new canonicals. So the first button would, ideally, pop up an in-line form for requesting one or more new canonicals. The inline form should probably ask the poster to input all new canonicals they wish to use for this story, and should have infinitely expandable fields upon clicking a plus button or something, to accommodate this.
If someone attempts to enter text into a Menu tag field that does not match any canonical, a message should come up to the effect that this field must be drawn from the canonicals, and if the right one doesn't seem to exist, perhaps the poster wishes to request new ones (button to in-line request form).
If that form is submitted, then the page should populate the Menu tag fields with whatever new canonicals the poster requested (and there must be a way for the form to process this as "legal" population despite the tags not existing yet). When saved/posted, this story will be put temporarily in Uncategorized and a flag will come up in the wrangler taskflow list, asking someone to come review and approve the new canonicals. If they seem to require editing, the requested form of the tags should be moved to the Display Name field and the canonical form entered in the Menu tag field in question.
So, about those Display fields. The lower part of the picture above shows what it might look like when someone has hit the button for "display alias fields" (or whatever verbiage seems most intuitive there). On that demand, fields are revealed below each Menu tag field, into which alternative text can be entered. This text does not create a new tag, and work would only be searchable by these under "any field" text searching. Instead it becomes part of the Story table text fields (right along with summary and body and so on) and is used as the link text, while the link url is still drawn straight from the canonical. Depending on the script for displaying stories, the Display database field can either be left blank or, if not filled in, auto-populated with the canonical name.
If someone enters text in the Display field without having entered text in the associated Menu tag field, a prompt should come up to the effect that a canonical must be selected before alternate display text can be assigned to it.
That leaves the problem of what to do when there are multiple terms in a given field, especially if only some of them are to be aliased. So, if there are multiple terms present in the canonical field, there needs to be some mechanism for the poster to select which alias goes with which canonical. I lean away from drag-and-drop, because that has such accessibility issues, but maybe number matching would work. Anyone know of any good methods for linking two bits of data, through a form? ( quinara has an excellent idea about this)
Thankfully, the rest of the form can stay just as it is! So, there's a start on the idea. What do people think? Are there other cases that would need to have the logic and triggers worked out? Any form-bits that are missing?
I'm thinking there should also be links to the canonical pools of each field type for the Fandom(s) in question, in case people want to check what's available, but I can't decide what seems most useful and findable: a link under the label, or a link on the far end of the text field. Under/after the label, so screen readers know it's there, maybe?
Also, does anyone know how to let a form take the kind of information it would not normally allow, as long as that information is passed to it by another form? So that, despite the Menu tag fields being limited to canonicals, they could still be populated from the "request new canonicals" form. And also enter those requested tags as "requested" or "provisional" instead of "approved". I'm thinking this is just adding the right id or value and then a lot of "if" statements in the script, but I don't deal with such complex forms that often so I'm not sure of that.
(Background for anyone just joining: I am strongly in favor of ditching the tag-synonym structure and selecting from the pool of canonical tags for fandom/character/relationships posting fields. Menus can then be far more simply generated, and malformed tags or wrangling accidents will not make stories un-searchable. This would involve some fairly simple modifications to the current database, and the addition of a few forms and form fields.)
The posting page really does feel like the keystone of the idea. That is the page where workflow would have to change most. So! Let us consider how it might work.
For one thing,
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Those fields would definitely require some significant revision to the post-form, though. Here's what I'm imagining so far:

What I'm imagining is that the first part of the posting form should be divided into sections, visually and by text labels. First come the required tags, Fandom/Rating/Warnings. Then come the optional tags, Character/Relationships/Tropes/Additionals. The form is further divided into what I have, for the purposes of the mock-up, called "menu tags", the tags to be drawn from a pool of canonicals, and which will appear in the various filter-menus. These would include Fandom, Character, Relationships, and Tropes. Then there are the "freeform tags", which is, in this revision, limited to the Additional tags, which would be linked but not wrangled in any way--that would be the pure folksonomy section.
The prompt-as-you-type function for Fandom/Character/Relationship/Tropes tag fields should draw on the canonicals pool for each field type. (Needless to day, names of new things are all placeholders, here.)
So far, so simple. Now we come to the modifiers. Some are on-demand. Down the right side, along with the distinction between Menu and Freeform tags, there are two 'buttons'. One is for when the pool of canonicals does not yet contain a required tag. Maybe you're the first poster in that fandom. You should not have to interrupt your posting process more than absolutely necessary, to request new canonicals. So the first button would, ideally, pop up an in-line form for requesting one or more new canonicals. The inline form should probably ask the poster to input all new canonicals they wish to use for this story, and should have infinitely expandable fields upon clicking a plus button or something, to accommodate this.
If someone attempts to enter text into a Menu tag field that does not match any canonical, a message should come up to the effect that this field must be drawn from the canonicals, and if the right one doesn't seem to exist, perhaps the poster wishes to request new ones (button to in-line request form).
If that form is submitted, then the page should populate the Menu tag fields with whatever new canonicals the poster requested (and there must be a way for the form to process this as "legal" population despite the tags not existing yet). When saved/posted, this story will be put temporarily in Uncategorized and a flag will come up in the wrangler taskflow list, asking someone to come review and approve the new canonicals. If they seem to require editing, the requested form of the tags should be moved to the Display Name field and the canonical form entered in the Menu tag field in question.
So, about those Display fields. The lower part of the picture above shows what it might look like when someone has hit the button for "display alias fields" (or whatever verbiage seems most intuitive there). On that demand, fields are revealed below each Menu tag field, into which alternative text can be entered. This text does not create a new tag, and work would only be searchable by these under "any field" text searching. Instead it becomes part of the Story table text fields (right along with summary and body and so on) and is used as the link text, while the link url is still drawn straight from the canonical. Depending on the script for displaying stories, the Display database field can either be left blank or, if not filled in, auto-populated with the canonical name.
If someone enters text in the Display field without having entered text in the associated Menu tag field, a prompt should come up to the effect that a canonical must be selected before alternate display text can be assigned to it.
That leaves the problem of what to do when there are multiple terms in a given field, especially if only some of them are to be aliased. So, if there are multiple terms present in the canonical field, there needs to be some mechanism for the poster to select which alias goes with which canonical. I lean away from drag-and-drop, because that has such accessibility issues, but maybe number matching would work. Anyone know of any good methods for linking two bits of data, through a form? ( quinara has an excellent idea about this)
Thankfully, the rest of the form can stay just as it is! So, there's a start on the idea. What do people think? Are there other cases that would need to have the logic and triggers worked out? Any form-bits that are missing?
I'm thinking there should also be links to the canonical pools of each field type for the Fandom(s) in question, in case people want to check what's available, but I can't decide what seems most useful and findable: a link under the label, or a link on the far end of the text field. Under/after the label, so screen readers know it's there, maybe?
Also, does anyone know how to let a form take the kind of information it would not normally allow, as long as that information is passed to it by another form? So that, despite the Menu tag fields being limited to canonicals, they could still be populated from the "request new canonicals" form. And also enter those requested tags as "requested" or "provisional" instead of "approved". I'm thinking this is just adding the right id or value and then a lot of "if" statements in the script, but I don't deal with such complex forms that often so I'm not sure of that.
no subject
Date: 2012-07-10 11:10 pm (UTC)(no subject)
From:no subject
Date: 2012-07-10 11:24 pm (UTC)It's terrible. It's in a couple of small websites so I don't know about performance, but it's unintuitive (everyway it's been implemented), the clients always force the tech guys (mostly me these day) to do it for them and we still get special snowflake arguments. So many special snowflake arguments. (each of thise websites represents about 20 people) Based on my experiences I can't even think about it as a potential solution - because arguments I've already seen about ao3? Boom.
I'm conflicted on how I feel about ao3, I really like the ability to control how my tags look and make new ones. but making tagging structure and policies visible needs to happen, and their needs to be more caching and reasonable queries.
(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-07-10 11:25 pm (UTC)What about making it one tag per field, with a "gimme another field" button so people could enter as many as they wanted? (I don't know if that's what you were suggesting on the new canonical request form?)
I think I understand the alternate display text thing better now, too, and it sounds brilliant! I like how that would handle generic names, for one thing, that I could just have it show "Treize" rather than "Treize (Allison & Lillia)" without me or anyone else having to mess with a metatag that has one foot in Gundam Wing and is probably not actually a useful search for anyone... (Messing with that exact metatag was one of the very first things I ended up doing as a tag-wrangler, BTW, true story.)
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-07-10 11:30 pm (UTC)At the moment, I'm fairly certain, hitting return or typing a comma after tag text makes it shift into a list of 'completed' tags (or whatever the actual phrase would be) above the text box: would it not be possible for that process actually to take the selected canonical tag text, list it as uneditable text and then present another text box on its right showing how it would display, initially/automatically populated with the canonical version of the text, but editable at will for each tag? So I could select/initially type the tags 'Jim Smith/Helga Jones, AU, pre-series' and then assign display text individually as 'Jimga', 'wtf' and leave 'pre-series'... I don't know how much more stress that would put on databases etc, but that's how I'd expect the form to naturally react.
(no subject)
From:no subject
Date: 2012-07-11 03:54 am (UTC)Because, yeah, I found your previous post very interesting but had nothing like the energy to engage in discussion/debate about why while I could see your very valid performance concerns, I was twitching like hell at the imposition of tag formatting on users.
I will admit I do still wince a smidge and I'm not entirely keen on the idea of wranglers being able to directly affect which tags go on a work even when it's a matter of new tags/canonicals, but this seems like something that could work scalably for the kind of enterprise level platform the AO3 already is/needs to be/will grow into, without involving any kind of leaps of genius. It seems... possible? Practical? And actually in some ways this method could give you significantly MORE control than you currently have over tag formatting. (I'm... bitter about the capitalisation issues I've encountered, perhaps.)
Relatedly, I do think a seperate metadata field for tags that are not meant to be searchable (ie, tumblr style tags) would also go a hell of a way towards lightening the load on both servers and wranglers alike. Those tags are often/usually long and very specific to a given work and it's just absurd to fold them in with the other folksonomy genre/flavour/additional tags even if I'm entirely happy for them NOT to be folded in. (Or in some cases, might prefer them not.)
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-07-11 09:19 am (UTC)to the war has gone by busaikko, Stargate Atlantis
General Audiences, No Archive Warnings Apply, Gen
***Tags: No Archive Warnings Apply, John Sheppard, Original Female Character, Mother-Son Relationship, Home***
Summary: Coda to The Minstrel Boy. Spoilers in the end notes if you haven't read that.
***Author Tags: no actual hamsters harmed in this story, John's woobie face***
--> where the Author Tags are not hyperlinks and not searchable as tags and therefore do not require wrangling of any kind (technically, 'John's woobie face' *could* be linked to canonical:John Sheppard, but as I've already used that tag, there's no reason to).
I'd... really like to have pull-down menus. The automatic prompting has never worked well for me (I need to type in a word, backspace until there are 3 letters left, and start typing it in slowly, hoping that something will come up.)
(no subject)
From:(no subject)
From:(no subject)
From: