Teaching in the portal

Sign in at portal.shuleone.co.ke. Teachers get a tutor view rather than a learner view.

What is in it

Screen	What it is for
Overview	Your classes, and what needs attention
Quests	The quests your learners are working through
Submissions	Work handed in, waiting to be marked
Exams	Setting exams, and marking them
Classwork	Work set to a class
Marks	Marks from portal work
Open learners	Learners not attached to a class

Seeing where learners are

The class view shows each learner’s position on their quests, what they have completed, and what they are getting wrong.

The last of those is the one to use. It shows a topic several learners are failing on while there is still time to reteach it — which is a different kind of information from an exam result, and arrives about a month earlier.

Look at the class before the individual. Five learners stuck on the same stage is a teaching problem. One learner stuck is a learner problem. They need different responses.

Marking submissions

Projects and written work come to the submissions queue.

Open the submission, review the work, award marks and write a comment.

The comment is the teaching. A mark tells a learner where they finished; a comment tells them what to do next. One specific sentence beats three general ones.

Mark promptly. Work marked two weeks later has stopped being about the learning and started being about the grade. Little and often, rather than a weekend of forty.

For coding projects, look at how it was built rather than only whether it runs. A working project assembled by copying is worth less than a partly working one where the learner understood every block.

Running the coding pathway

The coding pathway runs like any other quest, with one difference: learners get stuck in ways that need a different response.

Teach reading the error. Most learners do not read them at all. The error usually says what is wrong and where. Making a class read one aloud before touching the code is the single most useful habit to build.

Do not fix their code. Ask what they expected to happen and what happened instead. The gap between those two answers is where the learning is, and taking the keyboard removes it.

Let them break things. The playground and the sandbox exist for that.

Expect the pace to spread. Coding classes spread further and faster than most subjects. Plan for the fast learners to have somewhere to go — extending their own project usually works better than more exercises.

Exams

Set exams from the tutor view: build the paper, set the window, activate it.

Before a real online exam, run a five-minute practice with the class. Every problem you will have on the day — a device that will not load, a learner who cannot sign in, a corner of the room with no signal — appears in the practice, when it costs nothing.

Marking picks up written answers; the rest is marked automatically. The per-question analysis is worth reading before you hand the results back.

Open learners

Learners not attached to a class — self-directed, or from outside the school — appear separately. They are visible if your school has enabled it, and they progress at their own pace without set work.

The portal and the classroom

The portal is at its best when it is doing something the classroom cannot: letting each learner move at their own pace, and telling you what they are getting wrong before an exam does.

It is at its worst when it is used as the whole lesson. Learners working through quests in silence for forty minutes are not learning much that they could not have learned at home.

Use it for practice, for the learners who need to go back, and for the diagnosis. Keep the teaching.