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

True enough. Experimenting is a form of risk management (as one's essentially seeing what works and what doesn't).

edited 21st Nov '15 9:12:12 AM by KarjamP

Under the hypothetical new system, would it still be possible to collapse trope examples into folders for very large pages, such as the alphabetical folders that are currently standard for large pages? That is very much a usability thing for me; I don't want to have to manually scroll through 100+ trope entries looking for one or two.

Rocks fall, everyone miraculously survives.

I imagine we'd be able to support a wide variety of pagination options, including collapsing entries into expandable folders.

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

Some nitpicky questions:

What about the (admittedly rare) tropes like Deader Than Disco, which are divided into mediums, yet the examples can be about entire trends or genres rather than individual works?

Similarly, can the "no zero content examples" rule be turned off for the (few) tropes where the title itself is enough of an example, such as Long Title or Lucky Charms Title?

How much customizability will be possible regarding a page's look? Will it be possible to change the "X contains the following tropes" to something witty, as many work pages do? To change the medium names, like on Shaped Like Itself? Or to include stingers, such as these at the end of Literature.If On A Winters Night A Traveler or Paranoia Fuel?

edited 23rd Nov '15 6:06:22 AM by Korodzik

Lucky Charms Title seems to vary in context requirements. I would imagine that the general solution is for the coding of those tropes to have 0 characters fulfil the minimum text requirements. That means examples like Hunter × Hunter may get entered without sufficient context, but it is probably a small price to pay.

Link to TRS threads in project mode here.

• Deader Than Disco is a very dodgy trope to begin with. As to the specific question, we intend to preserve the option to add examples not linked to a specific wiki object, but restrict its availability to specific media categories and/or articles.
• I see no reason why we could not set trope-specific context requirements. However, the request to disable context requirements for any given trope would have to be vetted by a moderator.
• Article formatting:
  • The option to customize the example list header is something we can consider.
  • I would prefer not to change the medium category names. Adding an article-specific override for Just for Fun and Self-Demonstrating pages is a "would be cool to have" option that almost certainly won't make the initial feature list.
    • Related: Something we'll have to consider is the issue of tropes that are already medium-specific, so that their examples get categorized by genre. This will require some flexibility in the category coding.
  • Stingers are already in the proposal document. We intend for articles to have quote, image, caption, description, examples, and stinger elements, at a minimum.
  • The layout of articles in terms of style elements, headers, and the like, will be fixed.

Existing Just for Fun and Self-Demonstrating articles will probably be the most challenging to convert to the new design because of their non-standard formatting. It is possible that we won't bother to try and will let users recreate them manually.

edited 23rd Nov '15 7:06:22 AM by Fighteer

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

Just for Fun and Self-Demonstrating articles can simply be transferred over as "description only" type of pages. Quotes, stingers and the like can still be converted.

Also, it's not a given that images will be their own elements instead of markup functions.

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

"Fighteer has proposed that the system should automatically generate a proposal list for each input box."

Like in Wikipedia when you link to a wiki page, essentially.

"The admins are in the process of hiring programming staff to work on the new ideas"

Oh. And here I had thought that the admins wanted to do that by themselves.

"Also, it's not a given that images will be their own elements instead of markup functions."

What does that mean?

Get rid of the walled garden

• I haven't used Wikipedia extensively, but I had in mind something akin to how Facebook will auto-suggest links to pages or people that you've liked, as you type them.

• It had always been the plan to hire programmers to work on the site's overhaul.

• Images will still be able to be added inline, using markup.

edited 23rd Nov '15 9:45:00 AM by Fighteer

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

Images currently are not their own type of page, they are merely a markup that calls up the image.

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

OK, thanks for the answers.

Get rid of the walled garden

To clarify a bit more on the images thing, it is part of the proposal that I submitted that images will be independent data objects that may be associated with articles. Article-image groups will have associated voting elements, allowing users to indicate their favorites. The top-voted image for any particular article will be shown as the page image. Moderators will be able to lock an image to an article or prevent any image from being shown, if necessary. There will be a flagging component so that "bad" images can be called to a moderator's attention.

If you recall, we discussed that individual Character objects would be able to have associated article elements; this includes image links, so you can store and vote up your favorite image for each character, which would be rendered when you view that character individually or as part of the Characters view of a work article.

Individual images may be embedded as inline links, as always.

To clarify, the procedure will be:

1. Upload an image via the media uploader.
2. Link the image to the article via the Image Links interface (final name TBD), or directly associate it via the image uploader (my preference, as it saves a step).
3. Vote up your favorite image, which will be shown in the article header.

• [Optional]: Ask a moderator to lock the article's image.

edited 23rd Nov '15 11:34:43 AM by Fighteer

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

Worth noting that voting has attracted quite a bit of opposition in the internal discussions, as it tends to garner fan myopia.

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

Yes, but we already vote on images in Image Pickin' topics. It is my hope that the voting system, combined with an embedded comment thread, will replace that subforum.

A major complaint of editors is that important decisions are made on the forums, hidden away from the wiki proper. Putting the voting and discussion components within the articles should erase that problem. If it becomes unmanageable, we will have locking tools available, and can always go back to Image Pickin'.

edited 23rd Nov '15 11:44:41 AM by Fighteer

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

Wow. No, we cannot have a bunch of anonymous voting replace the forum. This will lead to lots of Fan Myopia and we have had that problem since forever.

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

This is the discussion we need to have. I find it troubling that we are declaring our inability to trust the troper body to make good decisions.

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

Through a vote? Image Pickin' discussions are a much better way to go about it and they work fairly well.

The issue of a forum/wiki separation is a real one but it's very different from image quality. It needs a general discussion not limited to Image Pickin'. I've in the private discussions recommended to connect forum threads to the wiki pages by default, perhaps partially merge them with discussion pages - the exact format still needs to be worked out, together.

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

That's why each images section would have an embedded comment thread, and all image-comment threads would be visible from a single interface, ideally hooked to the forums, together with their associated votes. That way the whole thing is integrated and accessible from both sides.

Edit: A crucial reason for having images be a separate data structure is that it makes it trivially easy to create a view to examine article image changes, so we can detect any shenanigans — as opposed to now, which depends on somebody happening upon a change and reporting it.

edited 23rd Nov '15 12:02:13 PM by Fighteer

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

Crowners are optional in the forum, though. They are not good methods in all circumstances. And a singular open comment thread is not well suited for decision making which is what IP was invented for at first.

I am thinking over a way to operate Image Pickin' in the new system but a lot is a function of how images will work. There are pros and cons to both "images as elements" and "images as markup" (the current system).

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

Third party's thoughts: To me, one of the apparent differences between the current Image Pickin' system and Fighteer's proposed replacement is that former is moderated just like any other normal discussions. In other words, while we are indeed voting for a new image, the mere fact that we're doing so via discussions mean that the moderators ultimately has control over what gets to be the page image and what doesn't.

The only other apparent difference I can think of at this time is the fact that with Fighter's proposed replacement, the image with the most votes automatically gets to be be the page image, potentially allowing images that are even better than the one on a page to automatically replace it. As Septimus Heap pointed out, however, allowing images with the highest votes to automatically be the page image can be a double-edged sword at times, especially if Fan Myopia's involved. That problem can be solved simply by the involvement of moderators and a tool to report problematic images.

edited 23rd Nov '15 12:39:44 PM by KarjamP

As long as there's a function to lock images, both general voting with automatic image switching based on votes, and problem-solving IP threads can work together. The first can be default, and if that produces images that aren't good, those problems can be solved.

At any rate, I think the highest voted image is less likely to be problematic compared to an image any random troper can put up without notice.

Personally, I'd want a function to block all images from particular series with crappy art, no matter public voting.

Check out my fanfiction!

Sarcasm aside, I can't imagine how to implement the latter, unless the media uploader requires the user to link to the source of the image, and I can't see that going well. Certainly, we'd want to keep the source work as an optional field, and have a separate interface that lets users identify unsourced images.

In fact, that just gave me an idea for something to add to the design document.

edited 23rd Nov '15 5:51:52 PM by Fighteer

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

I wasn't sarcastic. Half-way joking, sure. See also the last sentence of this post.

Anyway, wouldn't the media uploader be separate from whatever you use to link images to specific pages? I mean, wouldn't you have to submit an image to page after you've uploaded it if you want it to be considered for voting as the page image? Most page images are linked to the source, so if that's an attribute of the image object, which sounds like reasonable design to me, then it would work for those images with sources.

You could also do it per image, especially if you've got a more nuanced voting system with more than yes and no with no option to go back to neutral. You could have "Yes", "Neutral", "No", and "Fuck No", with the last one removing the image from your personal view regardless of voting, whereas the plain "No" option would still display it.

So from a purely technical standpoint, I don't see much trouble with it, and I certainly wouldn't mind seeing it, but I wouldn't exactly put it high on a priority list.

Check out my fanfiction!

The problem is that the "fuck no" vote on a particular source of images would only work if all of the images are sourced, and we can't make that mandatory. That said, yes, the idea is to associate the source with the image itself, not with its article-link.

Additional note for the design document: include an "images sourced" view for each work.

edited 23rd Nov '15 6:49:24 PM by Fighteer

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

Such a filter would simply not affect images without a source. It would still work for all sourced images. I mean, sure, it wouldn't work on images from a particular source that don't have that source listed as the source, but that's just because that image isn't from that source as far as the database is concerned.

Check out my fanfiction!