This Forum has been archived

Visit the new Forums
Forums: Index WoWWiki technical AddOns, APIs, Macros, UI, and XML

User Interface XML Pages Catigorization

You are welcome ;) As far as how to catigorize or mark things as elements or otherwise, I'm not sure. It's complicated because its hard to disambiguate when we mean a type or an actual element of a particular type. For instance in Anchor there is Offset, which is a Dimension. Now what that Dimension means in the context of an Anchor may need special documentation, or it may be that Dimension should be documented but with verbiage about Anchor, or both. In the lists of parts for an element currently its mostly just linked and documented as the element name. However if you go and show type next to the element name it starts becoming possibly an overly technical actual development manual, and maybe overwelming or wrong for a set of the audence.

there could be XML\(ElementName) XML\(TypeName) to keep the path short, and XML:Type category and XML:Element category.

as i started to document some of this, with tidbits that I had to go research, and not wanting them to be lost into the ether for everyone else, it would be way too much work i think to make a document for every use of Dimension and then its inline x,y... and its AbsDimension and RelDimension, as just examples. and I think it woudl be better to build out the XML docs for refernce and begin to point the hundreds of guides at those. I do remember tryign to use this wiki when i was starting and i do remember most of where i ran out of fundemental answers to get started.

hope this helps. --Celess22 (talk) 20:22, August 01, 2012 (UTC)

Portal Pages

Celess (talk) 01:46, August 4, 2012 (UTC)

Specifically the Interface Customization. For how long have they been so ungodly slow and huge? This is Wikia? Its not usable. Also I tried to load a differnt UI page on an android phone last night. It was 99.99% other content showing, scrolling for 5 minutes, not kidding (android browser probalbyu didnt know hwo to hide it) with a little tiny section in the middle. I think the UI should have its own featured article (to make it liveable perf wise) or should get an exclusion from that part of the template. Thoughts?

If you have problems with the mobile version of pages you need to bug Wikia. Unfortunately, they don't give us much or any control over the mobile version. If you want to make an alternative page to the portal, please do. --Gengar orange 22x22Beware the sneaky smile! Fandyllic (talk · contr) 3 Aug 2012 7:49 PM Pacific

AddOn Dev Category

I'm not sure about one. Theres a ton of dev stuff in AddOns, as cat page states that actual addons go in Hosted, though thats a can of worms too because where do you put 'non-hosted' references. Celess (talk) 16:08, August 6, 2012 (UTC)

also maybe UI AddOn would be better as AddOn UI makes it sound like theres somekind of User Interface for AddOns, which would be a whole nother thing.Celess (talk) 16:12, August 6, 2012 (UTC)

