Usability testing lab: audit a hard-to-use web shop and read a test in the browser

This lab gives each student a JupyterLab of their own with a small web shop that is hard to use on purpose: grey text that is hard to read, links that say only click here, boxes with no labels, pictures with no alt text, a focus outline removed, an error that says only Error 7 and a button too small to press on a phone. Beside it is the result of a usability test of that shop with twelve people, four tasks and a ten-question questionnaire, and short scripts that audit the page and read the numbers.

It is not an attack lab. Every copy has no route to the internet and none to any other student, so nothing can be downloaded into it and nothing in it can reach anybody else. The shop is made up and is a page to mend, not a real shop.

What students learn

How to look at a page the way a user does: the contrast ratio of text against its background, picture alt text, form labels, link words, the focus outline and the size of a button. Then how to read a usability test: the success rate and the median time of each task with pandas, the mistakes each task caused, and the score a ten-question questionnaire gives each person and the group. Finally how to fix a page, check the change in the live Preview and prove it by running the audit again. It suits introductions to usability, user experience and accessibility; check your own awarding body’s unit for the exact wording, none is quoted here.

Run it in your browser

The lab starts one service, jupyter, which writes the shop, the test data, the notes, a notebook and the short scripts into its work folder, and serves the shop from its own folder. Two links open from the lab’s page: JupyterLab, the workbench where a student edits the shop’s files and runs the scripts, and the Preview, the shop itself, which the student refreshes after saving a change. JupyterLab asks for no token, because the platform’s own door already knows who is opening it. The terminal beside the lab has no Python of its own, so it reaches the lab’s with docker exec jupyter, followed by the command to run inside.

  1. Open the Container page. Open Build on the bar and choose Run a container. Anybody may open it, and the Git lab and the SQL lab start with no account. Every other lab needs a free account: create one, sign in, then press Start.
  2. Find the lab. The Sample labs card lists every sample. Find Usability testing: audit a web shop.
  3. Press Start. Start runs it as it is, in one press. Edit the file first opens the compose file so you can change it before you start.
  4. Open it. On the lab’s page, the lab bar has two links. Press JupyterLab to open the workbench and Preview to see the shop in another tab. Then press Open terminal and type docker exec jupyter python3 steps/audit.py to see the counts of problems on the two pages.

What to ask students to hand in

The three files of the shop they changed (index.html, checkout.html and style.css), downloaded from JupyterLab with File, Download. With them, the output of the audit and the contrast check before and after, and a short paragraph in their own words on which problem the test found that they fixed first and why. Nothing is marked automatically: the paragraph shows whether the numbers were understood. For stronger work ask them to link each fix to a note an observer wrote or to a task with a low success rate, and to say what the test cannot show with only twelve people.

A basic lesson on this lab

Usability Testing Basics is a small lesson worked in this lab. In it a student lists the work folder and reads the observers’ notes, checks the contrast of the shop’s colours, audits the pages, reads the success rate, the median time and the questionnaire score of the test, counts the mistakes, and runs the audit again after a change of their own.

Free personal accounts have it in the Basics module, which is on Home, and every college can copy it from the Library’s Basics folder. It is deliberately small: it shows a teacher what a lesson worked in a lab is, and the lab does the rest. Copy it into a module of your own to change it.

The code on GitHub

The compose file has no Dockerfile: it runs one stock public image, the Jupyter Docker Stacks’ own scipy-notebook, pinned to a dated tag, as its own unprivileged account with 512 MB of memory. The image is licensed BSD-3-Clause and is not distributed by us. The file writes the shop, the test data and the scripts from a fixed seed when it starts, so every copy has the same numbers and nothing is downloaded, and it serves the shop with Python’s own simple web server in the background. The limits are honest ones: the shop is three small files, the test is made up and small, the audit checks a few common problems and not every one, there is no browser inside the lab beyond your own, and nothing can be installed from the internet. Nothing is kept when the lab stops, so a student downloads their files first.

Set it as work

Say in the task what to hand in.

  1. Make the lab. In your module add a task and choose the Container lab card, then In a GitHub repository. Give https://github.com/mitsurutech/lab-usability with the branch main. The compose file is the default, compose.yaml. Fork the repository first if you want to change it, for example to make a different shop or write different test results.
  2. Publish and try it. Publish pins the commit you were shown, so a later change in the repository does not alter a lab you have already set. Start your own copy first.
  3. Hand it out. Assign it like any task, with a due date if you want one, and say in the task what to do and what to hand in.
  4. Mark what is handed in. Open a student’s copy and the work they handed in, mark it, and send it back with a reason if it needs more.

Try this lab, and what it costs

A free personal account can work through the basic lessons in this lab, with enough free credit each month to follow most lessons and no card. For a class, a school or college has its first 365 days free for up to 50 students, then pays per student a year, with every lab included and staff free.

Questions people ask

Why is there no token or password to type?
A lab’s web page is reached only through the platform’s own door, which already knows who you are and lets in only you and the staff who teach your module. So JupyterLab is started with no token. Do not run it like that on a machine anybody else can reach.
Why does the terminal use docker exec jupyter?
The lab’s terminal carries curl, psql and a few other clients, and no Python. docker exec jupyter runs a command inside the lab’s own container, which has Python and every library. JupyterLab also has a terminal of its own, under File, New, Terminal.
Why does the Preview not change when I save a file?
The Preview is a static server on the shop folder, so it shows the file as it is on disk. Save in JupyterLab, then refresh the Preview tab; if the old page still shows, refresh it again without the cache.
Can students change the test data or add a page?
They can edit anything in the work folder, but not from the internet, which a copy cannot reach. To give every student another shop or another test, fork the repository, change what the compose file writes, and set the fork as the lab.