Fall2016.CSIS672 History

Hide minor edits - Show changes to markup

Added lines 89-93:
  1. Card Sorting
    • Card sorting is a relatively low-tech technique in UX design for using a group of subject experts or users to generate a taxonomy or hiearchical strucure of concepts or items. It is very useful for designing information architecture, workflows, menu structure, or website navigation paths.
    • Card sorting: a definitive guide - Card sorting is a technique that many information architects (and related professionals.) use as an input to the structure of a site or product.
    • Card sorting is a method used to help design or evaluate the information architecture of a site. In a card sorting session, participants organize topics into categories that make sense to them. They may also help you label these groups. To conduct a card sort, you can use actual cards, pieces of paper (and possibly software).
Changed line 18 from:
  • Test 2: TBA
to:
  • Test 2: Wednesday, Dec. 7, 2016
Added line 52:
  • What are personas and why should I care? - a quick intro from the Nielsen Norman Group.
Changed line 29 from:
  1. Designers are not users, by Jakob Nielsen, principal of Nielsen Norman Group.
to:
  1. Designers are not users by Jakob Nielsen, principal of Nielsen Norman Group.
Added lines 28-29:
  1. Designers are not users, by Jakob Nielsen, principal of Nielsen Norman Group.
Changed line 85 from:
  • An even deeper introduction to GOMS models for quantitatively predicting human performance on an interface design - focuses on notation and how to construct them.
to:
  • An even deeper introduction to GOMS for quantitatively predicting human performance on an interface design - focuses on notation and how to construct them.
Added lines 79-85:
  1. GOMS and Keyboard-Level Model
    • GOMS and KLM on WIkipedia.
    • GOMS and Keyboard-Level Model (KLM) are modeling techniques used in interactive systems to analyze complexity in user interaction.
    • Using the Keystroke-Level Model to estimate execution times.
    • A deeper introduction to GOMS with a psychology basis.
    • An even deeper introduction to GOMS models for quantitatively predicting human performance on an interface design - focuses on notation and how to construct them.
Added lines 75-78:
  1. UX/UI Prototyping Tools
    • The 7 Best Prototyping Tools for UI and UX Designers in 2016 - choosing the right prototyping tool will maximize efficiency while minimizing effort (choosing the wrong tool will waste your time, in the long term). Get to know a tool, before selecting it. Things to consider are: learning curve, type of UI (website, mobile app, desktop app, other, all), fidelity (low (sketch, wireframe), high (flow, interaction)), sharing (collaboration with teammates, users), skills required (easy, hard, programming required, visual design required), and cost (free, or how much).
    • How to choose the right UX prototyping tool - important thoughts on choosing the right tool for rapid prototyping of UIs.
Added line 72:
  • Paper Prototyping As A Usability Testing Technique - This article defines paper prototyping and explains how this technique can be used for usability testing. It is written mostly in bullet form to serve as a quick reference.
Deleted line 63:
  • How to perfect your UX with persona scenarios
Changed line 64 from:

How to perfect your UX with persona scenarios

to:
  • How to perfect your UX with persona scenarios
Changed lines 67-68 from:
  1. Use cases are written descriptions of how users will perform tasks on your system. Each use case outlines, from a user’s point of view, a system’s behavior as it responds to a request. Each use case is represented as a sequence of simple steps, beginning with a user's goal and ending when that goal is fulfilled.
to:
  1. Use Cases
    • Use cases are written descriptions of how users will perform tasks on your system. Each use case outlines, from a user’s point of view, a system’s behavior as it responds to a request. Each use case is represented as a sequence of simple steps, beginning with a user's goal and ending when that goal is fulfilled.
Changed lines 49-50 from:
  1. User personas - a user persona is a specific, imaginary example representing a set of real users - its an abstraction. As an abstraction, it focuses on the essentials, while abstracting away the unessentials. Also see:
to:
  1. User personas
    • User personas - a user persona is a specific, imaginary example representing a set of real users - its an abstraction. As an abstraction, it focuses on the essentials, while abstracting away the unessentials.
Changed lines 55-62 from:
  1. Conceptual models in a nutshell - explains conceptual models and describes why its best to develop the conceptual model of a system before its user interface.
  2. Mayhew's Usability Engineering Lifecycle.
  3. Scrum is a development process which incorporates all other development processes. It is agile and revolves around a theme of identify, implement, evaluate. It cuts through complexity to focus on building software that meets needs incrementally and empirically. Also see Scrum guide for term definitions (e.g., Sprint, Sprint Planning, Daily Scrum, Sprint Review, Product Backlog, etc.)
  4. User scenarios are the stories that your personas act out. Basically, user scenarios are thought exercises (though represented visually) in which you predict how certain types of users — represented by your personas — will interact with your UI in a given situation in order to complete a given goal.
    • Also see How to perfect your UX with persona scenarios, and Scenarios (from usability.gov).
to:
  1. Conceptual Models
    • Conceptual models in a nutshell - explains conceptual models and describes why its best to develop the conceptual model of a system before its user interface.
  2. UI lifecycle
    • Mayhew's Usability Engineering Lifecycle.
    • # Scrum is a development process which incorporates all other development processes. It is agile and revolves around a theme of identify, implement, evaluate. It cuts through complexity to focus on building software that meets needs incrementally and empirically. Also see Scrum guide for term definitions (e.g., Sprint, Sprint Planning, Daily Scrum, Sprint Review, Product Backlog, etc.)
  3. User scenarios
    • User scenarios are the stories that your personas act out. Basically, user scenarios are thought exercises (though represented visually) in which you predict how certain types of users — represented by your personas — will interact with your UI in a given situation in order to complete a given goal.

How to perfect your UX with persona scenarios

  • Scenarios (from usability.gov).
Changed line 49 from:
  1. User personas - a user persona is a specific, imaginary example representing a set of real users - its an abstraction. As an abstraction, it focuses on the essentials, while abstracting away the unessentials.
to:
  1. User personas - a user persona is a specific, imaginary example representing a set of real users - its an abstraction. As an abstraction, it focuses on the essentials, while abstracting away the unessentials. Also see:
Changed line 52 from:
  • Also see creating negative personas - how to plan for failure and user frustration.
to:
  • Creating negative personas - how to plan for failure and user frustration.
Added line 50:
  • Getting the most out of personas - personas are great, but they are all too often under utilized, or worse misused. Find out some tips for creating and using your personas, so that you can get the most out of them.
Changed line 68 from:
  • Also see Paper prototyping helper kit.
to:
  • Also see Paper prototyping helper kit.
Changed lines 60-62 from:
  • Also see How to perfect your UX with persona scenarios, and Scenarios (from usability.gov).

Use cases are written descriptions of how users will perform tasks on your system. Each use case outlines, from a user’s point of view, a system’s behavior as it responds to a request. Each use case is represented as a sequence of simple steps, beginning with a user's goal and ending when that goal is fulfilled.

to:
  • Also see How to perfect your UX with persona scenarios, and Scenarios (from usability.gov).
  1. Use cases are written descriptions of how users will perform tasks on your system. Each use case outlines, from a user’s point of view, a system’s behavior as it responds to a request. Each use case is represented as a sequence of simple steps, beginning with a user's goal and ending when that goal is fulfilled.
Changed line 62 from:

[[https://www.usability.gov/how-to-and-tools/methods/use-cases.html | Use cases\\ are written descriptions of how users will perform tasks on your system. Each use case outlines, from a user’s point of view, a system’s behavior as it responds to a request. Each use case is represented as a sequence of simple steps, beginning with a user's goal and ending when that goal is fulfilled.

to:

Use cases are written descriptions of how users will perform tasks on your system. Each use case outlines, from a user’s point of view, a system’s behavior as it responds to a request. Each use case is represented as a sequence of simple steps, beginning with a user's goal and ending when that goal is fulfilled.

Deleted lines 54-55:
  1. User scenarios are the stories that your personas act out. Basically, user scenarios are thought exercises (though represented visually) in which you predict how certain types of users — represented by your personas — will interact with your UI in a given situation in order to complete a given goal.
Added lines 59-69:
  1. User scenarios are the stories that your personas act out. Basically, user scenarios are thought exercises (though represented visually) in which you predict how certain types of users — represented by your personas — will interact with your UI in a given situation in order to complete a given goal.
  • Also see How to perfect your UX with persona scenarios, and Scenarios (from usability.gov).

[[https://www.usability.gov/how-to-and-tools/methods/use-cases.html | Use cases\\ are written descriptions of how users will perform tasks on your system. Each use case outlines, from a user’s point of view, a system’s behavior as it responds to a request. Each use case is represented as a sequence of simple steps, beginning with a user's goal and ending when that goal is fulfilled.

  1. Paper prototypes
    • Snyder, C. (2001) Paper prototyping. IBM developerWorks.
    • Nielsen, J. (2003) Paper Prototyping: Getting User Data Before You Code.
    • 7 myths about paper prototyping - paper prototyping is probably the best tool we have to design great user experiences. It allows you to involve users early in the design process, shows you how people will use your system before you've written any code, and supports iterative design.
  • Also see Paper prototyping helper kit.
Deleted lines 79-82:
  1. Paper prototypes
    • Snyder, C. (2001) Paper prototyping. IBM developerWorks.
    • Nielsen, J. (2003) Paper Prototyping: Getting User Data Before You Code.
Added lines 54-55:
  1. User scenarios are the stories that your personas act out. Basically, user scenarios are thought exercises (though represented visually) in which you predict how certain types of users — represented by your personas — will interact with your UI in a given situation in order to complete a given goal.
Added line 50:
  • User personas - finding imaginary friends for UI designers.
Changed line 56 from:
  1. Scrum is a software development which incorporates all other development processes. It is agile and revolves around a theme of identify, implement, evaluate. It cuts through complexity to focus on building software that meets needs incrementally and empirically. Also see Scrum guide for term definitions (e.g., Sprint, Sprint Planning, Daily Scrum, Sprint Review, Product Backlog, etc.)
to:
  1. Scrum is a development process which incorporates all other development processes. It is agile and revolves around a theme of identify, implement, evaluate. It cuts through complexity to focus on building software that meets needs incrementally and empirically. Also see Scrum guide for term definitions (e.g., Sprint, Sprint Planning, Daily Scrum, Sprint Review, Product Backlog, etc.)
Added lines 55-56:
  1. Scrum is a software development which incorporates all other development processes. It is agile and revolves around a theme of identify, implement, evaluate. It cuts through complexity to focus on building software that meets needs incrementally and empirically. Also see Scrum guide for term definitions (e.g., Sprint, Sprint Planning, Daily Scrum, Sprint Review, Product Backlog, etc.)
Changed line 17 from:
  • Test 1: Wednesday, Oct. 12, 2016
to:
  • Test 1: Wednesday, Oct. 19, 2016
Changed line 19 from:
  • Final: 7:30-10:30pm, Friday, Dec. 9, 2016
to:
  • Final: 8:30-10:30pm, Monday, Dec. 12, 2016
Changed line 17 from:
  • Test 1: Wednesday, Oct. 5, 2016
to:
  • Test 1: Wednesday, Oct. 12, 2016
Added line 50:
  • Also see creating negative personas - how to plan for failure and user frustration.
Changed lines 49-51 from:
  1. Conceptual Models in a Nutshell - explains conceptual models and describes why its best to develop the conceptual model of a system before its user interface.
to:
  1. User personas - a user persona is a specific, imaginary example representing a set of real users - its an abstraction. As an abstraction, it focuses on the essentials, while abstracting away the unessentials.
  2. Conceptual models in a nutshell - explains conceptual models and describes why its best to develop the conceptual model of a system before its user interface.
Added lines 48-49:
  1. Conceptual Models in a Nutshell - explains conceptual models and describes why its best to develop the conceptual model of a system before its user interface.
Changed line 17 from:
  • Test 1: Wednesday, Oct 5, 2016
to:
  • Test 1: Wednesday, Oct. 5, 2016
Changed line 17 from:
  • Test 1: TBA
to:
  • Test 1: Wednesday, Oct 5, 2016
Added lines 49-50:
  1. Mayhew's Usability Engineering Lifecycle.
Deleted lines 56-57:
  1. Mayhew's Usability Engineering Lifecycle - and a photograph of it.
Changed line 46 from:
  • NIME 2016 keynote lecture by Garth Paine - over the last two decades, the NIME community has seen an explosion of innovative and inspired ideas around the development of new musical interfaces. This lecture provides an overview of the field and important issues that emerge again and again, which may inform UI development in general.
to:
  1. NIME 2016 keynote lecture by Garth Paine - over the last two decades, the NIME community has seen an explosion of innovative and inspired ideas around the development of new musical interfaces. This lecture provides an overview of the field and important issues that emerge again and again, which may inform UI development in general.
Changed lines 40-41 from:
  • See, Silicon Valley HBO excerpt - the Pied Piper Platform Usability Test - "Totally Freaked Out" scene.
to:
  • How to talk to users during a usability test - "Echo. Boomerang. Columbo."
  • Silicon Valley HBO excerpt - the Pied Piper Platform Usability Test - "Totally Freaked Out" scene.
Added lines 44-46:
  • NIME 2016 keynote lecture by Garth Paine - over the last two decades, the NIME community has seen an explosion of innovative and inspired ideas around the development of new musical interfaces. This lecture provides an overview of the field and important issues that emerge again and again, which may inform UI development in general.
    • Also, here are photos of the lecture slides (since the video is a little grainy).
Changed line 25 from:
to:
Changed line 5 from:

Section 1: W 5:30pm - 8:30 pm / HWE 300

to:

Section 1: W 5:30pm - 8:15 pm / HWE 300

Added line 40:
  • See, Silicon Valley HBO excerpt - the Pied Piper Platform Usability Test - "Totally Freaked Out" scene.
Deleted line 43:
  • Also see, Silicon Valley HBO excerpt - the Pied Piper Platform Usability Test - "Totally Freaked Out" scene.
Changed lines 42-43 from:
  • Progressive disclosure defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone, whereas staged disclosure provides a linear sequence of options, with a subset displayed at each step. Both are strategies to manage the profusion of features and options in modern user interfaces.
to:
  • Progressive disclosure defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone, whereas staged disclosure provides a linear sequence of options, with a subset displayed at each step. Both are strategies to manage the profusion of features and options in modern user interfaces.
  • Also see, Silicon Valley HBO excerpt - the Pied Piper Platform Usability Test - "Totally Freaked Out" scene.
Added lines 38-43:
  1. Jacob Nielsen's usability pointers
    • Usability 101 -- How to define usability? How, when, and where can you improve it? Why should you care? This overview answers these basic questions.
    • Ten Usability Heuristics -- Ten general principles for user interface design.
      • Also see tips for designing Web Interfaces.
    • Progressive disclosure defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone, whereas staged disclosure provides a linear sequence of options, with a subset displayed at each step. Both are strategies to manage the profusion of features and options in modern user interfaces.
Deleted lines 49-54:
  1. Jacob Nielsen's usability pointers
    • Usability 101 -- How to define usability? How, when, and where can you improve it? Why should you care? This overview answers these basic questions.
    • Ten Usability Heuristics -- Ten general principles for user interface design.
      • Also see tips for designing Web Interfaces.
    • Progressive disclosure defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone, whereas staged disclosure provides a linear sequence of options, with a subset displayed at each step. Both are strategies to manage the profusion of features and options in modern user interfaces.
Deleted lines 44-47:
  1. Mayhew's Usability Engineering Lifecycle - and a photograph of it.
  2. Lewis, C. and Rieman, J. (1994), Task-Centered User Interface Design - A Practical Introduction.
Added lines 50-53:
  1. Mayhew's Usability Engineering Lifecycle - and a photograph of it.
  2. Lewis, C. and Rieman, J. (1994), Task-Centered User Interface Design - A Practical Introduction.
Added lines 36-37:
  1. The evolution of the desk - a thought-provoking, historically-accurate (almost) progression.
Deleted lines 38-39:
  1. The evolution of the desk - a thought-provoking, historically-accurate (almost), animated GIF.
Added lines 28-34:
  1. Heuristic evaluation involves having a small set of evaluators examine the interface and judge its compliance with recognized usability principles (the "heuristics"). See How to Conduct a Heuristic Evaluation, Usability.gov's Heuristic Evaluations and Expert Reviews, and Nielsen Norman Group's Heuristic Evaluation.
    • here are some of the most commonly used heuristics:
      • Jakob Nielsen's "10 Usability Heuristics for User Interface Design"
      • Arnie Lund's "Expert Ratings of Usability Maxims"
      • Bruce Tognazzini's "First Principles of Interaction Design"
      • Ben Shneiderman's "Eight Golden Rules of Interface Design".
Changed line 25 from:

TBA

to:
Changed lines 28-40 from:

Textbooks

  1. Debbie Stone, et al. (2005), "User Interface Design and Evaluation", Morgan Kaufmann.
  2. Donald A. Norman (2002), "The Design of Everyday Things", Basic Books.
  3. Saul Greenberg, et al. (2011), Sketching User Experiences: The Workbook", Morgan Kaufmann.

References

  • Wingfield, N. (2012), "Fresh Windows, but Where’s the Start Button?", NY Times, Oct. 22, 2012.
  • Lewis, C. and Rieman, J. (1994), Task-Centered User Interface Design - A Practical Introduction.
  • Jacob Nielsen's usability pointers
to:

References

  1. Usability.gov - the U.S. Department of Health & Human Services website on all-things related to building useable products.
  2. The evolution of the desk - a thought-provoking, historically-accurate (almost), animated GIF.
  3. Apple Watch "fails to excite" and is "a bit underwhelming" say designers - In April, Apple courted the design world by presenting the Apple Watch at a pavilion in Milan and holding a glamorous dinner for leading designers. So what do designers think of the product now – and why are so few of them wearing it?
    • Also see Apple and Hermès unveil Apple Watch collection with handcrafted leather straps - The Apple Watch Hermès Collection marks the first time Apple has released a watch in partnership with another brand and reinforces Apple’s desire to position its smartwatch as a luxury product rather than a gadget.
  4. An introduction to pair programming. This 9-minute video describes what pair programming is, the do's and don'ts of effective pairing, and the pros and cons of pair programming.
  5. Mayhew's Usability Engineering Lifecycle - and a photograph of it.
  6. Lewis, C. and Rieman, J. (1994), Task-Centered User Interface Design - A Practical Introduction.
  7. Jacob Nielsen's usability pointers
Added line 46:
  • Also see tips for designing Web Interfaces.
Changed lines 49-55 from:
  • Critchley, S., "Designing Musical Instruments for Flow", O'Reilly Digital Media, December 29, 2004. (If you ask musicians what they value most about making music, most of them will say — in some form or another — flow. Flow is that wonderful sense of being lost in your work, when "work" becomes joy. Time disappears, and so do distraction, anxiety, and just about everything else, yielding to a pure unity of creator and creation. So wouldn't it be strange if many of today's musical instruments were designed to prevent or destroy flow?)
  • Color scheme designer for user interfaces.
  • 6 tips for designing Web Interfaces.
  • Paper prototypes
to:
  1. Critchley, S., "Designing Musical Instruments for Flow", O'Reilly Digital Media, December 29, 2004. (If you ask musicians what they value most about making music, most of them will say — in some form or another — flow. Flow is that wonderful sense of being lost in your work, when "work" becomes joy. Time disappears, and so do distraction, anxiety, and just about everything else, yielding to a pure unity of creator and creation. So wouldn't it be strange if many of today's musical instruments were designed to prevent or destroy flow?)
  2. Paper prototypes
Changed lines 55-57 from:
  • Yahoo! Design Pattern Library
  • Intro to Python
to:
  1. Intro to Python
Changed lines 58-62 from:
  • Jeffrey Elkner, Allen B. Downey and Chris Meyers (2008), "How to Think Like a Computer Scientist - Learning with Python)", 2nd ed., The Open Book Project.
  • B. Manaris, V. MacGyvers, and M. Lagoudakis, "A Listening Keyboard for Users with Motor Impairments—A Usability Study," International Journal of Speech Technology 5(4), pp. 371-388, Dec. 2002. (This usability study shows that speech interaction with an ideal listening keyboard is better for users with permanent or task-induced motor impairments than conventional modes for alphanumeric input (37% better task completion time; 74% better typing rate; 63% better error rate). Results are shown relevent to alphanumeric input on mobile devices, such as PDAs, cellular phones, and personal organizers.)
  • Wikipedia, Fitt's Law, Hick's Law, and Power Law of Practice.
to:
  1. jythonMusic provides software for music-making and creative computing. It is a collection of Jython libraries for music, images, graphical user interfaces (GUIs), and connecting to external MIDI devices, smartphones, and tablets, among others.
  2. Color Scheme Designer and for user interfaces.
Changed line 5 from:

Section 1: W 5:30pm - 8:30 pm / HWE 105F

to:

Section 1: W 5:30pm - 8:30 pm / HWE 300

Changed lines 5-6 from:

Section 1: W 5:30-8:30PM / HWE 105F

to:

Section 1: W 5:30pm - 8:30 pm / HWE 105F

Added line 13:
Added lines 1-61:

Human Computer Interaction

When/Where

Section 1: W 5:30-8:30PM / HWE 105F

Description

Introduction to human-computer interaction and user-interface development. Topics include human factors of interactive software, interactive styles, design principles and considerations, development methods and tools, interface quality and evaluation methods. This course stresses the importance of good interfaces and the relationship of user interface design to human-computer interaction. It is intended for students whose future work may involve software development.

Prerequisites: Each student must have completed CSCI 230 (Data Structures and Algorithms) or an equivalent or higher course, or have permission of the instructor. Minimally, each student should have strong background in software development, data structures, and algorithms; also strong background in a high-level programming language such as Python, Java, or C/C++.

Test Dates

  • Test 1: TBA
  • Test 2: TBA
  • Final: 7:30-10:30pm, Friday, Dec. 9, 2016

Assignments / Projects

Homework1, Homework2, Homework3, Final Project.

Textbooks

  1. Debbie Stone, et al. (2005), "User Interface Design and Evaluation", Morgan Kaufmann.
  2. Donald A. Norman (2002), "The Design of Everyday Things", Basic Books.
  3. Saul Greenberg, et al. (2011), Sketching User Experiences: The Workbook", Morgan Kaufmann.

References

  • Wingfield, N. (2012), "Fresh Windows, but Where’s the Start Button?", NY Times, Oct. 22, 2012.
  • Lewis, C. and Rieman, J. (1994), Task-Centered User Interface Design - A Practical Introduction.
  • Jacob Nielsen's usability pointers
    • Usability 101 -- How to define usability? How, when, and where can you improve it? Why should you care? This overview answers these basic questions.
    • Ten Usability Heuristics -- Ten general principles for user interface design.
    • Progressive disclosure defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone, whereas staged disclosure provides a linear sequence of options, with a subset displayed at each step. Both are strategies to manage the profusion of features and options in modern user interfaces.
  • Critchley, S., "Designing Musical Instruments for Flow", O'Reilly Digital Media, December 29, 2004. (If you ask musicians what they value most about making music, most of them will say — in some form or another — flow. Flow is that wonderful sense of being lost in your work, when "work" becomes joy. Time disappears, and so do distraction, anxiety, and just about everything else, yielding to a pure unity of creator and creation. So wouldn't it be strange if many of today's musical instruments were designed to prevent or destroy flow?)
  • Color scheme designer for user interfaces.
  • 6 tips for designing Web Interfaces.
  • Paper prototypes
    • Snyder, C. (2001) Paper prototyping. IBM developerWorks.
    • Nielsen, J. (2003) Paper Prototyping: Getting User Data Before You Code.
  • Yahoo! Design Pattern Library
  • Intro to Python
    • Magnus Lie Hetland, Instant Hacking in Python (for non-programmers) and Instant Python (for programmers).
    • John Zelle, Teaching Computer Science with Python transparencies: one slide per page and four slides per page (PDF).
    • Jeffrey Elkner, Allen B. Downey and Chris Meyers (2008), "How to Think Like a Computer Scientist - Learning with Python)", 2nd ed., The Open Book Project.
  • B. Manaris, V. MacGyvers, and M. Lagoudakis, "A Listening Keyboard for Users with Motor Impairments—A Usability Study," International Journal of Speech Technology 5(4), pp. 371-388, Dec. 2002. (This usability study shows that speech interaction with an ideal listening keyboard is better for users with permanent or task-induced motor impairments than conventional modes for alphanumeric input (37% better task completion time; 74% better typing rate; 63% better error rate). Results are shown relevent to alphanumeric input on mobile devices, such as PDAs, cellular phones, and personal organizers.)
  • Wikipedia, Fitt's Law, Hick's Law, and Power Law of Practice.