Author: vlajkovic.d

For Project 3 I used the schema as a step by step guide in developing my cover letter. I found that the simple structure of the schema was very intuitive and gave me an understanding of how I should proceed in my writing process.  From what I have done so far I find that the schema is very much appropriate to the rhetorical situation that I am responding to because I am trying to put out application for job in which I hope to receive an interview for and this schema for cover letter fills the necessary needs for apply for a position. I can only really find one issue where I felt constrained by the schema. This was when I was working on the intro paragraph and I wanted to write something outside of the intent and reason elements. But because of how the schema is designed I was unable to write outside of those two elements. Outside of that I found the schema very helpful as it gave me a sense of what element each section needed and how I can transition from one part to another.

Going through the peer review was a very helpful experience for me as I was able to see how my partner took up genre and I was able to get pointers on what I needed to improve on my own project. I think that from the experience I was able to garner more ideas on I how I can add more to my cover letter. Going back to the schema I did not find any of the definitions or structure to the schema to be confusing to me. Compared to project 2 I found this experience to be smoother so far because I feel in project 2 it was about recognizing a genre and developing it along the way and working out the kinks. Whereas in this project I found that I was using a schema that was extremely polished and very straightforward to use so there really was not much of a learning curve. With regards to changes and improvements, I find that the ability to write outside of the two elements in the intro section to be one of the things I would like to be improved. And during the peer review from talking with my partner I found that the there maybe should be a general element that could be put into place when you have something that does not belong to the work, personal or school experience.

When looking at the other three genres that my classmates worked on, what popped out to me was cover letters. I found it interesting that after all of the resumes that I’ve had to create for job interviews and co-ops I had never once made a cover letter. I find that this genre can be extremely useful in the job word because it can be an effective way of separating yourself for other applicants. This genre allows implores to see how some of your personality traits and come up with a more vivid description of what kind of person you are compared to just a resume. Obviously this genre would be an appropriate response to a situation where I am looking or applying to a job. In this situation the audience would be an employer or hiring committee and the desired uptake would be an interview or even a job offer.

I found that from the schema the overall structure was pretty simple and very straight forward. I found that the schema for this cover letter had many of same qualities that you would find in a normal letter with a more guided approach on how you would structure it towards the intended audience which would be an employer. From looking at the schema there really are no parts that I find to be confusing at this moment. Looking forward at the research portion of this project, I think that I will spend time looking over my classmates cover letters as well as looking at cover letters that would reflect my field.

From the initial draft of project 2 I found that there were a lot of takeaways that I could use moving forward. Firstly I found that schema was appropriate for the rhetorical situation that I was responding to. I found that in the situation I made, it was necessary to create a proposal in order to get the proper course of action to correct or improve upon the situation. I found that working within a smaller group compared to a whole class there was a much more beneficial experience because there was a more specific direction that each one of us wanted to go in the group compared to the whole class. By that I mean that instead of having a schema developed by twenty something students with vaguer elements we were able to incorporate much more defined elements into our schema where we each develop a strong understanding of where, when and how to incorporate those elements into our work. Looking back at our schema I think that we did a very good job at defining the elements and the overall structure of a public initiative proposal, and gave ourselves a lot space to really develop our own unique form of that genre. Where I found some constrains within the schema was mostly trying have multiple elements of same kind or the same element with multiple attributes in the same section. For example if I wanted to put in a citation I could easily do so, but if I wanted to add a second citation element so that I could put in another citation on its own line, XML would not let me do so. For the multiple attributes part, I found that there may have been moments where I wanted to have more than one attribute within an element, for instance feasibility. But due to the design of the schema, I would have to add another feasibility element to select a different attribute instead of making it under one feasibility element. Another thing I would like to note is occasionally I found the definitions to some of our defined elements were similar to one and another which would sometimes confuse me. I found this to be the case when I was trying to develop my objective and goals for my first draft.

For the proposal model that my group is doing we are developing, specifically a proposal for the purposes of improving things found in the community. Usually there are not a lot of genres that will precede these proposals as these proposals are usually one of the first steps in developing/building this project. But genres like notes or emails can transpire from conversations or meetings that a few individuals to a group of people within  the community that can eventually lead to these people to develop this proposal. The uptake that can be found from these preceding genres don’t necessarily lead to the creation of these proposals. These notes and emails could lead to other things like articles found on the internet or local newspaper or phone calls to city board offices or fliers that lead to group meetings. As a result there could be many different routes in which uptake can go from one genre to another and how these paths lead to different approaches.

While we were building our genre model for project 2, our team looked at examples of proposals as well as looked into the background of why and how these proposals came to be. First we looked at more specific proposal examples that we used to know what all of the necessary elements and sections were needed in order to come up with the most complete model. After that we looked into a larger variety of proposals and tried to find commonalities between these different proposals to make sure that our model met the standards of a basic proposal.

The genres that typically follow this sort of proposal could be an RFP or bid or a more laid out plan that goes over the details of the execution of the proposal. Typically these are the more formal forms genre that will appear after a proposal is put out there. But there could be other genres that may come up directly or indirectly like emails, text messages, memos, etc. between the party taking the proposal or the party that put in the proposal.

The ways uptake can influence the way the genre is construed is by understanding what results you would prefer to see once you put the genre into play. What that means is that if you want a proposal that you would like to be received by a more general or crowd that is neither on one side or the other than maybe you would want to orient your proposal to give a very moderate input.

I worked in a workplace in a manufacturing background that was very technical based and involved a variety of genres and works that may have overlapped or coincided with one and another. I think that I would characterize the works undertaken in the work place to be monodisciplinary. I felt like that there were a slew of things that people worked on from generally the same discipline, sometimes varying, and from there the works may have sometimes collaborated and integrated with others. For instance you may have a quality report which may lead to a reflection a weekly report and from there the report could be sent out through an email chain. Some of these forms of work that you will see in this environment could be things like reports and research presentations to emails and notes. From a standpoint of my peers that I worked with I saw that there was good mix of people who were in my specific discipline and others who were still within the engineering discipline but not necessarily in my specific discipline. Most of my direct co-workers were of the same discipline, but other people who I did not interact with like people on the floor, HR, people working in a different division than the one I worked at can from different disciplines. I feel like in this environment though there were some variation of disciplines I experienced, overall I was surrounded by mainly one discipline based working environment. After graduating I see myself doing similar work to what I have done in my previous co-ops like reports, emails, and presentations. Hopefully I’ll also have the opportunity to also do some research journals/reports that I can work on. I see myself working with this genres because they are all necessary to this line of work and will enable me to the type of work that I would like to do. So far I’ve experienced a monodisciplinary work environment, but I hope to have experience working within places where multiple disciplines overlap and in some cases integrate with each other. I find that there are certain values in experiencing something like that.

For this entry I took a look at Sam Wagner’s project where she went into addressing how in America we do not take care of older buildings and how we can find ways to take better care of them.  I saw that from a discipline standpoint there were variation to how she approached and I approached project 1. For one since her discipline is civil engineering she was bring up more building oriented setting whereas I was going in depth with mechanical based approach.  For her problem statement there was a lot more first person and a good deal of background that she brought to the issue where I approached it from third person and went more technically into the issue.

Looking at the XML  source I found that there were a lot of commonalities between mine and Sam’s writing. I found that we both used general summary in each of our annotated bibliographies. I also found that our  summary and relevance sections were usually larger than the background. Some of differences were that she used MLA for citations where I used APA. She used multiple different summaries more than I did.

Looking at Sam’s project now I would probably have included more application/relevance material into my annotated bibliographies. What I mean by that is that I would have included more examples and applications that I could have given the reader on how to improve the problem. Obviously from viewing this project I have different way of viewing this project and developing an annotated bibliography, what I noticed is that schema is more of a guideline than a principal because looking back I feel like my annotations may have been a bit constrained and may seem a little rigid and clunky.

Overall I found that my experience with project was very refreshing and interesting to me. I wrote in a way that was not familiar to me and was able to understand the schema to writing a annotated bibliography. At first it was somewhat confusing for me to use Oxygen and type up my project in XML, but as continued to do it I became more comfortable with the idea of XML. One of the things that I worried about as I writing up these annotated bibliographies was that the transition from element to element would be somewhat bumpy and would not flow compared to a typed up version in a normal word document. But when I started looking at the formatted file, I was surprised to see that the overall flow and  composition of my work was very similar to what I would see on something similar written up on a word document.

At first I viewed having to use elements to my writing as a constraint because I had to think about how I was going to write something into a certain element or think about how that part fits there. But from continual use of the schema I was able to see that I was more efficiently organizing my thoughts and structuring my points in ways that made a lot sense. The markup schema that we devised in class help up very well as I was working on my project, though I feel there were moments where I wanted put in something but did not have a good feel for with element it belonged to or if any of the elements we came up with actually fit to that idea.

Moving forward I am actually looking forward to using Oxygen and writing in XML. I think that learning how to work within new genres and formats using this technology will be a great opportunity for me develop my writing ability and understand the ideas of genre.