[Sugar-devel] [DESIGN] Journal share activity

[Simon Schampijer]

On 05/03/2013 02:26 PM, Gonzalo Odiard wrote:
> On Thu, May 2, 2013 at 12:50 PM, Simon Schampijer <simon at schampijer.de>wrote:
>
>> Hi,
>>
>> Manuel and myself have been looking at the work-flow for the Journal share
>> activity these days: http://activities.sugarlabs.**
>> org//en-US/sugar/addon/4656<http://activities.sugarlabs.org//en-US/sugar/addon/4656>
>>
>> We discussed the design completely independent of possible technical
>> constraints we will see what we can do, and what we can not but we wanted
>> to first look at the work flow itself. Here is the state of things so far:
>>
>>
>> ===Use cases===
>>
>> (a) a teacher is handing out a pdf to the class
>>
>> (b) a teacher wants to collect a picture (Paint) or an assignment from
>> each pupil
>>
>> (c) a group of pupils want to share files between each other (e.g. a
>> project work)
>>
>>
>> ===Questions===
>>
>> * What can you share?
>> You can share Journal items.
>>
>>
> Walter pointed to two other request from teachers:
>
> * share one activity.
> * share favorite activities configuration.
>
> While the teacher can share a .xo bundle to share the activity, if is
> already installed, we can run setup.py, and create the bundle if needed.
> Can be a future improvement.
>
>
>
>> * To whom can you share?
>> People in your current network (see other activities you share)
>>
>> * Can everyone share who is a member of that session?
>> The case where a teacher wants to collect data from the pupils (b), does
>> impose privacy concerns. There should be the possibility to send a file to
>> one person only without making it public to all of the members.
>>
>>
> Good point
>
>
>
>> * Is it a push or a pull model?
>> (a) and (b) should be based on a push model. The receiver should be asked
>> for confirmation of this transfer (see the current file transfers in the
>> Sugar shell). Both sides need to know about the status of the transfer.
>>
>> (c) would be handled best with a pull model (see a download).
>>
>>
> Like in Browse or Record, the item to download should be updated
> automatically, when the user select it, is downloaded.
>
>
>>
>> ===Designs===
>> We basically started off with a UI based on tabs [1]. Each member of the
>> session has a tab, the label contains the colored XO icon and the nick name
>> of the learner. The first tab represents yourself. The header of each tab
>> has information about the learner and if it is yours a button to share
>> items with all the members. The body has the items you shared and each item
>> a button to un-share an item. The other tabs list the items the learner
>> shared and a button to download an item.
>>
>> This UI shows the pull model and handles case (c) well. It does not work
>> for the case (b) that well, as a shared item is public to all of the
>> members. Furthermore, a teacher would need to go to each tab in order to
>> collect the data it needs.
>>
>> Based on the downsides of the first UI [1] we came up with the second UI
>> [2]: On the left you see all the members that are present in the shared
>> session (similar to the UI in Memorize). There is a button for each member
>> to send him a file directly (handles case b). This list is scrollable.
>> There could be as well a row at the bottom of the list for a 'sent to all'
>> option to handle case (a).
>>
>
> I like the second UI more too.
>
>>
>> On the right side at the top is the list of items you shared publically.
>> There is a button to add new items. The list is scrollable. There is a
>> button to un-share your items and a button to download items shared by
>> others. This is case (c), case (a) could be handled with this model as well.
>>
>>
> Case (a) need information about who downloaded the object.
>
>
>
>> Below is a widget that shows the incoming items. You can accept those
>> incoming files individually or have a button for accept all. There should
>> be a way to select the storage target (Journal/USB/...) either with a
>> Palette or a dialog. This is case (b).
>>
>> In the second sketch in [2] you can see a feedback widget for the items
>> you sent (one-to-one transfers). It shows if an item has been received and
>> you can cancel a transfer (see the file transfers protocol in the Sugar
>> shell for this).
>>
>>
> I am not sure about this part. This division between the shared items, and
> the incoming and sent items will show duplicates. I think we can do a
> single list, with information about:
> * Who shared it.
> * If you shared it, who downloaded it, if not, show a button to download it.
>
> Gonzalo

I think there are two fundamental differences:

- one-to-many: you share an item publically to all of the members of the 
session, the ones that are available should be visible in one list, in 
the mockup at the top left, everyone can download any of those items, 
the download will go into the device you specify, there should probably 
be an indicator if you want to store an already downloaded item into the 
same place (like with any generic download)

- one-to-one-outgoing: you send one item to a specific person, here you 
need some feedback if the receiver acknowledged the incoming transfer

- one-to-one-incoming: you receive a file sent by one specific person, 
here you need an alert for the request, that you can acknowledge

I do not see any duplicates here. You can argue that the one-to-one 
transfers should be in one list with clear indicators what is an 
incoming and what is an outgoing transfer, that could work

Regards,
    Simon