[TYPO3-hci] The Constant Triptichon

[Christopher]

Alex Heizer wrote:
> Hi David,

<snip>

Alex I appreciate how important you think this is, and I'm especially 
pleased that hci issues with TYPO3 are being taken seriously, but I wish 
you would take a deep breath and try to understand that there may be 
value to viewpoints other than yours. Your arguments are simply /not/ as 
compelling to everyone as they are to you--and it's not due to any lack 
of experience, understanding or comprehension of the objections you're 
raising. It's because not everyone agrees that they /are/ problems in 
the first place.

The objection that I raised somewhere in this thread to the FE-like 
arrangement in the Page module (i.e. that columns may well be a better 
way to display long lists of content items) is much a much more serious 
argument /against/ the use of an FE-like interface.

> Secondly, you can say that "cars and trucks" equate to CMSes in which 
> there are standard elements (gas pedal, speedometer, steering wheel) 
> that are found in all models (TYPO3, Joomla, ezPublish) but the 
> placement of which are unique to each model. When you purchase a car or 
> truck in the US, it comes with a manual specially created for that model 
> which describes exactly where all the elements are in that model. So the 
> Sunfire may have a center console shifter but my Malibu has the shifter 
> on the steering column. The windshield wiper control may be 
> steering-column mounted on the Sunfire but on the dashboard beneath the 
> speedometer on the Malibu. But every Sunfire will have the shifter and 
> windshield wiper control in exactly the same place, and the 
> documentation will reflect that.

And any person who's driven a different Sunfire will be able to figure 
out the Malibu 'interface' in /minutes/. This is not a problem.

> The shifter doesn't move just because 
> on my Sunfire the paint is silver and I have sport wheels and tires, 
> compared to your blue Sunfire with standard wheels and tires. This is 
> the important aspect of a standard interface: the manual reflects the 
> exact location of a feature, and the car manufacturer spends a lot of 
> time and effort making the cabin usable, but also spends a lot of time 
> and effort creating documentation so that a new user can easily locate 
> everything.

This is drifting somewhat from the purpose. The differences in 
'interface' between different vehicles from the same maker are typically 
very small. /This/ is the situation we're discussing; a /very small/ 
difference between the interface of the cars that I detail compared to 
the ones you detail.

> And don't forget that cars are made for specific target countries, which 
> is why I can't buy a Smart or a Skyline GTR-34 in the USA. TYPO3, on the 
> other hand, is made for users in all countries and must take into 
> account that a change which "makes sense" to a user in one country may 
> be backwards to a user in another country (think: difference between 
> reading left-to-right in English and romance languages or right-to-left 
> or up-to-down in other languages).

Again, not really relevant to the current discussion--though important 
to general usability--since TYPO3's BE is already completely backwards 
if you're reading a rtl-language (i.e. since the frameset works as a 
sort of ltr drill-down navigation system).

> Having a standard interface that is 
> absolutely predictable for all editors is a must for usability.

if ('absolutely predictable' == 'visually identical') {
	'standard interface' != 'absolutely predictable';
}

A good, standardized interface is one whose

a) component parts are always present in different implementations 
(shifters are always present!)
b) component parts /operate/ identically in different implementations 
(shifters always work in one of two ways!)
c) important component parts are quickly available to the operator or user

If an interface must be absolutely identical to the standard or stock 
interface, then presumably you will be equally adamant that the ability 
to rename and reorder columns in the original page module be removed?

> That way 
> a consultant who has a client in another country can continue to support 
> them without undue hardship on the part of the consultant having to 
> figure out each site each time. Every time I've had to take over an 
> existing site for a new client whose site was set up using TV I have had 
> to spend time during a "discovery phase" to figure out their site 
> because it doesn't follow any standard setup. That's time I don't get 
> paid for, which makes my business less sustainable, which means to me 
> it's bad business sense to have to support another developer's site done 
> in TV.

Again, this has nothing to do with the discussion at hand. TV, at the 
moment, only displays columns, and has extremely limited opportunities 
to change the layout of the Page module (limited only to changing the 
order of columns)--and the original Page module can do be configured 
this way as well.

I don't see what currently possible changes to the TV /Page module/ 
could possibly take more than a minute or two to decipher. Any /other/ 
problems you're bringing up are not relevant here.

> Yes, it's nice for a new developer to be able to install an 
> extension that provides a lot of shortcuts to making a template without 
> them having to actually learn how to do real stuff in TYPO3, but for 
> both the end user and the next consultant to have to support the site 
> this deviation from a standard interface can be a nightmare. Since TYPO3 
> was designed to allow easy maintenance of a website, we really need to 
> think about maintenance usability instead of "neat-o" trick features 
> that a developer who is familiar with their own site will find "cool".

What place does this polemic have in this discussion?


-Christopher