[TYPO3-hci] BE vs FE

Waldemar Kornewald wkornew at gmx.net
Mon Jul 31 12:46:15 CEST 2006


Hi,
I'm member of the Haiku project (http://haiku-os.org) - on open-source
BeOS - and we are searching for a very easy to use CMS. We've tried
nearly everything and only Plone seems to fit our needs, but hosting
is too expensive and the whole system is too resource-hungry. We also
tried Typo3, but the backend is ridiculously complicated. Anyway, it
seems that we won't get around using Typo3 and I hope that we can help
with improving usability (and that you are interested in our
suggestions).

Why is there a separation between frontend and backend users? Can't
there just be a flag telling whether a user gets access to the
backend? Everyone should get access to the frontend. We want users to
register themselves to get access to additional services. For example,
we use Trac for bug-tracking and we want single-sign-on, so our CMS
should manage the user accounts. Or we want to restrict who can access
certain pages. In that case, our backend users must browse the
frontend.
I don't really get what the advantage of this separation is. It makes
everything more complicated, but for what reason? Security? Add a
simple flag (other CMSes already do this). What else?

This is probably only for 5.0:
I think that we should finally get rid of this "backend" concept. AJAX
makes this possible. Backends are more difficult to understand. What
speaks against only having a frontend and showing simple "Edit",
"Items", and "Admin" buttons in a simple bar at the top of every web
page? Instead of the current scheme where your page consists of
individual "segments" everything could become WYSIWYG-based. You could
add forms and plugins right into the editor and configure them
visually. Pages should become the central concept.

I understand that a page tree is a nice abstraction, but manipulating
your site in-place is even better because there is no need to abstract
anything. Also, the current "items" concept (page list-view) is nice,
but isn't normally a plugin needed to store items? In many cases it's
probably better to allow plugins to add special actions to the website
(when logged-in) and let plugins manage items. For example the news
plugin could add a "manage news" button and take care of all news
items. Where this data is actually stored should not be exposed to the
user, but you should still be able to say that your news plugin should
use the same data store as the news plugin on some other page (so you
can have a news summary on the front page and a separate archive
page).

The biggest problem of today's CMSes is that they expose their
implementation details to the user. IMHO, all tasks should be
performed *directly* and *in-place* instead of splitting them accross
implementation details like folders/containers. E.g.: why do you
separate news items from news plugins? One can't live without the
other, anyway. If something belongs together then it should be put
together.

Where do you collect your ideas for R4.5? We'll give R4 another try
and I might have a few more suggestions after having used it a little
bit and I don't want to repeat old suggestions.

Thanks!

Bye,
Waldemar Kornewald



More information about the TYPO3-team-hci mailing list