[TYPO3-hci] BE vs FE

[Christopher]

Waldemar Kornewald wrote:
> On 8/2/06, Tapio Markula <tapio.markula at dnainternet.net> wrote:

<snip>

> But please everyone rethink the user concept. The permission system
> can do *exactly* the same, but it's simpler and it would make TYPO3
> more useful for community sites.
> Why are you so reluctant to unify it? There is no good reason to keep
> the old system. Groups and permissions can do the same (same security,
> distinction between clients and admins, ...).

I could have responded to any number of the posts in this thread, but 
this one will do, and since it does a good job of illustrating something 
  I don't think you've correctly understood I'll start with that--

FE/BE

There is nothing about the BE/FE distinction _per se_ that prevents the 
development of community sites as you keep claiming--I'm sure you've 
misunderstood what people have been saying. TYPO3 /has/ a reasonably 
complete API for developing sites with many of the most commonly used 
community-site kinds of features--google fe_adminLib.inc. The problem is 
that it's outdated and quite labour intensive to implement and ugly to 
maintain. However, this has nothing in particular to do with the BE/FE 
distinction. There have been several movements in the community to 
improve what's available for this purpose, but there's no consensus yet 
on which extension or concept will form the best base for future 
development.


Training

Forgive me for making the assumption, but I can't believe, given what 
you keep insisting about training, that you have much experience with 
end-users. We use many different CMS products on client websites 
(according to their needs and requests), and we /know/, from long 
experience that /all clients need CMS training/. This is true for 
Mambo/Joomla, Drupal, Plone, Xaraya, some fairly ugly proprietary 
systems we've been forced to work with /and/ it's true for TYPO3. In my 
experience, clients have better luck solving their own problems with the 
relatively consistent TYPO3 BE than they do with any of these other 
products. In all honesty, I suspect it's because TYPO3 has one of the 
more well thought out concepts: Site contains pages, pages contain 
content elements etc.

In any case, the point is, in answer to a question of yours elsewhere in 
this thread, that I don't believe in the possibility of a product 
useable without training, even for the basics, because I have never seen 
/any/ CMS tool--or /any/ software--that even approaches this paradigm.

As far as a trial and error approach is concerned, I think if you were 
given a /properly configured/ BE to play with, you'd find you were able 
to create pages and contents in about 15 minutes.

And with respect to MS products, surely you don't really believe that 
anybody uses any tiny fraction of Excel's capabilities without training? 
I'd be willing to bet that the single most common use of Excel by 
untrained persons is as a /database/. Certainly hardly anyone uses Excel 
in any remotely effective way without fairly detailed training.


Target Audience

In a way, I /do/ think you have hit on a problem with TYPO3, but it's 
not a problem with the software. Rather I think that, like many others, 
you have mistaken the target group of users for TYPO3. I have said it 
before many times on the mailing lists, but I'll say it again here:

TYPO3 is a framework targeted at /developers/ and their /clients/.

Now before you jump on that with some comment like 'yes, and it shows in 
the interface...' please read what I have to say:

First of all, the clients of a competent agency or developer /never/ see 
the full complexity of the BE unless they are trained or otherwise 
qualified to use it.

For the needs of developers...well you've already noticed TYPO3's 
millions of options. These are a) present, and b) enabled by default 
because /it is not possible--or at least it's anything but easy--to come 
up with a less general solution to the problem/.

The problem is the problem that /developers/ face: we need a framework 
that can a) run anything from a 5 page home/about/contact/foo/bar 
website to a site with n x 10^3 pages, millions of page views per month, 
and a complex hierarchy of BE users /and/ that can do--or be extended to 
do--almost anything that a website can be reasonably expected to do. We 
also need a framework that may be used by extremely sophisticated users 
and also by total newbies.

These parameters /require/ those millions of options. It would of 
course, be a relatively simple matter to sit down, define a few common 
use-cases and write extensions that pre-configure most of the install as 
a starting point (in fact, I posted a crude extension for this job in 
the wiki a few months ago...), and I suspect that a lot of agencies 
developing TYPO3 sites do exactly this. But in the repeated development 
of custom sites, I find there is less commonality than you might think 
between one project and another. In fact, build a few sites with TYPO3 
and you will suddenly realize just how much other CMS tools require you 
to cram your users needs into a few pre-defined roles not really 
well-suited to their actual needs. But if you'd like to really cut down 
the interface, it's a matter of a couple of hours to build an extension 
to do it or copying and pasting two or three fields worth of 
configuration options.


Page/File Trees (getting tired now :-))

1. You can add files directly to a page--see the 'files' field in 'Edit 
page properties' form.

2. Page tree and files have no necessary /structural/ relation. It 
boggles my mind to think that you would want to mirror public 
information architecture in file structure or vice versa. Their needs 
are really quite different. I run a site with a /lot/ of assets that 
require a reasonably deep file structure. It would make no sense at all 
to mirror this structure in the website or to force the website to match 
this structure. I find this to be typical rather than exceptional...

/end ;-)


-Christopher