Member Type: "Member":
Textarea, Label (decimal), True/False
So those data types are definitely required out of the box.
But then what about the others, (created during installation)?
Approved Color
Checkbox list
Content Picker
Date Picker
Date Picker with time
Dropdown
Dropdown multiple
Media Picker
Member Picker
Multi URL Picker
Multiple Media Picker
Numeric
Radiobox
Richtext editor
Tags
Textstring
Are all these needed? Some of these I'm fine with, such as Textstring, Richtext Editor, Content Picker, Media Picker - others I'm less convinced about - especially those that require custom configuration, e.g. Checkbox, Dropdown, Radiobox.
Looking at each of the built-in property-editors, I've put down my thoughts...
Why is "Checkbox list", "Dropdown", "Dropdown multiple" and "Radiobox" available out of the box? with no prevalues set.
If I wanted a list with custom options, my instinct would be to create a new Data Type instance, and not use the default one.
As for the configuration fields...
"Add prevalue" - the term "prevalue" is still being used - needs a better (modern) term. (Options? List Items?)
Should the prevalues control use the "Multiple Textstring" editor? They both appear similar, (list of strings values).
Why have both "Dropdown" and "Dropdown multiple" entries? They are the same property-editor, with a checkbox difference.
"Date Picker" and "Date Picker with time" - again same property-editor with a subtle configuration difference.
Could there be a way to toggle between the two, without requiring knowledge of adding "HH:mm:ss" to the date format?
"Multinode Treepicker" - I'm not even sure that the name of this property-editor reflects what it does anymore. It can pick multiple nodes from trees? (?)
Having options for Content, Media and Members feels overkill and legacy for a single property-editor, too many options.
Generally I've only used MNTP for picking Content - maybe that should be the primary focus, so to reduce complexity.
XPath Start Node option - is that still relevant in v8?
Why would you pick Media using MNTP? given that the "Multiple Media Picker" is available.
I wonder if "Content Picker" and "Multinode Treepicker", could these be combined? e.g. have a "pick multiple" on "Content Picker"?
"Image Cropper", the UI for adding the crops doesn't feel consistent with (modern) Umbraco UI.
"Numeric", the configuration options are empty out the box. These could be set up with sensible defaults, e.g. 1-100, step 1?
"True/false" (aka "Checkbox", aka "boolean"), the labelling of this data type / property-editor confuses me. From a historic/legacy perspective it was named "True/False", is that still relevant?
In later v7 versions (and v8), it's got changed to a toggle control, no longer a checkbox - maybe we shouldn't call it a checkbox anymore?
Specifically on the "True/false" data type, if you modify it, saving it will remove the slash from the name, e.g. "Truefalse". Is it a bug? Should slashes be allowed? I'm not sure - hence the question.
The AngularJs component is called "boolean". But is it a toggle? Not sure.
There's a configuration field called "Write a label text". Seems strange to have this here, unless if it supported a localizable dictionary label? but it doesn't.
"Email Address" - I'd have thought this would have been used on the "Member" (Member Type), but it isn't. Not sure of its purpose.
It has a configuration option called "Required" - why? Wouldn't this be configured at property level? e.g. set it as mandatory on the doctype?
I wonder if some other built-in property-editors should be configured at data types out of the box? e.g. "Slider" and "Multi Url Picker"?
</random-thoughts>
What are your thoughts on the built-in data types?
Why have both "Dropdown" and "Dropdown multiple" entries? They are the same property-editor, with a checkbox difference.
I think they combined these into a single property editor in recent versions, right?
Image Cropper
"Image Cropper", the UI for adding the crops doesn't feel consistent with (modern) Umbraco UI.
Not only that, I haven't seen a good way of configuring only the appropriate crops for a given image (without a bunch of extra noise of crops unrelated to the current widget). Don't want it in the content section, because then the media item needs to be uploaded directly to there (IIRC). Don't want it in the media section, because it's weird to split across multiple media types for images.
I would also like to see the concept of "crop sets". Right now, you can name crops. However, you can't group them based on usage. For example, I might have crops for "Callout (Desktop)", "Callout (Tablet)", and "Callout (Mobile"), but I can't group them.
Start Node
XPath Start Node option - is that still relevant in v8?
Would be nifty to specify a C# function that is capable of choosing the start node rather than have it be XSLT. Or maybe even a JavaScript function.
Date
"Date Picker" and "Date Picker with time" - again same property-editor with a subtle configuration difference.
Would be nice to have a "time picker" too (rather, a date/time picker which includes an option for just time). Useful, for example, when creating an "open hours" feature for a business (e.g., 9AM-5PM).
Maybe this thing should be a single property editor with three options: "Date", "Time", "Date + Time".
Why have both "Dropdown" and "Dropdown multiple" entries? They are the same property-editor, with a checkbox difference.
I think they combined these into a single property editor in recent versions, right?
Yeah, they are both using the "Umbraco.Dropdown.Flexible" property-editor. I was more questioning why they are both present in a default install.
Start Node
Interesting one about this. The C# function was made for Umbraco v5. I recall at the time thinking 2 things... 1. This is awesome! 2. It's overwhelming for most devs.
Regarding the cropper, I rarely add custom crops and try to talk clients out of having them, as they just cause more problems when you are doing responsive images, ie. with Slimsy.
They are good as previews though, so if you could disable the custom cropping ability, and just show the previews in different dimensions, that would be awesome.
Also grouping of crops would be nice in that case, as Nicholas mentions.
I really like the idea Jeffrey mentioned at Codegarden, where you could add a media picker to a doctype, where the user could be able to choose between uploading a new image, selecting one from the media library, or from a thirdparty provider (Dropbox, Skyfish, Unsplash, Giphy etc.). And then be able to set crops/focal point from the node instead.
Would love to see some progress on that.
Regarding data types in general, I have also wondered about the need for all those preconfigured datatypes. Especially after 7.4, where the UI pushes the user to create new data types for every property.
The built-ins, have also caused problems on cloud, where a deploy-export file, would add .uda files for them, but their Guid keys didn't match up with the ones in other environments, causing schema mismatches.
Something from the back of my mind (I could be wrong but it sound clever! ;-)) tells me that the reason why some of the datatypes are configured during installation was to make it visible that one had a few options of using built-in datatypes - I mean if they are not visible in the list it's easy for new comers to overlook that the datatypes exists at all.
Currently getting a quick overlook once installed is actually a but hard since it requires you to right click the "Data types" folder and the click "Create datatype" where you then have a dropdownlist with a lot of names... Then you need to figure out if some of the names match something that you could be looking for and it's first when you have made a choice that you can see the available config options.
But it's also a mess that many datatypes are pre-configured whereas there are quite a few that are not either.
I'm wondering if it would perhaps be better to have some kind of dashboard listing the various data types in a card-like view with a little icon, name and description instead and then only have a few pre-configured data type out of the box? Could this work? (I'm not sure if it's currently possible to add a dashboard for the data types folder though).
Personally I never use the pre-configured data types - I usually create a bunch of folders for each data type like "Rich Text Editor" and then add my own configured instances in there to keep things "clean".
I also agree that some of the data types should probably be marked as obsolete and that we need to change the "Checkbox, Truefalse, whatever" to "Toggle". I think that the label for the toggle is because there can be shown a text to the right of the toggle when the label has a value. But I have not tested if it works in v8 - It used to in v7.
Thoughts on built-in Data Types
Warning, this is probably a long winded rambling topic!
I've often wondered by the Data Types that come built-in with Umbraco. Why certain ones are configured during installation and where are they used.
So those data types are definitely required out of the box.
But then what about the others, (created during installation)?
Are all these needed? Some of these I'm fine with, such as Textstring, Richtext Editor, Content Picker, Media Picker - others I'm less convinced about - especially those that require custom configuration, e.g. Checkbox, Dropdown, Radiobox.
Looking at each of the built-in property-editors, I've put down my thoughts...
Why is "Checkbox list", "Dropdown", "Dropdown multiple" and "Radiobox" available out of the box? with no prevalues set.
If I wanted a list with custom options, my instinct would be to create a new Data Type instance, and not use the default one.
Why have both "Dropdown" and "Dropdown multiple" entries? They are the same property-editor, with a checkbox difference.
"Date Picker" and "Date Picker with time" - again same property-editor with a subtle configuration difference.
"Multinode Treepicker" - I'm not even sure that the name of this property-editor reflects what it does anymore. It can pick multiple nodes from trees? (?)
I wonder if "Content Picker" and "Multinode Treepicker", could these be combined? e.g. have a "pick multiple" on "Content Picker"?
"Image Cropper", the UI for adding the crops doesn't feel consistent with (modern) Umbraco UI.
"Numeric", the configuration options are empty out the box. These could be set up with sensible defaults, e.g. 1-100, step 1?
"True/false" (aka "Checkbox", aka "boolean"), the labelling of this data type / property-editor confuses me. From a historic/legacy perspective it was named "True/False", is that still relevant?
"Email Address" - I'd have thought this would have been used on the "Member" (Member Type), but it isn't. Not sure of its purpose.
I wonder if some other built-in property-editors should be configured at data types out of the box? e.g. "Slider" and "Multi Url Picker"?
What are your thoughts on the built-in data types?
Cheers,
- Lee
Dropdown
I think they combined these into a single property editor in recent versions, right?
Image Cropper
Not only that, I haven't seen a good way of configuring only the appropriate crops for a given image (without a bunch of extra noise of crops unrelated to the current widget). Don't want it in the content section, because then the media item needs to be uploaded directly to there (IIRC). Don't want it in the media section, because it's weird to split across multiple media types for images.
I would also like to see the concept of "crop sets". Right now, you can name crops. However, you can't group them based on usage. For example, I might have crops for "Callout (Desktop)", "Callout (Tablet)", and "Callout (Mobile"), but I can't group them.
Start Node
Would be nifty to specify a C# function that is capable of choosing the start node rather than have it be XSLT. Or maybe even a JavaScript function.
Date
Would be nice to have a "time picker" too (rather, a date/time picker which includes an option for just time). Useful, for example, when creating an "open hours" feature for a business (e.g., 9AM-5PM).
Maybe this thing should be a single property editor with three options: "Date", "Time", "Date + Time".
Yeah, they are both using the "Umbraco.Dropdown.Flexible" property-editor. I was more questioning why they are both present in a default install.
Regarding the cropper, I rarely add custom crops and try to talk clients out of having them, as they just cause more problems when you are doing responsive images, ie. with Slimsy.
They are good as previews though, so if you could disable the custom cropping ability, and just show the previews in different dimensions, that would be awesome.
Also grouping of crops would be nice in that case, as Nicholas mentions.
I really like the idea Jeffrey mentioned at Codegarden, where you could add a media picker to a doctype, where the user could be able to choose between uploading a new image, selecting one from the media library, or from a thirdparty provider (Dropbox, Skyfish, Unsplash, Giphy etc.). And then be able to set crops/focal point from the node instead.
Would love to see some progress on that.
Regarding data types in general, I have also wondered about the need for all those preconfigured datatypes. Especially after 7.4, where the UI pushes the user to create new data types for every property.
The built-ins, have also caused problems on cloud, where a
deploy-exportfile, would add .uda files for them, but their Guid keys didn't match up with the ones in other environments, causing schema mismatches.Hi Lee
I think these are some good observations.
Something from the back of my mind (I could be wrong but it sound clever! ;-)) tells me that the reason why some of the datatypes are configured during installation was to make it visible that one had a few options of using built-in datatypes - I mean if they are not visible in the list it's easy for new comers to overlook that the datatypes exists at all.
Currently getting a quick overlook once installed is actually a but hard since it requires you to right click the "Data types" folder and the click "Create datatype" where you then have a dropdownlist with a lot of names... Then you need to figure out if some of the names match something that you could be looking for and it's first when you have made a choice that you can see the available config options.
But it's also a mess that many datatypes are pre-configured whereas there are quite a few that are not either.
I'm wondering if it would perhaps be better to have some kind of dashboard listing the various data types in a card-like view with a little icon, name and description instead and then only have a few pre-configured data type out of the box? Could this work? (I'm not sure if it's currently possible to add a dashboard for the data types folder though).
Personally I never use the pre-configured data types - I usually create a bunch of folders for each data type like "Rich Text Editor" and then add my own configured instances in there to keep things "clean".
I also agree that some of the data types should probably be marked as obsolete and that we need to change the "Checkbox, Truefalse, whatever" to "Toggle". I think that the label for the toggle is because there can be shown a text to the right of the toggle when the label has a value. But I have not tested if it works in v8 - It used to in v7.
Just my 2 cents :-)
/Jan
is working on a reply...