Part 3 Models and theories
 12 psychology
13 social
14 collaboration
15 task analysis
16 dialog
17 math notations for modelling
(18 extends 17)

Chapter 12 cognitive models
	Hierarchical
		Task and goal structure
	Linguistic
		Grammar
	Physical/device models
		Physical devices
		Human motor skills
	Cognitive architectures
		Underlying thought processes
	
12.1 every model covers some aspect of interface design
	Level differs
	Perspective
	Competence of user
	Performance of users

	Formulation or execution of a plan
		User and language
		Input language of interface
	Some assumptions discussed starting in chapter 1
		Long term memory vs short term memory (~7 items)
		Recognition vs recall
		Computational analogies often used in cognitive models
			Rule based systems
			Search  for solution
			Heuristics
			Connectionism (models of neurons)
		PROBLEM: try to avoid a mechanistic view of user

12.2 goal and task hierarchies
	Models assume users set goals; 
		Divide and conquer
		Stop at high level (don’t subdivide until you are studying hand gestures)
		Be aware of abstraction level(granularity)
	Most abstract: unit task
		Represent how users choose
		Users not perfect; prediction of error behavior poor
	GOMS goals operators methods selection
		Goals of user (memory point)
		Operators (basic actionS)
		Methods (how you do an operator)
		Selection (choose method)
good for predicting routine tasks
accuracy in some circumstances about 90%
does not work well to compare across tasks
	(training to production; transfer to new domain)
By adding PERT (prerequisites; critical path) valuable to evaluate system

Cognitive complexity theory CCT
	Model user with production rules
	State transition grammar (chapter 16)
	Example: what happens when you see you missed typing a space 
	(GOAL perform unit task)
	Problem broken down into series of steps
		Expert: proceduralized: so well practiced, you don’t think about steps
		Novices: often check and recheck rules; may not understand rules
		GOMS and CCT aimed at low level, proceduralized goals
		Complexity of system relates to number of rules
		Size of description can be enormous
		Notations vary (none ideal)
		Goal hierarchies can be post hoc; defined by interface
	Example:
		ATMs used to give money and THEN return cards
		(People grabbed the money and forgot their card)
		Solution: return the card and THEN give them the money
		Cash registers at grocery stores: used to hold credit card until done
		People forgot their credit cards: 
			It reads the card, and gives it back even before the total sale
			(Do not remove card)* remove card DING

12.3 linguistic models
	https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form

 https://www.cs.unb.ca/~wdu/cs4613/a2ans.htm

https://video.search.yahoo.com/search/video?fr=mcafee&ei=UTF-8&p=BNF+grammar&type=C211US105D20160820#id=2&vid=6c5b116f802b161cf8f0101c505904bb&action=click

	compiler design:
		lexical analysis is first
			(find what is there; detail syntax)
		BNF is not enough for SEMANTIC ANALYSIS
			But given the set of rules (CFG) you can figure out how 
			A program can be derived from the rules
		Code generation:
			As the rules are processed, you have what you need to generate code