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

Yeah, anything with a description wouldn't be a problem, since you could just stick it in there.

I was more wondering about those tropes where the subpages have images, since subpages generally don't have descriptions, and with a dynamic page design, they wouldn't always be subpages. The easiest way would be to just scrap any non-main trope page images, but it'd be nice to have the option of keeping them for those special cases.

Check out my fanfiction!

I'm not sure if there would be a simple way to implement it. We do intend to keep an Image Links section for each article that would allow favorite images to be voted on. Within that interface, assigning images to subpage filters might be a workable option. It's definitely an extravagance, though.

edited 18th Nov '15 5:35:34 PM by Fighteer

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

It would work if all page images were also on the same tiered structure. That would mean you could automatically assign an image of an appropriate tier for the page (which would be the highest tier image that isn't higher than the page tier).

But yeah, that's extra stuff, and not vital for the wiki's function.

edited 18th Nov '15 5:52:47 PM by AnotherDuck

Check out my fanfiction!

Exciting times. Will there be a demo at some point?

There would have to be, but we're a long way from that point.

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

Interesting. Thank you for telling us.

Is this going to be the next huge project, after namespacing? Does the community have to rewrite all difficult examples by hand? At the moment, there are examples which refer to more than one work, or have no work linked at all, etc.

Get rid of the walled garden

There will be ample warning before the development of this new architecture begins or is presented to the community. The idea is that converted articles will have a list of examples that couldn't be parsed, which users can sort out.

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

One possible problem I can foresee is that many examples (at least many that I have written) group multiple related works together, usually works in the same series or by the same creator. When the context for the example is the same in each work, it doesn't make sense to write it out twice; when the context analyzes a span of several works, having to split the example up would risk making a total hash of it.

Ideally, we could handle that by defining the relationship between the works, allowing the example to roll up the hierarchy. For example, a trope could apply to Lord of the Rings as a whole, or to a specific book within the series. If you look at just that one book, you'd see only tropes that apply to it, but if you looked at the parent, you'd see tropes that apply to each of the books, plus general ones. Where this creates multiple similar entries, it would be up to the users to clarify.

edited 19th Nov '15 8:56:03 PM by Fighteer

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

I assume that one can have three work pages, one for the 'verse, one for the series and one for each installment.

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

I'm very curious about this and how it might work, though I understand you might still only be in the early stages of figuring that out. I imagine this would still require some troper consensus as a quality control mechanism (preventing things that duplicate other tropes, are People Sit On Chairs, etc.), but I'm not sure how or where that discussion would take place, or how its existence would affect the drafting process.

Also, how would things like Useful Notes and Just for Fun be affected by this?

People are willing to come up with any excuse to get what they want, hens the "ruining the fun of the wiki" complaints. After all, many hate change.

Incidentally, while you are focusing on the standard articles, you should also have plans to account for other areas of the site, such as Useful Notes (if they don't have examples), certain Just for Fun and Self-Demonstrating pages, pages that had its examples trimmed off for one reason or another (like it being an Omnipresent Trope, it being controversial, etc.) and YKTTW (a place to draft new pages for the wiki).

Comments and voting mechanisms will be part of the draft article design, yes. It will resemble the existing YKTTW structure whilst being much more robust in terms of functionality. An overhaul of that system is on the table for the current site changes, anyway.

Those sorts of articles will still exist, of course. We plan to have the ability to define certain types of articles as "description-only", not permitting examples or wicks.

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

Myself, I was thinking of having Self Demo be a subpage type. And Just For Fun a page type that does not have examples attached, but still has all other associated functions. (A "no wick" filter may be an idea if it isn't too performance intensive, but it should not be hardcoded.)

Incidentally, this discussion is being a bit more general than the thread title. Time for a thread rename?

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

If you like. I wasn't planning on having a big macro discussion until we were closer to laying down code, but it seems like something people want.

Worth adding to my previous post: it's my personal idea that article types like WMG, Headscratchers, and Fridge be converted from their current wiki-standard layout to a nested discussion layout, sort of like the current Discussion pages with an emphasis on individual items followed by collapsible comment threads.

Correspondingly, the various Moments pages would become wickless examples lists, possibly with a voting element if we want to resurrect the original purpose of the crowner system. Essentially, people would submit items and then everyone could indicate whether they agree.

And what Septimus said about self-demo pages is accurate; we envision them as alternative-text versions of regular pages. For example, we'd have an article on the character Batman, and then someone could write a self-demonstrating version of the same page and hook it to the main one. Rather than a distinct article, you could pick it as an alternative view.

edited 20th Nov '15 5:50:29 AM by Fighteer

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

We should probably have a toggle on YKTTW that would allow one to temporary set the article to "Description only", just in case they've either can't think of an example at the moment or the YKTTW draft in question is not meant to have examples.

edited 20th Nov '15 6:37:07 AM by KarjamP

That would probably be handled based on the type of page being submitted to YKTTW. You would identify whether you're working on a work, a trope, a creator, a Just for Fun article, etc.

My vision is that anyone could create a "draft" article which would be private to their user-space, and could choose to submit it for public review at their discretion. Work articles would not require a public review stage, but tropes would.

Important to note is that these would be real wiki articles using the full suite of wiki functionality, not pseudo-articles in some alternate space. However, they would be suppressed from view (including examples added through the draft interface) until published.

edited 20th Nov '15 6:35:45 AM by Fighteer

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

Changed the thread title - it is now about all 2.0 related topics, but with the caveat that AFAIK the admins aren't working on this yet.

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

I personally think Self Demos should just either go away or have a scrutinizing process similar to YKTTW/the Complete Monster thread.

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

The problem with them now is that they are treated as distinct articles that can be linked to in place of more legitimate ones. The new system would put an end to that, making their creation more of an exercise in creativity than in wiki disruption.

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

A thought popped up in my mind: How would we manipulate the data after the overhaul? How do we add tropes, change them (in case we've made a mistake) or delete them?

The way the current data structure method currently works that we have text files that essentially represent entire pages. Altering the page is as simple as altering a text document. The overhaul, in contrast, seems to make this a bit more complex.

edited 21st Nov '15 6:54:23 AM by KarjamP

Adding tropes as in adding examples? There will be an example adding form where you have to specify the work, trope and the description involved. Optionally also the character. Fighteer has proposed that the system should automatically generate a proposal list for each input box.

All examples will be editable and (if I get my wish) move-able between works and tropes. I also have requested a restricted access mass edit function for changing a number of example entries. As for deletion, regular tropers can "delist" an example (change it so that it doesn't display in the listing anymore) and moderators will be able to make a full deletion - again assuming that I get my wishes.

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

I envision the editing interface being in-line, assuming that the user has scripting enabled. You'll click on an "edit this example" control and then make your changes right there in the article. "Add another example of this trope" could also be done inline with liberal use of AJAX.

As for deletion, I agree with Septimus that it would not be a database-level removal, but because each example is a distinct data object, restoring it from history should be relatively straightforward.

I would also like to see more advanced features like "is a duplicate of" that would merge two examples.

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

I don't really know how viable it is to convert the entire wiki into the new format you guys envisioned, and this isn't counting the inevitable temporary downtime it would take to convert from the old format to the new one.

The only reason why the wiki works as it is as the moment is because it runs on a descendant of PmWiki. Even markup language of TV Tropes itself can be considered a dialect of PmWiki's. Doing as you guys proposed will require yet another major overhaul to its coding.

Good system design requires a lot of carefully thought about decisions. You can't just implement a system without thinking it thoroughly or else the system could collapse. The convenience of an idea doesn't automatically make said idea viable due to the possible risks from multiple standpoints they may bring. This is why risk management is done in the first place: to test for possible risks so that one could minimize their effect and eventually mature the system.

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

I hear a whole lot of vagueness. The admins are in the process of hiring programming staff to work on the new ideas, and if it goes as I envision, we'll run the old and new systems in parallel and do plenty of trial conversions. I'd even like to add a control to articles in the current wiki that will run a test conversion on that article, so we can debug and tweak the process.

Nothing is being rushed into. We want to do this right as badly as you want us to.

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