Towards a new AO3 Posting form
Jul. 10th, 2012 05:27 pmSo, 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:
( Rough mock-up of a possible posting form and details. )
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:
( Rough mock-up of a possible posting form and details. )
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.