Forum:Namespaces?
Yes, it's hard to decide how to do namespaces better, and it's easy to end up with a mess where media categories, tropes and works don't have a fixed hierarchy and appear to be in random order, much like on TVT.
But it's worse without them, because unless everything is written very clear, it's impossible to tell what is what from links, and it may or may not be obvious even halfway through the article: is it self-demonstrating, starting with an example, and other in media res - or is it a work? And then, there are common terms with several possible uses.
Consider this:
> (Move log); 07:42 . . Vorticity (Talk | contribs) moved page Space (Music) to Space
Does anyone else see the incoming headaches?
TBeholder (talk) 05:19, 25 March 2014 (UTC)
- Heh. We hashed over this issue pretty extensively already. Space, I admit, is one of the more questionable ones, here -- at some point, it will probably be moved to a science fiction trope. Still, there was a lot going into this:
- We wanted to get closer to Wikipedia's names, so that the majority of the Wikipedia links would work without adjustments. There are certain cases where it will only get you close, but still only a click away. (No, we are not becoming wikipedia ... we are providing a link to go there if you want to see encyclopedic information. It's like outsourcing.)
- The namespaces where essentially arbitrary anyway. And you'd have to remember which was which, anyway.
- If a work had multiple adaptations, you'd have to know that if an anime was Anime First, started as a manga, or started as a light novel when making a link. Or was was it a Miyazaki anime over in the Film namespace? That sort of mess discourages casual editing, and possibly even casual browsing.
- Most of what the namespaces were separating are handled by mediawiki categories.
- You seem to be in the habit of checking the URL to find out what something is. But we have newer, better ways of doing it.
- How can you tell if something is a trope or work, even if it's potholed? Well, you can't on TVT without highlighting the link and reading the URL. But here? You can just turn on one of the two Trope Highlighting gadgets. Links to Tropes and YMMV tropes appear to be a different color.
- Want more info? Turn on the Navigation Popups gadget. A small preview of the page gives you an idea of its content.
- Note: this Navigation Popups isn't actually working right now, but it's pretty slick on Wikipedia. Getting it to work on Mediawiki 1.22.3 is a priority for us.
- I'm tempted to make it read Laconic instead, but those are often pretty bad...
- Namespaces make for more work when editing. Of course, some of that can be negated by the Auto Complete gadget -- but the more namespaces, the more cluttered that gets. Requiring namespaces for everything makes for worse Huffman coding.
So, that was my thinking going into this. But you're seeing some headaches emerging from the idea of getting rid of namespaces.
But it's worse without them, because unless everything is written very clear, it's impossible to tell what is what from links,
- Unless you're using gadgets...
and it may or may not be obvious even halfway through the article: is it self-demonstrating, starting with an example, and other in media res - or is it a work?
- So how exactly do namespaces solve bad writing? I mean, those are pretty much problem pages anyway IMO. If we haven't gotten into "Topic is a X" territory by the second paragraph... ugh. It might be possible to modify the {{trope}} template to put a note that something is a trope in the title bar -- would that be useful? I suppose I could do something similar with major work namespaces.
And then, there are common terms with several possible uses.
- I don't see how renames are going to effect confusion between similar terms, one way or the other. We're either going to need misambiguation pages, notes at the top of the page, and/or some separate namespaces on those anyway.
It's not that namespaces were a bad idea on TVT, given that they're using Pmwiki. But the wiki we use has a different software paradigm, and generally expects to be used more like wikipedia does. And they have pages on the majority of our works, too.
To be honest, you're not going to convince me to change it back, because I've invested >100 man hours into getting rid of the namespace suffixes. But if there are specific headaches that I'd be able to mitigate with software, then let me know, and I'll try to think of a way to address them.
Vorticity (talk) 06:14, 25 March 2014 (UTC)
Namespaces make for more work when editing. Of course, some of that can be negated by the Auto Complete gadget -- but the more namespaces, the more cluttered that gets.
... I don't see how renames are going to effect confusion between similar terms, one way or the other.
- Same as with coding: if errors are immediately obvious, it saves time even if you have to type slightly more. Namespaces make certain sorts of problems quite unlikely to appear in the first place: it's either an existing type in plain text or it's a red link.
- Example: there's "Death_Star". If an editor had to use "Novels/Death_Star" while writing each of 112 links, would this be too much work to do? I'm reasonably sure they weren't written all at once, either. Now, want to bet how many times you will have to fix links using "[[Death Star]]" alone as a trope because someone guessed from context and didn't bother to check, or just mixed up names?
- ...and since many, many tropes are named after works and things in works, and both use common words a lot, and easy to mix up, such confusion is going to be all-pervasive.
- Autocomplete is the root of many and ugly evils. :) "More work" by copypasting 1 short word is not.
- Lack of namespaces means every link strongly relies on the context. Which makes links on pages that don't give context at all almost useless - and this includes everything from "one word obvious trope" junk to big technical pages, especially search, including "What links here": unless an user already remembers what each name is, links have to be checked one by one to find anything particular. Namespaces instantly filter out lots of misses here, and for works referring to other works they may well narrow hundreds of found results down to 1-2 wanted right away, without checking every single one.
So how exactly do namespaces solve bad writing?
- Nothing solves bad writing, ever - or "fanfic" could not be used as an indecent word. ;) But a good site structure (whether via URL or tags) may have the inevitable problems contained and thus make them matter less. A reader searches for a trope page, and it's a work page - next, please! No need to dig through. Thus, less users are affected by this problem, and less problems affect a specific user. Also, this applies not only to bad writing as such - just as styles clarifying everything from the start aren't necessarily all good. Some ambiguous lines may be acceptable if a reader can determine whether it's most likely the right place before digging in.
It's not that namespaces were a bad idea on TVT, given that they're using Pmwiki. But the wiki we use has a different software paradigm, and generally expects to be used more like wikipedia does.
- The thing is, trope-wiki most likely will not, or even can not be used the same way. While wikipedia does provide easy reference to the One True Notion on anything that is Notable (in the One True...), beyond "surface" entries it can afford to make just about every common word a disambiguation page and still camelword-link to them. :) Trope-wiki by its very nature relies on internal cross-references all the time.
- The implementation of namespaces is another matter. Not that TVT version was too good or too bad, just convenient enough to support structurization needs on basic level. "Name_(Media)" format is obviously less convenient, but still much better than nothing.
- In fact, optimization on the "choose wiki engine" level is a joke. Any wiki or similar engine is inherently suboptimal for troping purpose due to the nature of content: its own structure being tables of entries - mostly (trope, work) - forcing it into linear text form is both prone to leaving pages too long for editing, and necessarily makes almost every entry duplicated to appear on both (trope) and (work) sides.
To be honest, you're not going to convince me to change it back, because I've invested >100 man hours into getting rid of the namespace suffixes.
- "People should think, machine should work".(c) ;)
TBeholder (talk) 07:45, 25 March 2014 (UTC)
Same as with coding: if errors are immediately obvious, it saves time even if you have to type slightly more.
I agree with this sentiment, but writing is not the same thing as coding. (Although there are some very good arguments that they are quite similar.) When you make a mistake in coding, consequences can range from incorrect results to compiler errors to inadvertent features. But the first result is typically very bad. In the context of an incorrect wiki link going to not quite the right page... well, the user will get to read a slightly different page.
I don't think worrying about linking errors is as important of a goal as is natural writing. Most of our users are non-technical, or should be, so I want to follow the principle of least surprise. One of those surprises includes typing in the name of a work in the URL bar and having nothing come up. That's what red text means.
...and since many, many tropes are named after works and things in works, and both use common words a lot, and easy to mix up, such confusion is going to be all-pervasive.
Cool story bro, but I think I need evidence on that one. As if such things weren't confusing already, and wouldn't continue to be confusing under any naming scenario. In an ideal world everyone will be able to classify things correctly and not complain about it, but I'm simply shooting for controlled chaos. Making most of the people happy most of the time is the goal.
Keep in mind that namespaces aren't going away where there is ambiguity. They're just unnecessary where there is none. And I don't feel like paying the penalty on every link is necessary for the relatively few cases where there is ambiguity. After all, if ambiguity is introduced later, we can always apply a bot to the links later on.
necessarily makes almost every entry duplicated to appear on both (trope) and (work) sides.
Sadly, I'm not in the mood to write *that* software monstrosity. Besides, I think natural language doesn't lend itself to that kind of double-linkage.
Nothing solves bad writing, ever - or "fanfic" could not be used as an indecent word.
I'm still waiting for someone to tell me how bad my own fanfic is. I've had a few good reviews but I don't believe them.
Autocomplete is the root of many and ugly evils. :) "More work" by copypasting 1 short word is not. <snip> "People should think, machine should work".(c) ;)
Heh, nice contradiction. I think I'm going to like you, TBeholder.
Vorticity (talk) 03:42, 26 March 2014 (UTC)