User talk:Xenocidic/Reddhott3

One important thing to note about this page is that actually works pretty well on mobile devices that don't support the 'standard' tab system. For example from my cellphone I normally can't view anything but the first tab contents, but on this page I could view each tab's contents. --Jimmcq 20:56, 24 August 2008 (UTC)

It should also be possible to hack the headers to look like how our tabs look now, I just had a hard time finding the tiny icons. –xenocidic (talk) 20:59, 24 August 2008 (UTC)

That's good to know, since we've wanted to support mobile devices better, but I'd like to know what the original problem was that we needed to fix? If this all came about because you couldn't navlink to a tab, this is a major overhaul for a minor issue.

I'm just going to mention a few concerns off the top of my head, that need to be factored into splitting up articles into separate namespaces:

1. Search ambiguity - If you search for Reddhott, instead of getting one unambiguous article as we have now, which the wiki can promptly show you, you get multiple namespace articles that match article titles, and the searcher is forced to perform an extra step to get to the desired article. I don't like changes that increase the burden for the visitor (i.e. extra steps). We're supposed to be making the site easier to search and navigate, not harder. Also, if he picks a transcluded one, does he get the navigation to get to other tabs? Adding hacks to handle special cases to do 'x' if it's transcluded, and 'y' if it's not, means there's a problem that needed to be considered in the design.
2. Search hits - We've just increased the number of hits returned by a multiple of four or five. If you search for something that happens to show up in each tab, you now get 5 hits, instead of 1 hit. We shouldn't increase the number of search results. (Sure, you can search by NS, but the burden shouldn't be on the user to filter the results by toggling search scope.)
3. Editing across tabs - I routinely do this, and it's certainly faster than having to edit 4 times as many articles. I just had to do 31 edits for Seed Pouch -> seed pouch across two tabs, and I'm happy I didn't have to waste time doing 62 instead of 31.
4. Patrolling - The number of articles we'd have to patrol is going to shoot up. I've been here during the busy peaks, where it was barely possible to stay on top of reviewing edits, and I don't want to imagine what it would be like, if we have 3x the edits, for Standard, Just for Fun, and Pocket Paradise.
5. Namespace collisions - I've stressed this before, several times, that one of the Reorg goals is to avoid Reorg 2.0. If some new game comes out down the road, and it has JfF mode too, then we've got a bit of a problem. We need to stick with longer qualified names, instead of 3-letter acronymns, so we don't run into ambiguities in the future. And even if you call the new NS JfF2, that's a very confusing convention.

I haven't sat down and thought about this carefully, to see if there are other issues that we also need to consider. --FeralKitty (talk) 05:48, 25 August 2008 (UTC)

Hrm, some excellent points. The major problem that this solves is not forcing the editor to view the entire wikicode for 5+ articles when they just want to change one tab. It also solves the (minor) linking to tabs issue. And finally, it means that the user is not downloading content for all 5 games when he may only look at the content for one. Not sure if this would give a boost in performance or not. I'll go thru the numbered points -

1. Search ambiguity - typing "Reddhott" into the search tab would bring you to the "All" copy of Reddhott, which transcludes all copies. alternatively, it could bring you to the classic tab.
2. search hits - this is true but could be seen as a benefit, as the user may want to confine their searching to one platform and/or game.
3. editing across tabs - no solution for this. I am working at getting AWB working here so that I can do bot edits with expediency.
4. patrolling - if we install navigation popups, patrolling will a lot easier, but yes, it increases the number of pages needed to be watched.
5. this is why in Reddhott 3 the tip namespace has been disambig'd to TIPJFF:.

There's definitely good and bad to this proposal, and based on the above it may in fact introduce more problems than it solves. Again the major concern is that I don't think having newer editors viewing the entire code for all of the tabs is the best way to go. If they're not completely overwhelmed and turned off, they'll probably introduce errors in some way. Other ways to solve this are proposed here: User talk:Xenocidic#My schedule. –xenocidic (talk) 10:59, 25 August 2008 (UTC)

I wasn't aware that you had decided that it was a problem for editors to see markup for all tabs if they only want to change one tab, and again, if they only want to view one tab. Honestly, I'm not sure how we can know what editors or viewers actually wanted to do, in that regard, but I think it's confusing to introduce a second non-standard way to do things, such as via an alternate "edit this tab" link. Were you planning to consistently do this across all tabbed articles, or are you only proposing that we do species this way, and not every single tabbed article?

Based on my experience here, people are going to make all manner of mistakes with editing, independent of whether it's one tab or five. I know this, because I've had to make all manner of corrections with the Classic articles. Do five tabs require slightly more understanding? Yes. But once they learn it, it's the conventional wiki way, instead of an "you're editing a transcluded document that lives somewhere else" way. Honestly, I think people are going to be just as completely overwhelmed and turned off if they happen to edit the Main article and don't even see an Infobox or requirements. So, in that regard, it doesn't seem to eliminate the '"completely overwhelmed" and turned off' problem.

If someone does happen to make a mistake, as will happen, and put a TiP edit on the Classic tab, it's a bit more convenient for another editor to fix the Classic and update the TiP at the same time, instead of having to fix one article, then update a second article. As for viewing, I think the comparison is a plus, but maybe that's just my curiosity and I find it convenient to tab back-and-forth and see how the requirements and uses match or are different.

1. Search ambiguity = I tested that, and you're right. The Main namespace has precedence, which is a disadvantage as well as an advantage. If you know you want to find the TiP Reddhott article, you're forced to know either to do a fulltext search, or toggle off searching Main. Both are burdens which don't exist now.

As Jim likes to point out, people are more capable than I expect, and trying to "dumb down" editing isn't necessarily doing them, or the more capable editors, a service. Perhaps the simple solution would have just to have written a "How-to" guide with some illustrations, that explained that the tabbed articles now contain stacked tab sections? Then we can spare ourselves the work of revamping hundreds of articles, and they can edit one, some, or all of the tabs, in a consistent manner. --FeralKitty (talk) 12:50, 25 August 2008 (UTC)

I wasn't aware that you had decided that it was a problem for editors to see markup for all tabs if they only want to change one tab, and again, if they only want to view one tab It's something I think might be problematic, but after this discussion I think you're right in that segregating the tabs into different articles would introduce more problems than it solves (FWIW, they could stay in the mainspace but just have the prefix:).

The easiest and most painless solution is to eliminate the "NOEDITSECTION" from articles. Perhaps taking a straw poll on whether editors think it's better to see the individual section edit buttons? –xenocidic (talk) 14:29, 25 August 2008 (UTC)

Please try NOEDITSECTION in a sandbox, and see if there are any problems. --FeralKitty (talk) 14:40, 25 August 2008 (UTC)

I've reverted Mousezilla back to the non-transcluded one and removed NOEDITSECTION. I don't see any problems, the only issue is that when editing the final section of each tab, the preview will show a "</div> </div> </div>" or something like that (example). This may occur in other sections as well, like requirements. Instructing people that these will show up during section edits and not to remove them should alleviate this concern. We should also consider moving to a single template to close tabs, rather than a template and two closing div statements. This is what {{divclear}} was designed to do - so that users will recognize the tab closing code and not remove it. –xenocidic (talk) 15:12, 25 August 2008 (UTC)

You can't edit the description or Infobox. I do think that there are too many edit links.

As for the divs or whatever, to be honest with you, it doesn't matter what's there. People are going to add or remove blank lines and screw up formatting, (partially) remove html markup, and remove or edit template markup. Sometimes it got so bad, that we'd comment "-- leave this alone --" to stop us having to repeatedly fix things like left and right floats, because people didn't know what they were doing, on articles with ToCs.

The content, however, is not supposed to be a commented how-not-to guide, and I don't want to throw tons of -- don't touch this! -- in the code, whether it's {{divclear}}'d or whatever, because people will remove the {{divclear}} too. I had someone a day or two ago change {{Species-TroubleInParadise-Standard}} to {{Species-TroubleInParadise-Desert}} or something because they thought that was how you categorized it.

Instead of trying to idiot-proof the markup, which is impossible, how about writing a guide, and that way, when people do something they shouldn't have done, you can point them to (the right explanation in) your guide. --FeralKitty (talk) 15:38, 25 August 2008 (UTC)

I wonder if there's a way to let the user customize whether they see editsections or not. I know I would love to see them all the time. If they need to edit the top business, they can use edit this page. There's also an extension to add edit links to the first section. As far as the divclear, I still think it's worthwhile: it's easier to use and point to. also we're already using one template, being "clear" it makes sense to use "divclear" instead and include the /div /div code in it. We could also call it {{tab close}} to make it even more obvious what it's doing. –xenocidic (talk) 15:50, 25 August 2008 (UTC)

I hope you're not going to push and push and push, and hope to get your way, because even I don't get my way when I want something to be different :) When I disagree with Jim, and he wants something different, I back off at some point and accept his preference. I think the best answer I can give you is "not now, let's let a month go by, and see if it's very much needed." I don't want to change something merely for the sake of change, if it wasn't really necessary to change it in the first place. I need to focus on some stuff Jim asked me about, so I can't keep rehashing my arguments or having repeated debates. This is still crunch time for some projects, and there's more to do by the 2nd. --FeralKitty (talk) 16:24, 25 August 2008 (UTC)

No, I've said my piece on this and I'll wait for Jim to weigh in on it. Also, since (I think) we're shelving the discussion on transcluded subpages to segregate content, discussion regarding div/divclear aka tab/tab close should continue at Template talk:Div#Consider using this for tabbing. By the way - feel free to not respond to my thoughts right away, especially if you've got stuff to be doing. At this point, I just assume that you review all recent changes and will respond in due time. –xenocidic (talk) 16:31, 25 August 2008 (UTC)

• P.S. If this proposal gets shelved one way to allow mobile browsers to see all content would be to have them used a custom .css and turn off the headertabs for them. –xenocidic (talk) 11:01, 25 August 2008 (UTC)