[TYPO3-dev] usability bug when changing type field

[Glen Stark]

Greetings.

I hope I'm in the right place for this post.  Apologies if I'm OT

I'm working at the LEM at the ETH Zurich as technical lead for a suite of 
software from Gecko-Research.  I've been asked to look at our web page to 
try and  improve how things run, so for the next few months I'm taking 
care of the web page, doing a lot of data entry, and figuring out how to 
streamline things.

I have run into what appears to be a usability issue, or perhaps more 
correctly it's a bug which a hack has turned into a usability issue.

  In our specific instance, we have a form which allows entry of 
publications.  These might be of different types, say Journal 
publication, Conference paper, phd-thesis, etc.  The data entry fields 
change depending on what type of publication you are entering.   So, for 
example, when create a new paper, and choose a non-default value, say 
"conference paper", a popup appears to tell me:

"This change will affect which fields are available in the form.
Would you like to save now in order to refresh the display?"

This is a useless, and indeed harmful dialog in this context (in all 
contexts?).  If I need to change the paper type, providing me the option 
to say ok or cancel is useless in that it is no choice at all.  I must 
click ok.  So we have the following problems:

(apologies if these things are overly obvious, or appear overly 
contentious)

- It is inefficient: it interrupts my workflow and concentration,
forces me to navigate the mouse to click "ok" on a meaningless dialog.
It's like having someone stand by your desk and ring a bell at  random
intervals...  It's minor, but it interrupts your concentration, rapidly
becomes very annoying, and negatively affects productivity.  In my case,
I have mouse induced repetitive stress injuries, so I get really annoyed
by unnecessary mouse clicks.

- Usability research, and probably your own experience, has shown that
useless dialogs are harmful, in that they train the user to ignore pop
ups.  They eventually barely register the pop up, clicking ok on
auto-pilot, leading them to ignore important dialogs.  Thus, one should
interrupt the user only when one thinks the user would appreciate the
interruption:  i.e. some event the user shouldn't be able to ignore.
Since the user can safely ignore the dialog in question, it would be
better gotten rid of.  


  - if the user creates a new publication, changes the publication type,
and then closes the dialog without saving, NO publication should be
saved or created.  As it stands an empty publication is created.
 
 - if the user saves a publication (or edits an existing publication
type), makes some changes, changes the publication type, and then says
"oh crap, I'm working on the wrong paper", and clicks on "Close
Document" (without saving), the publication should remain in the state
it was in when last saved.  As implemented the would have to manually
undo their changes.

I contacted the site administration team, and they inform me this 
behavior is inherent in the typo3 implementation, and they can't do 
anything about it (they have apparently gotten rid of the pop up for me, 
but that just removes the hack, not the original problem).  According the 
support team:

<<
It's all about the 'list mode'. It can be used to edit any DB table 
contents.
As a typo3 extension programmer, you only provide a DB schema dump
and a description of how the editor for the DB fields shall look like,
called TCA (table config array -- it's a huge PHP array).
http://typo3.org/documentation/document-library/core-documentation/
doc_core_api/4.2.0/view/4/2/

In that array, you can define a 'type' field (see 'ctrl' section on top
of the page named above).
Whenever the 'type' field is changed, you'll get that popup (by default).
The fact that it _saves_ during switching types is really a [bad] typo3 >>

>>

I haven't taken the time to dig into your code, but from my perspective, 
it seems like on changing the type, the records is saved, the form is 
refreshed, and the record ID is passed to the refreshed form which loads 
the saved record.  This is probably economical in terms of development 
time, but has the negative consequences I outlined above.  A simple 
workaround, which would avoid the bad behavior,  would be to use a 
temporary record, which only gets written to the permanent table (and 
gets assigned a record number) when the user chooses to save the record.  
I can think of other alternatives, but that seems like the simplest.

So, I would like to ask the people on the list:
 - Is it true that this is inherent the typo3 implementation, or is the 
support team just passing the buck?
 - If this is a typo3 thing, is there a plan to correct it in the next 
release?
 - If not, what can I do about it?  Would filling out a bug report be 
appropriate?  
 
If there is a technical issue I'm missing, I'd be interested to hear 
about it. 

Thanks for your time,

Glen Stark