Document Type Create Menu Missing 'Composition' Option

[marcemarc]

Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)

v14 rc3

Bug summary

In Umbraco, when you create a Document Type in Umbraco backoffice you normally have five options

Document Type with Template
Document Type
Element Type
Composition
Folder

In V14 we've lost this ordering of options and we've lost the composition option

Also, the icon used to represent 'Element Type' - the atomic symbol (elements science etc) has been changed to use the fragmented blocks (previously used on the composition option)

It's perfectly possible to create a Composition by creating just a Document Type - the menu items essentially do the same thing... the reason why there is an extra entry there though is to help support people new to Umbraco who are just trying to work it out from scratch, the presence of the option introduces the concept, which you would never guess at otherwise. more is more!

The order reflected the most common task of the menu at the top, eg Creating a Document Type and Template, and each further option decreasing in size of output created.

It's hard to know if this is by design or something that has been missed? so apologies if it's been discussed and decided to simplify and jumble up the order for a greater purpose, but thinking if that is the case, perhaps the description text should ber updated to reflect this?

Document Type - 'The data definition for a content component that can be created by editors in the content tree and be picked on other pages but has no direct URL' could be updated to mention composition?

Also, probably I ought to check - are we dropping the concept of compositions for V14!! that would explain why it's missing, doh!

Specifics

No response

Steps to reproduce

Expected result / actual result

I expect there to be an option to create a Composition with an explanation of what a Composition is used for with a fragment icon

Defines a re-usable set of properties that can be included in the definition of multiple other Document Types. For example, a set of 'Common Page Settings'

[iOvergaard]

Hi @marcemarc,

This has been left out on purpose (for now). We were getting reports that people found the "Composition" choice confusing, hence we did not want to spend extra time in v14 rebuilding that feature.

I will convert this issue into a discussion to let people weigh in with opinions. Perhaps new ideas will surface.

[marcemarc]

This was the original thought processes when it was introduced:

https://moriyama.co.uk/about-us/news/creating-doctypes-in-umbraco-v8/

[prjseal]

It would be interesting to see the reports of the Compositions option being confusing. Is that from developers in the Umbraco community? How many people need to report something for you to decide to remove it as a feature for everyone else?

[iOvergaard]

To be fair, we didn't actively choose to remove it. We haven't implemented it on V14 and instead focused our time on other things that seemed more important. If people want it, we'll implement it again, but I think we should do some work to make it more obvious what the different choices mean.

[bjarnef]

Could it possible be simplified further:

• Document Type
  • Template (yes/no) - toggle (enabled by default)
  • Composition (yes/no) - I don't recall if this did something more than document type without template)
• Element Type (selecting this could eventually reset selection under "Document Type")
• Folder

Something similar to inserting template section:

Alternative it could also be:

• Document Type
  • Template (yes/no) - toggle (enabled by default)
  • Composition (yes/no)
  • Element Type (selection this would disable template toggle)
• Folder

Besides that I also suggested some time ago that Element Types ideal should be moved out on Document Type tree node, as it in a perfect world can be used in Block List on Content Types (Document, Media and perhaps even Member, e.g. it could be useful for SoMe items in a property on a member): #15082

I also hope folders will be an option for member types in future as it didn't made it in current backoffice, so content types are even more consistent #14833

Then one has only 2-3 choices to make initially.

[nielslyngsoe]

Hi @marcemarc

Thanks for your enthusiasm, that is always lovely. And lovely that you care for new users, which is one of the points of removing this one. So I would love to put a few words on the decision and the idea behind it. And yes we can agree that the optimal way of removing something would be to provide something new, which is the end goal, but I'll get back to that.

For a composition(in our vocabulary/system) to exist there has to be two things that is combined — so for this feature to help new users figure out and succeed creating a composition it should have guided a user through making two doc types, resulting in a composition.

That is not the case, wether the user chooses the option Document Type or Composition leaves them in the same scenario, The scenario where they would have to learn about the composition button anyway — which actually have an relatively prominent position.

And I would say having this choice makes it even worse — A new user to the system would skim these options and conclude these are the different choices. As they are placed next to each other as options are in such list, they are interpreted as different to each other but a similar action. In this case, the user will see this as the choice of which type of entity to create. — Read entity not entities.

