TV Tropes 2.0: Database level redesign (Not in active development yet)

Long discussion going on in ATT about some of the upcoming changes to example writing in the new site, such as the name of the work in trope lists being automatically at the beginning, enabling automatic crosswiking.

Some of the fears are that a more "professional" standard will interfere with the 'fun' nature of the wiki.

Discuss and bring up new points on all sides politely please!

Coming back to where you started is not the same as never leaving. -Terry Pratchett

I'd be more worried about having to rewrite every example on the site

We (the mod team) have already submitted a large and comprehensive design principles document to the site's owners, documenting our ideas for a data-driven site architecture that would largely replace the current free-form text entry model.

In this architecture, an example would be a data relationship between a trope and a work, with those categories very broadly defined. Each example would have an associated description element that would contain the explanation of its use. When rendered on a wiki article, each example would take the form:

• Linking object: Description

Obviously, when rendered on a trope article, the work would be displayed as the linking object, and on a work article, the trope would be displayed. There would be no option to write examples that do not include the linking object, so this format would be absolute. The only exception would be within categories that don't implicitly require association with wiki articles, such as Mythology, Real Life, and whatnot.

The intent is for users to focus on the description elements — making them witty, memorable, and sufficiently detailed. These elements could contain markup, of course, so potholes and wicks within them are perfectly fine.

A parser would have to be written to convert existing articles to the new format, and it would treat the first wick on any given bullet as the intended linking object. If that example is already formatted according to the proper scheme (Link: Description), then it would strip out the link from the description as it would be redundant. Beyond that, it would not attempt to rewrite the example, so there would be some awkward ones until people went through and corrected them. That's unavoidable.

This system would offer tremendous advantages over the current one:

• It would allow us to hinder zero-context examples by requiring a minimum amount of description text.
• It would allow dynamic sorting and filtering of examples within an article.
• It would allow the wiki software to dynamically create subpages and ensure that all examples go in the proper one automatically.
• It would prevent potholing of the linking article, which is a violation of example writing rules.
• It would let us design a UI to auto-suggest article links so you don't run into namespace confusion or ambiguation problems.

edited 18th Nov '15 5:42:25 AM by Fighteer

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

Databases are fun.

For that particular idea with the parser, it'd probably be a good idea to prioritise the first namespaced wick over the first wick, since in particular for character tropes, the character is named first, and sometimes potholed to a descriptive (or not) trope.

But there will be a lot of manual rewriting of examples. That's just how it is. At least the work pages have a set format that's easy to parse.

I'm curious about how it'll work for character tropes. Those quite often have have loads of examples on character pages without crosswicking, probably because people think that while a trope is important for a specific character, listing every single character who fits the trope on the trope page can be overwhelming.

Check out my fanfiction!

My idea is to create characters as virtual objects, allowing any given example to be assigned to one or more characters who are themselves objects within a particular work. Users can build a hierarchy showing how the characters relate to the work and to each other.

Taking Lord of the Rings as a case study:

• Archer Archetype would be a trope linked to the work.
• It would also be linked to the character Legolas.
• Legolas would be defined as a member of the Fellowship and a member of the Wood Elves, both groups of characters.

If you were to look at the work's examples list, it would show Archer Archetype. It would also appear if you drill down into the Wood Elves and if you look at Legolas' specific character entry. The Archer Archetype trope would only show one example, however.

If many characters in the work had the Archer Archetype trope assigned, then the work's examples list would automatically handle the indentation. We could set a threshold to squelch examples in very long or complex lists, permitting the user to manually drill down.

---

As for parsing existing data, I imagine that some kind of logic could be used to identify crosswicks, by looking at the trope page for any example entry containing a reciprocal link. If one is found, it would know that's the right example, and they would be merged. It's also our intention to allow alternative example descriptions for the trope and work pages.

edited 18th Nov '15 6:36:41 AM by Fighteer

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

That's kind of how I'd make it as well, depending on the underlying structure. It'd probably be doable to do the same or similar with works within a franchise. Hierarchies and linked objects work well in databases like this one.

For multiple examples in the same work, I'd imagine it wouldn't be too hard to add some kind of "view more" function if it exceeds three or five or whatever examples.

Looking forward to what will come.

Check out my fanfiction!

One of the greatest advantages of doing it this way is that it will eliminate almost entirely the need to manually create subpages. The renderer will be able to handle pagination of long articles and the split of examples by media category or by trope category automatically.

edited 18th Nov '15 7:03:31 AM by Fighteer

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

Would there still be a limit on page size?

Check out my fanfiction!

There might be a limit on displayed page size, but it would be user-configurable depending on your system's capabilities — and possibly also depending on how many server resources it takes to create. If an article exceeds the limit, it would display pagination controls, akin to a long forum thread. You could also dynamically filter for broad trope categories like Plots and Settings — any high-level trope index.

There should be no limit on the internal size of an article's example list, at least not one that could be reasonably exceeded.

edited 18th Nov '15 1:50:29 PM by Fighteer

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

I thought I mentioned trope categories, since that's something that has been brought up as a sorting method before, but I guess I edited that away.

Could you also do something like bring up a character who's in a few games, and sort out all tropes from a specific game?

Check out my fanfiction!

That's the idea. For characters that appear in multiple works, you would be able to create a landing page that would collate all the information about their various appearances. This landing page could have its own description element, so you can present a general writeup.

Implied is a work hierarchy showing the relationships between works within a particular franchise or 'verse.

Since each article will have an internal ID value that is stored with examples rather than a text wick, it would be relatively simple to keep Batman (Franchise) distinct from Batman (Character). Moreover, the editing UI will hopefully be able to assist users with disambiguation. "Did you mean 'Batman (Franchise)', 'Batman (1966)', or 'Batman (Character)'" and so on.

edited 18th Nov '15 7:19:59 AM by Fighteer

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

So, as a whole, nothing about this new system has anything to do with "fun" or the "breezy language". The system will force users to input more than just "Trope" on an example list and can organize things together. There's no software police going to crack down on what you're writing and force it into formal Wikipedia text.

"But don't give up hope. Everyone is cured sooner or later. In the end we shall shoot you." - O'Brien, 1984

Exactly.

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

This is all fascinating. Sounds like a fantastic change if enough of the wrinkles can be ironed out.

Questions:

As things stand right now, each trope example is repeated at least twice; once on the work page, once on the trope page. Theoretically there's no reason the text of each should be any different, but in practice, there are usually minor wording variations at the very least. It sounds like with this new system there will only be one version of the example text, which will be dynamically inserted to both the work and trope page (as well as relevant character pages, etc.) When the existing site is ported over to this new site, how will the parser decide which version to keep and which to discard? Or will it keep both, displaying one and retaining the other behind-the-scenes somewhere where an editor could manually restore it if they decide that it's the better-written version?

So generally speaking, in this new system every example must be accompanied by, at minimum, both a trope link and a work link, with exceptions like Religion and Mythology and presumably Real Life, which don't usually have work pages. Where does that leave works too obscure to have their own work page? If I realize that, for example, my favorite song is a One-Hit Wonder, but the band that created it doesn't have a page in the Music namespace, would adding them as a OHW example require creating a page for them with only one trope on it?

We intend to allow alternate example text for use on work and trope pages. By default, of course, it'll use just the one, but the option to have both will be available. Designing a suitable user interface for this will be tricky, although the initial data load will have both to work with in most cases.

As for work links, the idea is that you can use the example entry user interface to create a link to a nonexistent work. Said redlink will be stored in the database as a virtual article, meaning that it won't have a description or indexing information, but will register examples that are linked to it.

Any user may, at their discretion, launch a virtual work article by adding indexing tags, category tags, and a description.

Redlinking to trope articles won't be allowed, but there will be a standard article drafting interface that will replace YKTTW. The advantage of the database system is that any examples entered within the drafting interface can be instantly promoted to live upon the article's launch without requiring someone to manually crosswick them.

Edit: Music examples have a bit of complication in that they may link at multiple points: "In <song|album>, by <artist>, stuff." What's the primary linking article there? Individual songs are poor links because of lack of uniqueness in titles. Really it's the entire song-artist or song-album-artist combo that forms the linking key, and constructing an interface to understand that will be tricky.

I think that we would have to start from the artist and drill down from there, treating artist-album-song as part of a hierarchy, much like work-season-episode. No artist, no link.

edited 18th Nov '15 9:01:49 AM by Fighteer

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

Will this formatting still allow for tropes associated with a character to also be shown on the main work page?

Yes. Whether they appear by default would depend on the user's and/or article's settings. There would be a variety of views available, including "all" (everything related to the article), "main" (akin to our current standard), "YMMV" (only subjectives), "Trivia" (only trivia items), "Characters", etc.

Selecting the Characters view would present the user with whatever hierarchy has been established for the work. Taking Harry Potter as an example, one might be presented with an expandable list as such:

• Heroes
  • Main Characters
    • Harry Potter
    • Hermione Granger
    • Ron Weasley
  • Griffindor House
  • The Order of the Phoenix
  • Misc
    • The Weasley Family
• Villains
  • Slytherin House
• Neutral characters
  • The Ministry of Magic
  • Hufflepuff House
  • Ravenclaw House
  • Muggles

I just made that up off the top of my head, and the organizational structure could be argued, but that's the basic concept.

edited 18th Nov '15 11:45:27 AM by Fighteer

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

