Changing the bindings for the attachment panes
Jim
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).
I'm toying around with creating an XBL binding that handles both of
these cases. Here are some of the benefits:
* Consistent UI (all attachments would look like [W] name.ext /1.2 KB/,
where [W] is the icon).
* Smooth scrolling in the composer attachment pane (listboxes don't let
you do this), good for getting drag-and-drop reordering of
attachments working.
* Better keyboard handling in the reader attachment pane (currently,
there's no keyboard accessibility whatsoever; there are probably half
a dozen bugs open about this and related issues).
* Clean up code; the attachment pane in the reader is a <description>
tag (with selectable="true"), which confused me to no end when I
first saw it.
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.'
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! :)).
- Jim
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning
Bryan Clark
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.
Focus and Selection
Jef Raskin is quoted as saying: "The system should treat all user input 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.
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.
Example message list view with 7 messages:
+--------------------+ | message 1 | | message 2 | | message 3 | | message 4 | | message 5 | | message 6 | | message 7 | +--------------------+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.
+--------------------+ | message 1 | |=message=2==========| |=message=3==========| | message 4 | |=message=5==========| | message 6 | |=message=7==========| +--------------------+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.
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.
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.
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.
Enter Checkboxes
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.
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.
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.
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.
Cheers,
~ Bryan
Jim
> 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.
That's my main concern: consistency. The proposed checkbox UI doesn't
appear anywhere else in Thunderbird (or on any major OS that I can
tell). The only place I can think of that does this is Gmail. In fact,
the only desktop app I know of that uses checkboxes in a list is
Lightning, and it uses them to mark completion of a task, so that could
be pretty confusing (of course, we could tell Lightning to change).
That said, I think using checkboxes would be beneficial as an option,
but I don't think we should force people to go against the grain of
their OS if they don't want to. One benefit of making an XBL binding for
both attachment panes is that if we added checkboxes, both of the panes
would be able to make use of them. Whether we add checkboxes now or
later probably doesn't matter, though it'll be easier to add them with
new bindings.
> 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.
The second case shouldn't cause problems unless the first case is true
as well, in which case you're already in trouble. (At least, that's how
it works in the XBL binding I'm proposing.)
One obvious issue is that if you click in the empty space of a list box,
it clears the selection, but I consider that a feature, since the only
other way to deselect everything is to click on an item and then
ctrl-click it again to clear it.
> Part of this problem can be handled with better display
> properties, when a selection is out of focus it could mostly disappear.
This is one problem I am fixing for the attachment pane: since it
currently doesn't allow focus at all, there's no visual difference
between an attachment you just clicked on, and one that's selected but
the focus is elsewhere (e.g the thread pane).
There's currently no functional difference between the two either, so
it's not so bad, but the difference between a blue box and a gray box
(colors may vary by theme, of course) should be at least as clear as an
enabled checkbox vs. a disabled checkbox.
Now that I've finished selfishly defending my favorite version ;), on to
the implementation. It sounds to me like the behavior of checkbox-mode
is just to invert the meaning of the ctrl key. (i.e. click defaults to
"add to selection" rather than "replace selection") and so on. Depending
on your interpretation, ctrl-click in checkbox-mode could act like click
does in regular-mode.
If this is the case, it would be pretty trivial to have both modes
supported in Thunderbird, since it really amounts to 1) taking the
complement of a single boolean, and 2) replacing the selection highlight
with a checkbox.
David Ascher
Faaborg's:
http://blog.mozilla.com/faaborg/2010/04/22/dont-talk-about-users/ and
http://www.uxmag.com/strategy/quantifying-usability
and the referenced
http://spreadsheets.google.com/pub?key=tJxF8zTuLdEj9pUcxnLAemA&output=html
which is implemented in bugzilla, and AFAIK has already proven useful in
helping Firefox UX thinking.
I particularly like the way Alex points out the inherent tensions
between these various principles. (in this case my guess would be
between ux-consistency, ux-error-prevention, ux-discovery, and others =).
--david
Jim
> 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).
I've filed a bug to do some more concrete stuff with this:
<https://bugzilla.mozilla.org/show_bug.cgi?id=630759>. It has a
XULRunner app attached with an in-progress version of the new bindings
for people to test out.