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

[Mel Chua]

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.