436555 - attachment presentation in received messages needs improvement

Status: RESOLVED DUPLICATE of bug 663765

(Thunderbird :: Message Reader UI, defect, P2)

Description

[Dan Mosedale (:dmosedale, :dmose)]

This is a somewhat more general Thunderbird version of bug 101891.  The core problem here is that the attachments presentation in received messages has issues:

* the names presented are often useless ("Part 1.2")
* no visual cues are given (type of file, size, ...) w.r.t. what the experience of clicking that is going to be like
* there's no distinction made between attachments that are already displayed inline in the message and those that aren't (note that we may want to do different things for attachments came with Content-Disposition: inline vs attachments that were forcibly displayed inline because of a pref setting).
* do we even want to show stuff that's already inline here?  this is especially weird for mailing lists that auto-attach signatures.

Marking as blocking thunderbird3, as this feels like relatively low-hanging UX fruit.

Comment 1

[Magnus Melin [:mkmelin]]

Ah yes the "Part 1.2" ones sure are annoying! It's used when the attachment is unnamed, I think. I doubt anyone would miss them from the attachments pane... A lot of text and html attachments come in inline (xref bug 65794) so I wouldn't hide named attachments, even if some mailing lists use something like "footer.txt".

Comment 2

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
There are at least three "multipart" structures usually used, mixed, alternative, related. Any multipart/xxx can contain any multipart/yyy parts including same subtype of xxx, and nest level is logically unlimited.
When alternative, multiple mail bodies are contained in it(a part of text/html body, and a part of text/plain body).
When related, a mail body consists of multiple parts(e.g. a text/html part + image/jpeg parts for <img> in HTML).
When digital signature is used, multipart/mixed is used, in addition to file attachement.
Further, a part can be Content-Type:message/rfc822(forwarded mail as attachment) which is also a mail, and nest level is logically unlimited too. 

To Dan Mosedale(bug opener):  
What is your definition of "attachment" of a mail?
Can it be defined by mail header only?
(Similar issue is involved in "Body" of "Body Search" of mail of multipart)

Comment 3

[WADA:World Anti-bad-Duping Agency]

Another question.
Following structure/hedears is possible(not prohibited by RFC).
 Content-Type:multipart/mixed;
  part-1 : Content-Type:text/plain; Content-Disposition: attachment
  part-2 : Content-Type:text/plain; Content-Disposition: inline
  part-3 : Content-Type:text/plain; Content-Disposition: attachment
  part-4 : Content-Type:text/plain; Content-Disposition: inline
Which is mail body? Which is attachment? 

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Wada,  
Dan explained in comment 0 that this bug requests for Thunderbird what 
bug 101891 requests for the mail/news client in SeaMonkey.  
I reported bug 101891 in June of 2007, 7 years ago.
I suggest you read that bug for background.

For the purposes of that RFE, an "attachment" is any part of a multipart 
mail that shows up in the mail/news client's "attachments" pane, which 
(in SeaMonkey) is inside the Message Header pane.  It is any part of the 
message that is not shown in the message body pane, but is available for
the user to "save" or "open".

If the mail/news client tells the user "here is an attachment", then it 
should provide a way for the user to see information about that attachment
without opening it, information such as MIME content type, length, and 
perhaps what program will be used to "open" it.

Comment 5

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #4)
> an "attachment" is any part of a multipart mail that shows up in the mail/news client's "attachments" pane,
>(snip)
> It is any part of the message that is not shown in the message body pane,
> but is available for the user to "save" or "open".

I see.
I misunderstood that improvement in presentation of nested message/rfc822 parts which have attachments(your definition), hierarchical display of attached/nested mail and attached files to it at both View/Inline and View/not-Inline, is also involved.
Sorry for my over expectation.

Comment 6

[David :Bienvenu]

no one is working on this, afaik, so off to b2.

Comment 7

[Bryan Clark (DevTools PM) [:clarkbw]]

I'm going to push this off further to rc1.  I think what this bug needs is some more specifics on what should be done and how long it might take.  It is a bit too vague in requirements... that could be my fault as it does have uiwanted.

(In reply to comment #0)
> * the names presented are often useless ("Part 1.2")

This just needs some kind of test cases to determine what is showing up as this type so we can understand what to do with them otherwise I don't understand how we can make the decisions.

> * no visual cues are given (type of file, size, ...) w.r.t. what the experience of clicking that is going to be like

In talking to bienvenu we already know the file type, but not the size until we save the attachment.  The file type is only expressed in the file icon.  I would think a nice way forward here would be to express the file type in real human terms.  Picture (jpg) or Picture (png) or Document (doc) or Document (rtf) instead of just taking the image/jpg mime type and showing that.

> * there's no distinction made between attachments that are already displayed
> inline in the message and those that aren't (note that we may want to do
> different things for attachments came with Content-Disposition: inline vs
> attachments that were forcibly displayed inline because of a pref setting).

I'm not sure how to do this in the existing attachment area however I think we want to offer the line attachments as a secondary option.  Inline attachments should likely have context menus inside the message.   But the attachments area should also have a secondary option for "Show Inline Attachments" which just adds the inline attachments to the other attachments.  We'll need to figure something out when there is no attachments area.

> * do we even want to show stuff that's already inline here?  this is especially weird for mailing lists that auto-attach signatures.

It would be great to be able to detect these and ignore them.  Perhaps if (mailinglist && last inline text attachment); not really sure what the right test is but I don't think anybody actually desires to save this attachment (and that is pretty much our real goal)

-----

So if we can get some ideas about how much time the work on the various pieces would take then I think we could file them off into separate bugs that block the b2 release.

Comment 8

[David Ascher (:davida)]

assigning to dmose for later processing

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

After discussion with clarkbw, we think that while this would be awfully nice to have, we wouldn't block Tb3 if this were the last bug.

Comment 10

[David Ascher (:davida)]

Attachment: WIP

This has been bugging me for a while, so I took a stab.  The attached works pretty well for me (mac theme only).

The main design goals were:

 - more discoverability -- figuring out what to do w/ attachments in the current UI requires a lot of guesswork, due to the use of context menus, subtle selection colors, and little feedback.

 - cleaner -- the current UI has weird styling choices IMO.

The priorities for use cases were picked as follows, w/ the most common at the top (therefore addressed w/ few clicks)

  - open single attachments
  - save single attachments
  - save all attachments
  - save some attachments
  - drag attachment to desktop/filesystem
  - detach & delete operations on single, all, or some attachments.

I used checkboxes as the selection mechanism, rather than the 'listbox' model which was used before, which I think is easier to figure out.  The keyboard selection is unchanged.

[note: no accessibility changes have been made, that's another bug]

The layout does mean that the large views are taller.  At this point I prefer the non-large view, and would suggest changing the value of the default for mailnews.attachments.display.largeView.  

I'll attach a screenshot of said narrower view.

Before doing any gnomestripe/qute work on this, I'd like to get a review to see what I've missed.

Comment 11

[David Ascher (:davida)]

Attachment: Screenshot 1 (mac) with dropdown buttons for each attachment

Comment 12

[David Ascher (:davida)]

Note that I don't address all of the points in comment #0.  This is primarily a style/UI change, not a change of what is displayed.

Comment 13

[David Ascher (:davida)]

Another thought I had is that w/ this code it becomes fairly easy to have a new pref which would hide attachments from the bottom pane that are displayed inline, and let people show them in the attachment pane on demand (and we could have a pref to maintain the current behavior).  Anything that results in that pane being smaller and less redundant w/o loss of usability would be worth considering, IMO.

Comment 14

[David :Bienvenu]

I think that could avoid some confusion, but has to be balanced with the ease of manipulating the attachments (e.g., save as, or open separately). I'm not sure how we'd do that with .txt attachments, for example.

Comment 15

[Nomis101]

(In reply to comment #10)
> Created an attachment (id=363273) [details]
> WIP

I've tried this, but I get:
RuntimeError: file not found: mail/attachment-background.png

Comment 16

[David Ascher (:davida)]

Attachment: patch w/ missing file

Nomis101: Sorry about that.  Try this version.

Comment 17

[Simon Bünzli]

Why not move the image inside the button to make it even a bigger click target and make it more obvious where to click for opening the attachment (my intuition would have been to double-click the icon)? Things would also look slightly tighter (only two rows: checkbox and button).

Also: Save and Delete should be separated by a <menuseparator> so that a slight mis-click won't be destructive (or annoying, when there's a prompt).

Comment 18

[David Ascher (:davida)]

Thanks for the feedback!

(In reply to comment #17)
> Why not move the image inside the button to make it even a bigger click target
> and make it more obvious where to click for opening the attachment (my
> intuition would have been to double-click the icon)? Things would also look
> slightly tighter (only two rows: checkbox and button).

Interesting idea.  I'm a bit concerned that clicking on the checkbox, if missed, would open the attachment, which can take a while depending on the setup.  I may play w/ that.

> Also: Save and Delete should be separated by a <menuseparator> so that a slight
> mis-click won't be destructive (or annoying, when there's a prompt).

Hmm.  In general, if we can't expect people to hit the menu item, we'd need separators everywhere.  The warning dialog is there to avoid destructive behavior, so I'm not super worried.  In my mind menu separators are mostly there to help group bunches of menuitems together in long menus, not to avoid mis-clicks.

Comment 19

[Simon Bünzli]

(In reply to comment #18)
> clicking on the checkbox, if missed, would open the attachment

So people are supposed to always hit the menuitems, but occasionally miss a checkbox? ;-) I wouldn't be too worried since you already seem to be using generous spacing around the checkboxes.

> separators are mostly there to help group bunches of menuitems together

Then, please group the non-destructive and destructive options...

Comment 20

[David Ascher (:davida)]

(In reply to comment #19)
> (In reply to comment #18)
> > clicking on the checkbox, if missed, would open the attachment
> 
> So people are supposed to always hit the menuitems, but occasionally miss a
> checkbox? ;-) I wouldn't be too worried since you already seem to be using
> generous spacing around the checkboxes.

Fair enough!  The checkboxes I used are particularly small, so they _feel_ harder to hit than the menu items.  But the point is valid.

Spacing around the checkboxes would seem problematic if they were inside a button -- would that area around the checkbox be a dead space?  
> 
> > separators are mostly there to help group bunches of menuitems together
> 
> Then, please group the non-destructive and destructive options...

Good point.

Comment 21

[Simon Bünzli]

(In reply to comment #20)
> Spacing around the checkboxes would seem problematic if they were inside a
> button -- would that area around the checkbox be a dead space?

Actually, I didn't mean for the checkbox to be inside the button, only the attachment's file type icon which I quite strongly associate with the file name (as they're inseparable in every view of the OSes file explorer, Open/Save dialogs, etc.).

As for the checkbox, I'd use some padding around it so that it extends invisibly (almost) up to the button, leaving hardly any dead space in between them while still making the user point to the checkbox itself (thus a slight mis-click "outside" the checkbox would still activate it). You're currently using a 2px border instead...

Comment 22

[David Ascher (:davida)]

(In reply to comment #21)
> (In reply to comment #20)
> > Spacing around the checkboxes would seem problematic if they were inside a
> > button -- would that area around the checkbox be a dead space?
> 
> Actually, I didn't mean for the checkbox to be inside the button, only the
> attachment's file type icon which I quite strongly associate with the file name
> (as they're inseparable in every view of the OSes file explorer, Open/Save
> dialogs, etc.).


Ah, I see.  I wanted to do that too, but didn't because it's the thing you can drag & drop to the desktop.  Putting the draggable thing inside the button, or dragging the button don't feel right somehow.

> As for the checkbox, I'd use some padding around it so that it extends
> invisibly (almost) up to the button, leaving hardly any dead space in between
> them while still making the user point to the checkbox itself (thus a slight
> mis-click "outside" the checkbox would still activate it). You're currently
> using a 2px border instead...

Giving a larger click area for the checkbox is a good idea, I'll try that.

Comment 23

[Simon Bünzli]

(In reply to comment #22)
> Putting the draggable thing inside the button, or
> dragging the button don't feel right somehow.

FWIW: Firefox's site button behaves that way and it feels OK - if you ever manage to discover drag'n'droppability in the first place (head over e.g. to https://www.paypal.com/ to try it out). Anyway, thanks for listening!

Comment 24

[David Ascher (:davida)]

(In reply to comment #23)

> FWIW: Firefox's site button behaves that way and it feels OK - if you ever
> manage to discover drag'n'droppability in the first place (head over e.g. to
> https://www.paypal.com/ to try it out). Anyway, thanks for listening!

That's a really good point, thanks!

Comment 25

[David Ascher (:davida)]

Comment on attachment 363494 [details] [diff] [review]
patch w/ missing file

philor, if you could give this a once-over, then I can figure out what's needed to do the qute/gnomestripe work.

Comment 26

[Phil Ringnalda (:philor)]

Comment on attachment 363494 [details] [diff] [review]
patch w/ missing file

Conceptually, I like it. Practically, not quite yet. That defaults to a few px of useless scrolling of whitespace, which maybe you aren't seeing from having persisted a non-default height for attachmentView, a persisted height that you probably want to blow away for everyone by changing the container's id. Then there's the way that regresses allowing re-detaching and re-deleting of detached and deleted attachments: it's sort of cute the way it saves a deleted foo.jpg as Deleted-foo.jpg, but not nearly as cute as not offering to do things we can't do would be.

Comment 27

[David Ascher (:davida)]

Note to self: get rid of context menu in attachment pane, and figure out how to make the menus in the buttons pick up on deleted/detached attachments (and remove those items from the lists).

Note to philor: by renaming the container, do you mean renaming 
messagepanebox' or 'attachmentView'?  Is there no way to blow away the persistence of the splitter location w/o blowing away the height of the containing vbox?

Comment 28

[Phil Ringnalda (:philor)]

Looks like I must have meant "I'm high as a kite, and I clearly have no idea why your screenshot shows no useless scrollbar just scrolling whitespace, but I get one."

Splitter location can't be directly persisted or blown away, because you can only persist attributes - you can persist the open/collapsed "state", but to persist position you have to either persist the width on both sides, or the width on one side and let flex take care of the other. However, that totally wouldn't work here (we'd persist a height of 0 for the attachmentView, or of allofit for the browser, if you quit while displaying a message without attachments), so the difference must have been something else, like maybe we have different values for mailnews.attachments.display.largeView.

Comment 29

[Thomas D. (:thomas8)]

(In reply to attachment 363274 [details] and comment #16)

With all due respect, I'd like to express my doubts if the UI as suggested in the screenshot of attachment 363274 [details] can be considered an improvement over current "listbox style" attachment pane with file icons. Whereas in current UI, attachments actually look like "file objects", my feeling is that the new UI looks cluttered, looks and feels like webmail (if I wanted webmail, why use Thunderbird??), and is less intuitive and to some extent /less/ functional than before. Attachments buttons just don't even look like files, as even David A. himself is aware of (comment #22: "Putting the draggable thing inside the button, or dragging the button don't feel right somehow."). I can see the good intentions, and the new UI certainly looks more sophisticated (i. e. more complex) than just "normal" file objects (icons + file name), but why reinvent the wheel?

Apart from that, I don't think the new UI actually keeps all its promises in terms of the declared design goals as laid out in comment #16:

>  - more discoverability -- figuring out what to do w/ attachments in the
> current UI requires a lot of guesswork, due to the use of context menus, 
> subtle selection colors, and little feedback.

What I see in the old UI is a file object icon for each attachment that looks like any other file object in my OS (Win XP). Double click opens a file; for any other action, right-click for context menu commands. Standard procedure, we do that a thousand times a day. Where's the guesswork?
When I select more than one attachment, the background of selected attachments is solid dark-blue - not exactly a "subtle selection color"?

>  - cleaner -- the current UI has weird styling choices IMO.

Cleaner? Not sure. In the old UI, I see ONE file object per attachment (a file icon with its file name). In the proposed new UI, I see a tidy, but confusing clutter of as many as 3 1/2 different UI elements per attachment: a checkbox, an icon, a button, and a dropdown part of the button.
 
> The priorities for use cases were picked as follows, w/ the most common at the
> top (therefore addressed w/ few clicks)

Fewer clicks? Hmm, maybe yes, maybe no. Let's see:

- open single attachments (old UI: double click | new UI: single click; old UI could be modified to optionally allow single click opening of attachments like in windows explorer)
- save single attachments (old UI: 2 clicks | new UI: 2 clicks)
- save all attachments (old UI: 2 clicks | new UI: 1 click; old UI could be modified to have 1-click-button, as well)
- save some attachments (old UI: 1 extra click to get the context menu)
- drag attachment to desktop/filesystem (no difference)
- detach & delete operations on single, all, or some attachments (3 clicks for both old and new UI)

> I used checkboxes as the selection mechanism, rather than the 'listbox' model
> which was used before, which I think is easier to figure out.  The keyboard
> selection is unchanged.

Just that we don't get that original feeling of selecting file objects, and we don't think of using practial shortcuts like ctrl+a any more as they usually don't work on checkboxes. Does ctrl- and shift-selecting still work as before?

> [note: no accessibility changes have been made, that's another bug]
> 
> The layout does mean that the large views are taller.  At this point I prefer
> the non-large view, and would suggest changing the value of the default for
> mailnews.attachments.display.largeView.  

LargeView = false sounds like a good idea.
But one of the core problems that this bugs seeks to address, i. e. give more information about the attached file, remains unsolved. Giving up "list view" and replacing it with a fixed set of controls for each attachment also means that you are giving up a lot of interesting options to use alternative views for the list:
With the new UI, you CANNOT:
- view a lot of attachments in a space-saving vertical list
- view long file names in full without hovering over every attachment
- list details
- sort by size, name, file type, mime type etc.

All of the above could be achieved by improving the current listbox UI.
Therefore, I'd much prefer and recommend improvements over the current listbox UI that make the file objects in attachment panel look and behave even more like any other file object in the OS (e.g. file objects in Windows Explorer):

- implement alternative view modes like details mode, small icons, simple list (bug 315144, cf. mockup screenshot in attachment 330616 [details] of duplicate bug 446452)
- make OS file manipulation keyboards shortcuts work for attachment file objects, too, like DEL, Shift+DEL to delete attachment files (bug 315144)
- make more OS file selection methods work on attachment file objects, too:
Ctrl+A to select all attachments (Bug 164351 against seamonkey), draw up frame around objects that you want selected

Having said which, of course the new UI as proposed by David does have benefits and maybe it's just the newness of the concept that confuses. Guess it depends where you come from in terms of usage habits etc. It's just that I think that building on and improving the existing interface might be a very good, (more) powerful and viable alternative. Combining the best of both worlds might include the following improvement for the traditional UI:

- reduce clicks and visualize options e.g. by adding a save / save all-button on the right hand side, just as David did in the new UI

XREF bug 360647, bug 315144, bug 164351

Comment 30

[Wayne Mery (:wsmwk)]

whatever evolves here may also help resolve some issues referenced in Bug 533921 comment 7. Do we want this as a goal for 3.1?  If not in the cards, then we should get serious about fixing some of the other bugs.  (we need more polish and need to be doing better in attachment-land)

Comment 31

[Dan Mosedale (:dmosedale, :dmose)]

3.1 is primarily about fixing things that would prevent users from accepting a prompted major update from Tb2.  Since this isn't a regression, I don't think it qualifies.  Marking wanted-thunderbird+, however, since there's real user pain here.

Comment 32

[Nomis101]

Attachment: Screenshot 2: My idea for attachment presentation (Mac) - with preview, checkboxes, properties pane

Let me propose my idea of an new attachment presentation. First of all, this is only a concept, I have no idea if this is easy to code. It needs interface refinement. And my Photoshop work is not very good. This is only to clarify my idea.
Let me explain it. This is for attached stuff only, not for inlined. On the left site you see all attachments, you can scroll through all attachments in the same way you know it from Mac Cover Flow. If you select an attachment in this overview you will see details for this item on the right site (name, type and size). If you double click on it (in the Cover Flow View), it will open in the appropriate application. To the right of the Cover Flow view you have a list of all attachments with a checkbox. If this box is checked, the attachment will be saved if you hit "Save all...". Per default all attachments are checked, because if you forward this email, only the selected attached files will be forwarded. So you can choose which files you will include in your forwarded mail. If you click on the "Save..." button, only this selected item will be saved.

Comment 33

[Thomas D. (:thomas8)]

Nomis, thanks for filing mockup screenshot attachment 426857 [details].

It is certainly visionary... and I like many of the details:
- indicate total number of attachments
- indicate total size of attachments
- indicate total size of selected attachments
- intuitive UI approach: select attachment(s), then click on action button (avoiding some, but not all of the visual overload of attachment 363274 [details]); although you skipped the file icons...

Problems (of attachment 426857 [details])

- I don't think we have got any so sophisticated attachment preview widget available yet, although there's an open bug about quicklook support. I think the current approach of inline previews might well suffice if we add a few common types like pdf etc.
- the attachment preview widget is too small to actually see much
- the attachment preview widget is too big to fit into attachment pane of standard 3-pane main window.
- the whole design is oversized and very space-consuming, which we must avoid
- the more we change about the current UI, the more coding time we will need (probably, I think...)
- reduplicating fixed xul UI elements (checkboxes, buttons etc.) does not seem a very efficient nor elegant strategy for a potentially unlimited number of attachments (even if we assume it's probably limited in the real world, but who knows, people might well send 20, 30, or 50 attachments). Attachment 363274 [details] has the same problem.

Comment 34

[Thomas D. (:thomas8)]

I wonder if we can find a design that does not completely overthrow our existing UI and codebase (like attachment 363274 [details], and attachment 426857 [details]), while still adding value that we would like to see added.

Design goals seem to be:
- more informative (information on attached files)
- more discoverable (easy access to various attachment file actions)
- space-efficient (!)
- intuitive
- nice and clutter-free layout; we are NOT a web mailer, so we shouldn't look like one. Rather we should have the look and feel of a native application.

I am still 100% convinced that the current UI approach of presenting attachments as file objects (just like any other files in the OS) could be very powerful and intuitive, because users will be familiar with usage patterns from their OS file managers, or even just file dialogues for that end. Rather than come up with yet another extravagant interface for attachments, we should seek to restore the charming simplicity, i.e. the full UI and behaviour of attachments as file objects. Iow, IMO acting on a given attachment file should not be much different from acting on any other file in the OS.

Requirements:

- Full focus respect (focus follows mouse click, focused element gets keyboard input)
- Full keyboard accessibility when focused (Ctrl+A, Ctrl/Shift-Selection etc., [Shift+]Del, (F2), Enter for default action etc.)
- Select and act (by clicking unique command buttons outside the file list, as opposed to reduplicating buttons for each file)
- Contextual actions/menus

Comment 35

[Thomas D. (:thomas8)]

(In reply to comment 34)
...where full keyboard accessibility also includes accessibility of the attachment with <tab> or some other key (existing bugs)

There's a lot of bugs out there because we are currently NOT meeting these basic requirements of user interaction in attachment pane.

Comment 36

[Thomas D. (:thomas8)]

Attachment: Screenshot 3: Attachment pane with added save buttons (simple list mode)

Adding "save" buttons to the existing UI

Here's my first stab at adding the "Save..." and "Save all..." buttons to the current layout, as previous proposals seem to agree with bug 541336 that these would be useful.
- with as few changes as possible to the current code/layout (I'm not happy with truncated file names, windows xp explorer handles this a lot better in list mode; at least, we should have less columns to show more of the names)
- as space-saving as possible (thus no extra textual information, except in status bar and button tooltips).
- We could also add more information about the properties of each file in a multiline-tooltip.

Now if you want to see more of the file details for every attachment, you right-click anywhere in the attachment area (on a file, or on free space), and the context menu will have the following sub menu (as in Windows Explorer):

View >  o List
          Details

Click on "Details" and you'll get Screenshot 3 (next comment).

Comment 37

[Thomas D. (:thomas8)]

Behaviour / functionality of the Buttons:

- dual buttons
- clicking on the left part will do the action (save/save all)
- clicking on the dropdown arrow reveals dropdown menu:

[Save... v]
+-----------+
|Open...    |
|Save...    |
|Detach...  |
|Delete...  |
+-----------+

[Save all... v]
+---------------+
|Open all...    |
|Save all...    |
|Detach all...  |
|Delete all...  |
+---------------+

Let me know if I missed something here...

Comment 38

[Thomas D. (:thomas8)]

Attachment: Screenshot 4: Attachment pane with added save buttons (details mode)

(In reply to comment 36)
> the context menu will have the following sub menu (as in Windows Explorer):
> View >  o List
>           Details
> Click on "Details" and you'll get Screenshot 3 (next comment).

Well, let's hope you'll actually get Screenshot 4 (attached to this comment)... ;)

Save Buttons (as in screenshot 3) + View: Details Mode (new)

This should be familiar to anyone using windows explorer, or any other file manager... nice & neat, the good old grid.

Benefits of Details Mode:

- see long attachment file names in full (instead of hovering over each
attachment just to see the name)
- see and compare file sizes of attachments (not implemented at present)
- excellent cost-benefit ratio with regards to screen real estate
- sort attachments according to name, size, file type, date/time when added
etc. (not possible at present)

Furthermore:
- Addons can easily hook into the attachments grid to add custom columns, e.g. a column for read/unread icon as proposed in bug 575879, attachment 458013 [details].

Comment 39

[Thomas D. (:thomas8)]

(In reply to comment #34)
> I wonder if we can find a design that does not completely overthrow our
> existing UI and codebase (like attachment 363274 [details], and attachment
> 426857 [details]), while still adding value that we would like to see added.

Disambiguation: While attachment 363274 [details] and attachment 426857 [details] (and attachment 458013 [details], too) all change the existing UI and codebase a lot, I wonder if we can find a design with less drastic changes while still adding value that we would like to see added. Perhaps something like screenshot 3 (attachment 458114 [details]) or screenshot 4 (attachment 458120 [details]) that build on the existing UI of TB's attachment panel and OS file managers/dialogues.

FTR: I filed
Bug 579473 as a [meta/tracker] bug for
Usability bugs about attachment pane UI (incl. proposed enhancements/improvements)

Comment 41

[Thomas D. (:thomas8)]

(In reply to comment #36)

> the context menu will have the following sub menu (as in Windows Explorer):
> View >  o List
>           Details
> Click on "Details" and you'll get Screenshot 3 (next comment).

typo fix: Click on "Details" and you'll get Screenshot 4 (attachment 458120 [details], comment 38).

Comment 42

[Thomas D. (:thomas8)]

Comment on attachment 458114 [details]
Screenshot 3: Attachment pane with added save buttons (simple list mode)

Bryan, thoughts? Building on the existing attachments UI and codebase could be a realistic (time-and resources-saving) and highly functional approach to this bug.

The classic "list mode" of this Screenshot 3, attachment 458114 [details] can be switched to "details mode" of Screenshot 4 (sic! beware of the typo in comment 36), attachment 458120 [details].

- Design goals and requirements are laid out in comment 34-35 (+ comment 39).
- specific design/functionality of "List mode" explained in comment 36 and comment 37.
- "Details mode" explained in comment 38.

Comment 43

[Thomas D. (:thomas8)]

Comment on attachment 458120 [details]
Screenshot 4: Attachment pane with added save buttons (details mode)

Bryan, thoughts? Pls find the information needed for your UI feedback in previous comment 42.

Comment 44

[Ulrich Windl]

On comment #34 (design): MIME messages actually have no "attachments", they can consist of multiple parts ("multipart"). At the moment Thunderbird treats every part as attachment, which is confusing. As parts may be nested arbitrarily, the "folder view" of a message may seem more appropriate that a "click to open", especially when being done recursively. Users get lost that way.
Also parts may have names (Content-Type[name], Content-Disposition[filename]) and types (Content-Type[type]). In addition there are exceptions to the tree-view of parts: Only multipart/mixed is the classical attachment content model; multipart/alternative and multipart/report (Mail errors) need special treatment.

Comment 45

[Bryan Clark (DevTools PM) [:clarkbw]]

Attachment: updated version

took some time today to update this version of the patch.  I'm not done yet but here's my work in progress.

Comment 46

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 458114 [details]
Screenshot 3: Attachment pane with added save buttons (simple list mode)

I like the direction of these however it's moving away from the origin of the bug where we rely less on people focusing on the attachments and more on checkboxes which preserve selection / user data.

With the checkboxes we need space for select all / none and then only one button for save as the default with the menu options being for other less used actions like delete or detach.

Comment 47

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 458120 [details]
Screenshot 4: Attachment pane with added save buttons (details mode)

see comments in comment 46

Comment 48

[Jonathan Protzenko [:protz]]

Hey folks, I can revive the patch from bug 564423 should you want to (removes the Part 1.2 - like attachments, although we need further feedback before landing this). I haven't read all of the comments on this bug, so sorry if it's not relevant.

Comment 49

[Dan Mosedale (:dmosedale, :dmose)]

protz, if I'm reading the recent comments here correctly, it looks to me like the next steps are for someone to keep iterating on what Bryan's done recently in comment 46 and 47.  If Bryan agrees with that, is it something you're interested in picking up?

DavidA, I'm guessing you're not actively working on this nor are you likely to soon.  If that's correct, would you be willing to assign it back to nobody to make it clear that this bug is free for the taking?

Comment 50

[Jim Porter (:squib)]

I'm working on something pretty similar to this in bug 282068 (which is quickly becoming my "fix everything bad about the attachments pane" bug). If people want to look at that and give ideas for how to fix this bug over there, I can work on it. I've recently gotten keyboard focus/shortcuts working in the attachment pane, which may obviate a lot of the problems this bug is trying to address.

Of course, that all depends on how strongly clarkbw feels about what he said in comment 46. :)

Comment 51

[Jim Porter (:squib)]

Since much of the work here has been superseded by bug 282068, should we close this? We might want to file individual bugs for the remaining issues in comment 0 as well...

Comment 52

[Dan Mosedale (:dmosedale, :dmose)]

No objection from me.

Comment 53

[Jim Porter (:squib)]

(In reply to comment #0)
> * the names presented are often useless ("Part 1.2")

Bug 663765

> * no visual cues are given (type of file, size, ...) w.r.t. what the
> experience of clicking that is going to be like

Bug 559559 and bug 360647

> * there's no distinction made between attachments that are already displayed
> inline in the message and those that aren't (note that we may want to do
> different things for attachments came with Content-Disposition: inline vs
> attachments that were forcibly displayed inline because of a pref setting).

Bug 671056

> * do we even want to show stuff that's already inline here?  this is
> especially weird for mailing lists that auto-attach signatures.

Bug 663765 (sort of)

If anyone has other issues mentioned in this that they think are not yet resolved, please file a new bug and have it block bug 579473.