[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Another auto-close idea...

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Tue, 31 Mar 2009 21:07:49 +0200

void pointer wrote:
> On Tue, Mar 31, 2009 at 11:30 AM, Stefan Küng <tortoisesvn_at_gmail.com
> <mailto:tortoisesvn_at_gmail.com>> wrote:
>
> Such buttons are ugly and never work properly for users who use
> non-default themes or use theming applications.
>
>
> You forgot to mention that it's functional...

If it breaks on a lot of systems, I would not call it functional at all.

> And how would users know about this? You know that users don't read the
> docs...
>
>
> That's what static text is for. Have text above the OK button that says
> "Shift+CLICK for auto-close settings"

We will soon end up with something like this:
http://www.codinghorror.com/blog/images/wgetgui-screenshot.png

> I have a hard time seeing the benefit of such extended auto-close
> behavior.
>
>
> Really? I thought I explained it quite well. What exactly are you having
> a hard time seeing?
>
>
> We already have fine grained auto-close behavior, admitted
> one setting for all operations.
>
>
> I've already established that it is NOT fine-grained. You give the user
> a very limited set of auto-close options. I've already found 2 or 3
> cases where I wanted certain auto-close behavior that TSVN did not support.

But why? Is it so hard/annoying to click the OK button after the
operation finished?
I think it's way more annoying to see an option (no matter how it's
implemented or what controls are used for it) in the progress dialog
that is only used once (if at all) by most users but visible for every
command.

> But what's the big gain here?
>
>
> Increase in usability and flexibility of TortoiseSVN. You seem to

That's sales-people talk. Buzz words, but they don't tell anything.

> pessimize this idea quite harshly. You have already acknowledged support
> for auto-close behavior, since you already have some limited support for
> it. However, with all do respect, it has been half-assed. I say that if
> you do not implement the feature properly (and in its most flexible
> form) you shouldn't have it implemented at all.

I'm against implementing something that doesn't add value to most people
but worsens the UI for all.
Flexibility is good, but it must be limited and weighted against usability.

> If you find that any ideas presented here you are unhappy with or
> foresee issues with, then by all means help contribute some thoughts.
> I'm sure you can come up with some great ideas.
>

Yes, I'm not happy with this. And you expect me to present ideas to make
it happen anyway??
I'm arguing against it, for reasons I've explained.

> There's a dialog staying open until you click OK, but that dialog
> contains important information. So for me that's not a big deal at all.
>
>
> But you do not determine what that important information is, the user
> does. Errors are the only thing we can assume are "important
> information". If you base auto-close behavior on important information,
> then you need to let the user define what falls into the "important
> information" category. Merges, for example, may be important information
> for some people (and thus they would not want the dialog to auto-close)
> but not for others. I need TortoiseSVN to be flexible to my needs. I
> don't want any features feeling like a burden. Let me tell TortoiseSVN
> when I want it to auto-close for each dialog in the most intuitive way
> possible.

Sure, it would be great if you could configure everything to your needs.
But every feature requires code and an UI to configure it. For many
people, there are already way too many options in the settings dialog.
Adding more doesn't help at all.

To keep the UI user friendly, we have to make it so that it works for
'best practices' and what's most common.
Having the same dialog auto-close for different operations does not fall
into that category. Also, having the dialog close automatically even if
there were errors is something I will not allow, sorry.

> If clutter is an issue for you, then simply add a static text as I
> mentioned earlier that says "Shift+Click to set auto-close options"
> above the "Close" button. In addition, add a special modal dialog that
> pops up when you SHIFT+CLICK that has a collection of check boxes in it
> that allow me to select the different types of information I do *not*
> consider important and thus will auto-close for.
>
> In the commit progress dialog, for example, I would uncheck everything.
> This would mean that unless an error occurs, I always want the commit
> dialog to close.
>
> If you do not mind a little bit of extra clutter, then we can do a
> little more than the static text and provide the check boxes right on
> the dialog itself. However, I like the SHIFT+CLICK idea the best.

If you can come up with a reasonable UI for the settings dialog, that's
fine. But adding that to the progress dialog is simply wrong.

Stefan

-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=1498737
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].

Received on 2009-03-31 21:08:12 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.