Feedback on "Reintroduce Tabs"

[madsrasmussen]

In Umbraco 8, we introduced several new features and UI updates. We got Content Apps, Language Variants and split view. In the transition, we also moved from a tabbed content editor to a grouped content editor to provide what we saw as the best editing experience when working with variant content. After a lot of feedback, we have heard your wishes, and it is now time to bring the tabs back.

When we bring tabs back, we don't "just" want to revert to the previous editing experience. We want to make sure we handle the challenges that caused us to change the tabs to groups in the first place. Therefore we want to keep the groups, but add tabs as an optional extra layer of organization.

The combination of tabs and groups will provide the necessary level of organization to keep the number of tabs to a minimum, so we don't run into the problem of content nodes with a large number of tabs again.

Set up Document, Media and Member types.

When you open the doctype editor, you will notice a new bar where you can add tabs. If you don't need them, you don't have to use them. That also means that all upgraded sites will work the same. You can add tabs to a doctype or reorganize existing doctypes if needed.

Setting up tabs on a doctype:

Doc.types.-.Adding.tabs.+.validation.mp4

The data structure

Tabs are built on top of the current property group data structure: when you add a new tab they are stored in the same database table (cmsPropertyTypeGroup). We can't use integer IDs to build the relationships in AngularJS and therefore will use keys/GUIDs to reference each other using a parent key. This could in theory allow for unlimited nesting possibilities, but the UI will restrict it to tabs and groups. A property has also been added for an icon (including color) and because both tabs and groups can be added directly on the doctype, the new level property stores how it should be displayed (level 0 = tab, level 1 = property group). We only have to explicitly check the level whenever the parent key is not set, otherwise the level should be implicitly derived from the parent groups level + 1. See data structure presented as JSON:

{
 "name": "My Doc Type",
 "alias": "myDocType",
 "groups": [
   {
     "id": 1,
     "key": "GUID-1",
     "name": "Tab 1",
     "icon": "icon-document black",
     "parentKey": null,
     "level": 0,
     "sortOrder": 0
   },
   {
     "id": 2,
     "key": "GUID-2",
     "name": "Group 1",
     "parentKey": "GUID-1",
     "level": 1,
     "sortOrder": 0,
     "properties": [
       {
         "id": 1,
         "name": "Property 1",
         "alias": "property1",
         "sortOrder": 0
       }
     ]
   }
 ]
}

The following structures are possible using this approach:

• Only groups with properties (current/default)
• Only tabs with properties
• Tabs containing only groups with properties
• Tabs containing both properties and groups with properties (this seems weird, but has its use-cases and is also required because of compositions/inheritance)

We initially agreed upon using a 'special' value as parent key, e.g. null = group and 00000000-0000-0000-0000-000000000000 = tab. Besides not being completely clear, we can't enforce a foreign key constraint to ensure we don’t end up with orphaned groups.

In our current version, we use a nullable, self-referencing parent key column with foreign key constraint and a generic level column (0 = tab, 1 = group) - which also allows for future extension, e.g. level 2 = fieldsets (horizontal groups, like zipcode/address, first/last name, etc.).

Package XML (export/import) and deployment

Because the data structure only adds new properties (parentKey, level, icon), existing package.xml/exported UDT-files should be backward compatible. Importing data from older versions will only create groups, so this will create the same structure as before (and thus the same as when migrating an existing site to the newer version). Exports from newer versions containing tabs won’t be officially supported on older versions though, but it should import tabs as groups (as older versions don’t know about the new properties).

The XML format has a few caveats: groups are stored in the element and are referenced by name, so tabs/groups will need to have unique names (currently groups are merged by name, but the new structure allows the same name in different levels). We will include new elements to support the new structure:

<DocumentType>
   ...
   <GenericProperties>
      <GenericProperty>
         <Name>Property 1</Name>
         <Alias>property1</Alias>
         <Key>...</Key>
         <Tab>Group 1</Tab>
         <ParentKey>GUID-2</ParentKey> // NEW
         ...
      </GenericProperty>
   </GenericProperties>
   <Tabs>
      <Tab>
         <Id>1</Id>
         <Key>GUID-1</Key> // NEW
         <ParentKey /> // NEW
         <Icon>icon-document black</Icon> // NEW
         <Level>0</Level> // NEW
         <Caption>Tab 1</Caption>
         <SortOrder>0</SortOrder>
      </Tab>
      <Tab>
         <Id>2</Id>
         <Key>GUID-2</Key> // NEW
         <ParentKey>GUID-1</ParentKey> // NEW
         <Icon /> // NEW
         <Level>1</Level> // NEW
         <Caption>Group 1</Caption>
         <SortOrder>0</SortOrder>
      </Tab>
   </Tabs>
</DocumentType>

Umbraco Deploy already generates UDA-files that use nested properties and GUID-keys, so this only requires exporting the new properties:

