Issue 92701

Summary: get rid of "text was truncated" popup
Product: gsl Reporter: richlv <richlv>
Component: codeAssignee: marc.neumann
Status: CLOSED FIXED QA Contact: issues@gsl <issues>
Severity: Trivial    
Priority: P3 CC: frank.schoenheit, issues
Version: DEV300m29Keywords: usability
Target Milestone: OOo 3.1   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Latest Confirmation in: ---
Developer Difficulty: ---

Description richlv 2008-08-12 11:50:16 UTC
when inserting numeric and formatted fields with limited allowed max content 
length, attempting to enter another symbol when at the limit pops up a message
 : "The inserted text exceeded the maximum length of this text field. The text 
was truncated."

such a text is not displayed for normal textfields.
this popup serves no hugely useful purpose, interrupts the workflow and makes 
user read (or learn to ignore) the popup and close it.

the length should be limited just like it is for plain text field, without any 
popups.
Comment 1 philipp.lohmann 2008-08-12 12:07:41 UTC
issue 80073 and issue 73360 say differently
Comment 2 philipp.lohmann 2008-08-12 12:08:03 UTC
closing
Comment 3 richlv 2008-08-13 14:14:57 UTC
ah, my search for 'text was truncated' didn't turn those up.
anyway, i consider that in this case the fix has been worse than the problem it 
tried to fix. the problems with this solution :

1. it interrupts user's workflow with the popup dialog (user has to read & 
close the dialog);
2. this can even result in a minor data loss - suppose somebody is entering 
some long number, then hits some other key when at the character limit (and the 
field has max value set) - field contents are immediately set to max value, as 
soon as the popup is opened;
3. this is inconsistent, as text fields do not produce such a warning.

this popup looks really weird especially on fields that allow single char input 
and are appropriately sized...

possible ways to improve it :

1. try to detect pasting (which seems to be the biggest cause of the 
disappointment with the old behavior) ? this is done in some places (for 
example, irssi), so that warning is only shown when there is actual possibility 
that loss of pasted content might go unnoticed;

2. make the warning non-obtrusive - something like oo.org help agent pop-under 
or down-sliding warning in firefox (for prevented page popups and other 
things). this way user would be properly notified of field limit both when 
pasting and when trying to type past the limit, but the workflow would not be 
interrupted.

i really believe form fields have become much less convinient to use with this 
change, but i won't be pursuing the issue, i'm just pasting my impressions & 
suggestion for the consideration.
i can report any of them as new issues, or reopen this one for implementation 
of particular improvement (like non-obtrusive warning).
Comment 4 philipp.lohmann 2008-08-13 19:40:45 UTC
ok, let's ask mr. formfield then: fs, what's your opinion ?
Comment 5 Frank Schönheit 2008-08-15 09:48:29 UTC
I definitely agree to richlv. A message box popping up during normal text/data
input is certainly a severe usability issue.

If it's not possible to fix this in VCL in general (by detecting paste
operations, as suggested by richlv - this would be the right way to fix it IMO),
then we should introduce a setting/flag/whatever at the controls, and VCL
controls create from within the toolkit should set this flag then.

Adding usability keyword, adding regression keyword (since the usability issue
is in fact a regression, even if it was intentional), targeting to next feasible
release, confirming.
Comment 6 philipp.lohmann 2008-08-15 10:02:17 UTC
We can change it again, but defined behavior can neither be a defect nor a
regression
Comment 7 richlv 2008-08-15 10:55:58 UTC
thanks for the positive response, i'm impressed & very glad ;)

maybe a non-obtrusive warning in all cases (both typing in and pasting) would 
solve most issues here ?

or maybe non-obtrusive warning for typing, and a popup for pasting, if that can 
be detected ?

also, if these changes get introduced, they probably should also be propogated 
to the text field, which currently does not have the warning, as opposed to 
formatted fields.
Comment 8 Frank Schönheit 2008-08-20 11:16:04 UTC
fs->pl: Maybe the behavior was defined that way for controls in normal OOo
dialogs, but the changed behavior of form controls is most certainly an
undesired side effect. In case it isn't - I do not know who "specified" the new
behavior of a modal message box during normal user input, but a) such a behavior
clearly is a big usability flaw and b) to my best knowledge, nobody from the
DB/forms team was involved into this decision.

Anyway. As long as we fix this problem for 3.1, I don't care too much what flags
we give it.

May I suggest to apply the changed behavior if and only if the max text length
is exceeded due to a pasting operation? Popping up a model message box during a
normal typing really is weird, usability-wise. If users really need to get
feedback that the letter they were to type doesn't fit anymore, we should find
non-intrusive methods to tell them.
Comment 9 philipp.lohmann 2008-11-03 15:19:44 UTC
done so in CWS vcl96
Comment 10 Frank Schönheit 2008-11-03 15:37:27 UTC
thanks a lot!
Comment 11 richlv 2008-11-03 15:39:14 UTC
even more thanks from me ;)
Comment 12 philipp.lohmann 2008-11-17 12:18:05 UTC
please verify in CWS vcl96
Comment 13 marc.neumann 2008-11-24 12:13:08 UTC
verified in CWS vcl96

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fvcl96
Comment 14 Frank Schönheit 2008-11-24 16:30:43 UTC
*** Issue 82495 has been marked as a duplicate of this issue. ***
Comment 15 thorsten.ziehm 2010-02-22 15:39:50 UTC
This issue is closed automatically. It should be fixed in a version with is
available for longer than half a year (OOo 3.1). If you think this issue isn't
fixed in the current version (OOo 3.2) please reopen it. But then please pay
attention about the field 'target milestone'.
The closure was approved by the Release Status Meeting at 22nd of February 2010
and it is based on the issue handling guideline for fixed/verified issues :
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues