102
edits
Changes
Jump to navigation
Jump to search
Line 191:
Line 191: − + Line 204:
Line 204: − + Line 224:
Line 224: − +
→Sugar on the Ground
|-
|-
!valign=top | [[File:Journal.png|90px|thumb|center]] ||valign=top width="15%" style="background:#e3e4e5;" | Sugar Journal save option ||valign=top width="15%" | Tony Anderson ||align=left valign=top|
!valign=top | [[File:Journal.png|90px|thumb|center]] ||valign=top width="15%" style="background:#00bb00;" | Sugar Journal save option ||valign=top width="15%" | Tony Anderson ||align=left valign=top|
The Sugar Journal should provide a 'save/save as' interface which should enable a user to choose whether to save the current document when an activity is closed. The interface should require a name change from 'current.activity' to a user supplied name. If the document is derived from one currently saved in the Journal, the user should be allowed to save (overwrite) or save as (create new document) by giving a new name to the document. This could be accomplished by showing a modal dialog at close time requesting the user to supply a name or not save the document. If the document has a user supplied name, the dialog could request the user to save or to provide a new name to create a new document.
The Sugar Journal should provide a 'save/save as' interface which should enable a user to choose whether to save the current document when an activity is closed. The interface should require a name change from 'current.activity' to a user supplied name. If the document is derived from one currently saved in the Journal, the user should be allowed to save (overwrite) or save as (create new document) by giving a new name to the document. This could be accomplished by showing a modal dialog at close time requesting the user to supply a name or not save the document. If the document has a user supplied name, the dialog could request the user to save or to provide a new name to create a new document.
|-
|-
!valign=top | [[File:Journal.png|90px|thumb|center]] ||valign=top width="15%" style="background:#e3e4e5;" | Sugar Journal backup and restore ||valign=top width="15%" | Tony Anderson ||align=left valign=top|
!valign=top | [[File:Journal.png|90px|thumb|center]] ||valign=top width="15%" style="background:#00bb00;" | Sugar Journal backup and restore ||valign=top width="15%" | Tony Anderson ||align=left valign=top|
Sugar provides a method to backup and restore the Journal (one method to a USB key and one method to the school server). The Journal also provides a select box to enable an action to be taken for all selected objects. This mechanism should be sufficient for the USB key case. However, the school server backup currently is based on taking a snapshot of the current Journal state. This means the size of the objects in a user's Journal cannot exceed the available local store on an XO (300MB for an XO-1, 1.9GB for other models). A mechanism is needed to save on the school server all documents created by the user and to restore a selected object to the Journal from the school server. Since many documents may represent library objects (e-books, audio, image or video media), the mechanism should recognize these and not save them as user documents. However, the metadata saved should enable the system to download the library items again as needed (and, as available).
Sugar provides a method to backup and restore the Journal (one method to a USB key and one method to the school server). The Journal also provides a select box to enable an action to be taken for all selected objects. This mechanism should be sufficient for the USB key case. However, the school server backup currently is based on taking a snapshot of the current Journal state. This means the size of the objects in a user's Journal cannot exceed the available local store on an XO (300MB for an XO-1, 1.9GB for other models). A mechanism is needed to save on the school server all documents created by the user and to restore a selected object to the Journal from the school server. Since many documents may represent library objects (e-books, audio, image or video media), the mechanism should recognize these and not save them as user documents. However, the metadata saved should enable the system to download the library items again as needed (and, as available).
;For example: the mechanism may be to upload Journal documents to an OwnCloud repository. The user could then select an item in the OwnCloud repository to be downloaded to the Journal. The user could also share any item in OwnCloud with other user groups or individuals
;For example: the mechanism may be to upload Journal documents to an OwnCloud repository. The user could then select an item in the OwnCloud repository to be downloaded to the Journal. The user could also share any item in OwnCloud with other user groups or individuals
|-
|-
!valign=top | [[File:Journal.png|90px|thumb|center]] ||valign=top width="15%" style="background:#e3e4e5;" | Sugar Journal activity resume feature ||valign=top width="15%" | Tony Anderson ||align=left valign=top|
!valign=top | [[File:Journal.png|90px|thumb|center]] ||valign=top width="15%" style="background:#00bb00;" | Sugar Journal activity resume feature ||valign=top width="15%" | Tony Anderson ||align=left valign=top|
In Sugar's Home View, a click on an activity icon by default resumes the most recent instance of the activity. This capability is designed into the Journal and is redundant in the Home View. A Sugar activity is a tool to enable the user to accomplish some task. If that task is not completed, the user can resume it via the Journal. If the tool is to be used on a new task, the user can launch it from the Home View. The current Home View assumes that the intent of the user is to continue the most recent task with that tool.
In Sugar's Home View, a click on an activity icon by default resumes the most recent instance of the activity. This capability is designed into the Journal and is redundant in the Home View. A Sugar activity is a tool to enable the user to accomplish some task. If that task is not completed, the user can resume it via the Journal. If the tool is to be used on a new task, the user can launch it from the Home View. The current Home View assumes that the intent of the user is to continue the most recent task with that tool.