My opinion is that all tropes should be listed on the Main page in some manner, at least until one gets to the point where a list gets too long. A reader on the page might want to read over the work page for The Lord of the Rings and simply read all the tropes that appear on that work, not have to hop to the Legolas page and the Gimli page and the Aragorn page, etc etc etc. There will be other readers who will want to read all the Legolas tropes together, I guess, which would be where the Characters pages come in.

That's why there would be an "all" view available. Of course, the trope list would be subject to pagination if it's extremely long. If you want to view Legolas' tropes in one place, then you'd select the Characters view and drill down to him. There would also be a virtual landing page for each character that could be accessed directly if you know the URL. This is where you'd enter the character-specific description and image.

Again, entirely off the top of my head, it might look like https://tvtropes.org/wiki/Literature/LordOfTheRings/Characters/Legolas. You could omit the Literature path to see either Legolas' tropes across all media or a disambiguation page ("Which version of Lord Of The Rings did you mean?"). Entering anything here would cause the examples to automatically be associated with all objects up the path, so adding a trope to /Literature/LordOfTheRings/Characters/Legolas would cause that example to roll up to Literature/LordOfTheRings, as well as to any character groups of which Legolas is a member.

Each unique destination would have a permanent internal article ID, so the above could also be accessed directly (without going through the path parser) as, say, https://tvtropes.org/wiki/584676377.

edited 18th Nov '15 12:22:16 PM by Fighteer

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

~Fighteer, your posts are very dense for myself, and probably other people who don't work with databases on a regular basis. My takeaway from this is that the underlying software organizational structure is changing, and that will have pretty much net positive benefits for the readership of TV Tropes. The troper body will experience some growing pains as the new formatting will make editing completely different from how we've been editing, but the rules are not changing in any significant way.

As a side benefit to this software change, troper mistakes like general examples will be much harder, and Zero Context Example will be impossible without Word Cruft.

---

The trope changes I see:

YKTTW will become a mandatory process that may or may not still require troper consensus. The layout may change as well, but the process of submitting a trope name, description, and examples before launching to the general audience will be required for any trope page.

---

The work changes I see:

The article "pages" are gone, completely. There exists a work, and that work is described and indexed in mediums and decades. When a general reader goes to the "work page", they see the description, a list of tropes are generated from the server's database of tropes associated with that work (at the time that the page is loading on their browser), and the index at the bottom. Readers can narrow their focus on a work (from "all relationships" to "main tropes" or "character tropes" or "subjective tropes".), or even narrow their focus from one franchise (single or multimedia) to just one work in the franchise, as long as that part of the franchise has been described by a troper. (Like, if there's no page described for issue #1 of the first batman comics, a reader can't go there, but they could if there was)

---

---

I think I've got that mostly right.

edited 18th Nov '15 1:11:48 PM by crazysamaritan

Link to TRS threads in project mode here.

Your analysis is correct in all important details.

Please be aware that nothing about any of this is set in stone or has even begun implementation. The beta site is currently developing a new "look and feel" for TV Tropes, but the underlying data remain the same clunky mess as always.

Edit: As an example of a brainstorm I just had, we could build a Bayesian filter into the edit parser and feed it a list of words that typically indicate Word Cruft or insufficient context. "I", "This Troper", "basically", "actually", "and how", "justified", etc. If the filter determines that the content exceeds certain thresholds, it'll flag it for attention or flat out reject it.

The reason this can work is that edits will be submitted one example at a time, not as huge chunks of text.

edited 18th Nov '15 2:02:40 PM by Fighteer

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

I guess the ultra short definition of the "database overhaul" is:

(With the caveat that I am going to ask for a mass edit function for trope maintenance.)

And there will almost certainly be a limit on displayed page size - browsers and slow Internet cannot handle arbitrarily large pages. Which parts of an example section will display on pages hitting the size limit will need discussion.

Incidentally, whether the "Work name: Example text" will become mandatory or whether variations like "First part of the example text Work link Second part of example text" can still be done has caused some heated discussion.

"For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." - Richard Feynman

The latter would be a nightmare to code. If we're going that route, it would be better to permit the linking object to be suppressed if it's contained (and not potholed) in the description text, but that should be allowable only for trope-facing example descriptions. And I would argue strongly against it, but that's from personal preference.

edited 18th Nov '15 3:39:28 PM by Fighteer

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

I prefer seeing what work an example belongs to first anyway. It's just annoying having to scan the line to find it, even if it takes just a few tenths of a second longer.

Page images would be a fun challenge, if there's more than just one on the main page.

Check out my fanfiction!

You can still embed images within text, but the primary image would be associated with the description element. If a character has a description, it could have an image. Placement in the article and formatting would be done automatically.

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"