{
  ...
  "PropertyGroups": [
    {
      "Key": "GUID-1",
      "Name": "Tab 1",
      "ParentKey": null, // NEW
      "Icon": "icon-document black", // NEW
      "Level": 0, // NEW
      "SortOrder": 0,
      "PropertyTypes": []
    },
    {
      "Key": "GUID-2",
      "Name": "Group 1",
      "ParentKey": "GUID-1", // NEW
      "Icon": null, // NEW
      "Level": 1, // NEW
      "SortOrder": 0,
      "PropertyTypes": [
        {
          "Key": "...",
          "Alias": "property1",
          "Name": "Property 1",
          "SortOrder": 0,
          ...
        }
      ]
    }
  ],
  "PropertyTypes": [],
  "__type": "Umbraco.Deploy,Umbraco.Deploy.Artifacts.ContentType.DocumentTypeArtifact",
  "__version": "4.2.0"
}

Content editing

When editing content, we discussed two different versions of how we could implement tabs. The first approach is similar to the Matryoshka package. We add an extra navigation bar underneath the editor header (See package for details). The second approach is to combine the tabs with the Content Apps navigation.

After we tested both concepts, we went with the second one. With one unified navigation for content editing, we achieve the simplicity we strive for in the back-office.

Content.section.-.tabs.mp4

Validation

Validation uses the badge system we already have for Content Apps. If one of the tabs contains a validation error, it will show a bouncing badge.

Current tab with validation error

Other tab with validation error

Split view

Currently, the split view only allows editing of the "Content" Content App. With these changes it will be possible to open any tab/app in the split view.

Content.Section.-.Split.view.+.validation.mp4

Block List Editor + Nested Content

The concept is still in the workings, but the general ideas are:

Block List Editor
The Block List Editor will work like the Content Editor. We will add the new tabs as part of the header where the current “Content” and “Settings”-tabs are. With inline-editing enabled, we can show the cog if there's more than 1 tab (similar to how the cog appears when settings are available).

Nested Content
Nested Content would mostly work the same. You pick which group to show from a dropdown (in the editor config) and tabs would be part of that. Nested Content will render properties added directly under the group or tab.

What will happen to Content Apps?

Content Apps will stay the same and will work like they always have. The only differences are that tabs will swap places with the current "Content" Content App and the full navigation will be available in split view.

Brainstorm of ideas and further improvements

With the new combined Content Apps and tab navigation, we have opened up some new ideas that might make sense for future improvements.

• Could we show all registered content apps for a given type in the doctype editor (within the new tab bar)?
• List views are also content apps. Could we move the configuration into the new tab bar? It would then be easier to change the icon, the name and set the sort order of a list view, possibly in-between other content tabs.
• Allow drag and drop of groups to the tab bar for fast conversion.

Final question. Do we call tabs for apps or what do we do with naming? (discussion about renaming Content Apps)

Current prototype (WIP):

• Doc type editor mostly working
• Content Editor is still a giant hack to test the concept :)
  v8/dev...v8/prototype/doctype-tabs

[soreng]

I guess it would be a good time to also rethink how "Content Apps" (other than the "content" content app), could add more tabs, or if they should be renamed somehow?

#10399
#8863

[skttl]

Love that you are putting "tabs" up with the content apps. I've always wanted to do that for Matryoshka.

I think everything looks great, and I can't wait to use it.

Are you going to change anything in the split view implementation? I've been wanting to experiment with opening the previewer in a split view, but it seems like its pretty hard coded to work with the content app.

[nul800sebastiaan]

@skttl Yes! So the video under "Split view" shows you it will work with all the tabs, and maybe Content Apps as well, not sure about that one @madsrasmussen?

[madsrasmussen]

No current plans to change the split view implementation.

Without starting a new discussion here, I personally like the idea of syncing another browser window better than having preview in split view in the cms. Maybe there is room for another topic about that :D

[craigs100]

@skttl, I'm really glad you didn't (put tabs with conten(x)t apps) ;)

[BatJan]

Wow! This looks really good 🤩 Love the progress you've made with it 👏🏻

[ronaldbarendse]

How to migrate existing sites to/from tabs?

Regarding easy conversion from groups into tabs, using drag and drop within the doctype editor would be great UX wise (this is listed as future improvement). If you have a lot of existing doctypes, this will be a lot of manual editing though... So I've created a SQL query to do exactly this (based on the current prototype, be sure to recycle/restart your site after executing to clear the cache):

UPDATE [cmsPropertyTypeGroup] SET [type] = 1 WHERE [type] = 0 AND [parentKey] IS NULL;

If you want to (safely) undo the above and convert tabs back into groups, the following SQL query can be executed (again, recycle/restart your site after running this):

UPDATE [cmsPropertyTypeGroup] SET [type] = 0 WHERE [type] = 1 AND [parentKey] IS NULL AND [uniqueID] NOT IN (SELECT DISTINCT [parentKey] FROM [cmsPropertyTypeGroup] WHERE [parentKey] IS NOT NULL);

Batch conversion will mostly be relevant to upgraded sites, as it will keep the current property groups to ensure backwards compatibility. We don't want to add additional settings to default to tabs instead of groups, as you'd need to set this before doing the upgrade and this would break compatibility/consistency when importing document types from older installs (e.g. package XML without explicit type set on the property group).

If you have any thoughts on how we can make the conversion between groups and tabs as easy as possible, please share them here...

[ronaldbarendse]

Also: converting tabs back into groups will be a bit more difficult, as we don't want to end up with a third, currently unsupported level (if the tab already contains groups). It's always possible to create a new group and move the properties from the tab to that group, but this is again a lot of manual work.

[ronaldbarendse]

I've updated the SQL queries to use the new type column, as the implementation has changed a bit: #10488 (comment).

[ronaldbarendse]

The final implementation will only require changing the type column, so a safe way to convert all groups into tabs will be to execute this SQL query:

UPDATE [cmsPropertyTypeGroup] SET [type] = 1 WHERE [type] = 0 AND CHARINDEX('/', [alias]) = 0;

[patrickdemooij9]

Looks like a great change! However, I am just worried about websites that already have quite a few content apps listed. For one of our websites we installed uMarketingSuite and TranslationManager which gives us 4 content apps. I feel like this together with the tabs could easily overwhelm the user. I wonder if we could fix this by grouping multiple content apps together somehow? Maybe a group uMarketingSuite would show the 3 content apps when hovering over? Or should package developers try to fit everything in one content app?

[ronaldbarendse]

The content apps will overflow into an ellipsis/more menu when they don't fit anymore (like you see in the split-view demo), but I agree that's not the most ideal solution if you have many apps/tabs.

Having properties for SEO and settings on their own tab/app makes sense, especially since you can still use groups: you want the mostly used/edited properties in the first tab (which you probably name Content) and 'offload' all secondary/more advanced to other tabs. I wouldn't recommend adding tabs for parts of the page, like header, body, footer, etc.

[benjaminc]

I think that is something that would need to be managed by whomever is developing the site. Tabs have to be explicitly added, so when doing so the designer/developer of the document types need to consider what content apps are currently shown for a given document type, and set it up accordingly. I am a fan of keeping them up with the content apps, as I think three layers of tabs (section, content apps, property tabs) is just too much.

[patrickdemooij9]

I do agree with that, but sometimes you don't really have a choice if you are using multiple packages that utilize the content apps.

I would love to have the ability to merge multiple content apps together and have the same functionality as 'More' where it would then show the grouped content apps.

[benjaminc]

Yeah, I would love to give the site designers more control over which content apps show up, and how, rather than just leaving it entirely to the package developers. I think the package designers should be able to put in defaults, but site designers should be able to reorder or disable content apps that shipped with a package, and do so in a way that won't be overwritten the next time the package updates.

[ronaldbarendse]

We've changed our direction (check #10488 (comment)), so the initial feature won't display tabs as Content Apps, but in a bar inside the current Content app. This should address the issues mentioned here, while still being able to implement the original idea in the future. Thanks for all your valuable feedback! 🙌🏻

[patrickdemooij9]

Another thing that I would like to see here as we move content apps closer to tabs is to make them not show up on split view. What if I have a content app that doesn't care about the variation of the content (language or segment)? Currently I would still be allowed to open it up in split view even though it'll just be a duplicate of each other.
Maybe we could add another property to content apps to determine if they show up on split view or not. Would also help with some of the unnecessary cluttering

[ronaldbarendse]

How to handle removing tabs/groups?

If you currently remove a group, it will remove all properties it contained. Because it's now possible to have properties directly on a tab: should we move the properties to the containing tab when a group (within a tab) is removed? And the same for removing tabs: should we move the containing groups directly to the doctype (and fall-back to the default 'Content' tab)?

Removing the last tab should at least ensure the groups are moved directly to the doctype, otherwise it won't be possible to revert from tabs back into 'groups only', right?

[dalyUSN]

Great to see that Tabs are on their way back. We love using Matryoshka and it'll be great to see that type of functionality back in the core. Also happy to see a discussion about renaming 'Content Apps'.

However, really not sure about that placement up next to 'Content Apps'. Node-based content should really live together with the tabs. Sitting them up next to the 'Content Apps' doesn't work well from a content editors UX flow.

When 'Content Apps' were introduced they were positioned in the top right to keep them outside of the main content area so they did not distract from the main content since it was for supporting data/content.

• Has there been much user testing on their placement there?
• Is there a reason why Core doesn't try to adopt a more 'Matryoshka' style approach to tabs placement?

[dalyUSN]

