Simon, thanks for taking the time to reply.
Simon Large wrote:
> Molle Bestefich wrote:
> > Stefan, thanks a lot for listening to all the bicker and trying to
> > improve something that obviously a bunch of newbies are having
> > problems with. I still think there's room for improvement however,
> > here's a bit of analysis and some concrete suggestions:
> >
> > * Poster never requested the combo box be turned into a button control.
> > He asked for it to go away completely and be replaced by an
> > 'abort/retry' dialog.
> > (Let's not do that :-).)
>
> You evidently haven't read the whole thread as you seem to be quoting
> only one poster.
The _original poster_, eg. the one who had the problem. Yes?
And why the cruel tone?
You know very well that I've read the entire archive of this thread.
> An alternative to the combo box was requested by Thomas Hruska.
So it seems.
It slipped under my radar.
Here's Thomas's suggestion (the part of it that wasn't rejected on
good grounds):
THruska> Yes...and the user should have to push a button labeled something like
THruska> "Insert" to actually insert the text. Right now the combo box is
THruska> responding to an OnChange() event (or equivalent) and
inserting the text
THruska> at the last known position...but that may not be where I wanted it to
THruska> go...so maybe there should be two buttons: "Copy to
clipboard" (or just
THruska> "Copy") and "Insert" (or "Auto Insert"). I'd have to see the UI
THruska> positioning of the buttons to determine the exact wording.
Basically Thomas is complaining that the text is inserted in the edit
box, and he might not have expected it to do that.
While Thomas's rhetorics are impervious, his point seems moot:
* the user can simply use CTRL-Z to undo the insertion (now there's a
standard for you).
* it only takes 2 clicks on the combo for the user to learn what it
does, so this is a one-time worry.
* inserting text doesn't ruin the old text - even if the user is
ignorant of standard CTRL-Z, he can just mark and delete the inserted
text.
Thomas also pointed out that the behaviour is non-standard according
to Microsoft.
I don't buy that as a good argument to changing good behaviour, but
you should feel free to do that if you wish :-).
If you *really* think that's a good reason to change good behaviour,
then a button is the way to go. That said, the change to a button has
made things worse (for now), not better. So if it is to be kept, it
definitely needs improvements from it's current state to work just
half as good as the combo box did.
> > * I'm a bit annoyed by having to click one more time now than before
> > (it all adds up...), and
>
> Click on combo, click on entry = 2 clicks
> Click on history, double-click on entry. Does a double click count as an
> extra click?
Yes, a double click counts as two clicks.
> Anyway, how often do you really need to use the history in a day? Do you
> really get that many problems committing?
I use it about 4-5 times a day.
Only a couple of times a week is it actually a commit that failed.
Most of the time I either simply do operations that the SVN WC model
does not support in an atomic commit (thus circa the same message to
both commits), or do repetetive operations against multiple projects
(where the commit messages are similar).
> > * The button opens a popup. The contents of the popup dialog flies
> > into the original dialog. The popup dialog's only purpose in life is to
> > contain a small list. My feeling is that this is not particularly good
> > GUI-wise,
>
> Why not?
Dialogs that popup and then disappear again are confusing.
If it has so little purpose that a combo box can do it's job, IMHO a
combo box should do it's job.
(If you stick to wanting a button because of 508 or MS standards, the
button should at least invoke a popup menu, not an entire dialog.)
> Actually, the original request included an additional edit box
> which would display the complete message (the list box only shows the
> start). That is still possible in future with a separate dialog.
The current design doesn't, which is what I'm referring to.
> > * A combo box control is more suited for the job...
>
> There were lots of arguments on that thread. The one against combo boxes
> is that its behaviour is non-standard/non-intuitive.
The complaint was of an extremely technical and hypothetic nature.
I've never seen a real user actually complain about this. Evidently,
from a user's POV it does not matter much that fx. Stefan chose to use
OnChange() to paste text instead of a "paste" button as MS standards
would have him.
> > * A good associated text should be fx. "Recently written" or "Recent
> > messages" or "Recent entries" (I prefer "recently written").
>
> That would have helped the combo box and could still help with the button.
Agreed...
> > * It seems to me that standardized GUIs would layout the control on
> > the right-hand, not the left-hand side.
>
> Curious. It was originally on the right and someone complained that a
> standardized GUI would put it on the left.
I think I've actually *never* seen dropdowns occur on the left-hand
side of their associated controls. Who said that?
> > Also, super-minor point:
> >
> > * I liked it better when the last message was per default displayed
> > in the combo.
> > That helped a bit to make it clear what the control does.
>
> It's not super-minor because people are still not finding either the
> button or the combo.
Agreed. It was a good suggestion.
> So, some suggestions:
>
> Let's assume first of all that the button is here to stay.
Why?
* It degrades the user experience.
* The proposal leading to it's implementation was, while rhetorically
perfect, completely irrelevant from a user's point of view.
> 1. History is perhaps not a good title because it means something
> completely different in CVS, and to some people it suggests
> already-committed messages.
Seeing as you're repeating one of my points, I agree completely :-).
> 2. Use a tooltip for the recent-messages button which says something
> like "Click here to select a recently typed message." and also displays
> the most recent message.
That could be a nice touch.
> 3. We could possibly make it even more obvious if the last commit failed
> or was cancelled, but that would require saving the success/failure of
> the previous commit in the registry, and would probably just be an
> annoyance for regular users.
If the text was visible per default (as I suggested), it *could* be
made red whenever the last commit failed. IMHO this is
over-engineering things.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Nov 15 14:54:44 2005