Author: stolov.l

In general, I agree with the changes proposed for the cover letter schema.  The first of these changes is to include the option for several “reason” statements within the introductory paragraph.  This is something I believe our group would have agreed had we given this element more thought.  As the cover letter group pointed out, this might be more useful for less technical positions, which our group did not focus on as much compared to technical positions that might be more relevant to our rhetorical situations.

Another point the group made was to have the “proposition” element in the introductory paragraph made optional.  I agree with their reasoning that this could allow more flexibility in the first paragraph.  However, from our research, we found that this element was fairly common in many of the samples we looked at.  In this case, I would agree to make the proposition element optional, but to also add a comment or add to the definition of the element to communicate that it is also recommended.  In the group’s design entry, they make the point that this element might “present a repetitive statement” depending on how their opening of their intro paragraph was written.  I would argue that this constraint could help guide the writer to change their opening instead.

Another great point made by the cover letter group was to include an “interest” tag in the background paragraph.  I believe this is a great addition for which the reasoning is well reinforced by the examples provided by the group in their design entry.  I think this shows the importance of including more people with different backgrounds in the schema creation process.  Our group of four people represented just 2 majors in the engineering discipline, which might push the cover letter to be better suited for certain types of jobs.  We also only had 4 different personal rhetorical situations to reference when we discussed any possible changes.  The cover letter group had several more, which allowed to draw from many more scenarios and test the schema against more rhetorical situations, which in this case made a change like this much more obvious.

For the most part, our group wrote the majority of our content without consulting the schema.  We found the schema was generally challenging to follow and not entirely intuitive when writing the blog post. It was easier to write the post in a word document, allowing for the organization of all the scientific content we wanted to include, and then match that to the schema elements.  We felt that the schema could have been better organized and laid out in a way that is more easy to follow when writing.  This could include listing elements related to each other next to each other, or putting them in places that they would more likely be found.  For example, a misconception would often be seen at the beginning of a post, or the background paragraph.  One solution we mentioned was to list the global elements twice inside of the schema.  They would still be listed underneath the global elements part of the schema, but would also appear inside of the background and answer elements in an order that would make sense for a blog post.  This way, someone looking at the schema for the first time could see how elements fit together for this particular genre.  The template file could also be improved by having all required and related elements built into the template. For example, it was not clear looking at the template schema that a technical principle was required in the background section. It was not until an error message appeared that it should be included in the background.

Another change that we feel might be useful is to either eliminate or redefine the “specific topic” element.  In the schema, it is literally defined as a “specific technical principle” which may be redundant since “technical principle” is already an element.  This may help make the schema more clear. Additional, the first section header should be a title for the blog post or the overarching question that all the individual section headers work to answer.

We also found that the numbering attributes under elements such as “technical principle” and “important idea” were not very useful to include.  In fact, numbering the elements could be rather distracting as adding another element into an already written post would mean going through and renumbering the elements already written.  This could make the blog post easier to write when using the schema.

Additionally, a separate italicize element could have been useful, since there were some cases where a word or phrase that is not necessarily an important idea could be highlighted by being italicized.

On a more positive note, some of us found the schema to provide an outline in a clear way. The combination of section headers and technical principles allowed you to put your skeleton down immediately, and then flesh it out. Despite the frustrations of mandatory / dis-allowed elements, the schema still has a very usable heuristic.

When writing my edutainment blog post, I found myself creating most of the content independent of the schema.  Instead, I used some of the examples provided by the group presentation to figure out how I wanted to present my information beforehand.  After writing most of it, I then went in and assigned elements to each part of my post.  This is where I found the schema to be the most useful, since it pointed out some useful pieces of information that I might have missed otherwise.  However, for the majority of my post, I felt that the schema was not terribly useful.  I felt that I spent extra time labeling elements afterwards which did not result in any changes to how I word things or how I organize ideas.  Because of this, I believe it was a great idea making the schema very fluid with many optional elements.  I felt the way the schema was made did not significantly constrain my writing.

Nevertheless, there are some changes that I would suggest, or at least discuss, for the schema.  I think I would have liked to see more optional elements related to the background section.  I personally had trouble starting my blog, so a more defined or structured beginning elements might have been helpful in this case.  Similarly, I had almost as much trouble concluding my post.  Specifically, I was not sure how to properly condense everything and how much detail I should put in my summary.  Also, I felt that it would be useful to add a suggested section header or some sort of visual divider between the conclusion and the sources.  This is because I feel that the sources section would be pretty similar for everyone.  Finally, the last change I can think of is to eliminate the specific topic element.  Personally, I felt that I never really needed to use the specific topic element, and I found it very similar to the technical principle element.  In fact, looking at the schema now, the specific topic element is even defined as a “specific technical principle” which may mean it could be slightly redundant.

Since we were basically able to break the cover letter down line by line, I used the schema heavily when working on my project.  In many ways, I believe it was useful since I did not have to guess on what to include in my beginning and ending parts.  However, I believe it may have hindered how smooth the cover letter read as a whole.  While each sentence might have sounded well individually, at time I felt there might not have been a good cohesion or transition between lines or paragraphs.  I think this was especially true for the background paragraphs, since we limited the sentences within this part to a single element called “experience”.  Because of this, I found the xml was the least useful for this part of the cover letter.  Instead, what I found the most useful was the peer review, since my peer reviewer was able to give me tips on what to include and not include, as well as how to divide the information up.  I believe these parts of the cover letter are harder to capture with simple xml layouts and definitions.

I think learning about rhetorical situations probably helped our group out the most, since it placed a focus on uptake and the other genres and surrounding information we had to consider when writing a cover letter.  A major decision we had to make was what kind of rhetorical situation we were responding to with our cover letter schema, which helped narrow our scope to what I think was a more useful document.  We also realized the importance of a job description when working on this as well, which was helpful to further define what our cover letters were structured like.  That being said, I am not too sure the readings were a big help in understanding the writing for this project.  Rather, the in class discussions and examples served as a better guide to how to define and talk about terms such as uptake and rhetorical situation.

The genre that stands out to me is the edutainment blog, mostly because I find it interesting.  Personally, I have read a few “What If” posts and have seen several videos from several of the YouTube channels that group 1 mentioned in their presentation.  I have found all of these entertaining and I feel like I learn something interesting from each post.  The genre itself is a good summary of a particular topic created from an understanding after what seems to be rigorous research.  Because of this, this genre might be useful in that it could store my knowledge on a particular topic should I choose to create one.  It can also educate and entertain others.

While it may seem unconventional, I can see this genre also being useful in a professional or academic environment, where it is necessary to train and educate a group of people on something that I am working on.  One particular focus of this genre is making information understandable on a much simpler level.  A rhetorical situation where this might be useful, therefore, would be presenting research I have done at some university or research organization to an audience without the same background as me, such as readers of a news publication.  My desired uptake would be to educate, which in many cases requires the audience to be entertained should the information not directly pertain to them.

While the schema gives a good layout of the genre, I will still have to study examples to learn about how to emulate a different, less professional tone in my writing.  It also seems like this genre will require a good amount of research depending on the topic I choose.  The research will also involve looking into possible images to include as well, though I can also see many situations where I would have to create my own images as well.

In writing this cover letter, the schema did seem to be particularly useful and helped guide my writing.  The only time it seemed to be constraining was the beginning paragraph on my cover letter, which I believe turned out to be very helpful since I wanted to include information that fits better into my background paragraph immediately after writing it.  However, the schema alone was not nearly enough to draft my cover letter, as I still referenced the job description and other examples multiple times to figure out how to word my qualifications, as well as how to structure my background paragraph.  I believe the background paragraph is by far that most challenging part of the cover letter to write, since I identified it as one of the main aspect of my first draft that I thought could change.  My peer reviewer agreed with this thought, and the same applied for her background paragraphs.  This makes me think that it might make sense to better specify or add elements to this part of the cover letter.  Specifically, some ideas we had were to add sub elements under experience, or to define background paragraphs to mention just one experience each.  This would mean if I was talking about my co-ops, I would split my writing into two background paragraphs, one for each co-op.  Additionally, if I wanted to talk about my personal or school experience, I could separate that into a different paragraph as well.   That being said, if we had done this initially, I could definitely see myself writing this design entry about how I felt very constrained when writing my background paragraphs, so I believe there should definitely be a balance for how defined this section is.

The two main genre’s that precede a cover letter are a job description or posting, and a resume.  While a job description is quite obvious, since it indicates a job opening that a cover letter responds to, a resume is not so clear.  While a cover letter typically precedes a resume for the reader, the resume is usually written beforehand by the applicant, and is referenced by the cover letter in a way that makes sure there is not too much repetition between the two genres.  If successful, a cover letter is usually the basis for various uptake genres such as an email or phone call regarding the next step in the hiring process.  The type of genre is dependent on the cover letter, since it provides contact information that is used to create the next genre.

To achieve the desired uptake of a cover letter, there are several tips our group learned from our research.  One of the most important points was an emphasis on looking at the preceding genre, the job description, when writing a cover letter.  The most successful cover letters are tailored to each individual job opening, and specifically reference certain, or all parts of it.  To put it simply, the cover letter connects the details of a position to the qualifications, interests, and personality of the candidate.  In this sense, uptake is important, which also lead us to look at cover letters with the relevant job description attached in our research.

However, much of this information is challenging to include in our genre model since each rhetorical situation can be so unique.  For example, it is hard to include elements that make sure the sentences created are not too repetitive of the resume, especially if it is not known how the resume is structured.  Similarly, since each job description can be different, it is challenging to figure out which element should include a direct or indirect reference to the details of the position the candidate is applying for.

For my second co-op, I worked at a biomedical company, with my primary focus being on designing equipment and machinery to automate the manufacturing process.  This involved more than just mechanical work, since for something to be automated it would normally have electrical components and some sort of programming.  Because of this, I was able to be involved and get experience in more than one discipline.  This seemed to be common for most of the mechanical engineers there.  While there were a good number of employees that specialized in other disciplines, such as electrical, systems, and optics engineering, every mechanical engineer did work related to those disciplines as well.  Almost every mechanical engineer, at least while I was there, was involved in programming and wiring.

