AU2016101606A4 - Method and system for creation of classes - Google Patents

Abstract

In a method of allocating each of a plurality students to one of a plurality of classes to be taught at an educational institution in a period of time, a computer system receives class data about the plurality of classes and allocation criteria data about a desired optimum class composition. The computer system processes the class data, the student data and the criteria data to produce an allocation of each of the plurality of students to one of the plurality of classes.

Description

"Method and system for creation of classes"

Cross-Reference to Related Applications [0001 ] The present application claims priority from Australian Provisional Patent Application No 2015902060 filed on 2 June 2015, the content of which is incorporated herein by reference.

Technical Field [0002] The present disclosure relates primarily to the field of education. In particular, the disclosure relates to a method and means of allocating persons to categories of individuals, and is particularly adapted to the allocating of students to classes in an educational institution.

[0003] It will be convenient to hereinafter describe the disclosure in relation to creating class lists or, more particularly, allocating each of a plurality of students to one of a plurality of classes to be taught at a specific educational level in an educational institution in a period of time, however it should be appreciated that the present disclosure is not limited to that use.

Background [0004] Throughout this specification the use of the word “inventor” in singular form may be taken as reference to one (singular) inventor or more than one (plural) inventor of the present disclosure.

[0005] Currently the collection and collating of student data related to class creation is a time consuming task. Data is often collected differently by individual teachers or year levels, within the one education institution. This can make it difficult to collate, compare and manipulate the data in the process of making new classes. Data is often collected by the pen and paper method and transferred manually into digital form. For a school with 1,000 students, with 10 pieces of data attached to each student, data entry is not only extremely time consuming and inefficient, but it also results in errors. These errors result in the creation of classes using flawed data. Human error (spelling mistakes, incorrect recording of attributes, skipping/missing data, etc) when entering the data, can lead to significant mistakes when creating classes. Data collection and entry can also be too vague resulting in errors. For example a student might request to be with “Sally B”. The person entering the data might enter Sally Brown, when the student was actually referring to Sally Bird. There may also be multiple students with the same first and last name in a year level.

[0006] The task of configuring the number of classes in an educational institution is significant, especially as the size of institution increases. Some of the variables when configuring an institution’s classes include the number of students, number of classrooms, number of teachers, government mandates or parent expectations on class size, and the types of classes (straight (5C, grade 5 students only), or composites/multi-age(4/5, grade 4 and 5 students)). Currently this process is done by pen and paper or by creating a rudimentary spreadsheet in a program like Excel, both of which are time consuming and prone to errors.

[0007] Creating classes is like attempting a jigsaw puzzle, without knowing what the picture is. Creating classes is equally like building a logical ‘house of cards’. It needs a strong foundation in data and careful and logical construction. If ‘cards’ are placed incorrectly or moved without considering the consequence, it can all come tumbling down. The creation process seems to revolve around “traditional logic” of placing students in groups and placing those groups in classes and shuffling them around until they meet the criteria set by the school. It has a feel of “trial and error” and is lacking a systematic logic. The traditional method of “shuffle groups until they fit” is fraught with problems. The lack of feedback of moving students and groups between classes can result in imbalances between classes and students being placed together who should be separated.

[0008] Currently classes are made by moving students around on paper or digitally such as in an Excel spreadsheet. The problem is that students also have a large amount of data assigned to them (assessment on behaviour, academic, special needs, separations, pairings, friendship preference, addition notes, etc). This data is all relevant to the creation of high quality classes. However, the amount of data often results in it becoming overwhelming and virtually useless. Even though the data is valuable, because it is so hard to visualize all the relevant and related data in one space at one time, the data is often isolated and dealt with individually (eg. gender, friendships, behaviour, academic or special needs, etc). Problems then occur because the data is interrelated. So by balancing classes for “Gender” that may mean that the classes “Behaviour Balance” is completely thrown out. By not having a feel of the balance of each class it becomes virtually impossible to know the effect which will be caused by the moving of student(s).

[0009] Because of difficulty in identifying and meeting placement requirements, when moving students in and out of classes there are a variety of factors to take into account. Some include: -Does the student have a friend in the class? (Most school’s require each student to have at least one friend with them in a new class) - Is there a student in the class already who should/should not be with the student being moved in? Does the class have an imbalance of students in a particular area? Such as for example, Academic, Behavioural or Special Needs, etc. Sometimes people creating classes forget to ask these questions. Other times they ask the question, but they miss the clashes or errors because the data set is so large and overwhelming. This can result in classes being created that are unbalanced, the failure to meet requirements of keeping students apart or together, or students being placed in a class without any friends. The best case scenario is that these errors in placement are identified early on in the process and corrective movements of students are made without causing a “domino effect”.

[0010] Another scenario results in these errors being picked up very late in the process so that the corrective changes made to the classes result in a “domino effect”. Moving student “A”, means student “B” must be moved, which means student “C” must be moved, and so on until it is easier to start the process again from the beginning. The worst-case scenario is these errors are not identified until the classes have been confirmed and the new school year has begun. The resulting unbalanced classes can lead to extremely unhappy stakeholders (students, teachers, parents and principals) and poor academic and/or social outcomes. One teacher can end up with all the “naughty kids”, students can be isolated in classes without any friends, parents can be frustrated at having their requests ignored accidently by the school and principals can be exhausted by dealing with upset teachers, students and parents.

[0011] With respect to recording and recalling student history, as students progress through school, their class placement history/data is often lost or forgotten. This can result in students who should be separated accidently being placed together. For example student “A” and student “B” were in grade 1 together and they didn’t work well together. Their teacher and parents recommended the students be separated in grade 2, and they were. Some years later in grade 5, these students may well be placed in the same class together if their history of being “trouble together”, is not recorded, misplaced or not referred to. It would be more ideal for student history to be recorded centrally and teachers are alerted of such history at the relevant time.

[0012] Secondary schools have very significant challenges when creating new classes. They often have students coming from a large number of “feeder schools”. This can make it very difficult to collect consistent and/or reliable data from such a large number of schools. Paper surveys are sometimes sent out to these schools, however these surveys are often not completed, completed insufficiently or not returned in time to assist with creating new classes. Due to the large number of feeder schools this process can be extremely time consuming. This transition process is also similar as children move from pre-school/kindergarten into primary school.

Many primary schools do not receive adequate data from pre-schools/kindergartens to assist them when placing students in their first year at primary school. The obvious effects of this lack of data are that classes are made with little or no knowledge of the students. As mentioned above, class creation is like building a house and the data is the foundation of that house. Without strong data the likelihood of creating well-balanced and cohesive classes is greatly reduced.

[0013] In pre-primary and primary schools the current teachers, who know the students very well, make the classes for the following year. When students transition into primary school, or into secondary schools, the classes are made by educators whose knowledge of the students is generally limited to what they have been able to collect by a survey (if it is completed or returned at all) or by a very brief observation. Therefore students are often placed on the basis of zero knowledge. Classes in many secondary schools remain largely unchanged from year 7 to year 10. So if the classes are created in year 7, often with very little knowledge of the students, they remain very similar for four years. Therefore the collection of data as students enter their first year at educational institutions is vital.

[0014] It is to be appreciated that any discussion of documents, devices, acts or knowledge in this specification is included to explain the context of the present disclosure. Further, the discussion throughout this specification comes about due to the realisation of the inventor and/or the identification of certain related art problems by the inventor. Moreover, any discussion of material such as documents, devices, acts or knowledge in this specification is included to explain the context of the disclosure in terms of the inventor’s knowledge and experience and, accordingly, any such discussion should not be taken as an admission that any of the material forms part of the prior art base or the common general knowledge in the relevant art in Australia, or elsewhere, on or before the priority date of the disclosure and claims herein.

Summary [0015] An object of embodiments of the present disclosure is to provide a method of allocating each of a plurality of students to one of a plurality of classes to be taught at a specific educational level in an educational institution in a period of time [0016] It is an object of the embodiments described herein to overcome or alleviate at least one of the above noted drawbacks of related art systems or to at least provide a useful alternative to related art systems.

[0017] In a first aspect of embodiments described herein there is provided a computer-implemented method of automatically allocating each of a plurality of students to one of a plurality of classes to be taught at a specific educational level in an educational institution in a period of time, wherein allocating each of a plurality of students comprises generating an allocation data specifying an allocation of each student to one of the plurality of classes, the method comprising the steps of: a computer system receiving class data about the plurality of classes, the class data comprising data specifying: a number of teachers available to teach the plurality of classes; a target number of classes for the plurality of classes; and a target number of students per class; the computer system receiving student data about the plurality of students, the student data comprising, for each student, data specifying at least one of: academic abilities of the student; historical academic performance of the student; nature of the behaviour of the student in class; an identifier of any other student who should be included in the one of the plurality of classes with the student; an identifier of any other student who should not be included in the one of the plurality of classes with the student; student friendship selections of the student; an originating class of the student; special physical and/or mental needs of the student; special emotional needs of the student; an originating educational institution of the student; social, emotional and/or academic notes in relation to the student; a recommendation of student placement in regards to teacher notes in relation to the student; or a recommendation of student placement in regards to administrator notes in relation to the student; the computer system receiving allocation criteria data about a desired optimum class composition, the allocation criteria data giving a weighting to at least two of: the nature of the behaviour of the student in class; the identifier of any other student who should be included in the one of the plurality of classes with the student; the identifier of any other student who should not be included in the one of the plurality of classes; a balanced spread of academic abilities of students, between the plurality of classes; a balanced spread of special needs of students, between the plurality of classes; a balanced spread of originating class of students, between the plurality of classes; a balanced spread of originating educational institution of students, between the plurality of classes; or the student friendship selections of the student; the computer system processing the class data, the student data and the allocation criteria data to generate allocation data specifying an allocation of each student of the plurality of students to one class of the plurality of classes.

[0018] There is provided a method of allocating each of a plurality of students to one of a plurality of classes as described above, further comprising the step of the computer system displaying class data, student data, allocation criteria data, and the allocation of each of the plurality of students to one of the plurality of classes on a graphical user interface.

[0019] In the method, at least one of the class data, the student data, the allocation criteria data or the allocation data may be displayed on a graphical user interface and colour coded to distinguish, for each student, at least one of: student gender; a level indicative of academic abilities; a level indicative of historical academic performance; the nature of the behaviour of the student in class; the special physical and/or mental needs; the special emotional needs; or a stream which is specific to the plurality of classes.

[0020] The method may further comprise the step of the computer system indicating any student in respect of whom an item of allocation criteria data has not been met.

[0021] In the method, a student in respect of whom an item of allocation criteria has not been met may be indicated by colour coding.

[0022] The method may further comprise: receiving an instruction from a user of the computer system to move a student from one class in the plurality of classes to another class in the plurality of classes; wherein the step of the computer system receiving an instruction from the user to move the student from one class of the plurality of classes to another class of the plurality of classes comprises: generating, at the graphical user interface comprising a first area and a second area, a first list of students in a first class at the first area and a second list of students in a second class at the second area; receiving, from a user input device, a selection of a selected student in the first list at the first area and an indication to move the selected student to the second area; and updating the second list to include the selected student in the second list; and providing an indication of any student in respect of whom an item of allocation criteria data has not been met.

[0023] Therefore, the method may include dragging and dropping of an identifier of the student from one class to another class on the graphical user interface.

[0024] The method may further comprise the steps of the computer system: sending a questionnaire to at least one teacher to gather student data about the student; receiving data gathered from the questionnaire which has been sent to the teacher; sending a questionnaire to the student to gather student data about the student; and receiving the student data from the questionnaire which has been sent to the student.

[0025] The method may comprise the step of the computer system receiving data gathered from a questionnaire which has been to a teacher.

