A technician field manual and hands-on support lab for diagnosing common desktop, network, application, and account issues.
The project demonstrates practical helpdesk habits:
- turn a user report into a clear troubleshooting path
- isolate likely causes before changing settings
- prefer safe, reversible fixes
- record actions, results, and escalation details in the ticket
- remove private information from evidence before sharing it
Open the live technician field manual or explore the full interactive lab.
| Artifact | What it demonstrates |
|---|---|
| Wi-Fi connected / no websites evidence pack | DNS and gateway checks, a topology note, a ticket resolution, and a short reflection using simulated data |
| Suspicious sign-in email runbook | Safe phishing triage, trusted verification paths, account protection, and escalation notes |
| Ticket closed without notes runbook | Ticket-quality review, user confirmation, resolution notes, and clean technician handover |
Six completed field-manual scenarios cover no display, Wi-Fi/DNS failure, low disk space, suspicious sign-in email, application crashes, and incomplete ticket notes. See the pilot modules index.
Entry-level IT support requires more than recognising technical terms. A technician must interpret symptoms, work safely, communicate clearly, and leave a useful record for the user and the next analyst.
This project turns CompTIA A+ material into realistic support scenarios and evidence that can be discussed in an interview. It focuses on the reasoning between receiving a ticket and closing or escalating it.
Every technician module follows the same five-question pattern exactly:
What happened?
Why did it happen?
How do I diagnose it?
How do I fix it safely?
How do I document it?
The working loop is deliberately short:
- Read the user-reported symptom.
- Check the safest and most likely causes first.
- Change one thing at a time.
- Confirm the result with the user or a defined test.
- Document the problem, action, result, and next step.
The interactive lab adds connector matching, hardware identification, topology tracing, simulated ticket movement, progress feedback, and an evidence-summary export. The Markdown runbooks remain readable without the app.
The project is a static HTML, CSS, and JavaScript site hosted on GitHub Pages. It has no application server and no build step for the main experience.
flowchart LR
Runbooks["Five-question runbooks"] --> Manual["Technician field manual"]
Activities["Interactive practice"] --> Manual
Manual --> Evidence["Ticket notes and evidence packs"]
Evidence --> Review["Privacy and safety review"]
Key areas:
app/ live field manual and interactive activities
pilot-modules/ six completed five-question technician runbooks
portfolio-evidence/ ticket notes, diagrams, results, and reflections
labs/ guided hardware, network, OS, and security practice
checklists/ session, safety, accessibility, and completion checks
datasets/ synthetic devices, symptoms, ports, and tickets
materials/ A+ source notes and course-sequence references
The wiki content is generated from local Markdown with node tools/build-wiki-content.mjs. Mermaid is loaded from a pinned CDN for diagrams; the source remains readable if the CDN is unavailable.
The interface is designed to be compact, predictable, and easy to scan under pressure. It supports visual and hands-on learning, short sessions, visible progress, and click/tap alternatives where drag-only interaction would create an access barrier.
ADHD- and autism-friendly choices include:
- the same five questions in every runbook
- one support problem at a time
- explicit start and stop points
- plain-language instructions beside technical terms
- diagrams before long explanations where useful
- safe simulated practice before changes to real systems
- Scenarios and ticket data are synthetic unless an evidence pack says otherwise.
- The intended reader is a new IT technician preparing for CompTIA A+ Core 1 (220-1201) and Core 2 (220-1202).
- Physical activities can be replaced with virtual machines, diagrams, or a router simulator.
- The project demonstrates learning and troubleshooting discipline; it does not claim production helpdesk access or unsupervised enterprise experience.
- A dedicated module should be treated as the source of truth for its scenario.
- Do not use real malware or send real phishing messages.
- Do not scan or change networks without explicit permission.
- Keep experiments separate from family, school, and work systems.
- Remove names, email addresses, public IPs, serial numbers, passwords, license keys, and employer data from screenshots and ticket notes.
- Power off and unplug hardware before opening a case; never open a power supply.
- Use a rollback point and preserve user data before OS, storage, or application changes.
Before treating a scenario as complete:
- The user-reported problem and success condition are clear.
- Diagnostic steps move from safe and simple to more invasive.
- The fix addresses the observed cause and includes a rollback path where needed.
- The result is confirmed, not assumed.
- The ticket note records the problem, checks, action, result, and next step.
- Shared evidence contains no private or identifying data.
- Relevant links and interactive controls work on desktop and mobile-width layouts.
For a completed example, inspect the sample networking ticket note, topology evidence, and reflection.
The current study targets are CompTIA A+ Core 1 (220-1201) and Core 2 (220-1202). Official objectives remain the authority when study notes and exam scope differ: