Talk: List of JavaScript enhancements

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

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.
―PapíDimmi (talk | contribs) 12:46, July 9, 2016 (UTC)

I don't see any issues whatsoever with the pagetitle. --Sa ju uk 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.
―PapíDimmi (talk | contribs) 13:19, July 20, 2016 (UTC)

Why does it matter if it's a proper noun or not? --Sa ju uk 14:16, July 20, 2016 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ It shouldn’t be capitalized and therefore is grammatically incorrect.
―PapíDimmi (talk | contribs) 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 DISPLAYTITLE 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.
―PapíDimmi (talk | contribs) 18:51, July 22, 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.

yhynerson1 talk 06:34, July 13, 2016 (UTC)

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?

Lil' Miss Rarity ^(message) • 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. 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 useskin=wikiamobile.

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)

A tabber is one means of organising non-sequential information of a large volume. You have not justified how collapsible elements are able to do better job at this than tabbers do, specific to this case. Therefore, until alternatives are proposed which can significantly improve the content display of this article, it would be preferable to readopt the tabber display, especially over the current headings which are certainly not making it easy to navigate. Hackey5 (talk) 10:45, July 31, 2016 (UTC)

@Hackey5 I'll admit, your apparently-working example had me stumped for a few minutes. At first, I thought that Wikia made some change to their mobile skin that fixed the problem. However, a bare-bones test proved otherwise:

<tabber>
|-|Title 1=content 1
|-|Title 2=content 2
</tabber>

Paste that into any page and press the "Mobile" preview button. I'll wait. Adding the selfsame code to my test wiki and useskining made no difference, so I knew this wasn't a case of broken previews.

My next assumption was that you used some obscure trick when "restoring" tabber, one that I didn't know about, to make the titles show up anyway. To test that possibility, I made a copy of this page as it appeared a few weeks ago. Even though both pages (apparently) used the same code, my copy didn't have headers on mobile.

Switching between your example and my copy, however, I noticed something odd: the hatnotes were different! It dawned on me that User:SuperSajuuk tweaked the hatnote after User:Yhynerson1 re-removed the tabbers (see diff). That meant that either your example or my copy was actually using more modern code.

To make a short story long and boring, the mobile skin apparently doesn't support the oldid query string. Instead, you always get the most recent version of a page. You can test it for yourself by clicking on this link (the example you gave), and then clicking on the pencil icon in the top-right corner. You should see the following code:

:'''''Note''': Please visit the [[Help:Advanced CSS and JS|Advanced CSS and JS]] help page for more information on how to use JavaScript and CSS on your wiki.''

