authors do not split their articles - problem and solution

Discussion corner for Developers of Serendipity.
Post Reply
stm999999999
Regular
Posts: 1531
Joined: Tue Mar 07, 2006 11:25 pm
Location: Berlin, Germany
Contact:

authors do not split their articles - problem and solution

Post by stm999999999 »

hello,

I have one s9y installation used by many authors. The problem: they often do write the whole article into the body and nothing to the extended field. :-(

Is this a problem, others know, too?

OK, perhaps I worked out a solution by adapting the search form as some themes using it:

in the form appears "search ...". By clicking into the form, the text disappear and the visitor can type his search string. If nothing is written, "search ..." will be shown again.

example: http://www.sankt-joseph-siemensstadt.de/ on the right top. (suche ...)

What do you think about this? Is this a relevant problem? Is my solution a good one which could be imported into s9y?

I do the following changes:

lang_xxx.php

Code: Select all

@define('BACKEND_EDITOR_BODY_EXPLAIN','Please insert an appetizer here, e.g. one or two paragraphs!');
@define('BACKEND_EDITOR_EXTENDED_BODY_EXPLAIN','Please insert the main text here!');
(the advice text)

admin/style.css

Code: Select all

textarea.grey {
	color:grey;
}

textarea.normal {
}
(I want the advice text be greyed out)

and the main (javascript changes) in admin/entries.tpl the textarea-things:

Code: Select all

<textarea
{if (($entry_vars.entry.body|@escape)=='') || (($entry_vars.entry.body|@escape)==$CONST.BACKEND_EDITOR_BODY_EXPLAIN)}
class="grey"
{else}
class="normal"
{/if}
onblur="if(this.value==''){ldelim}value='{$CONST.BACKEND_EDITOR_BODY_EXPLAIN}'; this.className='grey'{rdelim}"
onfocus="if(this.value=='{$CONST.BACKEND_EDITOR_BODY_EXPLAIN}')value=''; this.className='normal'"
style="width: 100%" name="serendipity[body]" id="serendipity[body]" cols="80" rows="20">
{if ($entry_vars.entry.body|@escape)==''}
{$CONST.BACKEND_EDITOR_BODY_EXPLAIN}
{else}
{$entry_vars.entry.body|@escape}
{/if}
</textarea>

and

            <textarea {if (($entry_vars.entry.extended|@escape)=='') || (($entry_vars.entry.extended|@escape)==$CONST.BACKEND_EDITOR_EXTENDED_BODY_EXPLAIN)}class="grey"{else}class="normal"{/if}
            onblur="if(this.value==''){ldelim}value='{$CONST.BACKEND_EDITOR_EXTENDED_BODY_EXPLAIN}'; this.className='grey'{rdelim}" onfocus="if(this.value=='{$CONST.BACKEND_EDITOR_EXTENDED_BODY_EXPLAIN}')value=''; this.className='normal'" style="width: 100%;" name="serendipity[extended]" id="serendipity[extended]" cols="80" rows="30">{if ($entry_vars.entry.extended|@escape)==''}{$CONST.BACKEND_EDITOR_EXTENDED_BODY_EXPLAIN}{else}{$entry_vars.entry.extended|@escape}{/if}</textarea>

Ciao, Stephan
garvinhicking
Core Developer
Posts: 30022
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: authors do not split their articles - problem and solution

Post by garvinhicking »

Hi!

As for the search, I do thing it's a nice thing. But using it for entry bodies seems a bit problematic to me. For one, it could lead to having that text inside the actual blog entry, as well as not being able to really make that field empty, if you would not like to have an extended body. Also, without javascript, it would not clear properly.

IMHO this is something that authors need to be made aware of the the main editor of a blog, and be taught to use it. Most CMSs have regulations that would need to be enforced by the person running the site; if you'd have a Typo3-CMS with many authors, they all wouldn't be able to just do what they like, they would need to be taught to use a specific implementation guideline, where to insert datasets, which columns to use/not use, etc. For multi-author blogs, IMHO such a social component of a common determinator would also be the wiser thing to do, rather than possibly introducing "dummy texts" that could end up in the system?

Regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
stm999999999
Regular
Posts: 1531
Joined: Tue Mar 07, 2006 11:25 pm
Location: Berlin, Germany
Contact:

Re: authors do not split their articles - problem and solution

Post by stm999999999 »

Also, without javascript, it would not clear properly.
äh, BTW, without javascript you can't use the s9y-editor in a right manner!

turn js off, make a new article, click to preview and:

instead of getting a preview your article will be saved
and - if this is your preference - the article, perhaps not ready yet, will be published!
Ciao, Stephan
stm999999999
Regular
Posts: 1531
Joined: Tue Mar 07, 2006 11:25 pm
Location: Berlin, Germany
Contact:

Re: authors do not split their articles - problem and solution

Post by stm999999999 »

As for the search, I do thing it's a nice thing. But using it for entry bodies seems a bit problematic to me. For one, it could lead to having that text inside the actual blog entry, as well as not being able to really make that field empty, if you would not like to have an extended body.


OK, writing the help text into the textarea itself could be a problem. What do you think about a system like found here: http://www.allesaussersport.de/archiv/2 ... –-ny-jets/ for the comment fields?

After a short look to the source I think it writes the text into labels to the forms, and overlays them onto the comment fields with absolute and z-index and makes them invisible for typing into the fields.

Would this be better?
IMHO this is something that authors need to be made aware of the the main editor of a blog, and be taught to use it ... For multi-author blogs, IMHO such a social component of a common determinator would also be the wiser thing to do, rather than possibly introducing "dummy texts" that could end up in the system?
The problem is I told them but many authors do write one time a month or so and they do not remember this.

And, yes, social problems shold be solved by social solutions at the best. But here I need a technical help.

So, before burrowing into the job of making a plugin or so, it would be nice to get feedback from other multi-user-blog-admin here.

So, Yoo-hoo, is there anyone out there!?
Ciao, Stephan
onli
Regular
Posts: 2825
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: authors do not split their articles - problem and solution

Post by onli »

Just want to throw in that I really don't use the extended entry field, like many others, so please don't think in a way that would force me to change that :)
And I really don't think we should do anything to make people use the extended entry more, it has no benefits in a non-magazine-blog.
sincerely
stm999999999
Regular
Posts: 1531
Joined: Tue Mar 07, 2006 11:25 pm
Location: Berlin, Germany
Contact:

Re: authors do not split their articles - problem and solution

Post by stm999999999 »

Just want to throw in that I really don't use the extended entry field, like many others, so please don't think in a way that would force me to change that :)
of course - it should only be an option
And I really don't think we should do anything to make people use the extended entry more, it has no benefits in a non-magazine-blog.
strong NACK - many personal blogs use it and this is good!

It is extremly annoying to the reader to have many long texts on the front page!
Ciao, Stephan
onli
Regular
Posts: 2825
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: authors do not split their articles - problem and solution

Post by onli »

strong NACK - many personal blogs use it and this is good!

It is extremly annoying to the reader to have many long texts on the front page!
It means for every user that they have to click again when they want to read an entry, instead of simply reading or skipping it. In a feed the entries are anyway seperated, the amount of entries on the frontpage is configurable, and how long is the average blogpost?
We probably shouldn't discuss this, didn't want to capture your thread, especially if that's only about a plugin (the choice of forum told me otherwise ;) )

PS: If you want to enforce this, you could also make the extended-aray visible by default (probably part of what you suggested) and make the normal entry-area smaller, fitting to a preface.
Post Reply