Stefan Küng wrote:
> On 10/4/05, Thomas Hruska <thruska@cubiclesoft.com> wrote:
>
>>Peter McNab wrote:
>>
>>>Stefan Küng wrote:
>>>
>>>
>>>>Now comes the really hard part: you actually have to look at the
>>>>commit dialog!
>>>>
>>>>7. Click on the combobox between the edit box where you entered the
>>>>log message before and the file list at the bottom.
>>>>8. See and be astonished!
>>>>
>>>
>>> 9 Not see and be admonished! :-)
>>>
>>>Seeing this comes up regularly, would it help if the last commit message
>>>was on display in the combobox when the commit dialog opened?
>>>
>>>Peter
>>
>>No. If a commit fails, TSVN should save the comment and automatically
>>load the dialog with the same comment when the user goes to commit
>>again. There is a minimum 90% probability they will do the same thing
>>again.
>
>
> Bad idea. If you remember, we had that once and many people
> complained. First, most of the time if you have to resolve a problem
> which made the commit fail, you have to commit some changes to fix
> this and *then* repeat the actual commit that failed. So you always
> have to remove the previous saved log message first for that
> intermediate commit.
Ah. Since that is the case (wasn't aware of that), then I agree: Bad idea.
>>_OR_
>>
>>Yes...and the user should have to push a button labeled something like
>>"Insert" to actually insert the text. Right now the combo box is
>>responding to an OnChange() event (or equivalent) and inserting the text
>>at the last known position...but that may not be where I wanted it to
>>go...so maybe there should be two buttons: "Copy to clipboard" (or just
>>"Copy") and "Insert" (or "Auto Insert"). I'd have to see the UI
>>positioning of the buttons to determine the exact wording.
>
>
> 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.
>>_OR_
>>
>>Both except the MRU is blank because the dialog is already loaded with
>>the last text used.
>>
>>
>>Also, the combo box is in the wrong position. Most users expect MRUs
>>like this one to appear above the text box the MRU refers to. Software
>>developers can handle shifts like that because we are used to awkward
>>environments, but I view TSVN as eventually being a tool used by the
>>average Microsoft Word document user to track their changes.
>
>
> 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.
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
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 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.
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%".
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.
3) "Commit to:" should be "Committing to:" and there should be a
read-only edit box immediately after it (instead of static text below).
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):"
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.
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).
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.
10) The tab order for the "Keep locks" checkbox should come before "OK".
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.
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.
14) Since multiple items can be selected in the "File-Extension-Text
Status-etc." list control, Ctrl-A should highlight everything.
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".
16) Right-click menu items in the "File-Extension-Text Status-etc."
list control should include shortcuts (only "Open" has a shortcut
currently).
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.
That's just one dialog and I'm sure I overlooked several issues.
--
Thomas Hruska
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Oct 5 10:18:21 2005