Hi Simon. Thanks for the reply. Please see my comments inline ::
On Fri, Feb 3, 2012 at 2:47 PM, Simon Schampijer <[email protected]> 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 > [email protected] > http://lists.sugarlabs.org/listinfo/sugar-devel _______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
