On 10/5/05, Thomas Hruska <thruska@cubiclesoft.com> wrote:
> > And what makes you think that people will notice the "Insert" button
> > more than the combobox? Also, if we provide a button, then you can be
> > *absolutely sure* that we'll get several mails a week asking to save
> > 'more than just the last log message'.
>
> No. I think you misunderstood me. You keep the combo box. Just add a
> button or two.
>
> > And did you really just suggest to add *two* buttons? Please have a
> > look at the commit dialog again, and then think about where to place
> > those buttons, and then imagine how the commit dialog would look like
> > with yet two more buttons. Why do you think I removed the button "pase
> > file names" and replaced it with an entry in the context menu of the
> > edit box?
>
> There is plenty of room for two buttons. Look at all that crazy amount
> of whitespace between "Log Message History:" and the left edge of the
> combo box. If you make one of the buttons a graphical representation of
> the clipboard (icon), change the text to "Message History:", and the
> other a standard-sized button, everything should both fit quite comfortably.
As I already mentioned: there's *no* room between the label and the
combobox. That room is needed for some translations.
> > Ok, can you please give me some examples at least? Where is the MRU
> > 'like this one' at the top of the edit box?
>
> Most MRUs are just one liners that show up in the same box. In this
> case, I'm not quite sure a combo box is even the right UI element to be
> using, but since you are using one, it makes sense that it should appear
> above the edit box because users move forward through dialogs - not
> backward...and moving up is considered to be backward.
I don't get it. Why upward/backwards? Don't you read from left to
right? And isn't the label left of the combobox?
> Your next question: What _IS_ the right UI element? Good question. To
> be honest, you need another dialog for there to be absolutely NO
> confusion about it. A "Message History..." button opens a modal dialog
> where the user can select from the summary items in a list box and see
> the full content in an edit box. Then they can click "Copy to
> Clipboard" (or tab past the button to the edit box and press Ctrl-C
> there) and then click "Close". It adds two clicks, but I'm sure someone
> will like the ability to select just a piece of a previous message. If
You add two clicks. You might think that's not a big deal. But people
tend to hate that. Why do you think keyboard shortcuts were invented?
And you don't need the ability to select "just a piece" of a previous
message: you can always edit the whole message in the commit dialog
and throw away what you don't want anymore.
> it is done right, the number keys on the keyboard could even be used to
> select a specific message number from the list box and then move the
> focus to the "Copy to Clipboard" button and then pressing the space bar
> could move the focus to the "Close" button (where pressing space bar
> again will close the dialog).
And that's *not* complicated? I think the current implementation is
*much* easier to find than what you're suggesting.
> > And did you really just compare TSVN with an 'awkward environment'??
>
> Yup. I did. I mean, it is a nice wrapper around an open source version
> control system, but it lacks professional finesse. That makes it fairly
> awkward.
Ok, define "professional" please. Because from what I know and learned
from "professional" products is that they might have nice colorful
UI's to impress the managers who decide what to buy, but they're
horrible to handle and sometimes even don't do the job they're
supposed to do.
So if that's what you want, I'm glad TSVN isn't "professional" at all.
> So while we are on the topic of the Commit dialog, let's address the
> "professional finesse" issue and changes that would make it far more
> professional _beyond_ those already addressed:
>
> 1) The title should be the same as the menu item. In this case, it
> should probably be spelled out "Tortoise SVN Commit - %Directory%".
We can change that.
> 2) The initial size of the dialog (first time ever displayed) should be
> large enough to show as many data elements as the screen resolution allows.
Definitely not. I really hate programs which think they can take up
the whole screen. And websites which automatically resize the browser
window to full screen immediately get on my blocked list or added to
my little script which modifies websites on the fly.
The initial size of every dialog/program should be as big as
necessary. That means the size should be so that everything that's
important is visible, but not more.
And besides: the size of the dialog is saved, so when you next start
it, you'll have the size you wanted before.
> 3) "Commit to:" should be "Committing to:" and there should be a
> read-only edit box immediately after it (instead of static text below).
I my knowledge of the english language isn't completely messed up,
then "committing" means that the commit is actually in progress at
this very moment.
And the URL you're committing to already *is* a read-only edit box and
not a static label.
> 4) Add static text labeled "Message:" immediately above the main edit box.
> 5) Eliminate the "To see the changes you've made, double click..."
> static text and immediately above the "File-Extension-Text Status-etc."
> list control add the static text "Changes made (double-click for details):"
Finally some good ideas.
> 6) Eliminate the underscore on the "Cancel" button - the ESC key works
> fine.
> 7) Eliminate the underscore on the "Help" button - the F1 key works fine.
So close! You ruined it again.
Search the mailing list. Then you'll find a lot of people who *insist*
that keyboard shortcuts must be available for all buttons. And even
fewer people know that ESC and F1 do the same as Cancel and Help
buttons than people know about the log message history combo.
> 8) Set each static text and checkbox to have an underscore
> (alt-shortcut) associated with it (make sure the tab order is correct
> such that static text comes before each primary UI element).
Why here but not on the buttons?
> 9) The choices for text case is inconsistent throughout the dialog.
> For instance, "Log Message History" vs. "Show unversioned files". Or,
> to make a better point, "Log Message History" vs. "Log message history".
> Case should be consistent not only in this dialog but throughout the
> application as a whole.
Good point. Patches are welcome.
> 10) The tab order for the "Keep locks" checkbox should come before "OK".
I think that's already fixed (I'll check this evening).
> 11) The "File-Extension-Text Status-etc." list control should select
> the first item by default. Tabbing into the dialog causes the focus
> rectangle to be "lost" until an arrow key is pressed.
That's consistent with e.g. the windows explorer.
> 12) Tri-state checkboxes are unusual beasts and their meaning is
> difficult for users to comprehend when in the "Grey" state. The
> checkbox looks partially disabled. It would be better to use two
> buttons: "Select All" and "Deselect All" and move them (ideally) to the
> right of the "File-Extension-Text Status-etc." list control. However,
> there really isn't room for that. I guess a tri-state checkbox is an
> "okay" compromise, but if it can be done differently, that would be good.
> 13) BUG: Select the first item in the "File-Extension-Text
> Status-etc." list control. Use Shift+Arrow Down to highlight a bunch of
> elements (more than two). Press space bar to select them. Press space
> bar again to deselect them. The number of files selected will be
> negative. Might want to fix that. Deselecting everything and then
> using the mouse to select a single item causes "2 files selected".
> Probably related.
That's fixed.
> 14) Since multiple items can be selected in the "File-Extension-Text
> Status-etc." list control, Ctrl-A should highlight everything.
Good point.
> 15) The right-click menu for all items in the "File-Extension-Text
> Status-etc." list control should include "Select", "Deselect", "Select
> All", and "Deselect All".
I think the context menu already has enough entries. Adding entries
which aren't really necessary is a real waste.
> 16) Right-click menu items in the "File-Extension-Text Status-etc."
> list control should include shortcuts (only "Open" has a shortcut
> currently).
Can be done.
> 17) BUG: Opening the help file (not just for this dialog) causes it to
> stay on top. That is, if the help file overlaps the dialog, clicking
> the dialog will give it focus, but the z-order doesn't change. If the
> dialog has no owner window, that might have something to with it.
Help dialogs staying on top is the windows default.
I think I'll stop for now, before I go completely nuts...
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Oct 5 11:04:17 2005