Another week brings me to another report on the developments in relation with my writing class at Arizona State University.  As mentioned in my last post I was working on a project which entailed creating a document which instructs a user on how to leave a review at www.tripadvisor.com.  That project is now finished and I have a few things to report.

In my previous post I discussed how my partner, or teammate we will call her, was unable to attend the first day of in class work on the project due to illness.  This was to some degree an inconvenience but also a nice opportunity to practice communication over the medium of email and texting.

We did end up meeting up a few days after class to create a draft of the document and that turned out to be as successful as I could have hoped.  We were able to communicate easily and both had a similar vision of what we wanted to do.  We also seemed to have a lot in common beyond the project which I won't go into.  But the point is we were a good match for a team.

One of the first steps to my project was organizing information.  It is suggested in the book the "analyze your audience and purpose" (Markel 153).  I knew for this assignment I didn't want my audience to be my grandparents.  I imagined them to be people who have used computers and are rather literate in modern internet technology.  As for purpose, this was a document which would be designed to teach someone how to leave a "good" review.  Good not as in I really approve of this place it was not bad but rather what I defined as professional and useful to other readers.

I think we succeeded in making instructions on how to create a review.  However I don't feel that the instructions really focused on how to leave a "good" review.  It just didn't totally match.  I feel like How to Write a Good Review should be it's own article.  We tried to follow Markel's organizing principle by using a pattern.  By doing this we were limited on how much depth we could go into about what is a "good" review.

I do believe that my literacy skills are improving slightly.  Partly I think it's confidence.  before I did follow many of the steps which are suggested in technical communication but I never really thought about them.  They were basically instinct and I never fully trust my instinct.  Now I actually have reason to back myself up so I'm confident in my communication actions.

For example I had to write an email to my supervisor last week about some technical issues I was having on a website and found it to be very simple and not intimidating at all.  Also my professional texting skills are pretty good i think.  In this last project most of our communication was texting and I also use that medium for group projects in other classes.

Memos are really useful I've found.  I've created at least three memos for this last assignment so I think I'm starting to get the hang of it.  I found writing email to my grandparents to be easier than I remember.

Another thing that I'm getting better at is typing.  I've been doing way more typing due to these emails, memos, and this blog included.  I can see I'm starting to memorize the feel of my own keyboard and can write with more ease.

I think I still need to work on my oral communication skills.  At the beginning of our classes we do what's called table topics.  Basically you have to stand up and talk about something for 90 seconds.  It's really hard.  I feel like I could easily do it if I was speaking to someone who I' comfortable with but in the class setting it's different.  As soon as I feel like one person out of the class doesn't really care or agree I instantly start to lose my train of thought and start looking for a way to conclude my speech.

I image this week I'll be called upon to do another table topic so my plan is to avoid anything which will lead to a conclusion until i'm confident I'm ready to stop talking.

Besides that I guess I'm ready to being tackling the next writing project.  I honestly don't even know what it's going to be but I'm not really scared of it.  I'm actually somewhat looking forward to meeting more people in the the class and seeing what kind skills I can learn from them.

That's all for today folks.

To be honest at this point in the semester I've already lost track of time and can't tell you if this is the fourth or fifth week of the semester.  What we do know is that this is my fourth entry about my experiences learning technical communications in a writing class at Arizona State University.  A lot has happened and it looks like much more is in the works.

Last week we finished up the first project and began working on our next project which is due one week from today.  The Instructions Project is a group project which requires the group members to create directions (instructions) on how to leave a review on a website which the group is assigned.

My group, consisting of two members, will do an instruction set for leaving a review on www.tripadvisor.com.  So far we haven't had the best of progress.  I received an email from my group partner several hours before class in which she explained that due to illness she would be unable to attend class that day.  We were supposed to complete a strategic planning memo together in class that day and my partner was sincerely sorry for putting that burden upon me to complete it on my own.  I was glad that she was nice enough to let me know what was going on.

To say I was actually disappointed that I would have to work alone would not be completely true, however.  I now realize after reflecting on my class period that working in a group may be something I actually need to work on.  Working alone is something I've become very comfortable with and as a result I think I've missed many opportunities to let other people help me out and give me ideas.  Many times have I decided to just take charge and do most of the work myself rather then count on others to do it.

So this I figured that this project would be a good chance to help develop my group working skills.  That's what the project was designed to do at least.  I think.

Anyways, in class I wrote a pretty cool memo.  It seems kind of odd to be excited about writing a memo but it was actually interesting to me.  I don't think I've ever written a legitimate memo before.  Wanting to know more about memos I took a look in the text book to see what I could find about memos.

What I didn't realize until the exercise in class and then reading the text was that a memo was as formal as it is.  For some reason I had imagined memos as basically a digital post-it note.  Well the one I wrote was way more than that.  In Chapter 14 of the text book there's a section about using the proper level or formality (Markel 373).  Although I have not put too much thought into this before I can see it's something I do.  Many people do it without thinking.

For example, when my group partner emailed me about her absence last class, her composition was moderately formal.  Communicating with my group partner has been exclusively formal.  This is of course much different than if I were working on a project with a close friend who understands me when I text him or her incomplete sentences and incoherent phrases which only he or she understands due to the scope of our relationship.  There was a lot of interesting pro tips in that chapter about writing a good memo.

To better understand this Instructions Project and look for tips I reviewed chapter 20.  From looking at the examples of instructions it seems like how the document is graphically organized makes a huge difference.  It looks like we will be doing brief instruction in this project so we will at least need skills in writing and graphics but fortunately will probably not need to worry about legal issues.

What will need to be figured out is how to delegate work within the group.  In past projects I feel like I've been a bit of a take over and haven't let other members contribute enough.  In this project one of my goals is to allow my group partner to have input on what we do and also to let her do her share of the work.  I realize that it may be difficult to figure out how to effectively communicate within the group to achieve these goals but I guess that's just part of the assignment and one of the main reasons for this class.

I have a meeting with my group tomorrow and will give an update on how things went next week.  Peace.

As the semester picks up I once again find myself struggle to survive each day.  It grows increasingly difficult to wake up in the morning and easier to find dozing off during lectures.  Not to mention my addiction to procrastination is getting worse.

So... Writing for professions.  I suppose in the profession there's not really a place for procrastination.  Things need to be done right and completed properly.  People aren't pleased or impressed with work that looks like it was completed last minute.  I wonder what the book says about this.

Sure enough...  In chapter 4 the book discusses effective ways of writing collaboratively.  Under the guidelines for managing your project are listed "plan your project" and "create and maintain an accurate schedule" (Markel 60).  I think that if someone like me would actually create and commit to a schedule then I wouldn't have procrastination problems.  That's the thing about procrastination I think...  I mean look at this blog...  I was scheduled to have this written by now and look I did it.  At the last minute? Maybe.

But that brings up another topic of managing a project: breaking down the project into several smaller tasks (Markel 60).  I think that if I create a schedule that has small parts of a project have deadlines then I would probably get things done on time no problem.   I'll hopefully try to employ this strategy in my next project.  Maybe I'll report on that in a future post.

Maybe you're wondering about my current project.  The Technical Description Project (TDP) which Ive been working on the last week turned out to be more complicated than I imagined.  While looking through other example projects it seemed to be that the way the TDP was layed out was very important.  Organization.

From the book I found the three principles for organizing technical information (Markel 153).  The first one says "analyze your audience and purpose."  So I started thinking about that and realized that my first draft for the TDP was kind of poor.  I needed to determine who my audience was.  Initially I think I wrote it for someone like my grandmother who is not very tech savvy.  But I reconsidered thinking that most people are at least somewhat familiar with purchasing things online.   So instead of giving a description of how to buy something on Amazon I wanted to show a user some neat function which will make his or her buying experience better.

I think I used good patterns in my TDP.  They were at least consistent.

As suggested by Markel I tried to avoid "sexist sentences."  I was always taught by my mother that using "he" in a sentence as a pronoun(?) was fine and represented either a male or a female person unless that pronoun was explicitly referenced as a non-female person previously.  But I guess it's good to avoid offending anyone in the professional workplace so I'm willing to pour some sugar or cream in his or her coffee if it makes him or her happy.

I thought the section in the book for using the people-first approach was interesting.  Basically it's a strategy of naming people by stating that they are persons before describing what kind of persons they might be.  That's something I've never thought too much about but it makes a lot of sense.

Anyways I did actually finish the TDP on time and I thought it looked pretty good.  The hardest part was deciding what features to include and what to leave out.  Amazon is a huge website and there's a lot of material that could potentially have been covered.

Writing the document wasn't too difficult for me.  I usually don't struggle too much with getting my thoughts onto the paper.  How to people think?  I'd like to say I think in the English language and use actual sentences and phrases inside my head when I think.  I remember asking my dad about this and he said "yeah sometimes I still think in [his native tongue]..."  It's the raw emotions and feelings which are sometimes difficult to think in a language because I don't know the right words to use.  But technical stuff doesn't seem too bad.

Anyways I think my limit is up here.  Same time next week?

Once again I'm supplying details about a writing class which I'm enrolled in at Arizona State University.  Last week I talked a little bit about what technical writing is and my plans on improving my skills in technical communication.  Moving on, this is a new week and there's more for me to learn and more for me to blog about.

Our first assignment is called the Technical Description Project (which I may refer to as the TDP later in this post).  It's basically a project where I will introduce a new user to a website and explain how the website can be useful.  It's a bit more complicated than that...  It's all written, and it needs to be professional.  Furthermore I'll need to user the Measures of Excellence in Technical Communication (page 13) which is honesty, clarity, accuracy, etc...

I got assigned the website to do my project on which honestly was a big relief for me.  Sometimes projects like this stress me out with making tough decisions like which site would be best.  So it's nice to know that any hardships I encounter will not be causation for me to blame myself for picking a difficult website to do the project on.  Even better, I got assigned a website which I'm excited to report on: Amazon.

Amazon.com is of course one of the biggest online markets.  I'm a regular customer and I know a lot about the site.  However explaining the site to a new user isn't something I've ever really thought about.  I guess in this day and age I kind of expect people to just type in a URL for a webpage and just know how to navigate the site by following whatever cues are present.  To me most sites are pretty self-explanatory.  I didn't need a manual to figure out how Snowbowl's website worked this last weekend when I wanted to figure out details about snowboarding there.

After analyzing a situation which occurred in class and thinking about some experiences I've had with my own mother I've concluded that this technical writing stuff is actually really important for some people who for some reason or another are not as self-intuitive and adventurous on the web as myself.

See in the project we're supposed to put in some images of the website.  Visuals I guess we could call them.  You know, they help people who don't fully understand the descriptive text and need to be physically shown what we're talking about.  Anyways, out professor asked if everyone knew how to capture those visuals and apply them to their document.  She then proceeded to begin a short tutorial on how to "print screen" and use the Windows Paint program to crop the image.

Now I've been using computers a long time and I'm familiar with this practice.  I've done it several times before until I discovered a much easier way to do it.  The Snipping Tool (which is included on all Windows PCs running Windows 7 or above).

You're probably wondering where I'm going with this.  Well in class I couldn't just sit by and watch as an entire classroom was instructed to do something the hard way.  So I spoke up and sure enough not everyone knew about this gem of a program.  So the professor asked me to show the class.  I just said, "uh... You just go to the start menu and type in "snipping tool" and you should get it..."

Then she was like, "No... Come up here and show us."  For a brief moment I thought seriously this isn't that hard.  But whatever I went up there and figured how hard can it be to show the class this little program?  Now walking up to the front of the class you could imagine I didn't have a plan about how I was going to going to give a tutorial on this program which I can't even remember the last time I used.  I was going to wing it.

Long story short: while I fully understand the program and what I did on it, I'm pretty sure my demo went over a few people's heads.  My bad.  I probably should have been more technical and descriptive in the demo process.

But what I learned is that people don't always know how to wing it when they encounter an unfamiliar program.  Many people have been taught how to use programs and don’t often figure stuff out on their own.  So technical communication is very important in these circumstances.  I can now see where better technical communication skills would have helped me explain technology to my mother who many times I've considered to be technologically impaired.

This TDP project reminds me of the subreddit (a branch of a huge social website) called r/explainlikeimfive (ELI5) where people who are not educated in a certain field ask somewhat complicated questions in hope that an expert will give an answer which he or she can understand.  I think I might read up on there to get inspiration for my assignment.

That's all for today.  My limit's up.