Name and taxon details: UI counter intuitive regarding cache states
It turned out that the originally reported problem was not a technical one but rather caused by the users sightlessness which was caused by a bit of hurry and the UI.
The original description is retained below:
Original subject: "Name Editor is not being refreshed after changing the name and taxon details"
After editing the name and taxon details the Name Editor still shows the old data:
- new taxon "Lymanbensonia incachacana variabilis" (supra-specific rank label is missing!) -> this name has parsing problems, thus the titleCaches will be protected
- edit name: rank=variety, genus=Lymanbensonia, epithet=incachacana, infraspesificEpithet=variabilis
- the taxon title cache is still protected, lock it by unlocking the lock icon
- the name editor is dirty now, save it
==> RESULT: the name editor still shows the originally entered text.
- closing and re-opening the name editor does not update the name
- The Taxon Node Editor shows the correct name
- Re-connect does not help
#1 Updated by Andreas Kohlbecker over 1 year ago
Ahh, now I understand the problem, it is the TaxonName.titleCache which is still protected.
I completely overlooked that this lock icon still is in unlocked state.
I am having the impression that the UI is not clear enough regarding the various caches and their protection states, whereas the following problems exist:
- TaxonName nameCache and titleCache are spatially too much separated from each other -> these fields should be next to each other
- The separation of Name and Scientific name pane makes adds an unnecessary complexity -> moving all the Scientific name fields to Name would make the UI much clearer
- the padlock icon unlocked and locked states are not easy to distinguish
- In case the Name.titleCache is being locked the Nom.-Code field is colored. (From the developer perspective this can make sense, since the code selection may determine the cache strategy, for users however this is rather confusing)
- The label of NomenclaturalCode should never be colored, the same accounts for the Rank
- Another color than Orange would help for a more intuitive understanding of the situation: Orange is close to red which usually means that this information is important. The atomized data becomes orange, when it is no longer being used to create string representations, but it is emphasized by the color and the users eyeball is dragged to these fields causing a distraction from the important details
- The scheme by which the coloring is switched on and off is logical but inconsistent: As far as is understand the logic, the idea is to mark those fields which would have been used if the cache was not locked (padlock icon locked).
- For the name cache this is ok. Genus, epithet etc are not used and thus colored when the name cache is is locked (padlock icon unlocked)
- When only the titleCache is locked (padlock icon unlocked) the situation is no longer intuitively comprehensible as shown here: Now the user needs the background knowledge that genus, rank, epithet, ... are used to build the name cache which is not used, so genus, rank, epithet, ... are also not used. This knowledge can be anticipated from the UI and the way it is arranged, but it is counter intuitive.
- When the taxon title cache is locked (padlock icon unlocked) and all name caches are unlocked (padlock icons locked) the situation is unclear. All name fields and cache fields should be colored since not used to build the taxon title cache.
The idea of coloring the unused fields can never be applied consistently to the UI, there are always situation in which the various cache-field dependencies will cause conflicting modes of the coloring scheme. I think we should consider to only modify the appearance of the cache fields, namely in that situation when they are irrelevant. This is much easier to handle since always consistent. The appearance of all other fields should not be changed. at all
Locked cache fields (padlock icon unlocked) could be renders as if they where ...
- inactive/readonly in default colors
- inactive special colors (font grey, background gray, dark and light)
- plain text labels (no text field box border around)
#5 Updated by Andreas Müller over 1 year ago
Andreas Kohlbecker wrote:
The idea of coloring the unused fields can never be applied consistently to the UI
I can't see this. Probably the current implementation, which is not yet fully correct, does not handle it correctly but I am pretty sure that it can be done consistently. The only semantics it has is "this field will not be taken into account when a cache is used". We already discussed that if multiple caches exist we need to work with various colours to clarify that certain fields are used only for 1 cache but not for the other one. Ofcourse this is not always fully intuitive as you need to know how to read it.
However, the important tasks here are:
- to indicate very clearly that there are protected caches somewhere and to show the user by this that there is something irregular in the data.
- to indicate that some field maybe will not be taken into account when entering data
The solution you suggest (and which we had more or less implemented in the past) does not fullfil this IMO. I not so seldom get request like "I entered data but it does not show up". It is enough then to ask if the field is colored. If you have to ask if one of the 3-4 cache fields are maybe protected/greyed out/have a text box border or what ever users will be more confused as they do not understand the cache fields anyway and especially not the multiple caches used in the taxon/name details view.
However, I fully agree that the current implementation still needs to be improved. There are tickets for this (also one which is resolved but needs to be given feedback as it is not yet fully correct, just had no time yet for this)