-----The message didn't get received by the list or archives since it was to long so I'm truncating and resending this----- ^_^ Let's see if I can make inline comments without breaking anything, rofl... I have a thunderbird extension which takes any sort of html, or text quotes and nicely formats them. So whether you use some html tags or just >'s at the start of the line, it turns them into some sort of html quote element that is uniformly styled. (Which is why I prefer HTML quotes being sent to the server instead of >'s because if mailman formats those and breaks the lines that start with > I end up with some sort of weird thing where there is a quote, non-quote, and quote on the next line because Mailman inserted a newline pushing the text out of the text type quote.
John Q wrote: > DanTMan.... always a pleasure. :) ^_^ you think that now... but you don't know how many times Jack Phoenix, and one or two other users has poked me and said to get hired onto the tech team... I'm not so sure how this would go on payroll... lol > comments in-line... > > DanTMan wrote: > >> Ok, time for round 2 of hit & miss ^_^ lol... >> >> Hit: The widget system is nice. >> Miss: The widget bar puts it's curvy self in between 2 strait edged >> boxes. Opening up an area in between the options and the page is fine, >> >> > but not when it doesn't flow.Actually, we had planned to make the widget > boxes without curves... but > we wanted to focus on getting this out so people could use it. We're > going to have things to fix, undoubtedly, so we'll be working in that > style change as we go. > > > >> Hit: A widget dashboard is nice. >> Miss: In Slate the widgets inside are styled white like the page, but >> the edit and X links are still white making them invisible. >> Miss: We have one dashboard and no links to it outside of the Special >> pages. I suggest using the parameter after the / to name dashboards, >> and placing a list of created dashboards and form to create new ones >> on the main dashboard page. >> > Actually, we haven't *officially* released the WidgetDashboard... but > I'm thinking a link to it will be in the username drop down on the top line. > > I think what you're suggesting is the ability to create more than one > dashboard... right now there's one per user, just like one user page, > one user talk page, one user profile page, and then one user dashboard > page. I can see how you'd fill it up in about 8ms... :) ... let me > think about how that would work and see what people want as we roll out > more. Yup... more than one dashboard would be nice. And some sort of quick links to them. Perhaps a widget to link to widgets ^_^ rofl... Stick one in your sidebar to get quick links to your dashboard. Actually for that matter, a Widget which you could hit an add button and create links inside of would be nice. Thinking it over, there's a possibility that using some form trickery, drag n' drop stuff, and various events that you could create one that will let someone drag a url from the page and drop it into that box to create a new link there. I don't know about only having one though ;) Don't forget... We may have only one Profile because it's a new feature. But as for Userpages and Talkpages. We archive our talkpages with sub talk pages. And don't forget about our gigantic userspace. Every user has a near unlimited region of space to fill up. Every page that begins with User:Username/ belongs to you... And MediaWiki even recognizes that as a fact because it adds your various User contributions and other links to the toolbox on those pages. ^_^ my userpage itself is actually comprised of around 15 pages together. Lots of transclusions, and even more parserfunctions which make a single set of pages on the Animepedia look customized to each individual site when a Bot simply copies all those to the other wiki it's told to. >> Hit: A wide logo is a pretty good idea, gives good content space and >> doesn't take up any important room. >> Miss: Erm... 266? What happened to 250 or 275... And what's with the 6?! >> > Heh... ok, have to admit I didn't think about it from a round number > point of view. 130x150 (pretty standard wiki logo size) = 260x75. I > think when I did this number a while ago... and I have to admit I don't > remember off-hand where I got the 133x150 which turned into 266x75. We > are actually thinking to make that area dynamic so that if the logo ends > before 266 then the header links move left allowing lnoger links for the > custom header links... but I wanted people to see how much space they > *have* before starting to deal with dynamic spacing there. > ^_^ if you need some consolidation... The logo in Monobook is actually 155x155px... We've just been lieing to everyone that it's 150, rofl... >> Hit: The drop-down on the top is nice, and putting a userpage link in >> there will make it possible for me to keep the userpage/talkpage links >> on other wiki in my WikiSwitch. >> Miss: You use the Username twice. >> Welcome, Dantman! *Dantman*[#\/] - [Log out] >> Take out one, and you have spare room for other things like [Switch >> user] or custom links. >> Welcome, *Dantman!*[#\/] - [Log out] - [Switch user] >> Perhaps the menu could even be a mouse-over. >> ((Note: I didn't notice the Long message there till I went to central. >> btw: Where is this message customized?)) >> > Actually, on our test wiki ... fp012.qa.wikia.com... it looks the way > you suggest. I'll have Emil take a look. Will ask the designer about > mouse-over vs. click drop-down. > If you use Mouse-Over you can provide a CSS fallback for those without JS that looks the same. So at this second: Miss: The dropdown has no CSS fallback, anyone without JS that doesn't know how to use URL trickery or search tricks to get to prefs or switch skins has no way to get to their userpage, talkpage, contributions pages, or even get to their preferences page to switch their skins. Hit: Widgets work even without JS. I disabled JS, and even though they're more dynamic then the rest of the site the RC Widget still showed up in the sidebar. That's a big hit, even if someone goes to a less functional computer, they still have the normal functionality of the widgets they configured elsewhere. >> Hit: The links at the top are nice, and customizing a set is nice to. >> Miss: Something's bugged in the css. Half the time "Create an article" >> fits, the other half the article drops down to the next line.... On >> the Animepedia I'm on the Main Page, I hit edit and it drops down, I >> go back to the article and it's still dropped down (Even though before >> then it was fitting on that exact same page), then I hit the article >> link again and it jumps back up to stay on one line. All the while, >> there's nothing on the right to drop it down with my wide screen. >> > Ok... we need to take a look at that. Any consistency in the behavior > you can figure out before we get there would be appreciated. > > >> Hit: YUI is a nice system to use. And in loading them, users could >> probably use them to nicely improve on the existing scripts, and even >> make more flashy methods for them. >> Miss: You're loading the YUI stuff badly. >> * You loaded utilities.js and animation.js even though animation.js is >> one of the scripts compacted into utilities.js. And you're loading >> animation.js instead of animation-min.js >> > :) I'll follow up with Inez. We actually are going to be consolidating a > lot of the separate js files into one to reduce back-and-forths... and > Yahoo just released a new version of YUI a couple of days ago that only > loads the elements needed on a particular page. We're not going to > upgrade to that until this release has settled, though. > >> * You're loading utilities.js and yahoo-dom-event.js even though the 3 >> things inside of yahoo-dom-event.js are already in utilities.js >> * You're loading container-min.js and container_core-min.js even >> though container_core is just a lighter version of container for those >> not using all of the containers. >> * You're loading the logger even though it's not something actively >> used. Though, I'd forgive that, since in truth. The logger is a nice >> JS debugging tool. I load it via Userscript on Wiki-Tools to help me >> iron out things till they work. >> > Yes, it's being loaded for debugging purposes. All of this stuff is new > enough that we'll need that there for a while yet. I'll ask Inez about > the lib overlap and see. > >> * You're loading all these scripts from the local wiki instead of >> loading them from the shared images server. That means more scripts >> are loaded for the client, and Wikia's servers serve out the same >> script again if the user goes to another wiki. When if they were >> loaded from images.wikia.com like I remember many used to be then they >> would only be loaded once between all Wikia wiki. >> > Yes, they'll be loaded from images... Emil noticed this late last night. > That will be changed shortly. > >> To summarize this is what you are loading: >> /skins3/common/yui/yahoo-dom-event/yahoo-dom-event.js >> /skins3/common/yui/utilities/utilities.js >> /skins3/common/yui/animation/animation.js >> /skins3/common/yui/container/container-min.js >> /skins3/common/yui/container/container_core-min.js >> /skins3/common/yui/autocomplete/autocomplete-min.js >> This is something like what you should be loading: (Note that of >> course you'd use whatever directory you placed it in on images... or >> you could do what I did when I created http://skins.wiki-tools.com, >> and have a subdomain for shared skin/lib output. Though, I was >> considering moving libs like yui to a new http://lib.wiki-tools.com >> once I got my overload method finished. >> http://images.wikia.com/skins3/common/yui/utilities/utilities.js >> http://images.wikia.com/skins3/common/yui/container/container-min.js >> http://images.wikia.com/skins3/common/yui/autocomplete/autocomplete-min.js >> >> Do we see the problem here? The second one loads the exact same stuff >> that the first one does. Except it's not double loading 3 scripts, and >> it's not causing the Wikia servers to dish out duplicate scripts. If >> you have issues with different extensions loading them independantly. >> Create a YUILoader class, and call YUILoader->loadJS( >> 'utilities/utilities', 'container/container', >> 'autocomplete/autocomplete' ); or such... In simple terms. Make it >> understand that utilities is the same as yahoo, animation, dom, event, >> etc... And have it save a list of what it needs to load. And when >> extensions load over half the needed scripts for utilities or >> yahoo-dom-event load those scripts instead and remove the others from >> the list. Also append -min.js to all the libraries except utilities >> and yahoo-dom-event. Yahoo even has a JS loader, PHP is much more >> robust you could easily create a better one in it. >> Or, you could do this the lazy way... And load utilities, and all the >> widget stuff that isn't part of the compacted stuff as -min.js then be >> done with it cause you've loaded everything you'll ever need, and also >> loaded the extra yahoo widgets that users can use to create their own >> user js scripts. Like how I integrated YUI's tabs into MediaWiki on >> Wiki-Tools (except it would be cleaner using ones already loaded >> instead of loading via userscript). >> >> >> > Ditto with above. I need to have Inez take a look. :) > Three comments, I sort of hit you over and over on that issue... rofl >> Extension suggestion: Fix up the User style extension. If you agree >> that it's a fair idea to give user's the ability to customize a >> stylesheet for their own userspace/talkspace I would be happy to fix >> up the extension to something usable on Wikia on the development >> server. If you want a reason, compare: >> http://www.wikia.com/index.php?title=User:Dantman&useskin=monobook to >> http://www.wikia.com/index.php?title=User:Dantman&useskin=quartzslate >> And think of how nice it would be for a user to customize the CSS of >> their userspace instead of using the ugly WikiText hacks to colorize >> and do strange things to the page. >> As for the skin stuff... We can either load a skinname, or load a >> common and a skinname, or we could load a common css page and >> introduce a new "skin-....." into the body tag and allow for per skin >> css just like we have per-page css. >> > Yes, Emil was taking a look at this just a few hours ago... it's a bug > that it's not getting included... but I think there might be a caching > issue through our squids going on there as well. We'll get that going as > soon as we can. > Bug, userstyles... ^_^ I think we're on 2 different pages. So... userstyles aren't being included into V2 as a bug right now? No wonder the JS I put in my global.js to enable EditArea when I'm editing isn't working. O_o but then why do I see the script tag in the source, and my JS overview tell me that my code is being included. And yet, EditArea isn't working and I have no JS errors. T_T I guess I did the JS testing for elements to well, and it's just failing without creating any JS errors because the elements it's looking for aren't there. But to summarize what I was meaning. Was not a userscripts userstyles that a user sees, but styles (never scripts) that a user uses to control not what he see's everywhere, but what everyone including him sees on his userpage. The idea just comes from this extension: http://www.mediawiki.org/wiki/Extension:UserPageStyles However despite the fact that Jim R. Wilson (Jimbojw <http://www.mediawiki.org/wiki/User:Jimbojw>) created it... I find it a little poorly done... It's using a in_array <http://www.php.net/in_array>('sysop', $wgUser->getGroups()) Instead of a $wgUser->isAllowed( 'hideStyles' ); Which also means that sysops are only being considered instead of being able to be extended to staff. And I don't like the fact that other user's styles aren't seen by admins. Not everyone is going to use it harmfully, I want to be able to see the nice things they do to their userpage to. And if i'm styling my own userpage to fix it up so that it's not buggy in looks, or I'm using it to color the background instead of using WikiText hacks, I don't want admins seeing a Messed up userpage because they can't see the custom styles. That defeats the purpose of the extension. Most likely I'd do a few things to do that. Like... Add a &userpagestyles= parameter to force them on or off against the default. Disable the userstyles in edit mode for everyone's userspace/usertalk except your own unless you set &userpagestyles=true. Anyone who wishes to see the styles while editing someone else's page can use JS to append a checkbox with name="userpagestyles" value="true" method="get" to the edit form and they can check it off to let them view it. Also, that &userpagestyles= can be used on the userpages themselves to disable the styles and regain whatever buttons were hidden from you by them. Plus, on the User:Username/style.css or whatever page we choose to use the styles would be disabled as well. So if you have an issue with a user using the CSS harmfully on their userpage. Just hit up the search or the url, to add the /style.css or whatever we choose to use and the styles will already be disabled there. Then as an admin just erase the stuff from the page. (.css pages are already protected, so a vandal can't come in and edit that page to make a user's userpage become screwed up for everyone. It's a great concept, with a little better ideas that could be used to implement it without causing vandalism issues. If you like the idea. I can setup the extension on the Volunteer Development server in the /extensions/wikia folder, and start tweaking it to make it coded right and use better methods of working nicely without being a vandal issue. >> Extension suggestion: The social bookmarking links at the bottom are >> nice. It would be nice to have a set of messages and a parser hook >> that would let us create links that will show up there. >> For a quick example idea on how to do it. Take the Animepedia, there's >> a anime encyclopedia called ANN which is nice to link to. It only does >> summaries, but it's nice for side information that we wouldn't bother >> listing. An example on how it would be setup to allow people to define >> a link that should show up there: >> ==[[MediaWiki:Social links]]== >> Format: * <name/id> <link-url> <image-url> <Hover Text> >> * ann-anime >> http://www.animenewsnetwork.com/encyclopedia/anime.php?id=$1 http:// >> http://images.wikia.com/anime/en/x/xy/Someimage.png ANN Anime >> And on an article, example 1825 is ANN's id for the Anime version of >> Naruto >> <sociallink name="ann-anime">1825</sociallink> >> Of course, you could just use social for the tag, or switch name with >> type. As for the Numbers, in simple terms, the input text would be >> split up by | and used to replace the numbers. >> Of course, bearing that in mind, this example could have gone this way >> using the same extension work. >> * ann http://www.animenewsnetwork.com/encyclopedia/{{lc:$1}}.php?id=$2 >> http:// http://images.wikia.com/anime/en/x/xy/Someimage.png ANN >> {{ucfirst:$1}} >> <sociallink name="ann">anime|1825</sociallink> >> Then we wouldn't need to use 2 separate link types for the links. >> However, that might or might not work depending on if you think that >> there should be one link of each type, or the number of links should >> be the same as the number of tags on the page. >> > Yes, we need to make this customizable for other countries/languages > anyway since their social bookmarking links are different. First goal > was get this out there to play with. ^_^ So 2 goals... A MediaWiki message that lets the actual social bookmarking links be altered to fit countries and languages. And a MediaWiki message and parser hook that lets wiki create custom social links to other sites that are directed at the current page through a parser hook in the page. (Perhaps double that hook with a ParserFunction just incase someone finds some reason to put it in a template. Say, turning my example into a {{ANN|anime|id}} template that takes less typing for the users and is a little more intuitive without adding extra things to do in programming. >> Put V2 of the skins on the volunteer dev server, and I can fix half >> the problems for you on my own in a few hours of my large amount of >> wasted time having little to do. >> >> Side note... That top menu might work pretty nice as a floated one. >> ^_^ You're already using YUI. > Ok, DanTMan.... good stuff. > > John Q. > > >> ~Daniel Friesen(Dantman) of The Gaiapedia, Wikia Graphical Entertainment >> Project, and Wiki-Tools.com ~Daniel Friesen(Dantman) of The Gaiapedia, Wikia Graphical Entertainment Project, and Wiki-Tools.com _______________________________________________ Wikia-l mailing list [email protected] http://lists.wikia.com/mailman/listinfo/wikia-l
