Author Archives: Lana Yarosh

About Lana Yarosh

Svetlana “Lana” Yarosh is an Assistant Professor in the Computer Science & Engineering Department at University of Minnesota. Her research in HCI focuses on embodied interaction in social computing systems. Lana is currently most proud of being one of the inaugural recipients of the NSF CRII award, of her best papers at CHI 2013 and CSWC 2014, and of receiving the Fran Allen IBM Fellowship. Lana has two Bachelors of Science from University of Maryland (in Computer Science and Psychology), a Ph.D. in Human-Centered Computing from Georgia Institute of Technology, and two years of industry research experience with AT&T Labs Research.

Reflecting on “Advice for New Faculty Members”

Posted on by
1

boiceI recently finished reading the book “Advice for New Faculty Members” by Robert Boice. It was recommended to me by Jeff Hancock during his visit to University of Minnesota and it was so helpful that I would be remiss if I didn’t pass along the advice to others. Some of you will be starting your faculty positions in the Fall (I wish I had read this book when I started), but I certainly found it helpful even though I’ve already been at this for a year.

This book is different from other sources of advice in that the insight comes not from Robert Boice’s own experiences, but rather from a series of empirical investigations of “quick starter” new faculty members. While there are several places you can find reviews of the book and summaries of some of its lessons, I wanted to focus on three pieces of advice in this book that I’ve found most surprising and most helpful (so far) in integrating into my own work practices:

  • The power of 15-minutes daily. As a new faculty member, many people gave me the advice to make time for writing. I did my best, trying to squirrel away entire afternoons or days for writing. However, I always found that other things came up, eating away at that time. When planning for a whole afternoon but ending up with only thirty minutes, I felt dejected and that it wasn’t worth attempting to get any serious writing done in that period of time. Instead, this book recommends planning to spend 15-30 minutes on pre-writing (e.g., outlining, brainstorming) and writing practices daily. This also mirrors great advice on making use of workable “bits” that I had previously read from Nick Feamster’s research practices blog. I was dubious as to whether this would work for me (“Isn’t there a cost in switching contexts in writing?” I thought), but trying it for a month, I found myself producing more consistently (in July: co-writing a 12-page grant, rewriting a journal paper that needed major revisions, and co-writing significant revisions for a CSCW paper) and less painfully.
  • Asking for feedback early and often. Boice recommends this practice for teaching, research, and service. I had already heard this advice for teaching during my orientation at U of M. Indeed, asking students and visiting faculty for feedback early and often led me to change my class to be more useful to students. Coincidentally, the advice counseled me to limit the amount of material covered each class, which also meant less time that I spent preparing for each session (which is a practice this book encourages for new faculty). However, in research, I have had a harder time asking for early feedback on in-progress papers and research ideas. This coming year, I am committed to finding at least two people to serve as a sounding board on each of my major projects. I suppose this piece of advice is not actually that surprising, but for some reason I never thought about extending the value that I got from getting frequent teaching feedback to the potential value I could get from getting frequent research feedback.
  • Stopping or pausing as a way of increasing productivity. This seemed really counterintuitive to me — how could stopping when I’m “on a roll” lead to more productivity? Previously, when I wrote and I got going, I’d try to really get as much as I could, squeezing every last word out of the moment. However, I failed to realize that this would inevitably lead to not wanting to write the next day and having a hard time starting next time I write. Of course, I didn’t want to start again: I was rewarding each start with a grueling 12-hour workday and I was ending when I was completely out of momentum! This lesson also mirrors Al Franken‘s advice to writers to “Park on the down-slope,” to make it easy to start again. During the past month, I’ve made an effort of stopping each writing session after 30 minutes, even if I am in the middle of a sentence, this has really helped me maintain the practice of daily writing and led to overall increases in the amount of writing I have done.

I’m sure others may find the bits I pulled out obvious but find value in other aspects of the book. Regardless, I definitely recommend this book to others (if you’re at U of M, I have a copy to borrow) and would love it if you could share the bits that you found to be most surprising, interesting, or useful to your work practices.

Sketching with Computer Science Students

Posted on by
Reply

Last semester, as part of my Design Methods class (more here, if you want any of the materials), I attempted to teach Computer Science students how to sketch. Each student had to practice sketching and submit at least one of their own sketches as part of the project milestone. While initially, this prospect caused some anxiety for the students, most were able to find a style and an approach to creating visual content that worked for them.

We relied heavily on Sketching User Experiences: The Workbook (Saul Greenberg, Sheelagh Carpendale, Nicolai Marquardt, and Bill Buxton), which does a great job explaining the benefits of sketching to the overall design process and providing some strategies for those who are less artistically inclined. Particularly, the books tutorials on storyboarding, simplified figures (e.g., stick figures), and photo tracing were used by the students with great results.

Students successfully used storyboarding, simplified figures, and photo tracing in sketching their design ideas.

Students successfully used storyboarding, simplified figures, and photo tracing in sketching their design ideas.

We added another skill to our sketching repertoire that was not covered in the workbook, namely constructing two-point perspectives. I chose to add this to the curriculum because I’ve found the rule-based approach of this method is generally well-received by engineers and is particularly useful in sketching and considering physical computing prototypes.

Many students were very successful in constructing two-point perspective sketches, even if they were resistant to less structured sketching approaches.

Many students were very successful in constructing two-point perspective sketches, even if they were resistant to less structured sketching approaches.

I found that the process of sketching out ideas helped students think divergently. For the last milestone, the students were asked to develop two prototypes that they found to be most promising, with a special focus on diversity of modalities and ideas in the final prototypes they chose to pursue. I was very impressed with the results!

prototypes

Some of the physical prototypes students developed from their sketches for the final class milestone.

In final student evaluations of course content, sketching was the component that worried me most. This is so different from a standard Computer Science skill or activity that I had to wonder whether students would find it valuable in retrospect. Indeed, in their final ranking of the thirteen components and skills covered in the class, sketching came in at #4! It was one of the most valued components of the class, despite (or maybe because of?) any initial trepidation students expressed about their drawing skills. I’ll definitely continue including this unit in the course in the future!

(Note: Images are used with permission from each project group, asked and received after the submission of final grades.)

Peer Teaching Presentations in a Curriculum

Posted on by
2

I haven’t blogged last semester, as I’ve been devoting my energy to teaching my first class (which went great according to the student evals!). The class, titled “Design Methods for Computer Scientists,” was a project-based course covering inspiration methods (e.g., design probes), design process, sketching, and rapid prototyping (e.g., 3D printing, Arduinos). As always, I want to share my materials, so here is the syllabus and the project description. But in this blog post, I want to reflect on one specific component of the class, peer teaching.

The goal of this component was to help students practice independently learning new skills and teaching these skills to their peers. Each student was asked to prepare a 20-minute class session on a topic of their choice that may be useful to others in the class (see, peer teaching description and rubric). Most of the presentations focused on cool APIs, tools, and techniques for rapidly bringing design ideas to life. Topics covered included: Arduino eTextiles, littleBits, Intel IoT kits and Galileo, WebRTC, GreaseMonkey, Processing, PhoneGap, and many more interesting topics. The presentations were spread throughout the semester and graded both by me and by the other students in the class (40% of the grade coming from written peer critiques). In terms of the short-term goals, I was excited to see that the student presentations generally increased in quality as the semester went on, with them getting presentation tips from each others. Additionally, it was great to see that students incorporated techniques covered in peer teaching presentations into their projects, so they definitely learned through the process. The long-term goal of this component is to keep the class material from getting stale by continually updating the parts that are most likely to change quickly (e.g., tools and technology available for prototyping), but efficacy towards this long-term goal is still to be demonstrated.

At the end of the class, I asked student to rate the personal utility of each class component. Out of 13 class components, peer teaching came in right at about the middle of the pack as the 5th most useful. Through discussion with students, we considered how this can be improved and came up with some directions for the future. Next time I run the class, I’ll be asking for peer-teaching presentation to submitted as 20-minute tutorial videos and asking each student to watch 10 and critique videos that are most relevant to them. There are several advantages as I see to this approach:

  • The presentations were great, with the most helpful parts generally being the hands-on demos and walkthroughs. Even though presenters shared their slides, the demo portion of their presentations was ephemeral and students could not refer back to it.
  • Collecting peer teaching tutorials as video would help us build up a library of resources across years.
  • All the presentations can be due on the same day (making this more fair) and all of them can be available in time for the prototyping milestone. As is, about a quarter of the talks occurred after they could be usefully integrated into the students’ projects.
  • It would free up significant time in class, which would be best used for project workgroups. I underestimated the difficulty that student groups have in meeting up outside of class, adding in-class time that the all have to be there would really help. Next time I teach, I’d like to keep Mondays as project days.
  • Students who do a great job can share this tutorial widely and add it to their portfolio as an example of their work.

Has anybody tried something like this in their classroom? I would love to hear how that went! Stay tuned for more reflections from teaching, including some examples of cool projects that came out of the classes.