schooltool-developers team mailing list archive

["Tom Hoffman" <tom.hoffman@xxxxxxxxx>]

Hm... this is the kind of thing we've found gets REALLY hard to follow
across national borders, because everyone's so used to the way their
local system works lots of assumptions get lost.  So let me try to
take a step back.

I like the structure of your spreadsheet because it seems closer to
the format schools would actually have and use already.

One BIG advantage of using spreadsheets is that (I assume) SchoolTool
doesn't really care what additional logic or scripting is taking place
behind the scenes -- it just reads what ends up in what cells.  So
from SchoolTool's point of view, for example, it might just see a row
of section ID's.  The spreadsheet itself may give a specific semantic
meaning to each column (row one is German class, etc) and have tests
for the business logic of the particular school's schedule (or
national system).

In the long run, it would be good to have SchoolTool itself doing
increasingly complex validation, but in the short term, schools with
spreadsheet wizards can do it themselves.  There are more spreadsheet
wizards than Python programmers in school administrative offices
anyhow.

Regarding adding arbitrary data about students -- we expect to get
there eventually, but it needs to be done in a pretty controlled and
thoughtful manner, or else we'll just give users enough power to
completely screw up their databases a couple years into their use of
SchoolTool.

--Tom

On Fri, Dec 12, 2008 at 9:23 AM, Gregor Jacobs <privat@xxxxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ho Tom,
> me again... I wanted to reply quickly, but as you will read, it became
> a bit more... One of my main focusses is uniqueness of course IDs and
> assigning each student to one (and only one) course per subject taught
> for his grade...
>> Ah, this is really good.  Personally, I've really been blocked on
>> figuring out how to do this sanely.  Ignas did a lot better than I
>> could come up with, and yours is even better.
>>
> Thanks =)
> I think this is a striking point: In order to enable it to work
> globally, there should be an "official" list with given working
> patterns. If I sent you a formula such as
> =WENN(B2<>"";VERKETTEN(A2:A4)) your (probably set to English) excel
> would hardly understand. I tried using English words here, but it
> didn't work, so either the file's formulae must not be changed by
> users (IMHO recommended), OR there should be a translation of the
> formulae available.
>
>> COURSES should actually be "SECTIONS" in SchoolTool usage.  The course
>> would be subject+level.  That is, it would currently be identified
>> like "9th grade German."  We haven't added grade levels to the model.
>> We will probably have a very simple implementation of that by April,
>> but I'm not sure if it will make the cut.
>>
> I actually meant to provide the information of class+subject+course_no
> in the course_ID
> Anyways, I forgot to say what I had in mind with that: In the table
> where the students' data are in, there is everything about the
> student: name, phone, parents' names, address, class, form teacher,
> shoe size =) etc... AND THEN! all available subjects the school
> offers: English, Math, Physics, PE, RE, Chemistry, Music, Art etc. Now
> the table can be programmed:
> Let there be a student named jacobsgr in 10th grade who will be
> assigned to...
> English: course #1, German: course #3, Maths: course #3, Physics:
> course #2, Art: course #1, Music: course #5, Chemistry: course #2, PE:
> course #1, RE: course #4
> Now, the table makes from this my courses' IDs: en10_1, ge10_3,
> ma10_3, ph10_2, ar10_1, mu10_5, ch10_2, pe10_1, re10_4.
> My imaginary brother John, who is in 7th grade, will have English 2,
> German 1, Maths 4, Physics 2, Art 3, Music 1, Chemistry 3, PE 1, RE 5.
> So the table displays his courses IDs: en7_1, ge7_1, ma7_4, ph7_2,
> ar7_3, mu7_1, ch7_3, pe7_1, re7_5.
>
> Now, John and me were both in "Physics 2" for our level, but by
> providing the grade in the course ID and including the grade there, we
> see it's not the same course.
>
> In my school, we offer German, English and Maths in three levels basic
> (A), intermediate (B) and advanced (C) and this can easily be taken in
> as well to create unique course IDs. M2 C1 -9 is a course I teach:
> Maths, 2nd schedule (if that's the right word - some 9thgraders have
> Mahts on Mon Wed and Fri, some on Tue, Thu and Fri), C level, course
> 1, 9th grade. And even such complicated things can be easily adopted
> by providing the "course no" as 2C1 or 1A2 or whatever to get a course
> ID like ma9_2C1 (which should work perfectly and is a unique ID)
>
> Furthermore, this method can ensure that nobody misses an obligatory
> course... In the list, gaps can easily be detected, but in a huge list
> it might happen that nobody gets it that jacobsgr unfortunately
> doesn't take a Physics course.
>
> When reading in data, maybe even an output in SchoolTool like
> "Students jacobsgr, hoffmantm have no Physics course. [C]ontinue,
> A[s]sign courses or [A]bort?" might make sure nobody gets lost unless
> on purpose.
>
>>> Now this is a very basic data form I made, but the idea is not to
>>> require entering lots of data by hand... SchoolTool should then read
>>> the students's IDs and then one by one the courses for English,
>>> Physics, Chemistry... and by that the student is put into that course.
>>
>> Actually, I think the columns could be completely arbitrary.  A row
>> could just be a student and a sequence of sections to enroll them in,
>> right?  The only somewhat sloppy part is that it is an arbitrarily
>> long list, but in practice there won't be a lot of columns.
>>
> I think the number of columns can be limited in a way that all
> subjects are mentioned and extra things like band, football and so on
> can be added on an extra table, so we even can split apart obligatory
> and non-obligatory events. What needs to be done before students are
> assigned (and this should be a vital point in the documentation) is
> the "what subject does our school teach and what are the subject
> codes?" as a "first run" of data entry. Maybe there should be some
> extra files:
> - - First Setup: Subjects, subject codes
> - - Second setup: teachers, courses / teachers assignments
> - - Third setup: Assignment of students to courses
>
> For maintaining, we could (offer to) hide a mark that there was a
> change in one line (student left school, new student, students were
> promoted, change of course) and if this boolean is set to true this
> student's data will be read in again.
>
> However, schools should feel free to add extra and arbitrary data
> which meet their means. Let them sort their students by hair color,
> number of pets at home, who won the [insert idea here] contest etc. If
> we give them the impression that SchoolTool can give them what they
> want, they'll use it. Schools are unique, and if it's easy to set up
> SchoolTool for unique requirements, it's fine, isn't it?
>>> I hope you like this idea. Speaking for me personally, it were lots
>>> less work to create one data file and read it in again and again, once
>>> for each course (using filters probably), rather than reading the data
>>> only once and having to enter lots of data (which also causes a higher
>>> chance to get errors into there)
>>
>> I think it is a big improvement.  Ignas is more deeply involved in
>> this now so I'm sure he has some (probably more perceptive) thoughts.
>> ;-)
>>
>> --Tom
>>
>> Also, go join https://edge.launchpad.net/~schooltool-developers
>> please.  We're moving our mailing lists.
>
> OK, will do so in the next days.
>
> Gregor
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAklCnggACgkQJAaCHiB6C0ILmACePxehvIHsJ+IappHFWfR6S/TX
> QFMAn2NFBbwezantczSeW29EydC1MLDE
> =JPRT
> -----END PGP SIGNATURE-----
>
>