Confusing aspects of CMS tab management

[sminnee]

This is a bit brief, writing it up as a partial diagnosis of some frustration of @chillu...

• The CMS editor shows "Content", "Settings", and "History" as 3 things that look like tabs, but they're not actually Tab objects in a FieldList, they map to 3 different controller actions
• SiteTree::getCMSFields() includes a Tabset "Root", with 1 tab "Main" by default.
• It's labelled "Main Content"
• But if you only have 1 tab, then the tab is excluded altogether
• But if you have 2 or more tabs in there, they get shown below the content tab.

This leads to really confusing situations, like, if you try and add something to "Root.Content" instead, you get this:

From memory, the root source of this confusion was the maintenance of backward compatibility through the SS2 -> SS3 UI changes. But it's definitely counterintuitive for developers looking to customise the CMS!

[clarkepaul]

I've done a few experimental designs in the past to try reduce the confusion of the tabs. In these examples I removed the top tabset in the toolbar and replaced it with an icon for settings and another for history (effectively removing the content tab). Then we would only have one "Content" tab if a developer was to create a second set of tabs.

I wasn't sure about the interaction of the settings and history though, could navigate away, popover, another panel, but reduces tabs. For this I actually also put page name and URL stuff under settings. This leaves a page being more about content only.

The other experiment was to use the same pattern that we use on blocks for the page itself. Moving settings and history (and any other top level tab) into a more options dropdown and presenting a link to edit page name and URL. Theres some issues in the UI with this though as we have another set of "more options" in the south toolbar so they'd need to be combined.

I should say that these designs were done to reduce the clutter of a page which holds content blocks and fix a UX issue with tabs.