[0026] The method may comprise the step of the computer system sending to at least one student a questionnaire to gather student data about that student.

[0027] The method may comprise the step of the computer system receiving data from a questionnaire which has been sent to a student.

[0028] The method may further comprise the steps of the computer system: receiving an instruction to re-allocate each of the plurality of students to one of a plurality of classes; generating a randomized prioritization of at least one of the class data, the student data and the criteria data the and processing the class data, the student data and the criteria data according to the randomized prioritization to produce the re-allocation.

[0029] In the method, at least a portion of the computer system may be cloud-based.

[0030] In the method, at least a portion of the computer system which is cloud-based may comprise a database system which receives at least one of the class data, the student data and the allocation criteria data.

[0031] In a further aspect of embodiments described herein there is provided a method of allocating individual students to at least one class in a given year level, the method comprising the following steps: predetermining a number of students in a year level, A; predetermining a number of straight classes, B; predetermining a number of composite classes in the year level, C; determining a composite class size, N, according to the formula,

N = A / ((2xB) + C); determining a straight class size as 2N

[0032] The method may further comprise the steps of the computer system: receiving student history data about the student, the student history data comprising at least: data specifying a class placement history of the student; the recommendation of student placement in regards to teacher notes in relation to the student; the recommendation of student placement in regards to administrator notes in relation to the student; and providing the student history to the teacher.

[0033] There is also provided apparatus adapted to allocate each of a plurality of students to one of a plurality of classes to be taught at a specific educational level in an educational institution in a period of time, comprising processor means adapted to operate in accordance with a predetermined instruction set, said apparatus, in conjunction with said instruction set, being adapted to perform the method as described above.

[0034] There is also provided a computer program product comprising: a computer usable medium having computer readable program code and computer readable system code embodied on said medium the computer program product being adapted for allocating each of a plurality of students to one of a plurality of classes to be taught at a specific educational level in an educational institution in a period of time according to the method described above.

[0035] Other aspects and preferred forms are disclosed in the specification as a whole and/or defined in the appended claims, forming a part of the description of the disclosure [0036] Further scope of applicability of embodiments of the present disclosure will become apparent from the detailed description given hereinafter. However, it should be understood that the detailed description and specific examples, while indicating preferred embodiments of the disclosure, are given by way of illustration only, since various changes and modifications within the spirit and scope of the disclosure herein will become apparent to those skilled in the art from this detailed description.

Brief Description of Drawings [0037] Further disclosure, objects, advantages and aspects of preferred and other embodiments of the present application may be better understood by those skilled in the relevant art by reference to the following description of embodiments taken in conjunction with the accompanying drawings, which are given by way of illustration only, and thus are not limitative of the disclosure herein, and in which:

Figure 1 is a screenshot of an exemplary graphical user interface utilised by a teacher to complete a survey in accordance with a preferred embodiment of the present disclosure where tabs at the top allow easy movement between survey topics.

Figure 2 is a graphical user interface display of Class Survey Results in accordance with a preferred embodiment.

Figure 3 illustrates an exemplary method of completing a student friends preferences survey in accordance with a preferred embodiment in which the teacher asks a “younger” student their preferences and fills out the table.

Figure 4 an exemplary method of completing a student friends preferences survey in accordance with a preferred embodiment in which “older” students select their friend preferences in order.

Figure 5 is an exemplary output display of the preferred embodiment of the disclosure for configuring the classes and/or streams in a school.

Figure 6 is an exemplary output display showing a sorting page in accordance with a preferred embodiment of the disclosure in which Year Level Summary is indicated on top, with student breakdowns and indicative icons for students with Friend Preferences, Separations and Pairings not met.

Figure 7 is an exemplary output display showing an indicative view of students by behaviour colour coding for easy viewing by the educator and in which students can be dragged and dropped between classes where alerts are activated when requirements are not met.

Description of Embodiments [0038] Further disclosure, objects, advantages and aspects of preferred and other embodiments of the present disclosure may be better understood by those skilled in the relevant art by reference to the following description, which should be read in conjunction with the accompanying drawings briefly described, above.

[0039] In a preferred embodiment of the disclosure, School Administrators (usually a principal, assistant/deputy principal or leading teacher or coordinator) register for a school account via a website by entering personal and school details, contacts and agreeing to terms and conditions. The class creator software application generates login details (username and password for administrator), and emails login details to the School Administrator. Thereafter the school Administrator gains access to the application by entering their login details via the website.

[0040] The school administrator is required to upload their school’s student database. First the school administrator downloads an Excel spreadsheet template containing the appropriate fields for each school’s student database, - preferably including first name, last name, gender, current class, current year level, student identification number. The school administrator inserts their school’s student data into the corresponding columns, usually via copy and paste from other administration databases. The spreadsheet is saved as a .CSV file. The .CSV file is then uploaded to the class creator application via a web application. As students are imported to the database for each school, the students are tagged with a Personal Identification Number (CCPIN). This identification number is used to attach data to the student. The student database is stored on “the cloud” using secure, remote servers (e.g. Amazon Web Services). The application also stores users' credentials securely (preferably using bcrypt) and generates a unique username and passwords for students to have access to surveys, if required.

[0041] The School Administrator is required to upload their school’s teacher database. The School Administrator downloads an Excel spreadsheet template containing the appropriate fields for each school’s teacher database - preferably First Name, Last Name, Gender, Current Class, Email Address. The School Administrator inserts their school’s teacher data into the corresponding columns, usually via copy and paste from other administration databases. The spreadsheet is saved as a .CSV file. The .CSV file is then uploaded to the application via a web application. As teachers are imported to the database for each school, the teachers are tagged with a Personal Identification Number (CCPIN). This identification number is used to attach data to the teacher and to allow levelled access depending on the school administrator’s selection. The teacher database is stored on “the cloud” using secure, remote servers (eg Amazon Web Services). The application also stores users' credentials securely (preferably using bcrypt) and generates a unique username and passwords for teachers to have tiered access to the API.

