[TYPO3-hci] BE vs FE

[Waldemar Kornewald]

On 7/31/06, Tapio Markula <tapio.markula at dnainternet.net> wrote:
> Waldemar Kornewald wrote:
>
> > tried Typo3, but the backend is ridiculously complicated.
>
> what way?
> Personally I like the page tree - it is easy to see the page structure.

It takes a lot of steps to do very simple tasks. It's not very obvious
how to create content and the interface is overloaded with lots of
functions which I'm sure could be simplified.

> The default page module is as such bad - I made it easier to use
>
> test
> http://t3test.xetpoint.com/typo3/
>
> as tester + tester
>
> test both
> 'Interface' 'Backend' and 'Frontend'

Well, it's still very overloaded. I mean, compare Typo3 with Plone, for example.

> > Why is there a separation between frontend and backend users?
>
> for setting *editing* possibilities - they are commonly only for backend
> users.
> Frontend users are commonly only users, which can *see* but not edit
> pages. Some extensions allows to set also editing for frontend users.

This doesn't explain why you have to separate those users instead of
using some "backend" role which can be assigned to anyone (such that
you can give frontend users access to the backend if they become team
members, for example). I mean, having this distinction is definitely
more complicated than not having any distinction. And there doesn't
seem to be any compelling reason to have such a hard line between both
types of users if you could easily manage this with roles/permissions.

> > 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?
>
> in fact this is possible - test
> http://t3test.xetpoint.com/typo3/
>
> as tester + tester
> as 'Interface:' 'Frontend' mode

Unfortunately, this system is very complicated because you can have
multiple content sections (even next to each other) and you have to
work with wizards. BTW, wizards are a good indicator of a too
complicated interface because developers often try to hide complexity
behind wizards.
Please take a look at Skeletonz and Plone. Even MODx is easier in
frontend-editing mode because it doesn't clutter the interface so
much. Typo3 shows eight (!) buttons for each element and five
additional buttons for the page itself. What would be a reasonable
absolute minimum? Four buttons? Much of the complexity could be hidden
behind drop-down buttons. For example, instead of showing "move up",
"hide", etc. as separate buttons they could be bundled into one
drop-down action list.

Also, I don't like that pages themselves are split into records. Pages
should only have one WYSIWYG editing section in which you can place
plugins and everything. This would be exactly as powerful, but a lot
simpler because you don't have to care about different types of
records. Records aren't WYSIWYG and ideas don't map 1:1 with the CMSes
concept. This is a very big problem.

> > 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.
>
> pages use WYSIWYG editor for normal contents. forms have form editor,
> to add/remove new fields - handy but not WYSIWYG.

Yes, but you still have individual records/segments. It's not that you
click "edit" and work on the *whole* page. You only work on individual
segments.

> > 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.
>
> It is extremely easy to move/copy pages using drag'ndrop functionality
> - that possibility can never be in frontend.

Maybe, but I doubt that we can make everyone 100% happy. That's
impossible if you want to create a good interface.

> > 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.
>
> It is possible to disable Web > List view. Administrator can disable
> modules from normal users/user groups. Typo can be extremely
> minimalistic, if needed. Then *only* 'Page' module is used.
>
> test
> http://t3test.xetpoint.com/typo3/
>
> using minimal + minimal

You just have disabled access to "List view", but that's not what I
talked about. i want a completely new concept that doesn't require
List view and that is a lot simpler.

>   For example the news
> > plugin could add a "manage news" button
>
> news don't have a module - good idea endeed.

Hmm, I don't know what you mean, but if you're talking about this
XOOPS-like system where you manage news items somewhere outside of the
page tree then I think this is a very bad idea. This kind of
separation not only makes the system less intuitive (separation is not
intuitive), but it also makes it less flexible.

> > 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?
>
> to store news items into different pages. You can store items under the
> same page or elsewhere. You can collect news from different pages,
> if you want. You are right, that news could be organized better.

Well, news, blogs, maybe even forums are the first thing you setup
after installing a page. If that isn't intuitive then most users just
try out the next CMS. Also, page creation should be as easy and
intuitive as possible. ATM, it isn't.

Bye,
Waldemar Kornewald