I read the multiple "future of SoaS" discussions on this mailing list and... to be honest, I was frustrated and didn't quite know how to respond.
So I called my aunt Lynne May (I stay with her family when I'm in Boston). She's been a teacher for over 15 years. She teaches first grade. (I've been showing her Sugar occasionally for the past 2 years, and she thinks it's very cool.) I described this thread to her, explained the situation, and asked for her perspective. The summary of it was: "This discussion you are having, as important as it may be to you, makes no difference to me as a teacher. Here is what does." Here are our notes - written up to the best of my ability, and then read over and edited (and added to) by her. I haven't edited anything out, so it's quite long.. I hope that others will be able to pull out the points that caught their eye, because I am not sure what in here will be most interesting to people. What teachers care about: * Is it friendly? * Is it consistent? * Is it sustainable? What they DON'T care about: * What group "runs" it? * Who owns the trademark? * What bleeding-edge features are being developed now for a future release? * What is the underlying operating system (which they never see)? Let's go into each of these topics in turn. Friendly. Is there a one-stop shop I can go to where my problems will be fixed immediately? Yes, theoretically it's possible to chase down the problem yourself, since everything is open source. And yes, you don't need technical knowledge because eventually, if you keep asking questions and trace things back to the appropriate developers in the appropriate upstreams, you'll likely find someone friendly to fix it for you. However, even if the individual developers are friendly - and we have very friendly, helpful developers - the process is not. Teachers don't have time to chase issues down the rabbit hole. They need to be able to report an issue and then know when that issue will be fixed by, so they know how long they have to improvise for. Consistent. It's important to have the experience be consistent for the kids. "When are we going to do that thing again?" they'll ask. It needs to work - and work the same way - every week. Kids hold you accountable for being consistent. They're in the classroom every single day. Teachers are also in the classroom every single day, and on-call every hour of that day. They also need consistency. Teachers improvise a lot, but they can only do so if they know what tools they have available, and that those tools can be relied upon. They set aside prep time; they have to know that they won't need to spend more than X hours per week to prep for this. If they can't predict how much time it will take to use a tool each week, they won't be able to use it. Tools need to be consistent from day to day, but also from year to year. Will they need to relearn a new toolset next year? She relayed a story about choosing the reading assessment tool the first grade team will use this school year. Should they use the same assessment program used in previous year even if there are missing books in the current set? Or should they switch to a different assessment program. It took them only 20 minutes total to make a decision. They based their decision on the consistency factor, affordability, and immediate response by customer service to their query which helped them solve the problem of having an incomplete assessment kit. The final selection was the same program that was being used in other grade levels, and the same program that was previously used. The takeaway I got from this story is that sometimes it isn't the design of the tool itself that makes it "better" for the classroom - sometimes its the deployability, and a big condition of that deployability is how it fits into the things that other teachers are doing and the other tools the same teacher will be using. Things beyond our control. (And usually beyond theirs.) We have to remember that Sugar will be one of many tools going into a classroom; teachers aren't just going to be deploying Sugar to their kids, they're also going to be deploying this math book, or that reading set, this Spanish programme, that alphabet chart, this counting-blocks set, this easel... And the support experience needs to be consistent. As explained above, teachers need to know that no matter what their problem is, if they spend 2 minutes reporting it at this location, it will be fixed N days later. And as soon as they've spent 2 minutes reporting it, they need immediate feedback and reassurance that yes, it's going to be fixed N days later; you were heard. It's not a fear of learning new things. It's being smart about wanting to know what returns on investment you can expect. It's silly to not know and limit how much it will "cost" (in terms of time) to get an unknown return on a potentially infinite investment. Consistency is a key design value. The reason teachers will choose not to use Sugar is not because the interface isn't quite right. Even if Sugar has a perfect interface and perfect Activities, if the support and deployment experience does not offer teachers consistency so they can offer consistency to their students, teachers will not be able to use Sugar. Teaching can be highly improvisational, but they can only improvise atop something predictable. Some teachers are "textbook-oriented," i.e., they prefer to have a step-by-step guide in teaching so that they can make sure they are "covering all the bases." In this case, they can only teach well if the "textbook" they follow makes sense and is accessible to them. The phrase "nobody ever got fired for buying an IBM computer" comes to mind. (I'm not sure if this is a good sentence to leave in; feel free to delete it if you'd like.) Sustainable. See above comments about being predictable in terms of work-load to deploy. In order to use any tool, teachers need to see an immediate promise - not immediate results, but an immediate promise of results in the basic subjects (since we are talking age 6-12 here) that they are teaching. Teachers have a lot to do. They're willing to try out new things, but they have to know exactly what they're in for, and it has to be stable for a reasonable length of time - a semester, if not a year - if not *multiple* years. And reliable. And responsive. And accountable. Because they need to be reliable and responsive and accountable. What would reassure teachers that SoaS has these three qualities? * Peer support. Being able to talk with other teachers that are using it and sharing stories. "What are you doing?" "How did you fix this problem?" * Seeing it in action. A professional development seminar over the summer that shows you how to use Sugar to teach a particular subject will get it to the "tape recorder" experience level. Story: my aunt bought a tape recorder to use in her classroom. It was a brand she'd never bought before (but one known for being reliable for classroom use). She hadn't seen this tape recorder's interface before, but she was able to, in the middle of a student activity, pull it out for the first time and turn it on and use it for the first time and have it fit seamlessly into the activity without interrupting it. That's what we want Sugar to be able to do. That's what Sugar on a Stick should be able to become. Ubiquitous as a pencil. As flexible and easy to conceptualize improvising with. If she had not been able to figure out to how to use it the first time - if the tape recorder had not worked once - it would have failed. Things must work the first time. But tape recorders are well-known things. There is a mental category for them. Teachers can see them and think about how they would fit these things into the context of their classroom. Because of this, they do not need step-by-step instructions, and this is wonderful. Sugar does not have a similar kind of mental category - how can you envision this fitting into your classroom if you've never seen it in action and don't know how reliable it's going to be? We're used to being able to bridge the gap by throwing in volunteer resources when problems crop up, but on-site volunteer help will not be possible in this situation. Unless you know that person and how they're going to interact with your students, it's hard - even dangerous - to rely on a flux of outside people. So teachers need a steady, knowledgeable resource to go to that is either already employed in their school or not physicall present in their clasrooms (basically, the overhead of getting a new person physically into the school isn't worth it). And that resource needs to know how to draw on a flood of community help when needed. (In the public school and probably some private school setting, tapping the parent community as part of the volunteer pool would be worth considering. The PTO is an active organization and the parents are always looking for ways they can help enrich their children's school experience. Although some schools and teachers would rather keep parents out of the classroom for several reasons, when the kind of help parents offer in the classroom is very specific and understood by both teachers and parents, I think this would be something worth considering as part of deployment team.) The goal of a teacher is to make students into independent learners. If a tool has to be maintained by the teacher constantly, it actively works against that goal ("Lynne May, the screen doesn't work!") because it gives the kids something to be dependent on their teacher for, and it keeps the teachers troubleshooting instead of going around and focusing on learning. This is one perspective on what actual teachers need. It does not speak for all teachers. I can't transcribe it perfectly, but I asked my aunt to go over the text before I sent it to make sure I'm not mis-stating anything, so if it isn't particularly eloquent, it is at least Not Wrong. It helped me get the perspective I needed to recalibrate my sense of What Matters. How do we turn this discussion into something that will help us most easily offer what teachers actually need? What setup, what governance, what environment for *us* will help us make this work for *them*? --Mel PS: I suspect that after a few back-and-forths on this, I will be able to turn it into something shorter and more clearly stated, but right now I am curious whether this helps anybody else see the previous messages in this thread in a different light. _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel