HCID 520: User Interface Software And Technology (Winter 2024)

📅 Schedule

Date	Topic and Chapter Due	Second Reading Due	SWOTs
Thurs, Jan 4	Course overview	—	—
Tues, Jan 9	History	As We May Think	#1 (GUI) start
Thurs, Jan 11	Theory	Direct Manipulation Interfaces (pdf)
Tues, Jan 16	Mediation	Distance Matters
Thurs, Jan 18	Accessibility	Ability-based design
Tues, Jan 23	Programming Interfaces	Learning Barriers
Thurs, Jan 25	Interactive Interfaces	Inventing Lisa	#1 due, presentations
Tues, Jan 30	Architecture	Handling Uncertainty	#2 (Programming) start
Thurs, Feb 1	Pointing	Beating Fitts
Tues, Feb 6	Text	Text Entry for Mobile
Thurs, Feb 8	Hands	Computer for the 21st century
Tues, Feb 13	Bodies	Human-Computer Integration
Thurs, Feb 15	2D	From Cartoons to UI	#2 due, presentations
Tues, Feb 20	3D	Recent Advances in AR	#3 (Future I/O) start
Thurs, Feb 22	Physical	Tangible Bits
Tues, Feb 27	Help	Software Learnability
Thurs, Feb 29	Intellectual Property	Look and Feel Lawsuits
Tues, March 5	Translation	Translational Science for HCI
Thurs, March 7	—	—	#3 due, presentations
Tue, March 12, 4:30-6:20 pm	Ethics	Post-colonial computing	Snacks, future of computing, ethics, equity, and more

 

👋🏻 Welcome!

I'm Amy (she/her). You can call Amy, or Dr. Ko if you want to be formal. Your TA this quarter is the wonderful Jayne Everson and the excellent Claire Mitchell is joining as a co-instructor. Jayne is my doctoral student, a fantastic educator, and also a maker. Claire is Jake Wobbrock's doctoral student and has expertise in wearables and sensing. I'm hoping that our collective expertise will bring a nice mixture of perspectives to the class this quarter! Think of us all as your teachers, with me as lead.

I'm excited to explore the world of user interface software and technology with you this quarter! By the end of this course, I want you to:

• Know the past, present, and future of interface technologies
• Be able to articulate informed perspectives about interface technologies and their role in products and society, in written and spoken form.
• Be able to rigorously analyze the opportunities and limitations of interface technologies, especially through the lens of human diversity, in written and spoken form.

We've devised a class that hopefully helps you learn the above, but it only happens if you engage consistently, focus on learning and not grades, and take full advantage of this rare opportunity to learn together.

 

💬 How to reach us

First, join Discord, and set your server nickname to your real name so that we can find you. That will be our primary point of contact, rather than Canvas, which has mostly horrible messaging, or email. Set your server profile's name to your real name, and preferable a headshot, so every knows who you are.

When you have questions:

• Read this syllabus first; 95% of the questions we get are answered here.
• If you're in class, ask us there during studio time.
• If weren't not in class, write #help on Discord and someone will reply.

You can also come to my office hours and talk to me directly about anything. I'll hold them Thursdays 4-5, just after class, in the studio, every week except finals week. I encourage you to stay and ask about anything! My time is hard to get, so make the most of this hour this quarter.

Expect replies within 24-48 hours on the weekdays, or sooner if we notice it sooner.

 

🧑🏻‍🏫 What will you do in this class?

Two things:

• Individually, read about interface technologies, including research papers that describe innovations, then write informed opinions about those technologies and share those opinions in class. Our foundational text will User Interface Software and Technology, a book I wrote specifically for this class.
• In groups, write four "SWOT" analyses (Strengths, Weaknesses, Opportunities, and Threats), in which you'll explain how an interface works technically, identify the assumptions it makes about who is using it and in what contexts, and then propose alternative designs that avoid those assumptions (but likely make others). These will be due every two weeks, starting at the end of week 4. On each due date, you'll present part of your analysis in class.

You can read more about each of those in the assignment descriptions below.

Each class will have the following structure:

• Recap (5 minutes)
  • Amy (or a TA if Amy is traveling) will present a recap of the key points, to set a foundation for our discussion
• Opinions (see details below)
  • Share your opinions in small groups of 2-3 (10 minutes)
  • An instructor shares their opinion (5 minutes)
  • We'll select 7 students randomly to present to the class for 3 minutes each (20 minutes)
• Discussion (35 minutes)
  • Amy will curate a set of discussion themes, ground in the points you made.
  • She will facilitate a discussion of the core observations, debates, and tensions.
  • She will end by linking the key insights from the discussion to the analytical work in your SWOTs.
• Studio (35 minutes). See details below about the SWOT assignments.
• Recap (5 minutes). We'll surface any questions or challenges that arose during studio, connect the analysis to the topics of the day, and recap the core ideas from the day.

This class will be 100% in-person, given the primarily collaborative, active learning nature of the activities (aside from the 25 minutes of short presentations). If you are traveling, ill, or otherwise cannot attend, there unfortunately will not be remote options at the class level. However, during the collaboration time, I encourage you to work with your teammates to arrange remote participation if you cannot join in-person. You are also welcome to backchannel on Discord during class, which will give you some real time experience during class.

📜 Expectations

Throughout all of the learning experiences above, I expect you to:

• Come prepared
  • Read the required reading before the class in which we discuss it
  • Come ready to share ideas and get feedback on writing
• Have humility about each others' different positions, power, and privilege
  • Do proactively fix inclusion issues or report them to a TA or instructor
  • Don't assume everyone has the same resources or rights as you
• Respect everyone's identities and lived experiences
  • Do respect names, pronouns, and pronunciations
  • Don't make assumptions about who someone is or what they believe
• Be responsive to your instructors and each other
  • Respond to emails and other messages within a few days
  • Never ghost a collaborator unless someone's behavior is harassment 
• Credit other people for their work
  • Do give explicit credit for any images, video, or other content you reuse or generate with tools
  • Don't copy other people's writing or content and present it as your own
• Prioritize learning over grades
  • Do ask questions and pursue curiosities
  • Don't obsess over points and GPAs

And I expect everyone in class to help assert these expectations — you, your TAs, and of course myself.

Finally, a note about generative AI (e.g., large language models and other data-driven content synthesis tools). I view these tools as tools, and ones that are not particularly good at writing, illustration, or other content generation. They create a convincing illusion of intelligence to be sure, but by no means do they generate novel, meaningful, credible insight about the world. You may use them to generate the essays required in this course, and if you do, you must credit the tools and the billions of people who created the writing on which they were trained. However, my prediction is that the writing it generates will not be particularly good, or meet this course's highest standards, and so relying on them to do your thinking means not learning, and settling for mediocre thinking. My recommendation is therefore that you only consider very narrow uses of them for things like 1) spell checking, 2) first drafts of translations if you are an English learner, and 3) superficial feedback on your writing. At best, however, these uses will be supplementary to your mind and skills, because believe it or not, you are smarter than a predictive model of the public internet's hot takes.

 

📕 Informed Opinions

Reading is the centerpiece of this class. That's on purpose: you'll spend much of your time in Prototyping Studio making, and so in this class, we'll complement that by focusing on understanding.

Before each class, we expect you to read three things:

1. The assigned chapter from User Interface Software and Technology indicated on the schedule above, which is the anchor for the topic for the day. These chapters are broad, focusing on key ideas and concepts, but not addressing anything in depth.
2. The research paper indicated in the schedule above, which goes deep on some theoretical or conceptual aspect of the topic.
3. A research paper, podcast, or other resource of your choosing related to the topic of the day. This might go broad or deep; the only requirement is that you want to read/listen to it. It can be scholarly, popular, or anything else. The point is to complement the two required research readings.

Some readings are behind paywalls. You can use the UW Libraries Proxy Bookmarklet to gain access while off campus.

While we expect you to read every word of the assigned UIST chapter, and read/listen to every word of popular media, we do not expect you to read every word of research papers. Instead, we recommend this strategy:

• Read the title and abstract first, to get an overview of the concept.
• Read the introduction, to get a sense of the problem the paper wants to explain or address.
• If the paper has an example section that describes the concept, read that next. If it has a results section, skim it for the key insights, then read the discussion to understand their significance.
• If you have any remaining questions, you may read the methods or implementation sections for the details, but you can likely skip them. Sometimes the details are important for understanding a work and its limitations; sometimes they're only important if you want to build upon it.

This strategy won't work for all papers; some are more theoretical, and may take more time to understand.

To demonstrate that you read, we're only asking for one short thing: a 1-3 sentence post in the relevant discord channel (#topic-date) sharing a concern, question, insight, or idea you had while reading the two pieces. Here are some examples one might post after the History chapter:

• Concern: This chapter should have also talked about who funded all of these inventions. That's where the real power is.
• Question: Why was XEROX paying for all of this? Did they see some market opportunity?
• Insight: It strikes me that most of these inventions were motivated by desks. I wonder what kind of computing we'd have if everyone had been remote like we are today?
• Idea: I think there are things we missed from the desktop metaphor that we could still explore, like what role the surroundings play (privacy, focus, etc.).

I will organize these just before class into key themes for us discuss in the first half of each class, grounded in the perspectives you shared. I may call on you to elaborate on a point you made.

To demonstrate that you read, come prepared to each class with an informed opinion on the topic of the day. These should mirror the writing in opinion columns in a reputable newspaper, where an columnist might write quickly and about something that is of interest to readers, but does so with journalistic integrity, due diligence, and research. These are not "hot takes", written to get attention, but they are also not carefully researched long-form essays. They are quick, informed arguments intended to start debate, grounded in the ideas that you read about.

Your opinions should have the following qualities:

• They should be about ~300-400 words (something you could read aloud in 3-4 minutes).
• They should address the ideas in the two required readings and your selected reading/audio/material. For example, you might identify a particular concept that you found interesting, or design idea that you found problematic, or a thought that the readings made you think of.
• They should include a citation to the resource you selected to read or listen to.
• They should communicate an opinion about the idea you identified in the readings (you think an idea is good and want to explain why; you think an idea is wrong and want to critique it; you think a premise is false and want to attack it; the readings gave you an idea and you want to share it).

Here's an example. Imagine I just read the history chapter, As We May Think, and watched Doug Engelbart's historic "Mother of All Demos". I might submit something like this:

It's hard to imagine how the 1945's must have felt. The countless technological changes, the world wars, powerful white men controlling the present and imagining the future. So many were inspired by Bush's vision of machines that could store and retrieve anything. It unleashed decades of innovation that ended up digitizing the world. And yet so few participated in shaping and realizing that vision. If you were a white man at a U.S. or U.K. university, you might have been captivated by the possibilities of digital computers, like Doug Englebart was. But if you were anyone else, did you even know that this future was coming? What rooms was the public invited into, to shape that vision? What tables did the public sit at to imagine who this digital future might include? What justification did the Western white men who controlled this vision give for keeping this power to themselves? Or was their claim to that power not even a question?

It likely was not. I remember reading Charlton McIlwain's Black Software a few years ago, and being struck how the story of Black men in tech started in the 1970's, not the 1940's. It was one of inheriting Bush's vision, not as a possible future, but as a market opportunity for a future that had already come. One that was briefly and richly realized by Black men in the U.S. passionate about entrepreneurship and the internet, and then quickly squashed by racist university admissions policies that excluded them, I.B.M.'s racist promotion practices that kept on the ground floor, and venture capitalist's racist investment practices, that gave money to untested white graduates of Stanford instead of the battle-worn Black businessmen of the south. As creative as communities were on the margins throughout the 70's and 80's with interactive computing, computers, the internet, and everything that has come since have always been a project of white power, profit, and control. It's hard to imagine how that could change since we haven't learned any of what history has taught us about power. If anything, we are doubling down in a time of generative AI, controlled by a handful of companies, led by a handful of men, none of whom ask these questions, like their counterparts eighty years ago.

At the beginning of class, you'll post these in Discord #opinions, then you'll gather in small groups of 3 and briefly share the opinion you wrote. Afterwards, we'll gather as class and randomly select 7 of you each day who have not yet presented 3 times to share with the whole class, so everyone gets a chance to practice presenting to a group. In the last two weeks of class, instead of selecting randomly, we'll solicit volunteers, to ensure everyone gets three chances to present. The class will share their feedback and opinions about your opinions on Discord #opinions.

Note: you will submit this on Discord #opinions, not on Canvas. The official record for credit will the score and feedback we give you on Canvas when you present.

Grading

