Re: [Apache Bloodhound] #195: Attach file form à la GMail

[Gary Martin <ga...@wandisco.com>]

I thought this deserved some extra discussion here:

On 19/10/12 11:17, Apache Bloodhound wrote:
> #195: Attach file form à la GMail
> --------------------------+----------------------
>    Reporter:  jdreimann    |      Owner:  olemis
>        Type:  enhancement  |     Status:  accepted
>    Priority:  major        |  Milestone:
>   Component:  ui design    |    Version:
> Resolution:               |   Keywords:
> --------------------------+----------------------
>
> Comment (by gjm):
>
>   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.
>   > 1. **Cancel upload** - This should be done individually via the {{{ x
>   Cancel }}} action you've already placed next to the upload indicator.
>   > 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.
>   > 1. **Toggle all** - I assume this is related to the previous three
>   buttons?
>   >
>   > Just to clarify: in the description field, what does the button at the
>   end do? 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.
>
>   Note: I think that we should discuss this on bh-dev so I will reply to the
>   subsequent email that this comment creates for us to continue there.
>
>   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.
>
>   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.
>
>   I would suggest that making sure it is possible to confirm all with a
>   single button click would be enough to reduce inconvenience here - and I
>   am not suggesting we should have an additional "are you sure" after that.
>
>   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.
>

Re: [Apache Bloodhound] #195: Attach file form à la GMail

[Olemis Lang <ol...@gmail.com>]

On 10/19/12, Gary Martin <ga...@wandisco.com> 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: