communicating engineers

Last weekend was the L.C. Smith College of Engineering and Computer Science open house. My WRT 407 students presented and demonstrated their year-long projects to visitors, guests, and an IEEE review team. Once again I came away from the event amazed by the creativity, talent, and genius of these pre-professional engineers. It is both a humbling and energizing event.

I spend much of the afternoon reviewing the project teams' documentation suites. While the format is not required, they typically take the shape of tabbed three-ringed binders. The suite consists of the following documents, which the teams have developed and revised over the course of the two semesters:

• Formal Project Proposal
• Individual Technical Descriptions
• Technical or Demo Presentation
• System Requirement Specification
• Test Plan/Test Scripts
• User or Implementation Guide
• Status Report
• Draft Research Paper/Article 

When I look at the range and quality (yes, quality) of the documents, I inevitably wind up questioning the outcomes of the course. I focus my instruction on genre and the communicative and rhetorical requirements of different types of documents in different contexts. Filtered down, that really mean that I'm teaching production. I don't really see that as a bad thing, but I do wonder how the production of technical engineering texts s in alignment with the course outcomes.

I have some improvements to make, particularly in regard to managing 40+ students in a class that meeting only once per week. Aligning activities and products to goals and outcomes will drive those improvements.

physical design

continuing with my previous post...

A number of years ago, Saul Carliner developed a three-part design model for technical communication that identifies physical, cognitive, affective activities performed while creating an information product. I've found the model useful when working with pre-professional engineers because it allows us (in the context of the technical writing class) to locate engineering design and development activities within a range of practices and activities defined as technical communication or information design. Most useful in these efforts is exposing the students to the physical design activities of the model.

Physical design occurs in the space between design and development; the preparation and creation of physical elements of an information product. In the context of an engineering project, physical design includes the core writing and editing activities performed by the engineer. The information that shapes physical design activities derives from the design documents created as a result of cognitive design activities. This type of product development (development based on pre-defined design criteria) allows the engineer to develop a product that meets specific needs and purposes.

The value of this model is that it allows the engineers to locate "meaning" within the design documents they create. To interpret the meaning between and among the structures of these documents, the engineers must understand these relationships in such a way as to present them for specific purposes (for example, the technical requirements of a product). In this regard, the engineers perform physical design activities to create the external forms through which users of their documents extract and construct meaning.

deconstructing ia

continuing with my earlier post...

Similar to Information Architecture (IA), Information Design (ID) carries multiple definitions and applications. In web contexts, ID ranges from developing maps and signage to simple web pages. As a practice, ID has been described as an interdisciplinary approach that combines skills in graphic design, writing and editing, illustration, and human factors. On a more ephemeral level, ID has been described as a position or stance one takes. Beth Mazur has likened this stance to a political or moral stance that we take the design or an information product to improve the quality of the communication. More specific to what I want pre-professional engineers to understand about IA; ID has been described as the act of designing and deploying content in such as a way to achieve the performance objectives for specific end users – objectives captured during IA analysis.

For the purpose of instruction in WRT 407, it has been useful to define ID as one aspect of design that occurs within the performance of IA analysis. Design activities performed within analysis are the point at which the engineer can focus on the context and purpose of the information products they are created during their engineering activities. If the product of IA is the blueprint or specification that guides development and deployment, ID is the act of shaping the specification. ID uses the results of IA analysis to inform the engineer's overall product design.

Within this framework of analysis and design activities, IA can be seen as any number of processes the engineer follows to understand available forms and structures; to design the physical aspects of the information product, and to develop the product to meet end-user requirements. The forms and structures available to the engineer are shaped and served by any number and type of discourses, styles, genres, and dialects. These are the standard designs – the genres and conventions that engineers are aware of and work with. Designing the physical aspects of the information product occurs when the engineer transforms one (or more) of the available standard designs into a new product that meets specific pre-defined requirements.

defining ia --- again

continuing with my previous post...

When I use the term information architecture  with writing students, it sounds impressive and maybe a little overwhelming. But then I get to the place where I have to define IA. That's when things get problematic.

I'm finding it best to situate IA as a verb. I ask the engineers to think about IA as the act they would perform to express the explicit details and concepts of the systems they are designing. One important aspect of that performance is creating an organization and structure for the information relating to and used by their system -- in particular, it is the act of architecting relationships among system components and elements.

After we have the activity of IA on the table, I move to the product of IA -- to the outcome of the performance. When defined as a noun, IA is the blueprint that contains the description of how information is organized and structured within the system. That blueprint is the  physical specification (technical and functional) that identifies a set of possible structures, patterns, and techniques to make information easier to access, understand, and used within the system.

Defining IA as both activity and product allows me to do two things in regard to situating IA within TC practices. First, the definition allows the engineers to see themselves as information architects who perform the activities required to create products that meet the needs of specific users. Second, the definition situates aspects of IA as a series of sub-activities performed at iterative points in and around the analysis and development phases of the engineers' design methodologies. Situating IA this way allows me expose for the engineers the relationship between analysis and design. The product of the design illustrates the engineer's ability to effectively address requirements identified during analysis.

How's that for a closed loop?

ia is about structure

continuing with my previous post...

We've come to understand Information Architecture (IA) as the practice of structuring information (often according to context) for a particular purpose. Tom Johnson and Donna Marsh circled around this definition last week. From their discussion, it seems that defining IA is problematic because it is most commonly applied to web development. However, from Donna and Tom's experiences (and those of others) it's quite obvious that IA also applies to disciplines such as TC, software programming, and user experience design (Peter Morville has said as much about a decade ago).

To complicate things a bit more, an alternate popular definition of IA exists within the field of information system design, where IA refers to the analysis and design of blocks or chunks of information (and their inter-dependencies) within a system. Beth Mazur has used this definition in her efforts to draw distinctions between IA and information design.

The practitioner perspectives that Tom and Donna provide and the academic definitions that Morrville and Mazur provide are built on features of information interaction, content analysis, classification, information hierarchies, information navigation, and information structuring for particular purposes. It seems to me that if I can invoke TC practices that include these features, I can illustrate to my students a range of practices that will help them understand the complexity of their design activities. For this purpose, I need to begin by locating design activities, as an aspect of IA, within TC practices and embedded engineering writing instruction.

tech comm, design, and information architecture

In the next series of posts, I want to try to revisit the relationship of design to technical communication practices. I explored the topic in a graduate seminar last year, but I'm bumping up against it again as WRT 407 comes to a close and the engineers begin to see the product of their design, development, and writing activities.

I want to begin with the question that I was asked during that seminar: "Why is it important for technical communicators (or anyone performing the role of technical commicator, such as an engineer) to understand that they are doing design?” The question is an important one because it demands that we reconsider traditional treatments of the disciplines and fields that serve (and are served by) Technical Communication (TC).

For a long time, I have viewed TC as a co-opted discipline; taking pieces and parts from any number of closely and remotely related fields, practices, and disciplines. My perspective placed TC in the middle of the design/development universe. Yet when asked to qualify the importance of viewing the technical communicator’s activity as something other than “technical communication,” my heliocentric perspective broke down.

Such a break down is possible because all perspectives of TC across the scholarship and literature are based on uneasy and inconsistent definitions of the discipline and the practice. These definitions always include (arguably, must include) descriptions of design, development, and production activities that are performed by technical communicators. This move to include any and all activities associated with creating an information product is what complicates an answer to a simple question about disciplinary perspective. Blame it on the reflexive nature of Composition as the mother discipline. Blame it on technology-mediated practices. Whatever the cause, technical communicators are unable to foreground their discipline within a clearly demarcated practice of design/development activities. TC is not at the center of the design/development universe; it has gradually become the generic glue that connects hundreds of fields, practices, and disciplines.

This is the position from which I will further consider the relationship of Information Architecture to TC over the next few posts.

questions of quality

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.

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.

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."

dual design

Giving a presentation last week - faculty asks, "Mike, when you say design, what do you mean?" Good question.

When discussing online course design, I'm tend to confuse instructional design with information design (and to complicate it even more -- information architecture). Lately, I've been trying to talk about design in two ways.

First, I address the basic concepts of instructional design. This is important because we want faculty thinking about their instructional strategies early on in the course design process. How are we going to instruct? What are the engagement opportunities? How are we going to assess?

Second, I address issues of organization and emphasize the concept of heuristic for the course space. How are we going to sequence the instructional blocks? What metaphor are we going to use to organize the content? What structures are imposed by the LMS?

I have to make an effort to keep these two aspects of course design separate and clear. I think faculty will be better able to work through our design/development model if we clearly differentiate between the types of design activities.