Specifications/Object Transfers: Difference between revisions
Jump to navigation
Jump to search
(→Nice) |
|||
(2 intermediate revisions by one other user not shown) | |||
Line 19: | Line 19: | ||
*Object preview (this might be better than description, if descriptions aren't used to full potential) |
*Object preview (this might be better than description, if descriptions aren't used to full potential) |
||
*progress bar (not strictly needed, if progress is shown only in Journal; definitely wanted if the transfer object persists) |
*progress bar (not strictly needed, if progress is shown only in Journal; definitely wanted if the transfer object persists) |
||
* Roughly the same user interface could be used for printing. The sugar control panel could be used to select a printer from the school server. The printer icon could appear somewhere on the frame. Drags to the printer would result in a printout. |
|||
===Preliminary Mockups=== |
|||
{|style="border: solid 1px gray; margin: 1em auto 1em; auto" |
|||
|- |
|||
| valign="top"| |
|||
[[image: Transfer_incoming.jpg|320px|thumb|center|Incoming object transfer]] |
|||
| valign="top"| |
|||
[[image: Transfer_outgoing.jpg|320px|thumb|center|Outgoing object transfer]] |
|||
| valign="top"| |
|||
[[image: Transfer_error.jpg|320px|thumb|center|Object transfer error]] |
|||
|- |
|||
|} |
|||
==Interaction Spec== |
==Interaction Spec== |
||
Line 30: | Line 44: | ||
# When the transfer finishes, both A and B receive another notification to indicate this. The corresponding Journal entry becomes a standard entry. A's reads "Sent O to B". B's reads "Received O from A". |
# When the transfer finishes, both A and B receive another notification to indicate this. The corresponding Journal entry becomes a standard entry. A's reads "Sent O to B". B's reads "Received O from A". |
||
# Should the transfer cancel or fail, A notification should indicate this. The corresponding Journal entry becomes a standard entry. A's reads "The transfer of O to B (was cancelled | failed)". B's reads "The transfer of O from A (was cancelled | failed)". |
# Should the transfer cancel or fail, A notification should indicate this. The corresponding Journal entry becomes a standard entry. A's reads "The transfer of O to B (was cancelled | failed)". B's reads "The transfer of O from A (was cancelled | failed)". |
||
===Considerations=== |
|||
*We'd like to make the system as robust as possible. It should be possible to resume transfers easily should they be interrupted for any reason |
Latest revision as of 13:36, 31 March 2008
Visual Spec
Information to show
Here I've taken a stab at outlining the information needed for a transfer. In truth I'd like all of this info to be available, but it seems prudent to attempt to separate info required from that which would be really nice to have, to allow us to consider all possible designs. The spaces in which we can show this information are: notification icon, primary icon, primary text, secondary text, and the secondary palette region. Of course, its useful to tell as much as possible with the notification icon itself, without requiring more interaction. It seems the most important thing to convey in the notification icon itself might be identity of the sender/receiver.
Needed
- Sender/Recipient name & colors (either sender or recipient, depending on perspective, not both)
- Object name
- Object icon
- Accept/Decline buttons (anything other useful actions?)
- Type of notification (eg. "transfer", to distinguish from invitations, etc.; could be told by the form (icon), but may be explicit)
Nice
- Sender/Recipient icon (I'd like to show this, but it's secondary to at least representing their color in some manner)
- Object description (it would be nice to have if kids actually use the description field)
- Object preview (this might be better than description, if descriptions aren't used to full potential)
- progress bar (not strictly needed, if progress is shown only in Journal; definitely wanted if the transfer object persists)
- Roughly the same user interface could be used for printing. The sugar control panel could be used to select a printer from the school server. The printer icon could appear somewhere on the frame. Drags to the printer would result in a printout.
Preliminary Mockups
Interaction Spec
Example
- Child A initiates an object transfer by one of the following means: clicking on the send-to button in the Journal toolbar; selecting the send-to option in the palette for a given object; dragging/dropping an object onto the XO icon of a buddy.
- Child A receives a notification. The notification indicates the person who the transfer has been offered to, the object to be transferred (call it O) including type and title, and the option to cancel the transfer.
- Child B receives a notification. The notification indicates the person who initiated the transfer (child A), the object to be transferred (object O) including type and title, and the options to accept or decline the transfer.
- When child B accepts the transfer, a progress segment gets added to the notifications of both A and B. This segment indicates visually the percentage transferred, and offers an approximate time remaining. Additionally, both A and B receive a progress entry in their Journal which indicates the same information that the notification held.
- When the transfer finishes, both A and B receive another notification to indicate this. The corresponding Journal entry becomes a standard entry. A's reads "Sent O to B". B's reads "Received O from A".
- Should the transfer cancel or fail, A notification should indicate this. The corresponding Journal entry becomes a standard entry. A's reads "The transfer of O to B (was cancelled | failed)". B's reads "The transfer of O from A (was cancelled | failed)".
Considerations
- We'd like to make the system as robust as possible. It should be possible to resume transfers easily should they be interrupted for any reason