Developer forum

Not sure I understand your question.

Hi Nicolai,

What I meant is the ability to create a more content-rich Long description of the product without the limitations of the HTML editor.

Something similar to how the Visual editor works. With various blocks of texts and images and maybe videos. 

I believe I have heard it mentioned in one of the presentations for DW10 or Rapido 4 but I am not sure if I understand it right.

Thank you,
Adrian

Hi Adrian

Yes - we touch on that often. But the product catalog and PIM is a data engine where data needs to be managed easy and fast and distributed to different channels.

Making long description a content builder makes the data frontend specific and will effectively 'ruin' the data as it will only be useful in the context of one Dynamicweb specific implementation. That is not good for reuse of data and the purpose of PIM.

I understand the need - but I would like us to come up with another approach.

As I see it, one way of solving this is the other way around. Instead of adding a content builder to a product, a product should be added to the content builder.

So the catalog holds the data - a page with content builder holds the visual presentation using that data. Then when you go to that product detail page, you will get the page instead of a regular product detail.

Lets say we have 3 overall scenarios

• Customers with few products, i.e. less than 100
• Customers with good amount of products, i.e. 5-10000
• Customers with lots of products, i.e. 100.000+

They have very different requirements related to this. If I have 100 products, it is ok to build each product page by hand. When I have 5000, that is not an option - I might go for one for each product group or each top product group. When I have 100k I might want one for each product category etc.

Adding visual content builder on a product is not a good option in my view - because it does not cover the above scenarios.

With Swift 1 / Rapido 4, we are discussing a model where you create multiple product detail pages - all taking structured data from a product. Then on the group, you can asign the primary page, and based on that we will render the product in the context of that specific product detail page setup. (In Swift the product detail page is a visual content builder).

In that way you can i.e. create 2 product detail pages using the visual content builder. One aimed at i.e. Bikes that has lots of images and properties and one for i.e. Accesories, which has 1 image and few technical details.

Then by using product categories, we can ensure that products have the data they need in those contexts. Most is actually just properties and images. But it could also be additional marketing texts put into a structure and then used in the product detail and making the data available in feeds etc.

So using an approach like this - and taking it even further, will scale with larger catalogs. Data is one thing, presentation is another.

Makes sense?

BR Nicolai

Hi Nicolai,

I know this subject has been circled before and I understand your arguments. It totally makes sense from the technical perspective.

We should also think about the Admin's perspective.

I am working on a project (actually I am in the analysis phase) where the scope is to decommission an in-house PIM.

This customer has tens of thousands of products and a huge set of attributes (I have mentioned them in some of my recent posts on other subjects). They have combined the interface for editing the long description and they are basically using the content management part from the Product detail interface when they edit the long description.

I believe that they have used a different approach for HTML editor and they are using some sort of JSON-based editor that supports blocks. Not sure if that's the best approach but it seems to work for them. And my job is now very hard because I have to replace what they have, and the editors have started to hate me already :)

I have added a video with a part of how they handle it right now and you can see the way they edit the descriptions of the products. It is not entirely visual until the preview part.

I am not saying that we have to do it like that, but maybe we can find an approach to instantiate a Visual Builder interface (as a modal window) from the Product detail editing interface. Pretty much like how you open now the HTML editor from the PIM interface but maybe open a more complex interface based on the Visual Builder.

Thank you,

Adrian

I am actuially thinking the admins perspective. Like I think of my children when they want candy on wednesdays. They want it, but it is not good for them, so they are not gonna get it.

In this case I think it would be a benefit for the customer to get rid of a bad habit to create unstructured product data. It would be much easier for the customer if their product data manager should not build stuff visually, but depending on the product type, they have a number of fields to fill out that will create content that visually will look the same all over.

And then that data can be used in other contexts. You would have problems on mobile, or moving data to other platforms etc.

What you get with a visual editor is unstructed data that will have different visual appearance depending on who did it.

The benefits of NOT using a visual content editor

