Talk:List of JavaScript enhancements

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] - . The usage would look something like this:

Thoughts?


 * 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.~Ultimate Supreme  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.


 * 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.


 * 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.


 * 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. ― <font color="#0000A0">PapíDimmi  <font color="#571B7E">( <font color="#4AA02C">talk | <font color="#4AA02C">contribs <font color="#571B7E">)  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:
 * https://www.scribendi.com/advice/movie_quotes_that_are_grammatically_incorrect.en.html
 * http://theweek.com/articles/465231/9-famous-quotes-that-are-technically-grammatically-incorrect
 * 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.

Dessamator (talk) 21:38, July 8, 2016 (UTC)
 * Of course direct quotes shouldn’t be changed. A page on a public wiki should, though. This is not an extension page, so grammar should matter in the title. <font face="Papyrus"><font color="#0020C2">― <font color="#0000A0">PapíDimmi  <font color="#571B7E">( <font color="#4AA02C">talk | <font color="#4AA02C">contribs <font color="#571B7E">)  12:46, July 9, 2016 (UTC)
 * I don't see any issues whatsoever with the pagetitle. --Sajuuk 18:42, July 9, 2016 (UTC)
 * My apologies for the late reply. Anyway, “Enhancements” should not be capitalized, since it’s not a proper noun. <font face="Papyrus"><font color="#0020C2">― <font color="#0000A0">PapíDimmi  <font color="#571B7E">( <font color="#4AA02C">talk | <font color="#4AA02C">contribs <font color="#571B7E">)  13:19, July 20, 2016 (UTC)
 * Why does it matter if it's a proper noun or not? --Sajuuk 14:16, July 20, 2016 (UTC)

It shouldn’t be capitalized and therefore is grammatically incorrect. <font face="Papyrus"><font color="#0020C2">― <font color="#0000A0">PapíDimmi  <font color="#571B7E">( <font color="#4AA02C">talk | <font color="#4AA02C">contribs <font color="#571B7E">)  22:03, July 20, 2016 (UTC)


 * It sounds like there are two good reasons to rename this page, then:
 * It will keep pedants like PapiDimmi happy.
 * It will put an end to this debate, and the related  edit war.
 * DarthKitty (talk) 23:51, July 20, 2016 (UTC)
 * Done. --Saftzie (talk) 02:44, July 21, 2016 (UTC)


 * Incorrect; there was one good reason to rename this page: it was grammatically incorrect. ’Course it made me happy; I’m a god damn grammer god. I never make any grammatical mistakes. <font face="Papyrus"><font color="#0020C2">― <font color="#0000A0">PapíDimmi  <font color="#571B7E">( <font color="#4AA02C">talk | <font color="#4AA02C">contribs <font color="#571B7E">)  18:51, July 22, 2016 (UTC)

