Talk:World of Warcraft API

Archived talk

• Talk:World of Warcraft API/Archive 2005 - Everything from 2005.
• Talk:World_of_Warcraft_API/Archive_2006_January_Split_Debate - The January 2006 API page split debate.
• Talk:World_of_Warcraft_API/Archive_2006_June - Up to and including june 2006.

Restructuring things without a new namespace

API Reference Categories Interface Customization World of Warcraft API Widgets Widget Methods Widget Event Handlers FrameXML Documentation API Events API Types

It basically looks like Rustak won't be adding any more namespaces - period. So I've started some structuring work without it (almost said REstructuring, but it isn't really..).

See the nice table on the right for categories I've created so far. They're not just duds; everything that belongs in them now actually lives there rather than Category:World of Warcraft API.

Comments so far, or nice and shiny ideas? (Please someone say something or I'm likely to go split the main API page just to spark some discussion :-)) --Mikk 15:12, 11 June 2006 (EDT)

The FrameXML section lacks lots of information - e.g. there's absolutely no information about substitution groups, links to the API documentation of the element, etc... As it is now - there is no reason to even have it

Now there is a huge and impossible to read list of all Widgets, and on the other side the Widget pages are empty and lack other important information - like their attributes, inheritance, substitution group members (yeah again)

My suggestion:

Combine XML User Interface & Widget API into FrameXML Elements or something like that (hope you geht the point). Provide API info (lua functions) AND xml info (inheritance etc.) from a single widget on ONE page. Get rid of "API_Widgetname" pages and only

As with all the categories - sure, good idea. The only problem is that api functions without their own pages would be simply not there. so before the "switch" to pure categories we would have to create pages for every api-function so that no function will disappear. Also I would recommend subcategories representing the current categorization in World_of_Warcraft_API like Action Functions etc..

watchout 09:29, 9 July 2006 (EDT)

I never suggested we get rid of World of Warcraft API. In part for reasons you mentioned, but also because we all want a big page that we can just ctrl+f in and get the bare minimums (arguments, very brief description). And yeah, those categories you suggest would be the categories I'd want to see. Though the problem is that if a function doesn't have a page, it won't show in the category, which makes me think it's not very useful to begin with, in spite of everything =/   --Mikk 10:48, 10 July 2006 (EDT)

Good, but what are the categories for? There seems to be no actual reason to have them, you could as well put all those pages in a global wowwiki category... Categories are for easier browsing through the wiki, you can find similar pages etc. but why using categories when that huge World_of_Warcraft_API has all functions while the categories cover no more than 10% of them?

And what do you think about the Widget thing? You left that out... Personally I thinks it's better to have more information on the function/widget pages than on those overview pages. (urgs, sorry for the delay, I thought I had checked this page more often...) --watchout 05:12, 16 July 2006 (EDT)

You know... I was going to start out saying that it'd be a pain to maintain separate widget pages since you'll be duplicating a lot of information. Then it hit me that we can easily put the methods for each (base) class into subpages and pull them in as templates in each widget's page. And even keep Widget API just like it looks today by pulling them all into that page. Cool idea. I'm going to go check with Flickering though since he's generating that page from a script. --Mikk 05:45, 16 July 2006 (EDT)

Hm, you mean inherited functions etc.? I didnt think mean to take it this far, but it's ok. The only thing that needs to be considered would be performance. I know that many templates were deleted in wikipedia because of the performance problems they caused. wowwiki is at least a level beneath wikipedia in both scale and users, but I really don't know how big the performance problem with templates is... Um yeah, my main concern was that information about one and the same widget is spread and to some degree duplicated over small pages. TBH, I don't like those huge UISUMMARY_ pages, where every inherited method is listed with all arguments... Hmm, maybe I should create a sample page to show what I mean... --watchout 14:17, 16 July 2006 (EDT)

Thats about what I meant: User:Watchout/DevWidget - still needs a bit refining tho (stupid edit links) --watchout 20:35, 10 August 2006 (EDT)

Why the "API" prefix?

Am I the only one getting annoyed by the "API" prefix on everything? It's just forcing us to pipe links all the time when we're linking to a function. It seems to me that it'd be more wiki to just use e.g. [[GetFramerate]], [[UIObject:SetAlpha]].... ?

Yes, it'd be a lot of work to change everything. I'm up for it though :-P (Of course with redirects from the old pages; that happens automatically in mediawiki when you rename a page)   --Mikk 07:45, 3 August 2006 (EDT)

API page redesign?

There's a proposal in WoWWiki:Village pump#API Boilerplate Styling to change the design of API pages. Presently, there's two proposals:

1. A complete redesign of all page content, as in Boilerplate:API Documentation by Mind.
2. Just change the Template:Tlink template to include a bit more colorful graphics, as in User:Mikk/Dev. (No changes required to individual pages)

=== Votes ===

• You can vote for two options if you're ok with either one.

Keep it as it is

1. Keep Mikk 07:54, 3 August 2006 (EDT) - ()
2. Keep Shadow 12:53, 3 August 2006 (EDT) - ()
3. Keep Osiris 06:35, 7 August 2006 (EDT) - ()
4. Keep Micah 18:40, 10 August 2006 (EDT) - (When I come to the API section of WoW Wiki I'm not here to look at pretty graphics, I'm here find information as quickly as possible. Any added graphics just add to the load time and take up UI space and changing the layout as in the Makeover proposal would simply spread the information out forcing me to have to scroll for information that is currently available in a single easy to read yet compact page. While the)
5. Keep watchout 18:51, 10 August 2006 (EDT) - (Actually I don't think a wiki should be built with fancy graphics or style info on every page. Mikk's suggestion would be ok, but adding graphics, or other style info that are not connected to the content, into a template isn't a good thing to do. The only thing you'll accomplish is (further) destroying other skins)
6. Keep Thrae 01:40, 12 August 2006 (EDT) - ()
7. Keep JIM 17:07, 12 August 2006 (EDT) - (The sole advantage to Mikk/Dev that I see is that you'd know at a glance which of the multiple Wiki pages you had open was the API and which one the event. I've never wanted for that distinction.)
8. Keep LudiKalell2 18:48, 14 August 2006 (GMT) - (I like it the way it looks now, small and simple, content >> design)

Boilerplate:API Documentation

User:Mikk/Dev

1. Template Mikk 07:54, 3 August 2006 (EDT) - (my idea but I'm in no way married to it - i just don't like the idea of a total makeover of all content. lots of work.)
2. Template Shadow 12:53, 3 August 2006 (EDT) - (Agreed with Mikk pretty much)
3. Template Osiris 06:35, 7 August 2006 (EDT) - (Slightly improves the appearance/readability of content, but neither suggestion is a drastic improvement over what we have now. Certainly not worth a total makeover.)
4. Template Ralthor 08:36, 8 August 2006 (EDT) - (Love the graphic on the side, just having a colorful design on the border makes a page full of text seem easier to read.)
5. Template Kirkburn 10:50, 8 August 2006 (EDT) - (Nice design :))
6. Template Progdog 20:14, 16 August 2006 (PST) - (I like the template. If anything, maybe it will inspire folks to work on pages more?)
7. Template MentalPower 21:12, 16 August 2006 (EDT) - (I like the template, the complete re-design is not worth it IMHO)

Comments

Design should never rule a wiki, content should. So you shouldnt decide whats fancy looking, but what's practical. The boilerplate thing doesnt seem practical to me, just restrictive (no offense) --watchout 19:05, 10 August 2006 (EDT)

I completely agree with your points about skins. I designed the vertical bar to work as well as possible on other skins. Yes, it still becomes dark, but it's definitely readable and doesn't hurt too much (look for yourself). And, yeah, it's up there on the list of stuff to fix when we get CSS access, if it does end up getting chosen. --Mikk 20:31, 10 August 2006 (EDT)

Using Monobook myself - dark text on light background is more convenient to read (but thats another topic...) - And from my point there is a break in the style. Its perfectly readable, but just breaks the style. But when I say content is more important to me, I mean it. It's ok with me. I just didnt see a reason to work on something when there's no need ;-). Oh and you should work on antialising the graphics (use PNG24 maybe? Filter out M$ via conditional comments).

(But the Boilerplate thing I still don't like because it kills content, making it harder for me to read etc.) --watchout 20:52, 10 August 2006 (EDT)

---

Got rid of "API TYPE" prefix

Welpz, I came to the end of my patience with piping links all the time to hide the "API TYPE" prefix, so now the API type pages are simply named e.g. "bagId", "unitId", etc, the wiki way. → API Types.   --Mikk 13:18, 13 August 2006 (EDT)