Author: christy.b

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.

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.

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.

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.

Our group’s genre model was for a feasibility report. One possible genre that a feasibility report could be considered an uptake from is a project proposal. A feasibility report takes a potential idea or task from a project proposal and assesses how reasonable it would be to complete the task given the company or proposer’s current situation. Most reports will have a section towards the beginning of the paper containing an overview of the task being assessed. This overview can be directly brought from the requirements set in a project proposal. A feasibility report is one of many different responses that could be uptakes from a project proposal. Some proposals are straight forward and don’t require an in depth analysis of the project. The response to this situation could just be an approval of the project.

The project proposal is reflected in our genre model through the problem statement. If there was a proposal, its requirements could be shown in the preliminary requirements section of our genre model where we lay out the different requirements of the project.

After a feasibility report is read, a decision will be made on whether or not the project gets approved or denied. The report may be used in addition to meetings and other forms of analysis for the group to make the correct decision. The desired uptake of a feasibility report is whether not it is viable for the project or task to be completed given the current circumstances. The uptake is supported by the different feasibility sections that lay out facts which will let the reader decide whether it is possible to complete the task or project. There is also a main summary at the end of most feasibility reports where the author explains his or her overall opinion on the feasibility of the project given all of the research that they conducted. The desired uptake seemed to be the only uptake that has currently influenced our genre model.

Our group’s chosen genre was a feasibility report. Some texts that a feasibility report might interact with include some research papers or other technical documents. Feasibility reports are a general analysis of how reasonable a task would be to undertake or complete. In order to add supporting evidence supporting one side of the argument, the writer of the report may reference previous research papers and include them as a reference at the end of the document. From the examples that we examined, we found that the reports were generally internally used within a company or organization, but there were also several examples which were made for public consumption. Interaction with reports were not always specific to one field, however. Despite the reports being very technical in their nature, the decisions that a company makes are usually made by some sort of management. So although the reports may be written by an engineer, it could be analyzed by someone in a business or management profession. An engineer would most likely be doing the research behind the report. They analyze all of the measures that determine feasibility and make their own suggestion at the end. When management reads the report, they can just look at all of the data that the engineers collected and make an informed decision based on that information.

Feasibility reports are created in response to some sort of idea that needs its viability to be determined and can potentially be a response to texts that present an idea. A feasibility report may be a response to a project proposal, for example. If a team member thinks that they have a good idea, they submit a project proposal that outlines the plan for their project. Management could then ask an engineer to write a feasibility report on this task to see whether it would be worth it to work on the task or not. Looking at the genre of feasibility reports as a genre system would be helpful. One could examine the feasibility reports in sequences of genres, looking from the problem statement to the reference material that supports feasibility arguments to the final conclusion. This would help us to better understand the genre and better examine how it interacts with other genres. A closer look at feasibility reports through the lens of a genre system would definitely prove useful to our group.

I worked at MITRE in Bedford for my second co-op. MITRE is a federally funded research and development center, or FFRDC, for the government. Our company took on many different problems for the government including anything from cyber security to GPS systems. The team that I was a member of was a team working on a GPS system. Although I cannot discuss many specific details of the project, I can say that our group would be considered to be doing interdisciplinary work.

Throughout the co-op, you could consider my discipline as computer engineering. My tasks generally involved programming hardware of some sort to integrate with the GPS system. There were two other disciplines represented by my team members which were electrical engineering and physics or mathematics. There was a lot of interaction between these disciplines throughout my six months at MITRE since we were creating an actual physical system. I had to do a lot of work with one person whose discipline was electrical engineering because my component needed to be added to the system’s circuit board. I had to test my software on the board that he fabricated in order to ensure that the system was working properly. My software component was just receiving data from the board, this information that I received was then used by the person with a physics discipline to actually produce coordinates of the system.

It is easy to see that this work could be considered interdisciplinary. There were three different disciplines, physics, computer engineering, and electrical engineering that each utilized parts of the other disciplines in order to create a functioning GPS system. I could see myself doing interdisciplinary work like this after graduating and entering the work force. Working with other disciplines allows for a little variety in the work that you are doing. You need to have knowledge of the entire system to make your components work rather than just doing your individual part. Constantly collaborating and working with other disciplines allows for an exciting and interesting work experience.

Seth Bakes’ annotated bibliography deals with the Northeastern University co-op web app. Similar to myself, Seth focused more on the problem than discipline in the problem statement, which I agreed with. I felt that the problem was more relevant to the annotated bibliography than identifying a discipline. The discipline is more implied in the text, where he and I both explain the type of of problem and the reader can infer that his has to deal a software app and mine has to deal with computer hardware and software.

In the citation section, Seth broke each citation tag (author, ref, and title) onto their own line and then included the entire citation in a comment. I think that I like this style better than my own as I just typed the entire citation on one line and then just inserted the tags where they belonged. The only issue that I saw with Seth’s citation versus mine is that in the formatted view, the entire citation was not able to be seen, just the text within tags. A combination of his citation style with mine would have been sufficient, where the entire citation was there in text but the tags were formatted in separate lines for better code readability.

With regards to Seth’s annotation, he and I followed a similar format. We each chose one type from each tag so there were three tagged sections, one background, one summary, and one relevance. When reading his entire annotation, his three sections seem to flow together nicely which was one thing that I struggled with. I felt that when reading my annotation, you could tell that the small paragraph was written in three different sections.

Comparing Seth’s annotated bibliography to my own made me see view mine a little differently. I found that my tags could have been formatted a bit better so reading the code would be easier. It also made me realize that I could have made much more smooth transitions between elements of the annotation. I also realized that both of us forgot to tag the type for title (journal, website, book, or website), so I would have changed that.

Composing in XML markup as compared to a general word processor definitely gave a different writing experience than I was used to. Overall, I felt that using the XML format gave nice guidelines for me to write the annotated bibliography. Having one specific form that each source and annotation should be in helped since we had to write five annotations in the same form for five different sources. I feel as though I was writing to the schema versus writing to the prompt at times, however. I didn’t find myself looking at the prompt much at all during the writing while in a general setting I was referring to the prompt often to ensure that I encapsulated everything from the prompt. If the schema is set up well, though, this shouldn’t matter as much as all elements of the prompt should have been included in the schema. It seemed like at times I was writing three different sections for each annotation rather than one complete paragraph. I believe that this is how XML writing is supposed to make you write, it just felt a little odd because I was not used to writing in this manor. I think now that I completed the bibliography I would have liked to make sure that each section flowed together nicely despite being written in the schema format of background, summary, and relevance. One way that I kind of felt restricted in the annotated bibliography form was that there was not much room to describe how the source could actually apply to the problem. The short nature of the annotation allowed for just a short sentence or two describing the application.

It seems like the “social action” of an annotated bibliography is to identify a problem and explain how other people’s ideas and research can be applied to that problem. It is a gathering of sources in a manor that the reader can infer how an the different sources will piece together and provide a solution.

Overall, I feel pretty comfortable writing in Oxygen. It gives a nice rigid format that allows the writer to stick to predefined guidelines and write for the specific genre that they are creating.

One problem that anyone driving in a city has encountered is traffic. Cities are renowned for their traffic and how long it takes to get from place to place due to the volume of people attempting to get places in such a small area. My discipline is computer engineering and I believe that some of the techniques that we apply could help address and decrease traffic in the city. Computer engineering can be thought of as a combination of computer science and electrical engineering. These skills can be applied to so many different things throughout a city due to computers and electronics controlling everything from energy consumption to communication. I think that an interesting application could be to control traffic signals to decrease commutes throughout the city. There is one computing system that I would utilize in traffic signal timing that could decrease waits and that would be to use machine learning, specifically an artificial neural network, to perfect waiting times at signals.

An artificial neural network is a form of machine learning modeled after the central nervous systems of animals. These networks take in sets of data and adjust their outputs based on current conditions and historical data. Each implementation of a neural network is unique in that you can control the weight of the inputs. It can give heavier weight to historical data or more recent data.

Currently, the traffic signals in Boston are set to timers. Depending on the time of day, the traffic signals will wait a certain number of seconds to change colors. According to the City of Boston website, the city retimes traffic lights roughly once every five years and has computer control of 544 out of 845 traffic signals. In order to implement a central control of the lights, a set of sensors at many different locations in the city would need to be installed. The inputs from these sensors would be fed into the neural network which could then control the timing of the traffic signals to be more efficient. The neural network also ‘learns’ from previous data. Based on its performance in previous situations, it can optimize the wait time of cars in the future. The traffic in different parts of the city could affect the timing of the lights half a mile away in order to increase efficiency. Quicker commutes lead to more time spent with family and enjoying their time rather than sitting in a car. Although this obviously wouldn’t completely solve Boston’s traffic problems, I believe that it would be fairly effective and increase the quality of life and decrease fuel consumption of those in and around the city.