DigitalPenny

I'll be with you in a minute.

Posted by Digitalpenny at 04:09 PM | Permalink | Comments (0)

Bernhardt, Stephen A. (1986). "Seeing the text". College Composition and Communication, 37, 1, 66-86.

In this essay, Bernhardt does a wonderful job connecting his stance on rhetorical control in how we perceive the text, at first, visually for meaning because of the manner in which the text is partitioned and shaped, to how we read the text for meaning by reading sequentially from one word to the next. Bernhardt uses five principles of gestalt theory and an example excerpt about protecting wetlands to define what he terms rhetorical control.

As I read Bernhardt's essay, the question that stood out for me aside from how is this text relative to visual rhetoric? was why write? Bernhardt made a compelling argument for my latter question. We write because we have an idea to communicate to an audience. That audience will more than likely be a "diverse" one. Not only that, but different readers will see a text from different points of view. And in order for a particular text to stand out from all others, it must be visually appealing first, by capturing the attention of the "primary" audience. If the text does not have a certain look and feel as determined by its author(s), then the intended audience along with other spectators will skim or glance it; in doing so, they might miss some extremely important details because the text has not been written or designed to be visually appealing.

...if the reader is sufficiently engaged with the text to flip the sheet over and look at the reverse, then the visual appeal has alread proven effective.

Bernhardt sees student essays as becoming more visually appealing. He believes that writing instructors need to "begin to develop a descriptive base for visual design" and that the vocabulary and practical applications of teaching visual design in writing courses is being overlooked (granted this article was published in 1986, I'm wondering if in 2005, does what he says still apply).

There's probably more to unpack here, but this is a beginning for me.
Wackywords: visual apprehension, graphic patterning, visual patterning, visible cues, rhetorical organization, graphetic, graphological, rhetorical control, predictable functions, gestalt: equilibrium or pragnanz; good continuation; closure; similarity, low contrast, localization, heightening of the boundaries, replicate, visual syntax

Posted by Digitalpenny at 12:03 PM | Permalink | Comments (2)

How do writers, who design courses or **Performance Technologists,** who help to write course assessments, determine a learner's ability to gain knowledge or to perform a specific task correctly? Of course, I don't have the answer, but I can give you some cues clues.

I still can't explain assessment, but where I used to work, they had ways of determining how well a learner would perform on the job based on test scores (I still believe this theory of evaluation is ridiculous). (aside: what do tests really tell us?) Anyhow, I always thought our method for writing assessments was a bit slippery. See, someone had taken time to design a method for calculating test scores against content and exercises, using a MS Excel spreadsheet, but we (the writers) never used the spreadsheet as it was intended. I always tried to follow the rules, which had been established for using the spreadsheet, but many of the people I worked with had found ways of bypassing certain items or fields on the spreadsheet. A co-worker once said to me that nobody used the information, so there was no need to complete the entries anyway. I thought, well why design the spreadsheet with those particular fields?

(...)

I was looking through an old stack of papers and came across some research I had done some time ago concerning how to write Performance Assessments for online (WEB and CBT) and instructor-led courses. See when I was given the task of writing courses, I was able to attended only one course, which was supposed to teach me how to develop and design courses. After sitting in class for a few hours, I found that the course's content was constructed with **designing the look and feel of the course**. It was not structured to teach writers how to write content and excrcises for the learner; let alone design an assessment for it. So, I had to do some research to first find out what the hell an assessment was, and second to find out how to write it into a course that I was creating from scratch with very little help or no help from seasoned course developers.

(...)

Of course, the URL on the paper I had found was listed as UofM...clara (whatever). So when I entered the URL into my browser, the link and the associated web pages had been updated.

So, if you are interested in writing assessments and defining ways of rating performance, (here's my clue) examine UofM's web site called, Virtual Assessment Center. It answers all kinds of cool questions like: Why assess? and What am I assessing? Check them out! You might like what you find.

Posted by Digitalpenny at 12:05 AM | Permalink | Comments (0)

In my July 21 post, Being Technical I wrote, "Universities and community colleges should look at creating spaces where Technical Writers can learn to diversify their portfolios; these spaces should include building relationships with businesses so that books used to teach—business communication, technical writing, technical communication, professional writing (or whatever they are termed)—are written with a true transition from academic to business writing in mind."

Since making that statement, which I feel is true, I've given it some thought. There are so many different businesses, and they all produce a vast array of documents. Documents for the general public, documents for internal use, documents that they pass on to their clients, and documents for shareholders. Any one book designed to cover that much *how to, what for* information could be tragic. Right? Yea, right. That's because the writing for each company is differnt, and their audiences are different. This leads me to think that books that are written for technical writers might be written so that they are site-specific.

Now, real technical writers, and the people they work with throw this term—site-specific—around all the time, but what would it mean when applied to writing a set of textbooks instead of defining a set of IP addresses or something specific just for XCompany? I think it would mean designing several thousand books (okay that number might be a little high) that specifically target a specific audience of people interested in technical writing for a specific type of company. This might seem a little far fetched, but stay with me.

A long time ago, I interned for IBM. (I'm not picking on IBM because I love the time I spent there. I'm just using it as an example.) On my first day, no, during my first week, I was given a hodgepodge of documents to read about what it was I was supposed to do while there. It's been so long, I can't really remember the document titles, but none aside from a dictionary, thesaurus, and grammar handbook were familiar to me. I was given about nine or so documents to read—this didn't include books that were on the shelf that I could use for reference. Aside from the dictionary, thesaurus, and grammar handbook, only one of the books was truly helpful. There was also an internal document, a cookbook of sorts that some folks on the team had written; it was indeed helpful, but suffered from lack of concept/context-building. But there was little that I had been taught in school that had prepared me for that summer.

I guess what I'm getting at is the fact that there is a set of unwritten and unspoken dynamic information that Technical Writers should be aware of before indulging office work. What's more important here is that the information I speak of is site-specific. No one workplace functions like another, especially in terms of document design and layout and audience, and what is expected of the Technical Writer. The **generic and generalized** books have been written. It's time that we begin to write site-specific texts for the trade. College and university students need some way of becoming aware of site-specific documents and how to write for them before they move into their profession. Is this not possible?

Sure, they say that the Technical Writer wears many hats, but how can we make it so that they know what to do when they put the hat on? What texts are out there that truly prepares the writer to sustain, generate new, and re-engineer what s/he seeks to define for a specific audience? What texts are out there that truly bridge the gap between workplace and academic writing? I can assure you that the texts writen to prepare the student for the workplace and the texts (if written at all) that they read or the knowledge gained once in the workplace are two different sets of documents.

Composition-rhetoric and communication writers who are interested in technology and technical writing might think about this as they theorize next steps for the field.

Posted by Digitalpenny at 08:55 AM | Permalink | Comments (0)

What does the technical mean when people use the term Technical Writer?
Well, that term suggests a few meanings for me.

• It means being able to toggle languages.
  
• It means being serious about being educated as a Technical Writer and being serious about continuing your education while working in the field.
  
• It means being savvy enough to notice and to accomodate changes in the local and global markets.
  

Learning a second language (L2) may not be necessary when you pursue a career in technical writing; however, knowledge of a second language, as in learning a foreign language, makes you more marketable. The language that I speak of here is the language that you intend to situate yourself within, that you intend to write-in, that you intend to use to communicate with subject matter experts (SMEs). It is the same language that the SME speaks or writes; you especially understand it when the SME refers to an object, the title of a book, or an equipment part as an acronym—the acronymic translation in your brain is almost immediate in most cases. In academe, I've often heard that when you are able to move immediately into another language within a discourse community that is not your native language, you are "code switching." I'm referring to it as toggling because when you write, design, create, and maintain documentation for a technical community or speak to SMEs, although you are code switching between technical jargon and its intended laymen translation, you (the writer) act as the pivot, which makes the resulting communication functional for the intended user of the text. So, the ability to toggle languages is imperative.

The Technical Writer is in high demand in both academe and in the corporate world. This means, in either case, that the Technical Writer must equip themselves with the knowledge and know-how of toggling different languages and using various tools to develop and deliver products and services. Technical Writers must continue to educate themselves not just by reading journals and books relative to technical writing, but to extend their knowledge-base by reading journals and books that are concerned with what makes a widget work, why it functions, and who will use it. They must learn to communicate with all types of engineers, information specialists, programmers, accountants, web designers, and many more field experts, depending on the preferred industry or organization; this is partly education and partly negotiation skill building. Writers who find a job and conform to and become satisfied with an unchanging and non-challenging skill set often get left behind by new software developments or technological changes. Universities and community colleges should look at creating spaces where Technical Writers can learn to diversify their portfolios; these spaces should include building relationships with businesses so that books used to teach—business communication, technical writing, technical communication, professional writing (or whatever they are termed)—are written with a true transition from academic to business writing in mind.

Lastly, the Technical Writer has to be savvy enough to notice and to accomodate changes associated with the local and global markets. This savviness includes continued education, negotiation skills, and language toggling. First it was the dot-com tragedy, now it's off-shoring and out-sourcing. India and China are vastly becoming sites of "do it all for less" while Americans are being laid-off. Not only is our technology being moved to those two countries, our writing is too. Personally, I don't know what's in store for the Technical Writer as a result of this, but I feel that if we don't take advantage of this moment, as writers, we will lose momentum and become defunct in a profession that's truly just being recognized as a typified field of study.

Posted by Digitalpenny at 12:11 PM | Permalink | Comments (2)

In Sisters of the Academy, which is a wonderful and inspiring read, Dr. Lesa Maria Covington Clarkson writes about being a single mom, rearing three children, and pursuing a Ph.D. Her story is extremely inspiring; it's about having patience, balancing work and family, and saying, "No" when necessary.

Although I'm not a single mom, I have three children. I found Lesa's story to be funny and familiar, especially when she talked about being on an elevator descending to take the subway. As she descended on the elevator, moving underground, she thought, "While I [had been] 'underground' for the past thrity-six months, 'life' had continued for everyone else. Did anyone miss me?" As I work on my Ph.D., I often think this way. Life for everyone else seems to be in constant motion; and while my life seems to be full of motion, it feels that I'm distant from the real world. What's important though, and Lesa would agree, is my immediate family and their support.

Working on the Ph.D. has been an adequate challenge for me this past year, and I'm sure completing it will be bitter sweet.

Dr. Clarkson asserts,

Completing a Ph.D. is somewhat analogous to playing solitaire on the computer. I played to win. I didn't win all of the time but I didn't give up either. I played to win. When I didn't win, I played to prove that I could win. When I won, I continued to play to prove that it wasn't a mistake.

So, I'll keep playing to prove my being here and pursuing this degree "wasn't a mistake." In the end, I'll win and so will my family.

Posted by Digitalpenny at 08:57 AM | Permalink | Comments (1)

I really don't know how this will this will post, but I'm hoping the size of this image is okay.

It's a photo that I've taken of my family's caricature from a Florida vacation. Glen was the the artist who distorted us. My hair was in a ponytail; so as drawn, it looks kinda awkward. AND M-sr does not look like himself to me. He resembles a few of his uncles. This is a great memory for my kids; they often look at this caricature and laugh.

Posted by Digitalpenny at 12:39 PM | Permalink | Comments (1)

When you have to interview or work with subject matter experts (SMEs), it's always a good idea to do the following:

1. Write about or draw the concept you are attempting to understand before you meet with them, and send it to your SMEs at least a week in advance of your meeting.
   
2. Take along any reworked documentation and any source documents that may be necessary to reference.
   
3. Find out what SMEs like to eat and/or drink and take that as a peace offering to the meeting. If you can't get that information, take refreshments anyway. SMEs are always in need of a good snack.
   
4. Ask honest questions about the product or concept, if you really don't understand something.
   
5. If you are not sure about how something works, have your SME(s) take you to their test lab and demonstrate and talk through what they are attempting to describe. You may also ask them to let you use the system to reiterate what they've just said; if you get the chance to do this one, you must be confident about using the system. Chances are, you'll **break** something that they need to fix. I say this because often when they demonstrate, SMEs are so familiar with the system that they tend to skip right over steps that the system's end-user needs to know. So, never be afraid to **break** the product.
   
6. If there is no security risk, have the SME provide you with your own login and password to the equipment for the product, which you are writing about.
   
7. Set some time aside and talk with developers or lab technicians about scheduling your own user-time to work on procedures you have developed for the customer in their lab.
   

Posted by Digitalpenny at 07:00 AM | Permalink | Comments (0)

We all use job aids to perform some task either on the job or while at home. A grocery list is a job aid for those of us who often need to remember what it is that we need when grocery shopping.

After reading the introduction to Clay Spinuzzi's book, Tracing Genres Through Organizations: A Sociocultural Approach to Information Design, I immediately thought, how do designers really go about designing job aids so that they aren't cumbersome and so that they are usable by people who generally work on a product or on a particular task. Bad product design can often lead workers to (re)write and list short-cuts as bandaid work arounds to help them better perform their job when the problem or issue continues to present itself.

This lead me to think about a book I once read called A Handbook of Job Aids by Allison Rossett and Jeannette Gautier-Downes, which is a great book by the way. In this book, Rosett and Gautier-Downes begin with their definition of job aids, which is "a repository for information, processes, or perspectives, that is external to the individual and that supports work and activity by directing, guiding, and enlightening performance." They go on to break out parts of this definiton in order for their readers to fully understand what they are attempting to define. What stood out for me about this definiton of the job aid is the fact that job aids deal with typified recurring situated social activities (C. Miller, 1984) that are associated with tasks and sometimes problems that can be reproduced. Job aids are a genre.

So, Spinuzzi brings to light several good questions: What problems result when designers go into the field, gather information, and attempt to formulate a job aid or guide for all to use? What goes unsaid or what is missing when the worker creates his/her own quick reference when working within a system? What gets lost when the designer attempts to design a universal job aid? What happens when site-specific problems are located in the design of a product?

Now, I'm thinking about design patterns, which are often related to how software programmers think about (re)designing systems after studying recurring patterns. If workers are locating and simply jotting down fixes to recurring problems within the system, and then jotting down the same fixes within the documents they are using to perfom their jobs, then how are these fixes (that have become job aids) being rectified and reused to develop and design better documentation and training. Although I haven't completed reading Spinuzzi's book, I'm hoping that as I read, that this is one of the issues he discusses.

Posted by Digitalpenny at 10:10 AM | Permalink | Comments (0)

So, what are design documents? What purpose do they serve? Who uses them and why?

The purpose of the design document is to provide its audience with a description of a particular document or set of documents that would eventually accompany a product; it often includes a working document title, author or contact, the change history, the scope of the to be developed (TBD) document, appropriate audience, any associated constraints for development, a boilerplate of what might be included in the table of contents (TOC), a brief description of each chapter, and a list of and developmental milestones. In other words, this particular design document is specification work, which dictates how a document for a product will come to exist.

The technical writer(TW)/information developer (ID) in the industry where I used to work, would often generate a design document or a set of design documents that described relative input necessary to create a document or set of documents associated with a particular product. For example, if the product was a computing system, then there existed a design document or a set of design documents for that computing system. Texts created for a computing system might consist of the following set of docs:

• Administrator's Guide
  
• Operations and Maintenance Guide
  
• Hardware Guide
  
• Software Installation Guide
  
• Reference
  

Now, in order to produce the design document, the writer would need to investigate the product area. This would include interviewing subject matter experts (SMEs)—systems engineers, systems architects, software developers, product managers, project managers, lab testers, and lab technicians—and reading source materials (documents that were usually written about how the system should work, theoretically). SMEs are normally the targeted audience, but this document can also be used as a marketing tool for selling the product to customers/clients.

If the product were pre-existing, the techwriter would often read historical documents that had been approved and published in order to help generate a design document. If the product were new, the techwriter often needed to do more work upfront in order to generate a design document. Of course there were course design documents too. These design documents were laid out like design documents for **guides** (as mentioned above), but they also defined course objectives as well as the method of delivery, course schedule, classroom setup, evaluation tools, and more.

What always perplexed me about developing design documents for courses was the fact that we (course designers, as we were called) never knew exactly how the course would be delivered to the customer and where. This always led to site-specific questions concerning course development, which would often lead to an inadequately developed design document.

Just to think about this document and what it involves, makes me want to unpack all that I've said here. But I'll hold all of that for a different post.

Posted by Digitalpenny at 07:00 AM | Permalink | Comments (0)

I believe that academom and Derek have made some extremely interesting comments about the talk last night given by Yvonne Divita.

Yes, I agree that the presentation was a sales pitch. I agree that the three of us sitting there knew more about blogging than some of the folks in the room. AND I agree that the food was a bit unpleasant, in fact; so much that I couldn't finish mine. But a few things about this presentation stood out for me as well.

Like Derek says, comp-rhet folk should join this wagon and ride it out. We should embrace this rhetoric of communication. For small and large businesses alike, I agree with Madeline. BUT if blogs begin to become a dominate means of (re)packaging products, responding to customer complaints, and (re)working business models so that they begin to impact the bottom-line (for the local and global economy), then maybe it's worth the effort for companies to move in this direction. Most, businesses are after all driven by technology and driven by those decisions that rely on technological impacts.

I also think **and I'm no expert here** that there could be some crucial and sensitive ethical issues that might result when businesses begin to use blogs as a means of communication with customers, clients, or vendors. In fact because most small businesses rely on **word of mouth** to stay operable and profitable, and because the internet and blogs are a place where information is sustained and archived, a few irate customers can ruin the image of a reputable business, that is, if that business is not large enough to undergo such attacks.

More and more, blogs are becoming a **word of mouth** source for people who are threaded into them. But business ideas that have historically been thought to be imperfect, impractical, and not profitable have often been the ideas to make entrepreneurs quite wealthy or well paid.

Posted by Digitalpenny at 04:13 PM | Permalink | Comments (0)

So, I've been playing around with my blog a little, trying something different. It's in need of a bit more work, but all in due time.

Posted by Digitalpenny at 08:44 AM | Permalink | Comments (3)

Have you ever received advice from someone who has no children about how you should control, work with, attend to, talk to, behave around...your children?

Have you wanted to tell that person or those persons to F*&% themselves?

Posted by Digitalpenny at 08:14 PM | Permalink | Comments (2)

We really are living in a matrix and we can't wake up!

Posted by Digitalpenny at 11:48 PM | Permalink | Comments (0)

Do parents still teach their kids "manners"? Well, I just had an 11 year old girl enter my house without knocking. It immediately pissed me off.

I was sitting here at my desk talking to M-jr, when the door flew open. She said, "Marcus...blah blah blah...." (WHATEVER!, I only heard "Marcus"). As she blah blahed, I looked up and sternly said, "You could have knocked! You don't live here you know!" She didn't say anything; she just closed the door and walked away.

The girl at the door must have caught M-jr off guard as well because he shouted something like, "Yea! You should knock, instead of just walking in." And then he went outside. Now, THAT was a bit different for me. (His making this remark.) He usually says (under other circumstances) something like, "Mom, it's okay (defending the other person). You're embarrassing me." But not this time, he was on my side. Way Kool!!!

If you don’t do it, and you have kids (some would call them children), PLEASE teach them to knock before entering someone’s house. Unless the home owner knows they are coming over. Then their intrusion would have been cleared BEFORE they step into some else’s sacred domain.

Posted by Digitalpenny at 07:21 PM | Permalink | Comments (0)

Derek, I downloaded Firefox, and I'm loving it!

Posted by Digitalpenny at 11:35 AM | Permalink | Comments (2)