• Responsiveness for mobile devices can be handled with structured data. If you get hardcoded markup out, you cannot control it.
• Reuse of data across platforms - a grid in html is just a black box if this customer needs to move data to market places etc.
• Possibility of SEO in the PDP page
  • I.e. adding alt text automatically on images in the template. That lacks from your demo
  • Using subheadings correctly document structure wise
  • Re-use headings and text as title tags and captions
• Consistent look of all product pages of the same kind of products
• Data can be re-used in i.e. native apps
• By using category fields, you can also use inheritance of field values so the enrichment of many products will be faster.
• Users do not have to learn to understand grids.

BR Nicolai

Hi,

If it helps, in terms of concept, what works in my mind is (and I know some is coming in Rapido 4.0) is having the ability to have multiple DW pages (using the Visual Editor) where we can set up the Product Detail using Rows and Paragraphs. 

Imagine there are 4 potential product detail pages:

• PageID 123 = for products with a image galleries and a lot of attributes and reviews, related products and whatnot
• PageID 124 = for Kits/Parts lists where layout is slighlty towards a configurator
• PageID 125 = for Services/Subscriptions, meaning there's no galleries nor related products
• PageID 126 = for new upcoming products where there's mostly marketing information

This works really well. The challenge is to find a simple and scalable way for products (whether that's 10 or 100.000) be associated with each PageID. Maybe through their Primary Groups, which have a pageId associated?

The additional challenge is then in terms of URL structure and sitemap (SEO details which some customers are sometimes picky about), so that it could seem seemless regardless of which Product Detail Page Id it would associated with. i.e.

• www.domain.com/products/my-group-1/productA (PageID=123)
• www.domain.com/products/my-group-2/productB (PageID=124)
• www.domain.com/products/my-group-3/productC (PageID=125)
• www.domain.com/products/my-group-4/productD (PageID=126)

Thoughts?

Nuno Aguiar

@Nuno

That is my exact thought - and using the pageid on the groups. And I think we have solved the URL problem as part of the process... That will not be Swift 1.0 though. But soon thereafter I hope.

I was careful not to use the term Swift and kept using Rapido, but I guess the cat's out of the bag now 

Hi guys,

Thank you for all your thoughts.

I agree that structured data is a lot better than bulk HTML. I am not a fan of Elementor or other visual editors used in other solutions.

What I was suggesting is basically similar, probably a bit different on how it is used.

The first suggestion was to have Structured data (JSON) saved in the HTML field instead of the final HTML. This gives a bit more freedom in how you output the content but can have some impact on performance.

The second part was to use the visual editor that we have on the Content section but trigger it from the Product editing dialog instead of having to switch to the Content section.

However, it seems that you already have decided on an approach and I am eager to see it in action :)

This means that the simple answer to my initial question is "Yes, we have a plan to support visual editing on products".

Looking forward to getting my hands on the "Swift 01" solution.

Thank you very much,

Adrian

Storing markup as json does not make it structured. It is just another format of unstructured data. Each product would potentially have different structure making it hard to use for anything outside.

The idea of visual editor in products is wrong.

The solution proposed will not make visual editing for each product - that would also be wrong.

The proposed solution will use product fields with structured data and visual representations made in visual content builder using those product fields.

NP

Hi Nicolai,

It seems that I was wrong on all counts.

Nevertheless, I am looking forward to testing your solution.

Any rough idea when that may happen? I have read on another thread something about the end of this month?

Thank you,

Adrian

It has been discussed as a possible feature for v1.1 of Swift - but no decisions yet. I cannot give you a date.

But it is not a Dynamicweb feature, but an implementation detail, so you wil be able to do it in the implementation. Swift 1.0 will have visual content builder for the product detail page, and we expect to extend that to have multiple versions of that using the same technique - and some ninja template tricks...

BR Nicolai

Hi Nicolai,

I will be happy with whatever I can get.

Ninja tricks? No problem :)

Thank you,

Adrian