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

Ajay Garg ajaygargnsit at gmail.com
Fri Feb 3 05:14:44 EST 2012


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


More information about the Sugar-devel mailing list