incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Dreimann <>
Subject Re: [Apache Bloodhound] #195: Make Attach file dialogue a popover
Date Tue, 16 Oct 2012 21:44:09 GMT
On 16 October 2012 21:31, Ryan Ollos <> wrote:

> On Tue, Oct 16, 2012 at 9:03 AM, Olemis Lang <> wrote:
> > New mockup has been attached to #195 for this feature in order to make
> > attachments form à la GMail | Google+ | ... I'll start working on this
> > so early feedback is welcome .
> >
> > I look forward to your comments.
> The mockups look nice, and I think they are headed in the right direction.
> I'm not sure how detailed the mockups are intended to be, but I'd suggest
> the following:
>  * Keeping the Download button that currently exists next to each
> attachment filename.
>  * Adding a delete button (e.g. an X next to the download link), available
> only when the user has permission to delete attachments (TICKET_ADMIN).

Unless I've said otherwise, mockups I'm contributing aren't meant to be
exact - they give a general indication. Implementation will determine the
details.  Having said that, I've added the download buttons to an updated
mockup (now uploaded to #195).

I'm not as sure about the delete button (currently available once someone
clicks on the file name), because I prefer safe defaults and people are in
a better position to determine which exact file has to be deleted (there
could be multiple, similarly named patches for example) once they have
clicked on the file to see a more detailed view. I'm not expecting huge
volume batch deletes at the moment.

> Here are a couple of additional things I've found undesirable in the
> current Trac attachment module, which we might be able to solve here:
>  * The area for entering the description of the attachment (the comment) is
> too small. The mockups show this textarea as being rather small as well,
> but I'd suggest we try to increase the size of it a bit.
>  * There is no way to preview the description that has been entered, which
> is particularly problematic when using wiki markup.

These two points seem to exactly duplicate the Add Comment functionality on
tickets. If we think this is important, I believe we should rather move to
attaching files to comments rather than tickets themselves. There are
various pros and cons to this, and I believe that makes it out of scope for
this ticket - I have however increased the length of the comment field.

The point of the current comment field should really be to succinctly
expand on the descriptive quality of the file name. Further information
really belongs in a Comment on the Ticket itself. I have almost doubled the
description field now in the mockup though.

 * (Possibly out of scope) When previewing a file for which there is no
> renderer available, or a file that exceeds mimeviewer: max_preview_size,
> the user is taken to a page where they are told that the file can't be
> previewed, and suggesting that they download it ("HTML preview not
> available, since no preview renderer could handle it. Try downloading the
> file instead."). Maybe we want to directly export (force the download) of
> these files? The only downside I see is that it could be slightly confusing
> to users as to why a file is downloading when they expected it to render in
> the browser (e.g. maybe it was a file that could be previewed, but the file
> was too large). Maybe there is a way to work around this, such as adding a
> notice on the page.
>  * Following on the previous point, for PDFs, it would be nice if they
> could be directly rendered in the browser. PdfRedirectoryPlugin is an
> extremely simple plugin that does this, and it works fine, except the
> ability to directly delete the file is lost (see [2] for workaround).
> Having the ability to delete the attachment via an X on the ticket page
> would work around this problem.

I have to admit that I haven't tried to find out what the file previewer is
really capable of. If we improve this system, we may indeed want to move
the delete button to the ticket page itself.

In regards to PDFs, using Chrome to open them I almost forget what a pain
they can be in other browsers (using external applications to view them).

> There is a plugin on Trac-Hacks [3], which might provide some inspiration.
> I tried earlier this year to get it working, with no luck. I might give it
> another try.
> [1]
> [2]
> [3]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message