[schooltool-dev] Configuration issues for schools
djgroos at gmail.com
Sat Feb 7 16:36:11 UTC 2009
Hi Tim Tom,
I can't speak to coding issues, but as a teacher who is starting to delve
into open source education software, the biggest needs are:
--assessment ie reporting and customization capabilities (I see that student
x can do this so her next step is to...). In other words a great need is
for time-efficient, methods of assessing individual skills/knowledge and
fine-tuning what they do next.
--While there are many great things about LDAP, the problem with it is that
if a teacher is in a school where those who control the keys to technology
don't want to support the teachers, it's tough luck for the teacher if an
LDAP is required. An option for w/-w/out LDAP would be nice.
--Stand alone apps are an important nitch as are web apps that students can
access via a browser or some way of collaboration :-) Things like FLE3
http://en.wikipedia.org/wiki/Fle3 (like SchoolTools is based on Zope) and
the free but not open source CmapTools that has a CmapServer component
providing multiple simultaneous internet access. Google Docs is great like
this, too. These collaborative tools are also part of the solution that can
support taking students to the next level.
On Sat, Feb 7, 2009 at 9:49 AM, Tom Hoffman <tom.hoffman at gmail.com> wrote:
> Hi Tim,
> I'm the project manager for SchoolTool, and I've worked a lot on
> interoperability issues between applications used in schools.
> Regarding SchoolTool & different platforms, SchoolTool is Python, it
> is fairly easily ported to other platforms that run Python. The only
> problem is that we (the core development team) don't have the
> expertise to support multiple OS versions, particularly as we have to
> focus on finishing our 1.0 release.
> I'm a little confused about what you're proposing for configuration.
> The standard way to address your use case is via web services or
> perhaps LDAP. There are a few directly relevant existing standards
> (SIF...) but none that are widely used, particularly by free software.
> or generally appealing.
> Actually, at this point, I'd say storing the data you want in LDAP is
> probably the approach most likely to work. The coolest way to do it
> would be passing around the relevant data via XMPP.
> On Sat, Feb 7, 2009 at 8:26 AM, Tim Holy <tim.holy at gmail.com> wrote:
> > Hi,
> > I'm one of the main developers for TuxMath, part of Tux4Kids. This is a
> > proposal that I've floated with GCompris, KDE-Edu, and discussed a bit
> > several folks on the #edubuntu IRC. This message is a modified version of
> > message I posted to some of the other lists recently, so if you've seen
> > then you pretty much know the contents of this message.
> > Over the last year we've begun to think about some issues in making
> > more useful for schools. As you probably know, TuxMath is an arcade game
> > that helps kids practice math facts. Teachers are using it, and several
> > expressed interest in being able to configure, track, and otherwise
> > administer classrooms of kids using the program. Adding these
> > will involve much that is TuxMath-specific, but in thinking about the
> > problem I've come to the conclusion that this work should probably start
> > with a foundation---mostly, a set of standards---that might be used by
> > different free software projects.
> > To be concrete, here are a few examples of some of the kinds of things we
> > might want to support in TuxMath:
> > 1. Letting teachers set particular lesson files for kids to tackle that
> > on a class-wide basis but with the ability to further customize lessons
> > particular students or groups of students
> > 2. Letting teachers see how kids in their own classroom are doing on the
> > lessons
> > 3. Managing "high scores" files by grade or classroom (we don't want 5th
> > graders competing against 2nd graders)
> > The part of this that I think will be easiest to generalize across
> > is really quite simple: implementing these tasks in a sensible way
> > a method for expressing relationships in a school. In particular, we need
> > specify the different grades, the different classrooms, and the kids
> > each classroom. This, therefore, is a "system-wide" issue of
> > and not one that teachers or sysadmins will appreciate having to set up 5
> > different times in 5 different ways for 5 different free software
> > Hence my interest in a set of standards.
> > I see two main components to this proposal. One is that there needs to be
> > software to create and administer these relationships. It's been
> > to me that SchoolTool might be appropriate for this purpose. However,
> > note that at Tux4Kids we support Windows & Mac too, so any solution
> > for us is going to have to be quite general and not
> > (SchoolTool seems to be web-based, but is currently only easy to install
> > Ubuntu?).
> > The second component would probably be a small library that facilitates
> > ability of individual applications (TuxMath, Tux Paint, GCompris
> > etc) to work with this information.
> > In terms of implementation: one of the challenges is that, at least in
> > US, many schools seem to run without any individual student accounts. In
> > other words, all students log in to an account called "Student" that
> > require a password. So we need to set this up in a way that all the
> > data does not get jumbled together. On the other hand, when schools do
> > up "real" user accounts, we want to make use of that.
> > I've set up a preliminary architecture for some of this within TuxMath
> > it will need modifying/generalizing if this is of general interest). For
> > better or for worse, I've established a directory hierarchy on the school
> > server:
> > school/
> > school/Kindergarten/
> > school/Kindergarten/Mrs. Smith/
> > school/Kindergarten/Mrs. Smith/Kid A/
> > school/Kindergarten/Mrs. Smith/Kid B/
> > school/Kindergarten/Mrs. Smith/Kid C/
> > ...
> > school/Kindergarten/Mr. Jones/
> > school/Kindergarten/Mr. Jones/Kid 1/
> > school/Kindergarten/Mr. Jones/Kid 2/
> > ...
> > school/1st grade/
> > ...
> > For schools without real user accounts, these directories serve as a mock
> > home directory (without any kind of security) for the kids, where their
> > specific data gets saved. In cases where the students do have real home
> > directories, the lowest level could of course be symlinks (on Unix
> > to their real home directories.
> > Our tools for administering these directories are quite primitive at the
> > moment---a command-line program (NOT teacher-friendly!) called
> > The advantage of this hierarchy is that it establishes a natural
> > for expressing relationships among the different members of the school,
> > so programs can then find classroom-wide configurations, etc. For
> > it is natural to "read up" or "read down" when you're looking for
> > configuration files. If two of the 4th-grade teachers decide they want
> > kids to have a joint high-scores table, they place a "highscores.txt"
> > in the 4th grade directory. But if another 4th-grade teacher wants her
> > just to compete among themselves, she can place a highscores.txt file in
> > own directory, and for the kids in her class the application will default
> > using that file.
> > This is not unrelated to the XDG specification (thanks Jordan for
> > me to this), although the various paths might have to be set dynamically
> > cases where there are no real home directories. (For example, we allow
> > TuxMath to be configured so that students can select their identity when
> > they start the program. Perhaps we might want a common login system that
> > then sets up XDG-paths before starting a specific application?)
> > Is this something of potential common interest? Any other parties that I
> > should include in this discussion?
> > Best wishes,
> > --Tim
> > _______________________________________________
> > Schooltool-dev mailing list
> > Schooltool-dev at schooltool.org
> > http://lists.schooltool.org/mailman/listinfo/schooltool-dev
> edubuntu-devel mailing list
> edubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the edubuntu-devel