Human-Computer Interaction
Human-computer interaction is the discipline this entire series has been relying on without naming, since every single topic so far was deployed, then checked not just for technical correctness but by actually looking at how it renders for a real reader on a real screen. Interface design is how a program presents itself and takes input, building directly on the event-driven programming the programming-paradigms topic introduced: a button waits for a click, a text field waits for typed input, and the whole interface is really just a collection of event handlers wrapped around whatever the program is actually doing underneath. Usability asks a sharper question than correctness alone: not just "does this work" but "can a real person actually accomplish their task with it, without confusion or wasted effort" — and this is exactly the gap this series' own testing checklist from the software-engineering topic couldn't close by itself, since a passing JSON-validity check or a clean overflow audit says nothing about whether a flowchart is actually readable on a narrow phone screen, which is precisely why every topic in this series has also been checked with an actual live screenshot on a simulated mobile device, not just the automated checklist alone. Accessibility narrows usability to a specific, often legally required case: making an interface usable by people with different abilities, like enough color contrast to be readable with low vision, a layout that still makes sense to a screen reader, and controls that can be operated by keyboard alone for anyone who can't use a mouse or touchscreen — none of which a program can verify about itself, since passing automated tests says nothing about what an actual assistive technology experiences. User evaluation is the practice of checking a design against real people, or at minimum a close, honest simulation of them, rather than trusting that a design that makes sense to its own creator will make sense to anyone else — the exact reason this series takes a literal mobile screenshot and reads it rather than only trusting its own content-validation script, which has in fact caught real problems the automated checks alone missed. None of interface design, usability, accessibility, or user evaluation can be fully automated away, because they are all, at bottom, questions about a human being on the other end of the screen, not questions about the code — and the final topic in this series, computing ethics, is what happens when that same question — who is this system actually for, and how does it treat the people who use it — gets asked about fairness, privacy, and consequences instead of interface design.