U4-4915 - Every data type should exist by default

Created by Douglas Robar 14 May 2014, 11:22:51 Updated by Shannon Deminick 26 Jun 2017, 05:41:32

Relates to: U4-5473

Relates to: U4-4822

Every datatype should exist by default, including the MNTP and Image Cropper (and all the others).

Why? Because otherwise people won't know they are there.

I know the argument that these datatypes need configuration and can't be pre-defined out of the box. So do Approved Color, Checkbox list, Dropdown, Dropdown multiple, and Radiobox and nobody complains even though they are useless out of the box without being configured. And... ideally people wouldn't use the 'default' checkbox list but would create a new datatype for each checkbox list they need and assign the appropriate prevalues there.

So it should be with MNTP, Image Cropper, Email address, List view, Macro container, Markdown editor, Member Group Picker, Member Picker, Slider, and User picker.

Discoverability of these super-useful property editors is important.


Sebastiaan Janssen 19 May 2014, 13:48:52

I feel strongly against providing completely useless datatypes. Even if they're filled with dummy dropdowns or no data at all, that is just plain confusing and will in some cases lead to people thinking they are broken.

Maybe add a dashboard with a description and maybe screenshot of each datatype as a dashboard in the developer section. That will expose the available types better.

Dan Okkels Brendstrup 19 May 2014, 14:02:47

While I agree with Doug's argument, there's also the problem that you end up with a lot of datatypes that aren't in use in the current solution, which can be confusing. I've sometimes taken the time to clean out unused datatypes from a solution just so I'm left with only the ones I know are in use in my doctypes. And then gotten burnt by media items that no longer worked because I'd deleted the "label" datatype, not knowing what it was for ;)

So a related feature request would be that each datatype could list the media- and doctypes that it is used on. That would be very useful.

Douglas Robar 19 May 2014, 14:07:08

I also feel strongly and don't think these are completely useless datatypes :)

New users don't understand that they can create additional data types. A dashboard isn't likely to solve that unless it replaces the entire creation process... which would break the convention used everywhere else in the back office so I wouldn't encourage that.

Maybe I'm wrong but I don't think there is a perfect solution here. Instead, this is incremental (and important) improvement. Have a datatype available for use. That's discoverable. Just like checkbox lists and drop-down lists.

The first time a noob uses one on a doctype property they'll ask, "why aren't there any values here?" and will quickly learn to configure the datatype. That's how it's been for years and tho not perfect works well and I've never heard anyone complain about it.

As new users become more advanced and comfortable they'll realize they probably want multiple drop-down lists and will learn how to create them. Again, this has worked well even if not an ideal solution.

The point of this issue is to stop making MNTP, Image Cropper, and other super-useful datatypes second-class citizens behind checkbox and drop-down lists.

If you want to argue removing checkbox and drop-down lists I would be more interested in that discussion. Though even then, the question of discoverability is very important.

Sebastiaan Janssen 19 May 2014, 14:26:33

@brendstrup I believe Concierge show that exact info (though not yet compatible with v7)


"why aren't there any values here?" Well, whenever we add something new that hasn't been like this for years, the response is usually: "x is broken!!". :-)

The "perfect" solution would be more like.. if you try to add a datatype to a document type which is not configured yet, it should give you a warning; even for those silly datatypes that are now added by default without any configuration (which until now I didn't realize that we did that, yuck!)

Douglas Robar 19 May 2014, 14:31:52

Now we're getting somewhere... what should the proper behaviour be?

As a crazy idea... we have all the datatype pre-defined in the datatypes tree. BUT, when you click on one that must be configured (color, checkbox list, mntp, image cropper, etc) you can't use it as-is but need to create a new datatype. All MNTP's might appear nested beneath the place-holder MNTP in the tree.

Actually, I'm not that thrilled with this but let's brainstorm and think outside the box a bit. These cool datatypes are too good to hide from users.

Douglas Robar 19 May 2014, 14:34:45

@brendstrup You could also use http://our.umbraco.org/projects/developer-tools/census, though that doesn't work on v7 yet.

Sebastiaan Janssen 19 May 2014, 14:43:18

@drobar Interesting, but yeah, nesting them would be a bit awkward. I guess adding empty datatypes is a good enough intermediate solution then if we're already doing that now. Then we can fix in a better way later (I know Niels still has ideas about a completely revamped doctype editor, which should just include something like: "Great, you want to add the MNTP datatype here, which configuration should we use for that?" and then a button for "add new configuration")

Dan Okkels Brendstrup 19 May 2014, 19:39:19

@drobar Thanks for the tip about Census, wasn't aware of that package. Very useful.

I agree that shipping empty datatypes is a good start. Perhaps with a better mechanism for adding inline helptext explaining how to configure the given datatype or at least a link to further documentation, such as the [http://our.umbraco.org/documentation/using-umbraco/backoffice-overview/property-editors/built-in-property-editors-v7/DropDown-List datatype documentation] on Our?

Douglas Robar 20 May 2014, 08:21:00

@brendstrup Perhaps something along the lines of U4-4916? Though I like the 'how to use and configure' being somehow built-in as well. Maybe more dashboards for major parts of the various trees ala U4-4918 or something?

I love the wide open thinking we're having; super helpful to the whole project!

Dan Okkels Brendstrup 20 May 2014, 11:27:33

Great idea, Doug. Since the documentation is (or should be, if lacking) already [http://our.umbraco.org/documentation/using-umbraco/backoffice-overview/property-editors/built-in-property-editors-v7/ on Our] there is an obvious place to pull descriptions and screenshots from. Or simply link to.

Shannon Deminick 26 Jun 2017, 05:41:32

Closing issue due to inactivity - see blog post for details https://umbraco.com/blog/issue-tracker-cleanup/

Priority: Normal

Type: Usability Problem

State: Closed


Difficulty: Normal

Category: UI

Backwards Compatible: True

Fix Submitted:

Affected versions: 7.0.4, 7.1.1, 7.1.2

Due in version:


Story Points: