[IAEP] [Sugar-devel] [SoaS] The Future of Sugar on a Stick

[Tomeu Vizoso]

On Fri, Sep 18, 2009 at 05:38, Mel Chua <mel at melchua.com> wrote:
> 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*?

Well, I guess initiatives like Caroline's are a first step into
addressing those needs. The band of geeks that build, test and debug
the .iso are only doing a very small part of the big picture. But
these band of geeks also have to worry about finding the best place to
develop their work and I think this is what Sebastian is trying to do
now. And I think it's SLs role to help him find it, even if at the end
is decided for SoaS to be a project outside SLs.

So Sebastian has asked for two things that he feels are needed to keep
growing the project. We have heard some voices against a new mailing
list, anybody is against creating a more formal structure for the SoaS
development team?

Regards,

Tomeu

> --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.
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning