Stefan Küng wrote:
> 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?
I wasn't talking about the label to the left of the combobox. I'm
talking about workflow. You have to move _down_ to the combobox and
then back _up_ to the edit box. That's backwards. Users should move
naturally forward through every dialog. This means the combobox should
come first, THEN the main edit box.
>>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.
I already know that adding clicks *is* a bad idea for any user
interface, but confused users are worse. And with the edit box first,
I'm likely to type some stuff, perhaps move the cursor, then realize
there is that combobox, select something, and that inserts the saved
text into the middle of a sentence. Depending on how long the saved
text is, it could be a real hassle to straighten everything out. If it
is put on the clipboard, then I've got a chance to do something about
it, but then again changing a UI element and having nothing _apparent_
happen is only going to confuse users more. That's why I said the
correct solution is another dialog...I don't like it any more than you
do, but it really depends on how confused users get. There are probably
thousands of people using notepad because they don't realize what the
combo box is for because it is not _intuitive_. Sure it has a text
label, but the static text label is too long AND it doesn't come before
the edit box, so users ignore it because they think it has to do with
the next UI element. Even if it comes before, the combo box is _still_
not intuitive as to its operation in relation to the edit box, so it
won't help any without help. Perhaps a group box would help? Labeling
that is tricky. Just calling the group "Log" might be sufficient.
People will then see that the combo box AND the edit box are related
somehow.
>>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.
Look, you've got a UI element that exhibits non-standard behavior. I've
never done well with figuring out what to do with non-standard UI
elements. What I was putting forth was a possible "standard" solution
to the problem with a couple shortcuts to speed up the process to a "one
click plus one hand pressing a couple keys" solution. You've shortcut
the effort by removing the dialog. However, by doing so, it creates
obvious user confusion. A number of people came out of the woodwork on
this list on this issue - think about the thousands who AREN'T on the
list and doing the same thing.
>>>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.
Colorful UIs have nothing to do with professional products. Well, it is
_ideal_ to follow the XP icon style and themes, but that is only barely
scratching the surface. The product should do the job too. Beyond
that, though, is usability testing (literally sitting down with people
who have never used the product [but think it is something they might
use] and _silently_ watch them use the software), user interface design
(my nitpickiness that's driving you crazy), user acceptance testing
(purposely seeking out target markets and beta testing with a number of
users from each market), and responding to user feedback with product
updates. When you get past just "getting the job done" and start
focusing on the latter stuff, then and ONLY then do you have the _start_
of a professional product. There are a ton of products out there that
claim to be professional but really aren't. I've even written some of
them (sad but true).
>>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:
>>
>
>>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.
I didn't say full screen. I said large enough to show as many data
elements as the screen resolution allows. So, for a 640x480 monitor
(yeah right - who has that?) the dialog will probably _shrink_ from a
default size. For larger resolutions, the main list control is what
defines the initial size (so that all elements can be seen).
> And the URL you're committing to already *is* a read-only edit box and
> not a static label.
Really? I can't put the focus on it. It doesn't look like an edit box.
If I can't put keyboard focus on it and it should be readable by a
screen reader (e.g. JAWS), it violates 508 Compliance. Things like that
mean the U.S. government and related organizations can't legally use
TSVN...and I can't copy and paste it if I wanted to (for whatever
bizarre reason - maybe documentation).
>>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?
Microsoft has laid out specific design specifications for dialogs,
menus, and other aspects of applications (don't ask me for links - the
pages are scattered all over MSDN and I've just committed the content to
memory because they are a pain to find). These are considered
"standards" for designing and deploying Windows applications. The only
reason I didn't specify that the "OK" button should have its underscore
removed is because the edit box is set to "Want Return".
Associating all static text with an alt-shortcut is required by 508
Compliance. Microsoft recommends, among other reasons, for 508
Compliance that the OK, Cancel, and Help buttons be left without
underscores to make it possible to use those shortcuts elsewhere.
In case you don't know what 508 is, it is the U.S. Disability Act. It
provides very specific guidelines for disabled persons (e.g. partially
or fully blind persons) to navigate software packages. Typically 508
compliant software has an accompanying statement that states what is
compliant and what isn't and what efforts are being made to strive
toward 508. The U.S. Federal government is required by law to have all
software they use be 508 Compliant or they can end up in deep legal trouble.
If you can figure out how to put shortcuts on every button AND static
text element for every primary UI element for every dialog, then kudos.
Though I would start with the most complex dialog to make sure it is
even a feasible possibility.
Now I know you probably don't like Microsoft for any number of reasons,
but if you develop software for their platform and they have a standard
defined for how to make dialogs and people expect dialogs to look
basically the same across the board, then it is best to not confuse
users with even a few stray underscores. I know several people I would
love to introduce TSVN to and they would use it, but I know these people
- they are easily confused by strange user interfaces. The more
familiar the interface is, the more likely they will have success using
it when I introduce it to them for the first time.
--
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 13:05:30 2005