learning components

While reading for a course we're building to prepare instructors to teach online, I came across a reference to a four-component instructional design system. While there might be a tad too much theory infused in the system, the component approach to design is intriguing.

I'm particularly interested in the Learning Task and the Supportive Information components. At first blush, it seems that both components would require the instructional designer to have a good understanding of the compositional requirements for writing useful and effective task-oriented information and supportive information. Essentially, it's the procedural/declarative discussion that Tech Com has been involved in for quite some time. The most popular (relevant?) research to consider procedural/declarative information has looked at software user manuals and instructional texts. In some ways, I see this research as a top-level look at the form and purpose of procedural and declarative information.

A second-level look would have us consider the compositional requirements of the procedural information (learning tasks) and declarative information (supportive information). I'm not quite sure what these requirements would expose. I do think that instructional designers would be well served by better understanding how procedural information relates to declarative information. Rather than approaching these information types as discrete chunks of information, the designer could imagine, through a writer's lens, the many interactions and reader/user support processes that reside between the two information types.

projection management

Another four hours in a strategic planning session for enrollment management at UC. Yes, the consultant is being paid. The exercises today: moderately engaging. What I'm seeing, however, is that regardless of the goals/activities we propose, our hands are tied by the university's policies/politics relating to tuition and program development. Back out to 30,000 feet and you see there's almost nothing we can do beyond what we're already doing. Simply put, we need to increase part-time student enrollment in programs that will take part-time students. They schools and colleges who "own" the programs wont pay to offset the cost of marketing and recruiting, but we need to do it anyway.

It's an awkward space. It's entirely likely I'm not seeing everything. I hope I'm not.

cardinal rule

No, not this Cardinal. They cost me my two top five brackets. Well, them and Pitt. I'm happy to see two Big East teams in the FF. I do like MSU. Have always enjoyed Izzo's style. And there's something about their colors and perpetual underdog status.

So back to the Cardinal: This guy is friggin' unconscious. Is he the greatest athlete of our time? How does he do it time and again? The Cardinal thing? He's a Stanford grad, of course.

That's all cool, but it's not what inspired me today. This weekend I glimpsed two cardinals, as well as a backyard full of robins. Not fat momma robins -- not yet. It is Spring though, and they're all back. The air smells green. The snow is gone (crossing fingers). April showers will bring mud season. Opening day for trout is two short days away.

Yes, even with my brackets in a smoking heap, it is still the most wonderful time of the year.

brevity

Many of us have understood this for a very long time. One time at band camp... during a tech writing gig at a software company, I became the owner/editor of a 2,500+ page user guide. The problem with the guide was not the word count. It was a mix-mosh guide of feature-centered writing and task-centered writing. It rambled like a silly blog posting, moving the reader (if she cared to follow) along an unorganized path of inconsistency and failed heuristics.

When the revision was done, we had three information products: one user guide, one tech/fact sheet, and one compiled help file. All three brief, concise, and stylistic (if I don't say so myself).

The point: Brevity does not necessarily mean discarding information simply to reduce word counts. Nor does brevity mean a picture contains a thousand words. Brevity, for the technical communicator, means the most efficient and effective way to transfer knowledge or skills to user of the information product. If brevity improves retention and learning, that's icing on the cake.

duck you

I've been called many things in my career, but this is by far the funniest. I think I'll be picking up two dozen rubber duckies for the CE and EE students in my WRT 407 class. I think they'll get a kick out of it.

if it smells like...

This is hilarious. I have to admit, I was wincing with pain as I read the post. The comments validated the feeling of a pin stuck in my neck and revealed the hidden humor.

I have to stop taking this stuff so seriously.

music to my ears

Here’s one reason why I love my job…

I got a call from a professor of music education at the College of Visual and Performing Arts (VPA). Seems she got my name from a person with the Kauffman Enitiative project (a project UC supports with web site design and content management). The VPA professor is writing a grant to design and develop an online music education course.

After meeting with the professor, I’ve agreed to assist with the grant in any way that I can. Specifically, I think I can help with costing out the course design and development activities. That’s fun, but it’s not why I’m excited. What’s really got me geeked up is the possibility that the grant will get accepted. I’m already imagining the possibilities of teaching a tactile skill, such as instrumentation, in an online environment. I’m seeing three different levels of courses, each engaging the instructor and learner with varying modes of interactivity. It’s also a fantastic opportunity to exploit a virtual space (such as SecondLife) for something other than pedantic navel gazing, porn, or gaming.

This is an extremely exciting project – a chance to work through challenging design requirements with some wonderfully bright and progressive people.

stupidly google

I've lamented before about Carr's ability to garner headlines simply by making stupid claims wrapped in academic rhetorical structures. He sounds convincing, but he's not doing anything that Howard Stern, Rush Limbaugh, and Jim Rome don't already do.

So I'm not going to review, attack, or dismiss the recently renewed interest in an old Carr article in which he pisses and moans about how old he's getting and wondering if, Is Google Making Us Stupid?

OK, maybe just a little attacking. Short answer: No Nicholas. Dumbass headline grabbers like you are making us stupid -- stupid for wasting time writing about your dumbassness.

What I do want to note is an absolutely wonderful quote I found in a refutation of Carr's idiot claim. In his well-crafted (and seemingly Composition-loving) rebuttal, Trent Batson states:

"It is easy to criticize a new technology; it is much harder to understand how the new technology can help create new abilities in humans. And even much harder to understand how technology can actually recapture and re-enable human abilities."

The challenge that Batson notes is what gets technologists geeked up. It is the essence of human achievement. There is a comfort that comes with most technologies. It's a comfort that hinders exploitation and extension. It is a comfort that allows the likes of Carr (and a number of unnamed tech-dismissive university executives) to bemoan how technology is chaning the way we do things -- as if change of any sort is bad.

Carr will have ample opportunity to bitch and cry as long as there is technological advancement for the rest of us to get excited about. It's a fair enough trade.

jimmy the who?

25-7 after round one. Not a particularly neck-breaking start, but a good one nonetheless. I loved Wisconsin and Cleveland State. West Virginia hurt everyone. I didn't have them surviving Sunday.

So much fun.

duplicity

A while back I was a member of the Senate Curriculum committee. Interesting dynamic, as I was the only non-faculty member sitting around a table of extremely self-important blow-hards.

Today I was reminded of one particularly entertaining proposal review. Mechanical engineering had submitted a proposal to drop WRT 307 (the professional writing course) as a required course from their curriculum. When a professor from the program showed up to defend the proposal, I asked if they planned to replace the course with another perhaps more discipline-specific writing course. He looked at me rather miffed and muttered, "We DO know how to write." He then turned his attention to his peers and continued on with his inane defense.

Of course I was not implying that mechanical engineers do not know how to write. They do. We all do. Which is exactly why WRT 307 or a more discipline-specific course must be part of the mechanical engineering curriculum.

What got me thinking about that episode in the curriculum committee was something I stumbled across in an IST brochure about summer courses. Tucked away on the last page in a small box labeled "Online Courses" was IST 600, 900 Technical Documentation.

Interesting you say? Why yes, it is interesting. Let me explain.

You see, under RCM (the university's vastly under-appreciated accounting and budgeting methodology) schools and colleges are expected to locate and use existing courses to meet curriculum requirements -- regardless of where the existing courses reside. This, of course, never happens. It's all about the money you know (and it is ALL ABOUT THE MONEY). Schools and colleges create duplicate versions of existing courses so they can keep 100% of the revenue. The math is quite simple.

So where is the process broken? Well, when course proposals pass through the Senate Curriculum Committee, the committee takes the submitting program at its word that due diligence was performed to locate an existing or similar course that could meet curricular requirements. The committee itself does not check the catalog. However, in cases of obvious duplication (such as a writing course), the submitting program will include some smack about how the unique nature of their curriculum requires a "different" course.

And so it must have been with IST 600, 900 Technical Documentation. There are at least five 600-level technical writing/communication WRT courses on the books. I know this because I worked on the framework designs of four of them. And so I can say with the utmost certainty that any one of the existing 600-level WRT courses would meet any curricular requirement IST places in front of their 600, 900 course.

Bigger issue: Did IST research the catalog to locate the WRT courses? Not a chance. Did anyone on the curriculum committee ask if the Writing Program was consulted? Not likely.

More to come on this. Much more to come.

braggarts beware

Smack talkin' fool? Yes, I am. I tied for the top spot in the conference brackets pool. We picked the Big East, ACC, SEC, Big 10, Pac 10, and Big 12. Split the winnings in half with my old friend the Eggman. My smack? Well, Eggs didn't pick a single conference champ. I, on the other hand, had two: Lousville and Missouri. Says something about luck, doesn't it. Yes, luck, skill, and cold hard CAAAASSSHHHHH!

It is the most wonderful time of the year.

we are siamese

Remember the SIAM model? It's still relatively popular among white paper writers (read: those lame attempts at product positioning papers that litter the floors of hotel rooms after trade shows). BTW, what ever happened to the white paper as a legitimate genre? We still teach it in professional communications courses, but industry has bastardized it to a point of inconsequential presence within the range of professional and business communication genres. Toll the bell for the white paper.

Back to the SIAM model. The systems criteria of serviceability, interoperability, accessability and manageability are as relevant today as they were with the first three-tiered client server systems. In fact, you could argue that the criteria have been applied, in varying degrees of maturity and necessity, to all modern technologies. That claim aside, I've found the model useful as a baseline set of criteria for an evaluative tool we're developing to identify and rate duplicate technologies and services on campus.

The first pass of the tool was cumbersome and dense, mostly due to my inability to explain the basic principle and use of the tool to our small group of extremely smart technologists. I think with some additional tweaking and the appropriate amount of contextualization, we're going to find that good ol' SIAM is a solid place to start our evaluation and an excellent foundation from which we can depart for a more refined analysis.

(re)focusing

For reasons completely (and maybe only slightly disappointing), I've recommitted to my commitment to complete my qualifying exams this year. I do have a large project coming up that requires my absolute attention, but other than that it is immersion all over again. It's needed. It's time. Bandying around other options proved to be both a waste of time and fruitless. I do think that the exercise was beneficial in that it allowed me to reassess where I've come from, what I know, what I do, and how well I do it. Yeah, that's a load of assessing. But sometimes it takes a gut check to keep you honest with that jump-shot. No leaning. No cheating. No short-cuts. You either shoot with good form or you doink it.

criteria

Struggling with a rubric for evaluating duplicate technologies and services on campus. Relative scoring is just that -- relative to the context, environment, policies, etc. At one level it seems like a simple effort to document an argument for or against consolidation or centralization. At another level it looks like a quantitative measurement required to make an informed and meaningful decision. More tweaking is needed, but the basic framework of the rubric looks usable.