nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Question about "content" replicants and the "enterprise" interface

Tim__D

I want to get some opinions about the best "content" form control.

Do you prefer to use a single VF field for the content/body area of a form? If so why?

Do you prefer to use a replicant consisting of plain text areas that generate

content content content

html? If so why and is it usable? Do you enable VF for these field or just leave them plain text?

I've done it both ways. Obviously if the information can be structured I would structure it Name,Date,Heading etc.. etc.. but I'm talking about content that users want free form. For example the content area of a "News" article or something.

The main driver behind this question is that more and more TeamSite FormsPublisher in my organization, needs a common face to its users who manage more than one application. To do this I need to draw a line in the sand and create Forms in a similar fashion to increase familiararity accross forms and reduce training.

Often times structure, usability, content reuse requirements are in conflict. Just give me the 80/20 opinion.

Find more posts tagged with

Comments

Bhargav Coca

I am not a total expert as some guys are here on Devnet. But i would like to share my experiances. In any Typical environemnt, people tend to categorize/compartmentalize/put it in a hierarchy. Because in future there will be changes and you will be forced to change only one VF textarea and dupicate it or do any modifications what so ever, insted of jamming all the things in one VF .

Again its hard to predict or set a uniformity across the table, there are so many other factors like number of departments ( The number of VF's needed may vary according to departments). If you are using DD if you are using DAS again there will be so many tables created for each replicant, what ever you do things will never be uniform through out. So i would use several Individual VF's rather than having just one across the board.

Hope this helps.

Thanks

Adam Stoller

I want to get some opinions about the best "content" form control.

Do you prefer to use a single VF field for the content/body area of a form? If so why?

Do you prefer to use a replicant consisting of plain text areas that generate
content content content
html? If so why and is it usable? Do you enable VF for these field or just leave them plain text?

I've done it both ways. Obviously if the information can be structured I would structure it Name,Date,Heading etc.. etc.. but I'm talking about content that users want free form. For example the content area of a "News" article or something.

The main driver behind this question is that more and more TeamSite FormsPublisher in my organization, needs a common face to its users who manage more than one application. To do this I need to draw a line in the sand and create Forms in a similar fashion to increase familiararity accross forms and reduce training.

Often times structure, usability, content reuse requirements are in conflict. Just give me the 80/20 opinion.

My personal opinion is that the less you use WYSIWYG textareas (VFE or TinyMCE) in your DCTs - the better the overall design - as WYSIWYG textareas break the separation of content from presentation.

However, given that the ideal (IMO) is seldom accepted by users who don't understand the rationale behind such philosophy - I'd still opt to minimize as much as possible the use of WYSIWYG textareas.

If pressure continues to bear on this - then provide a very simplistic DCT that contains 1 or 2 distinct fields and then one big WYSIWYG textarea - let them do whatever they want and when they complain about something not working the way they want later, you can point them to the fact that it would have been easier if they had allowed you to structure the content but they wouldn't let you ...

Often it comes down to a combination - a bunch of well structured DCTs along with one "general" DCT - and hope that the latter gets used as little as possible.

Tim__D

My personal opinion is that the less you use WYSIWYG textareas (VFE or TinyMCE) in your DCTs - the better the overall design - as WYSIWYG textareas break the separation of content from presentation.

However, given that the ideal (IMO) is seldom accepted by users who don't understand the rationale behind such philosophy - I'd still opt to minimize as much as possible the use of WYSIWYG textareas.

If pressure continues to bear on this - then provide a very simplistic DCT that contains 1 or 2 distinct fields and then one big WYSIWYG textarea - let them do whatever they want and when they complain about something not working the way they want later, you can point them to the fact that it would have been easier if they had allowed you to structure the content but they wouldn't let you ...

Often it comes down to a combination - a bunch of well structured DCTs along with one "general" DCT - and hope that the latter gets used as little as possible.

In the templating proejcts I have done there is always a "generic" template of some kind for info that does not fit a real data type. Press Release etc.. So for these where flexibility is needed my question is, where users enter in the body content is it better to use content replicants to separate

paragraphs of content

or is a single VF field the way to go? I think a single VF is much more usable for users especially writers but it does break the ideal model for managing content. Also when dealing with body content what do you do if you want to add a hyperlink to text without visual format? I dont want folks entering in html by hand! I'm trying to establish some real world CMS standards for my organization.

Adam Stoller

In the templating proejcts I have done there is always a "generic" template of some kind for info that does not fit a real data type. Press Release etc.. So for these where flexibility is needed my question is, where users enter in the body content is it better to use content replicants to separate
paragraphs of content
paragraphs of content
or is a single VF field the way to go? I think a single VF is much more usable for users especially writers but it does break the ideal model for managing content. Also when dealing with body content what do you do if you want to add a hyperlink to text without visual format? I dont want folks entering in html by hand! I'm trying to establish some real world CMS standards for my organization.

With respect to the former - it depends on how you want / need to process / render the content for actual viewing on the site. I like the idea of using separate areas for separate paragraphs - especially if you are using distinct CSS classes for the paragraphs - though if you can wrap the entire section within a div element you can apply the CSS that way without having to have distinct classes for the paragraphs.

I've done a couple of projects where we provide an OR replicant container which allows:

)

Tim__D

[QUOTE=ghoti]With respect to the former - it depends on how you want / need to process / render the content for actual viewing on the site. I like the idea of using separate areas for separate paragraphs - especially if you are using distinct CSS classes for the paragraphs - though if you can wrap the entire section within a div element you can apply the CSS that way without having to have distinct classes for the paragraphs.

I've done a couple of projects where we provide an OR replicant container which allows:

It seems like the implementations your describing have had similar challenges.In my most recent templating project I had also used a similar OR replicant. I too observed that some authors used a single instance containg a lot of paragraphs and some authors used multiple instances with a plain text in each one with little or no formatting. Users seem to find options based on the page and flexability they need which is not ideal.I happen to like the choice/or replicant feature a lot. Very powerful when trying to provide structured options for authors that need a lot of page flexability. Do you use this feature a lot and do your users find it intuitive?One thing that also gets back to VF is the application of styles. On my last project the users had a lot of tabular data. We opted for VF with the table option and style drop down. It worked pretty well.