[TYPO3-hci] BE vs FE

[Waldemar Kornewald]

On 7/31/06, Tapio Markula <tapio.markula at dnainternet.net> wrote:
> > Well, it's still very overloaded. I mean, compare Typo3 with Plone, for
> > example.
>
> it is possible to simplify - what is too much?
> I made an extension, which allow to take more off

IMHO, it needs a complete rewrite. Don't you see how weird this is?
Extensions are normally used to *extend* the system. In Typo3 we have
extensions which *reduce* the amount of features. How does that make
sense? A lightweight base which can be extended by those
feature-bloat-lovers is far less annoying than a system that comes
over-bloated out-of-the-box. The latter would require you to learn the
CMS to know how to make it simpler while the former doesn't require
much learning and you can get started immediately.

So, IMHO the number of buttons and the interface clutter should be
reduced to the bare minimum and a special "super-customize" extension
can bring all those little buttons back. Really, usability-oriented
design optimizes for 80% of the use-cases instead of filling the
interface will lots of shortcuts to make power-users slightly more
effective. A good interface greets you with a very simple view and
basic functinality. If you need more you have to learn. A bad
interface greets you with 20 buttons, so you have to learn before
getting even simple tasks done.

> > 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.
>
> there are some extension, which allow frontend users to edit pages - and
> adding one of those plugins you can get what you want.

But this doesn't eliminate the whole separation which our site admins
will have to deal with...

> > BTW, wizards are a good indicator of a too
> > complicated interface because developers often try to hide complexity
> > behind wizards.
>
> how to make choises, what content to use and where to put the content?

I'm not sure what you mean. Basically, wizards are very ineffective.

> > 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
>
> editing in pop-up window you mean or edit, hide ...
> it is possible to define, what buttons to show

Again, I'm not sure what you mean. Could you please write longer sentences? :)

>  >What would be a reasonable absolute minimum? Four buttons?
>
> what you really need - personally I like many buttons because they make
> some shortcuts (save and close for example).
> I would *not* like CMS, which use just few buttons.
> It is not bad to offer many buttons if there can be less.
> Using my extension you can define exactly what buttons to show.

It is bad to show more buttons than the average user needs.
Power-users can install extensions, but newbies have a hard time with
getting used to such a complicated system.
You might need all those buttons, but I hope you agree that a clean
interface is easier to use and that your special needs should not be
imposed on others. You're probably a developer and know a lot about
Typo3. At least, you have lots of experience. But most users don't
even want to know the system so well. They have other primary tasks
(not CMS-related) and a CMS is just a tool for them.

> > 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.
>
> slower to use - IMO *much* worse - (I don't like drop-down-lists if
> something can be done without using them)

It's one click more and most users would be thankful for a cleaner
interface. Also, you could still use some "power-user" plugin. It's
just the wrong solution to bother *all* users with that interface if
only power-users need it.

> > Also, I don't like that pages themselves are split into records.
>
> this is just a matter of taste

No, it's a matter of usability. A WYSIWYG editor would be capable of
replacing this system, so it could be easier to use. Of course, it
would mean a lot of work, but we're talking about possible future UIs.
If someone still prefers records he can use a plugin, but the base
system should be as intuitive as possible.

> > This would be exactly as powerful, but a lot
> > simpler because you don't have to care about different types of
> > records.
>
> then you should build entire new editor or use special markers,
> which looking source code could easily be destroyed - extremely
> vulnerable system.
> I know a CMS, which use those kinds of vulnerable markers ([...])

In many CMSes you are confronted with HTML markers (next to WYSIWYG)
and it doesn't seem to be a problem, so why would those markers be
problematic?

> >> 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 has advanctages and disadvantages. If everything is in one record,
> the record would be difficult to edit. It is easier to edit smaller
> segments.

Could you please give a good example? I can't imagine a use-case where
records are much easier to edit. They can be used to reduce the amount
of content that has to be loaded by the editor, but OTOH records
aren't WYSIWYG.

> If elements are in smaller blocks it is easier to move them from place
> to place - using AJAX drag'ndrop or copy/cut/paste
> like in the example below
> http://t3test.xetpoint.com/media/development/backendediting5.png

Well, you could copy-paste in a WYSIWYG editor, too. Only drag-n-drop
would be _slightly_ more difficult (but you can use d-n-d within any
editor by selecting the text and dragging it with the mouse).
Sometimes you have to make a compromise and IMHO the overall
advantages of WYSIWYG outweight its disadvantages (regarding records).

> Safe, because you don't have vulnerable markers inside one big content.

This is not a big problem, is it? I could break HTML or wiki tags in
any other system, too, but users don't seem to have a problem with
that (esp. if they use WYSIWYG editors, so they don't get in contact
with those tags).

> > 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.
>
> maybe but Typo3 offers flexibility, which you automatic loose if you
> want to show everything in one view.

I disagree. What kind of flexibility do you need that is *impossible*
or very ineffective with WYSIWYG?

Bye,
Waldemar Kornewald