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

No assumptions of preference or current editor population was made. The statement described the world population experience.

Even if TV Tropes had 1,000 editors and they all had zero experience with Facebook, the world population would adjust the population of people in TV Tropes to a population where more editors were familiar with Facebook than with any coding system.

The higher the learning curve, the more difficult it is to get good editors. If we don't get new editors, the wiki will stagnant and die. So long as new good editors coming in exceeds old good editors leaving, the wiki benefits. Getting rid of old bad editors is also a benefit.

Link to TRS threads in project mode here.

Really, other than the ability to make big batch changes offline and submit them as text, there won't be much loss of functionality in the 2.0 system. And, in the new system, big batch changes will be largely unnecessary anyway.

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

Except for trope and example repair. A way to do batch edits will be necessary.

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

We've kind of talked about this already, but...

• Renames/moves will require no work for examples, because the link will be to the article ID.
• Crosswicking happens automatically, so there won't be any hunting back and forth through Related lists.
• Deleting or moving example links can all be done in one place: the trope or work article that's being updated.
• Examples can be edited as distinct entities, so there won't be any concern about record locking or edit collisions.

The only thing that can't be done automatically through this system is cleaning wicks within description text.

edited 4th Jan '16 6:34:04 AM by Fighteer

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

Wicks within text are fairly frequent. Also, if a trope/work page has all the edit and move functions on the same page (let's say by way of checkboxes), it becomes very cluttered, perhaps too short when paginated (requiring more page jumps) and possibly a target for bad mass changes.

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

That's a thing we'll have to deal with through UI design. For example, I think that articles should have "read" and "edit" modes — the read mode exposes only the filtering, reporting, and comment controls, while the edit mode shows everything. As another feature, we could have the controls only show up for examples on hover.

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

I think the idea of being able to tag individual examples as spoilers is an excellent idea and a good solution to the issues of the spoiler policy.

Would spoilered examples be completely invisible when hidden, or behind a warning bar such as this?:

[WARNING: Spoilers! Click to reveal this example.]

With warning bars, it might be a good idea to be able to add a line of context to spoilers so people can better judge whether or not a particular example is safe. For instance:

[WARNING: Spoilers for The Empire Strikes Back. Click to reveal this example.]

• Luke, I Am Your Father: Darth Vader is Luke's father.

It was also mentioned that regular spoiler text would continue to exist as well. Would this work the same as on the current site, or would there be tweaks(such as the ability to put links in spoiler text without revealing them when moused over)? This might be useful in covering Subverted Tropes, where a trope looks like it's happening only for a twist to occur.

edited 5th Jan '16 1:34:39 AM by Wyvernil

We can iterate over those ideas to see what fits best. I'm not sure that episode-tagging spoilers will be practical from a user interface standpoint. The scope of this redesign also doesn't cover any changes to existing markup, so if you would like to submit requests to change that, it should go on the beta site.

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

The "Character" subpage type will need an element for the actor portraying the character, preferably with options for live-action, voice acting, motion capture, and maybe puppetry.

For example, Obi-Wan Kenobi is currently formatted on Star Wars – Jedi Council as follows:

Master Obi-Wan "Ben" Kenobi

Portrayed by: Alec Guinness (1977-1983), Ewan McGregor (1999-2005)

Voiced by: James Arnold Taylor (The Clone Wars, Rebels)

Appears in: The Phantom Menace | Attack of the Clones | The Clone Wars | Darth Maul: Son of Dathomir | Dark Disciple | Revenge of the Sith | A New Dawn | Kanan | Rebels | A New Hope | Marvel's Star Wars | The Empire Strikes Back | Return of the Jedi | The Force Awakens^note voice only

[description]

All of these films, novels, TV shows, and comic books will, as I understand it, be linked to Obi-Wan's character subpage under the Franchise.Star Wars umbrella, but there should be a way to link Guinness, McGregor, and Taylor as well, noting that the first two are live-action actors and Taylor is a voice actor.

edited 15th Jan '16 10:26:42 AM by HeraldAlberich

One of the relationships elements that we intend to build will allow you to link creators to work and/or character articles, with a type value to indicate the nature of the link. Examples: "actor", "voice actor", "writer", "director", etc.

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

I presume that an "actor" tag may be something worth using for certain elements. An actor element though is not within the scope of an "element" - that one's only for wikipage functions.

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

Is there any consideration here for how discussion pages should work? I think this part of 2.0 has been neglected a bit.

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

I think a couple improvements we can make for Discussions should be giving each conversation a title and making sure the watchlist notifies you whenever a new response is added. This should make following them much easier.

If a tree falls in the forest and nobody remembers it, who else will you have ice cream with?

Another possibility is a colocation of wiki discussions and forum discussions on the same pages. There is a concept of this in the moderator forum.

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

Could you please give an example of how the threads would be connected? I think I know where you're going with this, but I want to be sure we're on the same page.

If a tree falls in the forest and nobody remembers it, who else will you have ice cream with?

We are brainstorming some possibilities right now. The core idea is that all "discussion" threads on a wiki article would be handled internally as forum threads, using the same coding and data structures. Any given forum thread could be linked to one or more wiki articles and classified according to type ("General Media/Trope discussion", "Repair", "Image Picking", "Project/Cleanup", etc.).

The article's "Discussion" view would act as a header for all topics linked to the article. Users wishing to start a new discussion would choose which type it is (from the list above), which would in turn automatically link the topic in the proper subforum (IP, TRS, Media [by category], etc.). The threads would, of course, link back to the article and to its discussion header.

Conversely, new and existing forum topics could be linked back to the article(s) to which they apply.

We may wish to preserve a function for simple Q&A in the article's Discussion page, but that could lead to a continuation of the cultural split between wiki and forum.

Also at issue is whether to have the Discussion header show a preview of the contents of individual threads and/or allow posting in them directly without using the forum interface.

edited 19th Jan '16 9:23:27 AM by Fighteer

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

From a GUI standpoint, I would like the first thread post to be readable from the "discussion page" and the "expand" option would move the browser to the forum-style thread page.

Link to TRS threads in project mode here.

FWIW, my concept indicates that forum/discussion location should become a tag function. Thus, a thread can be tagged to display in one, two or possibly more forums ("forum" here includes both the subforums and discussion pages) - sometimes allowing the same discussion to appear in more than one venue is good.

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

That's reasonable.

Yes, we also discussed the ability to colocate topics within the forums themselves, such as having a Trope Talk discussion also appear in TRS. This could serve for general discussions about multimedia franchises as well.

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

For three examples, Lupin III, Two Words: Added Emphasis and Appearence Tropes.

• The general discussion on Lupin would be found with the tags on each of the Lupin medium pages, as well as general Anime and multimedia forums.
• when Two Words went into TRS, under the new system the same thread would appear as a discussion for the trope discussion page and the general TRS forum. Then when Two Words: I Can't Count was created, the thread would be tagged to that, and now that the thread is marked "inactive", posting is locked and the thread shows up in " inactive TRS" forum instead of the active TRS forum.
• The Cleanup thread would show up in the appearance index, and any trope in the index, as well as the "long term/perpetual" forum.

Do I have that right?

Link to TRS threads in project mode here.

Yes. Note that this discussion page change is not necessarily dependent on 2.0, though.

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

My understanding is that everything will turn into a thread in the new forum system. That way, things like TRS, Headscratchers, WMG, Crowning Moments would all be in one place. Based on the descriptions here, it sounds like each individual thread will have metatags to allow it to appear in more than one forum (e.g. a thread with a TRS tag can be found either by searching the trope in question and finding it among the random Trope Talk or by searching all TRS threads.)

Quite honestly, the current system is a mess because there are too many different places to go to. In addition to the forums (half of which are community-based and have nothing to do with Troping^note I'm inclined to agree with many of our moderators that we would lose little by getting rid of them), you have Ask the Tropers, which is formatted differently. For a name like "Ask the Tropers," it has an awfully specific purpose, which is mostly for reporting problem Tropers. In spite of this, it should not be (but often is) used for:

• Discussions on specific examples and defining tropes that should go in a Discussion thread,
• Trope Finder and You Know That Show-type questions,
• Problematic ads that should go in the specific forum, and
• Wide-ranging policy discussions that should go in Wiki Talk.

Then you add on top of that the discussion pages, which don't work like the forums, things like YKTTW and Trope Finder, and all of those things.

That's why we can turn everything into a discussion. Although just to make things a little more complicated, maybe there should be two types of discussion. The first would be "Ask the Tropers" style things: trope discussions, TRS, policy discussions, fanboying, Headscratchers, and the like.^note I see "Headscratchers" as more like "Ask a Troper about this work," which is better than the old "Complain about this work" definition it had The second would be "submission-style" discussion where there's a body text which can be both edited and commented on. That could be for YKTTW, Crowning Moments, WMG, Sandboxes, Analysis, and such.

These threads would all have tags both for the category in which you find them and for the tropes or works for which they apply. Wide-ranging policy changes could have their own category, as could major projects or vandal reporting.

Edit: An idea came to mind! Individual threads will have individual tags just like individual trope examples, right? We already had the idea that the site would respond to new edits with given tags, so if there is already an example of a specific trope about a specific character, it will say "Hold on! We've already got an example like this. Do you want to make sure yours is not a duplicate?" My idea is simply to apply this to forum threads as well if they deal with a specific example. That way, the message would add the fact that there was a forum thread about this for you to discuss. And if there isn't an example of the type yet — but there is a forum thread — then there could well be a good reason for that, and the message will say "Hold on! We don't have an example like this, but we do have a forum thread discussing it. Check there to see if your example may not be an example after all."

I don't know how effective it would be, except the next person who adds a Spongebob Squarepants character to Complete Monster no longer has any excuse

edited 19th Jan '16 6:48:54 PM by GoldenSeals