[Sugar-devel] [PATCH] sl#3315: Journal-Entry transfer from 1-to-N users.

[Ajay Garg]

Hi Walter,

Thanks for the reply.

1.
The "Configuration" section Control Panel serves the dual purpose of
adding buddies as friends on the fly during group creation; more
importantly, it is a place where the
operation-status-for-each-friend-of-a-group is shown.

If the second requirement (showing operation status) could be done
away with, we could do away with the Control Panel as well :-)



2.
Regarding the list-view version of Group view, I am a little
sceptical. After all, it is a journal entry (or a set thereof) which
comes first; then the operation (Copy, Duplicate, Send To, Erase,
Start etc.) is selected on the already-selected-journal-entry; and a
group is the thing on which the already-selected-operation on the
already-selected-journal-entry (or a set thereof) operates. It does
not happen the other way round.



These were purely my thoughts. Or may be I am missing something?


Regards,
Ajay



On Fri, Feb 3, 2012 at 6:21 PM, Walter Bender <walter.bender at gmail.com> wrote:
> This seems like a nice direction to be heading in general (be great to
> land something like this in 0.98). However, I wonder if the control
> panel approach is the right one? Why not do all of these operations
> from the Group View. Perhaps the batch operations could be done from a
> list-view version of the Group View. This way all the group-related
> activities would all be in the same place in the interface.
>
> regards.
>
> -walter
>
> On Fri, Feb 3, 2012 at 5:14 AM, Ajay Garg <ajaygargnsit at gmail.com> wrote:
>> Hi Simon.
>>
>> Thanks for the reply.
>> Please see my comments inline ::
>>
>>
>> On Fri, Feb 3, 2012 at 2:47 PM, Simon Schampijer <simon at schampijer.de> wrote:
>>>
>>> On 02/03/2012 07:41 AM, Ajay Garg wrote:
>>>>
>>>> ---
>>>>
>>>> The workflow can be assessed via the screenshots at ::
>>>> http://wiki.sugarlabs.org/go/Features/Transfer_to_many_screenshots
>>>
>>>
>>> Thanks Ajay for the patch.
>>>
>>> You should be more verbose in the description about the following points:
>>>
>>> * what does the patch do
>>
>>
>> The patch provides a user (say a teacher) to send a single-entry from
>> her XO, to all the students in the class (say, 20), with a
>> single-click.
>> That is, the teacher does not have to do 20 repeated steps for sending
>> the _same_ entry to (20) students.
>>
>>
>>
>>
>>
>>
>>
>>>
>>> * why did you take the decisions you took
>>
>>
>> A.
>> The core-backend (at the lowest level) remains the same. The entry is
>> sent "on the wire" from the server (teacher) to the client (student)
>> through the dbus-telepathy-filetransfer APIs. So, in a broad-level
>> manner, the sending to 20 students is a for-loop, over the
>> core-backend process.
>>
>>
>>
>> B.
>> It needed to be decided as to how to group friends. The most obvious
>> way to group them was to place friends under "groups" (there may be
>> any number of groups defined by the user).
>>
>> In my first iteration, I had added the ability to create groups a
>> newly added Control-Panel, and then add friends "one-by-one" into the
>> group from the neighborhod view (more details to follow).
>>
>> This is almost identical to the mockup at
>> http://wiki.sugarlabs.org/go/Design_Team/Proposals/Groups#Add_buddy_to_existing_Group_from_Neighbourhood
>>
>> with the following difference ::
>>
>> _Instead of having two options ("Make friend", and "Add to Group",
>> there are three options :: ("Make friend (without associating to any
>> group)", "Make friend (if not already), and add to group" and "Remove
>> from group")_
>>
>>
>>
>> C.
>> However, after looking at the mockup-number-3 at
>> http://wiki.sugarlabs.org/go/Design_Team/Proposals/Groups#Former_Design_Sketches
>>
>> it instantly seemed that this was the right way, as
>>
>> (i)  It allowed batch-addition of friends at the time of creating the group.
>>
>> (ii) The option to add from the "Neighborhood view" was retained, to
>> add any currently-offline buddy.
>>
>> (ii) A specific Control-Panel for groups could also be used for
>> examining the operation status. Please see :
>>     http://wiki.sugarlabs.org/go/Features/Transfer_to_many_screenshots#.5BStep_15.5D_view_operation_status
>>     http://wiki.sugarlabs.org/go/Features/Transfer_to_many_screenshots#.5BALTERNATE_Step_15.5D_view_operation_status
>>
>> (iv) The same control-panel can in fact be used to see the status of
>> _any_ operation on the group (though currently only "send-to" feature
>> has been implemented for groups.
>>
>>
>>
>> D.
>> There is only notification for a group-action, that gives the running status.
>> Moreover, the user (teacher) is prompted to click "Dismiss" only after
>> the transfer has been made to the last student. Please see screenshots
>> from [Step 08] to [Step 14] at :
>> http://wiki.sugarlabs.org/go/Features/Transfer_to_many_screenshots
>>
>>
>>
>>
>>
>>
>>
>>>
>>> * the patch involves new UI, did you discuss that with the Design team already...
>>
>> I am afraid I did not on an official basis (just looked at the mockups) :-(
>> From he mockups, I interpreted the workflow with the minimum of
>> user-intervention; and minimum cluttering of the UI (only single icon
>> per journal-entry per group, that shows running status).
>>
>>
>>
>>
>>
>>
>>> * did you have a look at previous work in this area, e.g.: http://wiki.sugarlabs.org/go/Features/Transfer_to_many
>>>
>>
>> Yes, I did; and derived the minimal and most optimal workflow for
>> "sending a journal enttry to a group".
>>
>>
>>
>>
>>
>>
>>> As well I am curious how you handle the following case: A teacher sends to a group of 20 children a file and gets twenty notifications about the transfer in the activity tray.
>>
>> "Send to group" uses just a single outgoingtransferbutton icon. That
>> is, there is a single icon per journal-entry per group.
>>
>>
>>
>>
>>>
>>>
>>> Regards,
>>>   Simon
>>
>>
>>
>> I must say that this is just a starting iteration. I am sure I may
>> have missed some important things.
>> Will look forward for your feedback, on improving/rectifying the patch :-)
>>
>>
>> Regards,
>> Ajay
>>
>>
>>>
>>> _______________________________________________
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org