Add 'Add as Element' to Doc Type Create menu

[philipdanielhayton]

Could we have the ability to add a new doc type as an Element. This would save me a load of clicks each time I forget to set new types as elements.

[FransdeJong]

As I see there are two issues this would solve.

1. It removes the extra clicks needed to create a element type
2. If I want to quickly create a nested content Item I regularly find myself creating a DocType, creating a DataType, go back to the DocType because I forgot to set it to element, go back to DataType.

If for whatever reason a extra Item in the create documenttype menu is unwanted this issue could also be solved by moving the toggle to the top of the design page.

[skttl]

I would love this, 80% of the doc types I create is elements, and I usually follow @FransdeJong s pattern :)

[nul800sebastiaan]

We'll have a chat at HQ, seems like an okay addition to me, but we'll soon get loads of choices and I'm afraid newcomers will have no understanding of what they mean and why they should choose one over the other.

There's a PR for this (and more) as well: https://github.com/umbraco/Umbraco-CMS/pull/5580

[nul800sebastiaan]

Thanks @thehaytonproject - we've had a chat about this today and we'll put this on our longer terms "ideas" list for when we start working on a UI update for document types.

Our discussion involved:

• Too many options in this menu confuses new users, it's already difficult to learn that you need a document type to get started and "bombarding" people with choices is only going to make that harder
• An idea we'd like to test is to set up default folders under "Document types" (Elements, Compositions, List views) under which you can only create document types of that very specific type. We'd also have a change to add help text on a dashboard while clicking each of these items. Just an idea, it might work.

[philipdanielhayton]

Hi @nul800sebastiaan

Thanks to yourself and the team for taking the time to review my suggestion.

I can't help but feel that you've over thought this one. It sounds like there are lots of big changes coming in a future update, which I look forward to hearing more about.... but until then, is it really so risky to add one additional button?

Does the potential issue of confusing new developers out weight the opportunity to provide a real QoL improvement?

