Robert Koberg wrote:
>
> Ahhh... so you see the benefit is turning forms into prettier forms. I agree
> that is a good thing. But how do you address someone who wants to enter an
> article?
After *lots* of thinking (and fighting with my girlfriend :) I think
there is an entire spectrum of editing needs that range from "totally
freeform" to "totally forced".
Totally freeform is Emacs (or VI, or Vim, or EditPad, UltraEdit, BBEdit,
you name it).
Totally forced is login (or the fill-up form to get your driving
license).
All editing needs range between those two.
In real world, you always need to give some freedom to the writer and
restrict some other.
Unfortunately, only one general rule can be found about this: you should
*never* give any more freedom than the writer needs, because it's only
going to do harm.
> I agree that willy-nilly editing on the page is a bad thing. But you can
> show a view of the page with the content section editable in a free-form
> way. In fact the users can use the site (uneditable nav bar) to naviagate to
> each editable page. So, in effect, they see the site as a user would but
> they can change the _content_.
The content editor I consider useful (and not only in this situation) is
the one that doesn't give me more freedom than I need, but never removes
freedom I *do* need.
This freedom should be inferred from structure information: luckily, in
the XML world, we have such information in the forms of schemas (DTDs,
XMLSchemas or Relax schemas).
In fact, to tell you the truth, I perceive schemas much more useful to
drive editing needs [than patch structure mistakes *before* they are
even made] than to validate content *after* the editing process is
generated. [not that I don't consider a-posteriori validation useful,
but I think that just-in-time validation is much more important for
human-written-content-oriented systems]
So, how much freedom do you give to your writer? It depends on the
schema he is supposed to fill.
There is a key difference between "template driven" and "skeleton
driven" editing, but "template driven" editing is just a subset of
"skeleton driven" editing.
> The content that is generally entered into an article can be managed, things
> like: lists, titles, paras, td, what-have-you...
Let's have a simple example: in template driven CMS, you normally have
very limited freedom: in a news page, there is a small image that
represents the news and it's normally always the same size and same
location. In most professional ones, you can also enter a smaller image
and a small abstract for the newspage (yes, if not entered, they might
be automatically inferred from the news page, but normally this option
is given).
Sometimes, this is beneficial: all news pages give a precious and
confortable sense of coherence to the reader, but what if you have a
highly visual event and one image might not be enough? come up with more
than one news page?
Go to a programmer and he'll have an instant solution: give the editor
the freedom to add images inside the text.
But then, pages look odd with more images with the same orientation
(say, image on the left and text on the right)... back to the programmer
and voila', the editor has now the ability to tell where the image go.
Result: concern overlap between the content editor and the art director.
But there is something even more important than this. Once you give up
structure for freedom, you loose semantic capabilities because, like it
or not, for computers the only way to obtain semantic information is via
structure analysis.
Let's take the example above: if the need of having optional inline
images in the article text is acknowledged by the group that manages the
contracts between the concern islands, they decide to update these
contracts.
This would result in:
a) granting the writer the freedom to "connect" more images to the
article.
b) create a presentation logic that would coherently reshape the
text/image layout depending on the availability and number of images in
the text.
PROs are:
1) concerns are fully separated: the editor simply indicates the
collection of images to insert, their sequential order and their textual
description (useful also for semantic image searching). The visual
designer and the usability manager are in full control of what goes on.
2) abstraction is imposed on the writer: having the freedom to indicate
where to locate images, give them the ability to "contextualize" this
information in the article. For example, they could write something like
"as you see in the image on the left", which inherently places concern
overlap in a place where only human semantic analysis can resolve it. In
fact, the WebTV version of the same text, for example, might display the
image in a subsequent screen, not on the left and not even on the side.
CONs are:
1) as it happens all times you change a contract, both sides have to
update. This normally results in higher immediate costs and might not be
immediately recognized as a way to reduce future efforts.
2) the editing system must be *much* more flexible than currently
available solutions (even commercial) or each schema requires a
specifically written editor.
Don't get me wrong: there are cases where full-freedom is a good thing
(where the art designer and the content editor are the *same* person),
but, as a general rule, creating a fully-featured WYSIWYG editor and
restrict it only on those parts of the page that are considered
_content_ is an extremely dangerous approach.
For sure, an incredibly limiting one since the publishing environments
who really need a serious CMS (and are willing to pay its price!!) are
those who normally need extremely serious editing solutions.
During my journey, I've seen more than one commercial effort that spent
months creating a visual editor based on simplified docbook semantics...
than later failed miserably as a content writing tool, despite its
simplicity of use compared to other solutions (think XMetal, for
example).
Why so? Too much freedom and too few visual contextualization.
The editor I'd like to have is an editor composed for the specific user,
on the specific schema, on the specific context. It's a server-side
generated editor. And this is why I love the contentEditing capabilities
of IE 5.5 because they are granular to the single element and allow me
to restrict the content editing commands that the writer has.
Of course, I'd also love to be able to add more abstract semantic
capabilities to those editing commands (instead of hardcoding even good
sematnic HTML into it) and I think Mozilla will be the key for this.
So, yes, I do see cases where having few "freeform WYSIWYG" content
islands inside a fixed page make sense, but it's absolutely *not*
something I would be willing to pay for. :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