<div class="hidden" style="border: 1px solid #ccc; display: block; float: right; margin-left: 0.5em; padding: 0.5em 0.75em 0.25em; width: 155px;">
    <div style="text-align: center;">'''Contents'''</div>
    <ul style="margin-left: 1.45em;">
        <li>[[#Tools|Tools]]</li>
        <li>[[#Site Enhancements|Site Enhancements]]</li>
        <li>[[#Dev tools|Dev tools]]</li>
        <li>[[#Talk Tools|Talk Tools]]</li>
        <li>[[#Wikia Skin Bolt-ons|Wikia Skin Bolt-ons]]</li>
        <li>[[#Editing Tools|Editing Tools]]</li>
        <li>[[#User Management|User Management]]</li>
        <li>[[#Site Integration|Site Integration]]</li>
        <li>[[#Chat Extensions|Chat Extensions]]</li>
        <li>[[#Page and File Management|Page and File Management]]</li>
        <li>[[#Translations|Translations]]</li>
        <li>[[#Non-Recommended Installations|Non-Recommended Installations]]</li>
    </ul>
</div>

This is a list of JavaScript enhancements categorized by type.

That HTML mess is the custom table of contents that Yhynerson1 wrote. Since the mobile skin ignores the __NOTOC__ magic word, I made sure our custom one is invisible there (see diff). If you click on various other pencil icons, you'll see that there are no tabbers. A couple of grammar mistakes that should be present in the old version are also missing (e.g. "a arrow").

tl;dr Tab titles don't work on mobile, and your "example" is actually what the page looks like right now.

Now then, let me reiterate my previous question: Would it be a good idea to break this massive page into several smaller ones?

DarthKitty (talk) 13:28, 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)

This is a really interesting idea, but I'm not sure how it would solve the immediate problem (layout). Even if we create a central repository for scripts, we still need at least one user-facing page to list 'em. Whiiiiiiiich means the tabs-versus-no-tabs debate will rage eternally!!! Mwahahaha...

*Ahem*

I mean, that would be terrible.

DarthKitty (talk) 13:28, July 31, 2016 (UTC)

Personally I don't see any debate, I see one user with 4 edits on the main namespace (all on this page) of this wiki with an opinion that noone else seems to share.

Changing it to be lua generated will definitely end the discussion, because few users can actually write stuff in lua, so they won't know how to fix the issue anyway. Short of reverting it back to its pre-lua version and possibly edit-warring over it. Dessamator (talk) 14:05, July 31, 2016 (UTC)

I entered this discussion because one day I returned to browse for scripts and found the article distastefully difficult to navigate since the tabber had been removed. If that's the case, I'm sure many others would be feeling the same way. I simply decided to have a say about it. My edit count is irrelevant.

Generating data using Lua is a logical step. How this data is presented to the viewer is what I would like to see managed efficiently. @DarthKitty, thanks for identifying the discrepancy in my claim earlier. To answer your question, I always think it is best to confine relevant information to one primary source where it can be easily viewed and managed. Splitting things between multiple pages just makes it more difficult for viewers to navigate and find things. I prefer the use of a tabber here because it keeps relevant information close together with browsing being a simple and minimal-scrolling process, essential for those seeking to find suitable scripts among a boatload. Now, there seems to be a concern due to a lack of generated headings, and I'm assuming Wikia haven't created a class that can be applied to elements so they can be viewed on mobile only, which would solve that issue. Unsolved, I personally do not find it pressing, as I explained earlier, with this wiki likely to be hosting far more PC technical editors than casual mobile viewers, although I imagine that my argument wouldn't weigh up for those insistent on universally optimal functionality. In that case, I emphasise that whichever layout option is decided on is equally convenient for the viewer. Headings nor collaspsible elements in their currently suggested forms achieve this. I would be interested to know how @Dessamator intends to have this article's content presented under a new page design, in addition to the handling of the content itself as previously mentioned. Hackey5 (talk) 15:11, July 31, 2016 (UTC)

> My edit count is irrelevant.

Edit counts are irrelevant but the nature of the edits are very relevant. If someone claims that they know what's best for a page they've never edited people will certainly be skeptical, regardless of how skilled they may think themselves to be.

Furthermore you stated that "It is irrelevant that editing might be made slightly more tedious for editors". This comment is made about a page you only edited to push your point of view. Wiki pages are a balance between the needs of editors and the needs of readers, and few users would likely edit any page if it was filled with unintelligible markup.

>I would be interested to know how @Dessamator intends to have this article's content presented under a new page design

Well, the page would be improved in stages. The first stage would involve importing all data about scripts to a lua module. The second would involve moving content that is is irrelevant for an average reader such as non-working scripts to a separate page, and possibly incorporating some of Shining Armor's ideas[1] to improve the layout. Finally, the last stage would involve an assessment of whether separate pages and tools such as collapsible sections and so forth are still necessary, and if so they'd be incorporated into the design. Dessamator (talk) 08:14, August 1, 2016 (UTC)

I clarify my statement, it is of lesser significance that editing be made slightly more tedious for editors in terms of being prevented from using the VisualEditor and having to scroll through the source editor than being able to click into heading sections, in comparison to viewer convenience. I will certainly push my point of view and justify my points accordingly. However, I would like to see productive changes actually implemented. Bringing up Shining Armor's October 2015 thread, those are indeed some good suggestions, yet, following months after its creation, few of them have been implemented. I understand that proceeding to change significant aspects myself will likely lead to complaints, so I am taking the time to discuss suggestions beforehand. Here, I do wish to carry out the proposed translations and non-recommended installations changes, as well as changing 'co-installable' to 'general'. If no one is opposed, I can get to it and tweaks can be made afterwards where necessary. At least it is one step in the right direction before we proceed to undertake a design overhaul of some sort. Talk is good, but it amounts to nothing without resulting action. Hackey5 (talk) 09:27, August 1, 2016 (UTC)

@Hackey5:

Bringing up Shining Armor's October 2015 thread, those are indeed some good suggestions, yet, following months after its creation, few of them have been implemented.

The reason for that was simple, Shining armor made suggestions but didn't followup on it, and didn't even reply to another user's comment. Also, the author labelled it as a rant, and didn't even add a link to the talk page which is the "appropriate venue" for discussing changes to an article. Heck, you don't seem to have noticed it until recently, despite the fact that it was below the article (and I added that link long ago).

Here, I do wish to carry out the proposed translations and non-recommended installations changes, as well as changing 'co-installable' to 'general'

Agreed. Dessamator (talk) 09:39, August 2, 2016 (UTC)

Take another look at the "Translations" section: some of the scripts listed there have i18n'ed descriptions. The problem with @Shining-Armor's proposal is, those descriptions would have to be removed—at that point, only English-speakers could browse for new scripts.

I think a better idea would be to create a new page for each language, e.g. List of JavaScript enhancements/es. Then we could use Template:Languages for navigation. This is how scripts like AjaxBatchDelete are organized, and I think it would let us remove redundant links.

I think we should probably remove the so-called "non-recommended installations" from these pages. If we don't want people to install old scripts, why list 'em? Maybe we could use a tracking category to organize the outdated stuff, something like Category:Deprecated modules.

We could probably get rid of the "expanded list" section, too. There's no reason to list CSS on a page called List of JavaScript enhancements, and @Dessamator's database plan might make the JavaScript bit redundant. Speaking of databases, this is what we're looking at so far:

{
    {
        name = "",
        description = {
            en = "",
            (...)
        },
        deprecated = false
    },
    {
        name = "",
        description = {
            en = "",
            (...)
        },
        deprecated = false
    }
}

Does that sound all right? DarthKitty (talk) 12:50, August 2, 2016 (UTC)

Threw together another mockup, in case I didn't explain that very well. I think it's a little better than the current version! DarthKitty (talk) 13:00, August 2, 2016 (UTC)

Yes, separate pages i18n for "Javascript enhancements" would make sense. Right now it is a confusing mix of several languages.

> I think we should probably remove the so-called "non-recommended installations" from these pages. If we don't want people to install old scripts, why list 'em? Maybe we could use a tracking category to organize the outdated stuff, something like Category:Deprecated modules

Agreed. Over time, deprecated scripts should be re-evaluated and deleted if there is no need for them, or possibly if they contain security exploits that were discovered later on (and no one is willing to fix them). Also, since this is stored in a structured format, it would be trivial to make it "re-appear" once it is useful. For example, an experimental script may eventually be completed, and be ready for use.

The database also requires a field for type or category of the script , e.g. "site enhancement", "dev tools", etc . It also requires scope.

{
    {
        name = "",
        description = {
            en = "",
            (...),
        type = "Site enhancements",
        scope = ""
        },
        deprecated = false
    },
    {
        name = "",
        description = {
            en = "",
            (...),
        type = "",
        scope = ""
        },
        deprecated = false
    }
}

Although, well probably need some validation for types to avoid typos, so it might make sense to use a separate data module to define allowed types.

Later on we'll probably change the infobox javascript to use the values from the lua module, if the user hasn't overwritten them. Dessamator (talk) 14:00, August 2, 2016 (UTC)