This is the talk page for discussing improvements to the List of JavaScript enhancements page.
- Please sign and date your posts by typing four tildes (
~~~~). - Put new text under old text. Click here to start a new topic.
- If you're new to the wiki, please take a look at the talk page help.
- Be polite
- Assume good faith
- Be welcoming
Scope
I've noticed some of the headers suggest certain types of script are limited to personal. For example, Interface Personalisation states: "These scripts alter the way Wikis look or behave so that it's more to your liking. Only use these in your personal JavaScript/CSS files, do not add them to the Wiki itself." I know this is not true for at least one script in that list. Similarly, Site enhancement suggests most of the scripts are only suited to site-wide installation, which again isn't true. My overall point is that grouping them under headers might make them a little confusing at times.
With that in mind, I'd like to template the entries to look something like this: HeaderLinks[s][p] - <description goes here...>. The usage would look something like this:
{{js-entry
| script = HeaderLinks
| site-wide = yes
| personal = yes
| description = <description>
}}
Thoughts? cqm 09:53, 19 May 2014 (UTC)
- That would make it a lot clearer. I second this notion. -- sqm talk 11:24, 05.19.2014
- You mean remove the headers completely and list all the available scripts in plain list form?
- I am also worried about the size bloat by using the template considering the amount of scripts and the rate at which they continue to increase. Though it would be neat; but huge
- I seriously feel that there is a dire need for another method to organise all the scripts in a way which would be easier to navigate and find for users
- Seperating them into different pages (and tabview) or dynamically generating lists using dpl might work.~UltimateSupreme 16:13, May 19, 2014 (UTC)
- Dpl is another option, but that would require some reworking of the infobox to add a type parameter and a relevant category for dpl to hook onto. Maybe we can make use of dpl's url variables to show a more specific list or some sort of js form to allow us to search for certain names, types, scope, etc? I'll get dpl enabled here so we can explore if it's suitable for what we need. cqm 17:53, 19 May 2014 (UTC)
- I like having a single unified list, but it needs a lot more organization. I've been working on it, and I think it's A LOT more organized now, but it still needs more work. Does anyone have any other ideas on how it can be further organized? Code Lyoko Wiki: User: Deadcoder 18:13, May 19, 2014 (UTC)
- I agree with Deadcoder, that it has been greatly improved in the last couple of months, but it definitely needs to be reworked with a new method to organize it. I don't know the specifics of how DPL works, but I think that the dynamically generated list using DPL sounds like a good option to me. It sounds to me like reworking the template would be worth it to be able to use that method. —RyaNayR (talk • contribs) 22:48, May 19, 2014 (UTC)
- I think DPL might not be a good answer in this case. While its performance cost is acceptable in this case, DPL really only works well in wikis with a very good category system; which, honestly, this wiki doesn't have. This could be fixed, but I don't think it's a good solution to the problem at hand. I think we should continue the current system of tabbing, until a better solution is determined. Code Lyoko Wiki: User: Deadcoder 23:06, May 19, 2014 (UTC)
(reset indent) I think that a DPL solution would be a major improvement over the current system of manually adding scripts to specific tabs. As far as a category system goes this wiki has a very minimalist tree that could easily be expanded upon with very little effort. Another benefit of DPL is the small page sizes and the ability to cache lists/queries in order to conserve server resources. Lil' Miss Rarity ]Open Source[ (talk) 00:54, May 20, 2014 (UTC)
- In reality, the only time we would ever need to uncache the lists generated by dpl is when a new script is published which only requires a simple null edit. cqm 09:14, 20 May 2014 (UTC)
- If we improve the category infrastructure on this wiki, I would be open to using DPL on this page.Code Lyoko Wiki: User: Deadcoder 21:50, May 20, 2014 (UTC)
Rename
I still have no idea why moving pages is disabled for everyone but sysops on this wiki, but this page should probably be renamed to “List of JavaScript enhancements,” since “enhancements” is a common noun and not a proper noun.
―PapíDimmi (talk | contribs) 07:35, July 8, 2016 (UTC)
- It is probably disabled because developers can change pages in the mediawiki namespace, and could potentially break existing scripts all over wikis. Beyond that, page titles do not conform to any grammar rules. People can potentially name them however they want.Dessamator (talk) 09:30, July 8, 2016 (UTC)
- Yeah, you’re right. Anyway, why should page titles not follow any grammar rules? That’s silly.
―PapíDimmi (talk | contribs) 09:32, July 8, 2016 (UTC)- Simply because it makes no sense to enforce grammar rules on titles. For example, if wikiquote has a quote in which the author made a grammar mistake, and the quote is notable exactly because of that grammar mistake, then it makes perfect sense to leave it as is, instead of renaming it. See:
- In fact, a page may be considered grammatically accurate one day and be wrong a few years later as those discussions about Shakespeare note. It still wouldn't make sense to change Shakespeare's books just because they are "grammatically" inaccurate.
- Anyway, back on topic. I think the codeeditor group has still retained the right to move pages, although I'm not really sure.
- Yeah, you’re right. Anyway, why should page titles not follow any grammar rules? That’s silly.
Dessamator (talk) 21:38, July 8, 2016 (UTC)
My apologies for the late reply. Anyway, “Enhancements” should not be capitalized, since it’s not a proper noun.
―PapíDimmi (talk | contribs) 13:19, July 20, 2016 (UTC)
NO TABBERS PLOX
- Do not use tabber. It doesn't work on mobile versions.
- Use a floating TOC and an back to top button on this page for easier navigation.
- I removed the tabbers about a month-and-a-half ago because, as yhynerson1 noted, they're detrimental to mobile users. Furthermore, tabbers cannot be edited using the VisualEditor, and are an annoyance for source-mode editors like myself. ("Wait, where was that redlink again??") There's also that annoying overlapping problem if you have "too many" tabs.
- I get that the other layout wasn't pretty, but I don't think "restoring" tabber was the right solution either. Maybe a "card"-based design would work better? By that I mean something like the one I was experimenting with a few months ago. Either way, I'll refrain from fixing the problem so that we can talk about alternatives.
- DarthKitty (talk) 00:45, July 18, 2016 (UTC)
- I agree that tabbers should not be used on this page. The overlapping tabs look worse than the headers in my opinion.
- I like the Card design, however, the page may become too large (visually) due to the size of the cards and the amount of JS scripts. Perhaps sections of cards could be collapsible? I don't know. Anything another than these tabs is fine with me.
- -- Monochromatic Bunny 15:52, July 18, 2016 (UTC)
- I find simple is better especially since this is just a list. How about some sort of collapsible organization where we put scripts under headers like we do now but instead of using tabbers we just stick them in collapsible lists?
- Do you mean something like this? DarthKitty (talk) 19:13, July 18, 2016 (UTC)
- I think DarthKitty's design should be used. I made a test design, but his is probably better.
- -- Monochromatic Bunny 19:40, July 18, 2016 (UTC)
(reset indent) Okay, I think I'm done tweaking the CSS and stuff. :p Any additional/new thoughts on my mockup? DarthKitty (talk) 21:14, July 18, 2016 (UTC)