[TYPO3-hci] BE vs FE

[Tapio Markula]

Waldemar Kornewald wrote:
> 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.

The idea of the original 'Columns' view was to allow different
options for different user, which cause very bloated view, which
I must create an extension to reduce the amount of features.
Sounds weird - in fact it is. It would be better not to have bloated
interface at all.

> 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

true - I have made some presets to make it simpler without need to learn 
to make it simpler and you can give quite easily simpler interface.
Maybe I could define in the presets default interface simpler as today.
It is easy to make simpler default interface.

In fact the truth that Typo3 has alternative page module, which is not 
so bloated, shows that even core developers regard the basic page module 
bloated!

At the same time it has much redundant buttons and missing of important 
features. I almost rewrite the whole 'Columns' view!
It works now quite well and is relative fast and easy to use.


> 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. 

that could be done in this way - we both agree that the default 
interface of the page module is bad.
But i would not put neither the bare minimum - but something between
bare minimum and bloated (*newer* so bloated than the default page 
module is - it is just an example of very bad interface desiging -
that's why there is just few people who are interested to develop it 
better).

> 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.

basically the core team made bad mistakes, when they made the standard 
page module - everybody addmits those mistakes, I believe.
It was hard work to make working page module.

>> how to make choises, what content to use and where to put the content?
> 
> 
> I'm not sure what you mean. 

you can put content into different content areas and you can use 
different content types - if you don't use a wizard you might need to 
select them from drop-down-menus afterward.

But adding new content depends on situation.
Adding new content element you normally don't need to define the content 
area but just the type because the content area, which you edit will be 
defined automatic.

In frontend editing not necessary wizard at all - adding new content 
after existing you add normal text if you don't change the type.
It is really easy in frontend editing to add a new content to a page.

>Basically, wizards are very ineffective.

yes - depends on the quantity of steps.

>> > 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
> Again, I'm not sure what you mean. Could you please write longer 
> sentences? :)

And I was not sure, what buttons you mean.

>> 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 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.

for me it is difficult to decide, what is the reasonable quantity of 
buttons.

>You're probably a developer and know a lot about

I really try to think about different kind of users - and I normally
make different setting for different users.

> It's one click more and most users would be thankful for a cleaner
> interface.
IMO SELECT-menus are ugly and they are not cleaner - especially they 
would make the frontend editing very ugly. Row of buttons looks IMO 
better - or tabs (one tab-row/ view works).


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

but if the page need for example five independent content areas in 
different places - CMS must be capable to create page, where contents
can be in any place the developer wants without any limitations.

> 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.

You should create a template for viewing complex structures.
IMO you shemes fits only for simple solutions. I don't believe
that page can ever be a one record because it doesn't offer unlimited 
freedoms.

> 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?

too easy to destroy because they would be among normal contents.
or this is just an unnecessary fear.


> Could you please give a good example? 

if you have big text they must scroll in WYSIWYG screens.

> 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.

normal text uses WYSIWYG editor and they are easy to edit.

  > Well, you could copy-paste in a WYSIWYG editor, too.

but you must select with mouse.

> that (esp. if they use WYSIWYG editors, so they don't get in contact
> with those tags).

If they have possibity to edit source codes.

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

complex page structures - you need for them then templates or markers 
inside normal contents. Much markers - much possibities to destroy the 
layout, because there is no way to stop editors to entire destroy the 
layout. All in one WYSIWYG view is really vulnerable system.