There are 18 sets of readings; you'll get 2 point for each reaction you post. These will be graded satisfactory/unsatisfactory. Satisfactory just means that you've shared a thought that's grounded in the reading's content and ideas. (We're going to do a reset on reading grades, and just count going forward).

Your opinion grade is based on your presentations, not on your writing, though we will use your post in Discord so we can refer to it when grading your presentation.

Presentations will be 21 of 100 points in the class, 7 points per presentation. Because we select randomly, you should do your best to be in class every day unless you are sick or in crisis, so you have enough opportunities to present. In the last two weeks, we'll solicit volunteers, to ensure everyone who's been unlucky has a chance to present. Once you've presented four times, we still expect you to read and write opinions, even though they won't contribute to your grade. They will still contribute to your learning, after all!

For a presentation to count for credit:

• The presentation must be about the ideas in the readings and the reading of your choosing (2 points)
• The opinion must be clearly articulated (3 points)
• The presentation should not include any obvious factual errors (2 points).

Each of the three criteria are satisfactory/unsatisfactory, and we'll use our discretion for partial credit.

While you listen to others present, write in Discord in #opinions about what you learned from them. Offer praise, share relevant reading. This is a chance to learn together from our collective viewpoints on these subjects.

If you have anxiety speaking to a group, or are sick, it is okay to record yourself presenting your opinion selected. Post this in #opinions and we will play that instead if you are called on.

Why are we only grading presentations, rather than everything you write? There are a few reasons for this:

• We want you to come to class :)
• Being able to communicate in both written and spoken form is crucial in professional practice.
• Assessing 800 opinions this quarter is a lot for our TA! This reduces that workload.

 

🤔 SWOT Analyses

You'll complete four three SWOT analyses about specific user interfaces. At a high level, a SWOT analysis is any report that analyzes the Strengths, Weaknesses, Opportunities, and Threats of something. In this class, your SWOT analyses will be about user interfaces in the world, and the user interface software and technologies that they use to function.

You'll do this in groups of 3 (with some groups of 2, since we aren't a multiple of 3). Your groups can be of your choosing, but must work with at least one new person each time.

There are three SWOT sprints:

• Interactive interfaces. These should be anything that takes user input and reacts immediately in response, such as any conventional website, app, or device.
• Programming interfaces. These are anything that meet the three properties of programming defined in the programming chapter: 1) loss of direct manipulation, 2) use of notation to describe future computer behavior, 3) use of abstraction
• Future I/O. These are any interfaces that use input other than mice, keyboards and/or output other than displays. 

Your SWOT analysis will proceed as follows:

1. Form your group (<10 min). We'll do this in SWOT studios in class.
2. Choose an interface and scope of functionality (< 1 hour). As a group, choose an interface to analyze and choose a scope of functionality that you want to focus on. It should be 1) something that everyone in the group wants to analyze, 2) it should be something you can actually use, so you can analyze its concrete behavior, 3) it should fit the broad theme for the SWOT sprint, and 4) it should be something that everyone is somewhat familiar with, but not expert on.
3. Explain functionality (<3 hours). As a group, research how the scope of functionality that you have chosen interface works from the system's perspective, focusing on user interface software and technologies employed in its core functionality, giving an overview of the key technologies, algorithms, and insights necessary for enabling the technology. Follow these guidelines:
   1. Write to your peers as the audience, helping them learn the key concepts of how the system works. Your goal is to deepen your peer's knowledge one "level" deeper — you don't have to become experts, or make your peers expertise, you just have to help them understand what the system is doing at a conceptual level.
   2. You may need to read research papers, consult technical documentation, or talk to experts (e.g., such as your instructors) to learn how it works. If you can't find documentation, rely on experts (e.g. your teachers!), and speculate if you must.
   3. Your goal is not to become an expert, but to at least be informed and knowledgeable at the conceptual level.
   4. The perspective you should write it from is the system's, not the user's. What input does it seek or receive, what does it do with it, how does it process it, how does it make decisions, what output does it produce? Provide the step by step process that it uses, and the decisions that it makes in this process, not just a list of technologies used.
   5. The level of detail is less than the source code for the system (which you don't have) and more than an interface walkthrough (which very little about what the system does internally).
4. Analyze assumptions (< 1 hour). Individually, analyze the assumptions the interface scope of functionality makes about the 1) user and 2) context of use, generating a list of at least 15 assumptions independently. Assumptions can span any aspect of the interface's assumed operating environment to the abilities, resources, and knowledge of users. However, the assumptions must be within the same scope as the explanation above. (e.g., if you explained how a recommendation feature worked, the assumptions should be about the recommendation feature).
5. Merge (< 1 hour). As a group, merge your list of assumptions, resolving any duplicates, and create an organized list of assumptions.
6. Write scenarios (< 1 hour). Individually, pick one assumption from the list that you did not generate and write a detailed scenario of exclusion. Your scenario should make it clear precisely how the scope of functionality interface's assumptions end up excluding someone from using the interface an your alternative design should articulate precisely how it doesn't. A satisfactory scenario should be as concrete as possible, describing hypothetical people and situations, not abstract generalities.
7. Redesign (<3 hours). Individually, conceive of an alternative design for the scope of functionality that does not make the assumption. This doesn't have to be a detailed design specification, just a design concept, at the same level of detail as your explanation. Explain what new assumptions your alternative design makes to avoid making the original assumption.

