[TYPO3-hci] The Constant Triptichon

[Alex Heizer]

Hi David,

David Toshack wrote:
> Hi Guys,
>
> IMHO the concept of FE vs. BE editing is not a natural HCI concept. It
> is a TYPO3 concept which only causes an extra layer of complexity to
> newbies. "Editing content in relation to its context" vs. "editing
> content irrelevant to its context" is a natural HCI concept. Table of
> contents vs. index/search for example.
>
>
> Lets look at this from a distance to work out _why_ different styles of
> editing are required. You don't use the index to find context sensitive
> content of a book. You use the table of contents because it guides you
> to the context in which that content is to be found.
>
> Conversely, you don't scroll through the table of contents to find a
> specific piece of content in which the context is irrelevant to your
> requirements. That is what the index or search is for.
>   
Two methods for looking up information, depending on on your intent and 
I often use both. Sounds like the difference between FE and BE editing 
to me. Seems like a natural concept, I don't understand the confusion.

>
> IMHO FE editing should be merged with TemplaVoila for context sensitive
> content editing. With the option of a "Dynamic Content Only" toggle to
> replace the TemplaVoila Page module.
>   
So a core feature should be merged with an extension that not everyone 
uses because not everyone wants to use it? This is exactly what my point 
is, why force something upon people who don't want to use it? If you 
have specific features you'd like to see implemented, that's one thing 
but TV isn't something that should be merged, wholesale, into what 
already exists that thousands of people are already used to. Like I said 
in a previous post, if you want to extend the FE, it should be extended 
to provide specific features that are missing.

> I don't agree with the documentation argument against a context
> sensitive editing layout. Car manufactures make many different makes and
> models of cars. Most of which have a completely different layout. The
> car manual will show you where all the major components can be found via
> a _very_abstract_ diagram. This diagram is specific to that particular
> model, which is all that is required in terms of finding the major
> components of your car. Although quite abstract in nature, I am not
> degrading the importance of this diagram. Its usually found on the first
> few pages of a manual. Not dissimilar to a sitemap which should always
> be found on the top level of a website.
>
> Manufacturers that make both cars and trucks don't make the interior
> _exactly_ the same. That's crazy! The design and layout is relative to
> the context of the vehicle.
>
> Although one might be a truck and one might be a car, if it is the same
> manufacturer in the same era, in 9 out of 10 cases you will find that
> window wipers, demisters, radio controls, foot pedals, even boot
> releases ... all work the same way; which is where the specific,
> collaborated documentation in the manual lies.
>
> Not only are context sensitive concepts recognized by humans in day to
> day life, they actually _simplify_ documentation. Why would you bother
> introducing a new context which has to be learned, rather than using the
> existing context that humans already understand? That is as crazy as a
> car sharing the same interior as a truck. Not only is it not natural,
> but its sooo much more natural for the context to be relative to the
> model in which they are trying to relate it to.
>   
There are two ways this can illustrate my point, depending on your point 
of view.

First, in all vehicles, there are standard placements of things. There 
are seats in the same place for both cars and trucks; the steering wheel 
is placed the same, relative to the driver; the gas pedal is on the 
right and the brake in the center, with a clutch on the left if it 
exists; the turn signals are in the same place and function the same (up 
for right signal, down for left). Equate this to the BE and you get an 
overall standard layout that doesn't change even if I'm driving a 
Porsche and you're driving an F-150. You don't have 4 turn signals 
spaced all around the cabin to reflect that in the FE (the exterior of 
the car) you have 4 direction signal lamps. Your gas and brake pedals 
don't mechanically switch to the back seat when you throw the car into 
reverse. So the standard interior doesn't change according to the 
context of the exterior.

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

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). Having a standard interface that is 
absolutely predictable for all editors is a must for usability. 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. 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".

So either way, your example shows the importance of not only having a 
standard location for each element that doesn't change based on the 
exterior of each individual vehicle (website), but also for a given 
model (cms) having a standard interface that remains identical for each 
unit built (installation) that documentation can be created for.

>
> I apologize if I have gone off on a tangent and am thinking more into
> the future than this thread was intended, but I believe this method
> makes the clear 1-2-3-you're-done process for editing much easier
> because the user relies on the automated context sensitive methodologies
> they have learnt simply from web surfing, instead of the need to
> reinvent and dictate new ones that are usually irrelevant to the context
> they are intended for anyway.
>   
This takes into account many editors in one culture, but in my 
experience many editors have basic computing skills and use the computer 
as a tool to accomplish specific job-related tasks. In other words, many 
editors don't have anything "learnt simply from web surfing", since 
surfing isn't something they ordinarily do. Being able to clearly show 
them a 1-2-3-you're-done process without making any preconceptions about 
their experiences or abilities would be best, especially when taking 
into account cultural differences of using an international product. I, 
for one, don't have the experience to make any assumptions about what a 
user in Brazil or mainland China will have learned from web surfing. So 
the interface and documentation need to be as clear as possible for 
everyone, not just the developer who is familiar with their one site.

Cheers,
Alex

>
> Cheers,
> David
>
>
> Uschi Renziehausen wrote:
>   
>> Hi Joey,
>>
>> JoH wrote:
>>     
>>>> It seems to me that we have 3 people thinking that the backend
>>>> representing the front end visually in some manner is a good idea -
>>>> and one person (all due respect) obviously in disagreement,
>>>>         
>>> You can count me in, so it's 3:2   :-)
>>>       
>> Now it is 4:2 ;-)
>>
>>     
>>> IMHO a great number of the TV downloads is due to the fact that the
>>> tutorial
>>> is called "futuristic template building" so maybe you should choose a
>>> similar wording to get better results ;-)
>>>       
>> May I inform you that I first heard/read about TV as a possibility for
>> getting out of the restrictions to 3-5 collums and then was frustrated
>> because I could not find any help how to use it, because I did not know
>> that the title of the TV-Tutorial is 'Futuristic Template Building'?
>>
>>     
>>> Just my 2 cents
>>>
>>> Joey
>>>       
>> Another cent by Uschi :)
>>
>>     
> _______________________________________________
> TYPO3-team-hci mailing list
> TYPO3-team-hci at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-hci
>
>