[0042] The School Administrators select the settings for the surveys to be completed by students and teachers. School Administrators can select from options which preferably include the following when setting up the surveys :Academic Assessment, Anecdotal Teacher Academic Assessment, Anecdotal Teacher Literacy & Numeracy Assessment, Results from assessments (EG. NAPLAN, PAT, ODT, VCE, SAT, etc) and Curriculum Levels (eg, AusVELS Literacy = 4, AusVELS Numeracy = 4.5).

[0043] Schools can allow students to select between 0-5 Student Friendship Preferences. Some schools prefer 3 preferences as that leads to students having “closer friends” in their future classes. Other schools prefer to allow students to select 5 friend preferences as it allows for great flexibility when creating classes and students are required to have 1+ friend. The application preferably offers students the ability to choose up to 5 friends, but a minimum of 3, therefore they only need to put 4th & 5th friend preferences if they wish.

[0044] Survey Closing Date: The School Administrator can set a closing date for the surveys. This will shut off teacher access to the surveys, to prevent teachers from editing the survey data while classes are being created. School Administrators will always be able to edit the survey results, an example of which is shown in Figure 2. The School Administrator can set a date for an automatic reminder to be sent to any teachers who have not completed their survey. Survey reminders are sent via email to the teacher. Reminders can also be sent at any time via the “Monitor Surveys” option. Once the School Administrator is happy with the survey settings they “Send Surveys”. Before the surveys are sent confirmation is requested on the preferences selected, if they are correct the surveys are generated and an access link sent to teachers via email. The purpose of the surveys is to gather information on individual students from their current teacher(s) and the student themselves. The surveys are generated via a database. The survey results link directly back to the database with real time transfers. Any data entered via the surveys is updated in the surveys and tagged to the appropriate student using their CCPIN.

In the database teachers have a “Current Class”, for example Tim Brown is the current teacher for 4B. All students in the database who are tagged as being in “4B” are used to populate the survey for Tim Brown. The information fields and possible selections/input data are derived from the selections by School Administrator in the “Survey Settings” section.

[0045] With reference to Figure 1, teachers access the API via the weblink that is emailed to them or via a website. The teacher is then required to enter their unique username and password to authorise access, and to direct the teacher to the correct survey. For example, Tim Brown, the teacher of 4B is directed to the survey populated by the students in 4B. The fields and input may contain but not be restricted to the following categories:

Behaviour: Very Good, Good, Satisfactory, Challenging, Very Challenging.

Academics (General): Well Above Level Above Level, At Level, Below Level, Well Below Level.

Academics (Literacy): Well Above Level, Above Level, At Level, Below Level, Well Below Level.

Academics (Numeracy): Well Above Level, Above Level, At Level, Below Level, Well Below Level.

Academics Assessment: Student Results from Assessments (e.g. NAPLAN, ODT, etc). Special Needs: None, Minimal Extra Teacher Support, Some Extra Teacher Support, Lots of Extra Teacher Support.

Separation: 1st Recommended Separation, 2nd Recommended Separation, 3rd Recommended Separation.

Pairing: 1st Recommended Pairing, 2nd Recommended Pairing, 3rd Recommended

Pairing.

Student Friend Preferences: 1st Friend Preference, 2nd Friend Preference, 3rd Friend Preference, 4th Friend Preference, 5th Friend Preference.

Streams: Specific “Streams” as designated by the school administrator. Examples include High Achievers, Dance, Basketball, ESL, etc.

Teacher Notes: These notes will be tagged to the student using their CCPIN.

Class Results: Allow Teachers to see all the results for the data collected on their class. The surveys are linked to the database, and with the teacher selection resulting in the student being assigned a numerical value for each area.

[0046] To streamline the collection of “Student Friend Preferences” there are two ways to collect the relevant information. One way is aimed at Big Kids, the other is for Little Kids.

After completing their “Class Survey”, teachers select the “Student Preferences” tab and can choose between two methods depending upon their students age, ability and maturity. With reference to Figure 3, younger, less able and less mature students will complete their Student Friend Preferences with their teacher. The student name fields in the “preferences” tab of Figure 2 are enabled with auto-fill to ensure names are correct, and the preferred student’s current class is listed in brackets to ensure the correct student is selected where there is more than one student in the year level with the same name. With reference to Figure 4, older, more able and mature students will complete their Student Friend Preferences independently.

[0047] Younger/Less Able Students Method (Teacher Led): The teacher is presented with another survey. Their students are listed on the left hand side column. The survey has column headers “1st Friend Preference, 2nd Friend Preference, 3rd Friend Preference...”. Each row has input fields aligned with each student, the number is dependent upon how many student preferences the School Administrator selected in the “Survey Settings” (3-5). The teacher will ask students privately and individually, “If you could choose to have someone from the year level in your class next year who it be?”

The selection by the student becomes their first preference. Teachers enter the preference into the correct input field. The teacher then asks the student, “Who else would like to be in your class?”

The process continues until enough Student Friend Preferences are collected and the teacher moves on to next student on the list. The input field is locked to the student’s year level, so they cannot choose someone from another year level. Students cannot choose themselves. The input field offers matches on the input using client side (JavaScript) technology to ensure a fast and responsive user experience. The input field will show the students: First Name, Last name, Current Class. The input field will be auto-filling. This saves time for the teacher, and ensures the data is entered correctly (no spelling mistakes).

[0048] Older/More Able Students Method (Independent): The application stores users' credentials securely (using bcrypt) and generates a username and password for each individual student in the class. These login details become tagged to the student via their Personal Identification Number (CCPIN). The application generates individual login cards for each student. Each card displays the student’s username and password, as well as the web address. The cards (in one embodiment, the size of a credit card) are produced as a PDF with multiple student card on each page, for the teachers to print, cut up and distribute to the students.

