managing design processes shneiderman and plaisant chapter 3
TRANSCRIPT
Managing Design Processes
Shneiderman and Plaisant
Chapter 3
Overview
• Organizational design to support usability– Shneiderman - both “design” and the organizational context in which it occurs
• Carroll and Rosson’s characterization of design– “radically transformational”
• Iterative design and its relation to software engineering– Spiral model
• Shneiderman’s “four pillars of design”– User interface requirements– Guidelines documents and processes– User interface software tools– Expert reviews and usability
• Development methodologies– IBM: Ease of Use, Lucid
Introduction
• Recall that early on programmers designed for programmers– That was fine then, has its place now
• However, usability engineering has become the norm– E.g., low fidelity prototypes, revisions based on feedback from users,
incremental refinement, testing, observation, etc.– Usability engineering as a part of design process
• Interspersed with implementation
• User Experience Professionals Association– Formerly, Usability Professionals Association– http://uxpamagazine.org/
User Experience Professionals Association
• http://uxpamagazine.org/
Organizational Design to Support Usability, 1
• Human factors laboratories • Organizationally, usability engineering included here
– Business case has been often made:• Software projects do fail• E.g., correction of 20 easiest to correct faults increase success rates from 19% to as
much as 80%– Projects have “user interface architect” and “usability engineer”
• “Usability group in a human factors laboratory”
Organizational Design to Support Usability, 1
• Human factors laboratories • Organizationally, usability engineering included here
– Business case has been often made:• Software projects do fail• E.g., correction of 20 easiest to correct faults increase success rates from 19% to as
much as 80%
– Projects have “user interface architect” and “usability engineer”• “Usability group in a human factors laboratory”
• Big idea about why hard to design good user interfaces:– Part of the challenge of interface design, implementation, testing, etc., is that it is
embedded in a design process of the (application) software itself, as well as entailing its own design process
• And for that matter, in all cases design is complex– Design is inherently creative and unpredictable.
• “Interactive system designers must blend knowledge of technical feasibility with a mystical esthetic sense of what attracts users”, Shneiderman
– As does all design
Organizational Design to Support Usability, 1
• Big idea about why hard to design good user interfaces:
– Part of the challenge of interface design, implementation, testing, etc., is that it is embedded in a design process of the (application) software itself, as well as entailing its own design process
– Leads to “iterative”, or “user-centered” design – much more later
Design
Evaluate Implement
Organizational Design to Support Usability, 1
• Human factors laboratories • Organizationally, usability engineering included here
– Business case has been often made:• Software projects do fail• E.g., correction of 20 easiest to correct faults increase success rates from 19% to as
much as 80%
– Projects have “user interface architect” and “usability engineer”• “Usability group in a human factors laboratory”
• Big idea about why hard to design good user interfaces:– Part of the challenge of interface design, implementation, testing, etc., is that it is
embedded in a design process of the (application) software itself, as well as entailing its own design process
• And for that matter, in all cases design is complex– Design is inherently creative and unpredictable.
• “Interactive system designers must blend knowledge of technical feasibility with a mystical esthetic sense of what attracts users”, Shneiderman
– As does all design
Organizational Design to Support Usability, 2
• Wide variety of design situations precludes comprehensive design strategy– Depends on time, budget, organization, personnell, …
– Will see different variations, e.g., IBM’s: Ease of Use works for that (large) organization
• Shneiderman says “each of project should have its own user interface architect”– That would be nice … and why not a usability engineer or two …
• All should understand a bit about design– Carroll and Rosson’s account well known in user interface community
– Another take on why design is “iterative” (in an extreme sense)
Carroll and Rosson’s Characterization of Design
• What is design? – a thoughtful, realistic, well-know characterization
Carroll and Rosson’s Characterization of Design
• What is design? – a thoughtful, realistic, well-know characterization
• Design is a process, not a state– This precludes a static characterization
• The design process is nonhierarchical– Neither strictly top down or bottom up– Simple understanding of design as “top down” is in part pedagogic and with experience is
abandoned
• The design process is radically transformational– Partial and interim solutions may play no role in final design– You throw designs away
• Design intrinsically involves (even) the discovery of new goals– I.e., reconceptualizing the problem, and its goals– Hence, can’t be top down
• Nonetheless, as in any creative domain, there can be discipline, refined techniques, right and wrong methods, and measures of success
Overall, We’ll look at:
• Iterative design– Current “best practice”– Specialization of Boehm’s spiral model
• Task analysis– How the ui (and software) design
process starts– Process of discovering characteristics
of users and what problems they need to solve
• More about evaluation next week
• First, “conventional” software engineering models …
Design
Evaluate Implement
Software Lifecycle Models
• Will relate design to software engineering ideas
• Show how activities are related to each other
• Lifecycle models are:— Management tools
— Simplified versions of reality
• Many lifecycle models exist, for example:— From software engineering:
—Waterfall, spiral, JAD/RAD, Microsoft
— From HCI:
—Star, usability engineering
Software Engineering: ‘Waterfall’ Lifecycle
Requirements analysis
Design
Code
Test
Maintenance
Quick look:
RAD workshops
Project set-up
Iterative design and build
Engineer and test final prototype
Implementationreview
Software Engineering: Lifecycle, RAD (Rapid Applications Development)
Traditional SE: Waterfall Model
• One of earliest design processes
– Does enforce “think first, code second”
• “Validation” at each stage
– E.g., design against requirement
• Milestones with products at each stage
– Which is good
Feedback in the Waterfall Model
• Validation alone not always sufficient
– Sometimes problems missed until next stage
– Hence, feedback between stages
• Problem when mistake in early stage
– E.g., missing requirement discovered in acceptance stage
– Rework of intervening stages needed
Waterfall not at all Good for UI Design!
• UI design hard / “risky”– May well get it wrong
• Just a fact
• Users are not involved in validation until acceptance testing!
– So don’t find out until end!– Only other place users involved is
requirements
• UI flaws often cause changes in requirements and design
– Have to recode written and tested code
– And this seems natural, given what we have seen about design in general and ui design in particular”
Iterative Design
• Iterative design offers a way to manage risk inherent in user interface design
– Because it is, well, design– But, there needs to be some sort of
system to test – hence, build
• Software design is refined by iterations of cycle
• But, isn’t this just like waterfall, where went from design to acceptance then back?
– We’ll see it’s not
Design
Evaluate Implement
BTW, Iterative Design - Wrong Way
• Every iteration corresponds to a release!
• Complaints are the evaluation that feeds back into next version’s design
• Using paying customers to evaluate usability not good
– They won’t like it– They won’t buy version 2
Design
Evaluate Implement
Spiral Model, 1
• Repeated cycles of: – Design – Implement– Evaluate– (size circle reflects
effort/cost)
• Design cost decreases with iterations, build cost increases (in radial dimension)
– As approach release
• Cost contained by early build iterations as cheap as possible
Spiral Model, 2
• Early iterations use cheap prototypes
• Parallel design is feasible:
– Build & test multiple prototypes to explore design alternatives
• Later iterations use richer implementations, after UI risk mitigated
• More iterations generally means better UI
Often called “User-Centered Design”(Term is worth a separate slide!)
• User-centered
• As noted,– Iterative design– Early focus on users and tasks– User analysis:
• who the users are– Task analysis:
• what they need to do– Involving users as evaluators,
consultants, and sometimes designers
• Constant evaluation– Users are involved in every
iteration– Every prototype is evaluated
somehow
User Centered DesignExample
1. Task analysis – Collecting requirements
2. Design sketches– E.g., paper sketches of UI design
3. Paper prototype– Interactive prototype made of paper
and other cheap physical materials
4. User testing
5. Computer prototype– plan to throw away
6. Heuristic evaluation– Usability experts
7. Implementation
8. User testing – Any final refinement
Design
Evaluate Implement
User & Task Analysis – Again …
User & Task Analysis – Again …
• First step of user-centered design
• User analysis: – Who is the user?
• Task analysis: – What does the user need to do?
User Analysis: Know Thy User(s)
• For beginning designer, helps remind that users not like us
• Identify characteristics of target user population – cf., universal usability– Age, gender, ethnicity– Education– Physical abilities– General computer experience– Skills (typing? reading?)– Domain experience– Application experience– Work environment and other social context– Relationships and communication patterns
• As noted, most applications have several kinds of users
User Analysis
• Techniques– Questionnaires– Interviews– Observation
• Obstacles– Developers and users may be systematically isolated from each other
• Tech support shields developers from users• Marketing shields users from developers
– Some users are expensive to talk to– Doctors, executives, …
Task Analysis
• Identify individual tasks program might solve
• Each task is a goal (what, not how)
• Often helps to start with overall goal of system and then decompose it hierarchically into tasks
– E.g., Overall goal: shoppers pay for their own groceries– Tasks:
• Enter groceries into register• Bag groceries• Pay
Essential Parts of Task Analysis
• What needs to be done?– Goal, .e.g., send an email message
• What must be done first to make it possible?– Preconditions
• Tasks on which this task depends• Information that must be known to the user
• What steps are involved in doing the task?– Subtasks– Subtasks may be decomposed
Other Elements of a Task
• Where is the task performed? – consider automated checkout– Front of supermarket, standing up
• How often is the task performed?– At most a few times a week
• What are its time or resource constraints?– A minute or two
• How is the task learned?– By trying it, watching others, shown how by store personnel
• What can go wrong? (Exceptions, errors, emergencies)– Barcode is missing or smudged– Shopper wants to buy alcohol or cigarettes
• Who else is involved in the task?
Task Analysis
• How to do a task analysis– Interviews with users– Direct observation of users performing tasks
• Pitfalls of task analysis– Duplicating a bad existing procedure in software
• E.g., sequential search– Failing to capture good aspects of existing procedure
• E.g., notes on paper forms
User and Task Analyses Techniques
• Questions to ask– Why do you do this? (goal)– How do you do it? (subtasks)
• Look for weaknesses in current situation– Goal failures, wasted time, user irritation
• Contextual inquiry
• Participatory design
Contextual Inquiry, Participatory Design
• Observe users doing real work in the real work environment– Combines interview and observation
• Be concrete
• Establish a master-apprentice relationship– User shows how and talks about it– Interviewer watches and asks questions
• Challenge assumptions and probe surprises
• Participatory Design– Include representative users directly in design team
So, What is Interaction Design?(Preece - supplementary)
So, What is Interaction Design?(Preece - supplementary)
• Recall, Preece et al. are concerned with more general interaction design (includes door knobs)
• Have looked at Shneiderman’s (and a couple of others’) take on interface design
• Will look at what Preece et al. say, quickly – the essential ideas are the same
• Terminology differs somewhat, and the applications are more general
So, What is Interaction Design?(Preece - supplementary)
• Quick overview … Preece’s take … the basic ideas…rather more general than Shneiderman’s two methodologies … “a rose by any color …”
• What? – Four basic activities– Three key characteristics
• Some practical issues– Who are the users?– What are ‘needs’?– Where do alternatives come from?– How do you choose among alternatives?
• Will see:– Lifecycle models from software engineering– Lifecycle models from HCI
• It is a process:– a goal-directed problem solving activity informed by intended use, target domain, materials, cost, and
feasibility– a creative activity– a decision-making activity to balance trade-offs
• It is a representation:– a plan for development– a set of alternatives and successive elaborations
What is interaction design?(supplementary)
• Four basic activities in Interaction Design:– 1. Identifying needs and establishing requirements– 2. Developing alternative designs– 3. Building interactive versions of the designs– 4. Evaluating designs
• Three key characteristics permeate these four activities:– 1. Focus on users early in design and evaluation of artefact– 2. Identify, document and agree specific usability and user experience goals– 3. Iteration is inevitable.
• Designers never get it right first time
• Some practical issues– Who are the users?– What are ‘needs’?– Where do alternatives come from?– How do you choose among alternatives?
Who are users and “stakeholders”?(supplementary)
• I.e., for whom is the product designed?
• Picture next
• Not as obvious as might seem:– those who interact directly with the product– those who manage direct users– those who receive output from the product – those who make the purchasing decision – those who use competitor’s products
• Three categories of user (Eason, 1987): – primary: frequent hands-on– secondary: occasional or via someone else– tertiary: affected by its introduction, or will influence its purchase
Who are users and stakeholders? (supplementary) Example: Shopping Market
Check-out operators
Customers
• Suppliers• Local shop owners
• Managers• Owners
- Shoppers - interact directly with product- direct users- receive output from the product - make the purchasing decision - use competitor’s products
-primary: frequent hands-on-secondary: occasional or via someone else-tertiary: affected by its introduction, or will influence its purchase
Design Consideration: Users & Needs(as in “know thy user” and what they need)
• Who are the users? – E.g., physical:
• size of hands may affect the size and positioning of input buttons • motor abilities may affect the suitability of certain input and output devices • height if designing a physical kiosk • strength - a child’s toy requires little strength to operate, but greater strength to change batteries• disabilities(e.g. sight, hearing, dexterity)
• What are ‘needs’?– Users rarely know what is possible
– Users can’t tell you what they ‘need’ to help them achieve their goals
– Instead, look at existing tasks:• their context
• what information do they require?
• who collaborates to achieve the task?
• why is the task achieved the way it is?
– Envisioned tasks:
• can be rooted in existing behaviour
• can be described as future scenarios
Where do alternatives come from?
• “Humans stick to what they know works”– Past designs, best practice, …– But recall, “if all you have is a hammer, everything looks like a nail”
• Considering alternatives is important to ‘break out of the box’
• To oversimplify:– Designers are specifically trained to consider alternatives– Software people generally are not– Like, divergent and convergent
• How do you generate alternatives?— ‘Flair and creativity’
—research and synthesis— Seek inspiration (next slide):
—look at similar products or look at very different products— Whether software or other things
IDEO TechBox – Fostering Design(supplementary)
• Library, database, website - gizmos for inspiration
From: www.ideo.com/
How to choose among Design alternatives? (supplementary)
• Evaluation with users or with peers, e.g. prototypes
• Technical feasibility: some not possible
• Quality thresholds: Usability goals lead to usability criteria set early on and check regularly
—safety: how safe?
—utility: which functions are superfluous?
—effectiveness: appropriate support? task coverage, information available
—efficiency: performance measurements
Testing prototypes to choose among alternatives (supplementary)
Shneiderman’s“Four Pillars of Design”
• To go back to “middle of the road” interface design …
Shneiderman’s“Four Pillars of Design”
• Shneiderman: Structuring projects in this way leads to efficiencies
• A means, or methodology, to go from ideas to systems
1. UI Requirements & Observation
• User Interface Requirements
– Soliciting and clearly specifying user requirements is a major key to success in any development activity
– Laying out user-interface requirements is part of overall requirements development and management process
• Often ~all focus on task functionality, e.g., database retrieval
– User interface requirements describe system behavior
• Ethnographic Observation– Contextual Inquiry
– Identifying and observing the user community in action
– Discussed later
2. Guidelines Documents & Processes
• Looked at guidelines last time – more this time
– Recall:• Specify fairly detailed elements• Helps ensure consistency – look and feel, etc.• Use has advantages and disadvantages
• Shneiderman and many others provide detail about use of guidelines for:
– Words, icons, and graphics – Screen-layout issues– Input and output devices – Action sequences – Training
2. Guidelines Detail …, 1(recall)
• Words, icons, and graphics – Terminology (objects and actions), abbreviations, and capitalization – Character set, fonts, font sizes, and styles (bold, italic, underline) – Icons, graphics, line thickness, and – Use of color, backgrounds, highlighting, and blinking
• Screen-layout issues– Menu selection, form fill-in, and dialog-box formats – Wording of prompts, feedback, and error messages – Justification, white space, and margins – Data entry and display formats for items and lists – Use and contents of headers and footers
2. Guidelines Detail …, 2(recall)
• Input and output devices – Keyboard, display, cursor control, and pointing devices – Audible sounds, voice feedback, touch input, and other special devices – Response time for a variety of tasks
• Action sequences
– Direct-manipulation clicking, dragging, dropping, and gestures – Command syntax, semantics, and sequences– Programmed function keys – Error handling and recovery procedures
• Training – Online help and tutorials – Training and reference materials– Command syntax, semantics, and sequences
Guidelines Documents and Processes
• Utility of guidelines, again:
• Shneiderman’s “Four E’s” ….of guideline creation and utilization
– Education• User’s of guidelines need training
and chance to discuss guidelines
– Enforcement• Timely and clear process necessary
to verify that an interface adheres to guidelines
– Exemption• When creative ideas or new
technologies are used, rapid process for gaining exemption is needed
– Enhancement• Predictable process for review to
keep guidelines up to date
3. UI Tools, 4. Reviews & Testing
• UI tools– In short, tools are available, e.g., Qt for interfaces– Recall, windowing system and web browser essentially enforce guidelines and
standards
• Expert reviews and usability testing– Again, part of design process -- Next chapters
Developmental Methodologies
• Not a pleasant fact, but software projects fail– Often due to poor communication between developers and 1) clients or 2) users
• UI development intertwined with general software development methodologies
– A principle point of tonight’s talk– Recall role of iteration in interface design– I.e., user testing (perhaps only relatively late) may suggest/require “transformational”
redesign• Which is not what managers, and others concerned with costs, like to hear!
• Dozens of development methodologies
• Will briefly look at two representative project management plans– IBM’s “Ease of Use Methodology” – The Logical User-Centered Interactive Design Methodology (LUCID)
• Note how each entails same essential elements discussed so far …
IBM’s Ease of Use Methodology: Business oriented, Deliverables
• Imagine a really big organization … with lots of departments … and ponder …
• Role by phase:
IBM’s Ease of Use Methodology: Business oriented, Deliverables
• Imagine a really big organization … with lots of departments … and ponder …
• Role by phase:
= =
Developmental MethodologiesLUCID, and its Stages
• The Logical User-Centered Interactive Design Methodology– (Kreitzberg, 1996)
Stage 1: Envision– Align agendas of all stakeholders with organizational strategy and the need for “extreme usability”– Develop a clear, shared product vision embodied in a concept sketch
Stage 2: Discovery• Study users to determine high-level requirements, terminology and mental models
Stage 3: Design Foundation• Develop a conceptual design and create a key screen prototype to convey the visual style• Usability test the design, revise, and repeat
Stage 4: Design Detail• Flesh out the high-level design into complete specifications
Stage 5: Build• Support the production process through review and late-stage change management
Stage 6: Release• Develop a roll-out plan to support the users’ transition to the new product• Conduct a final usability test• Document the lessons learned
Developmental MethodologiesLUCID Components (supplementary)
The Twelve Components of the LUCID Management Strategy
1. Product Definition High Concept for managers and marketers
2. Business Case Pricing, expected revenue, ...
– Resources Duration effort, team members, …
– Physical Environment Ergonomic design, communcations, …
– Technical Environment Hardware and software for development and deployment
– Users Multiple communities for interviewing and testing
7. Functionality Service provided to users
8. Prototype Early paper prototypes, key screens, running prototypes
9. Usability Set measurable goals, conduct tests
10. Design Guidelines Modify existing guidelines, implement review process
11. Content Materials Identify and acquire copyrighted text, audio
12. Documentation, Training, and HelpSpecify develop and test, paper video and online versions
End?
• .
User Observation in Design: Ethnographic Observation of Users
• Ethnography:– Branch of anthropology that deals with scientific description of specific human
cultures– The study and systematic recording of human cultures
• Preparation– Understand organization policies and work culture. – Familiarize yourself with the system and its history. – Set initial goals and prepare questions. – Gain access and permission to observe/interview.
• Field Study– Establish rapport with managers and users. – Observe/interview users in their workplace and collect subjective/objective quantitative/qualitative data. – Follow any leads that emerge from the visits.
• Analysis– Compile the collected data in numerical, textual, and multimedia databases. – Quantify data and compile statistics. – Reduce and interpret the data. – Refine the goals and the process used.
• Reporting– Consider multiple audiences and goals. – Prepare a report and present the findings.
Observing Users: The aims(supplementary)
Benefits & challenges of different types of observation
How to observe as an on-looker, a participant, and an ethnographer
How to collect, analyze & present observational data
Examine think-aloud, diary studies & logging
Observing Users: What and When to Observe (supplementary)
• Goals & questions determine the paradigms and techniques used
• Observation is valuable any time during design
• Quick & dirty observations early in design
• Observation can be done in the field (i.e., field studies) and in controlled environments (i.e., usability studies)
• Observers can be:- Outsiders looking on- Participants, i.e., participant observers- Ethnographers
Observing Users: Frameworks to Guide Observation
(supplementary)
• - The person. Who? - The place. Where?- The thing. What?
• Goetz and LeCompte (1984) – Who is present?– What is their role?– What is happening?– When does activity occur?– Where is it happening?– Why is it happening?– How is the activity
organized?
• Robinson (1993) framework– Space. What is physical space like?– Actors. Who is involved?– Activities. What are they doing?– Objects. What objects are present? – Acts. What are individuals doing?– Events. What kind of event is it?– Goals. What do they to
accomplish?– Feelings. What is the mood of the
group and of individuals?
Observing Users: Need to Consider (supplementary)
• Goals & questions
• Which framework & techniques
• How to collect data
• Which equipment to use
• How to gain acceptance
• How to handle sensitive issues
• Whether and how to involve informants
• How to analyze the data
Observing Users: Observing as an Outsider (supplementary)
• As in usability testing
• More objective than participant observation
• In usability lab equipment is in place
• Recording is continuous
• Analysis & observation almost simultaneous
• Care needed to avoid drowning in data
• Analysis can be coarse or fine grained
• Video clips can be powerful for telling story
Observing Users: Participant Observation & Ethnography (supplementary)
• Debate about differences
• Participant observation is key component of ethnography
• Must get co-operation of people observed
• Informants are useful
• Data analysis is continuous
• Interpretivist technique
• Questions get refined as understanding grows
• Reports usually contain examples
Observing Users: Data Collection & Analysis (supplementary)
Data Collection Techniques– Notes & still camera– Audio & still camera– Video
• Data Analysis– Tracking users:
- diaries- interaction logging Qualitative data - interpreted & used to tell the ‘story’ about what was observed.
Qualitative data - categorized using techniques such as content analysis.
Quantitative data - collected from interaction & video logs. Presented as values, tables, charts, graphs and treated statistically.
Observing Users: Data analysis (supplementary)
Look for key events that drive the group’s activity
Look for patterns of behavior
Test data sources against each other - triangulate
Report findings in a convincing and honest way
Produce ‘rich’ or ‘thick descriptions’
Include quotes, pictures, and anecdotes
Software tools can be useful e.g., NUDIST, Ethnograph (see URL resource list for examples)
Observing Users: Looking for patterns– Critical incident analysis– Content analysis – Discourse analysis– Quantitative analysis - i.e., statistics
Observing Users: Summary Points
Observe from outside or as a participant
Analyzing video and data logs can be time-consuming
In participant observation collections of comments, incidents, and artifacts are made. Ethnography is a philosophy with a set of techniques that
include participant observation and interviews
Ethnographers immerse themselves in the culture that they study.
Participatory Design, 1 (supplementary)
Users are designer, too
Controversial – cases for and against
• Yes, more user involvement brings:
– More accurate information about tasks
– More opportunity for users to influence design decisions
– A sense of participation that builds users' ego investment in successful implementation
– Potential for increased user acceptance of final system
Participatory Design, 2(supplementary)
• However, negative side, extensive user involvement may
– Be more costly – Lengthen the implementation period – Build antagonism with people not involved or
whose suggestions rejected – Force designers to compromise their design to
satisfy incompetent participants – Build opposition to implementation – Exacerbate personality conflicts between design-
team members and users – Show that organizational politics and preferences
of certain individuals are more important than technical issues
Design by Scenario Development(supplementary)
Day-in-the-life scenarios:
• Characterize what happens when users perform typical tasks • Can be acted out as a form of walkthrough
• May be used as basis for videotape
• Useful tools – table of user communities across top, tasks listed down the side – table of task sequences – flowchart or transition diagram
Social Impact Statement for Early Design Review
(supplementary)
• New systems can (and do) have large impact on individuals and organizations
• Seek to facilitate change:
• 1. Describe the new system and its benefits– Convey the high level goals of the new system. – Identify the stakeholders. – Identify specific benefits
• 2. Address concerns and potential barriers
• 3. Outline the development process
Social Impact Statement for Early Design Review
(supplementary)
• 2. Address concerns and potential barriers– Anticipate changes in job functions and potential layoffs. – Address security and privacy issues. – Discuss accountability and responsibility for system misuse and failure. – Avoid potential biases. – Weigh individual rights vs. societal benefits. – Assess trade-offs between centralization and decentralization. – Preserve democratic principles. – Ensure diverse access. – promote simplicity and preserve what works.
• 3. Outline the development process– Present and estimated project schedule. – Propose process for making decisions. – Discuss expectations of how stakeholders will be involved. – Recognize needs for more staff, training, and hardware. – Propose plan for backups of data and equipment. – Outline plan for migrating to the new system.
Legal Issues of Design
• Potential Controversies
– What material is eligible for copyright? – Are copyrights or patents more appropriate for user interfaces?– What constitutes copyright infringement? – Should user interfaces be copyrighted?
End
• Materials from:– Shneiderman publisher site:
• http://wps.aw.com/aw_shneider_dtui_4/
– Preece et. publisher, Ch. 6, 12– John Klemmer’s Intro. to HCI Design course
• http://hci.stanford.edu/courses/cs147/
– MIT OpenCourseware, Robert Miller’s User Interface Design and Implementation• http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-831Fall-2004/CourseHo
me/index.htm