You'll submit a document that includes:

• Preamble
  • Include an image of the interface you chose.
  • A title, describing the interface you chose
  • Your names
  • Whether everyone in your group permits us to anonymize your report for use in a research study about the analysis of user interface assumptions and tradeoffs. (There is no incentive or penalty for opting in or out).
• Analysis
  • Explanation. Describe the specific interface you chose to analyze. As part of this description, describe the core strengths of the interface: what problem does it solve, and for whom? Then, provide an explanation of how the interface works, including any images or diagrams necessary to explain its function.
  • Assumptions. Your group's merged list of assumptions, annotated by who identified them.
  • Scenarios and Redesigns. An individually selected assumption and scenarios of exclusion describing its consequences. For each of your alternative designs, an argument for how the alternate design avoids the assumption and what new assumptions the new design makes.

Start from this SWOT template. It includes guidance about expected length, though you're welcome to deviate from its formatting and length guidance, change fonts and layout, etc. We recommend keeping the structure in the template, however, so we can find the content required.

In addition, to help everyone understand the range of technologies, assumptions, and scenarios that each team analyzed, on the due date, each team will present a very short 3-minute, 5-slide lightning talk. The slides should be:

• Slide 1: The interface you chose. Show an image and explain what it is, in case some aren't familiar with it. Include your names on this slide.
• Slide 2: The functionality you focused on. What aspect of the interface did you analyze?
• Slide 3: Briefly explain how the functionality works. This should be very short, but provide a high level explanation of the key things the system does to enable the functionality.
• Slide 4: Most interesting assumption. What one assumption did your team think were the most interesting assumptions?
• Slide 5: Describe one scenario and redesign. Ensure it's the assumptions in Slide 4 so you don't have to explain it detail the scenario and failure, then describe your redesign a new assumption it makes.

Do not create more than 5 slides; do not go over 3 minutes.

Keep details to a minimum; each slide should be 30 seconds. They don't have to be perfectly polished; we're just sharing informally and celebrating the milestone. Put your presentations in this shared slide deck, so that we don't have to switch devices. Format your slides however you like.

Grading

SWOT analyses will be team grades; that means you should all contribute, and also ensure that you give feedback on each other's individual work, so that the whole document is high quality. Everyone in the group will receive the same grade, but they are not structured as group assignments in Canvas, so everyone should submit individually, and individual that doesn't submit will receive a zero. (Consider this a small way of ensuring coordination and agreement between the group about when the document is ready).

Due dates are suggestions; there is no penalty for a late submission. The only exception is the only real due date: Friday, 5pm of the last week before finals week; anything submitted after that will get a zero, unless you arrange for an incomplete grade with me prior to that date and time. However, because we have many SWOT sprints, and they'll generally go fast, set up team communication and collaboration to be resilient to absence or illness, and don't slip (too much). Definitely do not procrastinate :)

We'll assess each of the four sections individually, along the following scale:

• Exemplary (10). The section not only met the requirements, but did so by excelling in some way (e.g., clarity, completeness, insight, creativity, rigor, or other ways). There is no procedure you can follow for doing exemplary work; I recommend picking some kind of exemplary as a group and strive for it. (But don't pick all of them!).
• Satisfactory (8). The section provided the required content.
• Unsatisfactory (6). The section was missing required content.
• Missing (0). The section was missing.

Your SWOT's score is the sum of your scores on the four sections. The TA can use their judgement to provide scores between the levels above.

If your team doesn't present, we'll give your team a 0 for the SWOT, so definitely present :). Not everyone has to speak.

We'll drop the lowest two of your SWOT scores to account for lateness, sickness, and other crises.