Re: [Audacity-devel] Effect input validation and error messages

[Peter S. <pet...@ya...>]

I *like* Martin's warning icon.
 
I do appreciate Gale's comment about its discernabilty for VI users
but then Gale goes on to like the graying-out of OK which presumably
is equally indiscerbale for VI users.
 
I do *not* like verbose error messages - short and sweet is hood, and 
then the user can go off to RTFM if they need more background and 
enlightenment.  :-)
 
Peter

Peter Sampson
Tel: +44 (0)1625 524 780
Mob: +44 (0)7732 278 299
 

________________________________
 From: Gale Andrews <ga...@au...>
To: aud...@li... 
Sent: Friday, November 29, 2013 6:29 AM
Subject: Re: [Audacity-devel] Effect input validation and error messages
  


| From James Crook <cr...@in...> 
| Thu, 28 Nov 2013 21:10:45 +0000
| Subject: [Audacity-devel] Effect input validation and error messages
> The style that I think works best is to have warning icons beside invalid values:
> 
> When you hover over the icon, a tooltip appears telling you what the problem is.
> Here it would be that you have 'disabled the Z Register', but elsewhere have a setting which
> needs 'the Z Register'.  That setting would also have the warning icon.
> 
> This deals properly with cross-value dependencies.  For example, if max silence duration
> had to be greater than min silence duration you not only show it, but show which settings
> have the problem.
> 
> The warning icons show immediately there is some problem.

I think we should get David's opinion too. I'm not sure how accessible 
inline text messages are across all the different screen readers, but
I assume that icons or their tooltips won't be accessible?


> There are other ways of doing it which attempt to prevent you going through illegal
> values.  Experience shows that that is generally a bad idea.  If min and max are 10 and 20,
> and you want to set them to 2 and 5, you ought not to be prevented from changing
> the 20 to a 5 first.
> 
> I prefer that OK is not greyed out on an error.  If you click it, a dialog tells you that
> there is a problem with the values and that you can hover over the '!' icons to see
> a description of each problem.  I'm willing to be persuaded that the OK button
> should instead be greyed out - though I think in non obvious cases it will be a cause of
> questions that are like that old perennial 'why are my effects greyed out?'.

At the moment I like OK being greyed out in conjunction with an 
inline warning the most. No need to hover over icons or guess 
their significance.  

It depends how many inline warnings there may be and if we want 
to show all warnings as soon as one applies (as per current Truncate
Silence), all that apply at a given time, or only one warning at a time
(even if more than one currently apply).  

A warning icon with OK active seems a somewhat confusing
mixture of messages to me. 

But if it is hard for screen readers to access the inline text or icon
tooltip, a popup error on OK would be very friendly for them.


> I think we should however aim to be consistent on whether OK 
> greys out or not

+1.



Gale 



