On 10/19/12, Gary Martin <[email protected]> wrote:
>
[...]
>
>> Replying to [comment:7 jdreimann]:
>> > Replying to [comment:6 olemis]:
>> > > Feedback is welcome .
>> >
>> > Thanks Olemis, looking good!
:)
>> > I would remove some of the buttons though:
>> > 1. **Start upload** - I believe dragging a file onto the page or
>> selecting it in the file dialogue is enough of an indication that the
>> user
>> wants to upload it.
Please read Gary's comment below .
>> > 1. **Cancel upload** - This should be done individually via the {{{ x
>> Cancel }}} action you've already placed next to the upload indicator.
... it will also clear the list before upload , in case e.g. user
thinks ticket #25 is displayed and selects files to attach but
suddenly realizes that it's #26 , so clears the whole list and moves
on ... ;)
>> > 1. **Clear failures** - Again, this should be done individually.
>> Failures matter, especially in these low volume transactions (usually
>> someone will attach one or two files only); not the situation in which
>> I
>> would expect batch clearing to be helpful.
I'm +0 about this , so if this is the right way to go , no objections
from my perspective .
>> > 1. **Toggle all** - I assume this is related to the previous three
>> buttons?
>> >
Oh , no ! Sorry . Not needed any more . It was helpful in original
demo because it was possible to delete both attached files at the
server side and failures in the client . However , considering that
the former case will not be supported then I just decided to hide
items checkbox ... but forgot to remove Toggle all switch . /me
getting old or something .
>> > Just to clarify: in the description field, what does the button at
>> the
>> end do?
Upload file + comment .
>> I can't quite make it out from the screenshot. In the mockup it
>> was meant to confirm the input to save it, or cancel to clear the
>> changes
>> to them based on the inline editing discussions on the mailing list
>> recently.
>>
Well , in Trac attachment upload plus comment happen both at once . If
we are going to support editing file description then that's a
different subject , i.e. separate ticket .
;)
[...]
>>
>> Actually, olemis has a point. I didn't spot that issue as I did not
>> understand that jdriemann wanted the downloads to start at the earliest
>> opportunity.
>>
... well I actually translated the original demo , and all those
buttons were present and deserved to be considered . I did remove some
other items that I considered unnecessary e.g. delete attachment
button because that op is not supported at the moment . Might be added
later though .
>> My concern here is that sometimes people are going to find that they
>> are
>> uploading files that they did not mean to. I realise that jdreimann's
>> suggested drop area reduces the likelihood that a file will be dropped
>> accidentally when the drag action was meant for another location, but
>> mistakes will still happen just from selecting the wrong file.
>>
+1 ... files with similar names and other situations are possible .
Confirmations exist in GMail too , but in a subtle way . In that case
files are pre-uploaded without further notice , nonetheless users may
cancel specific uploads or remove files from the list before sending
the message ... which is exactly the action used to confirm
attachments list .
In this case that's not appropriate because pre-uploading files is not
a good practice in this context ... needless to say that it's hard to
delete attachments .
>> I would suggest that making sure it is possible to confirm all with a
>> single button click would be enough to reduce inconvenience here
That's exactly what «Start upload» is for . File uploads should be
sequential though .
;)
>> I
>> am not suggesting we should have an additional "are you sure" after
>> that.
>>
No need to . Users had a lot of time to choose , and individual
«Cancel» buttons (close to progress bar) will stop undesired downloads
. So there's no need for an extra confirmation dialog .
>> Finally, even if my reasoning above is a bit too protectionist,
>> immediate
>> upload certainly seems to me to be inconsistent with the conclusions I
>> believe we have come to about inline editing on the same page.
>>
Most of all , it's not in sound with underlying attachments module because :
1. there's no pre-loaded attachments cache
2. it's usually hard to delete attachments
3. ticket view does not have subtle acceptance mechanisms like
GMail send button
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
