On 05/03/2013 02:26 PM, Gonzalo Odiard wrote:
On Thu, May 2, 2013 at 12:50 PM, Simon Schampijer <si...@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
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