In terms of actual work, this was very useful since everyone could provide insight into a problem that might be multidisciplinary.  This also means that supervisors could be rather flexible as to who to assign to each individual project.  The work that I did and what most people did then, would most likely be described by Leavy as transdisciplinary, since it was problem-centered and generally evolved to include more than one discipline.  Since my concentration in mechanical engineering is mechatronics, which is many times defined as the blend on several disciplines such as mechanical, electrical, software, this is exactly the work I could see myself doing after graduating.

Mechanical Engineering is a broad discipline with many different applications, and I believe this is shown with the two completely different directions Chris Murphy and I take our major and apply it to problems within Boston.  While I looked more at the integration of mechanical, electrical and software for drone delivery applications, Chris focused on energy consumption and efficiency of Boston’s modes of transportation.  I believe Chris had a more concentrated approach as he mentioned looking at the difference between electric and internal combustion engines in his problem statement, while my approach was slightly more broad.  Outside of the problem statement, we both seemed to cite sources that mentioned a couple possible solutions for the problems we were discussing.  My bibliography mentioned both land and airborne delivery drones as a solution for inefficient package delivery, while his mentioned electric buses and electric garbage trucks as a solution to inefficient public energy consumption.  In terms of the XML source, we seemed to write in similar styles as we used the same element types.  Specifically, we both switched between “author” and “source” for the background element, stuck with “general” for the summary element and mostly used “application” for the relevance element.  One thing Chris has done which I have not is use different title levels for his citations.  For the most part, this has reaffirmed how I wrote my annotated bibliography, since it is written in generally the same way.  I would consider adding different title levels where appropriate and also being slightly more specific in my problem statement in terms of the insight my discipline provides to the problem.

Using XML definitely affected my writing process because the schema gave clear direction and purpose for every single one of my lines.  That being said, I still felt more comfortable writing my first draft on a word document and importing my lines later on.  The spell and grammar check tool in Word is also really useful.  In general I am not sure how I feel about using XML for composing singular writing assignments since it feels rather tedious for a non-repeating piece of work.  In this case, XML seemed to be useful since the annotation and citation portion was repeated 4 times.  Using a schema also improved my understanding of the “social action” of genres, since it broke down the bibliography in a way that it was very clear to see exactly what an author was trying to get across.  I also did not seem to have many technical issues with Oxygen, though that will be more clear once the project is reviewed.  However, it did leave out an element of creativity that I felt could have been useful at certain points.  There were times when I felt I had trouble smoothly transitioning from one line to the other because each sentence was constrained by the element descriptions that the class has chosen.  It might be beneficial, then, to use the schema as more of a loose framework for creating a genre, rather than a rigid one.  Since the class looked at about 10 or so examples, I would also say that I am unsure of how many other examples of annotated bibliography would be correctly characterized by the schema we created.  As we move on to project 2 and 3, I feel it might make sense to spend more time on the schema, and to possibly re-visit it after the writing has already started.  I feel that the class would get a better idea of what is expected and what is constrained once the actual writing process is underway.  I would also be interested in learning more about the other capabilities of the Oxygen program, since it seems like we stuck to the very basics for Project 1.  I am also unsure of how convenient making edits and peer reviews is on already written documents.

One of my few issues of living in Boston revolves around package delivery. Living on campus, any package that gets delivered to me I would have to pick up myself, which involves scheduling a time when the package place is open and carry it back. Living off campus, if no one is home to open the door for the delivery person, the package gets stored somewhere else, which leaves me with the same issue. Additionally, most delivery services don’t provide an exact time of delivery.
I believe this issue can largely be solved by automating the delivery process. Take the delivery person out of the equation, and give power to the person who wants the package. If package were delivered by a fleet of drones, the receiving party could check the location of their drone, and be given a more precise time of arrival. Additionally, they could tell the drone when to deliver.
A number of companies have already begun to work on this issue. One famous example is Amazon, with the development of Amazon Prime Air. This service uses unmanned aerial drones for delivery, though it seems that, for now, it is geared more towards rural areas. Another example is Starship Technologies, which uses small, autonomous, land vehicles for delivery within cities.
Solving this issues requires knowledge of multiple disciplines, since, at least with the examples mentioned, there are several mechanical, electrical, and software challenges to be overcome. While my mechanical engineering background would mostly relate to the mechanical components of these autonomous robots, my concentration in mechatronics is precisely geared towards the combination, or blend, of all three disciplines. This is important, since with these complex systems, it is very challenging to change one feature without affecting others. For example, the placement of a sensor could affect the center of balance of an aerial drone, how it is wired, or how it is utilized in the programming. An engineer that finds his/herself faced with such a problem might not be able to make the best decision if they do not have at least rudimentary knowledge of other disciplines, while a mechatronics engineer may be more qualified.