Thanks -- and to Alex, too -- I hadn't thought of grouping the
check- boxes. I'm first going to try a simpler & more permissive
approach and see how the user-experience feels, but if that's not
satisfactory I'll do the second group.
That's (kind of) why I suggested a global rather than disabling the
check boxes.
There's a danger of the user seeing those click boxes and being
frustrated by the fact that he wants to click one of them (to move
on to the next question?) and isn't allowed to. That's how *I* feel
sometimes about UIs - even if the UI guidelines say you should
disable controls that aren't available. So I thought that my
I find it frustrating to come across a disabled button and not be
able to see why it is disabled. In one application I am developing, I
have adopted the following strategy for screens where a lot of data
must be entered before proceeding: I put an invisible button
underneath the disabled button. If the disabled button is clicked,
the click passes through to the button underneath which can tell the
user what data is missing. This saves people a lot of time trying to
work out why the button is disabled, while giving them the visual
feedback that they haven't finished. If the button is enabled, it
traps the click and the information button underneath never gets used.
I'm sure the HIG purists will be horrified at this, but for this
particular app, it works really well :-)
Cheers,
Sarah
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
