[RFC] Combine style and extension management in ACP

[imkingdavid]

Related links:
Ticket
Pull Request
IRC Discussion

Currently, the extension management module is hidden in the middle of the list of modules under the System tab. Personally, I feel that is not intuitive from a UX standpoint, since if I were looking for the extension management module, System is not the first place I would look. Granted, none of the current tabs are the first place I would look ( ).

As a solution, I think that we should rename the current Styles tab/category to "Customise" or "Customisation". Within that category, we can house the Styles management area and the Extensions installation area.

- This would keep us from having related modules in unrelated categories. I do not see how Extensions relate in any way to the other items in the System tab.
- The Styles tab currently only has 3 modules, which is almost not enough to give it its own tab. Renaming it and adding another module or set of modules would give it more purpose
- IIRC, we plan on eventual integration between the ACP and the Customisations Database for easy remote installation of extensions and/or styles. By grouping them together now, we make that integration a more fluid process because it's all in one place.

Thoughts?

[Meis2M]

+1 good idea

[Senky]

Hm...you idea is fine, another one I think of is to do it in the same way as it is now - we have .MODS tab, so why not to rename it to Extensions, and use it?

[Vinny]

Absolutely yes, I loved the idea. But why not a full integration? I mean:
- Extension Management
--- Extension
--- Styles
--- Language Packs
--- ...

Since the plan is to integrate the CDB with the extension management module.

[EXreaction]

Hm...you idea is fine, another one I think of is to do it in the same way as it is now - we have .MODS tab, so why not to rename it to Extensions, and use it?

The .Mods tab should not be renamed. Many db installers rely on the .Mods tab to automatically add modules, this would break backwards compatibility for some mods that otherwise would work fine on 3.1.

I think .Mods should stay as it is, if it's never used it'll never be displayed. I would guess that some authors may still like to use the .Mods tab for their extension's acp modules.

Part of the reason for renaming the Styles tab is because there are currently only 3 modules in there right now, which seems to be rather few to warrant it's own tab, renaming it to Customisations would allow us to put extensions management and possibly other things in there as well.

[MichaelC]

Adding a new Customisations Tab, then have a management category for the Extensions Admin and Styles.

Then contributions should add modules under the customisations tab when its only a couple of modules (if its a lot then it could warrant its own tab).

.MODs shouldn't be added on any new installs but it should not be touched when updating.

[EXreaction]

Like I said above, removing or altering .Mods will break compatibility with some mods that would otherwise work perfectly. There is really no reason to do it.

[Senky]

Okay. Then new Customisation tab is +1

[nickvergessen]

Like I said above, removing or altering .Mods will break compatibility with some mods that would otherwise work perfectly. There is really no reason to do it.

This

[brunoais]

I say +2 for adding a new tab for the whole extensions. In that tab, (by default) the 1st thing there is to configure the extensions (somewhat, or like Unknown Bliss said).

+1 for the idea in the OP post.