[Sugar-devel] [DESIGN] Journal share activity

[Gonzalo Odiard]

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



>
> Regards,
>    Simon
>
> [1] http://dev.laptop.org/~erikos/**share/tabs.JPG<http://dev.laptop.org/~erikos/share/tabs.JPG>
>
> [2] http://dev.laptop.org/~erikos/**share/one.jpg<http://dev.laptop.org/~erikos/share/one.jpg>
> ______________________________**_________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.**org <Sugar-devel at lists.sugarlabs.org>
> http://lists.sugarlabs.org/**listinfo/sugar-devel<http://lists.sugarlabs.org/listinfo/sugar-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130503/fe5c1339/attachment-0001.html>