usability bug when changing type field

[Glen Stark-3]

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
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[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
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev