After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 494629 - Rethink composer's attachment UI
Rethink composer's attachment UI
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.22.x (obsolete)
Other Linux
: Normal enhancement
: ---
Assigned To: Matthew Barnes
Evolution QA team
evolution[composer] evolution[attachm...
Depends on:
Blocks:
 
 
Reported: 2007-11-07 15:29 UTC by Michael Monreal
Modified: 2009-04-27 19:21 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
Mockup (89.25 KB, image/png)
2007-11-07 15:36 UTC, Michael Monreal
Details

Description Michael Monreal 2007-11-07 15:29:19 UTC
I dislike the way how attachments are added to a new mail when not using drag and drop. The current design has the following problems:

- the toolbar button for adding attachments is the same as the one used for showing attachments in received mail

- the toolbar button for adding attachments is not placed very clever where it is right now.

I would prefer to move that action down to the actual attachment bar, I think this is where people look for a way to add things, not in the main toolbar. See mockup.
Comment 1 Michael Monreal 2007-11-07 15:36:03 UTC
Created attachment 98722 [details]
Mockup
Comment 2 Matthew Barnes 2008-02-16 23:32:08 UTC
I agree that the toolbar is not the right place for an "Add Attachment" button.

I also think the "Show/Hide Attachment Bar" label is rather useless.  Expander labels should not be phrased as actions; rather they should hint at what you'll see if you expand it (e.g. "Advanced Options" not "Show Advanced Options").

Iterating on your suggestion, what about something like this (in ASCII art):

  When the attachment bar is hidden:

  > 0 Attachments    [ + Add Attachment... ]  [ Show Thumbnails ]

  When the attachment bar is shown:

  v 0 Attachments    [ + Add Attachment... ]  [ Hide Thumbnails ]

The expander arrow and "Show/Hide Thumbnails" buttons would work identically, but that's okay.  Redundancy is good in UIs.

By the way, I'm trying to collect composer UI bugs for my composer rewrite targetted for Evolution 2.24.  If you have any other bugs like this could you please add "Composer" to the status whiteboard of each of them so I can easily find them?
Comment 3 Matthew Barnes 2008-02-17 00:41:54 UTC
Actually, I wonder if we should drop the expander altogether.  I can't find any other examples of what I consider good GNOME applications that use expanders this way.  It seems like maybe not the best widget for managing the visibility of top-level window components.

So now I'm leaning towards:

  0 Attachments    [ + Add Attachment... ]  [ Show Thumbnails ]
     |
     +-- Just a label

Maybe we should add a "View -> Attachments" menu item while we're at it.

Note, I'm not a UI designer.  Just brainstorming ideas here...
Comment 4 Srinivasa Ragavan 2008-02-18 15:38:32 UTC
Matt, iirc the initial version didn't had it and it was me who did all the work from Dobey's UI design. Lets not remove the expander. But definitely I like the idea of moving the '+ add attachment' thing.
Comment 5 Matthew Barnes 2008-03-11 00:37:22 UTC
Bumping version to a stable release.
Comment 6 Matthew Barnes 2009-03-27 01:29:15 UTC
I'm in the process of rewriting the attachment UI from scratch on the kill-bonobo branch, and now would be the perfect time to move the "Add Attachment" button if we still think it's a good idea.

@Srini, still in favor of this?
Comment 7 Srinivasa Ragavan 2009-03-27 05:39:44 UTC
Im fine with this. As long as we use the space around this wisely. 
Comment 8 Matthew Barnes 2009-03-28 03:25:22 UTC
I posted screenshots of the new design in bug #516933.
Comment 9 Matthew Barnes 2009-04-27 19:21:36 UTC
The attachment rewrite has been committed to the master branch and is believed to have addressed this bug.  If you find that not to be the case, please reopen.

http://git.gnome.org/cgit/evolution/commit/?id=e377ea5e61171e57f9e892652d0fd1f77953eda8