To help us plan SchoolTool's development process, we developed a few usage scenarios. In each scenario we make different assumptions about the level of technology that is available to the school community, and show how we hope SchoolTool will be used in such a scenario.  These scenarios are a few years old now and serve as guideposts to long-range development.

High Tech Deployment

In this scenario we assume widespread access to computers and communications technologies. Staff, students, and parents all have regular access to computers. Most also have PDA's and cellphones. The school has broadband internet access and its own web server and web site.

The school has a portal web site. Every student, staff member, alumnus and parent automatically has a home page in the portal, because it's connected directly to the schools SchoolTool instance. When a student signs on to the portal she immediately sees information that is customised and relevant. She is able to configure the information that shows up in her home page.

The most heavily used part of her portal home page is her personalised calendar. The calendar automatically reflects her class timetable, exam and test timetable, sport training times, club and society events and school-related special occasions. She is able to add personal events into her calendar, and view her calendar with or without all of these types of events. She can export her calendar so that friends and family can see it or include it in their calendars too.

She can also see a list of outstanding work assignments and tests. Each work assignment could be linked to relevant documents provided by teachers. A work assignment might include an estimate of the time required, which she could allocate in whole or in a series of parts onto her calendar to manage her time more effectively. If the assignment can be submitted electronically then she would be able to 'hand in' her work through the portal, and have it automatically flagged as completed.

The school web portal provides all the normal functions that one expects from a portal site. Messages can be sent to groups and individuals, she can monitor and respond to email through the portal, and participate in group discussions about work or social issues.

Her calendar and work assignment information is also automatically replicated and syncronised with SchoolTool software on her PDA, so that she has convenient access to this information at all times, even without network access.

A teacher uses the SchoolTool system heavily in the classroom and from home. The desktop or laptop computer in the classroom runs both a web browser for access to the school portal, and a custom SchoolTool client that provides the teacher with a comprehensive interface to SchoolTool functionality. The teacher uses the SchoolTool client to record absent and late students in every class, and to record the results of tests. These test results show up immediately in the portal system, and are available to students and their parents as soon as the teacher enters them into SchoolTool.

At home, the teacher marks work and captures the results into the SchoolTool client running on his laptop. Those results are transferred into the main SchoolTool database either over the internet from home, or when the teacher signs onto the school network in the morning.

Using the SchoolTool client or a web browser the teacher can also create work assignments for each of his classes, or for every student in a course, or for particular students. He can specify when an assignment is due and provide an estimate of the time required, as well as references to relevant documents.

If a student is marked as absent from a class, SchoolTool will follow school policy in deciding who should be notified automatically. For example, if the school is divided into Houses, then SchoolTool might automatically notify a student's housemaster that they had missed a class. If a student is consistently late for classes, SchoolTool might automatically notify a housemaster or subject head. And if a student is verified as being entirely absent from school, then SchoolTool might send urgent messages to the pager or cellphone of parents and responsible teachers to notify them of the situation.

A student's academic history is available to the student, her parents, to teachers, and to people with designated access privileges to that information. All test results are captured and stored in SchoolTool. The teacher is able to configure which tests contribute to final scores, and how final scores are calculated. Different forms of evaluation and scoring are supported. For example, a result might consist of a simple pass/fail or completion indicator, or it might take the form of a ranking of students in the class, or a symbol, or a percentage, or a mark out of some defined total. SchoolTool might in future keep track of student performance, and notify parents or responsible staff if a student's performance levels change suddenly.

This deployment of SchoolTool also makes use of its workflow capabilities. For example, the school has a policy of biannual reports from all teachers on all pupils. Twice a year the teachers are required to write reports on their pupils. These reports are then routed to housemasters for their commentary, and ultimately (only once a year) to the headmaster for his review and commentary.

Critical elements of this scenario are: a web portal for all stakeholders, that allows them to view relevant personal information from SchoolTool as well as providing standard portal type functions, a good workflow engine that allows us to route messages and documents requiring action to relevant parties, and track state changes.

Implementation note: we hope that it will be possible to provide modules for Zope, PHP-Nuke and other common portal toolkits to integrate SchoolTool information with whatever portal system the school has selected.

Low-Tech Deployment

In this scenario, we assume that the school has some technology and telecommunications capacity. This allows us to do data entry at the school. It may also allow us to use more of SchoolTool's functionality. The SchoolTool server would likely remain off-site, in a secure facility. Students and parents are unlikely to have ready access to computers or PDA's. There may be a few computers at the school for administrative and student access.

With one or more administrative computers on site, the school can install and use SchoolTool fat clients to provide specialized data capture facilities.  The fat client connects to the server over the internet, so the server does not have to be deployed locally.

Having more computers and greater data capture bandwidth allows the school to expand its use of SchoolTool to include a richer picture of school events. More test results are captured, since SchoolTool now is the easiest place for teachers to keep that data. The SchoolTool system is used to produce notices of events, and the broader school calendar is also managed through SchoolTool (clubs and sports teams publish their schedules through the system). Much of this information is still printed and posted on physical bulletin boards, but it is created and managed through SchoolTool.

Critical elements of this scenario are: the SchoolTool fat client, good report printing and publishing capability for schedules and calendars and notices.

No-Tech Deployment

In this rural / developmental scenario we assume that there is no SchoolTool server present on the school premises. Instead, the server is hosted offsite at a commercial educational outsourcing company that provides SchoolTool-related services. The school may be in a poor rural area with little or even no internet access. Students, teachers and parents are not assumed to have much or any computer literacy and access.

Why prepare such a scenario? Most schools in the world fit this description. Although technology and the internet have made extraordinary progress in penetrating the field of education, there is still a long way to go. In developing countries we hope to still benefit from SchoolTool by introducing standards in management practice and data capture that comply with SchoolTool's needs, even BEFORE SchoolTool itself can be deployed on site. And in those areas there is often an even greater need for high-level government and management oversight, and demand for high quality and timely planning information. We hope that SchoolTool can play a role in these situations, so the scenario is a valuable part of our requirements and software specification process.

The school admin team receive some training in SchoolTool, and are given a paper-based set of processes and procedures to implement. These processes cover only the essential elements of school administration: student registration, timetabling, time and attendance tracking, and results tracking. The school are expected to implement these processes, and capture relevant information on paper for later data capture. Ideally, a service provider visits the school each day and collects that paperwork, or captures the data directly into an offline SchoolTool client. A SchoolTool server is maintained on behalf of that school by a service provider. Data that is captured from paper is input to that SchoolTool server, or the SchoolTool client is syncronised with it, as often as possible, so as to have as current a picture of the school as possible.

The school structure, courses and timetable are all hard-captured before the start of the year - there is less room for customisation and tweaking, given that the data will be captured in advance and most likely over a web interface. Also, deployment is likely to be limited to academic aspects of school life - attendance and performance evaluation. No club, society or sporting information is likely to be captured at this stage.

Nonetheless we still have a functional SchoolTool instance that contains valuable data about the school. It is possible to include that school in planning and reporting exercises that give government insight into the state of education in the region. Over time, the school may increase its technology access, and migrate from an off-site solution to an on-site one (see the next scenario). But even in very poor environments, we can introduce the processes and use traditional data capture to bring schools into the network.

Critical elements of this scenario are: web based admin access, a set of paper-based procedures that complement SchoolTool, training materials to support these processes, the ability to manage large numbers of SchoolTool instances in a data centre, and the ability to operate 'core' services that map to simple paper-based processes without implementing the full suite of SchoolTool functionality.