Towards a new AO3 Posting form
Jul. 10th, 2012 05:27 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
branchandrootSo, 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,
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.
no subject
Date: 2012-07-11 03:56 pm (UTC)God, I hear you so much about the pulldowns. It's just that they'd be so long for some fandoms... although... I wonder if we could manage multi-level pulldowns for the cast-of-thousands fandoms. Those are usually broken up into some kind of useful subdivisions--teams or species or whatever.
The Trope/Genre would probably have to be some kind of cloud in a pop up from which you could select. There are already something like five thousand of those, and even flattened into their ultimate parent tags, I'm betting it would be well over a thousand total after retrofitting.
no subject
Date: 2012-07-11 09:16 pm (UTC)no subject
Date: 2012-07-11 09:22 pm (UTC)Definitely some kind of on-demand list of All The Canonicals for any given field, though, and one that can be selected from. Checkboxes, maybe. However it's formatted, that's an absolute must.