Students use the cards to login to the application using their username and password. This identifies them using their CCPIN and displays the correct “survey” for each individual school. The student is asked to confirm they are who their CCPIN identifies them as. The objective of this step is to ensure the student has the correct login card and is therefore entering THEIR preferences in THEIR account. The student is then presented with a grid containing all the students in their year level. The grid is set out with current classes being listed in columns. Students are listed in their current classes, alphabetically by last name, to assist students to find the friend preferences easily. Students cannot select themselves. The student clicks on the student they wish to be their first preference, then their second preference, and so on until they have reached the number of preferences as required by the school as selected by the School Administrator in the “Survey Settings” menu. The student then has the option to “Submit” their preferences or “Restart”. Once they are happy with their preferences and they select “Submit”, the student’s preferences are displayed and they are asked to confirm their sections are correct. The purpose of this is to provide a second layer of security so that the students’ preference(s) are correct. This ensures the student is making the selections they wish to make, and to ensure the student can’t complain such as by way of “They weren’t the preferences I made”.

[0049] The application allows administrators to instantly configure their school in regards to the number and type of classes that best suits their schools needs. With all student data centralised administrators can easily adjust the variables (number & type of classes) to create the configuration of their school, to best fit their requirements (number of classes, classrooms, teachers and students per class). This provides great assistance when schools are planning staffing and resource allocation for upcoming years. The School Administrator can configure their school by using the “Configure Classes” panel in the application. The application accesses the student database to calculate how many students will be in each year level for the upcoming year. The number of students in each year is displayed for the School Administrator’s reference. With reference to Figure 5, the School Administrator can then select the number of each type of class they require. For example, three classes of Preps, Two classes of Grade Is, One class of Grade l/2s, Two classes of Grade 2, etc. The “Configure School” algorithm then gives the school administrator an approximation of how many students will be in each class. It also displays the total number of classes, which may be useful for staffing and classroom considerations, such as timetabling. School Administrators may also elect to allow Stream (Grouping with common attributes) in their school in the Configure Classes page. This will allow educators to “tag” students as belonging to, or recommend they join, a particular “Stream”. An example of a schools using streams would be a school with High Achievers, Dance and Basketball Streams.

[0050] The “Configure School” algorithm makes it’s calculations as follows:

For Composite/Multi-Age Classes: A = Number of students in year level B = Number of straight classes for that year level C = Number of composite classes for that year level

N = Composite Class size 2N = Straight Class size Formula: A / ((2xB) + C) = N

Example: 120 students / (2x(4 straight classes) + 1 composite) = 120/9 = 13.3 Straight Class size = 2N = 2x13.3 = 4 Classes of approx. 27 Composite Class size = N = 1x13.3 = 1 Class of approx. 13 For Non Composite/Multi-Age Classes:

A = Number of students in year level B = Number of straight classes for that year level N = Class Size Formula: A / B = N

Example: 120 students / 4 classes = 30 students per class.

[0051] The school configuration as decided by the School Administrator is also directly linked to the application’s database and algorithm. This allows the administrator to add new students to the database and see how they impact class size (“Class sizes are too big now, we need another class”). Also, as soon as the number of classes in the Configure Schools section has been altered by the School Administrator, the application’s algorithm re-sorts the students amongst the new number of classes. Previously if a new class was added schools may have to start the whole process of making classes again. Now the algorithm will give schools a result for the new number of classes almost instantly.

[0052] School Administrators will also have the opportunity to assign teachers to a particular class for the upcoming academic year. Some schools like to do this as it allows them to place students with a particular teacher. Other schools prefer not to allocate teachers to classes at they feel classes should be balanced all round and not “in favour of’ individual teachers. The School Administrator will be able to select teachers from the application’s database and place them in a class for the upcoming year.

[0053] Once schools have collected the appropriate data the application runs an algorithm that attempts to provide schools with potential student combinations (classes) that meet, or come close to meeting the requirements of their educational institution. The algorithm produces these solutions within seconds. Schools are able to adjust the constraints of the algorithm that are most relevant to their schools needs and are provided with new class combinations in real-time. The above noted algorithm has the effect of putting teachers’ class selection logic into computer language and, that has allowed the inventor to leverage computer processing, organisational and automation capabilities to produce classes in seconds that would have taken teachers hours, days or even weeks to produce.

[0054] The above noted algorithm is also flexible enough to be altered to provide schools with a variety of possible outcomes to meet different needs. These alterations occur virtually instantaneously in the backend, so the user simply switches a toggle or selects a different version from a drop down menu and a variation of the classes appear. All results are dependent upon the dataset. There may be impossibilities - for example, Student “A” wants to be with students “C”, “P”, “O”. However, the teacher has requested student “A” is separated from students “C”, “P”, “O”. In this case student “A” would be separated from students “C”, “P”, “O” and he would be highlighted as not having a friendship preference.

[0055] Once all student data is collected via the online survey it is stored in the database. All data relevant to a student is tagged to them via their CCPIN. Relevant data tagged to a student may include, but not be limited to, the following data:

First Name

Last Name

Gender

Current Class

Current Year Level CCPIN

Teacher Survey Results:

Behaviour

Academic Level/Abilities Special Needs

Recommended Separations (including history) via teacher, parent or principal. Recommended Pairings (including history) via teacher, parent or principal.

Teacher Notes (including history)

Teacher recommendation a student is placed with/not with a particular teacher.

Student Friend Preference: These are the request from students to be with other students in their year level.

Administrator Notes: These notes may be in regards to a student’s situation that a teacher does not need to see. These notes may relate to a parental request to have/or not have, their student placed with a particular teacher.

[0056] The application’s algorithm then uses this data to create new classes, while attempting to work within the constraints set by the School Administrator. The School Administrator has the ability to turn ON or OFF the following constraints in the algorithm:

Student Friend Preference 1+

Student Separations

Student Pairings.

If all constraints are turned ON “Separations” override “Student Friend Preferences” and “Pairings”. “Pairings” do not constitute a “Student Friend Preference”, unless the student in the “Pairing” is also a “Student Friend Preference”.

[0057] With reference to Figure 6, the algorithm works by logically making small groups of students in relation to Separations, Pairings and Student Friend Preferences, as follows.

First, student “Pairings” are satisfied. Students identified as required to be a “Pair”, that are not required to be a “Separation”, are placed together. If a “Pairing” request corresponds with a “Separation” request, the “Separation” request overrides the “Pairing” request.

Second, each of those paired students are found a student who matches at least one of their “Student Friend Preferences” if a preference isn’t already met, but where the incoming student is not part of any paired students “Separation”, who is then added to the group.

Third, students with “Separations” have their “Student Friend Preferences” satisfied, where possible. Students with “Separations” are selected and a search is conducted for any reciprocating “Student Friend Preferences” that aren’t overridden by a separation.

If there is a match they become a group of 2.

Fourth, students that are not matched yet are sorted into groups of between 2 and 5 by reciprocal “Friend Preferences”. Students are selected and the algorithm searches for reciprocating preferences (1st, 2nd, 3rd) in the following order: 1st & 1st 1st & 2nd 2nd & 2nd 1st & 3rd 2nd & 3rd 3rd & 3rd 1st & 4th 2nd & 4th 3rd & 4th 4th & 4th 1st & 5th 2nd & 5th 3rd & 5th 4th & 5th 5th & 5th

If a “Separation” recommendation exists, the Student Friend Preferences are skipped.

Then, the algorithm iterates over the groups and searches for single students who have a Friend Preference that points IN to one of grouped students and does not have a separation in that group. The single student is then added to the group. This search loops through all groups attempting to make optimal Friend Preference groups of 3.

The above process of attaching singles to groups is iterated over again to create groups of 4 where possible, starting with the smallest groups.

Based on the number of students and the size of classes, the preferred embodiment may iterate this process to create larger groups of up to 5 to ensure as many students as possible are matched to a group and achieve the optimal outcomes for each class.

At the completion of this grouping process most students will have 1+ “Friend Preference” met. There may be some single students left and they will need to be placed with one of their “Friend Preferences” during sorting.

[0058] The groups are then tagged by gender and allocated an aggregate number for behaviour, academic, gender, group size, originating class and special needs scores of the individuals. The groups are then ranked according to the priority sort as selected by the School Administrator. The higher the groups needs (eg students with the worst behaviour, or with the lowest academic ability, etc), the higher their ranking. The rankings are numerical using the data from the application’s Surveys in regards to Behaviour, Academics and Special Needs.

[0059] The groups are then placed in to classes based on their ranking. The classes are sorted after each allocation by their aggregate priority sort number, in descending order, to ensure there is an even spread of needs in each class. The application’s user can select different variations of the algorithm to alter the sorting on students. The following are examples of the variations of potential class prioritisations:

General Mix = Class Size (Variance of 3 (eg, 25-28)), Gender, Behaviour, Special Needs, Academics.

Academic Spread Priority = Academics, Class Size, Gender, Special Needs, Behaviour.

Behaviour Spread Priority = Behaviour, Class Size, Gender, Special Needs, Academics.

Special Needs Spread Priority = Special Needs, Class Size, Gender, Behaviour, Academics.

Gender Balance Spread Priority = Gender, Class Size, Special Needs, Behaviour, Academics.

Class Size Spread Priority = Class Size (Variance of 1 (eg, 25-26)), Gender, Behaviour, Special Needs, Academics.

[0060] The Administrator is also able to select a ‘Random’ button to regenerate the classes using the process above, but using different sort priority. For example, if the Administrator had classes based on placing the students with the most challenging behaviour first, it would then start with the most challenging academic students, or students with the high level of special needs.

[0061] With reference to Figure 7, the application displays an overview of how students are distributed across the year level. A table is displayed for each year level. In the table individual classes are divided into rows. For each class the columns display the demographics in each class in a colour coded format including, but not limited to the following information:

Gender: Male, Female.

Behaviour: Very Good, Good, Satisfactory, Challenging, Very Challenging.

Academics (General): Well Above Level Above Level At Level, Below Level Well Below Level..

Special Needs: Minimal Extra Teacher Support, Some Extra Teacher Support, Lots of Extra Teacher Support.

Streams: Colour coded to display streams specific to the schools settings.

[0062] To be able to see the data displayed as a year level overview/summary and to be able to view the entire year level’s students colour coded by data category (gender, behaviour, academic, special needs, etc) with the simple click of a button allows educators to quickly see how balanced classes are across a variety of parameters. Previously this has been virtually unachievable due to the amount of data, even in small schools let alone schools with large numbers of students.

[0063] The overview is linked to the database, therefore, if any student data is altered in the surveys/database it is instantly changed in the overview and if a student is moved it is reflected in the overview instantly. This is a very powerful tool for schools to use when creating classes. To be able to easily see the spread of students in regards to variety of criteria is unprecedented.

[0064] Newly created classes can be viewed individually (e.g. Grade 4 C), displaying the details of individual students (Name, Gender, Previous Class, Behaviour, Academics, Special Needs, Pairings, Separations, Friend Preferences) in a grid. This view is useful for teachers to view classes on a micro/student by student level.

[0065] Newly created classes can be also be viewed as an entire “Year Level” (e.g. All grade 4 classes). All classes are displayed as a list of student’s names (with their previous class in brackets next to them). This view is useful for teachers to view classes on a macro level.

[0066] When viewing as a “Year Level” the view can be altered to show the year level as highlighted by colour for the categories of Gender, Behaviour, Academics and Special Needs for each individual student. This is an excellent way for users to identify imbalanced and needs within classes. This is illustrated by Figure 7 in regards to student behaviour within the year level.

[0067] If a student is clicked while in the year level view, a pop-up window appears with their relevant Pairings, Separations, Friend Preferences. If a student has a Pairing or Separation, they are highlighted with an icon to make them easily identifiable.

If a student’s Pairing, Separation or 1+ Friend Preference are met, their icon is GREEN. If a student’s Pairing, Separation or 1+ Friend Preference are not meet, their icon is RED. This way of highlighting errors/clashes will greatly reduce the number of student placement errors, and save educators a great deal of time while making classes.

[0068] Creating classes is as much an art form, as it is a science. Teachers have a unique and deep understanding of their students, and how they relate to peers and teachers, that cannot be captured by a survey or adequately interpreted by an algorithm. Allowing teachers to easily and confidently manually edit classes is one of the highest priorities of the application. The application allows teachers to move students between classes using the intuitive “Drag and Drop” method. While in “Year Level View” the user can click and hold on a student, “Drag” their name to another class and “Drop” them in the new class. This allows the user to easily manipulate the classes for new composition.

[0069] While using the “Drag and Drop” method the user receives instant/real-time feedback on the global effects of their alterations. For example, if a teacher moves a student to a new class and they no longer have a Student Friend Preference or they are placed in a class with a student they have a separation, the user is notified by the change in the relevant icon colour from GREEN to RED. Displaying clash and error alerts instantly provides teacher with an unprecedented confidence to edit their classes without the fear of bringing down the entire “house of cards”.

[0070] Movements of students between classes is also updated in real-time on the “Year Level Overview”. This provides the user with instant feedback on the more macro effects, positive or negative, of the changes they have made. This allows the user flexibility to manipulate classes with a far greater view of the big picture. Without this feedback it is far more likely that by manipulating the classes to balance one area (eg behaviour or special needs) the user could inadvertently cause an imbalance in another area (eg gender or academic ability).

[0071] Effectively, by allowing administrators/teachers to edit classes in the way described above, in this way feedback may be provided by virtue of the ability to "Drag & Drop" students between classes and then receive instant feedback of the effects of the move on individual students and on the entire year level balance.

[0072] As illustrated in Figure 7 there is a first area 73 and a second area 75 at the graphical user interface. The first area 73 comprises a first list of students 77 and the second area 75 comprises a second list of students 79. A user input device associated with the user may select a selected student in the first list 77 of the first area 73 and make an indication to move the selected student to the second area 75. The input device may be a mouse, keyboard or a touch screen. In this way, the selection of the selected student may be via the input device. Similarly, the indication to move the selected student may be received by the user at the input device. The second list 79 may then be updated to include the selected student from the first list 77.

[0073] Once the user has been or is satisfied with the classes they have created they can save them. Classes are saved within the application for future reference and access. The user may access these saved versions and edit them to create new versions.

[0074] The user can export the classes from the application in a variety of formats including, but not limited to XLS, CSV and PDF. The exported file can be saved and used by the user however they wish, but often it will be uploaded to a student management system.

[0075] All data is stored securely on the applications cloud based servers for future reference. Individual student data is tagged with their CCPIN. In future years this CCPIN and the related information that is used to identify students with their personal and class placement history. This information is very useful to educational institutions. For example, when students with a “Separation” in their history are placed together the user will be alerted with a “Separation

History” icon. It is then at the school discretion how they wish to use this information. They can ignore the history (e.g.“It’s ancient history”) or the students can be separated.

[0076] When the implementation of the application is “cloud based”, the nature of the application also allows for information to be collected quickly, and far more easily, across education institutions. This is particularly relevant to the transition of larger numbers of students from one institution to another (e.g. students moving from primary/elementary schools to secondary/high school to universities/colleges). Being cloud based also allows for this application to be used on a large variety of devices (e.g. Apple Mac, PC, etc) and it is not restricted to use on a single device on which it is installed or on one hosting service. Users can access the software from anywhere with Internet connection at any time.

[0077] The application can be used by institutions receiving students, to send out surveys to specific teacher(s) and schools to collect data on their incoming students. The ease of completing the survey online makes it much more likely the surveys will be completed and returned on time. Currently some schools place large numbers (100+) of incoming students , with little knowledge of the student’s behaviour, academic or special needs requirements. This can obviously result in the schools making classes that are unbalanced and not harmonious. This can have a negative impact on students, teachers and the entire school.

[0078] By collecting data more efficiently, by using the application’s surveys, these schools will have a better understanding of student needs individually and as a cohort. By using the application linked to this data, schools will be able to create more balanced classes, that meet their schools’ needs and provide better outcomes for all stakeholders.

[0079] While this disclosure has been described in connection with specific embodiments thereof, it will be understood that it is capable of further modification(s). This application is intended to cover any variations, uses or adaptations of the disclosure following in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains and as may be applied to the essential features hereinbefore set forth.

[0080] As the present disclosure may be embodied in several forms without departing from the spirit of the essential characteristics of the disclosure, it should be understood that the above described embodiments are not to limit the present disclosure unless otherwise specified, but rather should be construed broadly within the spirit and scope of the disclosure as defined in the appended claims. The described embodiments are to be considered in all respects as illustrative only and not restrictive.

[0081] Various modifications and equivalent arrangements are intended to be included within the spirit and scope of the disclosure and appended claims. Therefore, the specific embodiments are to be understood to be illustrative of the many ways in which the principles of the present disclosure may be practiced.

[0082] It should be noted that where the terms “server”, “secure server” or similar terms are used herein, a communication device is described that may be used in a communication system, unless the context otherwise requires, and should not be construed to limit the present disclosure to any particular communication device type. Thus, a communication device may include, without limitation, a bridge, router, bridge-router (router), switch, node, or other communication device, which may or may not be secure.

[0083] Various embodiments of the disclosure may be embodied in many different forms, including computer program logic for use with a processor (e.g., a microprocessor, microcontroller, digital signal processor, or general purpose computer and for that matter, any commercial processor may be used to implement the embodiments of the disclosure either as a single processor, serial or parallel set of processors in the system and, as such, examples of commercial processors include, but are not limited to Merced™, Pentium™, Pentium Π™, Xeon™, Celeron™, Pentium Pro™, Efficeon™, Athlon™, AMD™ and the like), programmable logic for use with a programmable logic device (e.g., a Field Programmable Gate Array (FPGA) or other PLD), discrete components, integrated circuitry (e.g., an Application Specific Integrated Circuit (ASIC)), or any other means including any combination thereof. In an exemplary embodiment of the present disclosure, predominantly all of the communication between users and the server is implemented as a set of computer program instructions that is converted into a computer executable form, stored as such in a computer readable medium, and executed by a microprocessor under the control of an operating system.