The choices would for a new user be seen as finite choices, aka. you would have to start over to get one of the other choices. Do notice, the user will understand that Document Type with Template is the same as Document Type, just with something extra. The wording gives that away. To be explicit, the user knows about folders, and they know if they choose a folder and regret they would have to delete the folder and pick another choice from list. (yes they will learn shortly that they can switch between element type or not, but... )
Point begin, the users overview of options is established at this point, and it will deceive them as the Composition will be interpreted as something different than a Document Type. But it is not — Instead I would love that we come up with a solution that underlines that a Composition can be made with anything. Even Element Type can be used as a Composition, Even Document Type with Template can be used as the base for a composition. So for the user to learn that freedom we have to look for a solution that demonstrates that. As well it should teach the user that they can make compositions as they go, its not an finite choice made in the beginning.
And most importantly it would have to be something that leads the user all the way and not half the way.

I do like the intentions and if there is a time where we can move the cheese it is now, which is why we have taken the opportunity to remove it, so there is room later to make a intuitive feature that actually briefs new users on their opportunities. :-)

So its the first step that opens up for rethinking this.

Let me know if you agree with the intentions and as well when knowing so makes you agree with the decision?

Thanks

[marcemarc]

@nielslyngsoe @iOvergaard Sorry for my lack of enthusiasm - only just seen this (don't think I've ever managed to make a successful point if someone starts with 'thank you for your enthusiasm' :-P) - via this issue: #17173

But from your suggestion above it seems like you are prioritising the knowledge that a 'Composition is just a Document Type' over 'You can use Compositions as a strategy to build Document Types'

When you are thinking of User Experience then it can be useful to build a Story Map (I recommend Jeff Patton's approach - https://jpattonassociates.com/the-new-backlog/) to build a story map for the key User Journeys in the backoffice.

When Composition was first introduced, nobody could understand why it didn't take off and why people still used Nested Document Types - building the User Story Map, with post it notes, enabled us to see there was no early introduction of the concept of the Composition Strategy for new users when architecting an Umbraco solution - you needed to be shown it existed or you'd discover it after you had built your first site. For training sessions with new users, we built a training wheels solution to introduce the 'Composition' option to the menu.

We were fed up with having to say 'Document Type Without A Template That As Long as it Doesn't itself have other Compositions, can be used as a Composition' - it was easier to say 'Document Types can be built from Compositions' 'A Composition cannot be composed of another Composition'.

Later this 'training wheels' package was consumed by Umbraco, as it was felt that people who knew about compositions being Document Types, were not slowed down by this.

So this menu option does have a 'negative' impact on people's understanding of how Umbraco is implemented - eg a 'Composition is just a Document Type' - but at the time, it was prioritised instead to focus on new people using Umbraco, and being introduced to the concept of Composition.

I guess I am mainly enthusiastic about the history and the purpose of the menu being understood and that it was a 'good thing' for a while! and it's a shock to find out it's considered confusing for the reasons it was introduced - but context is everything and times change and as Umbraco is not taught in the same way anymore, and composition is fairly established in the umbracosphere, so the menu may have already done its job!

You ask if I agree - it depends!

I don't agree with the decision on the grounds of 'we have to take the opportunity now to remove in order to have any chance to improve it in the future' - I think the menu option could have stayed in place - it is JUST the same implementation under the hood as creating a Document Type - so strategically for delivering the backoffice - we didn't save any time removing it!! - and in fact, we created an extra task for needing to update the documentation, when resource and time were short (and this wasn't done) - and user confusion and noise have been created over the removal! (minimal!) - I think the existing menu could have been pivoted to a new solution - it didn't need to be removed to enable that to happen, once we had decided what we wanted it to do :-P

Agree though if we were on the verge of delivering the improved menu - then it makes no sense to implement the old way - although I don't think much time was saved?, and it is 4 months on... so it wasn't the case it was about to flip to an improved solution? - in the meantime, it's ok for people using Umbraco 14 for the first time to maybe miss the concept of composition (probably!)

Agree on the basis, this is a tiny thing, the backoffice rebuild is a big thing, we just didn't do it, we had to focus on the minimum viable product, which means delivering the minimum thing to build a site and compositions can still be used, the impact is low.

Agree, impact is low! - only @marcemarc will notice :-P, it's been three months... it's not the main priority right now!

Now how do we make @marcemarc shut up about it! - really sorry for the noise and saying the same things all time, I will let it drop!

I am interested in the Story Mapping process for the backoffice journeys, I think there is a Stories On Board (https://storiesonboard.com/) somewhere of all the journeys the training courses were written around supporting, do you still use that approach?