StrategyWiki:Staff lounge

__NEWSECTIONLINK__

Welcome to all users! This page is where people can ask StrategyWiki-related questions to the staff and senior community figures, and they will do their best to answer. If you want to raise a topic for discussion (rather than just ask about it), please use community issues instead. New issues are entered here, with the most recent at the bottom of the page. If your question does not pertain to editing StrategyWiki (i.e. asking for hints or game-specific information), please ask on the guide's talk page or on the forums.

Please review the Table of Contents to see if your issue has already been raised; also check the archives (to the right) in case it was discussed some time ago.

To facilitate ease of browsing and replying, please:
 * 1) Place your question at the bottom of the list
 * 2) Title the question (by placing the title between equals signs: ==title==)
 * 3) Sign your name and date (by adding two hyphens and four tildes: --~ )

MultipleUpload
The author has fixed the file overwriting bug in his extension, so are we ready to use this again? — najzere T 15:26, 1 July 2009 (UTC)

Subtoc Content Headers
Mock version of my idea in the works on my sandbox.
 * What I would like to do
 * 1) Choose an arbitrary number (i.e. four rows of content) to establish the point at which guide ToC's should require modular summarization (this applies to large guides like MMORPGs).
 * 2) Create a standard set of templates and a usage policy for using and implementing modular, summarized sections of ToCs.
 * 3) Implement this on MapleStory/Table of Contents.


 * A summary of related thoughts
 * 1) Many individual MapleStory pages are exceeding the "warning" limit; in some cases by 3x or more (over 100KB).
 * 2) The MapleStory guide is our primary traffic generator for the website, so it should be used to set the precedent.
 * 3) The MapleStory Table of Contents has the capacity to be expanded more efficiently to better organize topics.
 * 4) Recent edits made by suggest that we should break down certain page headers into more accessible, expanded topics (he focused on Party Quests).
 * 5) I want to use Subtoc-like templates to minimize the default ToC size, and allow us to expand topics without worrying about spacing issues.
 * 6) We have never used Subtoc for a topic (i.e. for a column header); only expansions that act like H1 headers.


 * Why I posted it here
 * 1) Our community meetings are where we get things done, and that is a rare event that I have trouble attending.
 * 2) We used to decide things on the Community Portal talk page, but no longer use that page.
 * 3) Our forums are rarely patrolled or concluded upon because they are separate from the wiki, and I know all of the admins have this on their watch page.
 * 4) We can use this space to better organize our thoughts using templates if need be.

-- 06:50, 21 July 2009 (UTC)
 * I've always thought we could improve our organization a lot by including some helpful JavaScript, but the problem has always been that not everyone has it turned on. Recently I've been trying to find some figures on how many people really surf with JS turned off, but apparently it's not the most reliable thing to track. Most numbers I've seen haven't been any higher than 5%, which seems pretty small to me. Although I wouldn't want to make anything inaccessible to non-JS users, I don't want 95% of viewers to suffer for them either.


 * The workaround on other wikis is to switch display of collapsible elements to none with JS so that it will just be fully expanded for non-JS viewers. This wasn't necessary in the Header Nav so far, because there was a link to the ToC if someone couldn't get at it with JS. However, by putting hidden content in the ToC itself, even a link isn't going to be helpful. Someone with JS off will have to edit the page to get at a guidepage link, or use the PrefixIndex. The problem with collapsing the elements on page load, is that with slower browsers you're still going to see that huge list at the beginning and you'll have to wait for it to "shrink back up". It's just kind of ugly watching pages adjust themselves while you wait.


 * Personally, I'm in favor of using more JavaScript, since I feel like most people use it and if they don't, they can always turn it on for our site. If it doesn't interfere too much with certain bots and RSS (if we even have one), would it be too annoying for something server-side to send viewers to a splash page letting them know we use JS elements and how to turn it on in the major browsers? That would help people that have turned it off in the past on someone's advice, but don't know how to turn it back on. On the other hand, would it be too difficult to maintain and load a separate non-JS table of contents for those people? Lastly, if collapsible/expandable elements do get used in the ToC, I suggest we modify the look a bit to differentiate between actual subtocs and normal content expansions. — najzere T 15:10, 21 July 2009 (UTC)


 * I'm all for supporting this. I'm not sure of the best possible implementation, but almost anything could be helpful.-- 20:12, 21 July 2009 (UTC)
 * We have been stymied by visual limitations every time we begin to add "too much" content. I disagree with Najzere in that I don't believe JS is an issue for readers. Those who disable JS know how to enable it, and will be aware of how websites look. We wouldn't be the first website to have content that requires JS interpretation. I used to disable JS so I wouldn't have to see advertisements - when you do this, it changes all websites significantly. -- 00:23, 22 July 2009 (UTC)