The problem with UI AddOn is that it makes it sounds like there is some kind of AddOn name "UI". Would "AddOn API" be appropriate? --Gengar orange 22x22Beware the sneaky smile! Fandyllic (talk · contr) 6 Aug 2012 10:58 AM Pacificners.
Theres already a ton of precident with things being marked UI in the front for other Dev things, sort of like XML xxxx to say its of the XML stuff. I tried UIC which woudl be the most appropriate because that says User Interface Customisationm and it you really wanted to go all the way it could be UICAM - User Interface Customization and Macros, as is the Blizz way of thinking about the dev side for consumers. The UIC bleeds into Macro down in ther somewhere because macro commands are jsut lists down in lua with lua attached, and when you makean addon you will mix addon code with the backing code to execute the commands.
Overall I was going on what you said before, which ill charecterize what you said as: "Get the stuff in and sorted best can, can always clean up the organization, but need the refesh of the content and heavy lifting badly". You didnt say all that exactly but that was my tac. I thought UI was the best transitional marker to seperate that which is user wiht that which is addon and macro dev. API is bad becausether is already too much that says API which isnt API as for what API means and makes trying to teach and explain much harder. UIC is the best really, but its foreign here, markign UI isnt. So API is interface like known functions and variables, UIC is the UI developent, which is a topic, and covers many non-addon areas as I woudlnt call the FrameXML and GLueXML code user addons or customization but we do cover those. UIC is the topic and Macro dev is also covered by this side, but you dont need AddOn for UIC necessarily or AddOn for Macros. Its complicated. I think it woudl be best to table that till more is cleaned up. If I was king for a day, id just leave the cat as AddOns as a topic category since a good portion of that is dev stuff and the topic clearly states not to put addons, and gives me (and the users) a chance to find all the pages and set the {uiaddon} (aka uicaddon) and then start the blood-letting. Second choice, though none are ideal, woudl be to make the cat UI AddOn and move each one as I go through them, but it loks like most stuff in ther is already dev, and coudl jsut rename the cat later? —This unsigned comment is by Celess22 (talkcontribs) 22:30, August 6, 2012. Please sign your posts with ~~~~! ...Sorry :) --Celess (talk) 06:36, August 7, 2012 (UTC)
Renaming categories is a pain, but I'm okay with "UI AddOn", if you use it consistently. The whole thing about not putting pages for specific AddOns in Category:AddOns was not my idea and I really didn't agree with it, but I didn't oppose it. We could revisit putting non-hosted AddOn info pages in the category, since I'm pretty sure its current use isn't policy anyway.
Although XML and macros are not strictly API elements, they are part of the API support structure, so it isn't too far off to keep them under the API umbrella. Macros are an edge case, but they definitely change as the API changes and are not general UI from a basic user perspective (i.e. you could play the game perfectly fine without ever using a macro).
Just keep doing what you're doing. I'll make small adjustments as things go along and we can discuss any major issues here, although I think I'll make a forum post soon for discussion instead of my talk page. --Gengar orange 22x22Beware the sneaky smile! Fandyllic (talk · contr) 6 Aug 2012 9:54 PM Pacific
yeah i think might be better to wait and see what I can pull togehter and maybe can have better idea what to make for nameing of swaths of things. like collect all your marbles in one place and like 'oh i have like 20 blue marbles and only 1 red, ill organize the whole thing this way.' The API thing is an issue because if you call everyting API then you lose the ability to differenciate when you actually have an API. Like AddOns are nto an API, they use APIs and conventions, and have rules to follow that make them an AddOn. However you can make a functional AddOn and use no actual APIs. And documenting all that in a way that allows people to know context of a document and establish context of elements is never easy. One thing that can be leaned on is the vast amount of precidence in documenting programmable or customizable systems, from other worlds besides WoW. All thats left is diferenciating the document context like readers knowing they are in UIC and Macro land vs everyting else,and howto get to oneor the other if they wish.

Site Improvements

also the UIC&M (UIC and Macro Dev) Portal, just to try out a term, is much much, orders of magnitude, faster now. In order to complete it I need to make a <style> tag, and a template that can hold it, for a '#mptabslite' set that doesnt draw the ire of the portal menu js. I think the tabs are much moreintuative and poeple are usd to them,than the portal dropdown style things above, so i would think it would be good to keep them. I donthave rights to add templates to or whatever. I coudl give you the code which would be a 'lite' version of #mptabs. Part of the issue is that Google will punish you hard for those 2 - 8 min load times. Anditmakes it almsot not worth trying ot editthe portal because it takes forever to edit and see changes. For users, I know I woudnt come here for a long time because it wasnt worth waiting and watching my machine do gyrations loading 100,000+ DOM elements, plus the 'Media' retardation, and on Pedia it wasnt really any better, as the curse tardation is probalby jsut as bad, soemtiems 15 min load times on curseand many of the same people. I mean it shouldnt have so much tardation, its not liek webpages are new things in this world. #mptabliteneeds like 4 style lines, for #mptab, #mptab active, inactive etc... want me to ferrit out the proper code?Celess (talk) 06:35, August 7, 2012 (UTC)

FYI, if you want to test style stuff without affecting the entire wiki (aka not editing MediaWiki:Wikia.css, you can use Special:MyPage/wikia.css (which would be User:Celess22/wikia.css for you). The same goes for JS where you can use Special:MyPage/wikia.js (which would be User:Celess22/wikia.js for you). Try it out and get everything working as good as you can. Once you have it working pretty well, I will test it in my subpages and roll it out to the whole wiki, if it seems stable. --Gengar orange 22x22Beware the sneaky smile! Fandyllic (talk · contr) 7 Aug 2012 7:29 AM Pacific

right now its all isolated to UIC&M and live. there were 'lite' versions of portal infrastruture. I was very careful toonly affect that page. but to complete the tab menu, need one style. but yes it was done in a way to make easy for your perusal for possiblity of used on other protal pages if you wanted. i was thinking to just make an extra template and not touch the core css, but maybe better to not have extra templates if its ok to just make another style for the tabs in the regular css file. ill try the sandbox. sorry not really awake yet... --Celess (talk) 19:08, August 7, 2012 (UTC)

ok. User:Celess22/wikia.css its done. ;) that just needs to be added under the #mptabs section in the normal .css. it wont affect anything not already using the 'lite' versions; a page with tabs would have to use that version expressly, and would no longer try to use the divs to switch portal pages. this is needed for the tab menus to work with the {wwplite} template UIC portal is using atm.--Celess (talk) 19:27, August 7, 2012 (UTC)

