| abstract
| - How can WoWWiki become more (new) user friendly? I'm talking about stuff like:
* Template changes
* MediaWiki text changes (e.g. the green talk page banner when editing)
* Main Page pointers
* Better/simpler guides for new users Any suggestions are very useful :) 15:09, 30 October 2007 (UTC) More extensive/comprehensive Help: namespace? Just a thought. --Pcj (T•C) 15:59, 30 October 2007 (UTC) Yeah, our help pages need some work. There are a lot of things we use that are hard to find out about in help. We need to document stuff in help, not here in the Village pump... ;-) --Image:Gengar orange 22x22.png Fandyllic (talk · contr) 11:30 AM PDT 30 Oct 2007 Hehe :P Generally linking directly to wikipedia's specific help pages should work (for non-wowwiki specific stuff), as they are far more comprehensive than ours; however, what we do have needs better organising. 19:02, 30 October 2007 (UTC) Uniformity in tables and templates, too. I don't know how many times I've seen several different templates used for the same purpose. --Pcj (T•C) 21:56, 30 October 2007 (UTC) 1.
* Clear page layout and headers so the user can see what recogize what type of article/namespace he/she is looking at and instantly knwos where to look for the information they need. Implement via better templates/boilerplates. 2.
* Fix all issues with the wide aray of competeing and inconsistant top and section level template "boxes" and other headers while doing the above (this includes the ToC). 3.
* Remove superfluous and ugly nav boxes and provide navigation through categories with relationship defined naming. 4.
* Move all listing/type articles to where the belong, the category namespace, with redirects when appropriate. 5.
* Add portal articles with respective namespace based on user information access patterns. 6.
* Clean up existing policy articles and refine the rules for the policy process policy. 7.
* New semantically correct main page that reflects these changes. I Think that's enough stuff that'll never be done. ;) --
*
* talk:Zeal
*
* 19:27, 30 November 2007 (UTC) Well number three isn't happening, except for category renaming. Listing articles do not belong in the category namespace, because they aren't categories. Portals would be cool. How are the article message boxes inconsistent? They were all changed to be consistent. Policy articles have had some work (thanks to Sky), but yes, probably could have more done. 19:48, 30 November 2007 (UTC) A listing/grouping of types of things isn't a category? Sure whatever you say. ;p There are still a few i've noticed that do not match the nice new ones you've made Kirkburn. They're also all competing for the same spot (along with tooltips, info boxes, tocs etc.), looks ugly and is inconsistant in how that get's resolved.. A number of them should also be split to section specific versions instead, a change i tried to champion before i left. As to policies, i meant easier to find, with clearer applicable naming, organization of them collectively, then also making being easier to understand and flow well, especially where cross over occurs between them. --
*
* talk:Zeal
*
* 19:57, 30 November 2007 (UTC) Yes, an article that lists something is not a category. A category is a specific thing for MediaWikis, and it isn't designed for carrying content - for one, they don't get flagged as articles. Redirects are also to be avoided. Article message boxes are supposed to be above all other content, and thus not conflict with anything on either side. I know there's a few things still left over, especially the band-color templates, unfortunately. Sky was asking about the names of the policy pages recently - it's a fair comment. 20:09, 30 November 2007 (UTC) I don't like MediaWiki to dictate logic, rather work around it's failings, but if you want to stick to it's limitations, so be it. --
*
* talk:Zeal
*
* 20:24, 30 November 2007 (UTC) Neither do I, but I think it would be more confusing without a recode, especially since the categories do not necessarily cover the same things as the lists. 20:55, 30 November 2007 (UTC) Steering us a bit more back on topic, let's look at Zeal's list a bit (I did a little bit of editing): 1.
* Clear page layout and headers so the user can see what recogize what type of article/namespace he/she is looking at and instantly knows where to look for the information they need. Implement via better templates/boilerplates. -Zeal 2.
* This sounds to me like we need new headers. Right now the user has to look at the tooltip or right side box to know what they're looking at. 3.
* We should also maybe put the stubs on a diet. They are consistent, but rather large and blaring. They overwhelm much informative content. 4.
* Make a list of bad templates/boilerplates and we'll discuss improving them on each of their pages and the list can have a summary status of how that's going. 5.
* Fix all issues with the wide array of competing and inconsistent top and section level template "boxes" and other headers while doing the above (this includes the ToC). -Zeal 6.
* Again, make a list of problem top and section boxes. We'll use the same review strategy as mentioned above. 7.
* Remove superfluous and ugly nav boxes and provide navigation through categories with relationship defined naming. -Zeal 8.
* Again, make a list of "superfluous and ugly" nav boxes. We'll use the same review strategy as mentioned above. 9.
* I'm not sure about using categories, though, as discussed above. Nav boxes exist to get around the limitations of categories. 10.
* Move all listing/type articles to where they belong, the category namespace, with redirects when appropriate. -Zeal 11.
* Yup, we need to aggregate listing/type articles, but maybe not the category namespace, as Kirkburn mentions above. 12.
* Once we think of how/where to aggregate them, it should be easy. 13.
* Add portal articles with respective namespace based on user information access patterns. -Zeal 14.
* Good idea, but I'm not sure how we will discover user information access patterns. Maybe Kirkburn knows or can find some better information gathering from the wiki. 15.
* Clean up existing policy articles and refine the rules for the policy process policy. -Zeal 16.
* I'll let Sky and others work on that. I don't want us to get too overloaded with policy and process though. 17.
* Some things we need to resolve in this area, though: 18.
* Fanfic, as has been discussed. 19.
* When to use subcategories vs. main categories. 20.
* What bots should and shouldn't do and how articles they interact with should be tagged. 21.
* More writing policy on things like ability pages, server pages, and user pages. 22.
* Maybe some more naming policy. 23.
* Maybe we should put a policy portal link on the sidebar. It could take the place of Search WoWWiki and that link could move down to "wiki search", since it is basically the same thing and not currently a link. 24.
* New semantically correct main page that reflects these changes. -Zeal 25.
* I'll admit I don't know what this means. So a more detailed explanation would help. Some other ideas I had: 1.
* Get the Special:Search to show simpler output options: 2.
* List of articles only that have text matches without contents matching summaries below. 3.
* List of articles with text matches to article names only. 4.
* List of articles with text matches to contents only. 5.
* Move Google search down a slot unless we get paid more for it being higher. The wiki search works pretty well now and it's results aren't based on some past scan (or shouldn't be). 6.
* To reiterate, we really need a comprehensive redo of our help pages. They really are a mess. 7.
* Make the rework part of the new projects process and do a much better job of promoting and organizing the projects. Repeatedly promoting the projects in the Village pump might be good if it doesn't get to annoying. 8.
* Archive Village pump and Warcraft pump more often. Don't archive questions that haven't been answered. Okay I'll stop now. --Image:Gengar orange 22x22.png Fandyllic (talk · contr) 12:11 PM PST 2 Dec 2007 What i meant with my last point about the main page, was that it should should reflect the following: 1.
* Portals becoming main access points for users, which means removal of the existing list of article links at the top of the page. 2.
* Top level categories listed to provide navigation entry points seperate from the more busy and limited scope portals. 3.
* A shift to ensuring sementically correct markup thoughout the wiki. Specifically that means no more tables, make use of list elements and create a float based layout for good degradation for all resolutions. 4.
* The design would also use a consistant scheme for it's varies areas (icons, colours, content styling) so they carry across to each namespace/article type and don't make the user feel they've ever stumbled off their intended path. This would ofc mean a greater tie in and consistancy with template design. (I haven't touched it in a while now, and have no idea how much it reflects to this anymore, butUser:Zeal/Sandbox/Main_Page was a pretty basic attempt at this. --
*
* talk:Zeal
*
* 23:02, 2 December 2007 (UTC) Clear page layout... Hmm? ...and headers so the user can see what recogize what type of article/namespace he/she is looking at... Headers? As in, those items which I've seen on your sandbox pages, or actual == headers? If the former, that's only adding unneccessary styling and complication to the wiki. We already have the pagename in big fat letters at the top, so this shouldn't be an issue. ...and instantly knwos where to look for the information they need. Implement via better templates/boilerplates. This is an issue of having a lot of pages on the wiki. We've been moving toward standardizing pages through the use of boilerplates, but if people aren't going to aid in boilerplating, we can't do much. I must say, mass templating won't really help either, but then, there have been efforts in this also. --Sky (talk | con | wh) 00:03, 3 December 2007 (UTC) Fix all issues with the wide aray of competeing and inconsistant top and section level template "boxes" and other headers while doing the above (this includes the ToC). Me too. I would presume you're talking about boss and instance pages more than anything. Inconsistency, I can live with, more because the items can be used to identify what kind of page one is looking at. But when there's more than one box at the top of a page, that just doesn't work. As for the ToC, we've been moving away from the use of tocright (which, imo, is the main culprit) when the page already has at least one box on the right, but there are lingering pages that need it removed. Though, I would request clarification on that statement, incase I misinterpreted. --Sky (talk | con | wh) 00:08, 3 December 2007 (UTC) Fanfic, as has been discussed. Discussing. ;) [The help pages] really are a mess. You mean, a non-existant mess? ;P. Maybe some more naming policy. Specify. Move Google search down. Agreed. When to use subcategories vs. main categories. Subcategories are always preferred over main categories, as subcats link to the main categories anyway; what exactly are you referencing? What bots should and shouldn't do and how articles they interact with should be tagged. Foxbot = love (well, sorta. I have my issues with it, but they can't be fixed). Laurlybot = hate. The subpages, are, quite frankly, unneeded, as the pages will be re-updated by bot again; Laurly's said it's possible to code for the bot to change the main page parts that need changing as opposed to the subpage, and overwriting the tables is going to happen anyway, whether manually or automatically, so why aren't we having Laurlybot just doing main pages? I'd like to link to WW:ITEMS, as that shows that the community would rather have all the informatio on one page than on subpages. I personally don't understand how we went from what's there to what Laurlybot is doing now. The policy doesn't regard npc pages, but it does leave comment on how we should be dealing with mainpages. More writing policy on things like ability pages, server pages, and user pages. I don't know that ability pages need policy, as we have a boilerplate. But there probably should be something on server pages. As for user pages, anything goes. The only thing which is explicitly disallowed on user pages is WW:DNP. Maybe we should put a policy portal link on the sidebar. I agree with the thought. Policy should be linked prominently (somewhere) if it isn't already. Get the Special:Search to show simpler output options. That might be an inhibition of the engine, though good ideas. Make the rework part of the new projects process and do a much better job of promoting and organizing the projects. Sure, but if you haven't noticed, the people who contribute... contribute. And then there are the people who don't. So the issue here is general community involvement, rather than telling people that already know about the projects again to participate. Archive Village pump and Warcraft pump more often. Hmm... I'd disagree. But not a biggy. --Sky (talk | con | wh) 00:21, 3 December 2007 (UTC) Zeal, tables are the semantically correct method for showing data. 00:31, 3 December 2007 (UTC) Repeat what i said in IRC. Tabular data, certainly. Lists, layout, non-tabular data, headers, messages, certainly not! And they all exist on the wiki in various forms. Sky, your replies are painfully hard to read, don't know what is and isn't a quote and what parts were directed to me :S But i'll see if i can comprehend it.
* Yes, the former. Wouldn't have to be the same as i preposed before, but that's the general idea. It's not unneccessary styling (hell it originally came about to fix a big flaw in the monobook skin which still exists both here and on wikipedia) and they're not complicated, in fact they simplify and solve the problems with all the complicated variations of headers which current exist and get placed before the content.
* The reason there is no standardized pages is sadly because there is no standards across the boilerplates themselves, they all vary too much and the onyl thing consistant between them is that they look bare and like any other article (as you said, only item pages are currently recognizable because {{tooltip}} and it's location on the page).
* You interpreted it fine. I actually hate the ToC period because you have no styling or formatting control over it and it really just gets creates problems rather than being helpful to navigating the article. Only solutions i can think to have the helpfulness of a ToC without the issues it causes is if the toc was a navigation drop down or it was located outside the article's bounds (above it horizontally or in sidebar vertically) It's more a failing of the mediawiki base of how the page is layed out (article and user links, side bar, content, footer). It's a bit of a mess. Think that's the end of my points :S --
*
* talk:Zeal
*
* 01:13, 3 December 2007 (UTC) My 2cp: Help Articles and Policies: (I'm bunching these because I consider them integral to each other) This is something I'm willing to work on after I move. I think we need to reinvigorate the Help Team, though. It appears that no one is left from it to do the work and maintenance that should be done. I'm not volunteering for this, however, as I'm not sure I'll have the time. If I do, you'll be sure to hear from me. :P More to come! I can't process this craziness all at the same time! --DuTempete talk|contr 02:25, 3 December 2007 (UTC) Sandbox should be linked in the navi bar for the convenience of newbies. -SpoiltCheese 04:57, 17 December 2007 (UTC)
|
![[RDF Data]](/fct/images/sw-rdf-blue.png)