Category: Journals

Overall, I feel like this class not only made me a better writer, but it also improved my analytical skills. It has been making me think differently about everything I’ve been reading since we studied more about genre. Just a few days ago, I was reading a mystery book and I stopped in the middle to think about overlapping themes and structures that might be present in mystery books, and I caught myself trying to vaguely sketch out an XML schema in my head for that genre. Thinking back, I feel like finding structure in the assignments I’ve been writing in class has always been a subconscious thing I’ve done, but taking this  class will make me think more consciously about extracting structure from examples I’m given. I believe that doing this will improve the quality of any sort of documents I have to write in the future.

Overall, I feel the structure of the class, where we would do the assignments in XML, submit using Github, and write design entries using WordPress all worked well. Having our work out in the open for the entire class to see was a little nerve wracking at first, but in the long run I learned how useful having my work peer reviewed could be. On top of that using a markup language such as XML also seemed like an extremely useful tool in teaching us about extracting structure from a genre.

Looking back at assignment 2, my initial thoughts when starting it were about how easy coming up with a schema for whatever genre we picked would be. In my mind, the structure of all genres was pretty straightforward, and apparently all of my group members thought so too, except their structure was different that mine. Going through and discussing how to format out schema, and coming to a single conclusion was an extremely interesting experience. Before starting the assignment, I thought it would be a piece of cake, but as we went through, I realized how much work it would be. After we wrote up a schema we could all agree on, I thought it was perfect and we would be done with it forever. However for assignment 3, a few of our classmates actually disagreed with some aspects of it, which I thought was interesting. Even though our individual compositions looked really similar, there were some differences between our schema, which I found very interesting. It seemed like we all subconsciously knew about the genre, but all defined it differently.

I feel like after going through this class, I won’t be able to pick up on different genres in workplaces or daily life without consciously looking at the structure. Although it might be a little more work on my part, overall I think it will help me better pick up on how to using those genres properly and effectively. 

To start off, I would like to say that I definitely think about writing differently than when we started the course. My writing process has changed, and I will get into that, but also my role as an audience member has changed.

Looking first at how my writing process has changed, XML made me think about paragraphs as having a clear “intent”. Sometimes it was even smaller, with multiple sentences having their own “intent” and then combining that with another clump of sentences to form a larger idea. The way we communicated these intents were through the element names or “type” attribute. Looking back at project one we see this with the summary type. By identifying what the potential uptake of different parts of the citation (looking back at project 1 we had summary and relevance), the author can literally label their intention.

Now the question becomes how us as readers of the formatted document benefit from from these labels. Frankly, we may not directly see a benefit. We may only see the benefit through the author’s improved ability to clearly communicate an attempt by preemptively labeling their work. There is something to be said that a skilled can arguably do this already, but these labels certainly help some us. As readers of the XML, that we often were during our class, we can see the intent and this allows us to empathize with the author. It shows us the desired uptake quite literally.

Outside of XML and blatant rhetorical analysis my role as audience member and a consumer of many genre of writing, whether it is a youtube video (the finished product of a script) or a news article, has changed. Just the other day I was watching a video by a popular edutainment youtuber and noticed striking similarities to the genre we had made and used in class. Just watching the video once I saw clearly defined “technical principles” (only about 6) throughout the entire video. I also saw what I believed to be clearly defined section headers and key ideas. These key ideas were literally bolded on screen. Understanding the author’s uptake and see how my classmates and I had broken down the edutainment genre allowed me to empathize with the author in a completely new way. It also made his ideas abundantly clear once I could understand a bit more about the rhetorical situation. This isn’t just limited to the genres we covered in class, I’ve found myself being a better audience since our extended genre and rhetoric analysis.

Looking exclusively at project 2, I took alot away from developing our schema. Having to break down and define different parts of document made me look at writing in a new way. That’s not meant to be some “hazaaa” moment, but more I think analyzing the rhetorical situations around our genre really made it click for me. I wish we had added more detail to each paragraph-ish section of our feasibility study, but our project was already broken down significantly. The reason I wish we could have added more detail is because I think for working in XML you benefit alot from communicating small sections of writing’s individual uptakes. We definitely could have broken down our “page” elements more.

Looking back at how I began the class with my writing and how I write now, I see that there is difference in how I approach and eventually compose my writing. At the beginning of the class I understood that certain genres had a specific role in society and how they need to be used in a certain way to get some form of uptake. But now I see that there are more layers to writing in certain genres and that each genre has a defined structure that in turn is designed to respond to the rhetorical situation or give information that audience will need. I now find that understanding the rhetorical situation the genre is responding to is now the first part of my writing process. From taking this class I feel like I have a new perspective on writing based on the idea of genres where purpose and structure is not necessarily based on what the genre is suppose to do or how many paragraphs or sections are written but instead building off of previous uptakes that led to this genre and finding a way to subdivide the genre into components that lead to the success of the overall piece.

Looking back at my experience in class I found that working in XML and reading the articles gave me a new outlook in writing. I found working in XML to be strange at first, but as I became more practiced I found it refreshing and very helpful. For project 2, I found that developing a schema was an extremely beneficial experience that gave me and group members an idea of how to examine a genre and build off of those findings to make an accurate model. Creating a schema allowed me to understand the importance of each element and how the combination of these elements ultimately lead to next uptake the author hopes to achieve. I think that using XML has given me a way to develop papers in the future because I found that writing was much more clear and maintained a strong direction throughout so I think using in papers down the road will be very useful. The mix of software and technology at first was a little bit overwhelming but once I created my first draft for project 1 I found that I became more comfortable.

Probably my favorite thing from class was probably the question of the day, I found it to be interesting and a good way to get class started. One of my least favorite things from the class was probably the longer readings, just because I found that I would lose focus while reading them and I found them dry sometimes. One thing that I found to help me and get me more engaged in class were the readings and class where we would examine or read something and then get into groups and pull together what each one of us were able pull away from the reading. Overall I found this class to be enjoyable and I find that I will be able to apply a new mentally when approaching future papers.

Over the course of this semester, I don’t think that the way I write has changed much, but the way I approach an assignment definitely has. Using XML and defining a genre model before each project forced me to think about how I generally wanted to structure and organize whatever it is that I am writing. It was tedious to have to come up with conventions of each genre and define the purposes and uses of each “element” in the genre, but it made me approach every project as a problem with a very formulaic answer that I had to put together. I liked thinking of it that way because it broke down every piece of writing into a bunch of much smaller tasks and elements. This made writing a lot less opened ended, and thus a lot less of a chore.

I was pretty resistant to using XML while I was writing for the first part of the semester, and rather than writing in oxygen, I would write out a draft of my project in notepad and then copy and paste the relevant parts into the XML document. My genre analysis was still relevant while I was doing this, but it made it so that I wasn’t exactly addressing each element in the genre model. For project three I really tried to write to the genre model. It was nice because once the genre model was together, I could skip around and fill in elements with the information that I wanted to include. I didn’t have to write in order and it was much easier to step away from my writing and come back to it later because I didn’t have to remember my train of thought from before. It was kind of a pain to put together a genre model that would work for everyone during project 2, but having the genre model for project three was definitely worthwhile.

My only complaint was that writing in XML was a little clumsy. It was hard to keep things formatted and make sure my writing flowed. It would have probably made it easier if I could have made changes to the XML and then review my changes on a formatted version of it right away. Learning how to work with oxygen and GitHub was also kind of a necessary evil. I know most people don’t use GitHub that way, so it’s probably not super relevant knowledge for the future, but I was happy not to have to work through a terminal, because I didn’t want to worry about learning that this summer too. It wasn’t especially difficult to use GitHub or Oxygen, but it would have made it a lot easier to know how to use them well I think.

Seeing the connection between projects two and three was actually kind of cool. It was tedious but still informative to have to put together a genre model in project two, but it was interesting to have to write to a different genre model (that I didn’t make up) in project 3. I felt like project two was done with a real purpose because we used the genre models in project three. I also got to understand how helpful having a genre model to write to could be while writing project 3. While I really like the flexibility in choosing our own genres, I wish I had written a genre for project three that a schema would have been more valuable to have. Proposals are a really wide genre and the schema was helpful, but still had to be very open ended within each of the elements. So while I still saw the value in having the genre model, a proposal probably wouldn’t have been that much harder to write without the genre model.

I’ve learned about rhetorical analysis and genre in a bunch of different english classes before, but having to define it so strictly for each project in this class made me realize the benefit of analyzing a rhetorical situation as part of the writing process. I think it would benefit me a lot to consider the conventions of any genre that I communicate through a little more thoroughly than I did before. With luck, I won’t be writing that much in my future, most of anything I write will be to communicate directly with someone. So it’s going to be really important for me to consider what the uptake is for anyone reading what I write and that is worth putting some extra effort into thinking about.

The changes to the edutainment blog were not too significant from my view. Very little was changed about the structure, and it mostly became about making the schema more organized. Our group had mostly written our changes outside of the schema to begin with and I believe that definitely shows in our minimal changes. I tried to stay on the positive side, because despite our groups initial hesitation to draft our projects within the schema, we all more or less developed similar archetypes in our writing. For example we all ended up having misconceptions, important ideas, and technical topics. Even though we created these first on a word document, the schema fit what we had developed naturally enough.

I might be coming from a strong bias with that idea, mostly because I did not actually have much I wanted to change about the schema. Overall we didn’t really change anything that made the edutainment blog genre recognizable, even when looking at it from the schema. I personally did not see a large change with the improvements our group made, but as long those changes improved someone’s schema (which from the other blog posts, they defiantly did) then they are worth while. If this was a solo effort, I still do not believe I would have changed anything about the schema.

It’s tough to say that I ‘disagree’ with any of the changes we made, because I don’t think that is fair. It is more of just not seeing a difference. Again, it is important we made the changes because my group member’s did see a value in the changes. That also being said, I also regret not having much to contribute to our groups improvements, and my contribution to the group blog post was minimal. At the end of our assignment, I did very much enjoy working in edutainment blogs as a genre, and the old and new schema.

Looking over the schema template the only real change that it appears was made was the addition of “legal” and “other” subelement options beneath the feasibility heading. I think that adding these two categories is hugely helpful, especially with the addition of other. This allows for the author to add more information that may be project specific and not fall under any of the predefined subelements. Although this is not something that our team had initially discussed it adds additional room for proposal flexibility which was very important to us when writing the schema.

Other issues discussed in the team design post by the second group for the public initiative proposal included the addition of a global reference element and changes to the definitions and requirements for some of the attributes. Although the team did not suggest any possible definition alternatives it was definitely something that our original team had discussed and struggled with finalizing. Because each team member was looking at the genre from a slightly different angle based on our majors and experiences we tried to keep definitions and attribute requirements as general as possible while still providing sound guidance in structure. It was important to us that the document be able to reflect the project that it was for in a very specific and fitting manner contextually. The addition of a global reference element was something that we had talked about as well, however we were told that it would be a bit difficult to incorporate and because this genre was focused at the public we figured it was slightly less academic in nature and that in text reference call outs would not be necessary as long as those references were listed in a works cited at the end of the document. Overall I would say that I understand where all of these comments and changes are coming from and I agree that they would make a good addition and fit with the general goal that team 3 originally had for the schema.

The group that worked on the public initiative proposal for WP3 ran into trouble regarding some of the element definitions. The first change they made was to eliminate the sub-elements of action and execution had definitions so similar it only made the schema confusing. They decided to remove them from the schema and just allow for the text to be written beneath the approach section. They also decided to make the “who”, “what” and “when” attributes under the scope section mandatory to make the purpose section clearer. They also made the feasibility sub-elements; social, economic and environmental, to type attributes under feasibility.

I am not surprised by the confusion between the action and execution sub-elements as our group was only able to agree on the difference in definition and use of the elements after much debate. It is easy to understand why a new group working with the schema would struggle to understand the difference between the two. I agree with their change to eliminate both attributes as I believe it will make writing the approach section seem less choppy. Making the who, what and when attributes mandatory makes sense as well as they would be included in all proposals as they convey the most essential information concerning a public project. They also suggested adding a clear definition for scope that makes it clear what information it should include. I disagree as it would be somewhat redundant as there shouldn’t be a need for any additional text under scope. The scope is by definition the who, what, why, when and how of the project. Any information under scope should be covered by one of those attributes.

Their change of making the sub-elements of feasibility to type attributes was actually a reversal of a change we made in our revision process. We encountered some schema errors when we had them defined as type attributes as it only allowed for a single feasibility entry with one sub-type. To correct this issue, we decided to change the attributes to sub-elements. In addition to fixing the schema error, this change allowed for a single feasibility paragraph in the case that the proposal was not meant to be as long as a fully developed proposal. Each sentence within that paragraph could then be defined under the appropriate tag, such as social or economic.

The also suggested adding a global reference element that would work with the bibliography to add citations within the proposal. This would give the argument more credence as it would allow for statements within the proposal to be immediately supported by a reference, which a reader could then go to to look up more information that supports the claims made by the author.

Overall, I agree with the changes made by the group to the schema as I believe they will allow for a more streamlined writing process. I agree that there is not a significant difference between the action and execution sections and would leave their changes in the schema. I would not change the scope definition and I would revert the changes made to the feasibility section as I believe it allows for a more flowing argument in the feasibility section.

The changes made to our genre model during project 3 were mostly changes that we thought about when putting together our original genre model. Some of them I agree with and some we left out for particular reasons. Some people definitely ran into issues where the schema was constricting, and while I’m sure there are cases where the schema was wrongly constricting, we made it very strict to keep the letters focused and well organized. Especially among the examples of “good” engineering cover letters, there was almost no variation in the order things were included and there was very little filler text to make transitions easier. We probably could have helped this make more sense if we improved our documentation of each of the elements.