Just to add to this, I found an article about 'Content Apps' from when they were introduced. You see from the screenshot and link (https://umbraco.com/blog/umbraco-8-content-apps/) that the positioning of "Content App is not directly part of the editing experience".

Really believe the tabs for content editing are better placed within the current content area.

Thanks

[mattbrailsford]

I was going to write my own response, but I think this covers a lot of the points I was going to make.

Additionally, when I was re-implementing Fluidity in v8 (which I never released) I gave the ability to have tabs in the content apps section, but I quickly found that these became noise when there were too many competing options.

I do wonder though whether these all should be configurable as they all have a natural hierarchy and would give more power to the organisation of content.

1. Content app tabs -> Over-arching concepts
2. Tabs -> Sub division of those concepts
3. Fieldsets -> Field grouping for related fields

Probably out of scope for this discussion, but I do also wonder whether things need to be thought of from a higher perspective as I wonder if there are new concepts to consider (for example, in Vendr, our variants editor is a property editor that can demand it's own content app because it's such a complex property editor).

[ronaldbarendse]

Your feedback has been heard and we've updated our direction for the initial feature: #10488 (comment) 👍🏻

We also want to make sure Matryoshka still works when we introduce this new feature, so you're not forced into using the native tabs (e.g. if you have duplicate tab/group names, use the group separator descriptions and/or collapsible states).

[skttl]

I'm probably going to do some kind of Matryoshka > native tabs/groups migration package though, don't want to support Matryoshka more than necessary :)

[MMasey]

This looks fantastic! We add Matryoshka to every single project, and seeing this iteration of tabs looks like an improved version of that. One thing that I'm sure is already on your radar is making the tabs menu sticky when editing the doctype to potentially make it easier to move properties or groups to different tabs. (I'm aware that this is more complex than it seems, but it would be good to see). Another thing to note is to try and make the reordering of the properties and groups possible with the keyboard. This would be a huge benefit to both keyboard and power users.

In addition, will this have any implications on how compositions work, is a tab had it's own guid etc. For example what is I want multiple compositions that use the same tab name and I want to essentially configure multiple doc types with different compositions that all use the same tab name. (Apologies if this has already been answers and I've missed it)

[ronaldbarendse]

Making the tabs bar sticky was also one of my first reactions when seeing the video, so your suggestion confirms we should look into this 👍🏻

You can already reorder the properties/groups/tabs using the number input/spinner (not sure if it directly updates the UI though), but ensuring you can also move between groups/tabs using the keyboard would be a nice bonus. Any idea how this could be achieved, using keyboard shortcuts, context menu or something else?

Groups are already merged by name (they already have different IDs/keys) and we'll ensure this is now done per level. So tabs with the same name will get merged into one and any groups within the same tab will too 😄

[madsrasmussen]

Either making the tab bar sticky or making the scroll on drag work 😄

Keyboard shortcuts are on the to-do. The current idea is to use ctrl/cmd + arrow keys to move tabs/groups/properties around.

Example:
With the focus on a group. Ctrl/cmd + arrow right would move the group to the next tab.

[MMasey]

In regards to the drag controls, for me personally I'd prefer having the tab bar sticky, or maybe appearing when you drag. I always find having to drag up to begin a scroll in those types of interfaces liable to bugs, and unexpected and frustrating behavior (again that's my personal opinion on it though, others may vary 🙂)

That sounds like a good shout in regards to the keyboard controls. Maybe if keyboard usage is detected a little "instructions" window could appear for those no used to it. You could set it up to alert screen reader users of the controls too, and maybe allow people to hide it if they no longer need it. Ultimately though I imagine the best way to work out the best functionality is to test is with a number of people.

[ronaldbarendse]

All shortcuts are discoverable by pressing Alt + Shift + k (indicated in the footer bar) and there's already an Add tab shortcut 😉

[MMasey]

haha I always forget about that! I just had a little look at the markup in there and it's currently using div's for the all of the text. A separate issue, but something that we should definitely fix to add some proper semantic markup.

[liamlaverty]

First up, love this! 😍

In the below screenshot, there's a "validation errors must be fixed...". Is this red exclamation mark next to the Content tab visible if the user is scrolled down a long page? The notificationService red bar can be a bit vague & therefore frustrating by itself if you can't see where the validation error is in the open window.

[ronaldbarendse]

This is the doctype editor view (see the Validation section for how this works when editing content), but I agree this makes it even more important to make the tabs bar sticky, as commented here. Thanks for bringing this to our attention 👍🏻

[PeteDuncanson]

My only point would be to challenge the desire to remove them in the first place which is hinted at in the opening text. It seems to be that because some sites abused the amount of tabs they used (and this was highlighted to/seen by HQ) we all lost them as a result in a bit of an over correction.

A super tab heavy site is no fun for anyone but that doesn't mean it should be a limiting force on any future design choices. Some developers make poor choices, sure you can try to suggest they don't but they still will and sometimes needs must but don't let that be a driving factor on the new solution.

If anything I'd take the constraint/desire of "stopping people making stupid choices about the amount of tabs" off the table in whatever you come up with, it lead us here and didn't serve us well in V8 and won't going forward. Then fresh eyes on the problem with that constraint banished to history.

I'm very impressed with the work shown here so far. It warms the heart.

All the best.

[craigs100]

I concur with the "don't punish everyone for the misdemeanours of the few" sentiment.

[marcemarc]

