Group Tabs

[Jey-Cee]

Is your feature request related to a problem? Please describe. Loss of overview as more and more Adapter uses this feature.

Describe the solution you'd like Add tab groups for better overview.

Describe alternatives you've considered None.

Additional context Possible group could be adapter administration, where tabs like the zigbee one can be groupped. This tab is for zigbee device admanistration and not for instance configuration. As head tab we can use the Adapter tab and as sub tabs instances, zigbee,...

[DutchmanNL]

I like it, we should consider the grouping. One option could be:

• Core elements (like objects/adapter)
• Managing of devices/core functions (like Zigbee/zwave/esphome)
• others

[Garfonso]

One idea would be to add a new property "tabCategory" with a few predefined options and use this in the UI to automatically group the tabs.

[UncleSamSwiss]

How about by default simply grouping it by the already existing common.type in io-package.json (example)?

The user can then still edit the grouping somewhere if he want to.

[DutchmanNL]

How about by default simply grouping it by the already existing common.type in io-package.json (example)?

I think that would create to much groupings and for end-user perspective (not knowing ioBroker or the background) I don't see an added value one reason I suggested to keep it on 3 layers (core {always}, grouping for device management, others)

lets have an example look how I made this at my Docu page, I would suggest to keep it as simple as possible but very clear for endusers. Mostly they are already overwhelmed by the complexity of ioBroker the gun should close the gap

[Apollon77]

There is one topic that speaks against the grouping ... Admin 5 allows manual sort ... and as soon as a user is doing this all grouping will become very difficult when we add a new tab beause the first manual sort action of the user will kill the grouping. Anyone an idea on how to come around that?

[Apollon77]

Only thing in my eyes would be to have two categories of tabs and also separate them in the list.

First os Admin own tabs and "core functionality adapters" like Javascript, Devices, Scenes and such (yes we need to draw the line). And then have a separator line in the list and all other "normal adapter tabs" are the second category. Both lists are sortable (in it's own, not overlapping). This could work in my eyes.

The challenge is to draw the line between "core functionality" and "other adapters"

[DutchmanNL]

There is one topic that speaks against the grouping ... Admin 5 allows manual sort ... and as soon as a user is doing this all grouping will become very difficult when we add a new tab beause the first manual sort action of the user will kill the grouping. Anyone an idea on how to come around that?

As I suggested, make 3 main groups (or 2) and allow movement within that groups as an option to the enduser

mandatory things (Objekt, Adapter, instances) should always be on top or part of main