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-10 11:10 pm (UTC)no subject
Date: 2012-07-10 11:34 pm (UTC)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
Date: 2012-07-10 11:37 pm (UTC)I do have some hope it would be more intuitive to the Archive users, just because the idea of a tag that looks different than its destination is already established. *crosses fingers* But yeah, that's... not hopeful.
no subject
Date: 2012-07-10 11:54 pm (UTC)no subject
Date: 2012-07-10 11:53 pm (UTC)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
Date: 2012-07-10 11:37 pm (UTC)Re: the other issue about filling in with the input from another form field, I can confirm that it's possible to do with if statements as it's also something I've set up before. It should also be quite easy to automatically label them as "needs review".
no subject
Date: 2012-07-10 11:44 pm (UTC)Quinara has a lovely idea about the display name fields below, too.
no subject
Date: 2012-07-11 05:25 am (UTC)Though I would suggest a limit on how many additional fields you can add (in one go? for one story? in one time period?), or there will be someone (because there's always someone) who will attempt to find that limit and go past it. And that's a whole 'nother ball of wax.
no subject
Date: 2012-07-10 11:39 pm (UTC)no subject
Date: 2012-07-10 11:41 pm (UTC)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
Date: 2012-07-10 11:41 pm (UTC)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
Date: 2012-07-11 04:13 am (UTC)*wry* I can understand the twitching, given the culture AO3 has built up and advertised. It's just that... it's like a see-saw. We can either have set-term links that reliably find work or we can have everyone's-own-style links that only find some (*rueful* or we can try to mash both together with spit and volunteers and watch the servers crash). So, yeah, if the freeforms and the aliases can be completely divorced from the navigation, that feels like the best possible balance of the two. I hope the user base at large would feel that it's a reasonable trade-off.
no subject
Date: 2012-07-11 04:47 am (UTC)The fact that the AO3 DOESN'T live up to their promise of doing whatever you want with tags, actually, is extremely frustrating because when you deliberately sacrifice a good measure of something like search/navigation for your philosophical/ethical concerns you should probably, um, go all out. (And, just, I assume they realised they WERE sacrificing a measure of search/navigation because there was never going to be any way the volunteer wranglers could stay so on top of wrangling new tags that there wasn't ever noticeable lag on wrangling when people introduced new tags.)
This actually seems like it would be a way of addressing some of the ways that the current system still fails to give control. It actually lets the creator declare which canonicals are associated with their work (and currently, you don't -- you can tag whatever you like, sure, and then someone else does the wrangling to associate it to a canonical, unless you happen to be a wrangler yourself), while also giving them complete control over how it displays on their story.
no subject
Date: 2012-07-11 05:35 am (UTC)But the presentation is key, it seems. To explain, plainly and simply, that databases just cannot have multiple tags in every direction if the information will be easily and quickly findable does shut up most of the complaints. It's not something negotiable, really, when it comes to setting up a database to be efficient: consistency is key. Present it as, "do you want the tags to find results quickly and easily, or do you want the site to crash and/or your browser to freeze while the server chugs through sixty extra tables"...
People quickly realize that the trade-off is NOT between "speshul snowflake tags" versus "we are the OPPRESSED tag-users"; it's between "efficient and reliably quick search results from a well-organized database" and "mass chaos, dogs and cats living in sin, servers crashing, readers who can't find jack and won't stick around for a second attempt". Or, at least they realize that once you present those as the real options. And draw a line, and make an executive decision. This is not something I'd put up for a vote. It's a boundary set by intelligent developers and their managers, and like boundaries, is there for everyone's good and not something that requires anyone else's permission to negotiate. There's plenty else to negotiate on (like, say, the UX of your UI), but the database design? No.
The developers -- if there are any who, y'know, can develop -- are used to being the bad guys. Usually in most projects: sorry, dev says that just can't be done. Period. Have a workaround, but here, there may not be dragons but there will be a catastrophic database failure. Which is pretty much the same thing as terrifying monster just over the horizon, if you ask me.
no subject
Date: 2012-07-11 05:42 am (UTC)no subject
Date: 2012-07-11 06:09 am (UTC)no subject
Date: 2012-07-11 06:12 am (UTC)no subject
Date: 2012-07-11 07:23 am (UTC)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
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.