* Pick all or any combination of the existing class-allocation requirements (friendship, gender, academic levels, behaviour, faith, sports, special needs, exclusions, inclusions, ...)
* Create your own customized requirement, such as "70% of our students play soccer and 30% play netball, and we want the same ratio in every class." Anything you can describe, we can add it into the system for you within an hour.
* Control how conflicting requirements compete with each other through each requirement's own weighting (prioritie).
* The created class lists are guaranteed to be mathematically most optimized according to your weightings.
* Allocates 200 students into 8 classes following 8 requirements in 5 seconds, 3 friends each student. See the real class lists created by Teacher's Pet for a real school.
* The "sympathy toward friendless student" feature guarantees one friend for each student, meanwhile minimizing the friendship requirement's competition with other requirements. This solves such an dilemma: "if I increase the friendship weighting, other requirements are suppressed too much, but if I reduce it, some students won't have any friends."
* The "Pick-My-Friends" module sends secured emails to students and lets them pick their own friends on our portal. The whole grade can finish picking their friends within half an hour.
* Cater for split classes, e.g. a class that has 12 year-3 students and 9 year-4 students.
* Only allow one teacher to log into a grade at a time - prevents two concurrent users overwriting each other's work.
* Ignore long-lasting friendship: some friendship groups remain stable over many years and become exclusive to other students. The system tracks for how many years in a row a student has been requesting for a friend and actually got him/her. If you check the "ignore long-lasting friendship" checkbox below the friendship slider bar, and, if student A has been requesting friend B and actually got B for the last two years, and in the third year A requested B again, then the system will ignore this request.
* Click a button to move all students in one grade to the higher grade at the end of a school year.
* Enter student data manually on the portal, or upload an Excel spreadsheet in a few clicks.
* Depending on what requirements you pick, the system automatically generates a sample spreadsheet with required columns and some sample data. This way all you need to do is to fill data into the spreadsheets, then upload it.
* Store multiple class allocation results done with different weightings, and reload any of them later.
* Attach students to teachers - "Andy must be in Mrs. Smith's class".
* Keep student in certain house - "John's younger brother is in house RED so John must be in house RED too."
* Symmetric between data upload and download: starting with an empty grade, upload the student data spreadsheets, then download the student data into another set of spreadsheets. The two sets of spreadsheets are identical. Or you can download your data into spreadsheets, delete all data from system, then upload the spreadsheets. The data in the system will be restored to be identical as before the deletion, byte for byte.
* Upload-smart: you can upload the student data spreadsheets many times. No duplicate will happen. New data will overwrite old data.
| Attach a student to a teacher | "Andy must be in Mrs. Smith's class" |
| Keep a student in certain house | "John's younger brother is in house RED so John must be in house RED too." |
NOTE: Below are quite some technical insights into our advanced algorithm. You don't need to be an IT professional, but you do need to have a bit of technical mindset to understand it.
What differentiate our algorithm from other class list makers?
Why is our algorithm non-conventional?
The reason we have such capacities while other solutions don't, is that they all use primitive sorting algorithms (they openly admit it on their websites), which is technically impossible to do what we can do.
Our algorithm is fundamentally different from sorting. It is non-conventional. It doesn't know any of the class-allocation requirements that are listed on our website - it doesn't know there is a requirement called "friendship", or "academic levels", or "gender balance", and so on. What it has is a higher intelligence - it is able to interpret the description of any requirement, and work out on-the-fly how to fulfil this requirement.
For example, the description of the friendship requirement is "Each student should be given as many friends as possible", while that of the gender balance requirement is "Each class should have roughly the same number of boys and girls". Obviously such descriptions are not stored internally in our system as plain English - they are translated into a set of codes that a computer understands.
Every school is different. They may have different requirements on their class lists, and their priorities given to the same set of requirements may be different. A class list maker without the capability to create arbitrary new requirements and handle different priorities simply won't work for the schools.
How does our algorithm work?
When a teacher in grade 3 clicks the "Create class lists" button, the algorithm goes to the database to find out what class-allocation requirements have been selected by the teacher for grade 3. Then it retrieves the encoded descriptions of all the selected requirements, interprets them, and works out what should be done for each requirement. It doesn't care what these requirements are called. All of such interpretations are done on-the-fly within a micro second. Then it immediately starts the class allocation process. It finishes in a second, and your new class lists are displayed on the screen.
Obviously, different requirements often conflict with each other, and may require the algorithm to do things contradictorily. This is when the algorithm consults the weightings that the teacher has set for each requirement, and decide which requirement takes precedence.
A good analogy
Here is a good analogy that will help you further understand this non-conventional intelligence of our algorithm. A conventional software component is written like a stamping machine which makes a particular type of stainless steel bowls. If you want to make a larger or smaller bowl, or a different product like a kitchen knife, the die used by the machine or even the machine itself must be modified or replaced. That is why all other class list makers on the market can only handle a fixed few class-allocation requirements - every new requirement needs their algorithms to be modified.
In comparison, our software is created like a science fiction robot. This robot is not hard-wired to do anything. Without instructions it cannot do anything and is therefore totally useless. But it has an intelligent brain which can interpret complex instructions. Given a set of cooking instructions, this robot can pick up a wok and make you a delicious Kung Pao Chicken, while given a set of mechanics instructions it can pick up screw drivers and spanners and pull an engine apart then put it back.
Because our algorithm is not hard-wired to know any requirement, but it can interpret requirement descriptions and work out what to do on-the-fly, it can handle infinite varieties of class-allocation requirements, some of which may not even be known at the time when the algorithm was created. Any peculiar requirement can be converted into a encoded description and put into our database in a hour's time, then our algorithm can immediately interpret it and start to create class lists in the required manner.