I added the CSS from User:Celess22/wikia.css to my User:Fandyllic/wikia.css. I'll unprotect the other portal pages so you can put in Template:Wwplite, but if using Template:Wwplite on all portals doesn't work I've got to revert your changes back to using Template:Wwp. Also, I'm not going to add your CSS sitewide until everything works. --Gengar orange 22x22Beware the sneaky smile! Fandyllic (talk · contr) 8 Aug 2012 7:42 AM Pacific

I'm happy with the lite versions only on UIC as I was thinking it was a special case as was for people trying ot look someting up quickly. I did make it in a way so that it would work for the others if you wanted as a drop in replacement. It all works. The differnce is in whether the potalmenu reloads the page or uses the div switching. Without the div switching phones should work correctly and the pages should load between 10 and 100 times faster, if not even faster than that. The pages load fast enough that for some peple the page reload is probably faster than the actual div switch with the old way page fully loaded even. I cant work around the js issue without a new style or changing the js to ignore embedding the onclick. Its all baked and happy. All I need to do is change #mptabs to #mptabslite when it exists. If i change it now without the css the menu will look funny for everyone. I cant use inline css on the style attributes becaue it wont emulate hover and looks messy with the repclicates style on each menu tag. --Celess (talk) 16:51, August 8, 2012 (UTC)

If css is on the User:Fandyllic/wikia.css, does that make it available for everyone?. ... Nope it doesnt. --Celess (talk) 17:01, August 8, 2012 (UTC)

Ok I see. When I'm logged in the personal css or js work, but only for me nd only whne logged in (naturally). So I tested it on safari and ie9 and it works. Had to put #mptabslite back to #mptabs so the menu looks normal foreveryone since they wont get the style. If you want to try it, get the version in my .css thats there now, then change the wwplite template from #mptabs to #mptabslite, make sure logged in, hit the UIC portal page. Once you click on a menu and the page changes you will no longer be using wwplite obvisously, however the load speed for the UIC portal proper (wen its the actual browser page) is happy. Since the #msptabslite 'family' is a new name and a new set, it wont affect anything else if placed for general availability. Only comes into play when used and woudl only be used on UIC portal. I cant leave the wwplite with the new style as it woudl look broken for the rest f the world until the style is there. --Celess (talk) 17:35, August 8, 2012 (UTC)


As if this wasnt a big enough wall of text here... Basically this was all done in a way to not affect anyting else, until someone wanted to. The 'lite' versions of everyting are versions that were optimized for load and browser speed, hopfully reducing some long standing issues with wowiki portals. These have no real loss of functionality. I hit a snag with the portal menu because of the tie between the load js and the #mptabs where the js looks for a tag named #mptabs then wants to replace the onclick to activate the divs. I cant add or change any .css or .j or apraently embedd any on media wiki, as makes sense for security. My intent was to allow the tabs to just run thier natural anchor href so that all of hte divs didnt have to be preloaded. So part of the process and what the 'lite' wwp does is not smartly load only the single div of the intended portal browser page, expecting the achors to fire naturally. Right now, because you cant do hover with tag level inline css, is leave the #mptabs so the menu gets its hover, but with the js still replacing the onclick, which is unessary for lite at the moment. because of this the links dont work, they do but they try to load empty divs. Thus I wouldnt want to propagate this to other portals until theres the new #mptabslite to help disable the js on {wwplite}. The choices were edit the js, which is more risky, as to teach it to selectivly not do its thing on load, or to use a differently named style. If king for a day would add the css for now, then later if sounds like an imprement either teach the js to not add an onclick if the div is not there (which woudl be cool) or use ajax to load hte divs on demand. The point being is to not crush the page load, provide reasonable phone browsing, and help DOM pressure with number of elements as to make basic things like scrolling not tke 10 seconds to let the user move up and down. Page load and scroll were not happy for dev reference materal, where you couldnt even see the item to click if you dint want wait for the page to finish load because you couldnt scroll either. My other other choices were to either remove the tabs menu from lite, or to make a differently styled menu using tag level inline css, but my opinion is that the user familiarity aspect rules all.

