Recent Changes - Search:


Course Info

2012 Class Notes

2012 Students

Student Groups


2009 Students

Student Groups


2006 Class

2006 Faculty

2006 Evaluations

Lecture Notes

2006 Students

Student HWs

API Groups

Student Groups


Wiki Docs

edit SideBar


Course evaluation discussion

6 December 2006

White hat

  • We had guest speakers
  • Non CS folks in class
  • 3 professors
  • Breadth of reading materials
  • Studied design processes from different disciplines
  • We had a wiki
  • First design project had little to do with software, later project was software intensive
  • We viewed a lot of slides
  • We partnered with different people over the semester

Red hat

  • Not the worst class I have ever taken—it was a good class
  • I looked forward to coming
  • I dreaded Tuesdays but I enjoyed Wednesdays
  • Some people felt bad for the non CS majors
  • I worried about the non CS majors
  • Class was not structured as well as it could have been to accommodate the non CS people
  • I felt a lack of consistency in our planning—it fell apart when we got to the APIs part (GGG)
  • I felt like the lectures were speed dating—you met a lot of people but never got to sleep with anyone. Better to learn a few things in depth. The end actually was better in our ability to explore things as a class.
  • Should have done more in-process evaluation at each stage, since this is an experimental course we should have checked in more frequently.
  • When we were presenting and getting critique THAT’s when we were really creating a context for creative design.
  • Beginning of class was too structured.
  • Good to have weekly presentations, but should have had clearer goals for each week’s presentation. Weekly presentations were somewhat redundant.
  • GGG: I was completely frustrated because I didn’t think I was giving you guys much value.
  • I liked the stuff in the middle—the what are you designing for? The what is the purpose or goal of your work—the Papanek.
  • From a non CS student, a lot of the skills were transferable to non-CS environment. How can I use this in designing a health education intervention. This course moved from radical design to radical software design. Not a total loss for us non CS students.

Yellow Hat

  • Speakers and field trips.
  • Exposure to non-CS design.
  • Wiki was great.
  • Willingness of professors to disagree publicly, and willingness to change course if things were not working.
  • That Google engineer paper that Fred and Matt sent around. Effortless reuse of software by all at company. See parallel between that and what we did here. Great paper!

Green hat

  • The importance of culture and tools. Kipp Bradford—LabView. Simple, crude, even laughable tools can be really useful.
  • Resource rich environments, ala IDEO, supports creativity.
  • We really created a creative culture in the classroom.
  • More people from industry, creative people.
  • Bring in coding earlier to get further on the APIs.
  • Maybe a more restricted set of APIs.

Black hat

  • Need better real world examples of how you would use things. Have some very specific examples of how to use fewer tools.
  • Curt had a better example of how to use a tool than came from the slides. Give real world examples.
  • Use well tested APIs.
  • Need more checking in and correcting course in the second half of the course.
  • Pick most promising APIs.
  • Need more feedback to what is posted on wiki.
  • Get MediaWiki. Have templates and help. Need a clone of Matt.
  • First half of class I spent 3 hours looking at slides. That is not appropriate for an exploratory and creative class. Growing discussion instead of a bombardment would have been good. Lecture on strength of materials seemed irrelevant.
  • But this exposure can also be a benefit.
  • Too much reading up front, then none at all.
  • Need more case studies and examples. In future, use examples of projects from this class.
  • Sometimes we said things were good because of the process that got us there; I was waiting for my flaws to be exposed.
  • First round of projects not grounded in reality. Not grounded in actual constraints.
  • Paul Graham also spoke of the difference between school and real world projects; in the latter you are asked how far you still have to go, not how much you have accomplished.
  • None of the products are radical in any way. We lost the radical context.
  • Templates could have been rehearsed better by the professors.
  • Too much ambiguity. Where to focus—application or API??
  • I thought our first project would have something to do with our second project—it seemed like a waste to throw away all the learning from the first project.
  • Is it truly useful to use APIs—you don’t own your own code base, and most APIs are bad. A few are really good but most are not—no good or too complex.
  • Problem of definition of APIs. Does it matter for our premise whether something is an API or a language. Matt: use the things that work for you, if you are beating yourself over the head stop using it.
  • GGG: the radicalness was not explored, took too long, we faculty should look very closely at the APIs before the class begins.
  • Group APIs by language. Make it like assembling Lego bricks.
  • We need to set up the course to use non CS people in a better way.
  • Curt: is the API a good way to develop software? This course has not answered that question for me. How do we evaluate what is good or bad about an API?
  • Damon: a lot of this is not taught, it’s passed by word of mouth in companies. A lot is taught by example. You see the power of it and want to emulate that.
  • Mike: Keewook and Georges both talked about putting Legos together as analogy for API programming.
  • The course evaluation we are doing right now is really good. Matt says that this was true of Fred and Sarah’s classes.
  • The value of this course lies in EXPERIENCING these things, not in viewing slides. Slides contained a lot of knowledge but interaction was more valuable. Our discussions after class were great, especially after Wednesday’s class.
  • GGG I agree that more experiential learning is necessary, with less lecturing.
  • Software fails when you don’t know enough about who will be using the software and how.
  • These are great approaches for people who are driven and want to do good work.
Edit - History - Print - Recent Changes - Search
Page last modified on December 22, 2006, at 08:51 PM