Design Tool Studio
Taught by Patrick Hebron at ITP, Spring 2016
Previous Edition: Spring 2015
There is no one right approach or methodology in design.
If we all took the same path, we might all end up in the same place.
This course is presented as a project development studio, which means that the curriculum is here to support your individual projects.
Therefore, you should always feel free to do things your own way (reinterpret assignments, etc).
However, some of the in-class work and homework assignments involve assisting or reflecting upon the work of your peers. Here, you should only reinterpret assignments in ways that are mutually agreeable to the classmates with whom you are working.
As a project-oriented class, the curriculum will be adapted and revised somewhat over the semester to meet student interests, etc. So please check back for updates and changes. And please let me know in person or by email if you would like a particular technical subject to be addressed during class time. I'm happy to cover any subject in C++ or software architecture in general that would be useful to you.
Two Poems about Toolmaking:
Before the first class:
Read the first section of Buckminster Fuller’s book, Operating Manual for Spaceship Earth. The section is called “Comprehensive Propensities” and can easily be found online.
Please consider the following questions and be prepared to discuss them in class next week:
- What are some of the “piano tops” that exist within the digital design tools you use today? Try to think of examples that carry over from the pre-digital era as well as ones from an earlier age of computing.
- What are some of the ways that the tools you use make a clean break from their predecessors?
- Are there any tools that have no predecessors at all? And if so, what sorts of problems do they solve?
- What would a world without “piano tops” be like?
- Discussion of Buckminster Fuller reading
- Turtles all the way down: Re-inventing the while-loop in C/C++
- Discussion of initial project ideas and areas of interest
- In-class exercise: From Intuition to Exploration
From Intuition to Exploration:
- Form groups with classmates who are interested in a similar domain
- With your group, discuss the current landscape of this design area. Here are a few possible considerations:
- Who has this sort of design problem or uses tools in this domain?
- What tools already exist in this space?
- What are the strengths and weaknesses of these tools?
- Which of these weaknesses are the most challenging to overcome and which are the least?
- Individually, make up a list of assumptions about this design space and its necessary or essential elements
- Get back together with your group and discuss your points of view, assumptions and premises. Here are a few possible considerations:
- Which assumptions seem universal or inescapable?
- Which seem contextual, cultural, temporary or like "piano tops?"
- Individually, consider how this group discussion challenges or strengthens your earlier assumptions:
- What do you feel more certain of?
- What do you feel less certain of?
- What tests, prototypes or experiments might help you to further investigate your assumptions?
- What were the unique elements of your perspective on this design area?
- What tests, prototypes or experiments could you produce to showcase a unique element of your perspective?
- As a continuation of the in-class exercise described above, please perform one (or a few) such experiments. This can be done through code or any other means that seems appropriate to your inquiry.
- Meditation: On Description by Patricia F. Carini (from the book, Starting Strong: A Different Look at Children, Schools, and Standards, TC Press, 2001)
- Gears by Seymour Papert (from the book, Falling for Science: Objects in Mind, edited by Sherry Turkle)
- Pixar Case Study: Determining the Benefits of Direct-Touch, Bimanual, and Multifinger Input on a Multitouch Workstation
- New York Times review of Portal 2: Physics, With Wormholes by You
- Discussion of readings and video
- In-class exercise: Describing an Object
- In-class exercise: From Exploration to Formalization
- Technical Case Study: STL Containers: Capabilities and Constraints
Describing an Object (based on Prospect Center's Methodology):
- Take a few moments to consider the object (which will be revealed in class)
- Make one statement of something you notice about the object - how it looks or smells, its texture, etc.
- We will go around the room a few times to hear several descriptive statements from each person
- Feel free to describe a feature that has already been mentioned, but as a group, try to cover numerous dimensions of the object's being
- Stay with the object and your direct observations of it rather than things you might know about it from other contexts
- Do not be afraid to say something that seems totally obvious - everyone notices different obvious things and it is valuable to see that spectrum emerge from the group
From Exploration to Formalization:
- Each student will present his or her homework explorations to the class
- Members of the class should respond to the work presented descriptively, not qualitatively
- Resist the urge to extrapolate on intent or draw inferences about where an idea might be headed
- Stay with your direct observations and don't be afraid to say something that seems obvious:
- What are some features of the work?
- What themes do you notice in its components?
- Based on the class' observations, take a few moments to consider the following questions individually:
- Where did you succeed in bringing across an idea?
- Where was your idea seen differently from what you had been thinking about?
- What themes do you want to clarify or bring forward in the work?
- Which features of the work were extraneous to your conveying the idea?
- Spend some time talking with your classmates about these explorations. Run ideas past them, ask questions about their earlier observations, etc.
- Go back to your explorations and try to formalize. Emphasize the essential, find a pure distillation of the ideas you were pursuing in the earlier exploration.
- Start to think about how to expand a feature set from your explorations and their formalizations:
- One way of formalizing a feature set is to write a list of "user stories" - simple statements like: "As a user, I should be able to adjust an image's brightness and contrast."
- From this high-level view of the feature set, try to identify some of the data structures and transformations implicit in what you've described. For the example above, we might identify the need for an image container of some sort and various functions to manipulate its pixel values. For now, we won't worry about the implementation details.
- Consider the paths that seem to lead inevitably from your idea. As Chekhov said, "If you say in the first chapter that there is a rifle hanging on the wall, in the second or third chapter it absolutely must go off."
- Discussion of readings and video
- In-class exercise: From Formalization to Iteration
- Technical demonstration: Polymorphism, Inheritance and Common Design Patterns in C++ Code
From Formalization to Iteration:
- Students will present their "feature sets" / "user stories" to one another in small groups.
- In responding to your classmates' work, don't try to change the presenter's point-of-view. Instead, try to help him or her refine it. The goal is to provide feedback that will help the presenter create a clear plan of attack for developing the technical components of the project.
- Which features or user stories seem most essential to the idea?
- Which seem extraneous, unresolved or confusing?
- Which features will be difficult to implement?
- Can you think of any code or conceptual reference points that might be useful to the presenter?
- Do you see any missed opportunities? ("Since you're already doing X, you could easily extend that to Y...")
- Go back to your feature set, reflect upon your earlier work and the comments made by your peers.
- From these reflections, start to develop a plan of execution:
- Create a list of priorities:
- Which features are technically indispensable? For example, if you're building a 3D mesh editor, you might reason that "users must be able to load models from a standard file format like .obj"
- Which features are philosophically indispensable? These features may not be absolutely essential to base functionality, but they are key to the creative perspective you hope to instill in your software.
- Which features are not completely essential to your idea, but would improve usability, performance, etc?
- Now try to estimate / rank the difficulty or time commitment required to implement each of these features. Doing so may require a bit of research:
- Where can Cinder or other open-source libraries help?
- Where will I need to learn more about a particular computational or mathematical idea?
- If you reach questions you don't feel you can answer on your own, bring them into class next week.
- Create a preliminary sketch of your technical architecture:
- What are the core systems?
- How do these core systems communicate with one another?
- What design patterns might be used assembling these systems?
- Announcements and discussion of readings and video
- Technical demonstration: An Architectural Overview of the Cinder Creative Coding Framework
- Brief "progress report" presentations and peer feedback
- One-on-one meetings to discuss individual projects
- In-class work-time
- Start executing your technical plan:
- Feel free, of course, to approach this process in your own way. Here are a few things that might help you dive in:
- Gather your tools: If you're planning to work with any third-party libraries or platforms you're unfamiliar with, take some time to make sure that you've got all the basic pieces working together. If you find some technical conflict - a library that doesn't work on certain machine architectures, for example - it is easier to course correct early on. If you're having any integration issues with third party libraries, etc, please schedule office hours with me.
- Before going too deep on any particular component, it's often advisable to work out the general relationships between components. Frame out your core systems and gradually add features / details as you go.
- Toward a Theory of Architecture Machines by Nicholas Negroponte
- Excerpt from Mindstorms by Seymour Papert
- For this assignment, please read:
- Introduction: Computers for Children and Chapter 1: Computers and Computer Cultures
- I highly encourage you to read the entirety of this groundbreaking book at a later date
- Discussion of readings
- In-class exercise: From Iteration to Reflection on Process
- Last minute technical questions and opinion polls:
- If you've got some unresolved design detail, etc - ask your classmates about it!
From Iteration to Reflection on Process:
- What did you learn in the process that might have changed your initial approach?
- What would you do exactly the same way?
- How were your high-level concepts impacted by low-level technical or design considerations?
- How did your high-level technical architecture evolve as you worked through low-level considerations?
- Think about the tools you used to develop your project:
- In what ways did these tools aid your creative process?
- In what ways did they hinder your process?
- How did these tools shape your overall vision for the project?
- Were there things about these tools that seemed more challenging, confusing or limiting than was necessary?
- Were there things you were hoping to achieve that you couldn't because of limits in the underlying tools?
- What would have been required to get around these limits?
- How might someone answer the above questions in relation to the tool you've developed?
- How did your process of building this tool influence your understanding of using tools?
- How could you fold this experience back into your tool's point-of-view?
- When is a project finished? Is this project finished?
- Prepare you project for final presentation. Be ready to:
- Discuss your project and development process
- Give a quick demonstration of the tool and its capabilities
- Have your classmates interact with the tool and provide feedback