Also the perspective has bias, in you tend to only 'see' problem implementations that are handed over.. the well implemented sites stay well implemented, and you don't see the good practice use of tabs, limiting the number of tabs that can be created would be a way to tackle the concern of 'too many tabs'... rather than completely removing them!

[ronaldbarendse]

I think the problem with previously having too many tabs was the lack of any other grouping mechanism: now implementers can have both tabs and groups...

Of course they can still create super tab heavy sites, but we'll try to discourage that using smart UX (a larger 'Add group' button for example) and updating documentation, our courses, etc.

[DanDiplo]

I think this looks great - a mixture of tabs and accordion was always my preferred solution. Being able to move stuff like SEO Settings to it's own tab - with an icon!! - is great.

I do have a little concern about Content Apps - I wonder if there is more than two or three they should collapse to something akin to the Bootstrap Dropdown ?

The other thing I'd like to see is a slightly stronger sense of which tab is currently selected. The underline just seems quite weak and it's not immediately obvious which tab you are looking at. Some stronger "selected" styling would be good - maybe darkening the other tabs or some use of drop shadow - could help make it more obvious.

[ronaldbarendse]

Thanks Dan, we think adding tabs with icons will indeed help editors find things like settings and SEO properties a lot faster too 👍🏻

The Content Apps already collapse into a dropdown/menu when they don't fit anymore:

The active app also has a different color, besides the underline... Maybe the contrast can be increased a bit, but we don't want to give the impression of other tabs being disabled 🤔 You can create a separate issue for this if you like, as it's not directly related to this tabs feature...

[mttblss]

I really like the way this is looking

I have two observations/thoughts

1. If I've understood correctly there will be potentially multiple 'Content' tabs followed by 'Information' followed by potentially multiple 'Content Apps' as Content and Content Apps are conceptually quite different, should there perhaps be some visual distinction or separation of these tabs. Possibly something conceptually like the separators in the richtext editor toolbar, so the display would be in the order Content Tabs, gap, Info, gap, Content Apps for example.

2. Currently there are times when a group name has to be entered, but there is only a single group of properties on the document type and giving the group a name that is displayed in the interface feels forced. This can particularly be the case with composition document types that are used in the block list for example. I can see with the option to add tabs as well that this could become more noticeable with 'standard' document types as well. Could there be an option to hide the group name if there is only a single group being displayed (the block list editor would benefit from this too)

Many thanks,
Matt

[ronaldbarendse]

Thanks for sharing your thoughts Matt!

Making the new tabs (content apps) more visually grouped would indeed make sense. Because it's essentially a single Content App, removing the dividers between the tabs might even be enough. We want to avoid adding more gaps/horizontal space 😉

You'll be able to add properties directly on a tab, so you're not forced to add groups anymore. By adding a single tab called 'Content', it will look the same as before, but without the group name above the properties.

I've made a mock-up showing both suggestions:

[benjaminc]

I have to say I love both the idea of visual separation of the tabs vs. the content apps. I think the vertical bar works really well.

I also really love the Content tab with no groups. I've always disliked having to create a group for 2-3 properties, and while creating a tab doesn't improve the doc-type creator's experience, at least it does improve the content editing experience.

[mttblss]

Thanks @ronaldbarendse that mockup answers both my concerns perfectly!

[craigs100]

@mttblss Both your concerns would appear to be satisfied by putting tabs back as they were:-

1. Visual/functional separation
2. No unnecessarily forced group names
   ;)

[craigs100]

An interesting concept which gives me pause for thought(s):-

1. Why were tabs removed in the first place? What were the specific issues? I'm still not clear on the reasons.
2. Mixing tabs and content apps is confusing. Remember people want to work with this interface at pace. Not have to faff about. On a large screen those new tabs will be miles away from the rest of the content. A bit like the save and publish buttons are now.
3. I'd be concerned that there is no longer enough space for them, given that they now share the same row as Page Name, Conten(x)t Apps and Actions.
4. There isn't sufficient visual difference between a Conten(x)t App and a "tab".
5. It's now more work to set up a docType when all you want is the tabs and not the groups.
6. Will it be possible to ignore this work and just install Matryoshka going forward or will it be forced on us like the initial removal was?

Tabs weren't broke, so didn't need fixing. Happy for the inclusion of groups within tabs but the tabs need to be in the eyeline and easy to operate. Not being a bore, just trying to give my clients the best possible (i.e. most efficient, not necessarily pretty) editing experience. It can be prettied up once the ergonomics work ;)

[RyanHelmn]

The only problem I have is that these all look great on "deigner" screens. Once this is viewed on a standard laptop screen those content apps take up too much space, or get pushed into a dropdown which is even worse UX for the user.

Even if you had 20+ groups that were to be condensed into fewer tabs to fit nicely on smaller screens, you'd still have to resort to the 'accordion' way of navigating within the tabs.

[DanDiplo]

That's a good point @mattbrailsford I've often built sites that look fine on my widescreen monitor, but when its been time to train the client I can see how crowded it looks on their laptop screen. I wonder if a wider UX/UI review is required that takes into account all breakpoints? Maybe size of tabs could be dynamically reduced at different breakpoints - at smaller ones could it just show the icon (whilst not great, still better than collapsing).

