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
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
- 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
It's all about the 'list mode'. It can be used to edit any DB table
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).
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
- If not, what can I do about it? Would filling out a bug report be
If there is a technical issue I'm missing, I'd be interested to hear