cs349.tex

\documentclass[]{article}
\usepackage{etex}
\usepackage[margin = 1.5in]{geometry}
\setlength{\parindent}{0in}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{amsthm}
\usepackage{listings}
\usepackage{color}
\usepackage{mathtools}
\usepackage{pgfplots}
\usepackage[lined]{algorithm2e}
\usepackage{qtree}
\usepackage{xytree}
\usepackage{float}
\usepackage{enumitem}
\usepackage[T1]{fontenc}
\usepackage{ae,aecompl}
\usepackage[pdftex,
  pdfauthor={Michael Noukhovitch},
  pdftitle={CS 349: User Interfaces},
  pdfsubject={Lecture notes from CS 349 at the University of Waterloo},
  pdfproducer={LaTeX},
  pdfcreator={pdflatex}]{hyperref}

\usepackage{cleveref}
\usepackage{enumitem}

\definecolor{dkgreen}{rgb}{0,0.6,0}
\definecolor{gray}{rgb}{0.5,0.5,0.5}
\definecolor{mauve}{rgb}{0.58,0,0.82}

\lstset{
  language=Java,
  aboveskip=3mm,
  belowskip=3mm,
  showstringspaces=false,
  columns=flexible,
  basicstyle={\small\ttfamily},
  numbers=none,
  numberstyle=\tiny\color{gray},
  keywordstyle=\color{blue},
  commentstyle=\color{dkgreen},
  stringstyle=\color{mauve},
  breaklines=true,
  breakatwhitespace=true,
  tabsize=4
}

\theoremstyle{definition}
\newtheorem*{defn}{Definition}
\newtheorem{ex}{Example}[section]
\newtheorem*{theorem}{Theorem}

\setlength{\marginparwidth}{1.5in}
\setlength{\algomargin}{0.75em}

\DeclarePairedDelimiter{\set}{\lbrace}{\rbrace}

\definecolor{darkish-blue}{RGB}{25,103,185}

\usepackage{hyperref}
\hypersetup{
    colorlinks,
    citecolor=darkish-blue,
    filecolor=darkish-blue,
    linkcolor=darkish-blue,
    urlcolor=darkish-blue
}
\newcommand{\lecture}[1]{\marginpar{{\footnotesize $\leftarrow$ \underline{#1}}}}

\makeatletter
\def\blfootnote{\gdef\@thefnmark{}\@footnotetext}
\makeatother

\begin{document}
	\let\ref\Cref

	\title{\bf{CS 349: User Interfaces}}
	\date{Winter 2015, University of Waterloo \\ \center Notes written from Michael Terry's lectures.}
	\author{Michael Noukhovitch}

	\maketitle
	\newpage
	\tableofcontents
	\newpage
	

	\section{Introduction}
		\subsection{Definitions}
			\textbf{Interface}: external presentation to user
			\begin{itemize}
				\item \textbf{controls}: manipulated to communicate intent
				\item \textbf{presentation}: what communicates response
			\end{itemize}
			\textbf{Interaction}: the actions a user must do to elicit corresponding response
			\begin{itemize}
				\item action and dialog
				\item unfolds over time
			\end{itemize}
	\section{Events}
		\subsection{Event Loop}
			\begin{lstlisting}
while(true) {
	if there is an event on queue:
		dequeue it 
		dispatch it
}
			\end{lstlisting}
		\subsection{Timer}
			Some events are triggered by a timer, if that event's execution time is longer than the timer interval 
			then by the end of the event execution, you should add another of your event to the queue!
		\subsection{Interactor Tree}			
			We need a way to send information about what object is clicked \\
			\textbf{interactor tree}: hierarchical tree-based organization of widgets
			\begin{itemize}
				\item each component's location is specified relative to parent
				\item we use \textbf{containers} whose sole purpose is to contain components
				\item events go \textbf{down} the tree to \textbf{capture} the target clicked
				\item event bubble \textbf{up} the tree to \textbf{handle} an event (e.g. EventListener)
			\end{itemize}
		\subsection{Event Propogation}
			when an event happens:
			\begin{enumerate}
				\item calculate the parent node path
				\item loop through it and execute capture phase handlers
				\item execute DOM level 1 phase handler
				\item execute bubble phase handlers 
				\item execute default browser behaviour
			\end{enumerate}
	\section{Model View Controller}
		\subsection{Idea}
			We decouple presentation from data using the \textbf{observer} design pattern. This separation allots benefits:
			\begin{itemize}
				\item \textbf{change the UI}: easy to change how we interact with data
				\item \textbf{multiple view}: have different views of same data
				\item \textbf{code reuse}: different logic for same view etc..
				\item \textbf{testing}: data separation allows better logic testing
			\end{itemize}
		\subsection{Description}
			\textbf{Model}: manages the data
			\begin{itemize}
				\item represent the data
				\item methods to manipulate data
				\item create and notify listeners
			\end{itemize}
			\textbf{View}: manages the presentation
			\begin{itemize}
				\item renders the data in a model
				\item references to the model
				\item is a listener to the model
			\end{itemize}
			\textbf{Controller}: manages user interaction
			\begin{itemize}
				\item between the model and view
				\item helps interpret input and model events
			\end{itemize}
	\section{Layout}
		\subsection{Layout Manager}
			\textbf{Layout Manager}: keeps the layout for components given their constraints and preferences
			\begin{itemize}
				\item uses composite and strategy design pattern
			\end{itemize}
			\subsubsection{Dynamic Layout}
				\textbf{Dynamic Layout}: maintain consistency with spatial layout
				\begin{itemize}
					\item reallocate space for widget
					\item adjust location and size
					\item change visibility, look, feel
				\end{itemize}			
			\subsubsection{Layout Strategies}
				\begin{itemize}
					\item \textbf{fixed layout}
					\item \textbf{intrinsic size}:	find each item's preferred size and the container will grow to perfectly contain each item
					\item \textbf{variable intrinsic size}:	layout determined in bottom-up and top-down phases
					\item \textbf{struts and spring}:	items can either be fixed (strut) or variable (spring)
				\end{itemize}
		\subsection{Responsive Design}
			\textbf{Responsive Design}: change layout to adapt to screen sizes of different devices
			\subsubsection{CSS}
				\textbf{CSS}:	specifying formatting
				\begin{itemize}
					\item consistency
					\item reduce size (cache CSS)
					\item code reuse
					\item separation of concerns
				\end{itemize}
				\textbf{CSS reset}:	normalize appearance across browsers
			\subsubsection{Cascade}
				Layout resolves CSS rules and renders following these rules:
				\begin{enumerate}
					\item find all declarations that match the element
					\item sort declarations by \lstinline|!important|
					\item sort by origin (author > web browser)
					\item sort by specificity of selector
					\item sort by order (later rule wins)
				\end{enumerate}
	\section{Visual Design}
		Impose as little thinking as possible on the user
		\subsection{Rules}
			\textbf{Simplicity}:
			\begin{itemize}
				\item facilitate recognition instead of recall
				\item use only the essentials
			\end{itemize}
			\textbf{Consistency}:
			\begin{itemize}
				\item exploit perceptual patterns
				\item avoid ambiguous presentation
				\item present information consistent with user goals
			\end{itemize}
			\textbf{Organization and Structure}:
			\begin{itemize}
				\item grouping
				\item hierarchy
				\item relationship
			\end{itemize}
		\subsection{Gestalt Principles}
			Theories of visual perception that describe how people organize groups
			\begin{itemize}
				\item \textbf{proximity}: elements associated with nearby elements
				\item \textbf{similarity}: visual similarity
				\item \textbf{common fate}: moving together 
				\item \textbf{continuity}: continuous forms are easy to percieve
				\item \textbf{closure}: see a complete figure even when info is missing
				\item \textbf{symmetry}
				\item \textbf{area}: visual field split into background and foreground
				\item \textbf{uniform connection}: connecting lines/regions 
				\item \textbf{alignment}
			\end{itemize}
	
	\section{Transformation}
		\subsection{Basics}
			\begin{description}[leftmargin=5em,style=nextline]		
				\item[translate] add scalar
					\begin{flalign*}
						\begin{bmatrix}
							1 & 0 & t_x \\
							0 & 1 & t_y \\
							0 & 0 & 1
						\end{bmatrix}
					\end{flalign*}
				\item[scale] multiply by scalar
					\begin{flalign*}
						\begin{bmatrix}
							s_x &0 & 0 \\
							0 & s_y & 0\\
							0 & 0 & 1
						\end{bmatrix}
					\end{flalign*}
				\item[rotate] $x' = x\cos \Theta - y\sin \Theta$ \\
				$y' = x\sin \Theta + y\cos \Theta$ 
					\begin{flalign*}
						\begin{bmatrix}
							\cos \Theta & -\sin \Theta & 0 \\
							\sin \Theta & \cos \Theta & 0\\
							0 & 0 & 1
						\end{bmatrix}
					\end{flalign*}
			\end{description}		

			\section{Widgets}
				\subsection{Definition}
					\begin{description}
						\item[Logical Input Device]: graphical component defined by its function/behaviour
						\item[Widget]: part of an interface that has its own behaviour
							\begin{itemize}
								\item the \textbf{model} manipulated by the widget
								\item the \textbf{events} generated by the widget
								\item the widget \textbf{properties} which change behaviour and appearance 
							\end{itemize}
					\end{description}
				\subsection{Types}
					\subsubsection{Simple Widgets}
						\begin{itemize}
							\item labels and images
							\item button
							\item boolean \textit{e.g. radio button}
							\item number \textit{e.g. slider} 	
							\item text field
						\end{itemize}
					\subsubsection{Container Widgets}
					\begin{itemize}
						\item pane
						\item tab
						\item menu
						\item list choice \textit{e.g. dropdown menu}
					\end{itemize}
					\subsubsection{Abstract Model Widgets}
						\dots
				\subsection{Widget Toolkit}
					\textbf{Widget Toolkit}: software that defines a set of (event-driven) GUI components via API 
					\begin{itemize}
						\item \textbf{complete}: GUI designers have all they need
						\item \textbf{consistent}: look, feel and usage paradigms are consistent
						\item \textbf{customizable}: devs can reasonably extend functionality
					\end{itemize}
					There are two common implementations of widgets:
					\begin{itemize}
						\item \textbf{Heavyweight widgets}: OS provides widgets and hierarchical windowing system \textit{e.g. X, HTML}
						\item \textbf{Lightweight widgets}: OS provides top-level window, use toolkit for drawing and events \textit{e.g. Java Swing}
					\end{itemize}
			\section{Responsiveness}
				\textbf{Responsiveness}: the fulfillment of a user's real-time needs
				\subsection{Human Deadline}
					Make your program seem faster by using tricks to respond to a user's actions:
					\begin{itemize}
						\item busy indicator
						\item progress indicator
						\item rendering important information first
						\item fake heavyweight computations \textit{e.g. scrolling}
						\item work ahead during periods of low load
					\end{itemize}
				\subsection{AJAX}
					Classic web architechture relied on	'thin client, fat architechture', side step it using JS:
					\begin{itemize}
						\item AJAX issues call to web server (API)
						\item server handles request and returns data feed 
						\item client updates UI with feed using JS
					\end{itemize}
					Advantages:
					\begin{itemize}
						\item minimize bandwidth
						\item increase speed
						\item avoid HTML headers 
					\end{itemize}
					\begin{ex}
						AJAX backend using Bottle (Python)
						\begin{lstlisting}[language=Python]
from bottle import route, run, template, request

@route('/ajax', method='POST')
def ajax():
	# Retrieve the JSON
	json_data = request.json

	# upper-case and return the text
	upper = json_data['text'].upper()

	# Bottle will automatically send back
	# Python dictionaries as JSON objects
	return {'reply': upper}
						\end{lstlisting}
					\end{ex}
			\section{Design Process}
				We need to have descriptions of UI to clarify intent and \textbf{define interaction}. 
				\subsection{Formal Language}
				The design process can be strongly described with formal languages such as \textbf{Finite State Machines} allowing us to label states and transitions. But this rigid formality has troubles describing the rich informal world of the user:
				\begin{itemize}
					\item complexity of interfaces is too great
					\item can't clearly represent some ideas \textit{e.g. timed events}
					\item transition time (to create/update model) is not negligable
				\end{itemize}
				\subsection{User Centered Design}
					Design (and test) with real people in mind, using semi-formal languages
					\begin{itemize}
						\item understand user needs
						\item design UI first (then architecture)
						\item iterate
						\item use it yourself
						\item observe others using it
					\end{itemize}
					This can be put into a design process:
					\subsubsection{Understand the User}
						\begin{itemize}
							\item observe existing solutions
							\item list scenarios
							\item list functions required
							\item prioritize (freq and commonality)
						\end{itemize}
					\subsubsection{Design the UI}
						\begin{itemize}
							\item identify and design components
							\item design component distributions
								\begin{itemize}
									\item storyboards
									\item interaction sequeunces: macro structure
									\item interface schematics: micro structure
								\end{itemize}
							\item test the design with users
								\begin{itemize}
									\item prototyping (high vs low fi, paper, Wizard of Oz)
									\item user/usability studies
								\end{itemize}
							\item iterate again!
							\item document the design
								\begin{itemize}
									\item visual vocabulary
								\end{itemize}
						\end{itemize}
					\subsubsection{Refine the Design}
						\begin{itemize}
							\item refine requirements
							\item add new scenarios
							\item walk through new scenarios
							\item adjust UI design
						\end{itemize}

	\section{Experimentation}
	\subsection{Definitions}
	\begin{description}
		\item[Hypothesis]: specific, falsifiable idea of how and which variables influence outcome
		\item[Independent Variables]: variables manipulated by experimenter
		\item[Dependent Variables]: variables that are measured
		\item[Null Hypothesis]: there exists no relationship between independent and dependent variables
		\item[Control Condition]: no experiment performed
		\item[Experimental Condition]: experimental variable is manipulated
	\end{description}

	\subsection{Experimental Process}
	\begin{enumerate}
		\item formulate hypothesis
		\item identify independent/dependent variables
		\item design experiment
		\item check for:
			\begin{description}
				\item[validity]: are we measuring what we say we are
				\item[reliability]: do we get same results reliably
				\item[confounds]: are there influential variables we don't control for
				\item[subject pool]: do the subjects represent intended users
			\end{description}
		\item select representative subjects
		\item randomly assign to conditions
		\item analyze results
	\end{enumerate}

	\subsection{Study Designs}
	\textbf{Between subjects}: each subject experiences one condition
	\begin{itemize}
		\item[+] no learning effects
		\item[-] need more people 
		\item[-] problems with variation in subjects
	\end{itemize}
	\textbf{Within subjects}: each subject experiences every condition
	\begin{itemize}
		\item[+] order of conditions can counterbalance learning
		\item[+] need fewer subjects
		\item[-] learning effects can persist
	\end{itemize}
		


	\subsection{Experimentation Ethics}
	\textbf{Deception}: manipulating the truth by hiding or showing false information
	\begin{enumerate}
		\item \textbf{System Image Deceptions}: deceiving what the system is doing/can do \\ (\textit{e.g.} fluid progress bars)
		\item \textbf{Behaviour Deceptions}: taking advantage of physical/sensory limits \\ (\textit{e.g.} ``smooth'' transition)
		\item \textbf{Mental Mode Deceptions}: manipulating user's mental mode \\ (\textit{e.g.} fake static noise in Skype)
	\end{enumerate}

	\textbf{Benevolent Deception}: deception that can help the user:
	\begin{itemize}
		\item close gap between expectation and reality (\textit{e.g} 15 minutes remaining)
		\item balance needs of individual vs group (\textit{e.g.} noise in search results)
		\item protect user from themselves (\textit{e.g} ask whether user meant to delete something)
		\item satisfy design goals (\textit{e.g} placebo buttons)
	\end{itemize}

	\textbf{Malovolent Deception}: deceptions that benefit owner at user's expense
	\begin{itemize}
		\item using confusing language (\textit{e.g.} using double negatives)
		\item hiding certain functionality (\textit{e.g.} hide unsubscribe button)
		\item exploiting user mistakes (\textit{e.g.} ads with arrow button)
	\end{itemize}
	\section{History}
	\subsection{Batch Interface}
	\begin{itemize}
		\item punch cards prepared a priori
		\item response time of hours and days $\Rightarrow$ no real interaction
		\item only highly trained users
	\end{itemize}
	\subsection{Conversational Interface}
	\begin{itemize}
		\item commands typed through keyboard
		\item wait for response (user cannot make changes during execution)
		\item heavily scripted interaction
		\item trained users
	\end{itemize}
	\subsection{Graphical Interface}
	\begin{itemize}
		\item input through keyboard, pointing device
		\item high resolution, refresh, graphics display
		\item user in control
		\item recognition memory over recall
		\item skeumorphism metaphors
	\end{itemize}
	Notable moments:
	\begin{itemize}
		\item \textit{As We May Think}, Vannevar Bush
		\item Light Pen, Ivan Sutherland
		\item NLS Demo, Douglas Englebart
		\item Dynabook and Xerox Star, Alan Kay
	\end{itemize}

	\section{Input}
	\subsection{Classification}
	Sensing Method:
	\begin{itemize}
		\item mechanical (\textit{e.g.} switch)
		\item motion (\textit{e.g.} gyroscope)
		\item contact (\textit{e.g.} capacitive touch)
		\item signal processing (\textit{e.g.} computer vision)
	\end{itemize}
	Continuous v. Discrete \\
	Degrees of freedom

	\subsection{Text Input}
	\subsubsection{QWERTY vs Dvorak}
	\textbf{Qwerty}
	\begin{itemize}
		\item designed to reduce typewriter jams and speed up typists
		\item not perfectly centered on home row
	\end{itemize}
	\textbf{Dvorak}
	\begin{itemize}
		\item letters typed with alternating hands, 70\% on home row
		\item least common letters on bottom row
		\item right hand should do most of the typing
		\item \textbf{not faster} than QWERTY, no measurable difference
	\end{itemize}
	\subsubsection{Keyboard Design}
	\textbf{Mechanical Keyboards}
	\begin{itemize}
		\item fastest and most comfortable
		\item downsizing can pose difficult
		\item 80+ WPM
	\end{itemize}
	\textbf{Soft/Virtual Keyboards}
	\begin{itemize}
		\item ergonomic problems
		\item good when text input is limited
		\item 45 WPM
	\end{itemize}
	\textbf{Thumb/One-handed Keyboards}
	\begin{itemize}
		\item interesting but not mainstream
		\item ``chording keyboards'' are a thing
		\item 60 WPM
	\end{itemize}
	\textbf{Text Recognition and Gestures}
	\begin{itemize}
		\item Graffiti: map single strokes to enter letter (9 WPM)
		\item Natural handwriting recogntion (33 WPM)
	\end{itemize}
	\textbf{Predictive Text}
	\begin{itemize}
		\item using characteristics of language to speed up typing
		\item T9: was the shit back in middle school\
		\item 45 WPM for experts
	\end{itemize}
	\textbf{Gestural Text Input}
	\begin{itemize}
		\item ``Swiping'' across a keyboard to form words
		\item 30 WPM
	\end{itemize}

	\subsection{Position Input}
	\begin{itemize}
		\item force vs displacement: joystick vs mouse
		\item position vs rate control
		\item absolute vs relative position: touchscreen vs mouse
		\item direct vs indirect contact: touchscreen vs mouse
			\begin{itemize}
				\item Control-Display Gain: $\frac{V_{pointer}}{V_{device}}$
			\end{itemize}
		\item dimensions sensed: dial vs mouse vs wiimote
	\end{itemize}

	\subsection{Gestural Input}
	Gestures map movements to commands \textit{e.g.} Myo gestures

	\section{Input Performance}
	We want to measure which user interfaces are better using good metrics
	\subsection{Keystroke Level Model}
	Describe a task combining the length of time it takes for operators:
	\begin{itemize}
		\item keystroke: 0.08 - 1.2s
		\item pointing: 1.1s
		\item button press on mouse: 0.1s
		\item move hand mouse to/from keyboard: 0.4s
		\item mental preparation: 1.2s
	\end{itemize}

	Pros:
	\begin{itemize}
		\item easy to model	
		\item can be done from just ideas and mockups
	\end{itemize}
	Cons:
	\begin{itemize}
		\item time estimates are inaccurate
		\item doesn't model learning, expertise
		\item doesn't model pointing well
	\end{itemize}
	
	\subsection{Fitt's Law}
	A predictive model for pointing time based on device, distance, target size
	\begin{equation*}
		MT = a + b \log_2 (\frac{D}{W} + 1)
	\end{equation*}
	\begin{itemize}
		\item[MT] movement time
		\item[D] distance from starting to middle of target
		\item[W] constraining size of target, usually min(width, weight)
		\item[a,b] characteristics of the pointing device
		\item[IP] index of performace: 1/b
		\item[ID] index of difficulty: $\log_2 (\frac{D}{W} + 1)$
	\end{itemize}
	making a cursor move slower over an object enlarges in in \textbf{motor space}, even
	though it looks the same size in screen space

	\subsection{Steering Law}
	An adaptation of Fitt's Law for steering between two goals:
	\begin{equation*}
		ID = \log_2 (\frac{A}{W} + 1)
	\end{equation*}
	\begin{itemize}
		\item[A] distance between goals
		\item[W] width of goals
	\end{itemize}
	expanding this to make a tunnel:
	\begin{equation*}
		ID = b \frac{A}{W}	
	\end{equation*}

	\section{Visual Perception}
	\subsection{Temporal Resolution}
	People can only detect flickers up to 45 Hz after which it changes to continuous light. 
	In the same way, pictures at 24 FPS become a movie

	\subsection{Spatial Resolution}
	High resolution only applies to 1\% of photoreceptors in the eye.
	The distance from the screen necessary to distinguish a pixel $d$, can be stated as :
	\begin{equation*}
		d = \frac{\text{size of a pixel}}{\tan (1/30)}
	\end{equation*}
	So if you are a distance of .4 - .7m away from the screen, pixels need to be 0.23 - 0.41cm apart to be distinguishable

	\subsection{Color Perception}
	\textbf{Color Models}: bases of colors used for displays
	\begin{itemize}
		\item RGB: used on displays
		\item HSB: hue, saturation, brightness
		\item YUV: optimized for human perception
		\item CMY(K): used in printing (subtracive)
	\end{itemize}

	\textbf{Display Monitors}
	\begin{itemize}
		\item each pixel is composed of 3 sub-pixels: red, green, blue
		\item vary intensity of each subpixel and use visual acuity restrictions to make a single color
	\end{itemize}

	\subsection{Peripheral Vision}
	Low resolution vision in our periphery that helps
	\begin{itemize}
		\item guide focus
		\item detect motion
		\item see better in the dark
	\end{itemize}
	We can use this knowledge to directs user's attention, \textit{e.g.}
	\begin{itemize}
		\item ``wiggle'' window
		\item reserve red for errors
	\end{itemize}

	\section{Typography}
	Make reading as fast and clear as possible

	\subsection{Defintions}
	\subsubsection{General}
	\begin{description}
		\item[Typeface]: set of letters and numbers that make up a type design
		\item[Font]: one width, weight, and style of typeface
		\item[Glyph]: lowest divisible unit of type (a letter)
		\item[Point]: 0.351mm
		\item[Pixel]: size of one ``dot'' a screen
	\end{description}

	\subsubsection{Printing Terminology}
	\begin{description}
		\item[Baseline]: line on which most letters rest
		\item[Point size]: total height of a typeface block
		\item[Leading]: spacing between lines of text
		\item[Line spacing]: leading + point size
		\item[Ligature]: pair of letters replaced by a single printed unit (\textit{e.g.} fi)
	\end{description}

	\subsubsection{Font Terminology}
	\begin{description}
		\item[x-height]: height of x
		\item[em-space]: width of m
		\item[Drop cap]: capital letter at start the descends multiple lines (like in manuscripts)
		\item[Serif]: decorative stroke at end of main letter stroke
	\end{description}

	\subsection{Computer Typography}
	\textbf{Bitmap font}: handcrafted font for bitmap display
	\begin{itemize}
		\item can't be properly scaled
		\item limited resolution
	\end{itemize}

	\textbf{Outline font}: vector outline of font, converted to bitmap prior to display
	\begin{itemize}
		\item compact storage
		\item bitmap representation can be inaccurate on small display
	\end{itemize}

	\subsection{Design Rules}
	Consider different distances:
	\begin{itemize}
		\item far away
			\begin{itemize}
				\item should look like a uniform display
				\item headings should stand out
				\item whitespace should guide
			\end{itemize}
		\item nearby
			\begin{itemize}
				\item distinct lines of text should be visible
				\item short lines of text
			\end{itemize}
		\item reading distance
			\begin{itemize}
				\item words should be chunked
				\item similar fonts, distinct fonts for different meanings
			\end{itemize}
	\end{itemize}

	\section{Accessibility}

	\subsection{Temporary Disability}
	We all have ``temporary disbailities'': distraction, injury, other focus. Just walking
	severely inhibits our ability to read, understand, and think about cognitive tasks.

	\subsection{Inclusive Design}
	\begin{enumerate}
		\item Increases your audience:
			\begin{itemize}
				\item 10 - 20\% of population has a disability
			\end{itemize}
		\item Usually benefits everyone:
			\begin{itemize}
				\item curb-cuts: made for wheelchairs to roll from curb to street but used by cyclists, strollers
				\item cassette tapes: alternative for reel-to-reel tape so blind people could use it better
				\item closed captioning: useful for data mining videos and can help learn foreign languages
			\end{itemize}
		\item Required by law and is a basic precept for the internet:
			\begin{itemize}
				\item use alt-text
				\item use device-independent js events (\verb onSelect )
			\end{itemize}
	\end{enumerate}

	\section{Touch Interfaces}
	\subsection{Display}
	\begin{itemize}
		\item Resistive: two transparent layers that complete a circuit when pressed
		\item Capacitive: measures change in capacitance to find location of touch
			\begin{itemize}
				\item single-touch: capacitors at four corners
				\item multi-touch: grid of capacitors with a layer of driving lines to carry current, and sensing lines to detect it
			\end{itemize}
		\item Inductive: use a magnetized stylus to induce EM field in back of display
		\item Optical: use motion-tracking cameras
	\end{itemize}

	\subsection{Input Challenges}
	\begin{enumerate}
		\item fat finger problem: finger occludes the object, can make object bigger or account for finger occlusion with touch offset
		\item ambiguous feedback: touch interfaces can miss haptic feedback and confuse user if action unsuccessful
		\item no hover state: no way to preview your actions before you do them
		\item multi-touch capture: mutliple fingers can lead to ambiguous input
	\end{enumerate}

	\subsection{Interaction}
	Since we have a touch screen, our interface is of \textbf{direct manipulation}:
	\begin{itemize}
		\item dragging a document to the trash
		\item dialing a phone number on virtual keys
	\end{itemize}
	\subsubsection{Principles}
	\begin{itemize}
		\item visible and continuous representation of objects and actions
		\item all actions are valid, reversable, obvious
		\item interaction with object as opposed to interface
	\end{itemize}
	\subsubsection{Challenges}
	\begin{itemize}
		\item potentially not accessible
		\item analogies may not be clear
	\end{itemize}

	\subsection{Design}
	Help users:
	\begin{itemize}
		\item enter information quickly
		\item know what action to take
		\item utilize real estate and avoid clutter 
	\end{itemize}

	\subsection{Implementation}
	Touch Event API:
	\begin{itemize}
		\item touchstart
		\item touchmove
		\item touchend
	\end{itemize}


	\section{Touchless Interfaces}
	\subsection{Introduction}
	Intefaces either through voice, air gestures, \dots are extremely useful but suffer
	from errors due to being one-state input devices. The key idea is that the system should
	fail gracefully.

	\subsection{In-Air Gestures}
	\textbf{Live Mic Problem}: because touchless intefaces can be ``always on'', we need to find a way to distinguish commands from unintentional gestures (\textit{e.g.} scratching your head). 
	\begin{itemize}
		\item reserved actions: making a particular set of actions always used for navigation or commands
		\item reserving a clutch: making a rare action be the indicator to start/stop a command
		\item multi-modal input: use a different mode (\textit{e.g.} hardware button) to control universal params
	\end{itemize}

	\subsection{Speech Interfaces}
	Voice recognition challenges:
	\begin{itemize}
		\item \textbf{Rejection error}: system has no hypothesis about what user has said
		\item \textbf{Substitution error}: system mistakes utterance
		\item \textbf{Insertion error}: recognize noise as legal utterance
	\end{itemize}
	Although voice recognition seems like a good metric, user satisfaction is better measured with:
	\begin{itemize}
		\item discourse segment pop: completing a sub-dialog and revealing context
		\item human conversability: understanding casual speech
		\item dialog boxes: asking for confirmation at right time
	\end{itemize}

	
	\section{Information Visualization}
	
	\subsection{Why}
	Good data visualization allows people to make better decisions and be more informed.

	\subsection{What}
	\textbf{Visual encoding} is the process of encoding the data into a visual format, consists of:
	\begin{itemize}
		\item graphical elements called \textbf{marks}
		\item \textbf{visual channels} which control the appearance of marks
	\end{itemize}

	\subsubsection{Channel Types}
	\textbf{Magnitude channels}: for organizing ordered attributes
	\begin{itemize}
		\item position on a scale
		\item area/volume
		\item color saturation
	\end{itemize}
	\textbf{Identity channels}: for organizing categorical attributes
	\begin{itemize}
		\item spatial region
		\item color hue
		\item shape
	\end{itemize}

	\subsubsection{Channel Effectiveness}
	We can measure how effective a channel is with:
	\begin{itemize}
		\item accuracy
		\item discriminability
		\item separability
		\item popout
	\end{itemize}
	\subsection{How}
	Use software structure diagrams to describe the models
	\begin{itemize}
		\item \textbf{Reference Model Pattern}: and separate them from the views to enable multiple views of a visualization
		\item \textbf{Data Column Pattern}: organiza data into columns to provide flexible representations and schemes
		\item \textbf{Operator}: decompose visual data processing into composable operators
		\item \textbf{Renderer}: separate visual components from their rendering methods for dynamic rendering
		\item \textbf{Production Rule}: use if-then-else to dynamically determine visual properties
	\end{itemize}


\end{document}