We're currently working with one of the colleges to navigate a proposal they received from an online course/program vendor. These hack shops are popping up like mushrooms and making a lot of noise about tremendous enrollment targets and extraordinary returns (read: tuition revenues).
There are a lot of problems with these organizations and the promises they serve up. I may, in fact, spend some time dissecting the issues in terms of problem resolution. What's bothering me right now, however, is the lack of coherent dialog on campus around the issues of online education.
I spent some time today with the principals who will ultimately make the decision to outsourcing their graduate programs to a third-party vendor. I tried to explain the roll that quality plays at all levels of an online program. I don't think they heard it. Like a typical buyer, they're more concerned with costs and returns -- and enamored by the idea that they could pull out of their agreement two-years in if things aren't working out (read: they're not enrolling huge numbers and making millions of dollars). I wanted them to understand how even that act -- of bailing on a program that has already graduated and currently supports students -- could compromise quality.
Again, I don't think they heard it.
It's an ongoing dialog, and I should be happy that the conversation is even happening. I just worry about the outcomes should our message and services get blurred by unrealistic revenue targets.
Friday, February 4, 2011
Thursday, February 3, 2011
the uneasy art of persuasion
We spent some today in 407 talking about the role of the "the proposal" in engineering environments. I always try to impress on students the importance of thinking about project proposals as persuasive documents -- documents that must move a reader to a particular action, position, or opinion.
That's what we do in the classroom.
In practice, I know with a high degree of certainty that many of theses engineers will never write a single proposal. At best, they may serve as a subject-matter-expert or contributor. Yes, I know it's invaluable for them to understand the genre, the contexts, and how it all works together. But I still struggle with their time -- wanting to exploit the limited time we have them here.
The proposals they work on in 407 are specific to their Senior Design projects. That means they have some skin in the game, which is useful. Overall, it's a good exercise in that it helps them refine their thinking about the complexities and possibilities of their projects. In that regard, I should appreciate the activity. I just need to find some way to extend it -- to make it more meaningful beyond performance of an academic activity that they will likely never repeat.
That's what we do in the classroom.
In practice, I know with a high degree of certainty that many of theses engineers will never write a single proposal. At best, they may serve as a subject-matter-expert or contributor. Yes, I know it's invaluable for them to understand the genre, the contexts, and how it all works together. But I still struggle with their time -- wanting to exploit the limited time we have them here.
The proposals they work on in 407 are specific to their Senior Design projects. That means they have some skin in the game, which is useful. Overall, it's a good exercise in that it helps them refine their thinking about the complexities and possibilities of their projects. In that regard, I should appreciate the activity. I just need to find some way to extend it -- to make it more meaningful beyond performance of an academic activity that they will likely never repeat.
Labels:
Technical Communication
Wednesday, February 2, 2011
tech makes us dumb
The other day my mother-in-law was talking about how kids are smarter today -- that they seem so plugged in and aware. I commented that I don't think kids are necessarily smarter than earlier generations, but I do think they are clearly more comfortable with communication, instructional, and entertainment technologies.
A couple of days later I read a short article on the definition of modern literacy by Susan Metros. She claims that the skills necessary to successfully using technology (analyzing, visualizing, communicating, and innovating) will require everyone to be technologically literate (on a continuum that moves from stimulated to novice, novice to literate, and literate to fluent). This does not, however, equate to literate in the traditional sense. As Metros notes, "They know how to upload a movie to YouTube...they know how to text, and they are constantly connected to something digital. But my argument is they are not literate; they are just basically stimulated."
I find in these distinctions of literacy the same tension that exists in the technical writing classroom. How technically literate does a technical writer have to be? It's really more than the decades old debate about do we teach tools or do we teach writing. It has more to do with the technical writer's ability to comprehend complex topics and concepts, and to produce usable and original information products with an array of tools, technologies, and skills. In co-opting Metros' argument, the modern technical writer's "literacy" must be less about the tools and technologies and more about "ways of thinking and seeing, and of crafting narrative."
A couple of days later I read a short article on the definition of modern literacy by Susan Metros. She claims that the skills necessary to successfully using technology (analyzing, visualizing, communicating, and innovating) will require everyone to be technologically literate (on a continuum that moves from stimulated to novice, novice to literate, and literate to fluent). This does not, however, equate to literate in the traditional sense. As Metros notes, "They know how to upload a movie to YouTube...they know how to text, and they are constantly connected to something digital. But my argument is they are not literate; they are just basically stimulated."
I find in these distinctions of literacy the same tension that exists in the technical writing classroom. How technically literate does a technical writer have to be? It's really more than the decades old debate about do we teach tools or do we teach writing. It has more to do with the technical writer's ability to comprehend complex topics and concepts, and to produce usable and original information products with an array of tools, technologies, and skills. In co-opting Metros' argument, the modern technical writer's "literacy" must be less about the tools and technologies and more about "ways of thinking and seeing, and of crafting narrative."
Labels:
Teaching Writing,
Technical Communication,
technology,
writing
Subscribe to:
Posts (Atom)