On Wed, Mar 16, 2011 at 5:05 PM, Simon Schampijer <<a href="mailto:simon@schampijer.de" target="_blank">simon@schampijer.de</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> On 03/14/2011 11:28 AM, Gary Martin wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Hi Simon, On 10 Mar 2011, at 17:16, Simon Schampijer wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> One of the major functionality in activities is creating and/or modifying, for example creating a new game in Memorize a new abacus in the Abacus activity and so on. I am wondering what would be a good icon to use for that. I have seen the use of a scissor (like editing an activity), or the gear like we use in 'view source'. Any other ideas? And then it would be great if we could set on one and be consistent in activities and use the same icon in all of them. </blockquote> Thanks for raising this, I've added this topic to next weeks Design Team meeting, I'll try and get a few mockups together before then: <a href="http://wiki.sugarlabs.org/go/Design_Team/Meetings" target="_blank">http://wiki.sugarlabs.org/go/Design_Team/Meetings</a> </blockquote> Great - thanks! /me loves the progress we have in design meetings over the last weeks - all thumbs up! <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Some misc. thoughts regarding using the existing scissor/edit tool and secondary palette. Pros: * existing Activity edit secondary toolbars usually have only copy, paste, sometimes also undo& redo (so there is usually plenty of UI space) * no need to add yet another primary toolbar widget (less complex primary UI and/or space for other tools) * Sugar design model, editing is what you do during an activity to change it, 'creating new' activities should be done before an Activity begins (e.g. home --> start new, and/or proposed Journal duplicate feature).</blockquote> </blockquote><div> What is the origin of this 'should be done before an Activity begins'? This feels like a low ceiling and confining work/play space for our bold new environment. The tools might better be available when the inspiration arrives, such as in the midst of Activities. </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">BTW, Think it is OK for an Activity to support clearing/erasing/reseting state (such as Paint, Memorize), though ideally with reliable undo or versioning support to help prevent accidental data loss. </blockquote> All valid points. <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Cons: * overloading an existing UI category (traditional OS users have certain expectations for an edit menu)? * will folks overlook the edit sub-palette and miss the extra modification features? </blockquote> I fear mostly that - that people will not find that option for several reasons :/</blockquote><div> Please examine this 'fear' for us more. Shouldn't the Sugar Learning Environment strive to transition 'traditional users' into Sugar Learners by subtly exposing them to new tools and perspectives? As for the new Sugar Learner, should we not bias them with the older 'traditional', less free, pre-Sugar concepts, but carefully provide them greater freedom, such as to be able to edit not just a single instance, but a whole class, and even the environment. We may need to learn how to carefully provide such freedom, but the Etoys developers may have some experience to share. One advantage we have to maintain with Sugar is its clarity of purpose for environmental elements. This comes partly from simple and evocative icons, but also from consistency of the interface and system behavior, such that the learner is quickly exposed to patterns that reinforce a mental model of the system (and hopefully there are no or few aberrations to the intended design consistency that can easily prevent a mental model from forming). Gary's new game icons nicely fit this model because it is clear by the character of the icon that a new 'Memorize' game is the object to be edited. The general class of edit controls (under this proposal for our bold new Sugar environment) might best be represented by a variation of the the 'Source/gear' icon. As has been noted, the edit toolbars are lightly used, so there is room to design for the new capabilities. The scissors icon can de-generalized to cutting actions, and other, situation-suitable edit actions can be exposed or included as appropriate to the Activity designer. Some Activities are intended to serve primarily as editors. A single edit toolbar is inappropriate in these situations, where the primary edit actions need to be directly available. See for example, <a href="http://wiki.laptop.org/go/User:Godiard/Record/NewToolbar" target="_blank">http://wiki.laptop.org/go/User:Godiard/Record/NewToolbar</a> Pippy's primary toolbar would be improved if it contained the edit actions cut, copy, paste, undo, redo, along with clear in a section after the Run/Stop buttons (which might better be a toggle pair). It should be possible to create and save new scripts with a Source/gear icon/subtoolbar that would enter the new script in the Examples tree. The new script could then be dragged into one of the categories/tags and exported as text or copied to a new Pippy instance. Thanks for considering! --Fred </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> But you are right in that using another icon has issues space wise. Let's see maybe there are other options we have not thought about yet...:) Regards, Simon _______________________________________________ Sugar-devel mailing list <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </blockquote></div>