Improvements in content items preview

FilipLigacFilipLigac Member, Kentico Staff mod
edited May 2017 in Content Strategy

This is a feedback we received from one of the customers. He's looking for an improved version of content items preview. Based on my understanding, the current preview of content items is not sufficient for his needs (Configuring preview of content items).

"I hope this can help you serve customers with requirements like mine.

I signed up to test your headless CMS, as I'm looking for an alternative to GatherContent — a product I'm very familiar with.

The reason I didn't continue with my Kentico account was simply this: I couldn't preview a 'full, complete HTML page, including all content' within your service. Or at least I couldn't find out how to.

I realise it's easy enough to do this if I was hosting my own site, using your API. This is your core offering. But I'm often modelling content a long time before there's a production (or even UAT) environment accessible for me to plumb content into.

I need to preview all material, in full, in context, in your cloud.

What I'm looking for is simply a 'vanilla' rendition of all template/object fields, with basic CSS styling only, so my authors (and importantly, my clients legal teams) can "view each page" in full, at a specific URL, long before the clients' site is established.

It is important, specifically, that any repeating/linked content object(s) are rendered inline (in full, on the same page — rather than each related content block/object requiring a previewer to visit individual records).

I generally deal with highly structured content, that requires many individual fields of varying format. Many 'pages' also feature content/fields from related content objects. This is typically difficult to 'preview', in totality, till the content has been integrated with front-end templates.

By rendering a page as it might appear in full, in a production environment, any content stakeholder can get a clear picture of their material, without the need to use your web app interface, or visit multiple addresses. It's important for many of my stakeholders to read all fields of a particular content object, including metadata, taxonomy and summary content that may appear in specific contexts such as search, mobile only, or in list views etc.

This is what I failed to be able to do with your proxy CMS, and it's why I never returned to my demo after testing it out.

In the end, I opted to use WordPress, with a custom post type plugin (to configure all the content modelling and relationships), then a rudimentary, largely un-styled front-end template to render 'full pages' including any meta, and linked/related/repeating objects. A simple index/sitemap was all that was needed to navigate the structure.

This way a legal team was able to review each page of their prospective site, in full, signing off material before it ever made it to UAT.

