<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 11-01-18 1:09 PM, Jim wrote:
<blockquote cite="mid:4D360199.2010900@gmail.com" type="cite">Lately,
I've been working on patches related to attachment display in
Thunderbird. One thing I've noticed is the similarity of the
attachment pane in the composer and the reader (the main
difference is that the former is vertically-oriented, and the
latter is horizontally-oriented).
<br>
<br>
I'm toying around with creating an XBL binding that handles both
of these cases. Here are some of the benefits:
<br>
<br>
* Consistent UI (all attachments would look like [W] name.ext /1.2
KB/,
<br>
where [W] is the icon).
<br>
* Smooth scrolling in the composer attachment pane (listboxes
don't let
<br>
you do this), good for getting drag-and-drop reordering of
<br>
attachments working.
<br>
* Better keyboard handling in the reader attachment pane
(currently,
<br>
there's no keyboard accessibility whatsoever; there are probably
half
<br>
a dozen bugs open about this and related issues).
<br>
* Clean up code; the attachment pane in the reader is a
<description>
<br>
tag (with selectable="true"), which confused me to no end when I
<br>
first saw it.
<br>
<br>
I'm posting this here before filing a bug on this, since I know
there were plans to diverge the two attachment panes further
(adding checkboxes and such to the reader), so I wanted to get a
feel for what others thought of this. For what it's worth, I think
diverging the two panes is a bad idea, since the two panes do
roughly the same thing, except that you're (more) able to edit
attachments in the composer.'
<br>
<br>
I also know there were some concerns about keyboard/focus issues
in the reader attachment pane, but I'm confident that those can be
resolved (assuming people let me know what the specific issues
are! :)).
<br>
</blockquote>
<br>
Awesome! I think this could be a good thing. While in general I
want to move away from the keyboard/focus pieces it is how
Thunderbird has worked for a long time (and in most areas) so
sometimes despite new best practices you have to continue using the
old practices to be more consistent.<br>
<br>
The checkboxes and focus issues are very similar so I'll try to
cover them both at the same time just to make this more known.<br>
<br>
<b>Focus and Selection</b> <br>
<br>
Jef Raskin is quoted as saying: "The system should treat all <em>user
input</em> as sacred." This kind of usability principle is why we
try to protect the information users input with systems like
auto-save keeping data safe and undo to retrieve it when it's lost.<br>
<br>
Selection in tree views doesn't respect this idea of treating user
input as sacred because it constantly and easily throws away
information with a single missed click. An example is a list of
items you wish to delete like messages in our message (thread) list
view.<br>
<br>
Example message list view with 7 messages:<br>
<pre>+--------------------+
| message 1 |
| message 2 |
| message 3 |
| message 4 |
| message 5 |
| message 6 |
| message 7 |
+--------------------+
</pre>
Lets assume our user wants to delete message 2,3,5, and 7. So they
hold the control/cmd button and begin selecting those messages.<br>
<pre>+--------------------+
| message 1 |
|=message=2==========|
|=message=3==========|
| message 4 |
|=message=5==========|
| message 6 |
|=message=7==========|
+--------------------+</pre>
Now they are all selected but if this user at any time stopped
holding the control/cmd button during selection or clicks
accidentally in another area they can lose that entire selection of
messages. User input is gone and there is no way to get that back.<br>
<br>
I'm sure people on this list have done this before where you've
selected a number of things and then happen to miss click somewhere
and then had to reselect everything all over again. Likely on the
second pass you selected a smaller set of items because you didn't
want to risk losing that big selection list again. <br>
<br>
Another common issue with this is now related to focus. Selecting
these messages means that focus is in this list area. However if
the user miss clicks into the Folder Pane area on a new folder or
even the same folder focus changes. If they selected the same
folder then focus goes away from the list and is now on the folder.
Pressing the delete key while focus is on the folder should delete
that folder, even though the message list still shows a selection of
messages. Most users continue to think that because the selection
is still held that a delete action will be performed on the
selection even though it doesn't have focus.<br>
<br>
We have this problem with the folder pane and message list and then
again with the message view and attachment list. Focus means that
users can see something selected (though out of focus) and expect
that a command is executed on the selected items when in fact it is
executed on the focused item instead. Part of this problem can be
handled with better display properties, when a selection is out of
focus it could mostly disappear. <br>
<br>
<b>Enter Checkboxes</b><br>
<br>
The immediate solution that most design or usability professionals
have moved to is to use checkboxes instead of selection because
checkboxes maintain their state despite missed clicks. In the
example above a missed click wouldn't have changed the selection
state from 4 to 1, instead it would remain exactly the same as it
was. <br>
<br>
Another benefit is that checkboxes don't require holding key
combinations down to do multiple selection and thus are easier for
most users to take advantage of; compared to selection which
requires shift and control keys to use effectively.<br>
<br>
When replacing selection with checkboxes you still have the problem
of focus leaving and global keyboard actions affecting other areas.
Systems using checkboxes often show the checkboxes disabled when
focus leaves to indicate that the selection is no longer valid. As
well as placing the action options close to the checkbox options
which are often needed to make checkboxes as effective as selection.<br>
<br>
Now before you jump on this thread with sounds of how checkboxes
cannot possibly replace selection, yes there are differences, and
there are well known things we can do to fix that such that they can
be replaced. e.g. shift clicking with most decent checkbox
implementation works just like in selection systems.<br>
<br>
Cheers,<br>
~ Bryan<br>
</body>
</html>