[craigs100]

@skttl @RyanHelmn My own solutions generally have no more than 4 or 5 tabs max. Others' sites I've worked on have many more. My issues with this are many fold:

1. Position: They're out of context with the main content. They're up with the CMS's admin functions and a big mouse movement away from the main editing area.
2. Look: They look the same as Conten(x)t Apps and are effectively mixed in with them. Will cause confusion and mistakes, extra mouse movements and clicks which are unnecessary and inefficient.
3. Extra work to set up: With tabs relegated to second place, it will take much more work to add them in than it would to add a group header if it were the other way around. It just seems wrong-headed.
4. Reason: Is this being done because of a coding rabbit hole we've got into rather than thinking about editing efficiency.

In my view, it's being over-thought. Just instigate the Matryoshka editing solution in core and keep the docType editor the same.

[craigs100]

@RyanHelmn

It would be good to have more of a separation from the content apps to the actual content too, that's a story for another day!

It's what we already had in V7 or V8+Matryoshka and it's very much today's story ;)

[RyanHelmn]

@skttl @RyanHelmn My own solutions generally have no more than 4 or 5 tabs max. Others' sites I've worked on have many more. My issues with this are many fold:

1. Position: They're out of context with the main content. They're up with the CMS's admin functions and a big mouse movement away from the main editing area.
2. Look: They look the same as Conten(x)t Apps and are effectively mixed in with them. Will cause confusion and mistakes, extra mouse movements and clicks which are unnecessary and inefficient.
3. Extra work to set up: With tabs relegated to second place, it will take much more work to add them in than it would to add a group header if it were the other way around. It just seems wrong-headed.
4. Reason: Is this being done because of a coding rabbit hole we've got into rather than thinking about editing efficiency.

In my view, it's being over-thought. Just instigate the Matryoshka editing solution in core and keep the docType editor the same.

Suppose it does raise the question, especially if you look back to v7, would we even want so much control over the tabs. I can see the purpose in it, but personally I've never really thought too much into it. Tabs are tabs, makes it clear as day for editors what tab contains what and it's broken down.

[dawoe]

I am happy that tabs are making their way back into Umbraco. Never got to hear the reason why they were removed in the first place. Still curious about the reasoning behind that.

However I don't like them being up in the content app navigation for several reasons.

There is a issue that this area not always get noticed by editors. I often give training to editors or watch them edit content so we can optimize the content editing experience. And there is 2 questions I hear often :

• Where can I see the link of the item
• Where can I edit the page content on pages with list view enabled

Both of these arise because they don't notice the content apps. So moving tabs into this area might not be the ideal solution.

Also when you have a lot of tabs this can get really crowded, even if you don't have any extra content apps.

This is a example of one of our sites :

On this site we would end up with more then 10 'tabs' in the content tabs navigation (9 from content, the info tab and several from packages)

One could argue that we have to many tabs. But from building sites on top of Umbraco for more that 15 years and actually watch editors do their job I can state the following :

• They like properties grouped by functionality
• In a order where the most frequent edited properties are shown first.

From my experience I can say this works well. Editors rather have one extra tab to find a property in one click than that they have to spent time looking for a property.

Before we had Matryoshka installed on this site we noticed that editors were having a hard time finding the property they wanted to edit because of all the scrolling they had to do. They could you use the group navigation drop down on the Content content app, but see my first point. How many of you actually use that navigation ?

After we had Matryoskha installed their first reaction was that the editing experience was much better because they could see all the groups of properties at first glance.

As Matryoshka was the recommend package by HQ to bring tabs back to the backoffice I think core tabs should look the same. Especially because Matryoshka is going to be retired. So if we want to change to core tabs once introduced, the editors again are faced with a new editing experience, which is not optimal.

Dave

[dawoe]

You are making a assumption here that a lot of tabs only contain one property. But that is not the case.

With your proposal editors would have to scroll past the header and summary fields to reach the content blocks... which is the most edited property. So from an editors perspective this is far from ideal.

Moving navigation & tags to settings.... makes it unclear for editors where to find them.

Site implementers should have the choice how they implement this based on the needs of the editors. We don't want to make the life of editors harder by restrictions on the core CMS.

[skttl]

Definitely an assumption - just trying to get the context :)

[dawoe]

Seeing the popularity of your package I just want to the transistion to core tabs go unnoticed for editors.
Although the icon is a nice addition. And probably when there are 2 many tabs the text could be hidden so that just the icon is visible.

[skttl]

Is it too late to request 3 levels of seperations?

• Apps
• Tabs
• Groups

Since block list arrived I have really wanted to have a Settings section on content nodes too :)

[soreng]

@skttl i just talked about the same thing (settings on content) in the office the other day.

Seems like it is a bit of a mix now (in this RFC).

would be very nice to have the option to also move to an “app-tab”

[nathanwoulfe]

