Sunday, May 25, 2008
Lessons learned from teaching “Technologies for Online Communities” - a new course on creating “social networking” websites at APOC
Last semester I taught a groundbreaking course in the Annenberg Program on Online Communities at USC’s Annenberg School for Communication. It’s the first (and as far as I know, the only) one-year MA program that focuses exclusively on building and cultivating online communities. Titled “Technologies for Online Communities,” it’s a grad-level introduction to technical concepts and managerial/collaborative methodologies. Now that the semester has ended, I have a short bit of time to reflect before I start the next course in the program sequence - a research methodologies course led by Mathew Curtis in the psychology department, where I’ll be teaching online-specific research concepts and tools.
The goal of the course was to create product developers and project managers for “social networking” websites. Half (50%) of the surveyed class described their experience with technical concepts at the start of the class as “novice.” This was a pretty tall order: bring the class from novices to managers with a strong understanding of core concepts in 16 weeks. The course was a success, but as always, teaching is also a learning experience. Here I present a few takeaway lessons for instructors or professors considering similar courses or approaches.
1. Teach concepts as they are encountered, not how you learned them
I introduced concepts in a top-down fashion, because it’s how I was taught and how I best understand the material. By top-down I mean bringing in technologies and collaborative methodologies as they exist structurally: start with the client side, talk about HTML and web browsers, then move on to the server side, and talk about databases and client-side development.
The sequencing of materials will definitely be altered to better reflect how they are encountered during the design and development process, particularly how product design integrates with technical development. On the last day of class, Karen North, the director of APOC, handed me a syllabus for a similar course in online development. This course sequenced material in order of how it would be used to create a website. The course was basically one large problem-solving activity strongly connected to real-life, similar to a semester-long PBL exercise. Concepts were introduced based on how they are encountered in the development process. For instance, at the start of the development process, a server would need to be secured, which would also entail discussion of how servers work. This altered sequence would address requests throughout the semester for more examples and provide an ongoing, coherent narrative with real-life applications.
2. Splitting your brain is okay, to a point
The course material was split thematically into technologies (programming languages, client-server development, APIs) and collaborative/managerial methodologies (agile, recruiting talent, writing specifications). Students completed the same coursework, with the exception of the final project. The final project, which was among the highest-reviewed course components, was to create a presentation on either technical or managerial concepts. Most of surveyed participants found the technical portions of the course “beneficial” (averaging a 4.0 out of 5) while slightly fewer positively responded to the managerial portions of the course. While students generally found the two sections of the class to be overall beneficial to their learning, several offered suggestions on how course material was sequenced. These suggestions were mixed, and included a reversal of the order of material presented, de-emphasizing coding, and separating this single course into two courses.
I’m sticking to my guns here; I would like to preserve the ability for students to focus on either technical or managerial concepts in the final project, while encountering in all the class material through discussions, readings, and homework. While I think two separate courses would be appropriate, it’s unlikely that the program can support both. Throughout the semester I found students either naturally gravitated to either programming or managerial concepts. Students will naturally end up being professionals that accentuate either one or the other, depending on their personality and interests. By the end of the course, students should have a much better idea of the type of role they will play upon graduation. So it makes sense there is no “one size fits all” solution for students, and they will become more specialized.
3. Create managers who develop sites, not programmers who develop sites
Deciding how technical to get in an introductory skills course is a risky balancing act. Too much technical focus may lead to confusion, while too little technical information may not give students the core understandings they require. One of the decisions I made early on was to not turn the course into simply a raw programming course in, say, javascript. Students in a one-year MA program on online communities aren’t going to become software engineers over the span of one semester. Even if they did become wizzes in javascript, they wouldn’t receive enough tangible benefits to the larger picture: creating living, breathing, online communities.
So, from the start I was aware that the course could not create software engineers. Even aware as I was, I went a little too far; one place the class stumbled was in understanding object-oriented programming (OOP). This core concept could have been introduced more coherently, more slowly, or omitted entirely. I’m going to go out on a limb here and say meta-programming packages might be a more approachable alternative to “true” programming for novices. Drupal, for example, while esoteric in setup, allows students to get a social networking site up and running immediately. Being able to quickly create and modify a site in real-time offers both technical and attitudinal benefits.
Technically, students would encounter concepts such as PHP and database design within a safe framework. They would get the thrill of quickly creating and taking ownership of a database-driven website, which would be otherwise impossible for novices to accomplish in a single semester. The big downside to closer incorporation of a package like Drupal is that its inner workings (PHP, databases) would need to be appropriately described, otherwise its value as a teaching tool would be diminished. For instance, AJAX requires a solid understanding of javascript (client-end dev), client-server networking, and remote APIs (e.g. REST). Even if AJAX somehow went away in 2 years time or was replaced by Flash or Flex, the remaining concepts would still be valuable. If all students learn is how to use a particular type of CMS or templating system, which doesn’t exist in a few years, they may not have these valuable core concepts to fall back on.
4. Jettison components that aren’t accomplishing what you hoped, add new ones
Quizzes were the lowest-reviewed course component (which were: homework, readings, quizzes, in-class exercises, lectures, and final project). Ideally, viewed through Bloom’s taxonomy, quizzes help retention of low-level cognitive concepts, leading into higher-level understanding and application. But if students aren’t finding this part of the course beneficial, I may reduce it or cut it out entirely in future years. Quizzes are useful in undergrad courses as, frankly, a salient threat to do the reading and pay attention. For a grad-level course they may not be necessary, as grad students are more involved, driven and attentive. As long as students are involved with the course, low-level knowledge acquisition may better occur through small group activities or lab exercises.
Even though the course was paired with another course, which had industry speakers every week, the connection with industry needed to be stronger in this class in particular. I’m taking time over the summer to collect first-person reports from industry to roll in with next year’s course, particularly as concerns APIs (such as OpenSocial), monetizing contextualized data (directed marketing), and more freeform collaboration in the building process (e.g. Google-style project development).
5. Encourage direct and immediate classroom responses
This isn’t so much related to this course as teaching as a whole. As much as we talk about listening to our users, the same mantra applies to students. There is no substitute for an aware and receptive instructor. The semester is rather short, and the material is at times imposing and demanding of students, particularly novices. The overview skills course should be an agile u-boat that can turn at a moment’s notice, not an overgrown tanker that takes time to alter course. Noticing immediately where students are encountering difficulties is absolutely necessary to adapt the material to their needs. Additionally, paying close attention to them may offer perspectives that are more likely to reach fellow students than your own. In the case of this course, many students were well-versed in one or more topics, even if they didn’t have a grasp of all areas. For instance, one student had a deep knowledge of widgets, and was helpful in contributing practical examples of how her work life centered on interacting with developers to create widgets. It’s even possible to get students to focus their questions on each other, as well; peer learning is vital to the grad school experience, and was entirely appropriate for the online communities theme.
The goal of the course was to create product developers and project managers for “social networking” websites. Half (50%) of the surveyed class described their experience with technical concepts at the start of the class as “novice.” This was a pretty tall order: bring the class from novices to managers with a strong understanding of core concepts in 16 weeks. The course was a success, but as always, teaching is also a learning experience. Here I present a few takeaway lessons for instructors or professors considering similar courses or approaches.
1. Teach concepts as they are encountered, not how you learned them
I introduced concepts in a top-down fashion, because it’s how I was taught and how I best understand the material. By top-down I mean bringing in technologies and collaborative methodologies as they exist structurally: start with the client side, talk about HTML and web browsers, then move on to the server side, and talk about databases and client-side development.
The sequencing of materials will definitely be altered to better reflect how they are encountered during the design and development process, particularly how product design integrates with technical development. On the last day of class, Karen North, the director of APOC, handed me a syllabus for a similar course in online development. This course sequenced material in order of how it would be used to create a website. The course was basically one large problem-solving activity strongly connected to real-life, similar to a semester-long PBL exercise. Concepts were introduced based on how they are encountered in the development process. For instance, at the start of the development process, a server would need to be secured, which would also entail discussion of how servers work. This altered sequence would address requests throughout the semester for more examples and provide an ongoing, coherent narrative with real-life applications.
2. Splitting your brain is okay, to a point
The course material was split thematically into technologies (programming languages, client-server development, APIs) and collaborative/managerial methodologies (agile, recruiting talent, writing specifications). Students completed the same coursework, with the exception of the final project. The final project, which was among the highest-reviewed course components, was to create a presentation on either technical or managerial concepts. Most of surveyed participants found the technical portions of the course “beneficial” (averaging a 4.0 out of 5) while slightly fewer positively responded to the managerial portions of the course. While students generally found the two sections of the class to be overall beneficial to their learning, several offered suggestions on how course material was sequenced. These suggestions were mixed, and included a reversal of the order of material presented, de-emphasizing coding, and separating this single course into two courses.
I’m sticking to my guns here; I would like to preserve the ability for students to focus on either technical or managerial concepts in the final project, while encountering in all the class material through discussions, readings, and homework. While I think two separate courses would be appropriate, it’s unlikely that the program can support both. Throughout the semester I found students either naturally gravitated to either programming or managerial concepts. Students will naturally end up being professionals that accentuate either one or the other, depending on their personality and interests. By the end of the course, students should have a much better idea of the type of role they will play upon graduation. So it makes sense there is no “one size fits all” solution for students, and they will become more specialized.
3. Create managers who develop sites, not programmers who develop sites
Deciding how technical to get in an introductory skills course is a risky balancing act. Too much technical focus may lead to confusion, while too little technical information may not give students the core understandings they require. One of the decisions I made early on was to not turn the course into simply a raw programming course in, say, javascript. Students in a one-year MA program on online communities aren’t going to become software engineers over the span of one semester. Even if they did become wizzes in javascript, they wouldn’t receive enough tangible benefits to the larger picture: creating living, breathing, online communities.
So, from the start I was aware that the course could not create software engineers. Even aware as I was, I went a little too far; one place the class stumbled was in understanding object-oriented programming (OOP). This core concept could have been introduced more coherently, more slowly, or omitted entirely. I’m going to go out on a limb here and say meta-programming packages might be a more approachable alternative to “true” programming for novices. Drupal, for example, while esoteric in setup, allows students to get a social networking site up and running immediately. Being able to quickly create and modify a site in real-time offers both technical and attitudinal benefits.
Technically, students would encounter concepts such as PHP and database design within a safe framework. They would get the thrill of quickly creating and taking ownership of a database-driven website, which would be otherwise impossible for novices to accomplish in a single semester. The big downside to closer incorporation of a package like Drupal is that its inner workings (PHP, databases) would need to be appropriately described, otherwise its value as a teaching tool would be diminished. For instance, AJAX requires a solid understanding of javascript (client-end dev), client-server networking, and remote APIs (e.g. REST). Even if AJAX somehow went away in 2 years time or was replaced by Flash or Flex, the remaining concepts would still be valuable. If all students learn is how to use a particular type of CMS or templating system, which doesn’t exist in a few years, they may not have these valuable core concepts to fall back on.
4. Jettison components that aren’t accomplishing what you hoped, add new ones
Quizzes were the lowest-reviewed course component (which were: homework, readings, quizzes, in-class exercises, lectures, and final project). Ideally, viewed through Bloom’s taxonomy, quizzes help retention of low-level cognitive concepts, leading into higher-level understanding and application. But if students aren’t finding this part of the course beneficial, I may reduce it or cut it out entirely in future years. Quizzes are useful in undergrad courses as, frankly, a salient threat to do the reading and pay attention. For a grad-level course they may not be necessary, as grad students are more involved, driven and attentive. As long as students are involved with the course, low-level knowledge acquisition may better occur through small group activities or lab exercises.
Even though the course was paired with another course, which had industry speakers every week, the connection with industry needed to be stronger in this class in particular. I’m taking time over the summer to collect first-person reports from industry to roll in with next year’s course, particularly as concerns APIs (such as OpenSocial), monetizing contextualized data (directed marketing), and more freeform collaboration in the building process (e.g. Google-style project development).
5. Encourage direct and immediate classroom responses
This isn’t so much related to this course as teaching as a whole. As much as we talk about listening to our users, the same mantra applies to students. There is no substitute for an aware and receptive instructor. The semester is rather short, and the material is at times imposing and demanding of students, particularly novices. The overview skills course should be an agile u-boat that can turn at a moment’s notice, not an overgrown tanker that takes time to alter course. Noticing immediately where students are encountering difficulties is absolutely necessary to adapt the material to their needs. Additionally, paying close attention to them may offer perspectives that are more likely to reach fellow students than your own. In the case of this course, many students were well-versed in one or more topics, even if they didn’t have a grasp of all areas. For instance, one student had a deep knowledge of widgets, and was helpful in contributing practical examples of how her work life centered on interacting with developers to create widgets. It’s even possible to get students to focus their questions on each other, as well; peer learning is vital to the grad school experience, and was entirely appropriate for the online communities theme.
Labels: 4-year, apoc, MA, online communities, online networking social communitynext, social networking, teaching
