Changes

m
Line 1: Line 1:  
<div style="background-color: #FFF; margin-left:auto; margin-right: auto; width: 95%;">
 
<div style="background-color: #FFF; margin-left:auto; margin-right: auto; width: 95%;">
<noinclude>{{Translations}}</noinclude>
+
<noinclude>{{Translations}}{{GoogleTrans-en}}</noinclude>
 
{{hig-subnav-intra|p_page=Text and Fonts|c_section=The Sugar Interface|c_page=Toolbars|n_page=Rollovers}}
 
{{hig-subnav-intra|p_page=Text and Fonts|c_section=The Sugar Interface|c_page=Toolbars|n_page=Rollovers}}
    +
[[Image:toolbars.png]]
 +
: See [[Design Team/Designs/Toolbars | Toolbars]] for new design images.
 +
{{TOCright}}
 
===Toolbars===
 
===Toolbars===
   −
[[Image:toolbars.png]]
+
Every activity will have a "Toolbox" at the top edge of the screen.  The Toolbox consists of a set of (at least one) toolbars, individually selectable via the tabs beneath them.  Placement of the tabs beneath the toolbars themselves makes selection of tools and buttons within the toolbars easier according to Fitts' Law, since they will remain against the screen edges where they are "un-missable."  Though this makes the tabs slightly more difficult to activate, we anticipate the frequency with which these toolbars require explicit switching to be minimal, specifically due to their contextual nature as described below.
 
  −
Every activity will have a "Toolbox" at the top edge of the screen.  The Toolbox consists of a set of (at least one) toolbars, individually selectable via the tabs beneath them.  Placement of the tabs beneath the toolbars themselves makes selection of tools and buttons within the toolbars easier according to Fitt's Law, since they will remain against the screen edges where they are "un-missable."  Though this makes the tabs slightly more difficult to activate, we anticipate the frequency with which these toolbars require explicit switching to be minimal, specifically due to their contextual nature as described below.
      
====Grouping by Context====
 
====Grouping by Context====
Line 48: Line 49:       −
'''Undo/Redo:''' The undo/redo commands have extremely high importance on the laptops, since their presence encourages creative exploration without the fear of unrecoverable changes.  They should function in a manner chosen by the activity, and although that manner should reflect our current expectations, the collaborate nature of most activities complicates the matter to some extent.  A broad approach to managing collaborative undos requires a general notion of collisions between editing events.  The [http://www.abisource.com/twiki/bin/view/Abiword/AbiCollab AbiCollab tools] which make the Write activity possible define this idea in detail in relation to text-based editing.  The overall concept applies generally:  For instance, a collision in a drawing activity could mean the collision of the bounding boxes of two drawn shapes.  The secondary rollovers for the "undo" and "redo" buttons contain "undo all" (essentially revert) and "redo all" functionality.  When supported, these controls should be the left-most item in the toolbar.
+
'''Undo/Redo:''' The undo/redo commands have extremely high importance on the laptops, since their presence encourages creative exploration without the fear of unrecoverable changes.  They should function in a manner chosen by the activity, and although that manner should reflect our current expectations, the collaborative nature of most activities complicates the matter to some extent.  A broad approach to managing collaborative undos requires a general notion of collisions between editing events.  The [http://www.abisource.com/twiki/bin/view/Abiword/AbiCollab AbiCollab tools] which make the Write activity possible define this idea in detail in relation to text-based editing.  The overall concept applies generally:  For instance, a collision in a drawing activity could mean the collision of the bounding boxes of two drawn shapes.  The secondary rollovers for the "undo" and "redo" buttons contain "undo all" (essentially revert) and "redo all" functionality.  When supported, these controls should be the left-most item in the toolbar.
   −
'''Copy/Paste:''' Sugar has a fully featured clipboard within the Frame, and as such we want encourage children to copy and paste text, images, or anything else both within and between activities freely .  The copy/paste, reuse, reorganize, modify, and share approach is core to the educational and creative experience that the laptops are designed for.  We've simplified the paradigm, eliminating "cut" command from the top level editing commands.  The distinction between "cut" an "copy" can seem unclear to those unfamiliar with computing, and so we've chosen to embed "cut" functionality in the secondary rollover beneath the "copy" button, and called it "copy and erase."  When present, these controls should be left-aligned, immediately following the undo/redo commands.
+
'''Copy/Paste:''' Sugar has a fully featured clipboard within the Frame, and as such we want to encourage children to copy and paste text, images, or anything else both within and between activities freely .  The copy/paste, reuse, reorganize, modify, and share approach is core to the educational and creative experience that the laptops are designed for.  We've simplified the paradigm, eliminating "cut" command from the top level editing commands.  The distinction between "cut" an "copy" can seem unclear to those unfamiliar with computing, and so we've chosen to embed "cut" functionality in the secondary rollover beneath the "copy" button, and called it "copy and erase."  When present, these controls should be left-aligned, immediately following the undo/redo commands.
    
'''Find/Replace''' Wherever
 
'''Find/Replace''' Wherever
Line 80: Line 81:     
{|border=1 cellpadding=3 cellspacing=0 style="font: 9px 'Helvetica'; color: #FFF; border: 2px #fff solid; border-collapse: collapse; background: #404040; width: 800px; height: 60px;"
 
{|border=1 cellpadding=3 cellspacing=0 style="font: 9px 'Helvetica'; color: #FFF; border: 2px #fff solid; border-collapse: collapse; background: #404040; width: 800px; height: 60px;"
 +
!style="width: 60px;"|< Zoom Out
 
!style="width: 60px;"|< Zoom In
 
!style="width: 60px;"|< Zoom In
!style="width: 60px;"|< Zoom Out
   
!style="width: 60px;"|< Show Grid
 
!style="width: 60px;"|< Show Grid
 
!style=" width: 60px;"|< Show Rulers
 
!style=" width: 60px;"|< Show Rulers
 
!| [ Custom View Controls ]
 
!| [ Custom View Controls ]
!style=" width: 60px;"| Hide Toolbar >
+
!style=" width: 60px;"| Hide Toolbox >
 
|}
 
|}
   Line 93: Line 94:  
!style="width: 60px;"|< Insert Object
 
!style="width: 60px;"|< Insert Object
 
!|[Custom Controls]
 
!|[Custom Controls]
!style="width: 120px;"| Annotation Controls >
+
!style="width: 60px;"| Add Bookmark >
 
|}
 
|}
    +
=====Inserting Objects=====
 +
 +
Many custom toolbars will provide controls useful in editing contexts which don't always exist by default.  The Table Toolbar within the Write activity is a good example of this: Until a table has been inserted into a document, there is no "table context" within which to edit.  Of course, once there is one, the Table Toolbar will be automatically selected whenever the table is selected.  Since the act of inserting the corresponding object creates the context that the toolbar associates with, this control should always appear first within the toolbar.  The Icon guidelines provide further information on the visual style for insert buttons.
 +
 +
=====Bookmarking=====
 +
 +
We hope to encourage discussion, iteration, and sharing on the laptops, and so we hope to encourage the idea of annotation across many different activities.  When activities support textual annotations, highlighting, or other complex forms, they should have an Annotation Toolbar containing all of these features.  Some activities, especially early on before a system-wide annotation system exists, may simply like to implement basic bookmarking.  Though we hope to implement bookmarking as a subset of the annotation model, this particular feature is essential to some activities, and can be implemented in simpler ways in the meantime.  When bookmarking exists as a single action within an activity, it should be placed to the far right of any custom toolbar which seems appropriate.
    
====Hiding Toolbars====
 
====Hiding Toolbars====
Line 103: Line 111:  
=====Soft Hiding=====
 
=====Soft Hiding=====
   −
Most activities should use soft-hiding, which means that although the Toolbox will be hidden completely from view, it will still be accessible by moving the cursor to the top edge of the screen, provoking it to slide out and exposing the controls.  This works great for casual or turn-based games, as well as any games which don't require the mouse.  In these instances, the ability to access preferences, share or invite friends to the activity, start a new game, and of course exit the activity remains available at all times.  This is also useful for presentation modes, such as slideshows, allowing the child to access the bar to perform operations such as next, back, and of course stop slideshow, thus showing the toolbar permanently again.
+
Most activities should use soft-hiding, which means that although the Toolbox will be hidden completely from view, it will still be accessible by moving the cursor to the top edge of the screen, provoking it to slide out and exposing the controls.  This works great for casual or turn-based games, as well as any games which don't require the mouse.  In these instances, the ability to access preferences, share or invite friends to the activity, start a new game, and of course exit the activity remains available at all times.  This is also useful for presentation modes, such as slideshows, allowing the child to access the bar to perform operations such as next, back, and of course stop slideshow, thus showing the toolbar permanently again.  When a soft-hidden toolbar slides into view, it slides in on top of the activity view beneath, eliminating the need to reflow the content; When hiding is turned off, it again embeds itself within the view, thus shifting the content downward.
    
When the sole purpose for hiding the Toolbox is to provide additional screen area for viewing or editing, a control within the View Toolbar should provide this option.  Activities should not automatically invoke soft-hiding for this purpose (unless the aforementioned toggle is stored as a preference in the selected state).  Though the laptops have a small viewable screen area, the choice to hide potentially frequently used controls should be left to the children.
 
When the sole purpose for hiding the Toolbox is to provide additional screen area for viewing or editing, a control within the View Toolbar should provide this option.  Activities should not automatically invoke soft-hiding for this purpose (unless the aforementioned toggle is stored as a preference in the selected state).  Though the laptops have a small viewable screen area, the choice to hide potentially frequently used controls should be left to the children.
Line 113: Line 121:  
Activities which make use of the entire screen, and moreover require active cursor movement across it, may wish to hide the Toolbox completely from view, eliminating the possibility that it could be invoked at the screen edge via the mouse.  Hard-hiding allows activities to do this.  The primary use case for this mode is action games which could be interrupted accidentally during gameplay.  As such, these guidelines are written with respect to a fullscreen game, but their principles should carry over to other uses activity developers may find.
 
Activities which make use of the entire screen, and moreover require active cursor movement across it, may wish to hide the Toolbox completely from view, eliminating the possibility that it could be invoked at the screen edge via the mouse.  Hard-hiding allows activities to do this.  The primary use case for this mode is action games which could be interrupted accidentally during gameplay.  As such, these guidelines are written with respect to a fullscreen game, but their principles should carry over to other uses activity developers may find.
   −
Hard-hiding removes all access to the Toolbox for an extended period of time, and therefore should only be used within activities which don't have their own toolbars.
+
Hard-hiding removes all access to the Toolbox for an extended period of time, and therefore should only be used within activities which don't have their own toolbars.  Also, since hard-hiding eliminates any means of invoking the Toolbox, the activity must always provide any of the basic functionality otherwise contained within the Activity Toolbar itself.  Any game which supports networked play over the mesh should always provide a way for the initiator to name the instance.
   −
Since hard-hiding eliminates any means of invoking the Toolbox, the activity must always provide another way to return to it.  To remain consistent with soft-hiding mode and with general expectations, the escape key should always provide a mechanism for doing so, even if another means exists.  The escape key could immediately exit the game, returning to an intro screen where the Toolbox can be shown, but it will more likely pause the game and reveal a menu containing an option to do so.
+
To remain consistent with soft-hiding mode and with general expectations, the escape key should always provide a mechanism for exiting the game, even if another means exists.  The escape key could immediately exit the game, returning to an intro screen, but it will more likely pause the game and reveal a menu containing an option to do so.
    
{{hig-subnav-intra|p_page=Text and Fonts|c_section=The Sugar Interface|c_page=Toolbars|n_page=Rollovers}}
 
{{hig-subnav-intra|p_page=Text and Fonts|c_section=The Sugar Interface|c_page=Toolbars|n_page=Rollovers}}
 
</div>
 
</div>