> and that needs a group decision/policy as to how to handle it.  We also as a group should
> decide whether we like the icon approach.
> 
> In view of accessibility, I think it's too late/risky to make changes to validators for 2.0.6,
> if we are going for the dates Vaughan has suggested.
> 
> --James.
> 
> On 28/11/2013 15:23, Steve the Fiddle wrote:
> > Cc: to -devel as this also concerns design policy.
> >
> > This refers specifically to "Truncate Silence" and "Bass and Treble",
> > both of which are currently being updated, but also applies more
> > generally to all built in effects.
> > (prompted by http://bugzilla.audacityteam.org/show_bug.cgi?id=683#c6)
> >
> > Currently, user input is validated in a variety of ways. There is
> > little consistency.
> >
> > It is often essential that user input is validated so as to avoid
> > errors, but there are many ways that this can be done. The
> > "importance" is that the plug-in code receives valid data. The
> > secondary issue is to help reduce user errors. Input validation does
> > not, in itself, prevent user errors. What validation does is to ensure
> > that the code does not try to process with impossible parameters.
> >
> > A user error may cause an effect to produce the "wrong" result
> > ("rubbish in, rubbish out") but that is not the concern of input
> > validation.
> > Invalid data may cause crashes, freezes, corrupting of the project,
> > security vulnerabilities, or any manner of error. It can be difficult
> > to work out exactly what problems can be caused by invalid data so it
> > is important that invalid data is excluded. This is the primary
> > purpose of validation.
> >
> > Example below are taken from Audacity 2.0.5 on Windows XP.
> > Some of the validation approaches are:
> >
> > * Invalid input is "ignored" by the code. Example: if a negative
> > number is entered for "repeats" in the Echo effect, the effect exits
> > doing nothing.
> > * Invalid input greys out the OK button. Example: enter a positive
> > number as "New Peak Amplitude" in the Amplify effect.
> > * Typing invalid characters is prevented (1). Example: Leveller. There
> > is no way to enter an invalid value.
> > * Typing invalid characters is prevented (2). Example: most effects
> > prevent typing non-numeric characters in numerical input field.
> > * Invalid input produces a pop-up error message on "OK". Example:
> > Enter a frequency of "0" in High Pass Filter.
> > * Invalid input produces an "in-line" warning. Example: Enter 0 as
> > "Minimum silence" in Truncate Silence.
> > * There are others.
> >
> > Then there is the question of "what" is validated and the strictness
> > of the validation.
> > * Truncate silence allows any combination of numbers, comma, dot, +, -
> > and "e" as "valid" numbers,
> > * The Frequency fields in Change Pitch allow only numbers and one dot.
> > (comma cannot be used as the decimal separator).
> > * "Optional click track duration" in Click Track allows any characters
> > to be typed and produces an error on "OK" for invalid values.
> > * There are other variations.
> >
> > There are pros and cons to many of these approaches, but the main
> > reason that we have such a variety (so little consistency) is because
> > we had no really good general method for input validation. That may be
> > about to change with the introduction of the new numerical validators
> > (one for integers and one for float values).
> > Benefits provided by the new validators include:
> > * Only allow actual numbers, not just numerical characters: 123.45 is
> > a valid floating point number. +-1.2.3.4 is not valid.
> > * Comma is used as the decimal separator with relevant locale.
> > * Range can be validated (optional). Thus if valid numbers are 0 to
> > 100, then "-" cannot be typed and values greater than 100 cannot be
> > typed.
> > * The Integer validator does not allow the decimal separator to be typed.
> > * Attempting to type an invalid character produces a beep (may require
> > system sounds to be enabled) and the character is not typed.
> >
> > Disadvantages of the new validators compared with other methods:
> > * In-line warnings can be "educational". If the user is unable to type
> > an invalid value then there is no opportunity to show the educational
> > message. On the other hand, if they can't type an invalid value then
> > there is probably not much need to "educate" the user.
> > * There are implementation issues that can cause accessibility
> > problems, but it looks like these can be overcome.
> > * The validators do not prevent invalid values from being pasted, but
> > this can be handled separately,
> >
> > Overall, I think that the best policy would be to gradually roll out
> > the new validators across built-in effects, but not dogmatically so.
> > There may be some effects where the new validators are too
> > restrictive, or that the "educational value" of an in-line warning
> > outweighs the benefit of preventing user error. In most cases I think
> > it is better to prevent an invalid value from being typed, but I
> > expect there will be exceptions, for example I think that an in-line
> > warning could be useful in the Amplify effect rather than just greying
> > out the OK button.
> >
> > I think that the main case for including in-line warnings is in cases
> > where the valid range of values may vary. For example, filters cannot
> > have a corner frequency greater than half the sample rate, so a low
> > pass filter frequency of 10 kHz is valid only as long as the sample
> > rate is greater than 20 kHz. Unfortunately Nyquist plug-ins cannot
> > currently implement an in-line message, otherwise it would be nice to
> > have an in-line message in High/Low Pass Filters if the frequency is >
> > half the sample rate.
> >
> > I'd like to invite views and opinions as I am currently working on the
> > interfaces for Bass and Treble and Truncate Silence.
> >
> > Steve



------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
audacity-devel mailing list
aud...@li...
https://lists.sourceforge.net/lists/listinfo/audacity-devel