[0084] Computer program logic implementing all or part of the functionality where described herein may be embodied in various forms, including a source code form, a computer executable form, and various intermediate forms (e.g., forms generated by an assembler, compiler, linker, or locator). Source code may include a series of computer program instructions implemented in any of various programming languages (e.g., an object code, an assembly language, or a high-level language such as Fortran, C, C++, JAVA, or HTML. Moreover, there are hundreds of available computer languages that may be used to implement embodiments of the disclosure, among the more common being Ada; Algol; APL; awk; Basic; C; C++; Conol; Delphi; Eiffel; Euphoria; Forth; Fortran; HTML; Icon; Java; Javascript; Lisp; Logo; Mathematica; MatLab; Miranda; Modula-2; Oberon; Pascal; Perl; PL/I; Prolog; Python; Rexx; SAS; Scheme; sed; Simula; Smalltalk; Snobol; SQL; Visual Basic; Visual C++; Linux and XML.) for use with various operating systems or operating environments. The source code may define and use various data structures and communication messages. The source code may be in a computer executable form (e.g., via an interpreter), or the source code may be converted (e.g., via a translator, assembler, or compiler) into a computer executable form.

[0085] The computer program may be fixed in any form (e.g., source code form, computer executable form, or an intermediate form) either permanently or transitorily in a tangible storage medium, such as a semiconductor memory device (e.g, a RAM, ROM, PROM, EEPROM, or Flash-Programmable RAM), a magnetic memory device (e.g., a diskette or fixed disk), an optical memory device (e.g., a CD-ROM or DVD-ROM), a PC card (e.g., PCMCIA card), or other memory device. The computer program may be fixed in any form in a signal that is transmittable to a computer using any of various communication technologies, including, but in no way limited to, analog technologies, digital technologies, optical technologies, wireless technologies (e.g., Bluetooth), networking technologies, and inter-networking technologies. The computer program may be distributed in any form as a removable storage medium with accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the communication system (e.g., the Internet or World Wide Web).

[0086] “Comprises/comprising” and “includes/including” when used in this specification is taken to specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof. Thus, unless the context clearly requires otherwise, throughout the description and the claims, the words ‘comprise’, ‘comprising’, ‘includes’, ‘including’ and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in the sense of “including, but not limited to”.

[0087] It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the above-described embodiments, without departing from the broad general scope of the present disclosure. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims (5)

1. CLAIMS:

   1. A computer-implemented method of automatically allocating each of a plurality of students to one of a plurality of classes to be taught at a specific educational level in an educational institution in a period of time, wherein allocating each of a plurality of students comprises generating an allocation data specifying an allocation of each student to one of the plurality of classes, the method comprising the steps of: a computer system receiving class data about the plurality of classes, the class data comprising data specifying: a number of teachers available to teach the plurality of classes; a target number of classes for the plurality of classes; and a target number of students per class; the computer system receiving student data about the plurality of students, the student data comprising, for each student, data specifying at least: academic abilities of the student; historical academic performance of the student; nature of the behaviour of the student in class; an identifier of any other student who should be included in the one of the plurality of classes with the student; an identifier of any other student who should not be included in the one of the plurality of classes with the student; student friendship selections of the student; an originating class of the student; special physical and/or mental needs of the student; special emotional needs of the student; an originating educational institution of the student; social, emotional and/or academic notes in relation to the student; a recommendation of student placement in regards to teacher notes in relation to the student; or a recommendation of student placement in regards to administrator notes in relation to the student; the computer system receiving allocation criteria data about a desired optimum class composition, the allocation criteria data giving a weighting to at least two of: the nature of the behaviour of the student in class; the identifier of any other student who should be included in the one of the plurality of classes with the student; the identifier of any other student who should not be included in the one of the plurality of classes; a balanced spread of academic abilities of students, between the plurality of classes; a balanced spread of special needs of students, between the plurality of classes; a balanced spread of originating class of students, between the plurality of classes; a balanced spread of originating educational institution of students, between the plurality of classes; or the student friendship selections of the student; the computer system processing the class data, the student data and the allocation criteria data to generate allocation data specifying an allocation of each student of the plurality of students to one of the plurality of classes.
2. 2. The method of claim 1, wherein at least one of the class data, the student data, the allocation criteria data or the allocation data is displayed on a graphical user interface and colour coded to distinguish, for each student, at least one of: student gender; a level indicative of academic abilities; a level indicative of historical academic performance; the nature of the behaviour of the student in class; the special physical and/or mental needs; the special emotional needs; or a stream which is specific to the plurality of classes.
3. 3. The method of claim 1 or claim 2, further comprising the steps of the computer system: receiving an instruction from a user of the computer system to move a student from one class in the plurality of classes to another class in the plurality of classes; wherein the step of the computer system receiving an instruction from the user to move the student from one class of the plurality of classes to another class of the plurality of classes comprises: generating, at the graphical user interface comprising a first area and a second area, a first list of students in a first class at the first area and a second list of students in a second class at the second area; receiving, from a user input device, a selection of a selected student in the first list at the first area and an indication to move the selected student to the second area; and updating the second list to include the selected student in the second list; and providing an indication of any student in respect of whom an item of allocation criteria data has not been met.
4. 4. The method of claims 1, 2 or 3, further comprising the steps of the computer system: sending a questionnaire to at least one teacher to gather student data about the student; receiving data gathered from the questionnaire which has been sent to the teacher; sending a questionnaire to the student to gather student data about the student; and receiving the student data from the questionnaire which has been sent to the student.
5. 5. The method of any one of the preceding claims wherein at least a portion of the computer system is cloud-based.