Introduction to Computer Science YMT113 · Fall 2026 Assoc. Prof. Ferhat Uçar
14 HCI & Projects Monday, December 21, 2026

Human–Computer Interaction and How Software Gets Built

Software is used by people and built by teams. Usability principles you can apply to your project this week, and a tour of how industry ships software: Git branches, code review, tests, CI, and the roles on a team. The lab is a project workshop.

CS50Week 9 · Flask (optional: if your project has a web part) ReadStanford CS101: software; Nielsen's 10 usability heuristics

Before class · do this at home

Watch, read, then come

CS50x 2026 · Week 9: Flask (optional: if your project has a web part) by David J. Malan. Watch the lecture on YouTube (you are also enrolled on edX), read the notes, skim the slides. Our lecture builds on it instead of repeating it.

Learning objectives

By the end of this week you can:

  • 1 Apply usability heuristics (visibility of status, error prevention, consistency, feedback) to a command-line or web program.
  • 2 Explain affordances, feedback loops and why error messages should say what to do next.
  • 3 Describe the software development loop in industry: issue → branch → commits → pull request → review → tests → merge → deploy.
  • 4 Use Git branches and write a pull request description.
  • 5 Name the roles on a software team and what each does with your code.
  • 6 Prepare a five-minute technical demo.

★ the wow moment

The Therac-25 killed patients with a user interface, not a physics error.

A 1980s radiation-therapy machine delivered lethal overdoses because a fast typist could enter a mode the software did not expect, and the error message said only ‘MALFUNCTION 54’. The code was one person's, never reviewed, never tested against real use. Every practice in this week, usability, review, tests, exists because of stories like this. Your project's error messages matter.

Topics

  1. People first: affordances, feedback, consistency, error prevention and recovery; good and bad error messages from your own labs.
  2. Nielsen’s heuristics applied to a command-line program and to a web page.
  3. How software is built: issues, branches, commits, pull requests, review, automated tests, CI/CD, releases; the roles: developer, reviewer, QA, designer, product manager, SRE.
  4. Git beyond push: git branch, git checkout -b, git merge, resolving a conflict, tagging v1.0.
  5. The demo: structure (problem, 30 seconds; live demo, 3 minutes; what you learned, 1 minute; questions), rehearsal, and what to do when it crashes live.

No new lab: project workshop

The lab slot is yours. Bring your project to the room and use the instructor: code review on request, help with tests and README, and a dry run of your demo in front of one other student.

In industry

  • Pull requests are how code enters the world

    At Google, Microsoft and every serious open-source project, no line of code is merged without a second person reading it. Code review is where most learning on the job happens.

  • CI is your autograder, grown up

    The GitHub Actions run that grades your labs is the same system that runs a company's tests on every push. You have been using industry tooling since week 2.

  • UX is a profession

    Designers, researchers and accessibility specialists work alongside engineers. The heuristics you learn today are their daily checklist.

  • Demos decide

    Startups raise money, teams get budgets and features ship on the strength of a five-minute demo. Week 15 is practice for that.

Go deeper

Tags:HCIusabilityheuristicsGitbranchespull requestcode reviewCIdemo