[TYPO3-dev] [TYPO3-project-4-3] Re: usability bug when changing type field

[Xavier Perseguers]

Hi Glen,

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

It's not OT, but this discussion would be even better on the general 
list I would say. I'm moving it there.

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

I agree and I don't see the point keeping this dialog which, btw I 
ignore myself too.

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

I agree too.

>   - 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 agree to both point too although I know that due to some internal 
handling of those forms, changing this behavior would be a bit trickier 
than first issue that the warning box may be removed. At least, having 
the ennoying dialog tells you that the record will be saved, hiding it 
will lead to orphans records in case you change something that makes the 
form reload itself.

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

Yes, but what you missed is that some fields are computed during loading 
of the form and if an information changes, the whole form including 
fields that seems to be independent might be updated too. This is why it 
might be a bit tricky to do it "the right way".

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

They are right.

>  - If this is a typo3 thing, is there a plan to correct it in the next 
> release?

AFAIK (99% sure) no!

>  - If not, what can I do about it?  Would filling out a bug report be 
> appropriate?  

Provide a patch ;-)

> If there is a technical issue I'm missing, I'd be interested to hear 
> about it. 
> 
> Thanks for your time,

Thanks for sharing your editor thought with all of us. It's always good 
to have feedback from non-TYPO3 developers.

Regards

-- 
Xavier Perseguers
MVC ExtJS Leader

http://forge.typo3.org/projects/show/extension-mvc_extjs