Mel - thanks for this delightful and thoughtful post. I agree with
most of the points you and your aunt raise.
Ben says, about 'Friendly' and 'Consistent':
> These two things sound pretty much the same to me.
> They also sound absolutely impossible, taken strictly.
> Taking a more relaxed interpretation, you seem to be
> describing, in effect, a full-time professional support staff.
I disagree. As Tomeu points out, the SOAS community is organized
around an idea that supports friendliness and consistency. To the
comments that Gnome and KDE don't handle end to end packaging, the
lack of almost any distors that are targeted effectively at these
needs of teachers makes it important for some group to do it.
I would find it a refreshing counterpoint to have a group in this
ecosystem focused on maintaining a toolchain that first prioritizes
the overall teacher and classroom experience, and second prioritizes
hardware, OS, and software details. Some of its core releases /
components / packages (for instance, a new social & procedural system
for getting help or processing feedback) might not involve a single
transistor or line of code.
SJ
On Thu, Sep 17, 2009 at 11:38 PM, Mel Chua <m...@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*?
>
> --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!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