For some additional context re large numbers of tabs - one of our most heavily used content types has the following (from memory):

• summary
• domestic metadata
• international metadata
• generic metadata
• apply and enrol
• pdf settings
• admin
• seo
• workflow

It's a lot, but it's also a sensible division of the content based on editors' activity and frequency.

Conversely, a lot of our other types have one or two tabs only.

There may not be a one size fits all solution, so the focus then needs to be on providing enough flexibility for implementors to build the appropriate editing experience for their users.

I know when restoring tabs was first being discussed there was conversation around tabs OR groups, however the result looks like it will allow both. Makes sense then, I think, to consider allowing control over where the tabs are rendered... Different strokes for different folks, as they say in the classics.

[craigs100]

But I would seriously question which should be the prime grouping, tabs or groups. What has been suggested so far by HQ would make groups the prime grouping and, for those keen to give their editors the better editing context (in my opinion) extend the time taken to build each and every docType and therefore make Umbraco development more costly/less profitable.

[madsrasmussen]

Hey all,

I just wanted to say a quick thank you for all your comments so far. We are listening carefully.

The solution is not set in stone, so we are still able to change things. Please keep posting your points of view. Knowledge sharing is key and all your examples help a lot! 🥇

Thank you so far!

[dalyUSN]

Great to see a healthy discussion on this and it's really good to know that nothing is set in stone.

Having looked over the videos again it's interesting that the view for a Developer creating the Document Type with tabs on it is provided with the layout that would make the most sense on the content editor side of things. Echoing the layout from the Document Type view into the Content Editor will create a much more cohesive solution for someone who is both a developer and content editor, as many of us are.

I think user testing is essential for this placement, just as it was when the decision was made to remove tabs in the first place — something that didn't seem to take place then. We're all hoping to make Umbraco a "content editor focused CMS" but these sort of decisions are being taken without consulting content editors.

[OwainJ]

This 100%. The placement of the tabs, as they are shown in the doctype editor, seems like the best position for them rather than kinda squished up with the content apps; where I feel they can kinda get a bit lost and feel too separate to the content.

I think I'll send an email to some of my clients on Monday, to see if they could ask their content editors about their views/preferences on where they think the tabs should be placed; it would be interesting to see what they think, as they are the ones who actually use it day-to-day.

[craigs100]

Big question though, do you think groups should be prime or tabs? If tabs, then no need to add into the docType creation work load. Group headers can be added if needed as currently. Keeps dev time/costs down.

[marcemarc]

I think there is something in the difference between properties that allow for the editing and visual display of content, properties that describe that content, eg meta data for SEO, and properties that control how the content interacts with the rest of the site, eg hide from navigation...

I think editors have a different 'mental model' for these kinds of properties,

... with the content app style implementation for tabs, then that does feel a good way to 'divide' these properties, as I can have a Page Settings App Tab, or an SEO/Metadata App Tab - and focus the Content App Tab on only the visual elements of the page...

... but I don't think this would 'work well' if you had multiple tabs for visual content... then the content apps feel too far from the action?

... but once you move non-visual properties into Page Settings and Metadata... what's left for people? is there still a need for tabs beyond groups for visual properties? (it would be good to build some consensus over this to see how common this kind of scenario would be required - yes historically in V7 you would have 5+ tabs always, but is there a strong case for tabs for only visual properties? as that might tip the hat towards some kind of Matroyska approach...?)

I think when thinking about tabs and groups that different 'editor journeys' should be considered /measured against the proposed implementation:

Creating and Authoring Content
Creating and Cutting and Pasting 'already authored' content from Word
Editing existing Content
Proofreading / Previewing / Approving Content
Comparing Translating Content

As I think people are thinking about properties in different ways in this context, eg Creating and Authoring it's about the flow of the experience, but in Editing existing content it's about 'finding a specific property' to edit, and the two journeys aren't always complementary, and it's important to not just think of editors 'only' creating new pages when considering this...

Finally, I think the organisation of the display of properties for groups vs tabs isn't the same paradigm... you can't just make the properties that were on a group into a tab, and vice versa and get the same experience...

eg you tend to use 'more groups' than tabs due to the lack of horizontal limitation...

and I find it interesting some of the solutions people have come up with for common interactions when fresh to V8, having not designed for V7 -

For example, having groups of setting properties that 'instead of being properties on a tab' on every doctype that override via inheritance - are actually delivered by a 'Nested Content' page settings property, that allow you to 'add a nested content' item on a page that needs to override the default settings for that particular page,.. which is in response to managing 'vertical space' by not having tons of properties that are hardly ever used clogging up the scroll...

so I'm rambling but I'm just trying to say that switching between the two 'paradigms' isn't 1-1, and so the addition of a separate 'level' (is level the right word? groupingType - or are we just reusing level from the database table column) is a good good thing....

... of course, you kind of want the editor to be able to choose how they are arranged for the tasks they need to achieve, which might be different from their colleagues editing the same page... or even different for them depending on the task they are trying to achieve... (was there a 'favourite properties' package at some point in the past?)

I'm also not too sure that we cover the nuances of Document Type, Site structure and property grouping good practices in training or documentation or by example anywhere... so a spin off outcome of reintroducing tabs could be the creation of this kind of supporting material, and this might also address concerns over implementations with 'too many tabs'.. eg show people how...

[craigs100]

There are many types of editors. There are the professional content editors that work for huge companies and do hundreds of edits a day and there are bed and breakfast owners that are not IT-savvy and just want to edit their content occasionally without having to remember all the ins and outs of a complex interface or having to ring their site developer. All benefit from keeping things simple and obvious. This is why I reckon we're over-thinking this and, may I suggest, could be in danger of making changes just for the sake of it.

As for a site having too many tabs, I'd be happier allowing them to wrap than hide them under an ellipsis. Make 'em pretty if you must, but keep the utility (i.e. in line of site). As many have said, a site with lots of tabs is probably an edge case, so you might never see this in action, but some sites need the logical separation they provide for good reasons.

[madsrasmussen]

Thank you all for your feedback!

When looking through your comments, we can see the pros and cons of both solutions. "Tabs in Apps" work great for simple doctypes, but "Tabs as tabs" are needed for more complex scenarios.

We have been going back and forth to figure out what will be the best solution, but concluded that the implementor is the one who knows the best. The implementer should be in charge of what the best editing experience is, and we think that a combination of both solutions will be the right way in the future.

When that is said, we can't ship everything at once. The feature will become too big, and we want to deliver a solution now that will help with the current problem in the backoffice - we miss the tabs.

Changing direction

Based on all your examples, we have changed our minds and the best first version of tabs is a tab bar (tab as tabs). Content editors who already know Matryoshka will get an editing experience close to what they already know and love.

Part 1 - Tabs as tabs

The first version will be a tab bar. Our goal is Umbraco 8.16. Then you can start migrating your Matroyska Tabs to Umbraco Tabs before upgrading to v9. The doctype editor will be close to what you already have seen, but we won't include icons for tabs.

Future Part - Full flexibility in groups

We still think setting up doctypes should be more flexible. We don't think the current way to set up doctypes is fully suited for setting up complex doctypes with apps, tabs, groups, (columns?), etc. Setting up doctypes should be easy for newcomers and fast for experienced developers. Adding more buttons and complexity to the current doctype editor is not what we want. We will have to do some more thinking of how that could work.

Update in data structure

We have made a small update to the proposed data model: "Level" is changed to "Type", which gives more flexibility. The level can already implicitly be determined by the parent/child relationships and having an explicit type opens up more ways for future flexibility.

Limitations in v8

Today it is not possible to have two groups with the same name. We will run into this limitation for tabs too. It won't be possible to have a group and tab with the same name (or the same group name within different tabs), as they are all stored as generic "groups". That is something to be aware of when migrating from Matryoshka. In Umbraco 9 we will be able to remove this limitation.

Again, thank you all for bringing your concerns, ideas, and examples to the table! 🥳

[ronaldbarendse]

You can follow the progress on PR #10606 👍🏻

[madsrasmussen]

An update from the tabs feature.

We have had to make changes to the suggested data structure to finalize the composition feature.

We have replaced the parent key with an alias that is automatically generated based on the name and optional parent alias (separated by a forward slash, e.g. content/seo for an SEO group below a Content tab).

A summary of new and fixed stuff 🥳

• We've added two new properties to the existing property type groups: alias and type.
• The alias is automatically generated based on the name and optional parent alias (separated by a forward slash, e.g. content/seo for an SEO group below a Content tab).
• Migrating from a previous version will automatically generate the aliases and use the (default) group type, so this is backward compatible (it keeps the existing groups structure). This works across content, media, and members.
• The package.xml format also exports these new properties: the format from older versions can still be imported, but will only create new groups. If the content/media/member type only contains groups, the new format is completely backward-compatible (and it would be advisable to recreate/update the XML to explicitly specify the alias and group type)
• A new patch version for Umbraco Deploy will make sure the new properties are also deployed between environments (otherwise tabs would become groups again after a deployment!)

Updates to the UI

• Tabs work across content, media, and members.
• Tabs are implemented in the Block List Editor, both in "dialog" and "inline" mode.
• Validation markers are shown on tabs that contain a property with a validation error.
• The compositions feature is implemented.
• A "Generic" tab has been introduced for groups that don't have a "local" tab. This can happen if a tab has both inherited and local groups and the tab is deleted from the composed Document Type. The local groups will be moved to the "Generic Tab" because the inherited tab is gone.
• A new feature for quickly converting a group to a tab. When sorting you can drag a group to a new "Convert to Tab"-area. The group will be converted to a tab, and all properties will be moved to the tab.
• A whole bunch of bug fixes.

[skttl]

Att: Matryoshka users - I've put up some polls to get an idea of which features a being used in Matryoshka, if you can, please answer: https://twitter.com/skttl/status/1412678362376589315