Specifications/Object Transfers

From OLPC
Jump to: navigation, search

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

Incoming object transfer
Outgoing object transfer
Object transfer error

Interaction Spec

Example

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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".
  6. 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