On Thu, May 28, 2009 at 1:20 AM, Hans-Emil Skogh <Hans-Emil.Skogh_at_tritech.se
> wrote:
>
> And what would happen if you manually uncheck half of the added files and
> then click added? Or unchecks all of them?
>
Doesn't matter. In a very naive/simplified implementation, manual
checking/unchecking of items would not affect the behavior of the toggle.
For example, if I click the "Added" link and 5 added items are selected,
then I uncheck all of them manually, and then click "Added" again, it is
still going to try to uncheck all added items. So to the user, it appears as
though the click did nothing, but this isn't a problem because if the user
intends this to check all of the items again they can do a second click.
Now, I'm not going to defend this behavior, however, since it is a naive
implementation. Ideally, you could do some minimal checking. For example, if
the "Added" link's next click is intended to uncheck all added items, but
I've manually already unchecked them all, then it could preemptively switch
to toggling them back on. There are various predictive behaviors you can
give the toggle feature, it's just a matter of gathering requirements.
However, you do make a valid point on this one.
I still thinks that options that doesn't do anything should be grayed out.
> If you save a document, the save option gets grayed out until you make a
> change.
>
No, it does not, not for most applications at least. I won't argue that this
isn't done at all, however in most of the applications I use (visual studio,
notepad++) you can save as many times as you want, regardless of if you had
saved previous to that.
> If you press undo, the button gets grayed out when there are no more things
> to undo. They doesn't just stay enabled wating for a user to press it and
> then silently do nothing.
>
Again, you're comparing apples to oranges. These are two completely
different problem domains. Some cases make more sense than others to provide
a disabled option. This is not one of them.
Graying out an option does also provide additional cues to the user, like
> that the document has not been modified since the last save in case of a
> save button, or the presence of added files in a list of files in our.
>
Why would they care about the presence of added files? All the user should
care about is making sure all added items were selected. If there are no
added items, and he clicks "added", that means he can still be rest assured
that his commit will contain all added items, even if there are none.
And as I said before, if the user really does care about this, my suggestion
to add a counter somewhere is also an option, but not a very important one
IMHO. I know that when I want to see if I have added items, I go to "Check
for modifications". I don't go to the commit dialog to see what kinds of
changes I've made to my working copy. When I go to "commit", that normally
means I am confident of the status of my working copy and I plan to do a
commit. At this point, I already know or don't care that I have added items.
The commit dialog is the last step one takes in the cycle of a single
integration, and if you are reaching this point without knowing what in the
heck your working copy looks like (roughly), you're doing something wrong
and you're probably breaking the mainline.
I just can't see why we should make an exception from a perfectly good GUI
> defacto standard here, without getting a single benefit from doing so!
>
I never claimed that there would be a benefit to disabling links as
you expect. In fact, all along I've been saying that either case is
providing no benefits. This is about what makes logical sense.
It does not seem logical to me to expend the effort to disable items when it
provides no immediate benefit to the user. It does not seem logical to
disable something that does not make sense to be disabled, since in the case
of a Toggle, it is impossible for it to never be useful to the user.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2356277
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-05-28 17:56:05 CEST