The Course
This course is a combined graduate and undergraduate HCI course. The course is primarily hands-on, i.e. you learn by completing projects. Graduate and undergraduate students meet together and assist each other in their projects. The undergraduate projects are group projects emphasizing design and implementation of a user interface (UI), while the graduate projects emphasize evaluation and usability testing of the undergraduate UIs.
Undergraduate Course
Most of the work in the undergraduate projects consists of implementing an Android application (app). In the process of designing and implementing the UI you will:
- form groups
- propose a project (document)
- make a web site for your project
- identify the users and tasks of your app (document)
- present you initial app design (documents and presentation)
- review your app design with me (interview with me and other)
- implement your app (programming)
- present your final app (documents and presentation)
- assist in the usability testing of your app
- review your project with me (interview)
There is not much time in a semester to finish all the work, so we must get started immediately. Today and tomorrow you should start forming your groups. Read the project description and select an app idea for a project. I will introduce the app ideas in the next lecture.
By the end of the week, I will need a list of your group members so that I can have system administrators make your group project directories. Please send me an email of your group selection using the subject line:
cs4760 – Group and app selection
All your documents and implementations should be uploaded to the group directory. Your website will contain links to your documents, so that I can review them. Please do not redirect your website to another machine. I keep the website as a record of your work. Your group will make your implementation publicly accessible at a suitable time.
You will implement your project using the Grails Framework. There are programming assignments, tutorials that introduce you to the IDE (IntelliJ), Groovy and Grails Framework.
Graduate Course
The work in the graduate course consists of two parts:
- Assisting with the design of the undergraduate app and evaluating the app.
- A presentation and a paper on any topic in HCI.
- Specifically you will assist the undergraduate groups by:
- identify stakeholders and creating personas for the undergraduate UI projects (documents)
- make a heuristic evaluation of the undergraduate initial UI design (documents)
- design a usability test of undergraduate UI implementation (document)
- administrate a usability test of the undergraduate UI (work)
- write up usability test results (document)
My intent is not that you, the graduate students, manage the undergraduate projects, rather you assist the undergraduate groups much like a User Experience Consultant. So, I will assign you be assigned to a team, but please refrain from being their boss. You will discuss your analysis or findings with the undergraduate groups and give them links to your documents so that they can post the links on their website. Your goal should be to make the undergraduate projects better.
Beside evaluation and testing of the undergraduate projects you will individually study an advance topic in HCI. I have provided a list of topics just as example of topics, see graduate project description, but the topic is your choice and may be any topic in HCI. You will give a presentation to the class and write a short paper on the topic. The presentation and paper are different. The presentation is a general introduction of the topic suitable to the audience, undergraduate and graduate HCI students that do not know much about the topic. The paper is written before the presentation and is for me to read. You should assume that the reader of your paper, me, has a general understanding of the topic, so your paper extends the topic given in the presentation. I will be interested in reading about your unique ideas. I realize that you do not have time in a semester to completely test or verify your ideas, but you can propose them and justify them by what you have read in the literature. There is not much time in the semester, so please email me early your topic ideas. Your email should have the subject line:
cs5760 – Topic selection
Course Interactions
Looking at the course schedule, you will notice that during almost every class period there is some interaction between groups.
- Undergraduate groups make design presentations.
- Graduate and undergraduate students meet and discuss analysis.
- Graduate students present their topics.
- Graduate and undergraduate students meet to design, conduct and discuss usability testing.
- Class attendance is mandatory. Be courteous to the rest of the class and arrive on time. I cannot micro manage all the groups and interactions, so I will expect you all to manage yourselves.
I will not have time to lecture all the topics that you should learn, so I expect that you will read the text books on your own. The undergraduate text book is
“Interaction Design: beyond human-computer interaction” by Preece, Rogers and Sharp (any edition)
The book is good and covers a lot of the topics. My only complain about the text book is that it is a little disjointed, written by three authors. The graduate text book is
“Usability Testing and Research” by Barnum
The text book is very comprehensives, but still does not cover all the usability testing techniques. Graduates students may want to get both text books.
Many of the interaction and communications is via email. I will email graduate group via a class email list, so make sure that you are receiving these email and read them within the day that they are sent. I assign graduate student to the undergraduate group by email using the subject line
cs4760-5760 – Grad group assignments
Grad and undergrad students should read the emails immediately. The grad student should contact the group within 24 hours. At a minimum the grad students can introduce themselves, but typically the grad students will need to arrange for meetings. The group should reply immediately (within 24 hours). If the grad student should make the initial contact in 24 hours, the group should send an email to the grad student with me cc.
Project
This semester the class participates in a NSF Grant:
CI-TEAM Demo: Environmental CyberCitizens: Engaging Citizen Scientists in Global Environmental Change through Crowdsensing and Visualization
This is a citizen science project which means ordinary citizens collect data for scientists. In this project, the citizens will collect the data using Android phones and the data will be uploaded to a server for both the citizen and scientists to use. Students in the senior design course will make the website for visualizing the data collected by the citizens. Most app projects the citizens are high school, community college, and MTU students. Other users are the teachers and instructors of the students. Their classes may go on field trips lead by the instructors and teachers to Lightfoot Bay and other reserves of the Keweenaw Land Trust (KLT).
The scientists of the project are MTU professors, professors at other universities, National Forrest Service scientists and scientists at other governmental agencies. I will explain more about the scientists and their app ideas in the next lecture, but you can review their app ideas in scientists. You project will implement one of their app ideas.
This is a multi year project. You are participating in the thrid iteration of making Android Citizen Science apps.
HCI and Users
Human-Computer Interaction is the study of people using machines. The topic is very diverse and probably the most interdisciplinary topic in the computer science. I like to describe HCI as having three sides or aspects; the human user, the machine/system and the interaction between user and machine. On the computer side of HCI, computer scientists are assisted by engineers to develop new devices, for example the weii or data gloves. On the human side, computer scientists are assisted by psychologists to understand the user of the machine, their needs (tasks) and desire (goals). Computer scientists get to sit in the middle creating a new side, the interaction. The interaction between users and machines is how work gets done by most users. It is more than computer graphics and more exciting because besides creating pretty graphics the interactions has a dynamic element, time.
Our course could concentrate on the interaction, but computer scientists have discovered that a successful UI should began with understanding the users of the UI, otherwise the UI is not very usable or useful. In the words of Raskin:
Use a machine or tool in accord with its strengths and limitations, and it will do a good job for you. Design a human-machine interface in accord with the abilities and foibles of humankind, and you will help to not only get the job done but also to be a happier, more productive person.
Stakeholder Analysis
If I asked, “who is your user of the system?” you would probably answer describing the person using the system, the user. Software and computing system are not used by a person in isolation. We should really ask, “who are the people effected by the system?” and “who are the people that can effect the project?” People affected by the technology or have influence on the project are called stakeholders. This is a socio-technical model of software or system uses.
The onion model for stakeholders is described in
Understanding Project Sociology by Modeling Stakeholders
Stakeholder Onion Model:
The project is represented by four concentrate circles
- Kit – In this course, your app is part of the kit, but also the project and the “system” is part of the kit. The kit is all the hardware and software associated with the project
- System – Generally in this course, all the users, primary and secondary users are part of the system.
- Containing system – They are stakeholder that use the results of the system or provide input to the system.
- Wider environment – They are stakeholders that have influence on the project, for example the developers.
Example: Army App Stakeholder Onion Model
The modern army use smart phones, even on patrol. We are requested to create an app for army personnel to use while on patrol. Squads of soldiers lead by a sergeant patrol areas looking for any suspicious object or activity. Officers think that each solider should carry a smart phone and document any suspicious objects or activity. The documentation can be uploaded to a secure web server so that officers in the command center can analyze the activity and send commands.
Who are the stakeholders?
Instead of drawing the onion we can make annotated table:
| Kit | System | Containing System | Wider Environment |
| App designers
Programmers App evaluators
General Security officers other officers | |||
| Drill Sergeant | Drill Sergeant | ||
| App | |||
| Field Soldiers
Field Sergeants | |||
| Commander | |||
| General | |||
| Viewer designers
Programmers Viewer Evaluators
General Security officers other officers | |||
| Server
Viewer | |||
| Intelligence Soldiers | |||
| Commander | |||
| General |
Description of System and Stakeholders:
- App is the smart phone application
- Server is web interface and database for the documentations
- Viewer is the software for viewing the data
- Field soldiers use app to document suspicious activity
- Field Sergeants use the app but also direct field soldiers
- Drill Sergeants train field soldiers
- Commander provides assignments
- App designers design the smart phone application
- Programmers code the app
- App evaluators evaluate and test the app
- General is the officer, client, in charge of the project for developing the app
- Security Officer is one of many officers that report to the general assuring that the app is ok
- etc.
Primary and Secondary Users
We have encountered several different users: soldiers, sergeants, and drill sergeants. I like to classify users into levels: primary and secondary users. Primary users are the intended primary users of the app and are the target user of the design. Secondary users are unintended user or users that were not primarily designed for. In this example, the field soldiers and sergeants are the primary users. The app is designed for the field soldiers and sergeants. The secondary users are the field and the drill sergeants. The field sergeant may use the app to view field soldiers’ documents. The drill sergeant uses the app to instruct the field soldiers.
Stakeholders Goals and Influences
All stakeholders either use the system or influence the project. They all have goals that are associated with their influences. The onion model uses a stakeholder analysis table, which associates stakeholder roles with knowledge classes. This table is appropriate for larger project and insuring that all stakeholder are found and all knowledge classes have stakeholders.
For our smaller project, I suggest a simpler table that delineates the stakeholders’ goals and influences. There are two types of influences: contributing and constraining. Contributing influences are what the stakeholder can give to the project, for example data or code. Constraining influences are how the stakeholder limits the design of the system.
Example: Army App Stakeholder Goals and Influences
| Stakeholder | Goals | Influences | |
| Contributing | Constraining | ||
| Field Soldiers | Safely collect documents | documents | Easy and fast interactions |
| Completely collect info | document details | Comprehensive app | |
| Field Sergeant | View documents in field | Viewing access | |
| Squad safety | Warnings | Alert broadcasting | |
| Drill Sergeant | Exercises | Exercises | Programmable inputs |
| View results | Viewing access | ||
| Commander | Assign missions | Missions | Mission assignment |
| View process or doc | Viewing access | ||
| Interrupt mission | Interrupts | Interrupt alerts | |
| Through coverage | Maps and routes | Input for maps and routes | |
| Successful mission | Mission success criteria
App designs | design constraints | |
| General | Successful project | Project success criteria
Project designs | Project constraints |
| Security Officer | Secure app | login protocols | app constraints |
| Secure communications | Frequencies
Authentication protocols | app communication | |
| etc |
This table can be used to help design the project and the app. It further defines the role of the stakeholders. It helps to delineate what stakeholders to elicit for help.
Application Familiarity
We can divide the users into groups by the familiarity with the tools to perform the tasks. This was very popular division of users when computers first become available. The notion makes sense because novice and experts have different experiences using UI, and required different support. Because computer UI is more cognitive than most tools the division between experts and novice is measured by the how well the user understands the metaphor of the application, i.e. how well the user can anticipate the outcome of the interactions.
Novices are first time user of the tools. They are afraid of making a mistake and looking foolish. They just want to get the job done. Learning the system is hard. They do not understand the system, and their metaphor for the system is frequently wrong. They have no idea how to fix the problem
Advanced Beginners are not afraid of making a mistake, but they are still learning the system. They are more interested in getting the work done. Their metaphor or model of the system frequently fails, but they can recover from errors.
Competent Performers begin to have a correct metaphor or model for the system. They can anticipate the results of interacting with the system. They can perform a complex system of tasks to achieve a goal. General occurs after using the system for a few months.
Expert Performers are more interested in the system than solving problems. Then tend be teachers and support staff for the system. (Expert has a special meaning in HCI and means domain expert, not expert of the application.)
Who should you design the UI for? Depends how frequently your UI will be used. Also depends if the UI can leverage metaphors form previous experience. Design for all levels, but special attention to the novice and advance beginners. What can we do for each level?
Other aspects of User Analysis
- Learning style, e.g. “read and then do” or “do and then read” type people?
- Physical differences, e.g. disabilities, difficulty seeing or reading small font, small children
- Cultural differences, e.g. education, profession, or corporate style
- etc.
How can you learn about users?
Learn from others by reading or talking to the boss. What are the pro and cons? You can learn a lot correctly, but does it make sense to learn from the boss (tertiary stakeholder) about how trades man do their job? Would it make sense to learn from the General about the Army app or would the Commander be better to learn from?
Survey potential users, but responders to the survey may misunderstand the questions or answers. The survey can only illuminate what it asks about. Nevertheless surveys can directly query many primary users. Also the results can be quantified. Surveying requires more work then learning from others.
Interviewing potential users is an open ended process. The potential user may not really know tasks. Does it make sense to interview the field soldiers before they have used the app in the field? The interviewee may have forgotten important details. Also the interviewee may be giving misleading the answer. This frequently occurs when the interviewee give their answers as conclusions rather than their experience. The interviewer can try to ground the conversation, meaning asking specific questions about facts and direct the conversation to actual experience. Interviewing is much slower. Similar technique is using focus groups, and role playing.
Observing potential users is a grounded field work technique to learn about users. But you cannot ask the observed, “Why did you do that? What were you thinking?” You can ask users to think aloud, but this may interfere with their work. Sometimes it is not possible to observe users. You could interview right after the tasks, or use video tapes.
Ethnography is a technique where the observer participates in the job. In this technique the designer understands users and even has empathy for the users. But some times the designer is mistaken. Is it practical for the designers of the Army app to use ethnography?
Human Psychology
Because ultimately computers are used to solve problems and perform tasks, it is appropriate to study how humans typically solve problems and perform tasks. We are interested in the human cognitive processes: memory and reasoning.
Memory
Much like computer memory, human memory can be modeled as a hierarchy:
- Sensory memory – last 30 ms to 1 sec
- Iconic – visual
- Echoic – audio or aural
- Hepatic – tactile
- Short-term memory – 5 chucks plus or minus 1, Chris Blazek’s master theses suggest chucks of 4, last approximately half second.
- Long-term memory
- Episodic – event or procedure recall
- Semantic – meaning based, model as a network
Sensory memory behaves very much like buffers for input devices on the computer. Short-term memory is very much like RAM. It is volatile, fast and limited. Long-term memory is similar to a hard drive; it is long lasting, slow and large.
Forgetting? Typically there are two process of forgetting:
- Decay
- Interference
- retroactive interference – memory lost due to learning new items
- proactive inhibition – old memories interfering with new memory
Implications of human memory on HCI design:
- Don’t expect the user to remember anything longer then a half second and more then 4 chunks.
- If the task is explorative keep the response time to a half second, so what while the user is exploring the data is still in his short-term memory.
- Response time faster then 30 msec will be perceived to be instantly
Age?
Reasoning
- Physiologists have identified three forms of reason
- Deductive – rule based, e.g. ( A => B and B => C ) => A => C, or specifics from generalities.
- Inductive – Inferring generalities from examples
- Abductive – Inferring a cause from an act
Typically we learn by induction and abduction but never by deduction unless you are a mathematician. Abductive learning is very fast and perhaps the most primitive. It is learning by experience; if event occurs after an act then we suppose the act caused the event. After we learn we acquire skill by creating rules.
Implications of reasoning on HCI design:
- Expect the user to learn the UI by abduction or event based experience; consequently try to keep responses synchronized.
- Do not ever expect new users to know rules, and having to learn rules to operate the UI will increase learning time.
- Use positive logical assertion in coding.
Cognition
Chapter 3 in Interaction Design by Preece, Roger and Sharp discusses cognition and its effect on design.