On 16 October 2012 21:31, Ryan Ollos <[email protected]> wrote:
> On Tue, Oct 16, 2012 at 9:03 AM, Olemis Lang <[email protected]> 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] http://trac-hacks.org/wiki/PdfRedirectorPlugin > [2] http://trac-hacks.org/wiki/PdfRedirectorPlugin#Description > [3] http://trac-hacks.org/wiki/TracDragDropPlugin >
