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

I don't think you need to change anything in this early stage. But references to things like "objects", "relational databases", and "createpage functions" are likely to go over the head of the average troper. For right now when the details are still being hammered out it's fine, but when we're getting ready to roll it out, most tropers aren't going to care about the under-the-hood details, only how it's going to affect their wiki experience and how they have to do everything differently now.

Many of those details are only interesting to people who know how that kind of stuff works in the first place. People who don't know are mostly just concerned about the interface options and how they work, i.e. actually using the site.

I'll admit, the page is more a guide for developers, a building plan. 'Cause we don't know well how it will look once built, especially the UI.

The sky is falling. Run for your lives. The end of the world is nigh. They are going to change it and then it will suck.

Yes. This is the irrational fear post.

• The change is going to suck all the humorous stuff out of trope and work examples by restricting the way in which they may be formatted.
• The new format will not allow additional sections in trope and work articles. Just a description and an example section.
• The clinical and sterile way in which new examples are to be added will suck the creativity out of the contributors and cause them to write dry, uninteresting examples.
• The strict formatting rules will completely disallow experimentation. The site will therefore never be able to grow beyond what it is. The site will then stagnate and wither.
• The new design will steal control of the site from the userbase and hand it to the moderators. Moderators will have more tools at their disposal to remove fun stuff easily and without anyone noticing.
• The audience is not going to like the new site and will abandon it.
• The new site is too complicated under the hood. The maintenance costs will skyrocket.
• The way URLs are going to be handled makes no sense and is going to explode.
• Pony images everywhere!

Disclaimer: The above, being fear induced, may be slightly inaccurate.

Coming soon. All the stuff the proposal needs but doesn't have yet. (Featuring discussion pages. Why is that forum thread even locked?)

edited 23rd Apr '16 5:42:55 AM by war877

Uh ... is that supposed to be a list of actual concerns or just some kind of hyperbolic joke?

Both. I would like to see them addressed even if some of them are unlikely to be real problems.

I suppose I should clarify. Someone is going to raise each of these concerns at some point. Would you rather prepare for them or wait until closer to launch day?

edited 23rd Apr '16 6:38:43 AM by war877

OK, in order:

• There was some heated argument last year or so between moderators about whether "Work: Text" and "Trope: Text" would become obligatory formats. I did opine that the display of "work" and "trope" could be suppressed if it was linked to elsewhere in "text" so as to give some flexibility.
• You can always propose new sections, e.g an index list or a related tropes section.
• Seems fairly hypothetical to me - all edit pages and add YKTTW pages look the same too.
• Not sure what kind of experimentation we are talking about here...
• Something I've got concerns about as well, but it isn't that more - most of the functions that are new can be used by everybody or if no are based on already restricted functions. I am open to specific functions being expanded - I've already done so for "delist"/"relist".
• The overhaul is a functionality one, appearance will need its own concept.
• Possibly a legit question; then again the current site is also a maintenance issue.
• I agree with the functional URL being waaaay too complex.
• The "vote for image" thing has been bickered about at length and will need a resolution.

1. If you can't find a way to make example text entertaining when the linking object is displayed first, then I don't know what to tell you. Exercise those creative muscles.
2. You can still use the description area as you would now. There will also be automatically generated sections for article relationships (subtropes, child works, etc.). If you have other sections in mind, let us know what they are so we can decide if we want to support them.
3. Yeah, okay.
4. Yeah, okay.
5. That is one of the principles, yes. And I'm only being a little sarcastic.
6. That's a risk you take whenever you change something.
7. You should see it now.
8. URL construction is a feature we're going to have to iterate on quite a bit to get right. Nothing is set in stone.
9. As Septimus said, the voting for images thing is still a matter of some debate. The question seems to be whether we would like article images to be controlled by a small group of trustworthy tropers or a democratic sample of the user base.

I would like to point out that "Trope:Text" has been standard on work pages since the start and it doesn't seem like it's ever impeded creativity.

, , Those responses are all okay. At least for now, as my brain is sleep deprived.

Here's my idea for the threads and conversations:

One system for all of them as suggested by others.

But I like how some threads, the ask the tropers style threads, are several threads in one page, and others are one long conversation. I would like to marry the two. On a standard forum 'area', there will be a list of threads by name at the top, and a list of ATT style threads below. The ones at the top have more than 25 posts, the ones below have 25 or less.

With this system, the forum can be married with the conversations easily. Each thread will be associated with a work, or a trope. With a few forum exclusive threads (like all of the RPG subforum).

On each trope/work page, there will be a tab which says conversations. If you are logged in, a number next to it will indicate how many conversations have been updated since you last looked. If clicked, you will go to a forum 'area' specifically generated for that trope/work.

The forum 'area' will not just include threads for that trope/work, but threads for all parent and child trope/works. If the work has a franchise or a series, that is a parent. If the work has episodes, those are children. If a trope has a supertrope, index, or subtrope, those are parent, parent, and child respectively.

All the above threads should also appear at at least one point in the forum as well. Perhaps in select forum 'areas' like the one for western animation (which would have all western animation works as children).

Every type of thread would go like this. TRS threads, image pickin', general discussion, they would all be associated with a work or trope, and automatically get placed on several 'areas' accordingly.

This will hopefully increase the visibility of new threads, which tend to suffer a bit from inattention from what I've seen, and allow small issues to be dealt with cleanly in ATT style. Similarly, any thread that becomes long is well organised under this system.

I think people will be able to skim many threads faster this way. The new thread 'areas' would completely replace the neglected conversations.

