[TYPO3-hci] BE vs FE

[Waldemar Kornewald]

On 8/1/06, Christopher <bedlamhotelnospam at gnospammail.com> wrote:
> > But the main problem with what you say is:
> >> newbie editors I have trained
> > Do you think those editor would have been able to do anything without
> > your training? Somehow this doesn't speak for Typo3's usability.
> > Once you can train someone you have eliminated a lot of problems. The
> > point is that the CMS should be usable *without training*.
>
> I wondered it this was at the root of this thread. TYPO3 has many areas
> where usability could be improved, but do you think you could possibly
> make a more ridiculous statement if you tried?

>From that silly perspective everything can look ridiculous. Of course,
I'm *not* talking about computer n00bs. We are a team of developers
and many of us would be able to write a whole OS (in fact Haiku is an
OS ;). I want tech-savvy people to be able to get their job done
without any training. Maybe difficult tasks like creating a news page
are too much to ask for, but creating news items, pages, blog posts
(i.e.: all every-day tasks) must be as easy as possible.

> In a properly set up BE--have you even seen a TYPO3 BE configured
> specifically for the tasks a user may need to do?--we find it takes 2 to
> 3 hours to train a group of 1 to 4 users whose main tasks are to add,
> update, modify and delete content.

I can't believe that you're satisfied with this situation. Maybe
you've used TYPO3 too much?

> A full-fledged TYPO3 administrator or developer obviously takes much
> longer to train, but that has much more to do with the fact that they
> will need to learn some Typoscript than it does with any given part of
> the BE interface.

Agreed, some very advanced tasks (skins, etc.) just can't be made
totally obvious.

> >> "Nobody needs this/that" -> How can you know what others might need?
> >
> > Scratch the "Nobody". There always is *someone* who needs it.
> > How do I know that *most* people don't need it?
> > * I see that the concept is not very simple.
> > * I tried *lots* of CMSes. I didn't count, but I'm sure I tried at
> > least 90% of the open-source CMSes.
> > * If I see that most other (powerful) CMSes have found a simpler way
> > to solve something then I can be sure that I'm not totally wrong when
> > I say "Nobody needs that"
>
> Really? I have never seen any CMS that had implemented as useful a
> distinction as the List/Page module distinction. IMO, Joey has it
> slightly wrong to say that the principle use of these different modules
> is that users can choose which they like and use it instead of the
> other--though this is a useful side effect.

I did not criticize the List view. It is a nice idea to solve where to
store different kinds of items (news, etc.). It's not extremely easy
to use, but for a very powerful CMS it's a good tool. Even though, I'd
love to have a fully-WYSIWYG-enabled system I can live with the basic
concept of TYPO3.

It's just that the interface is being overloaded with too many
concepts and separations which don't have to be.

> I find it a little weird that you don't understand this
> distinction--this is the application/file manager distinction that every
> modern OS has. It's the model where you use a customized application for
> authoring files and a file-manager like the Finder in OSX or Windows
> Explorer on Windows to manage files.

But TYPO3 already has a container type: pages
Why do you want to introduce yet another similar, but totally distinct concept?

> > * Visitors and editors are both *users*.
>
> With, according to the TYPO3 paradigm, vastly different roles. As
> mentioned, TYPO3 is /not/ the best framework for interactive,
> community-based sites.

The roles are different, but they have the same properties.

> > * Nearly all CMSes don't make such a distinction and there are no problems.
>
> This is relevant how? Many vehicles have four wheels, some have two,
> neither has any particular problems...

It was just to show that it is not necessary to solve it that way.

> > * What is the advantage of having them separate? I still haven't seen
> > a good reason.
>
> Consistency of interface, and access to tools that are not practical in
> in-place editing. Plone has this kind of distinction too--eventually you
> need to get into the file structure and outside of the site's layout.

Well, you probably mean ZMI users and Plone users, but that can't
really be compared with TYPO3's distinction. In Plone, every user is
using the same login form and based on your permissions you can see
editing options or only do basic operations. Also, Plone is forced to
use Zope which has different needs.

In what way does "consistency" and "access to tool" prevent a
unification? Permissions could easily solve this.

> Again, this if this is something your use case requires, unless you have
> truly extraordinary reasons, your best option is going to be to find a
> tool that satisfies it instead of trying to modify an existing system.

Unfortunately, we couldn't find any better CMS.

> By the way--to /whom/ is Plone known for usability?

Just surf the web and read a few usability reviews and comparisons
between systems. It's everywhere.

> IT can take all
> afternoon to find a simple CSS file that needs changing...

You're talking about Zope which is really terrible. I'm talking about Plone.
And your task is not something that the average end-user has to do. In
Plone any user would be able to create an article or post a news item.
These are every-day tasks! They must be easy!
Keep in mind: I'm talking about every-day tasks being too complicated
and tech-savvy users having problems with TYPO3!

Bye,
Waldemar Kornewald