We found that it was excessive to put more than a line or two as a “reason” for applying in your introductory paragraph. Realistically, most employers are going to care more about what you can bring to the company so emphasis should be on the background paragraphs. The proposition element was also really important to keep because it’s like a summary of the whole cover letter in one sentence. It should be a very clear statement of what your intentions are with the letter. I know that during the presentations of project three, someone had almost the same definition as their take of the “compatibility” element in the conclusion, and I agree with them, but our intention was for the conclusion to be a reiteration of the letter and not the first time you clearly state your purpose for the letter.

I really like the idea they had to have an optional URL element. We didn’t really consider the unique circumstances that go with electronic copies of cover letters. As long as a URL isn’t bulky and clumsy in the middle of a cover letter, it would probably be really cool (as a hiring manager) to be able to be reading through someones cover letter and application and have a handy hyperlink I can click that will show me their portfolio.

We also talked about adding a space for a hand written signature. I completely agree that a cover letter should have a real signature on it, but we decided against adding a mandatory space because it would just achieve the same thing as adding 3-4 line break elements.

Looking at the beginning of the semester, I definitely look at writing differently. Trying to break down the basics of a genre has made me look at many things differently, as I try to break down the constituent elements of other things. Working within a schema has affected my process as I think about the schema and use it to inform what I write. Using this structure affects my work habits as I am better able to structure how I work. In addition, I am better able to work in a modular fashion; I don’t have to work on the beginning first or the ending last, I can jump around based on my research, or other factors. Thinking of writings, or any other media, in terms of genre really aids my understanding. I read a lot of screenplays and thinking about them in terms of the genre analysis we did in class gives me a better understanding of the genre as a whole. I love writing and wish I could do more of it, and I do feel much more informed about writing in my field (Computer Engineering).

Developing a schema in class was, I feel a very worthwhile activity. Breaking down a genre, extracting its structures, and making a template helped me to truly understand the genre we were studying (feasibility reports). As an aside, this class featured the only group projects that I actually enjoyed and looked forward to taking part in. The concept of using XML (more generically markup languages) has changed the way that I think about writing. Organizing my thoughts in terms of the structures of the genre is revolutionary to me. In reading court opinions, as it my wont, thinking of the composition in terms of its structures has really helped me understand the genre. One of my plans for the future is to try to start writing more (hopefully screenplays) and I am strongly considering utilizing some sort of markup language to help me do so. Overall I didn’t think that software, i.e., Oxygen, hindered me in any way; it was easy to use and its ability to warn me regarding schema errors was quite helpful.

I think that the third project was my favorite. I liked it the most because I got to write a edutainment blog post, of which I have read several hundred. This is probably not most helpful answer for posterity, as most future classes will not feature this genre and most future students will not share my love for the genre. In a pedagogical sense, the most useful project was the second, as it really broke down what the point of all the genre studies were. My least favorite, by elimination was the first.

In the future, I think that I will consider the genre of what I am reading more. What this means in practical terms is that I will sort of pre-process whatever I am reading as to be informed about its intent before reading it. Another thing that I think I would like to do is to create my own genre models based on things that I have read or am reading. Going back, this pre-process I think will be helpful as it only adds a small amount of time to the actual reading, but could really aid comprehension.

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.

I do think I write differently than the beginning of the semester. I was writing assignments for assignments but now, I think more before starting to write. I think about the genre, the rhetorical situation so that it decides my style and tone of writing. Although I was doing this before I took this class, I only think about the tone of writing. Now, I know why I would do this. In the concept of genre, I would write in different way as different genres for my project in school or after graduated.

The developing of the schema is worth of the time. We had to do research on the genre in order to develop the schema. In the process of doing this, I became an expert of the genre. It’s similar in program to make an “abstract class” which is a frame of something that can be used in similar situations. Writing in XML is an interesting concept for a writing class. Normally, I think writing is less technical and I was wondering that if I can learn something useful for my future from this class. However, the first thing that I learned was the language of XML. As an info science student, I learned many programming languages but I didn’t have any chance to know XML. The format of writing in XML is always a guide and frame for me to write. I was trained to create a frame before writing in China so I think writing in XML is familiar and useful.

For all three projects, I liked the second one most. I enjoyed doing a research on one type of genre and I did not have any experience on it before the project. Feasibility report is a useful genre for me as an info science student no matter I work for a company or start my own business in the future but I didn’t have a chance to get familiar with this type of genre. The least favorite project is the project 1. I didn’t have a clear definition of my major yet and most of my major courses are computer science related. I haven’t had a chance to take IS classes yet and I can’t distinguish two majors and I don’t know what kind of jobs are designed for IS students. All my Co-ops were CS jobs, I felt a little bit hard to get a discipline topic for the assignment. The time is a little bit tight that I didn’t have a chance to be in a study-pace. The writing of design entry is helpful that I need to keep writing in paragraphs at a rate of one per three days so that I won’t forget how to write for a writing class. Also, design entry normally helps me to think about the projects and readings and the process of assignments. It helps me to know more about the expect on assignments.

I’m going to think about the rhetorical situation and add some peer review when I write for the future projects. Thinking about rhetorical situation helps me decide my tone and style about my writing and the genre of the writing. Adding peer review is useful because the comment from classmates shows different understanding on the assignments and makes me rethink about my writing.

I do not think very differently about writing now than I did at the beginning of the semester. I definitely feel more comfortable writing in XML, but I do not think that my process of work habits have changed. At the beginning, my process was reading and understanding the prompt, doing the necessary research for the project, and then writing it in XML according to the devised schema. I did this same thing at the end of the course too. I do think that genre can be useful in and out of academic settings. In academic settings it is necessary to know how to structure certain pieces of writing, like a lab report, to effectively convey and experiment or project. Right now it useful for good grades, but in the future it will be useful in professional settings. Outside of academic settings, genre can be important for how a writer interacts with his or her audience. This is especially true within different social circles; a person will address friends, family, and coworkers in different ways in order to maintain successful relationships between the different groups. I think that the projects have helped me be more informed about my field. If I ever write part of a research paper, it would be useful to know how to write an annotated bibliography. In professional settings, I would not be surprised if I participated in writing a feasibility report or a cover letter.

For project 2, developing a schema was absolutely worthwhile. My group wrote a feasibility report, which contains many clearly defined sections and elements. Having a schema helped to organize the report structurally, and it ensure that all the necessary considerations and details of a feasibility report were included. Writing in XML made me more focused on the content that needed to be included in each writing assignment. However, it could be constraining at times, and I think that my writing style became more disjointed than it usually is when I write with a word processor. The mix of software and applications was not especially difficult to use. I just think that there was an initial challenge because I have only ever written using word processors. It was strange to see my writing so explicitly broken down into different pieces.

I think that my favorite project was the second one, where my team wrote a feasibility report. Although I think that this was one of the more difficult projects, I think that it will be the most useful for me in the future. One of my least favorite readings was Miller’s Genre as Social Action. It was fairly long, and as an engineer, most of it went over my head. One of my favorite activities was the discussion of uptake with the video and articles about Ted Cruz not explicitly endorsing Trump. This was interesting because we were using a concept taught in class and applying it to a current situation.

After this course, I will think more about the rhetorical situation when I am writing. Although my other courses and work environments are within engineering, writing will still be involved. Whether I am writing a lab report or an email to a coworker, I need to be aware of my audience and constraints so that I can effectively communicate my ideas.

Our cover letter group made changes to the original schema for writing project 3. In the introduction paragraph, we added multiple reasons, where before there was only an option for one. We added an optional URL that could direct the audience to some additional information like a LinkedIn profile, a portfolio website, or a code repository. We made a change that allowed for text in the background paragraphs outside of “experience” elements. We made the “proposition” element in the introduction paragraph optional. We added an “interest” element in the background paragraph. We made an optional space or image file at the end of the cover letter to allow for an electronic signature.

Overall, I think that these were good changes. Allowing the applicant to have multiple reasons for applying for a position helps the audience have a better understanding of the applicant’s motives and interests. The optional URL makes it easier for the audience to quickly access additional information about the applicant. This is especially helpful because many companies request portfolio submissions. It is also common within computer engineering and computer science for companies to request applicants’ repositories of previous project work. Allowing applicants to write outside of the strictly defined elements in the background paragraph section helps their writing flow better. Often writing can be disjointed when a person is trying to fit content into different confined elements. I personally am ambivalent about making the “proposition” element in the introduction paragraph optional. While I see how making that element mandatory could cause repetitive writing, the introduction of a cover letter is usually short, and I do not think that applicants would write so much that they would include redundant information. In my opinion, the introduction of a cover letter should be concise, while the background information should make up the bulk of the writing. I agree with the decision to add an “interest” element because this could help an applicant relate to the company on a more personal level. This could make an applicant stand out to the audience. I do not think that adding an electronic signature is necessary, but that element is optional so it will not negatively affect my writing.

A variety of changes were made to the documentation of the schema’s definitions. Some rewording might have been inadvertently done, during the process of copying and pasting, however more intentional changes were made in order to make the structure of the schema more evident (Granted these changes were all made in the template file, so I do not believe a direct adaptation to the schema is possible.). The chief decision regarding documentation was to condense all necessary information to create a draft of the schema into a single document (template file). By structuring the documentation in a more consistent style, I believe I was able to make it more clear to a reader what was being asked of them in each section, and was caused by my initial displeasure with parsing together how to approach the schema by looking directly at schema documentation, in addition to referencing the template document.  Other small changes like correcting minor errors (e.g. the ‘cost’ page not appearing on the template, some incomplete definitions), or fleshing out points to make them more clear were also made.

The proposed changes to the schema are as follows :

prelim_ana – I felt the goals of this section were obscure with respect to those found in the ’sccs_crt’ section. To try and better communicate the nuanced differences, I renamed the attribute to ‘prelim_ana’ from ‘prelim_req_ana’. It was not clear to me what ‘req’ was referring to. I also added important definitional specifications that highlight the differences between these two attributes.

exec_sum – For the exec_sum page, I would add the following tags that must be written in order : background, report_purpose, approach, key_findings. These (along with their informational definitions) provide the writer with a better idea of what a representation of an executive summary should look like. This was inspired by the fact I had no experience with executive summaries, and when referencing the individual writings of group 2 and correlating them with what I found online, I found an undefined range of expositional tone setting to concisely informational.

fsb –  I changed the <fsb_hlgt> element’s ‘suits’ attribute type name to ‘lgl’. Not only do I believe that this name has a more obvious meaning to it, but it also matches the naming of the legal type attribute for the ‘cost’ page.

sscs_crt – I added four attribute types for the <req_sect> element. These were, ‘technl’, ‘tmfrm’, ‘socl’, ‘other’. I believe these attribute types lend a better understanding to the concrete demands that are being put forth, helping to distinguish its purpose from ‘prelim_ana’.

fnc : I removed the ‘exp’ type attribute from this section. It seems there is redundancy here with respect to this page and the ‘cost’ page.

conc : I removed the ‘sum’ tag. It seems to me that the conclusion section is better situated as being entirely a summary section, rather than a set of sentences toward the end of the section. This was also informed by examples I found online.

Three last structural notes, it seems that it would make more sense in the genre if only one of each page type were allowed per page; secondly, the ’n’ tag specified in sections other than ’tbl_contents’ don’t seem to have much importance, and I believe can be removed without jeopardizing the genre model; thirdly, I found the enforced ordering of the pages to seem somewhat arbitrary. It seems the fastest way to be informed on the correct order by generating errors by placing pages in the incorrect order. Although changes could be made so that the schema more directly represents the genre, I do not believe that either change would greatly have changed my writing process.

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.

Overall, this schema was fairly easy to follow and work with. As expected, there were a few details that we encountered along the way that made the schema somewhat difficult to use. Many issues that we had rooted from lack of documentation or redundancies in the element definitions. Under the approach section, we found that the definitions for “execution” and “action” were so similar that we thought it might streamline the mark up to just eliminate these two attributes and leave the text under the “approach” heading. There were also a few places where it was difficult to identify what sub-elements or attributes were mandatory or optional. We noticed this when we were trying to write in our “scope” under the “purpose” section. We felt that “who” “what” and “when” should have been mandatory attributes (and the rest optional) in order to give an informative scope of the proposal. It also would help clearly define what a scope is and what information it should include.  

A minor bug we encountered was that the template model required a type=”___” attribute following approach and feasibility. However, when we defined these sections accordingly, it returned an invalid statement. As we discovered through the examples from the original group, approach and feasibility do not have a type=”__” attributes, but are instead defined within the paragraph itself as subelement. The change to the schema should reflect this difference in how the sections are defined.

One element that could potentially be added to the schema would be a global reference element. There is already a bibliography, so it would be useful to denote where each reference is used within the proposal. The <ref> would have an “author” attribute which would contain the author of the source in the bibliography it is that you are referencing. Another addition to the schema could be a “legal” and “other” subelement in the feasibility section in addition to the economic, social, and environmental elements. Therefore, the user of the schema would not just be limited to the three feasibility subelements already defined.

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.

The schema of the edutainment blog proved difficult for me to use in my writing process. Do to the lack of required elements built into the schema, I was often unsure of what I should include in each section of the blog post. I began writing my post within XML and composed my entire first draft in that manner, leaving many errors in the document unaddressed at the time. I was more focuses on determining the specific content that I wanted to discuss in the post, and did not really focus on what elements in the schema each part of the blog best represented.

I didn’t find the schema constraining, but I felt very unsure about how to use it most effectively. I was surprised when errors started popping up as I did not believe certain elements were required in each section. I have since gone back and am working to address those issues. I have since decided to write my post in a word document to decide how I want to organize it and will then work to incorporate it into the existing schema. I believe that writing it this way will allow my post to have better flow and determine which scientific information is necessary to include.

Reading my peer’s post and his peer review of my own work really helped me determine what I needed to do to improve my own blog entry. Leo first determined what content he wanted to include in his post and I realized I should have created an outline outside of XML, to determine how in depth I wanted to discuss the mechanics of solar panels. I also have yet to find visuals to go alongside my explanations and know I need to include them in my final draft.

I think the schema could be made clearer by listing what elements are required in each section, and those that are optional. Using a schema I did help develop proved much more difficult as I did not have a great understanding of the specific elements in the schema. I was unsure how the schema should be constructed and how the optional elements in the background and answer sections were usually arranged. I think a more careful study of the schema before I started writing would have been very helpful to me in my writing process, instead of doing it in the reverse order.

• List required elements under each section/add a place within the schema to make it clearer.
• add clearer definitions to each of the optional element to help the writers understand how they are typically used and in what order

For writing project 3, I decided to write a letter to a company I found on the Northeastern coop listing website. Overall I never felt too constrained by the schema, since it did a good job of differentiating sections that were more static versus sections that might vary from person to person. For example, the header of a cover letter is going to be extremely similar from person to person, but the body of the letter is going to vary much more. The group that created the schema ended up using attributes to differentiate between different types of experiences (ex. school, work, etc) for some added flexibility, which I thought was useful since it also gave me ideas for what I should be putting in my cover letter. I definitely think the schema helped me stay focused while writing my cover letter, and comparing it to cover letters I’ve written previously, I do feel like I see some improvement.

While comparing my work to the cover letter my peer wrote, I did see some things they did well that I should integrate into my cover letter. They did do a much better job of going into the important details of their experiences and how they relate to the job they are currently applying to. They pointed out that in my cover letter, I mention that I worked at an finance oriented place and the job I was applying to was at a finance oriented company, but I never took advantage of that connection to show why I’d be a good candidate for the position.

As for the schema, I think it does an appropriate job of outlining what a cover letter needs to be. I’m sure there is room for small improvements with some added tags in contact information and the signature, but I think the body struck a good balance between flexibility and structure.

For writing project 3, I wrote a cover letter. I used the schema to structure the cover letter, and the different element and attribute types guided me on what to include. The schema helped me write about my past work and school experiences, and it helped me convey why I thought I was a good fit for a company. The schema was appropriate for my rhetorical situation. The situation in which you would write a cover letter is when you are responding to a job posting, and you submit a cover letter with a resume. The cover letter helps highlight certain parts of a resume and convey some skills that may not necessarily be included on a resume. I do not think that the schema was too constraining.  For the sections that included experience, I was free to write what I wanted while including relevant information like programs I know and skills I have. The schema helped me write the introduction and closing paragraphs. This was helpful because it guided my response to how the company and work mattered to me. When I read my peer’s work, he used the schema very similarly to the way I used it, so this did not cause me to think differently about the schema. Receiving feedback from my peer on my work did not change the way I looked at the schema either.

Overall, I think that the schema developed for the cover letter was very effective for writing a complete cover letter. However, I think that I would add a “social” element in the experience section. After reading my peer reviewer’s comments, I realized that I did not emphasize soft skills enough. I think that adding a “social” element would remind writers to include information about their ability to work in teams, communicate well with others, etc. I think that this schema was more flexible than the schema I wrote with my group, which was a feasibility report.

My writing processes for WP2 and WP3 felt very different. In writing project two, I used the schema to respond to my rhetorical situation; I wrote based on the sections outlined in our research. For writing project three, it felt like I trying to conform my writing to the schema. I can attribute this feeling to two different factors. First, I wrote the majority of my science blog post away from a computer, I was at a seminar and my computer makes loud clicky keyboard noises so I used a notebook. This could contribute to the fact that I didn’t have a super firm grasp on the exact structure of the document. Also, I wrote it in pieces throughout the day, leading me to have rather disjointed sections of writing that I had to fit into the schema post hoc. The other reason that I have for this feeling is that I didn’t have a hand in creating the schema. For writing project two, I had intimate knowledge of the schema because I helped create it after studying examples of the genre. Beyond the problems that I, personally, had with the schema, it definitely felt appropriate to my rhetorical situation. This feeling of appropriate-ness, is likely attributable to the fact that I chose my question with this genre in mind. However, the schema did help me write as it added some amount of structure; for example, I was forced to think about the exact scientific principles associated with my question. My use of the schema was definitely most informed by looking at examples of my peer’s work; I used the documentation somewhat, but examples were most helpful. I think that, on a documentation level, the use of the specific topic, technical principle, and important idea tags could be made more explicit. When using those three tags, among others, it was often unclear the ordering they were supposed to go in and whether or not they were required.

For Project 3, I first used the schema as an introduction to the public work proposal genre. Once I had a general feel for content, I used the schema as a list for all the components I needed to address in my proposal. I found the schema to be appropriate for my proposal in that it contained all the pertinent topics that would be addressed when petitioning for a road improvement- any further details would be semantics or pertain to a specific proposal.

One aspect of the schema that was very useful was the level of detail in each section- it made it very clear what was required. Breaking down elements such as feasibility into economic and environmental components removed guesswork as to what the content should be focused on. However, there were other sections where I felt there was a lot of overlap and had a hard time differentiating between them. For example, when addressing the who and how aspects, I felt as though I was repeating that the MassDOT were the ones in need of funding and that the project would happen if the MassDOT received funding.

Overall the biggest problem I ran into was the variance in structure between the proposals put forward by the original Group 3; there were large differences between the length and number of attributes included in each member’s proposal. This made it difficult for me to gage the importance of each section relative to others or the general length it should be.

The peer review process helped me gain a slightly better idea as to how each section should be differentiated from one another. Not having been part of the original design team for the schema made is noticeably harder to use it and understand the sections. It was mostly through examples and peer feedback that I was able to gain a more in-depth understanding of it. I would like to improve the schema through better clarifying which parties involved (who) should be mentioned in each section (receiving vs. giving party).

While writing my initial draft for writing project two, I looked at the schema to devise how I would split up all of my points throughout the proposal. The schema provided a pretty decent form of splitting up the points necessary to convince a public figure that your proposed idea should be moved onto the next steps. I don’t think that there were any moments where I found the schema felt too constraining. I think if anything, the schema could have been a little more constraining. The different elements seemed to be fairly broadly defined so there could be a lot of overlap across sections depending on how you interpreted the documentation. I think that looking at my peer’s work verified how I was using the schema. My peer’s that I reviewed used the schema in a slightly different way that I did and I felt as though reading through his verified how I utilized the schema.

My peer reviewer’s comments had a pretty big impact on how I looked at my composition. She pointed out some good examples of where my paper could have been better focused and how to better apply language based on the rhetorical situation. I feel as though the documentation could have definitely been made more specific regarding the main elements. A more clear definition of each element could have went a long way when deciding how to use the elements. I would say most of the documentation definitions could have some information added to clarify them. Using a schema that we didn’t design was definitely a little different than using the one we developed. I found that with the one I developed, I already knew what I was going to put in each section by creating the schema so I didn’t utilize it as much in writing. Since I wasn’t as familiar with the new genre and didn’t get a chance to completely analyze the genre, I more heavily relied on the schema to write the paper. Some revisions to the genre model that I would suggest are as follows. First, I would add a global reference tag so you can denote any references that you had in the bibliography. I would probably also add more clarity to the definitions in the documentation to clear up what information should be in which section.

When writing my first draft of this project, I used the major titles in the schema mainly as a checklist of things that I needed to include in my public initiative proposal. I gathered all the information that I potentially wanted to use and made a big bullet list of things that I could use to support my argument. From there it was easy to peg where all my points would best fit into the schema. It was interesting building a writing assignment around the existing schema rather than developing both a piece of writing and a schema simultaneously. I kind of kept bullet points under each of the headers and filled in more with details and sentences until I felt like I had a sufficient argument/content to satisfy the requirements of each section. However, there were definitely drawbacks to this method. I really think I put way too much information and lost focus; my plan is to go back and trim everything that is extraneous and nail down a focus for the proposal. I got distracted using the schema in my brainstorming basically. However, having the schema in front of me helped me to figure out what kind of information I needed.

The schema definitely fit the proposed rhetorical situation, however it was next to impossible to come up with a rhetorical situation that made sense for me to explore. I guess anyone could be involved in proposing ideas for a city development project, but I can’t think of any real situations in which a mechanical engineer would be involved. I have no education or background in city/land development, construction, or addressing social issues. So this was a little bit of stretch from the project prompt.

From peer reviewing with my group, I noticed that there were a few sub elements and attributes that I didn’t use correctly or didn’t realize were in the markup. Not that this would change too much about my proposal, but it would have been helpful in constraining my writing enough to have kept me more on track.

Aside from these few confusions, the schema was very well set up and easy to use. I think my whole group could have benefitted from additional documentation of all the elements and organization of the markup, but this was only an issue in a few places (like the purpose section). I couldn’t find any definitions for attributes to elements; this could have been helpful in the scope and introduction sections as well.

Overall, it felt a little more constricting using someone else’s schema because I was assuming the whole time that the schema had to be completely correct, so I had to work my writing around the schema. In project two this wasn’t the case because while I was writing my first draft for my cover letter, we were still making changes to the mark up, so if I noticed something that made writing our cover letters difficult, we could just adjust the schema instead of adjusting what we were writing.

I used the schema as a guide that I won’t miss anything in the cover letter. Also, I didn’t develop the schema, thus, I need it as a guide but to find out what does it need as well. I think I used the genre in an appropriate way that I write the cover letter to apply a job that I found in NEU COOL. I feel like the schema has too many elements that I don’t know where I should put some common words like “and” to. Also, it feels hard to use some of the schema, there are some elements like and , sometimes it’s hard to make a sentence apart into those elements. However, these elements helped some time to get all the information in the cover letter. After reading the peer review, I feel like the definition of the cover letter is a little different from what I understand but it seems like making more sense to me. The cover letter is to describe things not from resume. Now I know more what I need for my cover letter. The understanding of the schema is the same between me and Tammy. Also, according to the peer review, I know that I will need to add something to show that I really want the job and my sincerity. Thus, I will need to think more about the genre.
I think the schema has been specific enough for a cover letter. I don’t think it needs any changes. I feel different to use this schema other than the schema from our group for project 2. I’m more an expert in the schema for feasibility report, but for this project, I need to do some research on the schema but still sometimes confused. I feel like it needs definition in the closing statement.

The edutainment blog offers gentle guidance for how you use it. Following the outline of numerous Section headings and technical principles, you can instantly create a good skeleton for your writing. I found myself with all of my thoughts categorized on paper quickly after completing my research.

I have to say that I definitely found the schema to be appropriate for the rhetorical situation. When we look at just the schema, it narrowed my focus to (like I mentioned above) finding technical principles I could focus my thoughts behind. This also had the unexpected side effect of forcing me to ditch what I didn’t need. I started with 12 section headers and I ended with 5. Not because the other seven were not important, but because they didn’t fit for the desired audience. It forced me to only keep what was truly important, instead of trying to be too inclusive.

Looking beyond just the schema, I think that the edutainment genre lends itself well to such a technical topic, mostly because those well versed in anything cyber likely are reading much more in-depth work. The friendly and open nature of genre lends itself to its uptake, educating the uninformed.

At first I thought that the schema would benefit from more specific elements within a technical principle, but after completing my first draft I can definitely see that this would be a hindrance. Otherwise I really like the genre and the schema, maybe after completing project three I will have more criticism, but as of now I have none.

Using a schema I did not design was surprising not that different. I found I quickly understand why certain elements and attributes are designed the way they are. I can definitely see someone getting frustrated with the genre I worked on, the feasibility study, because of how restrictive it may seem.

The schema was helpful to my writing. The cover letter was short, but seeing how the sections were organized along with the samples helped me sort my thoughts. It was appropriate for the rhetorical situation.

The last sentence of my first paragraph may not fit in the <proposition> tag. I wanted to emphasize my enthusiasm in joining the company rather than saying that I have the necessary skills since I felt that that’s explained throughout.

I accidentally excluded certain tags (<accomplishment>, <skill>, etc.) from the schema because I had overlooked them, but inserting them after finishing my draft didn’t bother me.

I want to add a “site” attribute to the <contact_info> tag. That would help for displaying portfolios. I also would like to add an <interests> tag that works like <programs>, <accomplishments> and <skills> because that feels like an important point that doesn’t entirely fit in those three categories. Additionally, it would be nice if the <proposition> tag included something else to the description to suggest an enthused statement to join (see my mention above about this) or a separate tag with attributes of “proposition” or the other. That’s just a suggestion from when I was writing though. It may be too specific. Other than that, I noticed there’s no place for an actual signature, which is typical of cover letters.

I like this genre and schema. It was clear and nice to follow. I kept putting off writing a cover letter because it intimidated me, but I’m really glad that I got to do this. The sample one was easy to follow and work from.

Edutainment blogging was a cool genre, but it was very fuzzy and difficult to work with. My second project was heavily image based, so I had to worry a lot about display. Thus, this genre was a very nice change of pace since it was short and all text. It also targeted a narrower audience. Not authoring the schema allowed me to focus on my piece rather than on structural or display problems.

Initially when I was working on my first draft for writing project 3 I was writing directly into the XML document replacing team fours example texts with my own words. However, in doing that my statements felt disconnected and scripted. For this reason I ultimately ended up writing the majority of my intro and background paragraphs in word and then transferring it back over into XML. It was nice to have the example texts in the schema template to understand what they meant by each of the tags. I found it more useful though to use the teams presentation as a starting point for the context of my letter. I did find the schema’s overall layout to be broad enough to cover any possible rhetorical situation that would lead to the writing of a cover letter. Being able to order your background in different ways while still prompting you to include personal, academic and work related experience was quite helpful given the fact that my situation may have been slightly different than that of other people writing a cover letter. It would have been nice to be able to use the reasons tag multiple times within the background sections, but it worked out regardless by just grouping it.

Receiving my peer review was tremendously helpful as I think it gave me an idea not only of how to fix the things that I asked about but also because he pointed out things that were missing or unclear that I had not previously noticed. Overall I think that the schema was very straightforward with the example text that was included. I do think that some of the tags within elements could have been better defined, but generally plenty of labels to be sure that you included all the necessary elements.

