cancel
Showing results for 
Search instead for 
Did you mean: 

Many WYSIWYG editors - 1 per paragraph - not intuitive

epsetin
Champ in-the-making
Champ in-the-making
May be the wrong forum – if so, please inform of correct one.

The new XML / Form editing feature for structured content is very slick. Usability-wise there is, however, one oddity. The way to add paragraphs is not from within a WYSIWYG editor, but to click on a plus (+) icon to add editors. That is not a standard idiom and, as it requires authors to mouse for every paragrap, diminishes usability.

1. Is this a known issue?
2. Can this be easily fixed by the end-user?

Thanks,

ee
4 REPLIES 4

epsetin
Champ in-the-making
Champ in-the-making
Just reply if you can hear me.
Is there anyone at home?

arielb
Champ in-the-making
Champ in-the-making
hey - my bad - i didn't know this forum existed (i only generally check the other wcm one, but i'll start looking at this one too now).

i have several answers to your question.

1) it depends what you mean by paragraph.  you can style things however you like in the wysywg editor, so a new line will create a new (html) paragraph.

2) for my first answer you might ask: if you can create a new paragraph just by hitting enter within an editor instance, why repeat the editor?  i don't have a good answer for this.  it's a stylistic decision by the form answer.  i don't really see much of a point of repeating wysywg editors since the separation of instances isn't particularly meaningful.

3) we really should have two appearances for textareas.  one that provides the full wysywg, and one that just does the plain text thing.  for a plain text textarea, presenting the textarea within a repeat makes sense.  personally, i have problems with presenting a wysywg editor at all within a form.  it seems somwhat contrary to the entire prinicipal of capturing structured data.  but it is there due to (overwhelming) desire for it to be there by customers.  if you want a plain text textarea, please file an issue in jira or vote for one if it's already there.

4)  there is no fix by the end user - other than removing the repeating block for the wysywg editor (modify the schema and set maxOccurs="1").

hope this helps.

ariel

rdanner
Champ in-the-making
Champ in-the-making
hey - my bad - i didn't know this forum existed (i only generally check the other wcm one, but i'll start looking at this one too now).

i have several answers to your question.

1) it depends what you mean by paragraph.  you can style things however you like in the wysywg editor, so a new line will create a new (html) paragraph.

2) for my first answer you might ask: if you can create a new paragraph just by hitting enter within an editor instance, why repeat the editor?  i don't have a good answer for this.  it's a stylistic decision by the form answer.  i don't really see much of a point of repeating wysywg editors since the separation of instances isn't particularly meaningful.

3) we really should have two appearances for textareas.  one that provides the full wysywg, and one that just does the plain text thing.  for a plain text textarea, presenting the textarea within a repeat makes sense.  personally, i have problems with presenting a wysywg editor at all within a form.  it seems somwhat contrary to the entire prinicipal of capturing structured data.  but it is there due to (overwhelming) desire for it to be there by customers.  if you want a plain text textarea, please file an issue in jira or vote for one if it's already there.

4)  there is no fix by the end user - other than removing the repeating block for the wysywg editor (modify the schema and set maxOccurs="1").

hope this helps.

ariel

ariel,

I tend to agree with you.  We are also using chiba at the CS Monitor to allow editors to work with content.  We chose to use XForms because we can port this capability into Alfresco at some point when we have a production environment. 

We use the add functionality in chiba to represent a large block of "COPY": say something like a summary or a caption.  Since we might want a PRINT SUMMARY and a WEB SUMMARY and possibly a BRIEF SUMMARY (hehe a summary of the summary?).  This means that lower level concepts like Headline breaks (the publishing industry calls the DIVVY) and paragraphs are controlled within the WYSIWYG editor (Tiny MCE).

The problem with this approach as you point out is that if you dont watch it you will find your users putting all kinds of unstructured things in the document. 

We limit what can be put in the editor so that what we get out at the end is structured content.  It is not as strucutred as I would like: for example we do allow them to bold something.  In the future I would like them to be able to mark the thing they would "bold" semantically which i could then style.

So we found that its important for the editor and the chiba add field capability work really well together rather then one approach over the other.

-R

kvc
Champ in-the-making
Champ in-the-making
Ezra - unfortunately, I'm not sure if there's any way around this … if the schema wants to enforce things like minimum 1 paragraphs but no more than five, the only way we can do that is to have separate fields that a user adds so that we can enforce # of items, etc.  Within the TinyMCE editor we do not have that control.

That said, lots of people just use one WYSIWYG editing area and within that allow people to create paragraphs ad nauseam.  It really gets down to at what level you want to reuse the content - if you want to repurpose specific paragraphs in other pages, you'll want a separate field.

Kevin