NO TABBERS PLOX
<span class="button" style="background:#03c;color:white;border:none;border-radius:0;padding:0 0.4em;border-right:1px solid white">yhynerson1 talk  06:34, July 13, 2016 (UTC)
 * 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?


 * <div style="display: inline; background-color: #012E53; border: 0px solid #012E53; padding: 4px; text-align: center; border-radius: 4px; color: #FFFFFF; font-weight: bold;"> Lil' Miss Rarity (message) &bull; Monday, July 18th 2016, 17:39


 * 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)


 * I prefer the module cards cards over collapsing boxes. <span class="button" style="background:#03c;color:white;border:none;border-radius:0;padding:0 0.4em;border-right:1px solid white">yhynerson1 talk  16:27, July 23, 2016 (UTC)


 * @Yhynerson1 - You probably should have discussed your ideas on the talk page before changing the layout. We were already discussing alternate designs.


 * Anyway, I still prefer DarthKitty's design, and I think we should go through with implementing his layout.
 * -- Monochromatic Bunny 18:49, July 23, 2016 (UTC)


 * The tabber interface is the easiest to use among these suggestions, primarily because it prevents the need for scrolling which with the abundance of content items is incredibly tedious. Tabbers do not load on mobile but it is no different than using basic headings. Collapsible divisions do not work on mobile either. Moreover, any viewer interested in installing scripts on their wiki would very likely be accessing the wiki using a PC, and if not, the mobile full site option would almost always be resorted to where tabbers remain functional. CSS can be used to fix the sloppy default layout that has the tabs overlap when exceeding one line. Subheadings can be used to edit specific sections.
 * Hackey5 (talk) 05:01, July 29, 2016 (UTC)


 * CSS shouldn't have to be used as a workaround due to the tabber's "sloppy default layout". The simplicity of headers and/or collapsible boxes is better in my opinion. Also, scrolling on this page won't be tedious due to navigation elements that can be used. —Monochromatic Bunny | ☎ 04:32, July 30, 2016 (UTC)


 * The statement "tabbers do not load on mobile but it is no different than using basic headings" is provably false. Basic headers are visible on the mobile skin, while tab titles are not. You can test it for yourself with the mobile preview button, or by using the query string.


 * Additionally, the mockup I made a few weeks ago takes up less vertical space than the most recent, tabber-based layout. If scrolling is your problem, then my suggestion is currently the best solution. Though honestly, I think this page will always be "too long", since we're trying to list every script ever. I wonder if we could break it up, somehow...?


 * DarthKitty (talk) 05:44, July 31, 2016 (UTC)


 * I do not understand this unwillingness to use tabbers. In fact, tabber titles are visible as shown here for the mobile display. Therefore, it does not matter which display is adopted for mobile as they will all be rendered the same with plain headings. For PC, however, the tabber display is the easiest display to navigate. All tab titles are visible with which the viewer can select any to access its content. Sometimes down-and-up scrolling is necessary for long items, but that is all the scrolling one must perform, and any tab title can be readily selected from the same location on the page. Collapsible elements scatter the headings down the page, making it more difficult to locate and navigate items, not to mention having to expand and collapse each section which requires even more scrolling and tedious fidgeting. This is not simple, this is not efficient, this is not easier. The only advantage I see to collapsible elements in this instance is that collapsed, they neatly hide all content. Otherwise, tabbers among these display options benefit viewers the most.
 * It is irrelevant that editing might be made slightly more tedious for editors. It is their responsibility to use the source editor (the VisualEditor being incompatible is not an excuse) to the necessary extent to add their scripts to the article. Ease of access for viewers takes precedence. Hackey5 (talk) 07:43, July 31, 2016 (UTC)

It seems like scrolling in general is tedious to you, but it's a normal part of any website. The collapsible boxes design has minimal scrolling; you can collapse the box if you think the page is getting too long. Also, would you suggest all pages use tabbers? You included that the headers are scattered down the page, but most pages on wikis use headers to organize information. —Monochromatic Bunny | ☎ 08:13, July 31, 2016 (UTC)

Store data and display page data in a structured format using lua
Personally, I'd suggest scrapping the whole design of this page, and generating it with lua. This is the developer wikia so there should theoretically be no lack of technical expertise, and all data on this page is structured and can be stored in a data module. This has some benefits, for instance we can store data about the authors of the scripts, the categories, and automatically update it and the documentation page's infobox with author information or link to scripts that share the same "category".

This would also make it easy to document the scripts without needing to add information to 2 pages, the script  page, and this one. Documenting in two places also means double work, and the fact that the docs can fall out of sync when changes are made, or the script is deleted for instance.

Generally speaking, few developers (at least I don't do it often) seem to take the time to add their scripts to this list. Dessamator (talk) 08:21, July 31, 2016 (UTC)


 * Well, that's a new take on it. I'm open to anything, besides tabbers, for this page. Your idea increases accuracy all across the board, so I support it. —Monochromatic Bunny | ☎ 08:34, July 31, 2016 (UTC)