Using another groups schema was fairly straightforward though it did not have the benefit of already knowing examples and how the schema breakdown matched those examples. Potential things to change:

• being able to include multiple reasons for things
• unsure of the purpose of the page break element when everything is already so broken up
• being able to include a space under your salutation before your typed out name to allow room for a signature
• a place for a date at the top of the document somewhere

For WP3, I found group 1’s schema to be most useful as a checklist. I walked through their example document and replaced the contents of each element with corresponding information specific to my background and goals. I found this schema to fit very well regarding personal background; however, there were areas with which it fell short. I believe a section regarding how a person views the field could be beneficial. For example, why I believe solar is important or why someone else believes the world needs computer scientists. A lot can be inferred from the things people put the most importance on in life.

The experience section of the schema was very well laid out. Between, “personal”, “work”, and “school”, one could supply information on any part of their life. I expect some people may argue that the personal section can be broken down further, as I initially thought, but I would now argue that it is not necessary and that the three existing sections are specific enough to fit most cover letters.

After reading Sam’s cover letter to SOM, I was able to see how to more smoothly depict the relationship between my background, long term goals, and how working at the proposed company would eventually play into that.

Using another group’s schema was not too different from using my own. When using a schema that I helped to put together, I had unique insight into certain elements regardless of their definition. I can see how in a complex schema with similar, more specific elements, one may find advantages to having provided input into the schema construction, however, the cover letter elements are very well laid out and clearly defined to the point where I do not notice any hindrances associated with not having helped design this schema.

In order to revise this genre model, I may want to bring up the topic of field importance. The ability to show passion and a drive for your work stems from seeing the importance of the work the company does as a whole.

As I was finishing WP2 I had the realization that it hadn’t been the schema that drove my writing process, but the writing process that drove the schema. I believe this was understandable for the first portion of the writing assignment — at which point we were evaluating our schema and making changes in accordance with how an example of the genre might look — however during the rewrite phase I think it might have been more appropriate for me to consider other approaches to my structure.

While I’m not immediately convinced that there exists an obvious way in which to improve my approach in relation to our final schema, this thought was highlighted during my final round of edits. I found that the changes we made for the ‘specific_topic’ and ‘explanation’ tags caused slight issues due to their ordering requirements with respect to the ‘technical_principle’ tag. Due to list type nature of my ‘answer’ section, the ‘answer’ section does not flow in a natural way, but it is intentionally divided therefore making the section feel less “spacious” than if I were to have it undivided. It felt natural that each of the topics within the list deserved their own ‘specific_topic’, however this necessitated that I find a way to include ‘technical_detail’ in a limited amount of space before the start of the ‘specific_topic’ list.

Although I wouldn’t claim that I actively sought out and applied analysis tools brought forth during the required readings, if there were one that might apply to my approach it would be the discourse community. The nature of blogs puts the community appeal, tone and discourse in the front seat, making you very aware of your audience while writing the blog.

In conjunction with the class material, I felt the group project offered a very useful mechanism for developing an understanding of the genre. While there were benefits of collaborative group effort in dividing workload to cover many different sources from a variety of mediums — the chief source of understanding for myself derived from a sense of added responsibility when working within a group. I find I’m much more comfortable with letting myself down than letting others down, and a consequence of this is that in group projects I do my best to be checked in and contributing at all times.

I really appreciated how open the prompt for the assignment was. By allowing us to choose a topic of interest, I found myself much more engaged in the material. Twofold, it allowed me to choose topics that I felt would benefit me outside of the class, increasing my investment in not only the structure and details of rhetoric, but in the substance as well.

If I *had* to change any part of this project, I think I might integrate the points made in the readings into our individual write ups. This could be something like a section of XML common in all projects covering topics, like <discourse_community>, <audience>, etc. These topics are covered in the design entries as well, however a direct analysis of our specific projects would be helpful in cementing the ideas.

I used the schema as a guide. All the elements not only are the structure of the genre but also a reminder of the information that I need to provide for a feasibility report. I didn’t have enough experience of this genre but I’m an expert of it now. I didn’t have any difficulties on the syntax of XML, but I had a little trouble in using “lvl” and “n”. After several tries and reading other group member’s XML, I figured out how to use these attributes to organize and beautify my feasibility report. The “Uptake” article was helpful so that I know my genre’s desired uptake genre and the genre will uptake from. Group’s research helps a lot since we have Seth who had experienced with this genre already and easy to get examples and interviews. The decision of the genre was quick and we had our team design entry ready pretty soon with Seth’s resources. We had everything decided fast as we communicated well to get everything done. I didn’t feel any difficult working with our group. In fact, all of our group members are very easy to work with. It will be hard and lack of time if we don’t have the group to do the research together. The design of this assignment is good since we have two parts, one is the group one is individual. I like the way of all the assignments in this class which is a kind of different from my other classes. After this project, I know the genre of our group and I know other group’s genre as well from their presentations. I’m also looking forward to the next project.

Overall, the schema figure we create helped guide me in my writing process. In the case of our genre of Edutainment blogging, we made sure to make the schema flexible, so it could fit the format of different types of blogs we looked at. I feel like the schema did help give me a guide on where I should put different thoughts I had and wanted to explain. I feel like if I didn’t have the schema, my explanation would have been more scattered and less intuitive, but with the schema I feel like it flows and seems more of a natural progression.

From a technical perspective, XML is a new type of markup language to me, and so there was a small learning curve. The most difficult part was using Oxygen to write the content of my blog post. It has really useful autocomplete features and auto formatting, but I ended up making the decision to write the blog post in a word processor I was comfortable with, with the schema in mind, and then adding the tags in Oxygen.

For building the schema, I definitely thought the group work was critical. It was useful to individually research blogs, and then see other group members opinions on blogs they looked at. Discussing which aspects of the blogs to add to the schema and where to put different tags was useful in creating a flexible, but accurate structure we could use for the project. In the end, I think we did a good job in building a final schema. Looking at our groups blog posts, you can clearly make out vague structural components, but you can also recognize our individual styles in the individual composition. This is something we observed while researching different blogs, and we tried to preserve this feature while building our schema.

For Project 2, the schema my group generated was a useful framework for how to structure my cover letter. It was very helpful in terms of defining the material that should be included in each section. It effectively served as a checklist for each step of the writing process. While it was very helpful for content, it was not quite as helpful for relation between content; it was very easy to satisfy the conditions of each element but by zooming in on each section individually, but creating a flow between sections was sometimes lost by using the XML processor. For example, I could list examples of experience from work, school, and my personal life in the correct order, but by focusing on each as an individual element, I would overlook the relation between each one and adding smooth transitions between them.

Overall, I think the group work was the most useful in terms of developing skills; it was in the groups that all the major writing analysis took place. The individual work was mostly based on following the schema and creating a product based on all of the experience we gained while in groups. I believe that creating the schema went very well for my group, while the individual composition was more challenging in that it had a very broad application and our schema allowed for many elements to or not be included. If I could change one thing about the assignment it would be an increase in peer review for both the schema and our individual compositions.

For writing project 2, my group chose a feasibility report as our genre. The schema was very useful for my writing process. Our schema was very structured, and it contained all of the necessary elements of a feasibility report. I think that the schema helped me write the feasibility report because it reminded me what types of information I needed to include. Since a feasibility report is very factual and technical, I did not feel like the structured schema limited my writing (unlike the annotated bibliography in project 1). I do not think that writing in xml was difficult for this project since all of my writing clearly fit into the different elements of the schema. However, I think it can be difficult for less technical writing when I want my ideas and sentences to be less fragmented and simple. The most helpful reading for project 2 was Seth’s feasibility report that he had written in a previous class. It was useful because it was short enough to identify its different elements, but complex enough to get a general understanding of a feasibility report. The group work was helpful for understanding writing since we all had to research the genre and combine our ideas into a broader, more coherent schema. I think that our group developed a comprehensive schema, and I think that I was able to successfully use it to create a complete feasibility report. I think that some of the research for my individual project (the feasibility of one company’s solar roadway panels) was difficult because there were not too many articles about the technical features of the panels.

Primarily, I appreciated having the schema for my individual writing for project 2 because it kept me focused and kept my whatever I was writing more relevant to my topic. I didn’t have a place to include tangential information, so I had less of it. That is something that I always struggle with when I write letters or assignments. I relied heavily on the schema and it kept me from having to think too hard about what I wanted to include in my letter and how I wanted it to flow; that work was already done for me. So all I had to focus on was what content I wanted to include and how my language was going to flow.

My only gripe with writing in XML is the lack of formatting. I understand why it is the way that it is, but its difficult to write in Oxygen and then all your text goes off the page because every line is so long. So I’m constantly hitting Ctrl+Shift+P and that got kind of annoying. I ended up making all my edits in my second draft in a word doc and then copying and pasting it into my XML. This is what I would have done for the first draft too, except I wanted to have the schema laid out in front of me to make sure that I was utilizing it.

Our genre was difficult to nail down to a specific format. It was evident through our research that a lot of people felt very strongly about how cover letters should and shouldn’t be. There were a lot of cases where reputable resources disagreed with something about how a cover letter should be. We tried to rely most heavily on feedback from our co-op advisors because we trust their experience the most. All the readings that they trusted and used in their classes and all the feedback they gave us from asking them questions was particularly helpful in nailing down what we wanted our schema to be.

I think that discussing things in our group made me realize just how different people can understand a certain piece of writing. I thought I knew most of the conventions of a cover letter before this. I thought most of our research was going to be focused on smaller details of it that make the difference between a good and a bad cover letter. There was one day when we split up our resources and each did our own research and talked about it the next day. I realized that what I understood from our research was completely different than what my team understood from our research. All our examples were relatively similar, but we took completely different things from them. It forced me think in a way that I wouldn’t normally in order to understand where my group mates were coming from.

I think our schema came out quite well. I think that we left it vague enough that it is not restrictive, but specific enough that it isn’t confusing. It was difficult, again, agreeing between our group because when we put together our schema the first time, I thought we were all on the same page. Then when we all made our first drafts, we didn’t really implement the schema in the same way as each other, so obviously we weren’t on the same page. It was difficult hashing out these differences, but I think it made our schema more understandable to a third party. If I could, I would have tried to find a way to add like a ‘preparation’ section to our schema. This wouldn’t be anything for the cover letter, but more of a way for the writer to organize their thoughts and goals for the cover letter. I think it is important for any writer to specify key requirements or values called out in a job listing that they are writing a cover letter in response to. I don’t know what XML’s limitations are, but it would be cool if we could have the reader call out skills from the job listing and then require at least half those skills to be repeated in the “experience” paragraphs in the cover letter.

My writing project two genre was a feasibility report. I think that our schema worked pretty decently in guiding how to write our report. Our schema mostly guided the report structurally versus rhetorically, however. So the schema easily separated the report into different sections but didn’t guide us as to the content and language. I felt as though reading through our documentation helped more with the rhetorical features. I believe that we definitely could have added some elements that defined more rhetorical features in the feasibility section and the executive summary. I found that the most useful part of developing my understanding of the writing was creating the schema as a group. Breaking down the genre as a group and creating the schema ourselves was the most helpful as it really allowed us to dig deeper into the genre to understand all of the working parts.

During the project, a major problem that I found was our relatively large size of the report. Had we stuck to the 750 word count maximum, it would have been easier to analyze the text. More rhetorical features could have been identified and added as elements instead of structural elements. If I could change something about the assignment, I might have split the project up into a little smaller groups. We had five people in our group and that was a little bit too much. It was hard for everyone to contribute an equal amount when creating the schema, design entry, and presentation. Less people in the group may have allowed everyone to speak their mind easier.

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 schema has been almost completely helpful.  It has helped keep me on track in my writing.  It also serves as a good checklist on what to include.  The only annoying thing about XML was that the oxygen editor doesn’t deal with implied line breaks the way I would like it to, so I need to manually insert them so I don’t end up with 400 character lines in my document.  I found group work was more helpful as we could each use our strengths to help others with their weaknesses.  For example I had strengths with XML and weaknesses with the design entry.  I feel like I met my deadlines better on this schedule.   Choosing the exact rhetorical situation to use the model on was the hardest part.  There weren’t many Co-Op jobs on the Northeastern site yet and I ended up going with something I found on LinkedIn that I wasn’t particularly interested in.

Edutainment blogging was a fun genre, but it was also very painful to write. I found myself going over the limit since I had to find a way to break down the material in a way that was entertaining without taking away from the content. Additionally, making visuals took longer than expected. I ended up excluding some parts because putting it all together was a lot of work. It’s a little upsetting since I was planning to incorporate gifs on the steps to make the algorithms easier to follow. Instead, what you see is a really long post with separate visuals for the steps (at least the main ones). It was also hard to style. Lists in lists didn’t auto indent, so I ended up adding some hyphens to let readers see what were sublists. Another problem was that I ended up mixing in the HTML <hr> tag, but it didn’t render that way. That’s fine, but having to manage these small bumps takes time away from writing the actual content. XML was difficult to work with for this project since I used a lot of visuals. It doesn’t make as much sense to read the XML version since the pictures are integral to the whole piece. It probably would have been better if I separated my post into different parts, but I really wanted to research something new. Overall, it was a cool genre to explore, but I think it’ll be more effective to target a more specific topic and audience next time.

The schema figured very prominently in my writing process as I used it as a guide for planning the outline of my public initiative proposal. I used the element definitions to decide which content was appropriate in each section and they helped me understand how each section related to the others. The schema was an asset for this writing project but I did not feel that differently when using it to write my proposal.  I have written experiment proposals for my other classes so I was fairly comfortable with the genre, using the schema as a guide.

