Morning all,
So on the train commute into work this morning, I had an idea that I thought may be good for Umbraco developers, but it may not good of an idea as I first thought.
The idea
I thought it would be great to allow beginners to easily create document types from a library of 'starting points'. Such as a Blog Post, with common properties etc...
The good part of this creation would be that these 'starting points' will come from a common library shared in the community, so they can be tweaked, improved on and new ones added via a public GitHub repo.
A further idea to expand on this is to have a new button or context menu item perhaps that would allow you to generate & save your document type to disk so that it could be uploaded to the community repo for reuse.
But if you wanted a company & internal repository for your projects then you could change an AppSetting or similar to point to your own private repo.
Feedback & thoughts?
Unfortunately I don't have as much time as I used to, so before even attempting to put some time into this, I want to know firstly is this even a good idea and would it be something people want to use?
Got a better suggestion or ideas on how to implement, or even time to help me collaborate then please let me know.
I think it would be hard to do that without providing some partial views to be used as a base. Even if they were just basic partials and the user was responsible for calling them.
If I get any more ideas/thoughts I'll let you know.
My initial thought is to look at a structure and then develop the simple document type
eg Home Page (usually separate design and structure)
listing page
news
faq
listing child
- news page
- faq item
Generic content page
grid page
non grid page
Search results Page
Error Page (404)
Settings page
These are the kind of things I have put in my settings:
- number of search results to display
- generic sitename
- email address for use
- menu selector
- footer options
- social share options
- error messaging
I certainly think common tabs and properties that are created for all sites is a good idea and would be a real time saver. Of course there are other ways of doing this like creating your own starter kits.
A simple way of doing this could be a couple of root master doc types that all other doc types inherit from.
e.g. a Content Master doc type could include the following tabs:
Content - Page heading, RTE (depends on people's preference with The Grid)
SEO (Meta title, meta description, open graph properties)
General properties - obviously this is always there but this is where I usually put any "built in" Umbraco properties such as umbraciNaviHide and redirect to (can't remember Umbraco alias).
On the latter, I'd say sometimes new users aren't aware of these Umbraco built in gems so would be good to have them "out of the box" so to speak
Warren was asking about uSync file formats for this.
for doctypes It is the same (nearly) as the umbraco one - but it does hierarchy stuff using Guids not ids.
But you could use the usync.core (it's its own standalone bit now), to do the imports for you.
So you could have xml files in the package, user picks them usync.core does the import. This way you could have composites and stuff (as all the mappings would be managed for you by usync)
This is how the localgovstarterkit does its content importing dashboard, it has an XML file of content, and it passes it through the uSync.core when the user presses the import button. It means they can pick different content to import.
When you are putting stuff in you need to know things like the master doctype ID, or the IDs of the composite types.
The normal imports will do this usually by alias. - however if the alias changes (the user renames it) then you loose that link, this is also true of the properties inside a doctype.
The usync.core also does mappings for things like templates & content nodes (e.g for MNTP).
The other thing usync will do (and you need to workout if this is good or bad for you!) is it will always completely sync a doctype when you import it.
The standard umbraco package imports are additive. So if you import a doctype, then change some things, and then import it again; only new properties and settings are added it doesn't wipe anything you have done.
The uSync code will force changes, so it will delete new properties, rename properties and basically make a doctype look exactly like you want it to... this may be a bad thing depending on what you are doing.
Sounds like using uSync.Core Library would be useful. So can I pull this in via NuGet without the uSync main package being installed?
I was thinking of adding a couple of extra fields which is name, description & author.
So that a more verbose name, description could be given in my custom UI for picking these 'Starting Points'.
As the name of the Document Type may be Blog Post but the Starting Point Name may be 'Blog Post with Social Sharing' for example.
Would love to pick your brains Kevin, as you obviously have a lot of experience with importing/exporting stuff out of Umbraco from your uSync package. So any words of advise & wisdom you can share would be awesome :)
It will lower the barrier of entry for newbies and maybe help teach best practices as well?!
Somekind of grouping like the ones mentioned by Ravi and Ben would be useful. Especially, the "General properties" with Umbraco's automagical property names spelled out correctly and properly described.
I like the idea of having the doctypes and templates split . Template structure and design is even more opinionated than the doctypes themselves.
Perhaps a sister project could be a template stub generator where you could tick of OpenGraph,Schema.org, Microformats or what ever turns you or a search engine on. Besides razor view optional outputs could be view models, service descriptions and the like on demand.
I really like where this is going, Warren! I remember how much i learned from your starter kit website package way back in the day. This very much sounds like the next iteration of that idea. Can't wait to see how this evolves! #H5YR!!
I just want one a rapid way for myself & the company to create common doctypes quickly (using a private repo) & then for people new to the platform to create common document types quickly.
The common document types & what they will contain will be the trickiest bit, as everyone has their own different ways of doing things.
Very interested in seeing where you landed with this as our company is currently in the midst of a similar effort - we've done a lot with shared libraries, extensions, conventions, etc - but are continually striving to make things more streamlined and standardized so we can spend less time reinventing the wheel and more time on higher level and creative tasks.
Hi Steve,
As with most things currently I get an idea & then it seems to die out because I just don't have the spare/free time to do this, free hack time is nearly non existent with our little one, got as far as creating the repo :-P
https://github.com/warrenbuckley/Starting-Points-Package
But if you have ideas or started building this then thats is fantastic as I a sure the community will love it & welcome it with open arms.
Happy to discuss any ideas or thoughts I had about implementation.
Feedback on Idea: Starting Points aka Common DocTypes
Morning all,
So on the train commute into work this morning, I had an idea that I thought may be good for Umbraco developers, but it may not good of an idea as I first thought.
The idea
I thought it would be great to allow beginners to easily create document types from a library of 'starting points'. Such as a Blog Post, with common properties etc...
The good part of this creation would be that these 'starting points' will come from a common library shared in the community, so they can be tweaked, improved on and new ones added via a public GitHub repo.
A further idea to expand on this is to have a new button or context menu item perhaps that would allow you to generate & save your document type to disk so that it could be uploaded to the community repo for reuse.
But if you wanted a company & internal repository for your projects then you could change an AppSetting or similar to point to your own private repo.
Feedback & thoughts?
Unfortunately I don't have as much time as I used to, so before even attempting to put some time into this, I want to know firstly is this even a good idea and would it be something people want to use?
Got a better suggestion or ideas on how to implement, or even time to help me collaborate then please let me know.
Thanks,
Warren
I think it would be a great idea. One of the issues I see though is people don't know what they want.
It would almost be best to see if it's possible with "property groups"
So you can create a composite page by quickly selecting pre-defined groups of properties/tabs.
For example:
News Article Base Properties could include:
Then you might have Facebook Share Properties which include the base Open graph properties.
So a user could create a page that derives from both Article base and Facebook Share.
However, would you create a template auto-generation method? So all the properties could use a default partial view for each set to render them out?
Hi Nik
I did not think about template generation, I am just thinking templates for your data aka DocTypes so to speak is my initial idea/thoughts.
I am not sure how I would approach that problem with composite document types at the moment & raises an interesting challenge.
Thanks for the feedback
I think it would be hard to do that without providing some partial views to be used as a base. Even if they were just basic partials and the user was responsible for calling them.
If I get any more ideas/thoughts I'll let you know.
Yes but auto scaffolding a basic view/template could be a bit tricky. So I will have to think about this further on implementation.
My initial thought is to look at a structure and then develop the simple document type
eg Home Page (usually separate design and structure)
listing page
listing child - news page - faq item
Generic content page
Search results Page Error Page (404)
Settings page These are the kind of things I have put in my settings: - number of search results to display - generic sitename - email address for use - menu selector - footer options - social share options - error messaging
this is an ace idea, i think it will help newbies give them a helping hand and also create a structure so devs can find things in consistent places
I certainly think common tabs and properties that are created for all sites is a good idea and would be a real time saver. Of course there are other ways of doing this like creating your own starter kits.
A simple way of doing this could be a couple of root master doc types that all other doc types inherit from.
e.g. a Content Master doc type could include the following tabs:
On the latter, I'd say sometimes new users aren't aware of these Umbraco built in gems so would be good to have them "out of the box" so to speak
umbracoNaviHide, redirectTo, showInFooter just to name a few.
Hi,
Warren was asking about uSync file formats for this.
for doctypes It is the same (nearly) as the umbraco one - but it does hierarchy stuff using Guids not ids.
But you could use the usync.core (it's its own standalone bit now), to do the imports for you.
So you could have xml files in the package, user picks them usync.core does the import. This way you could have composites and stuff (as all the mappings would be managed for you by usync)
This is how the localgovstarterkit does its content importing dashboard, it has an XML file of content, and it passes it through the uSync.core when the user presses the import button. It means they can pick different content to import.
Interesting Kevin,
That there is a uSync.Core what would this offer me say over the Umbraco APIs to create a new Document Type?
Short answer : Id mapping.
When you are putting stuff in you need to know things like the master doctype ID, or the IDs of the composite types.
The normal imports will do this usually by alias. - however if the alias changes (the user renames it) then you loose that link, this is also true of the properties inside a doctype.
The usync.core also does mappings for things like templates & content nodes (e.g for MNTP).
The other thing usync will do (and you need to workout if this is good or bad for you!) is it will always completely sync a doctype when you import it.
The standard umbraco package imports are additive. So if you import a doctype, then change some things, and then import it again; only new properties and settings are added it doesn't wipe anything you have done.
The uSync code will force changes, so it will delete new properties, rename properties and basically make a doctype look exactly like you want it to... this may be a bad thing depending on what you are doing.
Sounds like using uSync.Core Library would be useful. So can I pull this in via NuGet without the uSync main package being installed?
I was thinking of adding a couple of extra fields which is name, description & author.
So that a more verbose name, description could be given in my custom UI for picking these 'Starting Points'.
As the name of the Document Type may be Blog Post but the Starting Point Name may be 'Blog Post with Social Sharing' for example.
Would love to pick your brains Kevin, as you obviously have a lot of experience with importing/exporting stuff out of Umbraco from your uSync package. So any words of advise & wisdom you can share would be awesome :)
yep
https://www.nuget.org/packages/uSync.Core/
its not very well documented yet - that's my fault - but basically .
intialize usync somewhere
then you can call the serializers on
uSyncCoreContext.InstanceYou pass around XElements - so you can add anything extra before and after if you wanted to. they should just get ignored.
I'll put some more stuff in the usync project as not to clutter this up :)
hi, more usync.core detail over in the usync project if you need it.
https://our.umbraco.org/projects/developer-tools/usync/usync//72001-using-the-usynccore
This is an excellent idea.
It will lower the barrier of entry for newbies and maybe help teach best practices as well?!
Somekind of grouping like the ones mentioned by Ravi and Ben would be useful. Especially, the "General properties" with Umbraco's automagical property names spelled out correctly and properly described.
I like the idea of having the doctypes and templates split . Template structure and design is even more opinionated than the doctypes themselves.
Perhaps a sister project could be a template stub generator where you could tick of OpenGraph,Schema.org, Microformats or what ever turns you or a search engine on. Besides razor view optional outputs could be view models, service descriptions and the like on demand.
I really like where this is going, Warren! I remember how much i learned from your starter kit website package way back in the day. This very much sounds like the next iteration of that idea. Can't wait to see how this evolves! #H5YR!!
Thanks for the compliment Bob!
I just want one a rapid way for myself & the company to create common doctypes quickly (using a private repo) & then for people new to the platform to create common document types quickly.
The common document types & what they will contain will be the trickiest bit, as everyone has their own different ways of doing things.
Very interested in seeing where you landed with this as our company is currently in the midst of a similar effort - we've done a lot with shared libraries, extensions, conventions, etc - but are continually striving to make things more streamlined and standardized so we can spend less time reinventing the wheel and more time on higher level and creative tasks.
So - any updates or lessons learned?
Hi Steve,
As with most things currently I get an idea & then it seems to die out because I just don't have the spare/free time to do this, free hack time is nearly non existent with our little one, got as far as creating the repo :-P https://github.com/warrenbuckley/Starting-Points-Package
But if you have ideas or started building this then thats is fantastic as I a sure the community will love it & welcome it with open arms.
Happy to discuss any ideas or thoughts I had about implementation.
is working on a reply...