Re: [Evolution] Proposal: Evolution Attachment UI

["Srinivasa Ragavan" <sragavan novell com>]

fejj,

First let me clear one thing.
Im not trying to solve."inline attachment proposal".
What i meant was 'a proposal for UI Attachment', continuing the discussions from the proposals from dobey.

Im wasnt discussing about "Content-Disposition: inline" in this mail.
Im discussing about files, that are attached. 

What you have specified is one specifc problem, that if the two attachments in that case has same name. We 
can look at that case specifcally.

I agree that i could be confusing to put two files with same name. But how many ocassion is that scenario 
gonna occur. We can have a work around to have a string/some context info appended to the file name for 
display purpose or something else to avoid the confusion. I have specially spoken about the similiar 
scenarios, but not assumed the same file name every where.

I feel it may not be worth to ignore this idea, for a problem that of how to display what if we have two 
attachments of same name.

-Srini


> > > Jeffrey Stedfast <fejj novell com> 06/03/05 10:53 PM >>>
I'd like to first start off with the question: What exactly is this
inline attachment proposal trying to solve?

the problem with your approaches is that they do not scale to multipart
messages that contain other multiparts - your proposal only really works
for flat multipart messages; remember: MIME is a tree; not a list.

what if, for example, you have the following message structure:

multipart/mixed
  text/plain
  application/octet-stream; name="attach.dat"
  message/rfc822
    multipart/mixed
      text/plain
      application/octet-stream; name="attach.dat"


you've got 2 attachments with the same name... how do you present that
in a flat icon list? you can't.

the current method of display is more true to the presentation that the
original sender intended than an icon list could ever be.


another problem I have with your proposals is, what exactly counts as
"inline attachments"? Are we just talking about MIME parts with the
following header?

Content-Disposition: inline

If so, what if a user wishes to toggle an attachment to be viewed inline
even when its disposition is defined as "attachment"? Since there is no
placeholder in the message display, this won't be trivial to implement
nor will it "feel" right.

It seems to me that the problem (whatever it is) needs more thought.

On Fri, 2005-06-03 at 09:35 -0600, Srinivasa Ragavan wrote:
> Hi,
>
> I have thought about a new attachment UI, inline with the proposals on Attachment UI enhancements from 
> dobey and Nat, that replaces the existing buttons that are present at the bottom of every message part.
>
> - Remove those buttons and put a attachment bar.
>       
>       This can be done in multiple ways. Im listing down the various ways.
>
>       (1)     Have a small attachment bar panel, at the bottom of the message and show it, when there are 
> attachments. But it would then reduce the space of the message view. I have a sample at 
> http://gnomebangalore.org/~sragavan/attachment-manager.png. We can also decide upon, whether it should be 
> on the bottom, or top of the message. In this case, when a message that has a forwarded message which 
> inturn has some attachments, is viewed (if the forwarded message viewed inline), then all the attachments 
> would be shown in the same bar. This also helps to get all the attachments at one single place. All the 
> attachments would be displayed as icons.
>       
>       (2)     Have a small attachment bar sort of widget, at the bottom of the message. All the attachments 
> are diplayed as icon list in the attachment bar. Like at the end of the message, we have a small attachment 
> bar, which shows the attachments. Here again, when the message which has a forwarded message which inturn 
> has some attachments, is viewed inline, there are two ways to the problem. A sample is attached at 
> http://www.gnomebangalore.org/~sragavan/bar.png
>       
>               (a)     Show the attachment bar at the end of each message part, which would result in 
> multiple attachment bars in a message that has multiple forwards. This would really cause trouble, when a 
> mail has multiple forwarded attachments which inturn has attachments.
>               (b)     Show the attachment bar at the end of the top message part (bottom of the message 
> view). In this case, there would be just one attachment bar, at the bottom of the message view. The only 
> difference between (1) and this, is that it doesnt have a dedicated window space, which hides the message 
> view. When a forwarded (attached) message which has attachments is viewed inline, its attachments are shown 
> in the parent message's attachment bar and when hidden, its attachments are removed from the bar. But it 
> has a issue, that the user has to scroll a lot, if he has to see the attachments. This can be solved by 
> adding a button at the top without disturbing the UI, which scrolls to the attachment bar.
>               
>       (3)     Have a expander at the top, probably below the subject, which could list the attachments as 
> links on expanding it. It would be simple. But it wont be much user interactive. It is not a widget. Just 
> embedded html links. 
>
>
> I would vote, for the 2 (b) option. We should have a "Scroll to Attachment bar" button too as a short cut 
> to avoid scrolling.
>
> - Allow attachments to be shown inline
>
>       The attachments, which are set to show by default, should be shown inline. The attachments will be 
> shown in a widget frame which has a HIDE button at the top to hide the displayed attachment. They also can 
> be hidden, by click "Hide" in r-click pop-up menu of the shown attachment.
>
> - Resize the images to fit available size.
>       
>       Provide a option in Edit->Preferences->Mail Preferences->HTML Mail-> Resize images to available size
>       It should keep the aspect ratio of the image.

this is a good idea

> - R-Click popup menu on the attachment.
>       
>       The R-click menu should have "Save All Attachments", so that all the attachments in the bar can be 
> saved easily. I have put up a sample popup menu at http//gnomebangalore.org/~sragavan/menu.png. It should 
> have the default application from mime type default application ,other supported application and a 
> provision to open with a custom application. 

sure, this could be nice.

> - Emblems to show the status of the attachment. (A New idea)
>
>       Many times, ive forgotten that did i save the attachment. Or did i saw all the attachments. Just a 
> idea from that pexperience. We should have some emblems attached on those attachments, that are viewed, 
> saved etc. I have put up a screenshot of the mock at http://gnomebangalore.org/~sragavan/emblem-bar.png.
>
> All these are ideas, i wanted all your opinions and suggestions to improve the attachment UI.
>
> Thanks
> Srini.
>
>
>               
>
> _______________________________________________
> evolution maillist  -  evolution lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution
-- 
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
fejj ximian com  - www.novell.com