The most difficult aspects of XML have to do with the formatting for me. I find it takes some time getting used to the formatting system and I had to frequently go back to look at examples of how to insert citations and other information in the document. I found the definitions of the elements extremely helpful in my writing process. While our group tried to define each element in the schema, it really made made me think about each section of a proposal and about what content should be included in it. Determining the difference between and objective and a goal, or subject history and the current conditions gave me a much better understanding of a genre I thought I already understood very well.

I believe I broke up the content of my proposal well and that each section in the document serves a specific purpose. However, I did struggle with the length of the proposal as they are typically much larger than the 1000 word requirement from this project. I tried to reduce or summarize certain sections of this proposal and I was often unsure about which information to include and which to omit. It was an interesting editing process that really made me think about my word choice and forced me to get to my point quickly, using concise sentences. I think the assignment allowed me to analyze the genre very thoroughly and I have a much better understanding of both XML and the public initiative proposal than I had before.

During the composition of Writing Project 2, the schema that we designed was integral in informing what I wrote. Obviously a major factor was the idea (distributed weather sensors) that I wrote about, but when it came to me sitting at my computer, the schema told me what to write. To this end, the schema was incredibly useful; if I had no schema (it served as an outline) I would have no real idea how to write the report.

In terms of writing XML, I don’t feel hindered by it even a little bit. I write code for fun and for class, and XML is, from my point of view, just a really lightweight programming language. Sometimes adhering directly to the schema can be taxing, but Oxygen makes it easy to correct any errors.

Seth, for a class, wrote a feasibility report which he provided to us. Throughout the composition of my report, I used Seth’s almost as a template for both structure and content.

Both aspects, group and individual, helped with my understanding in different ways. In the group work, my teammates provided insights on the creation of the schema that I may, individually, not have seen, or at least taken longer to seen. This distribution of brain power helped expedite the process of schema creation and, in my opinion, made a schema more representative of the actual genre. On the other hand, individual work aided my comprehension as, in creating the work, I gained my own insights on the genre.

Ruminating on the assignment, I feel that something that went well for me was my group-mates. I felt that we worked well together. I also think that I, not to toot my own horn, came up with a fairly substantial idea that I could flesh out in my individual composition.

For this project, unlike with project one, I used the schema as a direct input for each draft of my writing. I filled each contextual section in with information piece by piece and then chose to read back over the piece as a whole to make sure that the document made sense as a whole as well. I felt that the schema that my group wrote together was a great representation of a very basic and overly generalized proposal. We left each of the sections broad enough in description that people could chose to take it wherever they wanted while still maintaining a logical flow. For my particular project I did not feel that this was quite as helpful as it could have been. Because there was a lot of disagreement certain sections were left out of the schema overall rather than making them possible optional sections which I would have liked to use. However, the format of our schema template was very straightforward and easy to use. The reading for me that I think helped the most with our genre analysis was the Spinuzzi article on ways to examine different assemblages of text. Being able to group different view points on genre situations was helpful because it helped me to fully grasp the complexity of the genre we were working in. Working with the group to create the schema and bring examples together for analysis was hugely beneficial. However, when writing the team design entry we had a difficult time making sure that all of our ideas were included and that the sections flowed together nicely. For this reason I think that maybe writing those individually and simply discussing them would have been more helpful. Overall I felt that this project was very manageable and was a useful topic to learn. The only thing I would change is maybe having a simpler explanation of each of the milestones that we were scheduled to meet prior to the start of the project. There were some times that I was just focused on the current step cause I wasn’t sure exactly what was coming next and having that more holistic understanding might have helped to get a better grasp on the project earlier on rather than just at the end. 

For the individual composition of WP2, I felt that my group’s schema helped to structure my argument. There are many more points that could have been addressed so the only hindrance I found was in the simplistic nature of public initiative proposals.

Writing in XML took some getting used to but now it is pretty simple to follow a schema in word and insert the appropriate sections into XML upon completion. This makes editing your work a little more complicated but not to an extreme degree.

I thought that the group research we did was very effective. One of the most important questions we would ask ourselves when dealing with the persuasive nature of a proposal was “What is the intended uptake?” or “What is this the uptake to?” I think these two questions helped us make a relatively linear guideline.

I think my group worked well together. The class time we were able to dedicate to this project was very helpful, especially when frequent syncs to the website were needed to check the formatted version of a file. I would not change how this project was laid out. The end of WP2 transitions very well into WP3.

During the presentation for the feasibility report, Seth mentioned that the topic of feasibility reports was one which one of his computer science professors regular brought up. Due to my own interest in the computer science field, and probably party due to being a victim of ‘imposter syndrome’, this comment marked the moment when I decided it is high time Oliver Scott gains some experience with feasibility reports. Although the cover letter is another genre that I would undoubtedly find myself replicating outside of class, I believe this is a genre with a large number of samples on the internet, and one that I feel I have somewhat of an understanding of already.

Feasibility reports, as the name suggests, are a vital topic for those working in the technical professions — especially those which are project based. During my co-op experience working at a tech startup, the rate at which the management team drops old projects and seeks out new ones provides the perfect scenario for feasibility reports. Being able to understand what is required to complete a project, and forecast the relevant details on how to complete it is vital before embarking on a new project. I see the scenario going as such: 1. Manager notifies me of a design goal being considered. 2. Research the design goal. 3. Report back to the manager with my feasibility report.

Reading the template file not only conveys what the feasibility report is, and the structure of it, but in this particular instance it is also clear that the group in question kept in mind a high priority for strict organization and modularity in their schema.

It wasn’t clear to me from the template file how various attributes would be applied for certain sections (for example, ‘rss’ in ‘pre_req_ana’) however it seems that there is documentation within the class schema file, so with that in mind I don’t believe I should run into any issues.

The tone is informed and professional for the feasibility reports I skimmed. I don’t believe this will be too difficult to replicate, however I will need to do some research in determining how to approximate the timeline for the project.

The Edutainment blog post was the most interesting genre to me as it combines humor and science in a very unique way. I have read a fair amount of these blog posts throughout my time at Northeastern on topics related to my major of chemical engineering and others. This genre would be useful to me as I often have trouble explaining what my those in my field do to my family and friends. While I was on co-op, my younger brother frequently asked the question “So what do you actually do again?.” I had explained that I was working on process validation studies several times now, but couldn’t articulate my job description well enough in colloquial terms for him to understand my responsibilities. The edutainment style of a response specializes explaining complex scientific subjects to the average person without an extensive background. If I were to master the skills of this genre, I would have a much easier time explaining to my friends what chemical engineers typically do in their fields.

I doubt I would ever use an edutainment style post in my remaining academic career as most of my classes would require a more formal genre to summarize the projects I am apart of, but I could utilize it later in my professional career. If at my future job I was ever asked to do an interview with a journalist or news station I would want to utilize some elements of the edutainment genre to make the subject more entertaining and accessible for the average viewer. My goal would likely be to spark interest in whatever I was working on and a formal report analyzing the results in a very technical manner would not inspire any curiosity in the average person. By making the subject fun and using analogies to describe the science going on, it may generate the uptake of the audience (the general public) to do some more research into the subject or inspire a younger generation to choose a scientific field of study.

From the schema template, I learned that the genre of an edutainment is not very rigid and is designed to be flexible to suit the writing style of any particular author. The edutainment post also relies heavily on the use of graphics and other visuals to break up the text and present information in another way to the reader. It is somewhat unclear to me how long these edutainment posts tend to be. I have seen many that vary in length from a few cartoons being used to explain a scientific fact to a long article broken up with various images.

The tone of my classmates’ edutainment posts are informal and humorous. They make the subject matter interesting by not using a serious tone throughout the work and the use of graphics made it easier to stay interested in the subject. To complete my own version of this genre I will first need to determine if I will have time to do so, as the edutainment post seems like it could take a significant amount of time to do properly. However, if I find a subject that I am comfortable with, I believe I will be able to draft a decent edutainment post without too much trouble. The largest issue will be finding cartoons/images that go along with the subject well, as I do not have the time or the artistic talent to create them myself.

Any of the three other genres would be helpful to me. The cover letter is appealing because I’m graduating next year, and I need to start applying to jobs for then (also it would be a nice change from how long the blog post takes.). But I’m also interested in the proposal. I’ve been framing my writing around my interests in game development, so it’d be cool to come up with a proposal of how we can integrate them in school. There’s a lot of thought that goes into the idea though. Games are fun when we willingly play them but introducing them in a forced way might destroy their effectiveness. I won’t have enough time to research that topic in depth for this project, but I’ll keep it in mind for the next few days.

The feasibility report would also be good to review. My capstone team and I constructed a bit of one for our project. I’m not too interested in creating one right now for any personal projects though since creating a project proposal would be more beneficial starting out.

I’ll dissect the cover letter for now. The schema for it is stricter than my team’s edutainment blogging. Almost every line is given a tag, and it has a clear start and end. How I see myself writing this following this outline is by opening with the company and position that I’m interested in applying to. Then, I explain why I am interested and why I would be a good fit broadly. That ends the introduction. Next, I move into the main section where I go in depth with my experience relating to the position. This can be work experience or my education. Finally, I close reiterating my strong points (not necessarily experience but working style whether in groups or individually) and thank them. Following that is the salutation. Overall, I like the structure and will probably be reviewing this genre.

For the third and final project, I will have the option of doing a feasibility report, proposal, or edutainment article/blog. Being in engineering, all 3 options are viable papers that I may write at some point in my career. However, I believe the proposal would be the most useful schema for me to work on since a lot of the work I will be doing will be in mechanical contracting.

It is very possible that I will have to market my ideas or market my brand’s work over that of other companies. For example, if a contractor sends out a request asking for an HVAC system, it could my job to talk about all the direct and indirect benefits of a system my company could provide. The audience would be the building contractors and engineers who decide which company presents the best product at the most competitive price. My proposal would be written with the intent of being selected for the job and earning my company new revenue.

The schema could teach me the elemental breakdown of a proposal and how to best distribute information. An interesting point I learned in class was that many proposals talk about all the indirect benefits of their project rather than the actual project itself. (i.e. all the town benefits from redoing the roads in the center of town.) To write the proposal, I would need to research both my project of interest and any benefits/impacts it can have on seemingly unrelated topics.

I think two of the genres would be interesting to me, the cover letter and the the project proposal. The cover letter has the most obvious usefulness of the two. While applying to jobs, most will require a cover letter as a part of the application process, so it would be useful to know how to write a cover letter. The project proposal would also be fairly useful, as I may have some idea that I would want to pitch publicly.

As I said before, a cover letter could be an appropriate response to a rhetorical situation in my future. The situation would be applying for a job. Somewhere in the application, it would ask for a cover letter and I would need to provide one in order to be considered for the job. The audience is likely the HR department and the rest of the hiring team that may read it. The desired uptake would be that the audience would have a quick overview of my accomplishments and my relevant skills to the position that I’m applying for.

From the schema/template file, I get a pretty clear idea of how a cover letter is set up. It will be in three different sections generally, with introduction, background, and closing paragraphs.  The only thing that may be unclear to me is if all cover letters follow the same format for all majors and experience levels. I’m not sure if an engineer with no background will have a similar cover letter to a liberal arts major with twenty years of experience. From reading examples composed by the group, they all seem very similar in structure. The writing style makes the authors seem eager to get in further contact with the company. On my own, I would have to read a lot more examples of cover letters. Although they are all similar in structure, the word choice may be different throughout examples, so it would be good to read a variety of cover letters from many different fields.

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.

I think that the cover letter genre is interesting. In the future, this would be useful to me when applying for coops or jobs. This job application process would be a rhetorical situation where creating a cover letter would be an appropriate response. The situation would be responding to a job posting. The audience would be the company’s hiring manager and possibly other engineers. I would want the cover letter to effectively convey my desire and qualifications to work with a company so that they would be interested in giving me an interview.

The schema looks like it offers flexibility to highlight the writer’s qualifications. There is an introduction where the writer can explain why he or she is writing the cover letter. A background section lets the writer detail important experiences that a resume may not clearly show. Finally there is a closing paragraph where the writer can explain why he or she is a good fit for the company and detail what next steps can be taken. The style is unique to each student, but the tone is always professional. All of the examples devote most of the cover letter to relevant work experience. To compose my own version, I will need to look online for more cover letter examples.

While listening to the other teams present their genre, the one I’m leaning toward using for project 3 is the cover letter. Out of the three genres, I feel like cover letters are the most relatable to me at this stage in my life. I’m at a point where I’m going to be applying to jobs or internships, so I’d imagine I’m going to have to write a few cover letters. I’m hoping that I can improve the structure of my cover letters to help convince employers to hire me. Previously when writing cover letters, I really had no idea what to write. I just wrote the first things that came to mind, and the result seemed unstructured and unorganized. I’m hoping that having the XML schema as a structure will help guide me, and I’ll be able to reproduce new cover letters when it comes time to apply to jobs.

Looking at the individual compositions created by the cover letter team, the overall structure of cover letters seems pretty rigid. There is a portion for contact information, greeting, body and closing remark, and the body is further broken down into sections. The overall tone of the letter is formal, which is expected since this is supposed to be a professional letter. From a content perspective, I noticed a majority of the letter talks about the qualifications of the applicant. It talks about the applicants previous experience in the field, and how it can be applied to the position they are applying to. Personally, I feel like this is an area I could improve on in my personal cover letters. I did include information about myself, but I was hesitant to repeat information that was already on my resume. My cover letters ended up having a decent chunk where I talked about the company itself, and why it was interested in it, but I feel like I could reduce that a little bit and include more about why I would be a good fit in the company.

After the presentation, I’m thinking to choose the genre of cover letter from group 4. A cover letter is useful for everyone when seeking a job. I will graduate in 2017 May which means I will need to know how to write a cover letter after that. We don’t need a cover letter for any Co-op jobs but I will need this for the job seeking after the graduation. The audience of a cover letter is the job interviewer. They need reading the cover letter and resume to decide whether need me to have an interview. The genre that I will need to uptake from is the job description. From the schema, I can know the structure of a cover letter and it’s very useful to give all the information organized. The schema template file is clear and I think I will do a little research on presenting the academic knowledge such as computer programming language. The example is clear since we are all technical majors which have similar requirements.