Edit reason: spelling/grammar.

edited 23rd Apr '16 10:45:14 PM by war877

Again, thank you for entertaining my silly fears. Having had time to think about your responses, I have follow ups on some of them:

I have two cents on the vote for image thing: Automatic voting is always subject to abuse. I am predicting that going that route will cause more problems than it cures:

A hundred people come on the site and vote up loads and loads of pony images. You fix the images and lock them. Now what? Can you unlock them? Do you have to wait for a hundred other people to even out the vote, or can you clear the vote? When are you allowed to clear the vote? Are you allowed to simply invalidate some of the votes?

I am glad someone is thinking about the URL thing. In its current form, I think that it is too experimental. This means it is not likely, but rather certain that it will develop complications. I like the idea of integrating a search function into URL lookup, but think it will explode.

#1, #3, #4, #5 Thank you for confirming my worst fears, fighteer. I am now going to worry about this project right through launch day. This is actually why I think #6 is going to happen. (And I am actually totally serious.)

I am completely satisfed that additional article sections will be supported. The structure of a page can be quite complex. I assume you have it in mind to support multiple example lists on a single page if needed? And also text sections after example lists? And also custom lists of things other than examples?

Edit: To clarify concern #4: Free form page structure is inherently flexible. Database controlled page structure is inherently rigid. I have no idea what ideas the future tropers may have to do something creative, but whatever it is they may come up with, it may be possible in the old system and impossible in the new system due to inherent structural limitations in how a page may look.

edited 25th Apr '16 2:52:10 AM by war877

Speaking as someone who's been active in Image Pickin' for years now, the idea of making sweeping changes to how pics are chosen for pages is rather disturbing, and if it's really left to some kind of voting system that's open to the public at large, I can't see it doing anything but putting us back in the quagmire we had years ago when the wiki was flooded with pics that were any combination of bad quality, JAFAAC, copyrighted, spoilery, or riding the ragged edge of NSFW, if not all the way over. IP's been one of the most productive and, IMO, successful functions of the entire wiki, and I'd like to see it stay that way. The system's not perfect by any means, and we can always use more participants, but I don't think moving away from how it functions now is going to be a net positive for the wiki in the long run.

edited 25th Apr '16 5:20:02 AM by Willbyr

I agree completely. But that is probably a problem for a later day. That suggested change is like a year or more off, right?

As long as the change gets a dedicated discussion thread before being put into effect, I can keep quiet until then.

Just add folder nesting, please.

That's the only thing I want.

The design proposal will permit collapsible/expandable lists based on nesting levels of indentation, but folders as markup elements that are inserted into example lists will be obsolete. Example sorting and grouping will be handled by the renderer based on metadata. You could still use folder markup in descriptions, I suppose.

edited 25th Apr '16 11:04:45 AM by Fighteer

I'm with Willbyr. IP is the only "work" part of the forums that actually gets stuff done consistently and quickly, and is fine as-is.

Well, I seem to be definitively outvoted on allowing global voting for images. I still think we can use some sort of "likes" system in general for images, quotes, and "moments" areas in 2.0, but the selection of article images and quotes will probably remain with the current loose committee system that we've formed in Image Pickin'.

edited 26th Apr '16 6:48:27 AM by Fighteer

I've removed the vote thing from the core concept and put it in "questions" instead. Far too much opposition to have it in the core concept.

(Copied from other thread because it's here in the right place.)

Excuse me, but this doesn't make sense to me:

"The idea is that it will be possible to specify alternative example text for the work and the trope articles, but it will be optional."

But what is this good for? We are e.g. removing Zero Context Examples from the wiki. At the moment, you have to check both on trope pages and work pages. In 2.0, you'd have to check every example just once, because (I thought first) it'd be the same, since it's stored in the database, and the page is generated.

But with alternative texts possible - doesn't that mean we'd still have the problem that we have to check every example twice?

This question was addressed on page 2 or 3 of the thread, but I'll answer again here. The management of trope-facing vs. work-facing description text for examples will be somewhat tricky. I envision something like the following:

• Examples will be created (by default) with a single description element applying to both trope and work articles.
• There will be an "add alternate description" control available to editors that will let you add alternative text for specific faces of the example.
• Examples that have such alternative text will display a control to view and/or edit them.

Note that a certain minimum length of description text will be enforced by the editor, such that you can't get away with an obvious ZCE. I also had the idea of applying a probability filter to analyze descriptions for the ratio of Word Cruft to indicate a lengthier ZCE.

edited 1st Jul '16 1:02:55 PM by Fighteer

This sounds somewhat tricky indeed.

I would prefer to aim big and then trim the infeasible ideas than to aim small and undershoot.

The idea of a word cruft text filter is interesting to me. And it would be something I would find easy to write.

That said, there is no minimum length of a sufficient context example. Some tropes have sufficient description with a zero length text on occasion. Wherever the bar is set, there is going to be perfectly valid yet exceptional example text from time to time.

A useful compromise might be to set a different sufficient context length for different tropes.

There are a few cases where the trope example is only allowed on one page currently. Most obviously in cases of partial example sectionomy, But also darth stuff seems to only be allowed in one place currently. How will this be handled?

Also, there is the thing where an example text is going to appear on multiple work pages, most obviously character pages. Will custom example text apply to all work pages or be work page specific? Also, with subtropes being a thing, it might appear on multiple trope pages as well.

A trope wihere 0 text is enough context?

Um, I think so. Probably one of the title tropes, like Tyop on the Cover or Names The Same or Alliterative Name.

Nevermind.