On a related topic, I also want to add custom HTML tags (https://developer.mozilla.org/en-US/docs/Web/Web_Components/Custom_Elements) into the rich text field, in code edit mode, and not have them stripped. This will become increasingly important."

Tagged:

Comments

  • JanL@kentico.com[email protected] Czech RepublicMember, Administrator, Kentico Staff admin

    Hi Filip,

    Thanks for posting it. I'll reply to Dave Turnbull here (the author of that feedback).

    Dave, thanks for letting us know! I got the idea. I agree that especially for legal people, it would be great to have a preview feature like that.

    One way of achieving this could be to develop a universal sample site that fits all projects and requires almost zero configuration. Another one would be to implement such preview feature directly into the Content inventory service. Neither of those two ways would be easy to invent but I think it is a great challenge!

    I've linked this conversation into our internal systems so that we have all the context if such feature gets implemented.

    Speaking of context, could you please tell us more about why you'd like the custom HTML tags to be supported in the rich text editor? We'd love to understand your scenario fully. We're about to announce the 'Modular Content in Rich Text' feature these days. It allows you to put an arbitrary amount of content items into a rich text element. Until now, you could put content items into the 'Modular content' elements. Now, the support spreads to 'Rich text' elements too. The content items in the rich text can be of your specific type, similarly to the custom HTML tags. The feature is deployed, you can test it out in the Content inventory service. I think this might be what you're after with the custom HTML tags. We'd be happy to hear if this would help you achieve your goals. We'll appreciate any details you'd share.

    Furthermore, if anyone reading this also wants such features, just let us know in the comments!

    Thanks

    Jan

  • DaveTurnbullDaveTurnbull Member

    Hi Jan

    Thanks for considering the full-on preview. I'm most interested to know if you get any traction with that idea.

    As far as the custom HTML elements go, I've just tried your improved content items in the rich text field — nice one!

    However, I'm not sure it immediately satisfies my requirement.

    What I'd like to be able to do is use my own HTML tag (confirming to the custom elements spec https://www.w3.org/TR/custom-elements/), around the embedded module, so that the content remains semantically valid, e.g. [structured content here from a content modle]

    Presently, I can't see a way to enter a code/edit view of the rich text field, in order to add HTML tags to the field (and have them preserved when switching back to WYSIWYG), e.g. to add tags above and below the content module. Do you allow HTML edit view of a rich text field?

    Nor can I see how I'd define the embedded content module, with a custom HTML element definition/name, in order for the wrapping HTML element to be added automatically, (according to my unique naming requirements), when the content module is added to the rich text field.

    So I'm not sure if I can add my own tags at all. Currently, it's a bit unclear what the inserted content module will 'do' when the containing field is called.

    I can certainly see the content module being inserted, in-line, in the rich field — that's clear. What's not clear, is what this insertion looks like from an HTML perspective, nor how the inserted content module would be delivered via API — e.g. is the content parsed into the containing field, and is there a

    <

    div> with a custom class added as a wrapper?

    By using the W3C spec, I'm aiming to be sure all the tags in the body field remain semantically valid and would be 'true' HTML. It also means I can prevent the 'dirtying up' of the parent field with ad hoc shortcodes and random divs etc.

    One more question… 

    If the inserted content module is, say, an advert/promotional block which I don't want to be delivered along with the rest of the content in every context (in, for example, a mobile-width context the ad may not be wanted), can I request that inserted content modules be withheld via params in the API request?

    Cheers,
    Dave

  • JanL@kentico.com[email protected] Czech RepublicMember, Administrator, Kentico Staff admin

    Hi Dave,

    Good question about the traction. Our product teams are now in process of validating the idea of such preview. If you wish to tell us what exactly you'd expect of the preview functionality, then I've passed your address onto one of our product owners. We'd be glad if you tailored the functionality together with us. I'm also involved, but our product owners always have the most broad overview of the customer's needs. BTW, at Kentico Roadshow, our CEO mentioned that Get Started built a an ad-hoc simple preview site for content editors to get quick glimpse of the results during the process of content production; not only for legal and other post-production reviews. Therefore, I think such feature is well worth considering. But naturally, we can't give any promises at this point.

    Regarding the custom HTML elements, I'll be happy to answer, but, I'd also like to get the full picture if you don't mind.

    The output 'Modular Content in Rich Text' functionality is a HTML string with <object /> tags inside. The tags represent the modular content items.

    Example: <object type="application/kenticocloud" data-type="item" data-codename="john_doe_maintenance_plan_review"></object>

    The tags do not contain the contents of those items, they only point to the modular_content part of the JSON response. It has two benefits. If your app does not support the tags, the processing wouldn't get hurt. And, you can re-use one modular item in multiple rich text fields without having it appear twice in the same JSON response.

    Apart from the current implementation, we're also considering the possibility to serve the rich text content as JSON (besides HTML). That way the internal structure of the content would be completely platform-independent.

    You've triggered my curiosity with your messages. Let me ask a few questions.

    How exactly would you use the custom HTML elements? I mean, do you use these elements just in browsers? Or, do you have some other software that processes those elements?

    I'd guess it is the case of the latter one as I believe the only difference between the two is that the custom HTML elements are allowed to be processed by user agents (unlike the data-* attributes). If you don't process the information in browsers, what is the reason to use these attributes? BTW, the support for data-* attributes among browsers is much broader than that of custom HTML attributes.

    Furthermore, what are the examples of information being stored in such elements? Why do you need to avoid random divs in the output? Citing the HTML5 spec, "The div element has no special meaning at all. It represents its children." The representation of the children is the only semantics. Agents (browsers, custom software) should avoid any actions based on the existence of divs and spans other than acknowledging the container-containee relationships. Is there any special reason to avoid these tags?

    Jan

Sign In or Register to comment.