An alternative way to test this in somewhat isolation, would be to add a :MediaWiki template, like for the MainTwitterFeedScript, to hold the css which I could place above the menu in wwplite and that way woudnt have to add this to the main css and could still have a complete wwplite, and use selectivly for differnt portals as saw fit. Until you were satisfied as to place the css in the main css. --Celess (talk) 18:07, August 8, 2012 (UTC)

WW Portal Lite Example


If you add contents of User:Celess22/wikiatabsstyle.tag to MediaWiki:PortalTabsLiteStyle (which I cant make myself), then can have one working portal. I cant "...other portal pages so you can put in Template:Wwplite..." until have style, we all need style... :) The CSS would be limited ot the use in wwplite and I understnd changing the site css is a careful thing. Once happy and seems good to all concerned could jsut add the new css to regualar site one, aor leave the template one. Having the special template allows Media to accept the <style> tag, or I have make the same with inline, but then no hover. Should be a very benign change. --Celess (talk) 20:43, August 8, 2012 (UTC)

Okay MediaWiki:PortalTabsLiteStyle updated. Not sure why this is needed, but it's there. I may be a bit slow to respond for the next week or so, since I'm pretty busy at work. --Gengar orange 22x22Beware the sneaky smile! Fandyllic (talk · contr) 9 Aug 2012 4:32 PM Pacific

Thank you :) And Ill keep that in mind. :) This allows me to make the menu functional without having to update the main css. Later when you are comfortable can just add that to the main css, and wonthave to use the template. Ill test it on UIC an as you asked will put it on the others. The way it was done allows you to swap wwplite and wwp at will and all still working, as you see fit. --Celess (talk) 04:45, August 10, 2012 (UTC)

ok, UIC portal is now happy and done or 'lite' imporovements for now. please remember to remove any instances of #mptabslite from your personal User:Fandyllic:media.css or whatever its called ;) and clear your browser cache. what you will see is a screaming fast load of UIC portal, and now functional portal tab buttons, which will load a new page wen clicked to the other portals. The other portals still use the old template and will be slow and their menus will work the old way. Hit it once Portal:Interface_customization and ill then change the others, or may be Raylene13 (sp) would like to try. Hit me up and tell me if you cant hop in chat for a few minutes. Ill be around for the next few hours and monitoring my mail. want to tell you about a few other things planned. --Celess (talk) 04:58, August 10, 2012 (UTC)

Portal Changes

No, not yet on the css. :) You can tell by going to Portal:Interface customization and then trying to click on another portal. UIC will be fast the other portal will be slow. Ill propagate to the other portals. You can switch any of them back by jsut changing {wwplite} to {wwp}. UIC was like up to 8 mins for fully load, by the time the last ajax was done. There were some like 500+ images with aobut a 6 sec latency per image hitting media image server. There should be a sizeable upswing for two reasons, if you are getting decent traffic; one is that the pounding of the preset specific media image server 'slot' for WW will stop and for the WW servers in general, and the client side itself. --Celess (talk) 18:42, August 10, 2012 (UTC)

speed wise is far form perfect, but should be way more livable. the div switch was more slick, but not useable the way the templates are arranged atm, wihtout going to ajax for the div loads which not guarenteed to always work. ill look at it more in the next few days --Celess (talk) 19:13, August 10, 2012 (UTC)

FM and Twitter are back --Celess (talk) 19:50, August 10, 2012 (UTC)

Ok, if you are happy with it, can move the template version to site wide media.css. Will be a hair faster that way. Just take the css and remove the <style> and </style> tags obvisously. Can place under the #mptabs ones.Ill remove the template include from {wwplite}. It will still work fine if both are there. --Celess (talk) 20:13, August 11, 2012 (UTC)

well.... I must have fixed someting because ads stopped on portal pages when logged in, as they are supposed to. they still load on Portal:Main. I went and watched the page load and console and its as programmed. --Celess (talk) 01:11, August 12, 2012 (UTC)

Portal Status

  • Portal:Main - still needs love. dun have rights. is what gets hit by Google, as I jsut tried hitting not logged in.
  • WoW - Universe - updated

--Celess (talk) 20:13, August 11, 2012 (UTC)

Oops, sorry. Portal:Main should be editable now. --Gengar orange 22x22Beware the sneaky smile! Fandyllic (talk · contr) 10 Aug 2012 1:52 PM Pacific

Ad blocker interference detected!

Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.