Content Types are "the big show" when it comes to getting content, info, data, other into Kentico Cloud for a project. Just as there will be many different types of content - there will equally be many different types of role involved in managing that content e.g. editor, developer, admin etc.
As an example, with Content Types we see people modelling:
1. First class content entities e.g. News, Article etc.
2. Partial content entities e.g. code snippets, call to action
3. Navigation content entities e.g. navigation group, navigation item
4. UI localization content entities e.g. resource string group, resource string item
5. Workarounds for pretty much anything else that needs stored and edited by someone via the UI
Based on the above, and also on having this request in a sales call ("can I limit what types of content a given role can access"), it would be good if we could manage access between a user's role and a Content Type - especially if the model is going to become large, full of Content Types that a standard editor will never use etc.
In this way, and the following is only an example, you could configure a project so that editors can manage (1) and (2), and more advanced users can manage (3), (4) and (5). Ideally the UI only presents Content Types that you can manage.
We had recently some discussions on how organize a client list into different industries. There were two solutions on the table:
1. Create a content type called industries and apply an inventory item as a modular content to a client
2. Create a taxonomy group, called industries and tag the content item "client" with a tag
Our dev favored option 2, however, it seems not to be possible to localize a tag and it would therefor never be possible to display the tag in the UI.
What would the official recommendation for this?
I've developed a tool that makes it easy to request Kentico Cloud and overview obtained content in JSON format. I would be pleased for any feedback.
Here you can check the tool: https://www.milanlund.com/request-delivery/
Here you can get more information: https://www.milanlund.com/blog/kentico-cloud-request-delivery
I would like to start a discussion around using MS Word (or other external tool) for content preparation and editing. Currently MS Word is often used to prepare, review, spell check etc. content, and then the result is pasted into the CMS (of any kind).
The question is whether this is being widely considered a workaround that is somehow necessary because CMS editors lack some functionality or other aspects that MS Word offers them, or it is a natural part of the content management process that people would still like to use even if the CMS editing interface was perfect.
What we heard so far is that people use MS Word in order to:
- Have intuitive UI that they know
- Check spelling or grammar
- Track changes from original version
- Add inline comments
- Be able to sent the document for review
- Do not need to log into CMS to prepare content
I would like to hear any thoughts you may have around this. In particular:
- What are the aspects that make people use Word?
- How their current process involving Word looks like within initial content import / further editing?
- How clean is the pasted content, and are there some extra steps necessary to clean it besides of paste?
- How their ideal process would look like if CMS would have all the features they would want?
- What features the CMS would have to offer to achieve this ideal process?
- Is it better to have a CMS that does a perfect paste from Word, or a CMS that offers features like Word? Or both? Or other?
The reason why I am asking is to figure out what scope and what amount of investment to the Kentico Cloud content editing interface is worth it in order to improve the content editing experience. It would be unfortunate if we spent time to provide similar features that Word has, but people would still use Word instead of those built-in features.
We are interested in any opinions from anyone who is dealing with MS Word or other similar external tool in their content editing process, not just from current Kentico users.