The genre model that jumps out to me as interesting is the science blog genre. I find it interesting because I have read many compositions in this genre; it would also be a way to expand my writing repertoire as I have never written anything like it before. Of the genres presented by my classmates, I would reckon that the least likely genre that I would write is the science blog post. In my uninformed opinion I have an equally likely chance of writing any of the other three, through I would put a slight bias towards writing a cover letter. The possible situations for writing one of these exist in both my professional and academic life, also feasibility reports (my group’s genre) and project proposals are very similar, increasing my chances of writing one. Audiences for any of the three are current or potential employers, with cover letters generally being reserved for the potential variety.

Writing this entry with the opinion that I will be writing a science blog post for my writing project 3, I shall observe its template file. From the template file I gain an understanding of the structure and intended contents of the blog post. In the beginning, the question is presented, the scientific principles are laid out, and it is good. Following the beginning, the answer is elaborated on, more scientific principles are shown. This, it turns out is the end of the piece. Throughout the composition, various elements, e.g., visual elements, analogies, are given. Having read upwards of 150 of these posts, I really have no questions about them, and the schema is quite clear. Based on the examples given by my peers, these “blog posts” are meant to bring levity to an otherwise serious or bland topic. In order to manifest an example of this genre, I will have to research a question that I want to answer, which I will then have to create a response to (in the form of a blog post).

I found each presentation for WP2 to have its own areas that were unique and interesting. However, I thought that a feasibility report almost had too much in common with my group’s focus of public initiative proposals. Group 1 was, in my opinion, the most unique subject with little in common with the other three groups.

Group 4’s focus of a Cover Page stood out to me the most. As I will be graduating in under a year, I need to start to compose cover letters for some of the jobs I plan to apply to. My top choice of BlueWave Capital requires all applicants to submit a cover page with their resume and I think this class would be a good environment to put together a first draft. I will also be submitting my resume to some other solar developers that I think may be a better audience for this exercise considering I do not have previous experience with them. The intended uptake to these letters would be offers to come in for an interview.

In order to compose my own cover letter I would need to do research into the specific company’s mission statement and address the ways in which my skills are compatible with their goals. I think this will go well with the relatively professional tone found in group 4’s cover letters.

The genre that most interests me is group 4’s cover letter analysis. I think that this genre would be an incredibly useful one to study now considering we will all be applying within the next few months to either new co-ops, summer internships, or future full time jobs for after we graduate. I personally, am in the process of applying for my dream summer internship and have been asked to provide a very open ended cover letter stating my interests and company specific goals. For this reason, I think that doing a cover letter for my third writing project would be very helpful for myself to get started on the letter and be able to analyze deeper different styles or types of information that may be included in a good one.

Cover letters are a commonly requested item when job openings are posted by companies. The audience would be all those people looking for that type of job. The desired uptake would be that the author would receive an interview opportunity to further discuss the job and their qualifications. The schema/template file is very concise yet covers all of the possible subjects that your cover letter should touch on. The files are written in a very professional manner and have a predetermined structure. Additional research on my behalf would mostly involve looking into the differences between letters for internships as opposed to full time positions if there is any as well as research into a company of interest to properly enter the desired situation.

Truthfully, I think that an Edutainment blog would be the most fun and interesting piece of writing to develop for project 3. That being said, I haven’t been able to think of a topic over the last few days that I think I know well enough to write a really cool edutainment blog about. If I get inspired in the next day or two though, I might try to explore that idea a little more.

This being said, a lot of what drove me to go to school for engineering was the thought that I’d be able to make a solid impact in my community. My hope was that somehow my community would be able to benefit from my education since I have so many people from my community to thank for helping me to receive my education. Right now, Worcester is overhauling all the ugly parts of town and putting a lot of money and effort into community development. There are a lot of requests for proposals (RFPs) on the city website that have to do with neighborhood development, repairs of old broken structures, renovations to schools, etc. It’s really cool to see the progress that is being made, and think about how much the city has changed in my memory. I looked through a bunch of RFPs,but there were a lot of them that were engineering related that were just way over my head still, but there was one called the “Community Development Block Grant Program” (CDBG Program) which asks for any proposals for how to spend a $3.8 million annual federal grant the city receives. They have some very vague guidelines for what they want to accomplish (minimize slums, meet an urgent city need, serve low- moderate income persons, etc.) and the rest is fairly open.

It has always bothered my how much space in Worcester is just taken up by old factory buildings and ugly junk yards. It’s mostly just a waste of space and makes the city look a lot more run down and poor than it actually is. I cross referenced this with some of the (very) many RFPs for city development in Boston to see what kind of stuff might fit into this CDBG RFP and got a lot of ideas for things people might want to do with empty lots in developing neighborhoods. Boston has really tight guidelines for what they are willing to build and what proposals they won’t even look at. I hope to use these Boston proposals to help me develop a public initiative proposal in response to the Worcester CDBG request.

I also think that this kind of proposal will fit in well with the schema that group 3 put together during project 2. They focused their proposal format on city development, since those were the best examples they found. I also think that their schema is very straight forward considering that proposals need to flow well and the format is fairly predictable. My only confusion, now that I’ve looked at examples of how they have used their schema, is what parts of the schema are required and whats optional? It seems like some of the examples leave empty elements in the schema, and I’m not sure that is just because it’s not totally finished or if the empty elements just aren’t required.

To develop this for project 3, I’d need to decide on what kind of actual development I’d like to see in these ‘wasted spaces’ in Worcester, be it a park, community center, commercial building, etc. It also might help to pick a particular space that could be redeveloped. This whole time I’ve been brainstorming I’ve been picturing some old abandoned factories that are in the residential areas near Union Station and WPI (downtown Worcester) but I’m sure there are other neighborhoods that I’m sure could use similar development that might work better for this project.

I’m concerned about not being able to either (a) do the proposal justice and actually put a good amount of content in it, or (b) spending way too much time and making a project that is way longer than it should be for project 3.

Design Entry 9: Reflecting on WP2 (in-class; no word count)

In this entry, please take some time to reflect on the second writing project of the course. I’d like you to focus on the relation between your research, the schema, your understanding of the genre, and your individual composition.

Below are some questions to generate reflection. As always, feel free to address any or all of them:

• How did the schema figure in your writing process (how did you use it)?
• Did you find that the schema your group devised helped you or hindered you? In what ways (did you feel guided, constrained, normal, etc.)?
• Are there specific aspects of writing in XML that are difficult for you?
• Were there particular readings that helped you better understand or research your genre?
• This project had a lot of aspects, including both group and individual work—what did you find most useful to you for developing your understanding of writing?
• What did you think went well for you in this project? What was difficult?
• If you could change something about the assignment, what would it be?

While writing the draft for the second writing project, I used the schema we created to guide me and keep the draft focused on being a scientific blog post rather than just an essay explaining my topic. As a team, we made sure to do our research by looking at a variety of science blogs before drafting up a schema, and I think the resulting template was solid. We made sure to give it some structure by splitting the blog post up into two main parts (background and answer) with each section having a few required parts, but we also retained a lot flexibility by having tags that could be used anywhere. Personally, I preferred using the schema we created as a small team for this project over the schema we created as a class for our last project. This might be a product of learning from any mistakes we made when creating the first schema, and making sure not repeating them for this project.

While peer reviewing my teammates composition, I noticed that the general structure was similar to mine (which was expected since we used the same schema), but we still had a few differences. The most obvious difference I saw was the structure in which we cited sources at the end of our post. While researching the structure of science blogs, we noticed that they would cite sources by either just embedding links to them when they were mentioned, or they would be formally cited at the end of the post. I chose to cite my sources more formally by using MLA format at the end, while Ben was more informal by having a paragraph at the end of the post where he discusses resources he used, and gives a brief description of what they contain and why they are relevant. This would be extremely useful to the reader if they want to learn more about a specific part of topic that was explained. Personally, I preferred his method since it seemed to fit the casual nature of a scientific blog post.

I used the schema to organize the content of my proposal and also as a reminder as to what information was necessary/required in a public project proposal.  I felt the schema was appropriate for the rhetorical situation as I attempt to convince the audience that the MBTA has serious issues related to its subway and that it would be in the benefit of the city to resolve them. The schema did at times feel constraining as it did not allow for multiple paragraphs within a section and allowed only one feasibility section. However, we did not intend for this to be the design of the schema and plan to correct these issues. One thing I though about was that most proposals would include some form of data and the schema does not currently allow the presentation of that data in a table or graph as visuals often have more of an impact on the audience

The schema helped me separate which information I thought would be appropriate for the introduction and that which belonged in the background. The definitions and elements within the background schema made it easier to draft my proposal and saved me some time in the decision process. I think my peer review partner struggled like I did as to how much information to include in the schema, as the proposal is meant to be a much longer document where as writing project 2 is meant to be around a 1000 words. We both struggled with how much detail should be used and both made some vague statements at times in an attempt to summarize our arguments. I found the schema designed in small groups easier to use as it was more aligned with what I was trying to do, which is to be expected when only five people designed the schema compared to the whole class.  I found the definitions acceptable in the schema, but would be open to revising them a bit if others in my group thought it necessary.

The introduction and roadmap tags were helpful guides. Overall though, the schema restricted my writing. I wanted to build up step by step to the A* algorithm by introducing the two algorithms that it is a combination of. However, I noticed that some parts fit better nestled rather than mandatory and separate. For example, I thought that a section discussing one algorithm fit in the explanation tag, but in that section I also wanted to include the question_relative_topic tag. Sometimes learning works better like this rather than when a subtopic is introduced before hand so that the learner sees how it ties into the broad picture. On another note, algorithms rely on a lot of iteration, so it would be good to include an instruction portion to the schema (like steps).

Typically, my topic assumes that the reader has some experience with programming, but I tried to break it down for even a general audience. A problem I had was deciding which terms to use. For example, I referred to tiles and nodes, interchangeably. Tile was specific to the situation I was discussing but node is the common term. I wanted to use node after introducing the tile as one so that if they decide to research more in depth, they would be able to follow without having to refer back for clarification. Another major problem I had was trying to keep the reader interested by using comparisons and images without losing what I wanted them to take away. (Try not to read it before I finish though? Otherwise, you’ll just be really confused…)

Oliver’s paper fit much better with the schema. He used the optional important_idea to support his topic, which I can incorporate into mine. After reading his, I do see how some of the sections I were unsure of fit in with our tags.

Making the schema for academic blogging was pretty different from making the first one as a class, mainly because this genre approaches writing in a very casual but informative way. Since it’s casual, the layout of one blog post can vary greatly from another’s, which made it difficult to gather commonalities without taking away from the pieces.

When writing, I used the schema as a checklist for all the essential parts of my cover letter. I felt the schema was appropriate in that it included all of the necessary components of a cover letter in the order they should appear. I am still in debate with my group about the exact structure of the ending, but I feel as though the schema is mostly where it needs to be. Being a culmination of examples and other cover letter models, there was not much room for variance to slip into our model. I believe that the documentation definitions are all accurate to their intended purposes and any changes would be a matter of ordering.

During the peer review, my partner’s model was very bare, which led me to further specify the amounts of information he needed in his letter. Creating a schema in a small group made the process quicker because there were fewer opinions and less controversy over how elements should be included. By having a relatively large influence on the schema compared to when in class, it made the writing process quicker because I was more familiar with the what and why aspects of each element.

Some minor points I believe could use some work are the header and ending paragraph; the header could include multiple lines for an address and an option to add a second address (home and school address). The last paragraph could use differentiation between the end of the paragraph and the invitation to further the hiring process. Otherwise, I believe our schema is mostly complete.

I found the schema helpful as a template for the structure of my Writing Project 2 draft. Organizationally it provided a good overview of the sections commonly used to create a compelling proposal, and the definitions helped to further clarify these components.  However, I think the schema would benefit from more structural flexibility. Having all content be required to fit into one of the predefined categories does not make it a very versatile tool. For example, a person might struggle to mark-up a proposal that was not composed using the schema as a guide, as all parts of the text may not conform to the options it offers. With changes to the hierarchical relationship between the <p> elements and the structural components, such as <feasibility> and <approach>, I believe the schema will be much better suited for general use and analysis, rather than just composition.  Going forward, when making revisions to our schema it might be helpful to keep in mind all possible uses of the schema in order to make it the most useful tool it can be.

For my experience in group 2, the Feasibility Study was a well defined schema. It provided me with many options, while also pushing me towards a clear and universally understood skeleton. That flexibility focus is well appreciated, and our schema is definitely appropriate for the rhetorical situation. I say this because while it is very loose, our focus on summery writing and have a well defined outline (table of contents) creates presentation. It is very digestible writing because it is broken down in so many different ways.

I did find the schema constraining at times. Specifically I feel that we need to add the ability to have multiple “fsb_hlght”. I wanted to include different sections and was unable too because of the constraints of the genre. The schema on the other hand provided me with a very clear and straight forward skeleton. The ability to have any number of pages, and having many different types of pages was surprisingly guiding. I was worried that having so many choices would defeat the purpose of the skeleton / schema, but I did not experience that.

In terms of how we can improve the schema, I want to add a title attribute to different elements containing paragraphs. I found myself doing this during the paragraph itself and think it can be defined well within the actual element. For example under the <req> element I found myself writing the title followed by a colon.

I used the schema as a checklist for what to put in my cover letter.  I found it to be appropriate; there wasn’t anything I felt needed to be there that wasn’t in the schema.  The schema was helpful in keeping me on track for the writing.  My partners cover letter was much longer. His was also better fitted to the specific job.  I feel like this was due to our difference in interest for the two jobs.  When reading it I realized we could better clarify the difference between types of experience.  I didn’t feel like this schema was much different than the whole class schema.  When revising the genre model I would like to take another look at the element and attribute definitions.

