[TYPO3-hci] The Constant Triptichon

[Alex Heizer]

Hi David,

My apologies. You had responded to my email which was about something 
else, and I didn't realise you had changed the thread to be about 
context. I understand the concepts and agree that it's important for 
people to be able to relate things within the context of the environment 
in which they are working.

However, my point was only about why TV or TV-like context changes 
should not be incorporated into the core, effectively changing the 
current BE environment.

I also appreciate your passion on the subject and everyone's enthusiasm 
to discuss ideas to help move T3 forward. Otherwise, where's the 
community? It would just get stale and boring. :)

Cheers,
Alex

David Toshack wrote:
> Alex Heizer wrote:
>   
>> 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.
>>     
>
> Close, but let me explain. The _context_[1] of this particular post is
> CMS specific, not TYPO3 specific. FE and BE are not natural concepts.
> Which is why I did not use the terms FE and BE. Lets imagine for a
> second that we're just designing a generic CMS interface. Or not even
> that, lets just call it an editing interface to be completely abstract.
>
> I can't stress enough the importance of HCI and the Human concept of
> _context_ ... it is how us human rationalize anything. If _anything_
> isn't in context it doesn't make sense to us! If you take something
> _out_of_context_[2] its context must be learnt before it can be applied.
>
>
> - Editing content in relation to its context:
>
> - - TYPO3: FE, TemplaVoila and the Page module
>
> - - Generic: Content you're editing relates _directly_ to the _position_
> it is in. FE is right on position, TemplaVoila is very close (could be
> closer, and have the ability to toggle between the two). Page module
> uses a sudo position. It is not always used in its context which defeats
> the purpose of even having a context, other than being close to it. (Not
> good enough in my opinion if we're going so much effort for HCI.)
>
>
> - Editing content irrelevant to its context:
>
> - - TYPO3: List module, and any other module used to edit records of a
> specific type or category. Not created especially for one specific
> _position_ or _context_ on your website.
>
>
>
>   
>>> 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.
>>     
>
> Please try and understand I'm being _very_ abstract with this post.
> TYPO3 should not even be mentioned. Little own core features and
> extensions. As you will see, the keywords in this post are _abstract_
> and _context_.
>
>
>   
>>> 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.
>>     
>
> Thats crazy, how is having pedals in the back in context? In fact
> everything you have mentioned that is in the same place is in _context_
> with its use. You have completely missed my point.
>
>
>   
>> 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.
>>     
>
> Its all about context. I bet you won't find an air brake lever in that
> manual, or on that dashboard. Please don't dumb down my arguments to
> suite your point of view. You're taking what I say out of _context_,
> excuse the pun!
>
>
>  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.
>>     
>
> See above.
>
>
>   
>> 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".
>>     
>
> I agree completely! That is why I say TemplaVoila should be in _context_
> with the layout of the website. If the context in which they're editing
> is obvious at a glance, surely this beats trying to figure out which
> content area is mapped to where.
>
> This is not about "neat-o" trick features, it is about HCI!
>
>
>   
>> 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 beg to differ. You're not taking into account the _context_, which is
> what my point was all about!
>
>
>   
>>> 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.
>>     
>
> I should have stuck with the table of contents vs. index analogy. I'm
> sure all cultures understand that concept. Its the concept of _context_
> I'm referring to. Its a very simple concept for humans. Even most
> animals of the world rationalize things in context.
>
>
> We obviously don't see eye to eye on this, as many of us have made
> _very_clear_ points which have been discounted. However, as a solution I
> see no reason why the existing Page module couldn't stay if enough
> people share your view. which would mean you get to keep your existing
> sudo page layout documentation. Maybe it can be disabled by default if
> the majority would prefer.
>
> The world would be a very boring place if we all saw things from the
> same point of view, and I appreciate your passion on the subject. Thanks
> for the discussion.
>
>
> Cheers,
> David
>
>
> [1] http://en.wiktionary.org/wiki/Context
> [2] http://en.wiktionary.org/wiki/take_out_of_context
> _______________________________________________
> TYPO3-team-hci mailing list
> TYPO3-team-hci at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-hci
>
>