UMass Lowell Dept. of Computer Science

COMP 4620 — GUI Programming II

Spring 2016 Semester, Section 201

Prof. Jesse M. Heines

Notes for Class No. 11

Introduction to Usability Testing and Using MongoDB

Thursday, February 25, 2016

A video of this class is (or will be) posted at:  http://echo360.uml.edu/heines2016/comp4620-201.html


Handouts and Materials


Openings / Announcements / Reminders

The GUI Programming project sequence is not dying just because I’m retiring!

I have been asked to remind and encourage you to please take the NSSE survey

I have also been asked to remind and encourage you to take advantage of the Drop-in Resume Makeover event on Tuesday, March 1st

Code School courses, at least some of which are free


Class Notes

Related reading for this class:  Handouts and GetMEAN: Chap. 6


Introduction to Usability Testing

I want to try to present the entire “big picture” today, but you’ll only do part of this in next Tuesday’s class (March 1, 2016)

Documents Needed for Usability Tests

  1. Instructions to be read to the test subject
  2. Tasks to be performed by the subject on a form that you will hand to the subject for him or her to follow during the usability test
  3. A form to be used by the evaluator (yourself) to record what happened during the test
  4. Questions you will ask of the subject after the test

Before the Tests

  1. If you have time, it is nice to add “hooks” to your software to capture users’ actions
  2. Test the software thoroughly yourself and with the other member(s) of your project team
  3. Identify potential users who are available to test your software
  4. Write down the directions you will give these users when they come to take the test
  5. Write down the things you will want users to do
  6. Make sure you have everything you need to take notes during the test

During the Tests

  1. Stick to your plan
    • don’t deviate from your written directions
    • don’t answer too many questions, let the user try to figure things out
    • don’t “improvise,” make every test the same
  2. Sit back and silently watch the subject use your program
    • watch carefully -- be as observant as possible
    • look at facial expressions for signs of confusion
  3. Take copius notes during the test! -- write down everything that you observe
    • do not “filter” your notes at this point, just write down everything
    • you can analyze and filter the notes after the test is completed, but you get only one chance to record what went on
    • try to record how the user was reacting at specific, identified points in the program
  4. Do not talk to the subject during the test!
    • if the subject asks a question, reply with something like, “What do you think?”
    • if you must answer a question, try to give a simple “Yes” or “No” answer
    • do not interrupt the subject for any reason
      • exception: when it’s time to end the test
      • exception: if he or she is obviously stuck and cannot proceed and is getting frustrated
      • let the subject “struggle” for at least 60 seconds before you interrupt, which can feel like an eternity
  5. If you have to “bail the subject out,” just fix the problem and let him or her continue
  6. Be sure to thank the test participant

After the Tests — With the Subject

  1. Ask the subject to describe his or her experience before you start asking specific quesitons of your own
  2. Ask all subjects the same questions in the same way
    • as with the directions, the best way to ensure this is to write your specific questions down beforehand

After the Tests — “Back at the Office”

  1. Organize your notes
  2. Review them with your fellow co-workers
  3. Prioritize the changes suggested by the tests
  4. Make those changes that you can

Final Step — Writing Your Reports — to do immediately after testing or being a test subject

Final Step — Writing Your Report — for Assignment No. 2

  1. I am expecting a report of about five pages in length
  2. Your paper should report:
    • the details of what happened during your tests
    • the changes you plan to make in the final version of your software based on these results
    • the changes your tests indicate should be made but that you simply don’t have the time to do
    • your conclusions about the quality of your user interface
  3. Use the Short Usability Test Report Template { DOCX | PDF } to guide your work
  4. See the grading criteria in Assignment No. 2 as we discussed in our last class

Brief review from last class ...


Writing a REST API (Ch. 6, p. 160)

Overview

The type of API that we will be building is called a REST API

Here’s where the REST API fits in our application

and here, in a nutshell, is how it works


Syntactic Details

Each CRUD operation has a URL path and optional parameters (p. 163)

The requests are differentiated by the method that each operations uses (or with which each URL path is called) (p. 163)

Putting these two together we get (p. 164)

When subdocuments are involved, we add the subdocument path to the URL (pp. 164-165)

Response and status codes (p. 165)


Please don’t forget to fill out the Google form as you review each other’s projects on Tuesday


This is document http://jesseheines.com:8080/~heines/91.462/91.462-2015-16s/462-lecs/lecture11.jsp.  It was last modified on Friday, August 26, 2022 at 4:09 PM.
Copyright © 2022 by Jesse M. Heines.  All rights reserved.  May be freely copied or excerpted for educational purposes with credit to the author.