Is adding one additional button really going to baffle new developers? (Keen to stress that we're talking about developers here)

Is going from 3 buttons to 4 really bombarding users?

I'm a little sleep deprived so apologies if my post seems narky 😅 I don't mean to sound bitter, I just disagree with your justification. I do value and appreciate the work you and the guys do.

PS - Not to go off topic but you might want to consider whether your taking away some of the developer's agency with your second bullet point. More folders == more buttons.

Anyway, I'm gonna go get some sleep. Kids hey !!

[FransdeJong]

@nul800sebastiaan I strongly disagree with HQ on this one for a few reasons:

1. Should everyday developers be suffering in productivity in favor of the newcomers? We have documentation and Our to get newcomers started don't we?
2. The options we have right now are Documenttype, Documenttype without a template, Documenttype collection and Folder. I would favour removing Document Type Collection and putting the Element in it's spot. Document Type Collection is not intuitive at all and you need to go into both documenttypes created that way anyway to do aditional settings.
3. The folder idea blocking the flexibility for a developer to order the documenttypes neatly. For example: I have a newssection on my site. I have a overview DT, a detail DT and a featured items Element. These are all related to news so I want them in one folder. Now I'm forced to use the new folders? Or am I forced to have three empty folders in every install I dont use?

The most productive way in my opinion is to go with a menu with the following options:

• Document Type
• Documenttype without a template
• Element Type
• Folder

This menu isn't at all overcrowded and makes setting up DT's a breeze.

Edit: A small addition. With adding these changes we could also add a tour that explains the difference between the options and point to the correct pages in documentation in the forum.

That way Umbraco can be optimized for everybody and newcomers are guided and find there way to the friendly community a lot faster.

[dawoe]

I agree with @FransdeJong on this one. Remove the document type collection and replace it with a Element type

[kjac]

Don't forget about culture variance here. It's one of the things people complain about here and there, how they forget to set culture variance on doctypes because it's hidden under "Permissions". Hence why I opted to add "Document type varying by culture" in #5580

[FransdeJong]

I agree. This issue is that by keeping this menu simple we create a mess further down the line.

I have heard of more developers who now have this workflow: If I want to quickly create a nested content Item I regularly find myself creating a DocType, creating a DataType, go back to the DocType because I forgot to set it to element, go back to DataType.

Same with variants. The workflow often is: Set up the site with all documenttypes and properties. Switch on extra languages, click on every doctype to set it to multilingual, go back trough every doctype to set every property to multilingual.

That seems a lot more user unfriendly and I can't help to think this confuses beginners more than a few well explained options.

[ronaldbarendse]

Too many options in this menu confuses new users, it's already difficult to learn that you need a document type to get started and "bombarding" people with choices is only going to make that harder

The existing choices are already slightly confusing for new users, so I don't see adding 1 or 2 would make a real difference here (especially if it also removes the rather unused 'Document type without a template'). As noted in https://github.com/umbraco/Umbraco-CMS/pull/5580#issuecomment-534733348, adding descriptions to the choices might be the best way to help people get started (without having to go to external documentation).

An idea we'd like to test is to set up default folders under "Document types" (Elements, Compositions, List views) under which you can only create document types of that very specific type. We'd also have a change to add help text on a dashboard while clicking each of these items. Just an idea, it might work.

This would actually make it worse, as you're forced to make a decision (what folder to select) even before you can add something. Changing a document to element - or vice-versa - would need to update both trees, compositions can also be documents and list views are data types 😉

If we would have different APIs for creating documents/elements or data types/list views, it would make sense to have separate trees ('Element Types' below 'Document Types' and 'List Views' below 'Data Types'). But that's not the case and these are all too much intertwined to change that IMHO.

[marcemarc]

I think the problem here is largely historical and the way the concept of document types has evolved over the time, and changes have been thought about in the context of the problem they were solving and the impact on this menu or how new people come to grasp document types and associated concepts hasn't necessarily been considered...

... what I hope is being said here is ...

We know there is a problem, but it's kind of like this because we just keep making small changes without considering the impact, this request (although undoubtedly a massive performance gain to day to day users of Umbraco) is the sort of request we just changed in the past, and got us into this mess...

... so we want to find the space to think about this properly in a joined up way ... as the words 'Document Type' touches so much through the core, backoffice, training materials, umbraco culture, forum, that we want to get the next step 'right'...

There is a lot to consider here

Document Type

As a label... is it the correct phrase for a Document Type... are they more Content Type's? for a newbie to Umbraco... 'Document Type' doesn't instantly mean something, these aren't Documents!, documents are PDFs, Word Docs... so this becomes a term that 'needs to be learned and understood' - it is immediately a barrier to learning - but this is unchangeable? right?? in the whole history of Umbraco can you imagine a world where we don't say the word DocTypes?? and everyone know what it means?

As a menu expands the options 'tend to get more complicated' the simple options are presented first... so one of the UI points of confusion is your first option is to create a Document Type, but your second 'more complicated' option is to 'Document Type Without Template' so the more complicated option has less in it than the simple popular action... so your head fights what it means... and really you need to understand how Document Types + Templates work before you understand what this means... but if you are new to Umbraco... you haven't created a Template yet... so the first choice is a puzzlement...

We have the concept of Compositions, to help build up Document Types from smaller pieces... we refer to them as 'Compositions' when we discuss them, some error messages say this Document Type can't be composed on another Document Type... and This Document Type is already used as a Composition... but there isn't a menu option or scent about 'how to create a Composition' - you have to learn this concept, it's difficult to discover it via the Backoffice UI... Composition isn't really an 'official term'

Elements and Compositions are both Document Types without Templates, but the IsElement checkbox is the distinguisher between the two... but that's not discoverable in the UI you can't look and see in the tree.. which items are which, so people do use folders to make this distinction - see screen shot

A common interaction in Umbraco is to have Components/Widgets (everyone calls them different things), pickable items in the content tree but without a template, are also created as 'Document Type Without Template' but not necessary 'Elements' because they aren't used to define an item that can be used as the schema for repeating nested content item.

But is Element the right phrase here? is this really an element? or a schema? or a Component?

It's all in the language and the history of the evolution of this area of Umbraco... I would argue it isn't the number of options that is confusing for new people, it's the terms themselves! and so the strategy to present only a few, so more often the correct one is chosen is what we have...

... but my input is that...

(and I understand this is not a small task)

... having distinct 'good names' for these 5 different variations of Document Types will aid discovery and understandability for people new to Umbraco - you want people to see 'Create Composition' and you want the Tour to flag what this concept is, and if you look to the docs to find out what a Composition is you want to find a description, on a page that explains the five different types succinctly...

It will make it easier to teach, the UI can make the default 'Document Type' more prominent as the preferred option for when people are starting out, but you want those people to grasp that there are other options and ... they should discover what they are for rather than pretend they don't exist!

But I think it would be a big change, and perhaps it is impossible!

• maybe in the meantime it's just a package idea! - add an option to that menu, and allow it to create a DocType with IsElement as true... experience Umbracians could install to speed up their day to day, but without confusing this menu further whilst long term changes are considered!

[dawoe]

@ronaldbarendse

(especially if it also removes the rather unused 'Document type without a template')

I use this all the time. For when creating composition doctypes. Doctypes that will not be rendered at the frontend (settings, categories, etc..). And for those who are still on v7 for your doctypes to be used in nested content etc.

I actually think I use this one more than the first option

[philipdanielhayton]

I actually think I use this one more than the first option

Yup, me too. A hell of a lot more actually.

Whilst I agree with the spirit of what has been said, I still think it's a resonable request in the short term, to address a problem that a lot of seasoned developers seem to be having.

Clearly there are some fundamental design choices that need re-visiting, but that's surely for a future major version of Umbraco? In the mean time, why not alleviate a bloody annoying design issue with a super simple fix?

At the end of the day, these variations of Doc Types do exist. A new developer will eventually run into them, so you're really not solving anything by keeping them obfuscated.

[marcemarc]

I have created a PR here:

https://github.com/umbraco/Umbraco-CMS/pull/6779

That allows the values iselement=true and culturevary=true to be read from the querystring when creating a new Document Type...

In the short term if this were pulled in, it would allow someone to create a package to wire up an addition to the Create menu... for the common task of creating an Element Document Type... but leave the menu that needs some thought moving forwards 'as is' until their is capacity + RFC etc to discuss...

... but the menu can still be discussed on this issue for when HQ have room to revisit the topic...

So the above is so I can try to test my further vague thoughts on this: eg first guess is:

Document Type Document Type With Template

Composition Type Element Type Variant Type Folder

Notice how Document Type is the first option - and the second option is now Document Type With Template...

This is really easy to understand, that one option is to create a Doc Type, and another option is to create a Doc Type with a template...

... as a newbie to Umbraco you have to learn what a Document Type is but you can immediately understand now what these two options are...

The current display of Document Type (that automatically creates a template) and Document Type Without Template - is harder to grasp for beginners, as it immediately questions why you would create one without a template, and it's not clear that you 'create a Template' when you just choose 'Document Type'... when you want to add a Composition or Element type at the moment you'll find your brain pausing for a nanosecond, as each time this option is presented you have to 'work it out'.. this is because the simpler option is presented 'after' the more complex option in the list, and specifying a negative term 'without' feels like a warning... and in your head you are thinking 'composition' or 'element' and there is no synergy with the 'Document Type Without Template' label...

Changing this to

Document Type Document Type With Template

will I think have a massive boost to the UX and the understanding of working with Umbraco and doc types for the first time, and also for experienced users too.

But it needs to be played around with, hence the PR, I'm not sure where Document Type Collection fits into the narrative yet

Anyway hope the PR moves the issue on a little bit.

[kjac]

@marcemarc maybe it's just my lack of imagination... But I don't see how it's possible to inject create options from a package?

[marcemarc]

@kjac I was thinking tap into the Tree rendering and menu events to remove the existing Create option and replace it with a custom SuperCreate option, that opened up a different custom view, which could then rearrange options as desired to experiment further, with it's own custom supporting js controller 'if necessary' ...

... but if this is not possible then it's still a timesaver to bookmark the Url!

Anyway that is how I think it is possible, but would have to try and then admit failure! It's the sort of thing I've done before in V7 customising forms menu and content tree menu, to provider further advanced options, but it's entirely possible I am completely wrong!! and you questioning it makes me think it probably isn't possible :-P!!!! if so I'll close the PR and walk away sheepishly!

[kjac]

Hehe I am not saying it can't be done. I'd be interested in seeing it done, really. I guess my concern is mostly adding extensibility stuff to the core that's practically impossible to use. It all has to be maintained and kept working for so and so long to avoid breaking changes.

[marcemarc]

Raising the PR is just the quickest way to find out.

But agree if the overhead of maintaining this look for a QueryString parameter is greater than any perceived benefit for opening up the process to package experimentation... then we can forget it was ever mentioned and close the PR!

[marcemarc]

@kjac "Rome was not built in a day"... https://youtu.be/cIKtCMdsACA

[kjac]

Color me impressed 😂

[ronaldbarendse]

Reading through the comments, I think we can all agree on the following:

1. Keep the amount of options to a minimum, so you don't get overwhelmed (especially newcomers);
2. Having descriptions on every option helps making the right choice easier (also targeted to newcomers);
3. The following choices are required, as you can't switch between these:
   • Document type (without template);
   • Folder (container);
4. Make sure we also include a way to quickly setup variant document types, element types and collections (targeted to advanced users);
5. When creating a nested/inherited document type, we should limit the choices and make sure the correct defaults are used (e.g. creating a document type below a culture variant 'Text page' would make sure the 'Allow varying by culture' is also enabled and you should only be allowed to create element types below elements);
6. Compositions can't be created (they are document types inherited by others).

---

A clean create dialog could have the following options with descriptions:

1. Document type
2. Document type collection
3. Element type
4. Folder

Changing a document type to an element (and vice-versa) can be a destructive operation, so I think that should be available as an action (in the tree, above Move/Copy) instead of a checkbox. This would also justify adding it as a separate option.

When adding a document type collection, the following dialog is shown:

We should probably add a checkbox 'Allow varying by culture' and make sure the umb-checkbox (toggle) is used here... Because this action creates and saves two document types with optional templates, having this extra option and step is justified IMHO.

So we're only left with finding a way to quickly create a culture variant document type and related template (without adding them as new options). I don't think we should ask this within the dialog (like the document type collection above), as that would add an additional step and repeat most of the 'Permissions/Templates' tab.

But we already have keyboard shortcuts! 🎉 So if we added nice notifications to indicate toggling options on/off (list view, root, culture variants, default template) and make sure adding a new/default template actually works, this could be a great way for advanced users to quickly setup new document types:

---

So to summarize, the following would be required for all this:

• Clean up the create options and add descriptions (only the 4 options from above);
• Move changing document/element type to a tree action (instead of the checkbox);
• Clean up the create document type collection dialog (allow culture variants and use toggles);
• Make sure only the right options are available for nested/inherited document types and the defaults are correct (variants below variants and elements below elements);
• Allow creating a default template (using the shortcut);
• Optionally: add notifications when using a shortcuts.

We could optionally add suggestion boxes right after creating a new document type. This could be only text (e.g. 'You can use keyboard shortcuts to allow varying by culture.') or even include buttons to execute an action. This would however require a new UI component, so that should IMHO only be added if it can be used in other contexts.

[marcemarc]

Hi @nul800sebastiaan I put together a package following experimentation with the menu options, mainly aimed at people whe are new to Umbraco: https://our.umbraco.com/packages/backoffice-extensions/super-doc-type-create-menu/ Git Repo: https://github.com/marcemarc/Moriyama.SuperDocTypeCreate and blog post explaining my thoughts: https://moriyama.co.uk/about-us/news/creating-doctypes-in-umbraco-v8/ ... in case this is useful for when this topic reaches the top of the HQ ideas list...

[ronaldbarendse]

@marcemarc Very good reasoning and great to see this can already be customised using a package!

However, I really think we should have these options in Umbraco core (with slightly refined descriptions). Together with fixing the other issues from my previous comment, that would be a great enhancement for both newcomers and advanced users.

[TimGeyssens]

@nul800sebastiaan Marcs idea is perfect I think, what are the odds that could go core? Since I think it has value for the implementor experience... (both for newbies and experts)

[nul800sebastiaan]

While the state/* labels have changed a little over the past year, this blog posts still describes the issue tracker process quite well: https://umbraco.com/blog/the-umbraco-issue-tracker-process/

Currently this issue is labeled as status/idea. Which is described as:

The “idea” status is used to indicate that the current item is a great idea, but neither HQ nor the community can make progress on at the moment. This means the issue is effectively parked but we’re happy for more feedback and discussion on it. We won’t close it since we agree it’s something we want to have in place in the future.

We regularly evaluate the list of ideas to see if they still make sense and if they fit into the themes of what we’re working on in the near future.

Currently, this feature doesn't fit in the things we're working on and we want to make larger changes but we also don't have the resources to properly describe the way we'd like to see those changes implemented. So for now, this idea is great, the discussions are great and they will be taken into account once we get some time to focus on this again.

[TimGeyssens]

@nul800sebastiaan thanks for the clarification, but I guess the current "Add 'Add as Element' to Doc Type Create menu" doesn't cover the current situation anymore, have you seen @marcemarc idea? Since it basicly is a refactor of the create doc type menu... with more clear options for the current way you would use doctypes

[nul800sebastiaan]

As I said, we want to make larger changes (than "just" adding a new option). All the input from this discussion is valuable and useful, once we have the time to put in to it.

[edit]: whoops, fat-fingers.. didn't mean to close

[TimGeyssens]

Awesome, thanks for the details!

[DanDiplo]

Just want to say I'm totally in favour of the way Marc is proposing. I've lost count of the number of times I've gone to create a doc type for use with Nested Content but forgot to to tick the "Is Element Type?" checkbox (hidden on another tab). This then invariably means going to create a datatype to use with the doctype, then remembering I've forgotten to tick it, then having to cancel out, go back to the doctype, click it and save it, then go back to create the Nested Content datatype again. Very annoying!

I'd count myself as an experienced user, but the UI just makes this too easy. Making it explicit up front would stop loads of frustration!

[nathanwoulfe]

Long time coming, but good things come to those who wait 🤷. This is merged to v8/contrib, hopefully released as part of 8.12