Electronic SIWES logbook evaluation in Nigeria should separate user requirements, prototype usability, record consistency and educational impact. A system can complete a task without proving that it improves supervision or learning. Start by deciding which question your campus pilot is meant to answer.
A new OAU case study provides a useful example of why denominators matter. Our analysis includes three charts, an evidence-layer infographic and four free CSV tools. The blank protocol and test logs are editorial planning aids. Use dummy records while designing tests, with appropriate institutional approval before any live pilot.
Electronic SIWES logbook evaluation in Nigeria: keep the samples separate
The study by Sholanke and colleagues, published 12 November 2026, reports a requirements survey of 629 students and a usability assessment involving ten participants. These are different evidence groups. The larger survey does not turn the prototype test into a 629-person usability study.
| Evidence group | Reported denominator | Question it addresses |
|---|---|---|
| Requirements survey | 629 students | What users report needing |
| Usability assessment | 10 participants | Experience with the prototype |
| Task completion | 22 assigned tasks | Whether assigned activities were completed |
| Record consistency | 150 sampled records | Whether checked records matched inputs |
Reconstruct task completion before interpreting it
For your own pilot, define success before testing. Does completion require a correct final result, no assistance and no duplicate submission? Record partial completion and help separately. Otherwise, two teams can use the same phrase while measuring different experiences.
Record consistency is another question
A record check should preserve the expected input and the actual output, using dummy identifiers. Include failed attempts and recovery behaviour. A final correct record can conceal repeated submissions or manual repairs if the test log records only the last attempt.
Read the usability ratings within their scope
A favourable rating can help identify an acceptable interface. However, a rating is not a measured reduction in feedback delays or stronger learning. Testing dates were not established in the inspected material. This is one institutional case, not a national adoption estimate.
Use an evidence hierarchy for the conclusion
Choose a primary pilot question and give it a measurable outcome. For example, “Does the new process shorten supervisor feedback delay?” needs defined start and end events. “Do users prefer it?” needs a different measure. Keep both questions if they matter, but do not substitute one answer for the other.
The blank protocol prompts you to state a baseline, follow-up period, comparison process and missing-case rule. Record likely alternative explanations, such as different placement schedules or supervisor workloads. Decide how you will interpret the findings before seeing the results, then preserve changes to the plan.
Plan a fair comparison without promising a result
A campus team might compare the existing and proposed workflows under a documented design. Choose a feasible allocation method with the appropriate academic and ethics oversight. State which students, supervisors, placements and tasks are represented. A convenient test group may not represent users with different devices, access needs or connectivity.
Keep the measurement window comparable. If one group receives additional training or more supervisor attention, record that difference. Also record exclusions and unavailable observations. An apparently faster average can change meaning if failed submissions or unanswered feedback requests disappear from the analysis.
Treat these as design questions, not a ready-made research protocol. The local team must justify its sample, instrument and analysis for the actual research question. Our worksheets deliberately leave those decisions blank instead of inventing a universal minimum sample or success threshold.
Test access, recovery and export as separate workstreams
Use controlled dummy accounts to check role boundaries, interrupted submissions, retries and export completeness. Document the expected behaviour and the observed result. Do not test another person’s account, extract real student records or assume that a high consistency percentage proves appropriate access controls.
The OWASP Application Security Verification Standard provides requirements for technical security verification. It can help a qualified team define a separate review. Referencing it does not certify a product or turn the reported usability exercise into a security audit.
For accessibility, consult the W3C WCAG quick reference and involve relevant users in appropriate testing. A successful task on one laptop does not settle keyboard operation, assistive-technology compatibility or mobile reflow. Keep access barriers and incomplete tasks visible in the findings.
Ask governance and procurement questions early
Clarify who controls records, who may view or amend them, how changes are logged and how information can be exported when a service ends. Ask the institution’s responsible officers about privacy, retention and approved use. A prototype demonstration alone does not answer those questions.
Before comparing costs, define what is included: hosting, support, training, migration, recovery and export. Keep an unanswered requirement as unresolved. Avoid claiming value for money until the proposed comparison uses equivalent functions, periods and service responsibilities.
Download the free evaluation tools
The reported-measures CSV preserves denominators and interpretation limits. The pilot protocol is blank, while the dummy-task log separates help, errors and retries. The final checklist records questions about permissions, recovery, export and governance. None requires you to submit student information to us.
- Reported SIWES measures and denominators (CSV)
- Blank campus comparison-pilot protocol (CSV)
- Blank dummy-data task and recovery log (CSV)
- Permissions, recovery and export questions (CSV)
For related placement context, see internship opportunities for mechatronics students. Our technical and traditional education overview addresses a broader education question. Neither is evidence that one logbook system improves learning.
Methods, limitations and citation
We checked the published study on 13 November 2026 and reconstructed its stated task, record and rating arithmetic. We did not access participant-level data, test the application or establish collection dates. The paper’s absence of a direct paper-process comparator limits claims about improvement. No causal effect, grading validity or security assurance is inferred.
The protocol, logs and evidence hierarchy are original editorial organising tools, not validated instruments. Three charts represent distinct measured questions without a filler comparison. Suggested citation: Disciplines In Nigeria, 13 November 2026, “Electronic SIWES Logbooks in Nigeria: Evaluate a Campus Pilot”, with Sholanke et al., DOI 10.11648/j.ijiis.20261504.12 and the stated limitations.