In writing my individual entry for writing project two, I wrote most of the text in a normal word processor. After writing all of the sections outlined by the schema, I transferred the text to Oxygen. I kept the schema in mind throughout the writing process, but it only became concretely part of the process at the end. The schema that we designed for feasibility reports felt appropriate to that genre. As noted above, the schema was kept in mind, which definitely helped to guide my writing. No actual examples come to mind, but just having the various sections outlining what I needed to cover in my report was very helpful. Looking at my partner’s report, the only thought that I had was how poorly I had used the schema and how desperately in need of revision mine was.

In regards to changing the schema, there are several ideas that come to mind. The first is the table of contents page, which I found rather confusing (although mainly due to the documentation). Generally, I would like to change the documentation to make it more specific as I found it vague throughout the writing of my report.

Using a schema designed by a group of five people versus a class of 20 odd people was noticeable. First, in creating the schema, there wasn’t a whole lot of discussion, something was proposed and we accepted it. Not to say that the process was bad, it was just something that I saw. Also, the schema was much less complex than the one created for the annotated bibliography. Having a room of people working on one problem simply leads to something more complex.

I used the schema to create the basic structure of my feasibility report. I started by looking at my group’s documentation page and the elements in our schema to write the table of contents. This outlined the rest of my feasibility report. The schema was appropriate for our rhetorical situation. The elements we included clearly guided the reader through the background of our selected projects, included supporting evidence for how it would or would not be feasible, and allowed the writer to make a judgment of feasibility. Overall I did not feel that our schema was constraining. However, I think it would be helpful if writing could be included in page elements to help transitions between sub elements. Also it could be useful to include paragraph elements. My peer review partner’s composition looked somewhat similar to mine. However, it was missing elements like a report, risk analysis, and design. These elements, especially risk analysis are integral to a feasibility report, but I am sure they will be added once my partner’s draft is finalized. I found that using this schema that was developed as a small group was different from using the class-developed schema for annotated bibliographies. As a small group, we had more individual input, and we could generate a more specialized schema. Also, we had more time to individually research our genre.

I found the greatest strength of our schema to be its flexibility. In thinking about how to structure my document, it had the benefit of helping me to differentiate the background and answer as two separate entities, but otherwise it allowed for a freedom of form I think is inherent to blogs. Additionally I weighed heavily on the ‘important points’ and ‘roadmap’ tags of our schema, allowing me to think about all needed explanations in a digestible manner, however after reading Tammy’s submission, it was clear that the way I used these tools was not the only way to do so.

One of the few circumstances I found that could benefit from broadening the genre was the ‘scentific_principle’ tag, the description of which feels perhaps too clinical. I think a ‘technical_principal’ might broaden the use of it in a way that explicitly scientific topics in addition to technical topics might be discussed equally. This same point might be said for the ‘fundamental_science_involved’. In both of these instances the documentation would need alteration as well. I think the documentation could also find heuristic benefits if the examples used in sequential element descriptions were related to each other so a user could get an idea of how the topics might be used in conjunction with each other with regard to a particular prompt.

In addition to the flexibility of this schema, I think the majority of my satisfaction was derived from having a clear understanding of the implications of each discussed element as we were creating them. This can be attributed to a) having already gone through the process of developing a schema earlier in class, and b) being in a small group allows for greater command of the final decisions, so less need to make concessions keeps a uniform vision in tact.

Although I felt very content when writing my entry, I am curious if other group members see the way in which we approached elements as being the effect of flexibility, or that of us not having a clear understanding of the schema. From looking at the other members (aside from the broad outline of the schema), we leverage elements as they fit to our style, rather than fitting our style to the elements. I see this as being an inherent part of the blogging domain, however perhaps other members will want to instantiate a more regimented approach before handing our schema off to another group.

It was surprisingly helpful to have our schema to write my first draft cover letter. I didn’t have to think too much about where I wanted to include certain information and I didn’t feel the need to go back and reference a bunch of other examples while I was writing my cover letter. There was already a place to put everything that I wanted to say in it. It also was helpful to make sure that I didn’t miss any important points in my cover letter because i knew that certain elements were necessary; and on top of that it was necessary to put them in a certain place in the cover letter.

I did find that the schema was appropriate for my rhetorical situation. I realized that it was actually using optional elements that I didn’t think that I would need. That being said, I think that we left our scheme general enough to be able to be applied to many different situations.

I never felt like the schema was constraining. I actually felt the opposite, the schema reminded me that I needed certain elements that I may have otherwise skipped or been to lazy to think of something good to say in that place. I especially felt that the schema was helpful in putting together my introductory paragraph. I still think my introduction could use a lot of work in order to feel more natural and focused/informative, but having the schema helped me to generate what I wanted to communicate in that paragraph at least.

When reviewing my partners composition, I realized that we both understood the “experience” elements to mean different things. In each of my “experience” elements I basically filled in a paragraph’s worth of information recounting one relevant experience. So I only needed 2 or 3 different “experience” tags. He used “experience” in order to denote every sentence where he mentioned a skill or something he was exposed to. It made it so that I filled in a lot more content into my middle paragraphs than he did. As in, I listed fewer “experiences” with more detailed descriptions and he listed more “experiences” with less details about each one. This is probably something that we should discuss and nail down how we intend for it to be.

I think so far our scheme is quite effective, and aside from a couple of revisions we have already made to our definitions, that what we have is working pretty well. I think that we need to add sub elements to our “experience” elements in order to better define what needs to be included in one of these paragraphs. It might be helpful to break experiences down in “skills,” “certifications”, “languages”, etc. and then leave an open list that the writer can fill in with whatever they want, but at least having suggested sub elements would prompt the type of information that you want to include in the paragraph.

I can’t imagine trying to make up this schema with any more people. It was difficult enough to be able to hash out what we wanted to do in our schema with just 4 people. It makes me concerned that our schema might be less easy and understandable to anyone else that is less familiar with the schema. I think it would be worth re-formatting our documentation to represent what is a sub element or attribute of what so that our glossary is a little bit better visual representation of what we want our schema to be. I think it would make it easier to look up what a particular tag is if it weren’t just in a list of definitions.

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.

There are several changes that I thought about making to our group schema. First of all, I think that a global reference element would be useful. In my writing, I refer to several statistics that reflect how much work would need to be done. This includes prices of tasks and the number of traffic lights that the Boston Transportation Department controls. It would be nice to be able to denote a reference so the reader can view the source of these statistics. One other thing with the schema is that I found myself wondering how much detail I should be putting into each section. Some sections kind of overlap so I didn’t want to include information twice. I felt as though the overall layout of the schema helped me write, however. It was easy to separate my thoughts into the different categories and elements.

My partner’s composition looked fairly similar to mine. Seth’s was laid out a bit better than mine I think. Most of my sections ended up being written in paragraphs while his had concise bullet points that were then explained. This conveyed the information much more clearly as the reader was able to look at each bullet and know the exact success criteria or preliminary requirement. I would say that we could potentially make these sections require bullet points so that the writer knows to explicitly state each preliminary requirement. I think we might want to consider getting rid of the feasibility section and maybe add a feasibility summary option at the end of success criteria. After you explain what it means for the project to be a success, we could then explain how feasible it would be to complete the tasks listed in that section.

When writing my initial draft for writing project 2 I used the schema as an initial outline to be filled in piece by piece with relevant information. For project 1 I had written the entire project out in a word processor initially and then broken down the pieces to be put back into the schema for an annotated bibliography. However, this time around I decided to try writing my proposal document in pieces based on the schema and then read back over it to correct for any repetitiveness or inconsistency. The schema we have created fits well with my rhetorical situation however, at times its format is a bit too rigid for the types of information that I am trying to display. I would not say that the schema constrained the context of the proposal. If any thing it probably helped to keep the report formal and logical in its ordering of information.

The piece that I peer reviewed was much different from my document. It was straightforward in its approach and kept the information in each section concise and to the point. The project proposed in it was made slightly simpler than it would be in real life in order to keep within the constraints of the assignment. Because of this I feel like there are a few areas where problems or opposition could be discussed more further or that his project could be a little bit more thought out as far as a long term solution.

Using the schema created by the class as a whole in project one was a bit easier because we had talked about each aspect so in depth that it felt like the elements had become very general and were well understood by everyone using it. In this project thought, the schema felt slightly constrained due to the fact that it was made by fewer people looking at a larger variety of examples. By trying to keep each element broad but still descriptive there were definitely areas that became a bit specific to certain types of projects or proposals.

I thought our initial schema for WP2 fit my proposal well. However, I would like to give the ability to have multiple sections with the same major theme but different sub headings, this may be easier to do if we just make ass sub-headings entities rather than types. Also, there are a few sections I believe that could benefit from having the ability to include multiple paragraphs.

The schema we wrote acted as a step-by-step process for persuading the reader to see my side of the argument in an attempt to receive approval. Our schema almost felt constraining considering the type of writing I’m doing. Since there is a lot of different direction to take the argument of going solar in Boston, there are many times I’d like to switch back and forth between background and steps forward. This is the standard way of writing about societal improvements but I may have to tweak my thought process to formalize the argument into a more proposal-like layout.

Working in a small group really allowed us to hash out different design options and debate the usefulness of each aspect of the schema. This was better than working as an entire class because we were able to talk on a less formal level and instead of almost giving up and just making things general enough to please everyone, we were able to draw up multiple optional entities that allowed people to get more specific.

The overall level of repetitiveness/ specificity within entities and broad sections needs to be revisited.

Since our group’s schema is feasibility report, the first step I did was to set a topic which is the Waitless App. I feel like my situation is perfectly for the feasibility report. I had this idea of developing the Waitless App for a while and this feasibility report is the perfect genre to propose my idea in a formal way. Writing this report makes my mind clearer of the functions of the Waitless. The schema helps a lot to organizing my words and report. The schema doesn’t have a page of explaining why do we need this App. I put the explanation in the exclusive summary which I’m not sure if it’s appropriate. The feasibility page has difference types where I can easily express my idea in different field whatever it’s a technical way or a financial way. After the peer reviewing, I found out that how to use the schema to make my sub-contents in the table of contents page which is great that I don’t need to figure it out later. It makes the report looks more organized and clearer. The schema of success criteria needs definition because I was a little confused to use this schema. Also, the timeline page and the estimate cost page is not the same as what I thought. Using the schema is mostly the same as long as I understand the definition and the purpose of each element. The schema for the first project is kind of short and less complicated than this project so it feels like easier for last time. However, the schema we have for this project organize the whole report which is good for me to write it. I would like to discuss about the success criteria and the report pages later.

Our group accessed samples mainly via online hiring sites and NUCareers. For variety, we analyzed 12 different samples from varying disciplines in order to create an overarching or “average” template. The samples we selected were relevant to us in that they either dealt with job listings within our disciplines or they were in response to openings for a co-op position. To broaden our scope, we also obtained general cover letter advice from co-op advisors in the form of verbal or written tips, as well as formal documentation describing cover letter production.

We began studying the situation by discussing our previous co-ops and interview experiences. One of us also met in person with a co-op advisor to discuss their experiences with the dos and don’ts of cover letters. We decided this would be the best course of action to take because personal experiences are much more valuable than online samples and models. Furthermore, we also wanted perspective from readers of cover letters rather than just writers. We entered the scene by broadly reviewing cover letters from an array of jobs and disciplines. We then compared the similarities and differences between the cover letters from those positions. While we saw many variations in content, we found that most cover letters have many similarities in structure regardless of the job they are in response to.

As a whole, our genre followed a very predictable and repetitive pattern. The basic outline of cover letters was a greeting followed by three major sections addressing purpose for applying, applicant’s background, and why applicant would be a good fit (in that order), followed by a cordial closing. This is similar to a business letter format. Also similar to a business letter, cover letters tend to have reasonably simple and professional sentences that are word efficient. This format along with the fact that cover letters were less than a page made for a concise and well flowing document. The main purposes of a cover letter is to take the sterile facts and numbers found on a resume and convert them into a flowing and easy to read form that ties everything together.

Focusing on the more technical disciplines, such as engineering and computer science, we noticed that cover letters are more concise and filled with quantifiable information; though that does not mean that they were necessarily shorter.  For example, a cover letter for a social work position included information about the writer’s passions as opposed to simply talking about their qualifications for the position.  However, our engineering co-op advisors emphasized that a cover letter is used for a hiring manager to get to know the applicant and how his goals align with the job along with his qualifications. This provides some insight into the engineering discipline, and shows that it is not simply concerned with factual, quantifiable information when making hiring decisions. This also means that the cover letter is an uptake of both the job description and also the attached resume.

In our research of various cover letters we found that the rhetorical situation strongly affected the composition and elements of the cover letter. Cover letters would be structured differently depending on which discipline it was associated with, or simply if it was in the form of an email rather than an independent document. This discipline-specific format was reinforced by the information we received from our co-op advisors.  Due to these large differences, we decided to base our genre model to a rhetorical situation most useful to us; our genre model is based on a cover letter written for a job in the engineering discipline, by an applicant with previous work experience, and with the intent to be sent as an individual document preceding the resume. We left the elements and attributes generally stated, and added some optional attributes that would allow for anyone of any discipline to fill their cover letter with content important for their field.

We used the example resumes we analyzed to decide what attributes were absolutely necessary in all cover letters, and which ones would only sometimes be relevant. We had to acknowledge that there is still a good amount of variance in rhetorical situations within even our own discipline. This simply meant that we included some optional elements that would be nice to have in some situations, such as a sentence about how the applicant learned of the opening, or what connection he or she may have.

One aspect we did not include in our model was some sort of indicator of whether or not the cover letter has information that too closely resembles the resume it precedes. We learned from our analysis that the cover letter should not be a reiteration of the resume, though that is challenging to indicate in an xml file, especially if we do not have a defined model for a resume.  

Update: After going through the peer review process, we decided on several changes regarding the format of our schema. One of these changes included general writing formatting, such as spacing and line breaks. We added room for 2 lines in the address section so it would be displayed like a normal address (street on the first line and city/state/zip on the next). We also created an option for a line break within the last paragraph between the compatibility and next step elements. This option could be used at the writer’s discretion depending on the flow of their letter. Furthermore, we added acknowledgement as an optional sub-element under closing statement element since we noticed a thank you statement was fairly common in many of the cover letters we read.
From our peer review, we also found that the background paragraphs were usually the part of the cover letter that needed the most edits. However, we concluded this was not due to how we modeled the schema, but simply due to the fact that this is the hardest part to produce. Any additional clarifications or restrictions to this section might seem constraining since this is the section that more directly responds to job descriptions which can vary significantly. As a compromise, we decided to add sub elements that could be used to call out highlights under experience paragraphs. We added languages, skills, certifications, and programs as optional sub elements to work as a list of possibles to include inside this section. The hope is that this would help the writer to generate ideas for what to include in this section and keep the letter focused.

My group’s genre is feasibility report. A feasibility report is a genre that studies the project and analyze it to see if the project is feasible or not. The genre that feasibility report might uptake from is project proposal. The purpose of a project proposal is to propose an idea of something. It needs to show that what has been proposed is a good idea and can increase revenue of the company. A good project proposal not only propose an idea, but also a marketing analysis and trend analysis. After the proposal has been proved, we need a feasibility report to show the feasibility of the proposal. If the proposal is lack of feasibility, it may need a change or a recall. There are a lot of things that a feasibility report needs from a project proposal. For example, the idea, the exclusive summary and the application overview are mostly from the project proposal. However, to complete a feasibility report, it needs some more fields such as process needs to be followed, technical feasibility and risk analysis. All these fields need feasibility reporters to do a research on and analyze on.

The next step of the feasibility report is the decision. The audience which could be a bunch of managers or maybe board of directors, after they reading the feasibility report, they need to make a call to approve or not. After the decision, the action will be taken. If the feasibility is a good one which shows the benefit and the risk, gives all the data in a good possible way and a bad possible way, it will lead the audience much easier to make the decision. A feasibility report needs to show the best case and also the worst case in order to make the report more reliable. The decision is not only an approval, but also a paragraph which contains the reason of the decision. What shows in the feasibility report generate the decision.

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.

We began our study by constructing a list of all the types of proposals we have been exposed to. In doing so, we were able to gain an understanding of where our experiences overlapped. By focusing in on public initiative proposals for this project we were able to narrow down the scope of our genre to make finding examples and creating a sample schema slightly simpler. Given that these proposals have been made public or use public funds, finding samples was fairly straightforward as cities are required to maintain lists of different proposals and Requests for Proposals (RFPs) that they had published or received on their websites. Some of the samples that we examined for our analysis included a new community library proposal, a design-build proposal for building conservation to the town of Newtown and a sustainable art proposal submitted to Duke University. When selecting these examples, we tried to collect a variety of formats and situations. Many of the samples we analyzed were fully developed written proposals, following a somewhat standard format that focuses on a specific issue and suggests a solution, going on to discuss the benefits the proposal could provide.  The first sample is a power point developed by the city of Stoughton, Massachusetts for a town hall meeting to present to the public on this possible city improvement project. The second sample is a concise proposal from a private construction firm to the city of Newtown, Connecticut for the mothballing of a series of abandoned public buildings. The third sample moves away from the general theme of construction and focuses on a smaller community improvement project, sustainable art installations on the campus of Duke University. In addition to these finished examples of proposals we have been looking into different examples of RFPs and calling city council and public board members such as the director of the Stoughton public library board of trustees, Pat Basler.

In addition to studying the finished product of a proposal, we looked at the events and genres that occurred prior to the creation of a proposal and what genres the creation of a proposal resulted in. We found that in the case of public initiatives a problem was often discussed in a Town Committee meeting and then debated for some time before the proposal was created. Committee members would agree to a basic solution to fix a problem and would then notify the public of the issue and ask for feedback about their proposed solution. After taking account of public opinion, their solution could be modified to better suit the town’s needs and then the official proposal would be created and submitted to all required parties for consideration.

In some cases, a city may identify a problem, but lack the resources to develop a solution.  To solve the problem, a city may publish a RFP (request for proposals) to inform the community and relevant parties of an opportunity to develop the city in some way and seeks suggestions on how to best achieve their goal. Because the project and proposals will all affect the community as a whole, much of the information being distributed on each level will be made public for people to read and ask questions about and are therefore meant for wider consumption by anyone who is interested. No part of this proposal process is internal to any particular organization. There may be associated internal communications within the companies or groups creating proposals to be submitted, but their final proposal is meant to be submitted to the city (or a group working on behalf of the community) to become public record.
Analyzed marketing campaigns that go alongside a proposal (accepted or otherwise) that highlight the potential benefits of the project. While not strictly part of the genre of a proposal, the marketing campaign works alongside and after the initial proposal, and was created by the same authors who were responsible for implementing the project. The marketing campaign is used to shape the opinions and expectations of the audience concerning the outcomes of the project, and attempts to define the possible uptakes of the situation.

In an attempt to better understand the situation involving public project proposals, final products of proposals were observed to gain an understanding of the general format. We also studied how RFPs are constructed, modeling after an accepted proposal. To gain a better understanding of the process before a proposal is submitted, we have contacted the Director of the Stoughton Public Library board of trustees. Her input has helped us to see how the initial recognition of a problem interacts with the final proposed solution that we have already studied. In addition to studying the proposals and RFPs, we analyzed a marketing campaign the town of Franklin, MA produced that went alongside the proposal to change the traffic pattern of the downtown area.

Structurally we found that proposals were straightforward compared to other genres found in the world. Sections and elements that may be found in a proposal are usually titled and are strictly designed to fulfill the specific purpose set by that element. The language throughout these proposals are formal and to the point. It is written to give the intended audience the problem at hand, possible solutions, and how to go out and execute or list what it necessary to get this done. The language or types of words found within these proposals are general and simple enough to be understood by the general public. The pattern and structure of these proposals are usually started off by a title element where anything associated with that material is found under the title. The sentences found in these sections are shorter and contain all necessary information to make its point in that section. In these proposals there aren’t many, if any, sections where you’ll find excess writing that sets up another section or for instances uses writing tools to develop tone or forms of imagery. Instead the sentences are purely informative and are design to make one point after another.

By studying this genre we are able to gain insight into the ways that groups or organizations communicate with each other in a formal and primarily persuasive format. By using the Spinuzzi article on ways to examine different assemblages of text we looked at both the linear and progressive steps involved in the situation surrounding a public initiative project as well as the overlap in conversation and exchange of information throughout the proposal writing process. With public projects there are a number of different stakeholders involved at different levels at different points of the project. Because of this, it is very important to keep track of any decisions or steps made in a formal and publicly published format. The ability to communicate your ideas or goals to a large audience with varying levels of involvement and expertise is vital to achieve the changes that you hope to make. In addition, we were able to observe how the author(s) of a proposal sought to control the uptake of the genre by including various sections in the proposal. The author(s)’s goal is for their intended audience to agree with their proposed solution method, and will attempt to construct their argument to lead the reader to conclusion that the author’s suggestion will be beneficial for the town and is worth pursuing.   

Our final genre model is a direct result of the examples that we examined and the people that we talked to. Based on the persuasive nature of the genre, we chose to develop a very structured model for how the document should be formatted. Generally whether you are writing a persuasive essay or project proposal there are a set of agreed upon steps that should be followed to lead your audience towards your desired uptake. This is why our schema is first broken down into levels of structural separation for clarity and ease of understanding. Within each section we break it down further indicating necessary content to include or discuss.

Since there are so many different methods of persuasion and such different levels of professionalism, many sections needed to include overlapping optional sections. A Letter of Intent, Executive Summary, and Abstract all get across the same information with different levels of formality and at different points in the study. Sections such as these require one or more of the listed attributes to be included.

Each proposal we studied had its own methods to attempt to persuade the audience. There were many sub-sections that could have been included to reflect all of these strategies, but we decided to keep our sections broad enough to be all-encompassing with the understanding that it could be altered or added upon when the situation called for it.

**Addition**

After our first attempt at using our schema, a few shortcoming became evident. Firstly, we decided that it was necessary to incorporate multiple paragraphs into each of our sections. This allowed us to change some of our types/ sub-headings into their own entity. For example, instead of incorporating economic details as a type of feasibility, we are now able to write multiple paragraphs under feasibility that can include economic, social, and environmental arguments.

Due to the persuasive nature of our texts, we found it necessary to allow for visual backup. The insertion of an image or chart allows one to reference data during their argument.

My group’s chosen genre for project two was feasibility reports (or studies). These reports outline implementation details of an concept. Included in these details are specific timelines, costs, and other recommendations for the final product or system that will be produced.

Feasibility reports uptake such genres as ideas or research papers. A feasibility report uptaking an idea is essentially the fleshing out of said idea. The idea or concept for the solution to a problem doesn’t have any practical value until someone decides to take action and figure out implementation. Creating a feasibility report from a research paper is similar, as the research paper lays out what is essentially an abstract concept with little to no real-world details.

The previous genres are reflected in a feasibility study as the preceding idea is essentially the backbone of the report. If there was no preceding genre (an idea or paper) there would be no study and the entirety of the report is based on the idea.

Following the chosen genre are actual implementations and the attending genres of an implementation. The implementation, generally, is the actual materials needed to make the device (or however the idea manifests) and the person-power needed to construct and/or distribute the implementation. The attending genres can include business plans defining fiscal details or, for public concerns, legislation of any form concerning the implementation. The “desired” uptake is the actual implementation although that sometimes cannot exist without the attending genres. This “desire” is reflected in the ability of the report to act as an outline or plan to the final implementation.

While creating our genre model, I don’t think we were explicitly thinking about uptake. However, feasibility reports are inherently quite good at being “uptaken”. As part of the genre model, a person looking to uptake a report (formed using our genre model) can look at specific structures and extract them in order to uptake the report. For instance, there is a summary that one can easily see the intent of the report or there is a financial section that one can look at to see how much this could cost. In a general sense, the genre model makes uptaking of the report easier as the desired components are more easily extractable.

The genre for my group is cover letters. Our genre is typically preceded by job openings and listings, which often contain specific details of the job in question. Cover letters are an uptake of job listings in that they are a direct response to them- they are an attempt to obtain the job by demonstrating why the applicant is a good fit for the job. Cover letters are usually curtailed to a specific job opening and its particular responsibilities so they can be seen as the perfect uptake for all the duties entailed.

Other genres that precede the writing can often also be incorporated into the letter. Such genres can include conversations with the employer at a job fair, connections to the company through previous work, and references to advertisements. A genre that typically accompanies a cover letter regardless of any other factors is a resume. After resumes, typical genres that follow a cover letter would be a follow up email, phone call, or letter. The desired uptake from these situations would be a furthering in the hiring process, such as obtaining an interview, or even straight out being accepted for the job.

The desired uptake can be seen in our genre model as it culminates an array of experiences with cover letters. We viewed various professional cover letters and reached out to co-op advisors to determine what factors led to the highest success rate with cover letters. We then incorporated these traits into our model to make it as precise, readable, and balanced as possible when discussing why the applicant would be well suited to the job. Some other uptakes that had moderate influence on our model were grammar, sentence structure, and syntax. While our model could create a solid foundation for cover letters, it itself cannot determine if the language used is in line with what the reader wants- we cannot predict the personality or exact type of the reader (friendly HR staff or terse engineering supervisor) and what they value in a cover letter, example being personable vs. professional traits. Overall though, I believe our model does an acceptable job of up taking previous information and putting out a product that will create desired uptakes.

The genre’s that proceed the creation of a public initiative proposal can vary based on the specific situation the proposal is meant to address. Often there are informal discussions among town officials or the public that first identify a problem and then determine if it is something they could address. After this informal discussion, town officials may decide to hold an official meeting about the problem and may invite the public to attend to voice their concerns and have their opinions be heard. A town meeting or Town Hall is a genre that is meant to convey information to the public, but also allows town officials to gauge the mood of the town related to certain issues. The uptake of a town meeting is that town officials can expect to learn the opinion of the general public, and the public can expect the town officials to take into consideration their desires when making decisions on behalf of the town. Based on what is said in the meeting, officials can determine if the public cares about the topic, what the public thinks should be done, and how much support/resistance town officials can expect when addressing the issue at hand. Once this information has been obtained, town officials can create the genre of a public initiative proposal that takes into account the general public’s opinion while suggesting a way to fix the problem. Also, a town may determine that a problem exists but is unsure of how to solve it. They would then create the genre of a Request for Proposals (RFPs), which would directly result in the creation of proposals that suggest methods of solving the problem and take the uptake of the RFP (that is the problem statement) into account.

While the genre of a public initiative proposal is fairly straightforward in it seeks to address a problem while convincing the general public that the solution it outlines is the best option. In addition to defining a solution method to a problem, the content of a public proposal may be affected by the uptake of the genre’s that preceded it. For example, if at a town hall meeting citizens expressed concern that the road repairs would create bad traffic delays during rush hour, the proposal may include a section detailing the detour route that would be used during construction with data showing that it would only create a few extra minutes of travel for the average commuter. Alternatively, the town may decide that the citizens concern is valid and as a result, the construction will only take place at night when few people are on the road. In both of these examples, the genre of the proposal was affected by the uptake of the genre that came before it.

The creation of a proposal could result in many various genre’s including a town vote on whether to implement the proposal, construction bids for the work detailed in the proposal or the development of a schedule for the activities outlined in the proposal. A vote on the proposal would spark a debate on the benefits of implementing the proposal contrasted with the costs of the project and any inconvenience it may create. The public would use the uptake of the proposal, which is the arguments  for implementation, and either be convinced that the project is necessary or decide it is not.