| Line 7: |
Line 7: |
| | ===Sugar Digest === | | ===Sugar Digest === |
| | | | |
| − | I encourage you to join two threads on the Education List this week: [http://lists.sugarlabs.org/archive/iaep/2009-April/005382.html "math instruction"], which has boiled down to an instruction vs construction debate; and [http://lists.sugarlabs.org/archive/iaep/2009-April/005342.html "70 minute interview with Bryan Berry on XO deployment in Nepal"], which has boiled down to a debate of catering to local culture vs the Enlightenment. I encourage you to join these discussions.
| + | The [http://lists.sugarlabs.org/archive/iaep/2009-May/005593.html discussion about pedagogy] on the IAEP list intensified this week. My takeaway from the discussion is that while we won't (and don't need to) reach consensus about "one right way" to teach, we must have consensus around our goals as a community or our efforts will become too diffuse to be of any practical use; we are not engaged in an academic exercise—we are touching the lives of real children on a global scale. Indeed, the primary reason we spun One Laptop per Child from MIT (and Sugar Labs from One Laptop per Child) is because we intend to deliver "things to think with" to learners everywhere. |
| | | | |
| − | Rather than commenting here, I want to discuss a third, orthogonal topic: creativity. I hosted a visit to Cambridge this week from Diego Uribe, a Chilean researcher who is currently a Fulbright scholar at the International Center for Studies in Creativity in Buffalo, NY. Diego challenged me with two questions: Can we be more deliberate in developing children's creativity skills and how can we use Sugar to better disseminate creativity heuristics?
| + | As a community, we have consensus that Sugar and Sugar activities should be freely and readily available to learners everywhere. This would suggest that the developer community continues to strive to make it “simple” to create and share Sugar activities and its efforts to create versions of Sugar that run on multiple operating systems and on multiple hardware platforms. |
| | | | |
| − | Diego is of the belief that creativity is a skill that can be taught; there has been more than 50 years of research into how to teach this skill; and yet creativity is rarely a deliberate part of mainstream education.
| + | But what is Sugar? At one level, Sugar is an API that provides a unified framework for activity developers to support collaboration, reflection, and sharing in their programs. But those features were chosen with a purpose: to encourage learners to engage in authentic problem-solving and a critical dialogue about whatever problem in which they are engaged. This engaged, learners will develop skills that help them in all aspects of life. |
| | | | |
| − | Diego introduced me to Ruth Noller's formula for creativity that I had not previously encountered: The probability of creativity is a function of knowledge, innovation, and experience, modulated by attitude. In this formulation, attitude is often the weak link.
| + | Sometimes that dialog is with your peers, sometimes it is with a teacher or mentor. Sometimes it is open-ended and sometimes it is within the context of structured instruction. In every case, it involves expressing, debugging, critiquing, and reflecting. In every case, it is enhanced by "the hard things to learn", Alan Kay's "non-universals", e.g., reading and writing; deductive abstract mathematics; model-based science; etc. |
| | | | |
| − | Central to his own vision of teaching creativity as a skill is the ability to strike the proper balance between divergent and convergent thinking.
| + | The culture of FLOSS, with its emphasis on ''en plein air'' debugging and critique, is part of our pedagogy. Sugar embodies the message that everyone has an opportunity and responsibility to contribute to our knowledge commons. That contribution need not be Python code. Members of the Sugar community must: |
| | | | |
| − | Guidelines for divergent thinking
| + | * explore, share, evaluate, and debate best practices; |
| − | * defer judgment
| + | * provide technical and pedagogical support; and |
| − | * go for quantity | + | * create new learning activities and pedagogical practice. |
| − | * make connections | |
| − | * seek novelty | |
| | | | |
| − | Guidelines for convergent thinking
| + | ---- |
| − | * apply affirmative judgment
| |
| − | * keep novelty alive
| |
| − | * check your objectives
| |
| − | * stay focused
| |
| − | | |
| − | (I was reminded of David Reed's analogy to water and ice: innovation occurs in its liquid phase; consolidation in its solid phase.)
| |
| − | | |
| − | Diego was "preaching to the choir." When I was director of the Media Lab, I never told the students or faculty what to work on—their ideas were always much better than mine—but I did insist on a creative (learning) process that I described in a paper, [http://www.media.mit.edu/publications/bttj/ForwardPages5-6.pdf "The seven secrets of the Media Lab"].
| |
| − | | |
| − | :The phases of the moon represent the cyclical process of innovation at the Media Lab. In the 1980s we used to describe the first phase of the innovation cycle as ‘demo or die’. John Maeda rephrased our mantra in the late 1990s to be ‘imagine and realize’. Indeed, it is a violation of our cultural norm to have an idea and not build a prototype — in large part because of our deeply-held belief that we learn through expressing. Building a prototype also enables us to advance to the second phase of the innovation cycle — critique. The Lab, which has its origins in architecture (the founder of the Media Lab, Nicholas Negroponte, is an architect) draws upon the tradition of studio design critique; we have daily visits from our industry partners and other practitioners with whom we engage in an authentic critical dialogue about the work. In this exchange, the work is discussed within a broader context — ideas (and prototypes) are exchanged, improvements and alternatives suggested. We then advance to the third phase of the innovation cycle — iterate. Iteration within the Lab means returning to ‘Step One’ to push our ideas further. Iteration within our partners’ organizations means taking a prototype towards real-world application. In both cases, we can learn from our mistakes (and successes).
| |
| − | | |
| − | Another secret is fire:
| |
| − | | |
| − | :Fire fuels the Media Lab. We invest in the passion of people, not their projects. It is the fire that burns in every student and faculty member that inspires and motivates them — love is a better master than duty. Innovation at the Lab comes from the bottom up. It is not regulated by a top-down process, but by continuous feedback from peers, the faculty, and our external collaborators.
| |
| − | | |
| − | These principles proved affective at MIT in establishing a learning community that is both collaborative and critical. These same principles were an influence on the design of Sugar; however, we can probably do more to embody them directly into Sugar itself.
| |
| − | | |
| − | Diego and I spent the next two hours exploring how we might make the creative process more explicit in Sugar. He suggested that we consider two common, approachable heuristics in our deliberations—SCAMPER and PPCo.
| |
| − | | |
| − | SCAMPER is a technique developed by Alex Osborn, described in his book Applied Imagination. SCAMPER is an acronym for "substitute, combine, adapt, modify, put to another use, eliminate, reverse." It is used for encouraging divergent thinking.
| |
| − | | |
| − | PPCo is also an acronym: "positives, potentials, concerns, overcoming concerns." It was developed by Roger Firestien and Diane Foucar-Szocki; it is used for convergent thinking.
| |
| | | | |
| − | What follows is a brief summary of our using a small sampling of the SCAMPER and PPCo methods.
| + | Roland Gesthuizen, replying in [http://lists.sugarlabs.org/archive/iaep/2009-May/005637.html a different thread] had a concrete set of suggestions for teacher participation in our community: |
| | | | |
| − | ----
| + | * report back issues that make using the Sugar interface difficult when used it in the classroom (collaborate) |
| | + | * develop and share lessons built around applications that work on Sugar (curriculum) |
| | + | * share by word of mouth, blog and twitter with colleagues that we are using Sugar (communication) |
| | + | * ask deep and hard questions about the learning that goes on when students use Sugar (pedagogy) |
| | + | * work to answer these questions (research) |
| | + | * and more... |
| | | | |
| − | We started by focusing on "Substitute" as our divergent thinking technique. We set a goal of coming up with at least five ideas (quantity) as we thought about replacing parts of Sugar with alternatives; making changes to the Journal, adding a new Sugar component, or coming up with lesson plans to suggest the use of Sugar in some more creative ways. Some of our ideas included: making a SCAMPER example from an existing activity; making SCAMPER "cards" with helper questions for each activity (in the spirit of Squeak Cards); creating a math example where we ask students to come up with multiple proofs, multiple uses, and multiple implications of each new concept; a peer-edit extension to the Write activity where the editing is focused on a SCAMPER activity; a template for the Portfolio that would encourage the use of SCAMPER to expand upon work in the Journal; using SCAMPER and PPCo to organize the bulletin board; a SCAMPER activity; SCAMPER channels in IRC; SCAMPER tags in the Journal; inter-generational SCAMPERing; a SCAMPER visualization of Journal content; and a version of sharing where those who join an activity engage in a SCAMPER or PPCo activity.
| + | ===Help Wanted=== |
| | | | |
| − | We then used PPCo to critique our ideas, using some stock questions to organize our convergent thinking activity: "How to?", "In what ways might we?", "How might I?", "What are all the ways to?" | + | In the run up to [[Sugar_on_a_Stick/Roadmap|the next Beta release of Sugar on a Stick]] Sebastian Dziallas has asked for help with testing all of the activities being considered for inclusion. We'd like to be more thorough in finding any problems so that we can be sure to address them in time for the final release in September/October. There is also a [http://dev.sugarlabs.org/query?status=accepted&status=assigned&status=new&status=reopened&component=SoaS Trac query] that pulls up all |
| | + | of the open tickets for SoaS. |
| | | | |
| − | We itemized the positives of embodying SCAMPER into to sample Sugar activities:
| + | ===In the community=== |
| − | * They would easy and quick to prototype;
| |
| − | * They would not be content specific;
| |
| − | * They would be an easy way to get the community to test the idea;
| |
| − | * Anyone can do it;
| |
| − | * It would be easy to share the results;
| |
| − | * They would give us a simple framework for evaluating the idea.
| |
| | | | |
| − | We also itemized the potentials of embodying SCAMPER into to sample Sugar activities:
| + | The [http://sugarcamp.eventbrite.com/ OLPC France Sugar Camp meeting] will be held in Paris on May 16. |
| − | * It might lead to some general principles in Sugar;
| |
| − | * It might lead to teachers reassessing their assessments;
| |
| − | * It might lead to more useful collaboration;
| |
| − | * It might make things more fun and more social;
| |
| − | * It might lead to more sharing and collaboration;
| |
| − | * it might promote more mentoring.
| |
| | | | |
| − | And we did some exaggerating:
| + | There will also be a Sugar meeting on the 17th (See [[Marketing_Team/Events/MiniCamp_Paris_2009|Paris Sugar meeting]]). |
| − | * It might lead to more learning;
| |
| − | * It might lead to authentic problem-solving;
| |
| − | * It might lead to a world of SCAMPERing;
| |
| − | * It might lead to a world of learning to learn;
| |
| − | * SCAMPER combined with Portfolio assessment might make standarized testing obsolete.
| |
| | | | |
| − | We listed some concerns:
| + | A team of Babson College management students will be working with Sugar Labs beginning this fall as part of a Management Consulting Field Experience (MCFE) Program. |
| − | * What might be a way to keep SCAMPERing fresh?
| |
| − | * In what ways might we visualize progress?
| |
| − | * How might we integrate SCAMPER with the Portfolio?
| |
| − | * In what ways might we tell the SCAMPER story?
| |
| | | | |
| − | And we listed some ways we might overcome one of our concerns: In what ways might we tell the SCAMPER story?
| + | ===Tech Talk=== |
| − | * Case study: e.g., a SCAMPERized English class;
| |
| − | * Stand on the work of SCAMPERers who have come before us;
| |
| − | * Conduct a controlled experiment;
| |
| − | * Sketch out specific Sugar examples;
| |
| − | * Create some videos of SCAMPER in action;
| |
| − | * Create an immersive SCAMPER experience ("show, don't tell");
| |
| − | * Create a SCAMPER Mindmap;
| |
| − | * Create a SCAMPER portfolio.
| |
| | | | |
| − | Finally, we made an action plan:
| + | Christian Schmidt led a [http://meeting.laptop.org/sugar-meeting.log.20090509_1013.html Design Team meeting] this weekend that covered topics such as improvements to the Home View, a clock extension on the Frame; support for printing within Sugar; a global strategy for keyboard shortcuts; and a global dictionary. |
| − | * Short term: research for SCAMPER examples; blog about SCAMPER to the community; create a portfolio template; make a sketch of a Journal template; and introduce SCAMPER at Sugar Camp.
| |
| − | * Medium term: create a SCAMPER Sugar challenge; and get SCAMPERized Sugar into the hands of teachers and learners.
| |
| − | * Long term: having creativity principles materialize in Sugar.
| |
| | | | |
| − | The choice of SCAMPER and PPCo were somewhat ad hoc. Nonetheless, I came away from my morning with Diego convinced that we can embody some creativity principles into Sugar to great effect. | + | The [http://wiki.laptop.org/go/Food_ForceII Food Force team] has a new release and is looking for feedback. Download the .xo bundle from [http://code.google.com/p/foodforce/downloads/list here]. |
| | | | |
| | ===Sugar Labs === | | ===Sugar Labs === |
| | | | |
| − | Gary Martin has generated a SOM from the past week of discussion on the IAEP mailing list (Please see [[:Image:2009-April-25-May-1-som.jpg|SOM]]). | + | Gary Martin has generated a SOM from the past week of discussion on the IAEP mailing list (Please see [[:Image:2009-May-2-8-som.jpg|SOM]]). It is worth a close look this week. |
| − | | |
| − | The SOM for the entire month of April is [[:Image:2009-April-Sugar_devel_som.jpg|here]].
| |
| | | | |
| | === Community News archive === | | === Community News archive === |