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

Alliterative Name still has to say the name in the example, unless it's attached to a character by context, and we have specific handling rules in mind for those.

Any given article can be set to block reciprocal examples from displaying, but in the case of Sugar Wiki and Darth Wiki articles, that would be inherited from the SW and DW templates. It's worth noting that the link would still exist in data, so there's no inherent reason why one could not request SW or DW views of a work article, seeing all the examples listed therein. What we would do is suppress them in the default article view.

I was under the impression that most of the subpages would be outmoded by the new system, with recap and character pages being more the exception than the rule.

Darth and Sugar, for example would be replaced with a darth and sugar filter on the trope list, off by default.

Exception would have to be made for works that belong on darth, sugar, and both.

Darth Wiki as a repository for unpublished works is a kludge that can and will be discarded when work articles no longer have to deal with title collisions. "Unpublished" will simply be a tag on the article that will affect how it's presented. For example, we'd probably suppress it on indexes and crosswicks.

What sort of works get placed on Sugar Wiki, out of curiosity? I'm not aware of any.

edited 2nd Jul '16 6:10:07 AM by Fighteer

Some joke work pages are placed on Sugar. And yes, 2.0 has something about unpublished works, or should have.

Those "joke" work pages would seem to fall into the same basic category as Unpublished Works: works that don't actually exist and therefore would not be visibly linked to from the main wiki.

I wasn't just talking about unpublished works. There are other things that belong on darth. The darth tropes, obviously, but also the odd special work page. Eversion.

That's on the main wiki, unless I'm missing something very badly.

Hmm, Eversion Eversion. Try now.

Unless I'm badly mistaken, that's just people goofing around. Such things would be broadly tagged as Just for Fun in the new system and we'd have to explore the exact ramifications of doing so. Seriously, though, I am not saddened by the thought of casting off some cruft, or at least storing it away in attached subpages where it doesn't confuse people as to its purpose.

edited 3rd Jul '16 6:15:23 AM by Fighteer

Hmm... Consider the preservation of darth styling and sugar styling on these two pages and the small handful of similar work pages on my personal wishlist for 2.0. I would categorise these pages as self demonstrating.

Self-Demonstrating falls under the Just for Fun umbrella. As I've said before, our primary focus for 2.0 will be the functioning of the core wiki systems. We intend to allow alternative description sections for articles in various categories, such as Analysis, Self-Demonstrating, and so on, but those won't have separate example lists.

Maintaining distinct example sets for a work, some of which are for goofing around, doesn't make sense from a logical perspective. I suppose we could allow JFF articles that act as normal articles in terms of how you view and edit them, but don't crosswick. Functionality-wise, they'd act much like Unpublished Works.

edited 6th Jul '16 7:08:06 AM by Fighteer

I may have forgotten details, but currently I believe there to be room in the specification for easy accommodation for this kind of just for fun page.

First, tropes are likely to appear not just on two, but a bunch of pages, based on a complicated tagging system. This was discussed in greatest detail concerning characters that appear in multiple works, and the discussion of character ensemble pages and episode recap pages. Allowing similar tagging of examples as darth or sugar would be possible without adding any new functionality to the design.

Currently, I am under the impression that example sections will be "smart". Allowing various categories of tropes to be filtered out. One could design a user interface with tabs as a list of categories for accessing this table: standard, character, ymmv, trivia, darth, sugar, all. As but one example. Instead they could be checkboxes to select or deselect.

This second categorisation is based on trope type, not a tag associated the example. Of course editors are always going to have the occasional need to override the tag in some cases. The two systems are sort of tangled together. For example a trope may sometimes be considered a character trope if it is tagged with a character and sometimes not.

Regardless, the smart table operating behind the scenes could easily generate a custom view of the trope list, one that filters out the tropes for a work based on the presence of a darth tag, the same way as will work if a person looks at the characters page for a specific work and character.

Secondly, the idea of a custom view for an example still has the possibility of supporting much more than just views for trope side and work side example writeups. One possibility is to associate a custom view with each tag associated with the example. Tags would automatically include the trope and work in question, but may also include the character, the episode, and an artificial tag such as darth. Each page would have a primary tag associated with it. A trope page with the eponymous trope tag, a character page for a work would have a list of example sections, each one primarily associated with a specific character tag. The primary tag determining which custom view of the example gets displayed.

If this were done, then not only could the "darth" page get a custom trope example list, it would have darthy theemed writeups of all those tropes.

If the special page styling of sugar and darth were reduced to a page type flag instead of being determined by namespace, the darthy theming can be preserved for this pair of self demonstrating pages no matter where they end up recategorised.

In total, the amount of work required to adapt the current design to cover special consideration for just for fun pages is zero, depending on how the tags and custom example writeups are implemented.

I think you underestimate the amount of work involved in supporting alternative "fun" versions of example lists for works and characters. While fun is certainly something we want to encourage, the interface design for such a project would be cumbersome, as would the amount of work needed to maintain examples within it, all for extremely dubious payoff.

I would rather set up JFF versions of work articles as entirely distinct from their parents. It has the advantage of being much simpler to develop and maintain, and doesn't implicitly encourage users to create them.

That said, the design space for multi-language support need not be limited to actual translations, but could be adapted for something like what you suggest.

edited 7th Jul '16 12:33:25 PM by Fighteer

I pinned and renamed the topic to be clearer as to what it's about. There is no change to the development status.

A little follow up: Apparently the admins are still looking for another developer and thinking on how to tackle this megaproject.

I was under the impression that a european developer studio had been signed already? Is the site looking to recruit their own team?

... I'm surprised that this thread at 13 pages and counting doesn't have a header post summarizing the current status of the discussion/development yet.

Have they posted a job opportunity somewhere I could look at it?

@Dawn Paladin, we haven't listed any positions, but I believe that we are preparing to hire another developer soon. If you send a resume to tom@proper.io I'll take a look at it. Thanks!

@Dev Tom I will be occupied by my studies at Viking Code School until March, but when I graduate I would be very interested in joining the team! I'll reach out to you when I'm ready.

• bump* Something new?

It'd be really cool to learn what you are doing. The kickstarter project was several years ago after all.

Right now we are currently working on a major revision to the site's design, with tons of bugfixes. 2.0 will be on the horizon after that.

Oh, this is going to be interesting. Really looking forward to testing this out.