[schooltool] Demographics Rough Draft

[Tom Hoffman]

I went over several standards documents for student demographic and
contact info and took a crack at assembling a reasonable common set of
attributes for the sake of starting further discussion.

Name
----

First name*
Last name*
Prefix
Middle name
Suffix
Preferred
Sort name?

Demographics
------------

ID #
Gender*
Birthday*
Ethnicity*
Native language
Place of birth
Citizenship
Photo

Contact (per contact)
---------------------

We probably need to be able to attach arbitrary numbers of contact
persons to students. This data would be stored about the student
himself and/or each parent, etc. contact.

Priority (in list of contacts)
Name (as above)
Address line 1
Address line 2
City
State
Country
Postal code
Email
Home phone
Work phone
Mobile phone
Language

School
------

Advisor
Counselor

There are sets of properties which can, and perhaps should be,
expressed as group memberships, such as gifted/talented. This may
allow for somewhat easier customization than attaching lists of
boolean attributes to students.

What would you need to have added?

--Tom

[Neil Manson]

Hi All

Post by Tom Hoffman
I went over several standards documents for student demographic and
contact info and took a crack at assembling a reasonable common set of
attributes for the sake of starting further discussion.
Name
----
First name*
Last name*
Prefix
Middle name
Suffix
Preferred
Sort name?
Demographics
------------
ID #
Gender*
Birthday*
Ethnicity*
Native language
Place of birth
Citizenship
Photo
Contact (per contact)
---------------------
We probably need to be able to attach arbitrary numbers of contact
persons to students. This data would be stored about the student
himself and/or each parent, etc. contact.
Priority (in list of contacts)
Name (as above)
Address line 1
Address line 2
City
State
Country
Postal code
Email
Home phone
Work phone
Mobile phone
Language
School
------
Advisor
Counselor
There are sets of properties which can, and perhaps should be,
expressed as group memberships, such as gifted/talented. This may
allow for somewhat easier customization than attaching lists of
boolean attributes to students.
What would you need to have added?

These look good - Thanks Tom.

Could I suggest having a few (perhaps 5) extra fields that could be used
for arbitrary additional data.

For example, our students have a student ID, and Exam Number and a Login
ID, all of which are useful for different tasks, and all of which I
would like to have stored in SchoolTool. However, this is very specific
to my institution, and would not make sense to put in for everybody.

It would be nice (but not necessary) if the titles of these extra fields
could be customised as well.

Regards,
Neil
--
Neil Manson
Course Coordinator: School of IT
Monash South Africa

http://sit.monash.ac.za/
http://sit.monash.ac.za/staff/manson/

Neil.Manson at infotech.monash.edu
Tel : [phone]
Cell : 072 298-5124
Skype: neil.manson

[Tom Hoffman]

On Fri, Dec 19, 2008 at 8:15 PM, Neil Manson

Post by Neil Manson
These look good - Thanks Tom.
Could I suggest having a few (perhaps 5) extra fields that could be used for
arbitrary additional data.

Yes, I should have mentioned that.

Post by Neil Manson
For example, our students have a student ID, and Exam Number and a Login ID,
all of which are useful for different tasks, and all of which I would like
to have stored in SchoolTool. However, this is very specific to my
institution, and would not make sense to put in for everybody.

Yes, in particular it seems like everyone needs several ids, but there
is no consistency as to what they are called.

Post by Neil Manson
It would be nice (but not necessary) if the titles of these extra fields
could be customised as well.

Yes, that shouldn't be a problem.

--Tom

[Ignas Mikalajunas]

These additional fields, we want what kinds of them?

Text, Number, Date, Dropdown?
Required/Not required?

We want the data in a separate form, or we want to see it in the add
person form?

Which of them should be displayed in person listing tables (list of
persons in the system)?
Which of them should be displayed in person picking tables (group
member picker)?

I guess users can handle the evolution using export/import so if users
will want to change the type of the attribute, name of the attribute
or "converge" 2 variables into 1, they will have to export the old
data, fix up their demographics, fix the data in excel/csv, import it
back.

Ignas

[Tom Hoffman]

Post by Ignas Mikalajunas
These additional fields, we want what kinds of them?
Text, Number, Date, Dropdown?
Required/Not required?

I'm thinking that we limit it to not-required text fields.

Post by Ignas Mikalajunas
We want the data in a separate form, or we want to see it in the add
person form?

It depends on the overall design, whether we put everything on one
form or have several sub-forms/sheets/tabs.

Post by Ignas Mikalajunas
I guess users can handle the evolution using export/import so if users
will want to change the type of the attribute, name of the attribute
or "converge" 2 variables into 1, they will have to export the old
data, fix up their demographics, fix the data in excel/csv, import it
back.

I think we will keep it simpler than that. Like you've got fields
"custom1" through "custom5" which are just text fields like the others
except the admin can give them a separate title.

--Tom

--Tom

[Gregor Jacobs]

Hi Tom and the others,
this sounds nice... Let me write a few lines...

Post by Tom Hoffman
Demographics
------------
ID #
Gender*
Birthday*
Ethnicity*
Native language
Place of birth
Citizenship
Photo

Two suggestions for adding:
1. Date on which student entered this school
2. School the student was on before

Thinking of my school, I think we needn't use Ethnicity. However, if
there is a default value set (which can be set in the school's global
settings) it will work fine. This could also apply to "native
language" so that the most common one can be set as default, and the
field reads then "Native language (if other then
$DEFALUT_NATIVE_LANGUAGE)" or whatever that variable is.

At least, I think ethnicity does not need to be an obligatory setting,
as there are countries which do not officially record such data and
thus nobody would complain if this piece of information lacked.


I wish you a merry Christmas (if you celebrate it) and a happy new year!

Gregor

[Tom Hoffman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Tom and the others,
this sounds nice... Let me write a few lines...

Post by Tom Hoffman
Demographics
------------
ID #
Gender*
Birthday*
Ethnicity*
Native language
Place of birth
Citizenship
Photo

1. Date on which student entered this school
2. School the student was on before

Yes, those are two good ones.

Thinking of my school, I think we needn't use Ethnicity. However, if
there is a default value set (which can be set in the school's global
settings) it will work fine. This could also apply to "native
language" so that the most common one can be set as default, and the
field reads then "Native language (if other then
$DEFALUT_NATIVE_LANGUAGE)" or whatever that variable is.
At least, I think ethnicity does not need to be an obligatory setting,
as there are countries which do not officially record such data and
thus nobody would complain if this piece of information lacked.

In any event, just about everything will be optional, particularly
since SchoolTool has uses other than a full student information
system.

--Tom

[Martin Stevens]

Post by Tom Hoffman
I went over several standards documents for student demographic and
contact info and took a crack at assembling a reasonable common set of
attributes for the sake of starting further discussion.
Name
----
First name*
Last name*
Prefix
Middle name
Suffix
Preferred
Sort name?
Demographics
------------
ID #
Gender*
Birthday*
Ethnicity*
Native language
Place of birth
Citizenship
Photo
Contact (per contact)
---------------------
We probably need to be able to attach arbitrary numbers of contact
persons to students. This data would be stored about the student
himself and/or each parent, etc. contact.
Priority (in list of contacts)
Name (as above)
Address line 1
Address line 2
City
State
Country
Postal code
Email
Home phone
Work phone
Mobile phone
Language
School
------
Advisor
Counselor

These all look good to me, a small query/something to think about.

Can siblings be linked ? So that duplicate contacts are not required.

So a student can have multiple contacts and a contact can have multiple
students.

Also it might be usefull to think about addresses, an example use case
would be if a student move address, then it is very likely that the
parental contact(s) will move address as well.

So maybe the contact could optionally inherit some properties from the
student.

Regards

Martin Stevens

[Ignas Mikalajunas]

Post by Martin Stevens
These all look good to me, a small query/something to think about.
Can siblings be linked ? So that duplicate contacts are not required.
So a student can have multiple contacts and a contact can have multiple
students.
Also it might be usefull to think about addresses, an example use case
would be if a student move address, then it is very likely that the
parental contact(s) will move address as well.
So maybe the contact could optionally inherit some properties from the
student.

But won't that complicate the UI for the rest of students for quite
marginal benefits, and suddenly instead of "remove/archive" a student
you will have a problem with old parent/guardian data
archival/management, and users will have to understand that somehow
these things are separate issues, will have to know the rules like "if
you archive all the students related with this parent, the parent will
be archived automatically" or "if you change address of this student
(which he does not have at the moment, as address is only stored for
contact persons), you will change all the related addresses".

My biggest concern is having another class of objects that have
different and not well defined management semantics, like - when and
how do you archive/delete contact information for parents? Do you
remove any contact information that is not linked to any student? What
about undoing such an operation? What about "remove student A" "add
student B", do we want to explain everyone that they should never try
doing that, or do we want to have a separate UI just for student
contact management, effectivelly adding a separate person class just
for parents?

Ignas

[Tom Hoffman]

Post by Ignas Mikalajunas

Post by Martin Stevens
These all look good to me, a small query/something to think about.
Can siblings be linked ? So that duplicate contacts are not required.
So a student can have multiple contacts and a contact can have multiple
students.
Also it might be usefull to think about addresses, an example use case
would be if a student move address, then it is very likely that the
parental contact(s) will move address as well.
So maybe the contact could optionally inherit some properties from the
student.

But won't that complicate the UI for the rest of students for quite
marginal benefits, and suddenly instead of "remove/archive" a student
you will have a problem with old parent/guardian data
archival/management, and users will have to understand that somehow
these things are separate issues, will have to know the rules like "if
you archive all the students related with this parent, the parent will
be archived automatically" or "if you change address of this student
(which he does not have at the moment, as address is only stored for
contact persons), you will change all the related addresses".

I would say that in a primary or secondary school, students themselves
shouldn't really have contact info -- their parents should. Of
course, even in secondary school, occasionally students live on their
own, or have their own cell phone or email address that the school
actually recognizes as valid (sci fi, I know) so you still need to be
able to attach contact info to a student.

But I think it is simpler to just say "enter parent contact info under
the parent" than "inherit parent contact info from the student."

Of course, this does require a clear way to connect students and
parents and view all this in a reasonable way, but that's probably
necessary and unavoidable.

--Tom