Category: Journals

The genre of public initiative proposal can be the uptake of several situations but can also be sparked by something as simple as an individual desire for change. If one person sees a problem they wish to have addressed, they have the power to write a proposal with the intended uptake of public action to address their area of concern. That being said, public initiative proposals can also be the uptake of a public discussion at a town meeting or of formal complaints to the local government. The intended uptake to a complaint would be an apology or a solution but proposals are the first step associated with improvements. Although they may not be the intention of the person issuing the complaint, they are necessary to achieve their final goal.

Typically the intended uptake to a proposal is acceptance at a public hearing and an RFP to aid in the process of hiring contractors to do the work laid out in the initial proposal.

The genre model that we have put together follows the general thought process we observed when one might be referencing a previous document. For example, we have an objective portion that lays out the intended impact we would like made. This can be followed by the goal, which is a more concrete desired output that will have an effect that leads to the objective completion. Lets say someone complains that the library is not handicap friendly. The objective of a project could be to make the library handicap friendly, however the goal would be to install a wheelchair ramp and handicap parking spaces.

Many points in this process are influenced by uptake. When some company is responding to a RFP, they would not only check off all that the RFP asks for, they may also check against the initial proposal to gain situational context as outlined in the reading earlier this week.

Generally there is usually a document called a request for proposals (RFP) which is submitted by a town or organization calling upon members of the community to provide proposals outlining their ideas or proposed plans to solve a “problem” or to enact an idea put forth by the town. At this point project proposals are written and submitted to a board of town members who were appointed to the project. Following a proposal comes a series of meetings, whether that be with the town or only with the board members who then decide which proposal they are going to enact or fund. Although previous genres are not directly represented in our schema we did take into account the information that would be given to people in an RFP for them to be able to iterate back in the proposal. The objectives and the goals sections allow for the writer to address the requirements of the RFP in an obvious and straightforward way.

The direct uptake of our genre is discussion. Because there is rarely just one proposal submitted your ideal uptake would be that post discussion the town or the board decides to go with your project but that is not always the outcome. If they do pick your project you may be issued a project budget or asked to submit a more detailed plan or schedule. This desired uptake is represented in our schema with the plan section of the proposal which would outline initial schedules and budgeting plans.

The biggest way that uptake influenced our genre model is that it is primarily a basis for discussion. A proposal has to be broken down into simple and easy to follow steps that all sorts of people can understand and get behind. With most technical writing it is very important to know your audience so that you can give them the most information possible without overwhelming them or losing them along the way. In most cases though you are typically communicating with fellow engineers or project managers. In the case of public initiative project proposals however you are writing for doctors, stay home moms, bankers and people who may not necessarily have the technical know-how that your discipline relies on to support their ideas.

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.

There is no chicken-or-egg question when it comes to blog entries discussing complex topics, and the research that these entries are referencing. An acceptable definition is almost certainly workable that would state the genre of research as being antecedent to that of the blog entry. Although broader consequences of the research may be illuminated by the entries, the entries themselves give no attempt at adding to the research of the topic at hand. The genre of research doesn’t directly presuppose that it ought to be brought to the masses in layman’s terms, however there is an appreciable need for this translation in order to ease in the understanding of important issues for those who are affected by them but do not understand them.

Just as our genre would not exist without the theoretical existence of research on a specific topic, it would would lose importance if it detached itself from the direct instances — journals, reports, etc. — of this research. By providing both off hand references to names and projects in addition to direct citations, the views of the blogger are kept within the realm of reality and legitimized to the reader. These references fulfill the criteria for the first half of the definition of uptake, and the ability to translate them to high-school-readable levels and digestible analogies fulfills the latter half.

The explicit genres that might follow our genre would be those which exist on various social networking platforms. This is seen in links that allow the reader to subscribe to the blog, or share it on Twitter, Facebook, Instagram etc. Another avenue of interaction is a comment section present in most of these blogs. Not only does this help to spread the name of the blog to which the entry belongs to, but it also targets an audience which is most likely to be receptive to educating themselves on the topic (friends with similar interest, typically a younger demographic). I believe an implicit uptake of our genre is also to educate the reader so that they might make changes in their own lives or value systems, in addition to helping the reader to communicate the ideas they’ve read about to friends in their own life.

In our initial draft of our genre model we accounted for the explicit uptake of social media forwarding by including elements for this purpose. Ultimately we chose to remove the comment section and a few other existing uptake related elements as fabricating their existence seemed unimportant.

My team’s genre for project 2 is a feasibility report. Typically a project proposal precedes this genre. A project proposal lays out an idea or project to be accomplished by giving a detailed and logical description of the steps to be taken to solve a specific problem. However, a proposal will not automatically be accepted. It needs to be well-researched and possible. This is where a feasibility report interacts with the proposal. A feasibility report will assess how reasonable and possible it will be to execute what is in a proposed idea or project. Because of this, the two genres closely relate to each other. A feasibility report delves further into the claims made in a proposal. More research will be conducted to decide if the ideas in the proposal are feasible. Additionally factors like expenses, timelines, and risks are considered.

After a feasibility study is produced and read, the group or organization that commissioned it decides on its next steps. If the feasibility study declares an idea or project to be too risky, the group would have to reconsider its original ideas. This could lead to creating a new project proposal. On the other hand, a feasibility study could approve of the ideas generated in a project proposal, and the commissioning group could go ahead with their project. This would lead to countless other genres being used in order to begin work on the project. In either case, the desired uptake of a feasibility report is the production of a logical and unbiased evaluation of a group’s idea, which can then guide the group’s next actions. My team’s genre model reflects this with the elements that we included; we have an element for an executive summary, preliminary requirements analysis, feasibility, success criteria, design, cost, risk analysis, financial planning, and a conclusion.

The genre we are analyzing is a cover letter. Cover letters are typically preceded by job postings, as they are a method of expressing interest and representing your strengths as related to a job you are applying for. Cover letters tend to be tailored to the values and description used in the job posting since the author/applicant wants to represent themselves as a good fit for a particular job. Genre’s preceding a cover letter can include conversations or posters at job fairs, online ads posted on hiring websites, ads on university resources such as NUCareers, etc. A cover letter may be ignored if it is not well received; however the hope is that the uptake would be interest in you as an addition to a manager’s company. The hope is that you get a response in the form of an interview request following your cover letter.

When putting together our genre model, we considered how easily the reader will be able to find the important information in the cover letter, how much time and energy the reader would have to commit to reading the letter, and how to encourage professionalism and courtesy in the assembly of the letter. For these reasons, we included a fairly rigid structure for how to organize and assemble the content in the letter. We made introductory and closing paragraphs mandatory, and we built in a greeting and signature. That way it would be easy for the reader to pick up the letter, get a good sense of the purpose of the letter and the goals of the applicant from the first couple sentences and then find all the applicant’s qualifications immediately afterwards. We also made sure that the closing paragraph would include an invitation for further communication (an interview) and the header would include sufficient contact information for the reader. The assumption being that if its an easy and pleasant experience for the reader to read through your cover letter and reach out to you, then you’ll be more likely to get an interview.

Unfortunately there are a lot of things that can influence the uptake of a cover letter that could not be controlled by a genre model. Strategically, an applicant should include action verbs in their cover letter, use easy to read and professional language, describe accomplishments they have made in their professional experience, express goals that align with the company’s values, or anything else that makes them sound like the best fit for the position they are applying.

Our team chose a feasibility report as a genre to study, model, and produce for writing project 2. Our initial access to a sample was through our group member Seth who had written a feasibility report for a previous class. After reading and analyzing his report, we looked for other example reports on the internet. We found about five other examples of feasibility reports produced by various universities and companies that appeared to be fitting examples off of which to base our studies. Documents published by a university or reputable company will generally be credible and of good value. Some of these sources gave guidelines and templates for writing feasibility reports. These aided our understanding of the actual samples we found.

In order to study the situation that a feasibility report addresses, we mostly referred to Seth, who had created a report before, along with the previously collected samples. Through studying samples, we found that feasibility reports are generally published or produced by a company or university attempting to validate or invalidate the need for the proposed product or action. These documents can be produced and read internally within an organization to decide whether a project is feasible, or they can be read by an outside party who will decide for themselves whether or not the idea or product will work. It was possible for us to access the scene of actually writing one of these reports by interviewing our group member Seth. We also were able to contact one of Seth’s professors about his experience reading these reports. In this way, we came to understand how different viewpoints interact with the same genre.

From our studies, we were able to identify the structural, rhetorical, and lexical features of a feasibility report. Structurally, most reports were written in a similar format. They contained an overall abstract or summary of what topic the paper was examining. The paper then moved into the requirements of the paper’s topic followed by the actual examination of the feasibility of different areas of the topic. Some of these areas included economic, environmental, and technical feasibility. These feasibility sections were then followed by a conclusion which provided the author’s opinion on whether or not the project would be viable given the examined factors. Rhetorically, the reports strongly appealed to logos as well as a more mild appeal to ethos. The reports contained many facts, data, and charts which provided logical arguments to the reader as to why the project may or may not be feasible. The appeal to ethos was provided by the company or university’s reputation. A highly regarded university producing a paper allows the reader to believe that the information is credible. The lexical features of the reports generally contained a lot of discipline specific language with declarative sentences that provided the facts found through the research done for the report.

We found that feasibility reports reveal quite a bit about the rhetorical situation that they address. The reports are always logic based. They do not deal with emotional responses to a situation, but rather provide factual information by which a logical decision can be made. It shows that in general, most decisions being made in engineering fields are made because of factual evidence pointing to the correct solution. Engineer’s emotions or personal preferences will usually not overpower facts laid out showing a better path to the solution.

The elements and attributes that we generated were all produced directly from the analysis that we did. The overall structure of the report provided a large number of elements for us. For example, each major section of the report was designated as its own element, such as the table of contents, executive summary, and feasibility sections. There were also attributes that we added based on topics discussed in each section. In the feasibility elements, there were attributes available to accurately describe the topic of feasibility such as technical, economic, and environmental feasibility. Some of the decisions that we had to make regarding our analysis were whether certain elements or attributes could be optional or required. Overall we included the same elements that were in our samples. However, we omitted a detailed project schedule since our time is limited.

Our group noticed that there was a larger variance in included sections. We believed that this is dictated by many factors, including the sources of funding, the actual medium of the project (physical or digital), and the potential impacts. We designed our genre model to allow for a flexibility with what to include and what to leave out, enabling our genre model to cover studies about building a dam, and building a web app equally well. For the sake of our projects and condensing the format slightly, we included less in depth versions of timelines and financial reports.

Update: After the first draft of P2, our group came to a few realizations. Firstly, while our schema allowed for carefully outlined and segmented ideas, we were missing the ability to create titles in certain places. This occurred primarily under success criteria and the preliminary requirements analysis. We also felt constrained without having the ability to include multiple requirements sections under the success criteria page. These two changes will allow us to better express our different ideas and bolden the section headings, increasing the readability of our document. We had to create an image account for our group to upload design images. This way we could refrain from cluttering the class repository with the documentation images. Lastly we added a global <ref> element that can be included on any page. This element allows us to include outside sources and cite them. This is not something we brainstormed during the development phase, but it proved necessary once we started our personal projects.

Proposals can be commonly found in many different fields. At the most basic level a proposal is merely a written suggestion for submission and consideration by an audience. For writing project 2, my group is taking a closer look at the particulars of public initiative proposals. These texts’ goal is to introduce an idea for a project that will improve a community, as well as address the benefits of implementing it, and the possible challenges that may be encountered throughout the implementation proccess.

There is a very strong correlation between the texts of public initiative proposals and RFPs (request for proposal) . As an official solicitation, RFPs directly reference project proposals, and in most cases, these proposals originate as responses to RFPs. Though these texts frequently exist within this formalized call-and-response structure they remain readily understandable to the most audiences, not just those in the trade, due to their public nature. Additionally, the project proposal may be seen as the progenitor for all subsequent documents relating to a project. Texts such as design reviews, feasability reports, etc. all will use the original proposal as a reference source.

For writing project 2, our group chose to analyze proposals for public projects.  As proposals is a very broad genre that includes proposals for experimental design, construction bids and proposals for a change in laws, our group decided to focus on public initiative proposals.  Public Initiative Proposals are those projects that aim to serve the community by improving some aspect of life, whether by solving a current problem or introducing something new that will better the quality of life.

The genre of a public proposals interact with many other assemblages of texts that occur both prior to and after the generation of the proposal. Public proposals can either be generated by a city/town or submitted to the town for consideration.  The governing body of the town may identify a project that they wish to implement and generate a proposal to present to the public to persuade the town’s population to support their project. Before generating the proposal, the town will often ask the public for their insight to understand their needs, concerns and ideas about project. Once this data has been collected, the town generates the proposal with this feedback in mind and often submits it for a vote of public approval. Once approved, the project commences based on the criteria established in the proposals. Throughout this process, a representative body of the town will frequently communicate with the public, to convey updates on the project and to alleviate any concerns that arise.

Alternatively, a town may recognize a problem that must be addressed, but lacks the resources to solve it on their own. Often a town will produce a Request for Proposals (RFPs), which outlines the problem and asks for outside companies to submit proposals to address their concerns. An RFB is a common text that will prompt the generation of a proposal, and will always come before a proposal sequentially. Any proposals that the town receives are often discussed and voted upon at a Town council meeting, where both the Town Officials and the general public can voice their opinions and vote on the various proposals.

When a public initiative proposal is viewed under Spinuzzi’s genre ecology framework, it is easy to see the complexity of the genre. Their is some sequential activity such that a RFP will always come before the generation of a proposal as it prompts the generation of that genre, but many other texts occur in a overlapping fashion. Public opinion is collect both prior to the generation of a proposal and after work begins. The recognition of a problem or a potential improvement will mediate a discussion among the town’s population as to how to best approach it, and result in an interaction between the town and outside companies. The town may submit a RFB (request for bids) to various companies to perform that work, which will result in some companies submitting a detailed outline of the cost of their services. In addition, a proposal will often result in the generation of genres unrelated to the actual work detailed in them, as marketing campaigns are generated alongside proposals by those promoting them in order to sway public opinion. These could include flyers, commercials, or speeches in favor of the change and highlighting the benefits of project.

For Project 2, my group decided to work on cover letters for our genre. Cover letters typically interact with resumes, portfolios, and professional profiles such as LinkedIn; they are meant to either supplement or bolster the aforementioned genres by expressing the owner’s skills and desire to work somewhere. Cover letters are meant for relatively specific consumption but can be narrowed down to fit the particular needs of an individual application. For example, an engineering student applying for coop at a list of biotech companies could create a cover letter framework that contains 90% of the information about him and why he would be a good fit for the job. The remaining 10% would then be tailored to the specific needs of each company and position he was applying for.

Cover letters can be found in the hiring process of almost all major professional jobs. Those writing cover letters typically posses certain skill sets and drives that they want to make evident to those reading them, such as company supervisors and HR staff. Their goal is to promote and differentiate themselves when compared to other applicants in a more personable way than the straight facts of a resume.

The content of cover letters is usually formatted around the specific needs of the job in question; applicants will view the position and company background before tailoring their cover letter to fit the particular job. They will take into consideration what the hiring party values and then do their best to explain how they meet or exceed those exact criteria. They are effectively summing together all of their major traits and explaining how they could be put towards bettering the company.

The Spinuzzi reading helped me to think about how independent vs. overlapping cover letters are with other documents of similar genres. It will guide our research in deciphering which end of the spectrum, employer vs. employee, has more influence in shaping the format of cover letters.

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.

For writing project two, my team is focusing in on project proposals. More specifically public initiative proposals for projects that aim to improve a community by presenting a laid out plan detailing the problem at hand, possible solution and ways to achieve the solution. A number of different forms of both official and unofficial texts revolve around the planning, writing, and presenting of a project proposal.

Prior to receiving any sort of proposals, a city usually has to publish a public RFP (request for proposals) to inform the community of an opportunity to develop the city in some way whether that be to form a youth basketball league, rebuild the town library, or instal a new public art exhibit in the park or public areas. Prior to the RFP, towns usually hold a meeting or forum to discuss the possibility of implementing this new project and to gather ideas and opinions on specific details that the project should achieve. This information collected at the meeting will be the information that is processed and simplified down into a set of requirements to be published in the RFP. 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.

Genre repertoires seem like a very interesting perspective to take when researching the proposal production process. It is definitely meant to be communicative in an official setting. However a lot of the process that surrounds the proposal process is both sequential in its official format, but unofficially there is a lot of overlap between the different genres associated with them.

Our group decided to explore the genre of scientific blogging, in which an author attempts to break down complex scientific topics into layman’s terms so a broader audience can digest it easily. A “science blogger” would typically be an individual with a background in a scientific field but also has experience in explaining ideas unique to a field to individuals not involved in it. When trying to choose a topic to describe, they will typically wait for a breakthrough to happen that generates a buzz and sense of excitement within a field, which might spread and peak the curiosity of individuals in other disciplines. Their skill set allows them to parse through the jargon of any journal article or academic paper, and be able to extract key ideas to let the others know what happened and what sort of future impact it might have. It is common for them to use easily comprehendible mediums of explanation, such as comics, diagrams, or analogies in order to convey their idea as quickly and succinctly as possible.

While reading through the genre frameworks outlined by Spinuzzi, I immediately thought about scientific blogging while reading the description of Genre Systems. Spinuzzi describes the framework as “made up of sequences of genres that hand the baton of communication onward”, which is exactly what happens in the field of scientific blogging. A team of academics will put out some sort of publication that describes their findings to their peers in that field, and these bloggers will grab the “baton of communication” to create a blog post that spreads these findings and ideas to a wider audience. In this case, the “source genre” would be a journal article or scientific paper and a chain of communication branching from it might go to a scientific blog, and it can continue further to other genres such as comics related to the scientific blog post to aid in an explanation, or scientific video blogs where complex topics are broken down in video form. In order for our group to understand the genre we are studying, it is important to look at this chain of communication, to see how the explanation of ideas mutate at each link.

The genre my team is developing is of the translation of difficult topics from the complex to the vernacular. At a finer level, we are focusing not only on the blogging side of this realm, but more pointedly on those blogs which make a concerted effort to relate to, and entertain, the reader. This is accomplished by leveraging modularity of discussion, humor, analogies, images and a perhaps incidental use of first person.

The genre is akin to a veil being thrown over a swath of difficult to understand sources relating to a singular difficult to understand topic. If the author of the blog tailors the veil correctly, the sources that he/she relies upon to create the blog entry should be undetectable to the reader — instead leaving the impression that a trustworthy oaf who happens to be grounded on a particular topic is doing you the favor of telling you what they overheard two professors saying about it during a long elevator ride.

The benefit of a well executed example of this genre, is that it can spread with ease over the internet. Although in a sense sharing the entry on social media is transitively sharing the scientific papers and research that it is referencing, that of course is not the impression that is given off to the unsuspecting Facebook scroller.

In order to orchestrate this successfully formulated entry, the author must operate in a world in which he must act as a student when reading complex papers, be professional when interviewing experts, be relatable when detailing his/her conclusions, be sensitive to the efficacy of his/her style — making alterations accordingly, and wear any given number of other generic hats.

While the reading was a helpful reminder to view the generic elements with a more clinical eye, I found the dictating of genre analysis frameworks to be forcefully abstract. Perhaps considering the differences between the frameworks might have yielded a stronger and nonintuitive understanding of the purpose of each genre frameworks — and the benefits of each approach with relation to the others — I cannot shake the apathetic feelings of an engineer taking a writing course as to how much added insight can divulged by using the different frameworks listed.

Group 2’s Genre is definitely communicative. Looking at how people interpret and use feasibility studies, we see that it is more a collaboration of different texts. Certain parties may only interested (or even able to fully internalize) certain portions of it. Whether we are talking about an engineer observing a systems interaction paragraph of the study, or a financial analyst looking at the financing plan.

Analyzing feasibility studies as a genre system, we see it as a collaboration of many genre. For example a systems diagram, outlining the interactions of multiple databases, alone is just an image. Now while the informed observer might be able to get most of the author’s intention just from the image, the feasibility study as a genre system is concerned with many different audiences. Thusly the image, while summary in nature, is likely accompanied by a contextual paragraph or sentence. These collections become part of a larger image that has to be equally interpreted by many people, with many different backgrounds.

Throughout the genre system we see this many forms. Most segments have their own summaries, allowing you get quick versions of the aspects of the study outside of your field. This is important because these studies (often very large, 10’s of pages), can be observed by many people in conjunction. Our group was able to get in contact with a professor here at northeastern with many years in the software industry, he explained that these studies are normally received by a large board consisting of many senior faculty. These faculty have a broad range of backgrounds, but standard among them are senior engineers and senior financial / managerial staff. We’ve also read that these boards can consist of outside eyes, sometime ecological experts or government advisers, depending on the nature of the project. The study itself has to bring together many people, across many disciplines. In a way this is the genre systems defining feature.

A second, but important lens to look at the feasibility study through is the lens of research. Our genre (or genre system) is a direct response to a question. “Can we do this? Is it Feasible?” is the question asked. Answering this question, depending on the scale, will take many people, and the decision is ultimately made by many people in conjunction.

Design Entry 7: Reflecting on your first draft (200-500 words)

Use this entry to reflect upon your initial draft for WP2 and brainstorm potential changes to the schema. Below are listed some generative questions:

• How did you use the schema (i.e. what was your writing process, where did the schema figure into your writing process)?
• Did you find the schema to be appropriate for your rhetorical situation? Why or why not?
• Were there moments of tension where the schema felt constraining?
• Were there particular moments where an aspect of the schema helped you write your composition?
• How did your peer review partner’s composition look in comparison to yours? Did looking at someone else’s use of the schema prompt any potential areas of the schema that could be revised or made more specific?
• Are there aspects of the schema that could be made more specific?
• Are there documentation definitions that could be changed?
• Was using a schema you designed in a small group different than using the whole-class schema in the first assignment? How?
• List out some potential areas you might want to discuss revising your genre model/schema.

Our genre can be broadly categorized as edutainment, education with an entertaining twist. The genre includes a variety of mediums, such as texts with referenced images, comics, and video blogs. Since it is a conglomeration, it takes from academic genres (textbooks, journals, interviews, etc.) and presents them in a conversational manner. The following are examples of the genre: TED Talks, xkcd: What If, Computation Fairytales, the Cartoon Guide series, and the Manga Guide series.

Let’s take a look at two in the lists: Computational Fairytales and the Cartoon Guide series. The former introduces basic programming concepts through a collection of narratives. It first lays out the story for each chapter, and then presents the problem (loops, Big O notation, algorithms, etc.) with images to clarify the comparison. For example, it introduces Djikstra’s algorithm, a shortest path algorithm, by having the protagonist help a village find the most efficient emergency route. The village is divided into sections, representing the nodes in a graph, and connected by bridges, representing edges between nodes. Throughout, the reader is placed in the main character’s perspective: the reader learns the concepts as the protagonist learns or presents them.

The Cartoon Guide series takes another approach to the genre by presenting information in comic format. The books themselves do not have a concrete storyline, rather the characters act as a guide, occasionally making humorous commentary and references to make the text more entertaining.

Edutainment is a great learning tool, as it appeals to a wide audience from children, who are still learning basic necessities (language, calculations, etc.) to adults who are simply interested in new ways of learning. Certain items in the category may be intended for a particular demographic, but overall, they are for broad consumption.

The genre is a response to typical education techniques. It tries to engage its users to maintain their attention. It is not internal to an organization or field; it is created by those with backgrounds in the targeted subject or by a group of people focusing on different aspects of the composition (scientists, writers, artists, etc.). Additionally, it can prompt other genres, such as critiques, student essays/responses (like this one), and scientific studies (on its process and effect); and even inspire other genres, or subgenres, such as educational video games.

To form our schema, we can review examples of works in our genre and sort out their commonalities. Edutainment is broad, but perhaps the layout can include small sections with brief explanations of the topic and then relatable comparisons accompanied by images. We may also find it helpful to speak to the people who create in the genre. Another idea is to inspect the parent works that make up our genre first.

My group has decided to focus on public works proposals. We were all interested in the methods by which someone can go about persuading an audience that their goal is worth investing in. Proposals are common among any field that requires funding, action, or permission. Since proposals can be constructed by such a wide variety of people, it is interesting to see how different areas of society put different levels of importance on the same features.

Public works proposals are often the first step in an assemblage of texts that will complete a goal. Once a problem/ area of improvement is identified, a public works proposal will be submitted to a governing body, usually a town or state, that will then decide if the proposed improvement is worth pursuing. If the proposal is accepted, there will then be a RFP, request for proposals, sent out to the public that allows contractors to bid on the job. Once a contractor is selected, a contract is drawn up which will then lead to job completion. This entire process is kicked off by one’s ability to convince others that their proposal is worth investing in. Public works proposals have so much power because although they can be rejected, they also are unrestricted and do not require any preceding documents.

There are many types of proposals but I tend to look at public works proposals as parts of genre sets. They can be submitted from one person to another and are the start to a sequential set of actions. That being said, there is definitely some overlap when a group is constructing a RFP, they must refer back to the proposal to ensure that the original goal is properly explained. Similarly, all responses to a RFP will be going down a list, making sure all features of the RFP are addressed at some point.

For the second project, my group chose feasibility reports for our genre. This genre can interact with other texts such as technical reports, data sets, published studies, and journal articles. A feasibility report uses these types of texts in order to have factual support for a proposed solution. These texts are not confined to one space; they can be produced and used internally in an organization or field, and they can also be available publicly. For example, a technical report could be produced for a product in a smartphone company. This could be passed around to engineers who work in the company to help their development of the product. Later some of the technical specifications in this report could be released to the general public to advertise the product. Another example could be a psychology study that a university runs. At first this would be internal to the university. However, this could later become more widespread after it is published in a journal for a larger community to read.

The genre of a feasibility report usually is not meant for the wide consumption that the assemblages it interacts with can have. The people who compose this genre can be in a variety of disciplines. Despite this, they share the same goal – to convince another group or organization of the feasibility of a proposed solution to some problem. The group or organization that commissioned the feasibility report would be the one who reads it. They would then use the report to decide their next actions going forward. For example, a feasibility report could be commissioned by a computer company that wants to update their operating system. After reading the study that was researched and produced by another group of engineers, the company would consider what was in the report. If the study found the updates possible and beneficial, the company would go ahead with those updates. However if the study found problems with the updates, the company could take this information and try to find another solution.

For my most recent co-op I was working at a medical device company that produces tubeless insulin pumps for diabetics. As an FDA regulated company, I was involved with the design, construction, and execution of some of the many verification and validation tests we were required to perform by law.  Many of my peers and coworkers’ work and expertise fell very rigidly into the category of mechanical engineering. However, as a result of my preexisting knowledge of other disciplines, I was frequently put to work on projects that required interdisciplinary work. It is in my personal nature to seek to understand all aspects of a project, it is not required of the job. This can sometimes lead to the frustrating situation where, when working on a project with a partner with the same responsibilities as you, you are able to assist them with any aspect of work they are performing, while you are left to do the interdisciplinary work alone.

I think knowledge of many disciplines is beneficial to any environment, especially in the field of engineering. These days, few engineering applications can be found that can be considered “pure” mechanical, electrical, computer etc. work. The more you already know the more connections you can make both between your existing knowledge, as well as when learning new concepts.  Having interdisciplinary knowledge will make you a more valuable asset to any team.

At my most recent co-op I worked on a team of scientists and engineers to fabricate primary metal via clean electrochemical processes. The company, Infinium, was a fairly young start up composed of about 18 people.  We had quarterly progress/production goals that we had to meet to keep our investors giving us money and therefore had a lot of strict timelines. That meant that on a daily basis, aside from trying to work on our big picture problem (how do we make this metal production system work?) we had all kinds of more focused problems (how do we quantify the progress we have made on this particular aspect of our project? How can we do this experiment on a budget and time restraint?). Solving all these projects took the involvement of engineers, finance people, chemists, and a machine shop among others. On top of that, often times one person would fill the roll of two positions; for example one of my coworkers played the part of both engineer and lab manager, there was also a two month span when we had no finance people working for the company.

All this considered, my last co-op was the most transdisciplinary environment I have ever worked in. I realized that the most important part of making this all work was communicating effectively. Everything was accomplished quickly because of the fact that most of the time the whole company was under one very small roof. This also made it easy to figure out when we needed to reach outside for help. If no one at the company was well versed in a certain topic, we’d reach out to  other servicing companies to get answers.

Personally, I struggled communicating with my supervisor. I spent most of my time on a subproject focused on aluminum. My team was made up of only three people. My supervisor was not an engineer; he had a background in physics and chemistry and was extremely smart, but lacked practicality and some communication skills. Many hours were spent by my supervisor spit balling a bunch of ideas, and myself and the other engineer  figuring out which of his ideas we could actually apply. Communication improved as I got more comfortable with my supervisor and the chemistry we were doing; I started to understand what he was saying from the perspective of a scientists versus an engineer and I could give input as someone with a mechanical background. We made an unbelievable amount of progress in the six months I worked at Infinium.

It was a unique and rewarding experience to work at such an interdisciplinary company. It made me understand all the different kinds of work that make a business successful, and forced me to push out of my comfort zone and approach problems with a more open mind. Untimately, it forced me to collaborate with people who had all kinds of different strengths and expertise which I think is a fundamentally important skill to have as an engineer.

During my most recent co-op, I worked as a Systems Engineer at a small Cambridge startup involved in the emerging field of carbon nanotube (CNT) production. A production machine with the price tag of a mansion in a place called something like ‘Quiet Rivera,’ and the appearance of a grunge rocker’s winnebago is at the center of the company’s undertakings.

Given the unexplored status of CNT production, the unique element of necessitating research with engineering is the defining aspect of working at N12. You have to be focused intently on what it is that you’ve been trained in — as you are likely the only one doing it — and yet sensitive to the demands of the other specialities so that motors spin fast so long as CNTs grow thick. If I had been asked a week ago as to the degree of interconnectedness of the mechanical engineers, computer engineers, electrical engineers and chemists, I would have no doubt have ranked it as high as the scale I was given allowed for.

After reading Leavy’s paper however, some now evident points were brought to light that display the potential for greater levels of interoperability, in addition to the realization that the workplace could even have been categorized as multidisciplinary by Leavy’s definition. In hindsight, although engineers worked alongside each other and chemists in a familiar and highly accommodating manner, a deep understanding of each other’s processes beyond observable properties was minimal amongst the majority of the team. Some engineers would certainly fit the bill for transdisciplinarity, however the general attitude is that only the chief engineers of each field should be able to transcend their discipline — and with their analysis other engineers could be delegated.

It’s difficult to imagine how this bridge might be mended without taking team members off of their projects of interest. Thinking back on N12 fills my head with only positive adjectives, and yet I still don’t think that I will step back into my role there upon graduating. Questions over how I will bend my degree toward hardware or software, where in the world I might locate myself to do so, and the dreaded question of if I can truly see myself being a lifetime engineer are still present. Luckily there is still some time to figure that out, and maybe broaden my specialties as I do so.

I worked for an engineering firm, Qinetiq, based in Waltham. As a company our main sources of income, from my perspective (I only worked there six months as a low level software engineer), were government (Department of Defense) contracts.
While QinetiQ was known for its DoD contracts, it was made known that the company was attempting increase its commercial interests. While in Waltham, I mainly worked on a commercial product, namely PowerLine Systems.

A listing of products can serve to illuminate the “problems” we dealt with. We had several products that dealt with the protection of military forces, e.g., a system that provided soldiers with the vector of incoming fire, armor systems for planes and other vehicles (I saw pictures of Humvees), and robots used to defuse, or otherwise render non-dangerous, bombs. Our commercial products included the aforementioned PowerLine Systems, which took measurements of power lines (voltage, current, power factor, etc.), a system for measuring the structural integrity of train tracks, and a system that measured weather data.

My coworkers were mainly other engineers, mostly software (I am a computer engineer which is basically the same). I did interact with some mechanical and electrical but only on a casual basis. A few specific coworkers come to mind with regards to integration between disciplines, the people who wrote testing procedures. These people were not engineers but had to write extremely detailed testing procedures which are, of course, important. Interaction with these people was interesting as we had to explain how to ensure our products were of the highest standards to people that did not have our intricate technical training.

I do not, at this juncture of my life, have much of an interest in work like what I did at QinetiQ. It’s not that I didn’t enjoy what I did, I did immensely and I learned a great deal, but that I want to pursue another activity more, becoming a lawyer.

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

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

I had my second Co-op in EMC2 this Spring which is a data storage corporation. My job was to code in Python to test hardware. I have a cube and also a workspace in the lab. Beside taking about our work, we also chat about our lives some time. We had our own language which I could not understand anything in the first weekly meeting and that was the third day I started my Co-op. We had some software and website to do our job with is something similar with Oxygen and GitHub we use for this class. As an information science student, I’m more like a software guy but what I need to do was to test hardware which I didn’t have any experience with. Most of my coworkers are electronic engineers or computer engineers. I was the only female and the only software major. After 2 months, I was able to understand the hardware and develop software for testing. I think the work space was in an interdisciplinary level. If the problem was a hardware problem, I may not have the answer but if it’s a software problem, I had some ideas which was useful. I think this is the kind of job that I want to do after the graduation. I may not very outgoing but I do like to learn things and apply them into the work. I can learn things everyday and find some secret function about the website or the software and tell my coworkers. We always help each other and since I was the only female in the group and there are fewer females in this field, I feel my words mean something. I may look thing in a different way. Coding is kind of interesting when I can apply it not to the homework but to the real world. I still talk to people a lot, not only by emails but also face-to-face talking. I can’t face to my computer whole day without making a sound, I’m not a robot, but this job forced me to talk with my coworkers and solve the problem together no matter it’s a hardware issue or a software issue. I was happy that I could work in EMC2.

The company I worked for dealt with HVAC controls. It was a medium-size consulting firm (roughly two dozen people). We undertook problems regarding the HVAC systems for commercial buildings. The company was split into several sections, the most prominent being engineering and sales. The sales section dealt with online sales and specific orders, while engineering (my section) dealt with creating the control systems for projects where they did not know what they needed. There would often be overlap between the engineering and sales departments when it came to pricing of parts needed or backtracking to find what parts where already in place or had been sold in the past. While there notable differences in the knowledge and approach to HVAC controls that both departments took, there was very clear communication between the two of them. All the acronyms and industry language was shared and there were no language barriers in that sense.

Coop was a very enlightening experience for me in terms of how important industry experience is in a field and how technical skills are only a small part of your ability to succeed in the workplace. I can very well see myself doing the same work after I graduate due to both my personal experiences and the state of the HVAC control industry. My boss was a role model for me in terms of how well rounded he was in managing the workplace and a key part of my decision to pursue a Masters in Engineering Management. The HVAC industry is also sorely in need of younger workers due to other upcoming areas of engineering attracting a large percentage of the new workforce generations. The combination of the industry state and the flexibility my masters will give me will most likely leave a lot of room for me to grow and hopefully rise through the ranks of the HVAC control industry.

I spent my third coop working at a solar developer based in Boston. The company was broken down into Site Acquisitions, Project Management, Finance, Accounting, Construction, and Public Relations. During my coop, I spent almost all of my time working with the Project Management team, we oversaw all aspects of our projects including landowner and abutter relations, permitting, contracting, utility management and a wide variety of other project-related issues that could pop up on any given day. There were a wide variety of degrees that the people on the Project Management team held. The fact that one team was made up of -and heavily relied on – engineering, law, real estate majors and a variety of other specialists, helped me to realize how multi-disciplinary this role would be. Since each project passed between every group in the office at one point, communication was of extreme importance. Knowing how certain planning board interactions could reflect on the company, for example, would be a great time for the Project Management and Public Relations groups to have a meeting and chose the best course of action. In a company of roughly 40 people, keeping everyone on the same page can be a full-time job. However, maintaining enough communication for everyone to work effectively and draw information from all sides of the company is vital to the company’s survival.

I can absolutely see myself working as a developer for a renewable energy based company in the future. The engineering background is incredibly useful for talking with contractors and members of the constructions department, but is not absolutely required to be a developer. The main source of interest is the fast-paced environment that always allows for improvements in efficiencies. Since renewable energy is such a new field, there are no set rules of conduct laid out and this allows for people to work within their tams to find the best way to complete their goals.

I co-oped at two different places:  Novartis, a pharmaceutical company, and ChoiceStream, an online ad company. I did web development on internal applications for both.

At Novartis, I worked on a few applications for creating and managing samples for the oncology department. I don’t have a good biology background, so the technical jargon was a challenge. The development team was casual, but there was some overhead with planning meetings, getting approvals, and establishing a good base design down before development. This is reasonable though as its a multinational company and a lot of people rely on the integrity of the data. My mentor here was more of a scientist beginning but over the years he drifted into software development. A few of the other co-ops’ majors here were CS/Biology, Bioinformatics, and Math/CS. Overall, my experience here was wonderful! I still keep in touch, but I’d like to explore my interests.

ChoiceStream was smaller and more casual, and they had the incredible snack shelf and Bagel Fridays! A lot more goes into ad placement than I’d known (like how some of their developers use AdBlock! Gasp, their products worked too well!). I worked on some applications to track and generate ad campaigns here. I did a bit of automation with a tool called Chef, which had a bunch of cooking references for sub or related technologies (Cookbooks, Recipes, Kitchen, Knife, etc). Just pointing that out since many technologies today use common words in other fields for naming. In a way it’s helpful because the comparisons relate to the task, but it can also get confusing. It makes it sounds like I can cook, but really, I can’t.

In the workforce, you need to be able to communicate with a variety of people: other developers; management lead; users, whether they are scientists or ad operations; and HR. My main problem is my anxiety. It makes it difficult for me to ask for clarification, which is vital in tech, or really any field, where disciplines intersect. I also tend to have a soft voice with those I’m unfamiliar with. My supervisor joked about creating a curriculum to remedy that. It started off with, “Yell as loud as you can at standup!” Anyway, sorry to my group in advance!

I need to really think about what I want to do after I graduate (in…9 months? Oh, dear…). I’d like to get into game development to help people though, so I joined the ReGame VR Lab after researching for the first writing assignment. I’m starting off simple first, but so far, I really enjoy it!

At my last coop, I worked at a large financial institution in New York called Goldman Sachs. It might seem like an odd choice as a computer science major, but they are becoming reliant on technology to keep the company up and running and as a result, almost a third of the company now has some sort of technology background. However, being a finance company, I had to regularly interact with people coming from finance backgrounds, and all of my projects ended up being related to finance. When first getting started there, it was interesting to see how my coworkers in technology would interact with their finance oriented peers versus the technology oriented peers. With their technology peers, they seemed to talk more openly about projects, and use plenty of jargon that was relevant to the technology industry. When talking to their peers in finance, they would choose words carefully so someone without a technology background could understand the idea they were trying to convey. It was the same the other way around too: I noticed that my finance peers would use a lot of analogies to when trying to explain financial topics to us. When communicating, both sides had to cut down on the disciplinary jargon in order to convey their ideas to each other.

After talking some of my coworkers, what surprised me was the diversity in college background of various people working in finance. Sure there were a decent amount of people who majored in finance, but there was also a significant amount of employees who majored in disciplines such as psychology, history, engineering and english. A question I would commonly ask is how they applied what they learned in college to their current position, and I got a variety of interesting answers. For example, a psychology major explained to me that his discipline gave him the ability to better understand how the human brain works, and he could use that to be better at managing his team. The English major told me that his discipline helped him convey his thoughts and ideas clearly, which helped in emails, meetings and when giving presentations. Overall, this coop had more transdisciplinary interaction than most computer science coops, and let me improve my ability to communicate with coworkers who come from various backgrounds and disciplines.

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.

I worked at Corindus Vascular Robotics for my co-op. It is a small to medium sized company with about 80 people. There is a huge variety of disciplines. The engineering department includes manufacturing engineers, software engineers, electrical engineers, and mechanical engineers. Outside of this, there are people who work in shipping, finance, IT, and marketing. The company has built a robot that aids surgeons in percutaneous coronary intervention (PCI) procedures. As part of the software team, I dealt with coding the robot. Working with the code involved programming new capabilities, fixing bugs, and creating supplemental testing applications. Work within the software team was mostly mono-disciplinary. However, we sometime worked with the electrical team when there were issues between our code and the hardware. For example, we had a bug where the system would throw an error when certain motors crossed voltage regions. My team also worked with manufacturing when we developed tools for them to test the robotic system. These were some inter-disciplinary experiences that I had.

For the most part, I focused on projects within the software team with little interaction with the other disciplines. Obviously this was very mono-disciplinary. However as mentioned in the previous paragraph, there were times when my work was inter-disciplinary. Outside of the research and development lab where I worked, a lot of the company was multi-disciplinary; manufacturing engineers, electrical engineers, software engineers, and mechanical engineers all worked on building the same robot, but they mostly did not integrate. Each team mainly focused on problems within their disciplines, and used those collectively to design and improve the robotic system.

After graduation, I could see myself doing this type of work. I liked the research and development environment I was in. There was always work to do, and there were a variety of problems to solve. I had the freedom to come up with my own solutions, and my work and my code directly contributed to the company’s robotic system.

In the problem statement of Chris Murphy’s first writing project, he deals with his discipline directly. Contrariwise, I discussed an issue that exists on the periphery of my discipline. From my point of view, this is indicative of my lack of desire to work directly within my industry (computer engineering). I want, at this point, to work as some form of litigator, or at least to work within the judicial system, while Chris, being most likely a more rational person, identifies a problem within the industry with which he has actual training.

Looking at Chris’ markup, it is much cleaner than mine. The indentation is more uniform and the spacing between each citation makes the whole document easier to read, directly in contrast to my bibliography which is generally describable as haphazard. In the domain of similarities, we made ample use of the “general” and “application” attributes for the summary and relevance tags, respectively.

Looking at Chris’ bibliography and others from this class does make me think about what I would do differently given a second chance. Probably the main change is that I would have a more focused problem statement. Chris’ statement is focused and to the point, mine is rambling and frankly doesn’t even come to a point by the end. This can be generalized to the whole document in saying that I wish that I could have put more time into it. This final point is something that I wish about my entire life.

For design entry 3, I compared Oliver Scott’s annotated bibliography to my own.  Oliver and I essentially identified the same problem, global sustainability. Oliver specifically focused on the wasteful habits of the current American population and spent time discussing what had changed since World War II; when Americans willingly went without goods and comfort to ensure the success of the war effort. Since then, he argues Americans either don’t care that sustainability is an issue or haven’t fully recognized the problem we face. I focused on the need to develop large scale renewable technology and the economic issues these projects must overcome to be successful.  Oliver’s discipline of computer engineering allowed him highlight specific technologies within the field of automated trash sorting that will help improve the efficiency or reliability of these systems to reduce wastefulness.  I read Oliver’s problem statement prior to knowing his discipline of study and was surprised to learn he was a computer engineering major as he took a very historical and analytical approach to his problem statement. Oliver’s commentary about what had changed in American society in just a few generations was very interesting and he seems to suggest that since society as a whole does not care enough to reduce waste, we must turn to technology instead.

Oliver broke up each part of his citation into separate lines which made it easier to read and seemed better organized than my own, which I left in a varied paragraph format. Oliver and I used the tags in about the same way, but he consistently broke up the citation into several more parts, often using two or three types of the summary element. As a result, I thought his document was well organized and would prove to be easy to code. Oliver also did not try to explain the specific technologies that he mentions in the annotated bibliography which I think works better than what I did in my own bibliography. If this annotated bibliography was written alongside a larger work, I would not have written as extensively, as I felt the need to explain the technology in order for the average reader to understand. While I liked Oliver’s organization, I believe having the 5-6 element tags can cause the annotations not to flow well and make the transitions from one section to another somewhat difficult. I struggled with the transitions in my own annotations and I consistently used 3-4 tags. If I could change anything in my own bibliography I would better organize my citation sections and reduce some of the content in the annotation regarding the technology.

Chris Murphy’s annotated bibliography focuses on the issue of sustainability. His research focuses in more specifically on the use of electric vehicles instead of combustion engines for public transportation and waste removal. In the problem statement Chris addresses the larger effect that these two types of vehicles already have on the environment as well as the population as a whole. He discusses how his discipline gives us the tools that we need to address this problem if only people were to make the effort.

I found that although the overall method with which Chris presented his problem came across quite differently than my own problem statement we ended up drawing the same conclusion on how our discipline can help and why these problems have not already been addressed. In my problem statement I focused much more on why the problem I was researching was important to me rather than focusing on the people that it would help. I did this because the problem that I presented focuses more on personal preference and a tendency to avoid unnecessary waste while I know that many people would disagree with my desire to preserve older buildings for aesthetic reasons as well as economic reasons.  Chris’s problem is one that I think everyone can agree is something we should work to fix.

Looking at his XML formatted document the biggest difference that we had was our use of different citation styles. He also kept quotation marks in the code itself while also calling it out as a quote which lead to double quotation marks in all of his formatted annotations. We both tended to only use one type for background, summary, and relevance for each source. However Chris seemed to only use general summary every time and application relevance every time.

Overall, I do not think the Chris and I’s annotated bibliographies were all too different in format. I did enjoy the consistency in his annotation format but I do not feel like that would have worked as well considering the sources that I chose to use and for the problem that I was addressing. The one thing that I would take from reviewing Chris’s project was the straightforwardness of his problem statement. I like its simplicity and the fact that it is to the point without adding extraneous information that is unnecessary in a review of this format.

Reading Leo Stolov’s annotated Bibliography, it is very similar to my own. We both chose issues, that while not dangerous, represent inefficiencies/failures. These quality of life improvements represent our efforts for quality as engineers and developers.

Leo’s problem statement did a very good job of breaking down the problem. After reading his first paragraph, I immediately understood the individual components of the package delivery issue in Boston. He explains it in a way that any one (especially outside of a technical profession) would say “Obviously the way we do it is not ideal”. I also like that he summarized a potential solution right in the problem statement, something my annotated bibliography sincerely lacked.

The first thing I noticed about Leo’s sources is that he has a good mix of news stories and papers. I attempted to bring the same mix of our sources to my bibliography, and I believe it creates a valuable diversity.

Looking at his XML source, his code is very clean. The lines are broken at very precise intervals and he also spaced out any multiple authors into a new line. It makes his code clear to read by highlighting the sub-elements, and overall shows a carefulness and professional approach to his code. I noticed that he broke down some of his relevance and summary paragraphs into different types. Meaning that he would have two different summary’s or approaches with different types to the same article. This allowed him to really highlight the way he breaks down his thoughts. I found myself struggling to match myself to certain definitions, but Leo just incorporated both. I had not thought of doing so, but now will to help better define my own thoughts in XML.

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.

I read Seth Bakes’ annotated bibliography. He’s major is Computer Science related so that he defines his discipline very technical. The problem he found is the website for Co-op search. Although I’m also in College of Computer and Information Science, my major is Information science which is less tech than CS major. He found out that the website has a poor user interface and poor navigation for the user. The resources he found are also very technical which can be hard to understand if the reader doesn’t have any experience in website design.
The way that he uses tags in XML is similar with mine but he has only one field for his background, summary and relevance. I made my tags in more details. If read XML file only, Seth’s file is easier and cleaner than mine which makes me think if it’s better. The citations are different than mine, I used APA for my citation style while he uses MLA style.
This comparison helps me know how other students write their annotation. If I have a chance to make some changes to my own annotation, I would find a resource for methodology. In my case, I found the problem of parking, however, all my resources are topically related. I didn’t use methodology resource but I had some examples from other city solving this problem. I think I should find some article about city planning.

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

Looking through Ben Gincley’s annotated bibliography was an interesting peak into another discipline, and what kind of work they do. Ben discussed the field of neural engineering, which is a relatively new field in which they are trying to find ways restore lost neural functions. The initial difference I saw when comparing y annotated bibliographies is that Ben’s covers a slightly broader topic. My annotated bibliography was focused on the specific problem of detecting lead paint in Boston houses, and Ben focused more on discussing breakthroughs in ways neural engineers are helping paralyzed individuals get back to having normal lifestyles, whether that be through improving their means of communication or giving them mobility again. As a byproduct of this, my sources ended up being selected from a wider range of genres to build up to a solution to the initial problem I brought up, and Ben was able to pull mostly from scientific journals and papers to discuss his discipline.

Looking at the XML markup, Ben and I seemed to agree on in which of the “buckets” we should put different ideas we were trying to convey. We both followed the order of giving a background, summary, and then explaining the relevance to the topic we were discussing. One of the differences I see is that Ben’s XML looks much neater than mine. A clear difference is that his lines wrap around to the next line when they are too long, and end up fitting in the margins while you have to scroll to the left, past the margins, to finish reading each of my lines. It’s definitely something I’ll look into improving in future writing projects.

Tammy Huynh used her annotated bibliography to research the newest virtual reality (VR) developments as well as their potential applications. Both of our bibliographies address ways in which certain groups can have their lives improved by a development related to our major. However, Tammy’s ability to address motor disorders through computer science clearly shows how one’s understanding of their major combined with unique personal experience can open up incredible technological uses that non-specialists may have never thought of.

Regarding the use of XML editor, Tammy displayed an impressive ability to retain document fluidity by having sentences broken up in the middle by the appropriate tags. There are several instances of the background of a source transitioning seamlessly into the source summary. This layout reduced repetitiveness and increases readability in a way I wish I had thought to incorporate in my bibliography.

Tammy and I used the tags relatively similarly. The largest difference in our use of tags was that Tammy would often write the majority of her posts within the general summary or application summary section. I feel as though this better explained the aspects of her focus that the reader may not be familiar with. This strategy worked well for Tammy, however, I believe my argument was served properly with a more relevance-focused annotation.

I read through Dan Doherty’s annotated bibliography, which similar to mine, dealt with the problem of fossil fuel use and an increasing need for renewable energy sources. While my articles focused on transportation, Dan’s focused on infrastructure. A notable difference in our problem statements though was that he focused mostly on the solutions to creating greener solutions for cities, while I focused more on targeting the problems that needed to be addressed.

Looking at the XML markup for our annotations, we both used the same general structure of background, summary, and relevance for our 3 tags dividing up information. A notable difference between one tag-use though is summary; I used it once per annotation to encompass a major point of the article, whereas Dan used it several times to further break up key points in his articles. With this added degree of specificity, he also further categorized his summaries as general, interpretation, and approach, while mine were mostly general statements.

After viewing Dan’s article, I view my article as more concise but maybe too brief in areas. It brings back the question of balancing conciseness with adequate support for an argument. I do not believe one way is more correct than the other, but that instead it comes down to purpose and target audience of the annotations. One thing I would potentially change about my annotation though would be lengthening some summaries beyond a general statement to give the reader a more well-rounded idea about the articles.

I read Chris Murphy’s annotated bibliography that dealt with fossil fuels and sustainability. Specifically, he looks at fuel efficient vehicles that would reduce the amount of fossil fuels being used. In Chris’ problem statement, he gives a brief background of the issue of sustainability in Boston, and he follows that by saying that his discipline of mechanical engineering can help solve that problem. This structure is similar to my bibliography. However, he uses his discipline to look a very specific topic of combustion engines and electric motors, while I focus more on general skill sets used in my discipline.

Overall the markups look similar. Both of us use APA style for our citations. Both markups also contain a similar structure since everyone in our class wrote these using the same general schema. In Chris’ annotated bibliography, he uses the same structure of background type source, summary type general, and relevance type application except for one annotation (where he uses background type author). In my annotations, the types I use are more varied, and I have different combinations of them. Sometimes I have two types for an element, like a value statement and application for relevance. After comparing these bibliographies, I do not view my own differently. Neither piece is better than the other, they just have different content and styles.

Ben Gincely uses the study of his field to approach a much broader, and transdisciplinary issue than my topic of automatic waste sorting. In investigating neural engineering, Gincely investigates an issue in not only a vitally applicable realm, but one in which further research is demanded. The nature of this topic seems to be reflected in the approach to his problem statement, which has a greater emphasis on providing the scientific context of neural engineering, than the societal context I provided in my own annotated bibliography.

The XML content of Gincely’s citations had a higher degree of complexity than my own. He leveraged the title ‘level’ attribute, in addition to providing untagged text.

Of note for the annotation content, Gincely opened each of his entries with more in-depth research on the people and institutions behind each source. Additionally he managed to maintain a smoother transitional effect between sections, aided by the choice of not forcing every element attribute variant into each entry. This is primarily seen in his forgoing of the summary ‘interpretation’ and relevance ‘value statement’ attributes.

Lastly of note on semantics: Whereas in my work I used inconsistent (and in some cases incomplete) citation styles, Gincely’s work was of more proper formatting. Unfortunately I hadn’t thought to look at the provided examples earlier on in the project, however in hindsight I should have corrected myself to fit a description closer to Gincley’s. Additionally, the flow of Gincely’s annotations provided for a more fluid reading experience, however I am unsure that I would have been able to accomplish the same without breaching the 200 word limit.

Using XML markup on this project did not feel like a drastic change in pace for me. My writing process usually involves creating an outline and then fleshing it out with detail until it’s almost the prose that will be in the final product, so in a way, using a markup language was very similar to this only with the addition of some extra technical formatting.

The development of the schema as a class had both its pros and cons. By composing the schema as a group, a good portion of the preliminary work I would do in structuring the assignment was already done. However, at times I felt the thought I wanted to express had to be slightly contorted to fit into the rigid structure we had created.

The XML formatting was more restrictive than what I’m used to. I missed being able to add certain characteristics that weren’t built into our schema (italics, bold, etc.). That slowed my writing down to a crawl, but overall, it was an interesting way to organize thoughts. Paired tags made it easy to locate material and view metadata (like number of authors and revision number). It ties in well with version control too. I like that we had our own associated document, so I could just update mine and not accidentally break others’ documents (like I did on co-op). I’ve only used Git for tracking code, but I could see myself using it more for creative/technical writing, especially for stories to see how they change overtime (and cringe at how they started out…).

I didn’t like that the schema was set so that the background tag was required before the summary (and other related positional constraints) because sometimes I prefer to give a brief description tied to the summary first and then lead into the source. Sometimes variety makes a more interesting read. Viewing XML, at least in the process of writing it, wasn’t as clear-cut as just using a regular word processor. For example, I kept clicking the indent button so that my text wouldn’t run off screen. Hmm, I’m sure there’s a way to set that though. I don’t mind using Oxygen for future assignments; I’m just more familiar writing differently, so it’ll just take a bit of time to learn shortcuts to create a steady workflow.

On a related note, annotated bibliographies provide a good reference for both the composer and others to review sources and see how they relate to current projects. With that in mind, structuring it with XML makes it easy for others to get a sense of our thought. It’s especially useful for peer reviewing later since our different concentrations shape how we write.

Writing in XML markup definitely changed my writing process. Whenever I write, I follow the prompt and make sure to respond to all parts of it. However, my writing seems more natural when I am not using XML. I think that this is because the markup schema has a rigid structure. All of the elements are explicitly blocked out. On one hand this is good because it reminds you exactly what you need to include in the writing project. On the other hand, it makes my writing feel more disjointed.

For my sources, the schema that we created in class seemed somewhat awkward. In all of the examples that we saw, each source was an academic book or article dedicated only to the research topic. Some of my sources were different because I was researching ways that electrical engineering skills could be applied realistically to solve different food crises. Some articles gave brief overviews of different companies’ products that solved these issues. Since the articles were not research papers, there were obviously no experiments performed whose “approach” I could describe. Also, I could not point to these articles and say that they represented some kind of foundational text like I could with a published paper in a journal.

From Genre as Social Action, genre represents action with a situation and motive. In this project’s annotated bibliographies, the situation is finding relevant sources to a problem our discipline could solve. The motive is to show these sources and explain why they are valuable to us. We accomplished this by writing the annotated bibliography according the schema. In this, we included a problem statement that explained how our discipline could solve a unique problem. In the annotations of sources, we gave some background on the source we used to establish credibility of the author or source. We also gave some summary of the source’s content, and we later explained its relevance.

The process of the first writing project is a little surprised me when I need to use XML for a writing class. I thought writing is something that I need to describe my thoughts clearly, XML won’t make any differences. However, not as I thought, writing in XML did help me for annotating bibliography. Using XML as a coding language is not hard for me as I code for other classes. But writing in XML is different. What appears in Oxygen doesn’t look right and I can’t do any spelling check, formatting check (formatting check here is the format of an essay like spaces and punctuations) and words count. I had to commit to master when I was done for the first draft and check the formatted file online to see if I need to change anything. The schema which we discussed in class helped me think about the sources. Before, I may just write something, but by using schema, I can write and think. It makes my writing more fluently and more logical. I might have some redundant meanings of my essays before but schema avoids it. For using Oxygen and GitHub reminds me about my Co-op. I had similar process for submitting code in my Co-op this spring. I need to edit my code first, make sure it’s working and submit it to the workspace that my group shares. Every time when I submit something, I need to note it. The process is the same as I do for this project, sync, write description, commit to master and sync again. I need to find sources first and then using the schema as a guide to annotate it. GitHub keeps tracking the changes that I made and I think it’s going to help for group projects so that we can sync and edit and track the changes. Using Oxygen is not a problem for me and I’m glad that I can learn and use XML for this class.

My immediate takeaways after completing the first assigned project are likely the intended ones. The strict structuring of XML provided an ideal means of making explicit the context and weight of each sentence. I began the project with an understanding of these implications however, they were made painfully more clear after rereading the project guidelines once completing my annotations.

As I had begun my project without the word count restrictions in mind, rereading the instructions necessitated cutting several sentences from each of my entries. Although such a realization tastes like sour lemonade when the alternative is going to bed, the process heightened my understanding for the economy of words. Tailoring the delivery of the annotations to fit these constraints without sacrificing meaning was an important, and dare I say, even a gratifying step in the writing process.

In hindsight I think the schema’s structure for source/author background could have had a more open definition. The running definition placed an emphasis on providing credibility for the source/author, that I believe was perhaps overstated. Attempting to both hone in on the chops of the source/author, in addition to giving a general idea of the goal of the paper — without treading into the summary section — felt somewhat unnecessary.

Another uncovered area is that there were no restrictions in place on mixing and matching different citations styles. During my project I (regrettably) used a mix of APA and IEEE. Although I didn’t think about consolidating all sources under a single citation style, I assume that there should be a homogenous method of citation, and mixing and matching wouldn’t be permitted. Or maybe I’m wrong about that, hope so!

Oxygen as a development suite seems to have all the nuts, bolts and autocomplete features I would want from any IDE. Organizing future projects using Oxygen seems like a fitting way to leverage XML to structure future writing assignments.

This writing project was my first time using an XML markup instead of a normal word processor and the results were quite different. Overall I felt as though I spent more time focusing on the format of the processor than on the actual content of what I was doing. One of my biggest weaknesses is programming and it was hard for me to adjust to the format of the command window with a language I was unfamiliar with. Part of my problem was that I didn’t know what I didn’t know; once I had the general gist of how to structure my annotations, I was unsure whether or not I had correctly divided and marked them up in the processor.

In the end, I reverted back to laying out my annotations in a traditional style in Microsoft word and then cookie-cutting them to fit into the XML file with correct formatting.

Once I got past the struggle of learning XML, I noticed that it had prompted a new way of thinking and organizing thoughts. I typically think of literature and science as two different, if not polar opposite, fields. However, XML forced them together by taking a scientific and structured approach to literature. It broke the literature down into its most basic elements, which created both clarity and confusion. On one hand it identified every unique aspect of the annotations and created a framework/guideline for future ones. On the other hand though, it drew from our recent readings regarding genre and brought up questions regarding “what is this genre?”, “who says this is definitely how this genre is classified,?”, and “is this the only correct way to classify this element?”.

I feel as though science is a field of definites and literature is a field of subjectivity, and therefore there will be problems regarding crossing both of them over. I think that focusing more on the actual writing and practice of it would be more beneficial than using Oxygen and analyzing how to break the writing down.

While completing Project 1 I felt like XML was a hindrance to my writing process as I constantly had to stop and consider which element or attribute best fit each part of the annotation. I often found that parts of the annotation could be categorized as either a general summary definition, an approach or some combination of both.  The mark-up schema was useful for ensuring I completed all required parts for each citation, but this could have been achieved by following a checklist and completing this assignment in a standard word processing format. The mark-up schema made the annotations somewhat choppy as it was difficult to add sentences that allowed for transition between two sections as they did not often fit well within an element.

XML proved to be a fairly straightforward mark-up system and I was able to navigate fairly easily with very little prior experience working with similar technology. I found that the hardest part of the technology was understanding how to sync Oxygen and Github and upload my completed file. However, this should be much easier in the future now that I have done it once.

The schema proved to be somewhat restrictive as I was writing the annotated bibliography as some types of writing, such as research reports or a thesis had not been defined within the schema, but this could be easily resolved by adding those types into the element. While developing the schema in class, I believed that the more specific the schema could be the easier it would be to create the bibliography. I found that the broader types of elements that were built into the schema allowed for an easier flow of writing as I was not worried about the constraints imposed by the schema.

I believe the social action of the genre of an annotated bibliography is for the author who cited the sources to provide some justification as to why he thought they were valuable to reference in their work. The short annotations along with the citations allow the audience some insight into the author’s thought process as they developed their project and the arguments they attempt to make in their piece of writing.

Oxygen is a fairly straightforward system to use and I believe their is some benefit to the development of a schema before beginning a writing project in order to create a basic outline for that piece of work.  However, I do not believe actually writing the project in Oxygen has any added benefit after the initial schema is created.

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

The processes of creating an annotated bibliography in XML was definitely different than any other english assignment I’ve gotten. It provided an interesting experience of trying to convey the information I wanted in a way that would flow in an intuitive manner, and also fit the schema we put together. I had to give significantly more thought into how to phrase what I wanted to say, so I could also match the definition of the type attribute I was trying to write for. I do feel like the XML structure obstructed my writing process, but it did so in the same way a gutter guard would obstruct a bowling ball from going in the gutter. Having to use the structure kept me more focused on what I should be conveying in an annotated bibliography, rather than rambling and getting off topic. It also made me give more thought into what sources I chose for my bibliography. There were a few sources that I ended up not using because after I read through them and fitting them into the schema, I realized that the information wasn’t as useful as I initially thought it would be. From a technical perspective, it wasn’t too difficult it get used to. Really the only technical obstacle to overcome was learning how to navigate my way though Oxygen, and then figuring out how to test my final XML document in a normal format. Being a Computer Science student, the portions of the assignment where we had to use Github were’t new to me, and didn’t cause any problems.

Continuing to use XML is going to be a process that will take some getting used to, in both adapting my writing process for it and learning more about the technical aspects of it, but overall I feel I will come out in the end being able to more concisely and clearly express my ideas and thoughts.

During writing project one, I found the schema we developed to be a useful tool for staying in track. The general flow that was considered during the schema development was applicable to all of my sources and allowed for the construction of a legitimate argument. There were a few notes I omitted to allow the overall annotations to fit the schema layout, but overall, I felt more guided than hindered in my writing. Although the layout takes some time to get used to, I now see how proper utilization of Oxygen will allow for less restricted writing in the future.

Regarding technical difficulties, XML is relatively intuitive. The only major point of concern is that using a track pad to highlight portions for editing can be difficult considering the sensitivity of Oxygen. This can be remedied using keyboard shortcuts. The other primarily technical concern was that we were not sure when we would be able to check our work. I propose that moving forward we have set times we can expect our work to be uploaded so that we will know when we can check it. This is only an area of concern since we have other classes that require us to prioritize our time. As it stands, I don’t think I can effectively read my work in XML to ensure quality. I really appreciated the example file to check my work against.

Our schema was sufficient for the first project considering how concrete annotated bibliographies normally are. Moving forward, I would like to add more optional fields that can be used when most appropriate without forcing all entries to look incredibly similar. I see the value of breaking down our writing in this manor. Breaking down professional pieces and then rebuilding with their framework is a good method to reduce the amount of content lost in translation between class and homework.

Generally, I struggled to keep ideas flowing rather than have each section obviously outlined. I think if we consider of the order of our fields while constructing our next schema, we will all be able to write much more fluid pieces that contain all required aspects we define without sacrificing the readability of the document.

Our first writing project was my first real experience using a mark up language. I had worked with HTML really briefly before, so at least I wasn’t terribly intimidated by working without a text editor, but aside from that, I went into it completely inexperienced. As a whole I appreciated doing this project. I feel it’s a useful skill to have learned a markup language, and the learning-through-doing aspect of it was very helpful. The fact that I had a project to complete forced me to really get a workable baseline understanding of XML, Oxygen, and GitHub. The markup schema we came up with in class served as a very good checklist of sorts. It was helpful to basically have boxes I had to fill in to complete each annotation. It also helped me make sure that what I was writing actually qualified as an annotation and not some kind of weird tangent. XML on it’s own was also fairly easy to understand, the hardest part was probably understanding how all these programs worked together to make my published project on the WordPress page. I still don’t think I know how GitHub works, but thats a work in progress.

My only gripe with having done project 1 in XML is that I feel like I got distracted from the ultimate goal of making an annotated bibliography. I was focused on learning XML and building and understanding the schema that I feel like I didn’t allot enough time to finding appropriate sources and thinking about what I really wanted to make my bibliography about. With design entry 1, I genuinely just came up with something that I think is the biggest problem in Boston (transportation/traffic). When it came down to it, it was really difficult to find sources that I felt were applicable and well focused on this topic. I tried not to stray too much from my original idea, but my problem statement in Project 1 is about lighting in Boston which is related, but different. There also isn’t much that would be a city/campus related problem that would call for expertise from a mechanical engineer before some other kind of engineer too, so I wish I had taken more time understanding genre analysis and finding ways of applying it to something I can relate to. Basically, I think that had I not been working through the XML learning curve, I would have accomplished better annotations and compiled much better sources. That being said, now I know, and shouldn’t run into the same problem with Project 2.

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.

Over the course of completing the first project, there were a few things that I noticed using XML to write a paper (which I had not done before). First, I was not used to writing XML with such strict standards. Through the course of the co-op that I just finished, I wrote and read a fairly decent amount of XML, as we used it for configuration files. XML of this ilk is not particularly rigid, especially as it was only used, to a degree, internally. In that setting we could pretty much add or subtract any elements we wanted without noticeable repercussions. So getting used to writing within the bounds of a specific schema was rather interesting. Not to say interesting, i.e., bad, quite the opposite in fact; the ability to know, essentially, exactly what was going to be within each element was quite pleasant.

Using XML to create my annotated bibliography was novel and rather refreshing. I would say that the key enjoyable element was how explicit the structures were. Normally when one is reading, the various structures (the citation, the elements of the citation, the elements of the annotation, etc.) are implicit, our minds just understand them. In this format, one has to think very precisely about what to write. Having this relatively rigid structure helps to organize thoughts which makes for a more efficient, and often times more satisfying writing experience.

As we move on to projects 2 and 3, I don’t really think that the schema needs a lot of revisions. For my purposes, as simple as they may have been (I’ve no idea what anyone else did), the schema worked just fine, although I wasn’t really able to find a real, solid use for the value statement attribute of the relevance tag. As far as composition goes, I really only used Oxygen to look up attributes for tags and to validate my XML files. For the actual writing of the bibliography, I used vim (more specifically neovim), but I realize my choice of composer is rather unusual.

Overall, I would describe my experience with project 1 to be quite enjoyable. To me, the concept of making generally implicit (except in maybe some post-modern books) genre structures explicit is borderline revelatory.

Writing our first assignment in XML format had a significant impact on the way that I wrote. Being someone who is used to writing most of my assignments in a word processor, I will admit that I did actually start the project there and then transferred it over to XML in pieces. Having that XML format and having the class defined attributes was a huge help when it came to focusing my writing and making sure that I was able to address everything that I needed to.

However, my biggest struggle with the program was the inability to format certain ways. For example, quotations were only allowed in the background and summary portions of the annotations where I had gotten a quote from a source pertaining to its audience and relevance. For my problem statement I would have liked to make it so that different statements were grouped more obviously by adding paragraphs, however the program would not allow for this type of formatting here. Additionally, as person with pretty rough spelling abilities, not having the autocorrect function that seems to have made its way into all of our typical forms of communication in today’s society was really hard. Having the lines of text continue out beyond the bounds that were easily visible in the markup program made it hard to be sure that words were correctly spelled, that grammar was used properly, or even if all of the different parts that we needed to include flowed together properly. Being able to see the formatted version online after it was synced and uploaded was incredibly helpful. I just think it would have been more helpful if that upload happened instantaneously so that we could make corrections as we went. There were a couple of occasions that I read the formatted product and realized that sentences were not stringing together in the way that I had intended or that punctuation was clearly missing in the different citations.

Overall, I think that writing the final project in XML format was a bit unnecessary and that all of the benefits that I got from having it could have been taught or displayed more easily in a simple outline of required elements. However, that could be a personal preference due to the way that my brain chooses to organize information. This XML format may make more sense to other people.

The beauty of being a mechanical engineer is that they are involved in all aspects of engineering and problem solving; engineering and problem solving are integral parts of most public service industries. That being said, mechanical engineers can be found holding all kinds of job titles and working in a huge variety of industries.

Boston boasts being a youthful city full of innovation because of all the colleges and universities that it hosts. However, Boston is also one of the oldest cities in the country and has an extremely dated and inefficient transportation system to go along with it. Services like uber and hubway are extremely popular because of how difficult it is to travel via train within the city. Even Uber and biking pose their own challenges because traffic can be debilitating and biking among Boston drivers can be dangerous. Despite Boston being relatively small, it can take unreasonably long for people to commute to work and school because of the outdated MBTA system and the mess of roads and traffic inside the city limits. Aside from being an inconvenience, poor transportation systems also contribute to safety concerns (especially in the winter) and the huge influx of people who try to live inside the city because it’s too difficult to commute from somewhere else.    

Although transportation and infrastructure are issues typically handled by civil engineering/consulting companies, it is an issue that needs more hands on deck. Tackling this problem will take lots of financial and practical planning that would involve several types of engineers. Reorganization of the transportation system and updates made to the MBTA could massively improve the state of things, but as a mechanical engineer, I wonder if the implementation of an entirely new transportation system would be a more effective fix? What alternatives could exist to make traveling in Boston less of a problem?

In the current field of mechanical engineering, many endeavors are focused on taking existing technologies and making them more advanced and more efficient. Most of the modern equipment we use has been around for decades, if not centuries. What separates the current equipment from its older iterations is how well it can do its job and how little energy it can use. Examples of this include cars, whose mpg has increased drastically in the last half century; planes, which can now go much farther and faster, all while using less fuel; and trains, which can now transport more cargo using less energy. Major examples aside, even simple products such as bikes have changed as a whole to expand the different terrains they can handle and create a smoother ride. The case in point being that almost all the technology we need exists, but it is up to us to continually improve upon and enhance it.

The discipline I am currently studying is mechanical engineering and a common crossover between my studies and outside life can be found in transportation; it is one of the largest consumers of fossil fuels and is full of inefficiencies that are often distressing. After living in a city (Boston) for the last 2 years, one of the largest inefficiencies I have noticed is with the city buses. They all run on diesel and make frequent stops. Often times they are driven by impatient drivers who accelerate and break rapidly in order to catch breaks in traffic just to stay on schedule. This combination of factors leads to a tremendous amount of wasted energy.

One of the largest ways my discipline could help solve this problem would be to create large expansions in the hybrid and electric motor sectors for buses. The use of electric motors in buses alone could have a tremendous impact on the amount of gas the city uses in addition to the decrease in emissions and lingering exhaust fumes around stations. By their nature, electric motors generate almost no heat/wasted energy and are very efficient at accelerating. Equally important is the fact that they can also regenerate energy through braking, compared to typical brakes that just turn useful energy into heat. If such technology were to be implemented in the city’s major fuel consumers, including buses, garbage trucks, and EMS/Police, it could have a profound impact on the city’s reliance on fossil fuels and in turn make the city much greener.

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

Whenever I think of what discipline I belong to or want to be a part of I always say to myself mechanical engineer. But what does that really mean? There are many different ways a person could define the role and any of those descriptions could be correct, but to me that discipline is any person who incorporates their innovation into any mechanical properties that leads to the benefit of others. These people could be out managing supply chains over at plants or designing crucial parts to mass manufactured products. But the one commonality is that they are applying their understandings in the sciences and mathematical fields and combining that with their creativity to come out with outcomes that will better the lives of others. When I think of the publications that come out of this discipline I usually think of academic journals, manuals, and reports all of which are very professional and technical in nature. The reason that this discipline can have such variation in the types writing is due to the context in which the publish works are used for. One might expect academic journals to be used for a mechanical engineer doing research work at university or working on a development project where you are venturing into the uncharted waters. Where as manuals and reports maybe used for an environment more suited for a business or manufacturing surrounding that will require constant update reports or manuals on producing a product.

So far for project 1, I’ve been trying to spitball some ideas on what are some things that are currently problems or could be improved upon, and to keep a stronger focal point on the subject I’ll probably stick to something in the Boston area. The first thing that comes to mind when thinking about problems in the Boston area is the transportation. If it be public transportation or the city’s infrastructure like its streets, bridges, or tunnels you really can’t go wrong. Let’s start with public transportation, more specifically the train/subway system. There are many aspects of this system that an average Bostonian would tell you needs some work. One would be the timeliness of which the trains arrive or reliability of the schedule which may be due to system failures or poor planning . Another would be the space and capacity of which these trains can hold up to especially during peak hours. Now with the infrastructure of the city there has been a long history with Boston and bad traffic. The root problem is that since it is an older city it does not follow the more practical and modern grid design most American cities use today. The only method of improvement so far have either been digging or building. What makes these problems relevant to my discipline is that they feature core problems that can be solved using mechanical or physical solutions. So the next step to take would be to find practical solutions to these existing problems.

Information Science is basically about how to manage information and make the information to be used in a better way. Computer science classes which I have to take, gives me the solving problems skills in a logical way. In other words, Information Science helps things “make more sense”.

What I found not making sense is that most of street parking in Boston are 2-hour limit parking. If you have a car, you must know that it’s hard to park around the city. Even if you find a street parking spot, it’s normally a 2-hour limit parking. It’s not enough for visiting a friend, traveling around the city or having a meal in a popular restaurant. What can you do in the city within 2 hours?

All the parking space near Huntington Ave are 2-hour parking, if you have a class right after another class, 2 hours won’t be enough and you don’t have time to move your car. A ticket would appear on your car. The only place that have 4-hour parking is Ruggles Street near West Village, but we are sharing that street with Wentworth.

I know that school has parking garages for students and staffs. I still remember that one day in 2014 fall, when I had an 8am class with my friend who drives but he was still late for the class. 8am class shouldn’t have a lot of traffic and he was coming from Allston which is not far from school. He told me that it took him 15 minutes to find a parking space in the garage. I didn’t have a car back then but I knew students need to buy the parking permit which is not cheap for a college student. It shocked me at that time and I begun to think that it’s not worth to buy a parking permit. I got a car in fall 2015 in case I need it for my Co-op. I started to drive to class occasionally. I had to find a parking space for 20 minutes. Even I found one near Huntington Ave, I need to move my car every 2 hours because the street parking there are 2-hour-limit parking. This summer, I thought there should be fewer students on campus so I drove on the first day of class. It took me 10 minutes to park the car that I didn’t need to move it every 2 hours. But if I want to park in the garage for Summer2 Day Parking only, it’s going to cost me $230, which only four days a week that I have to come to school.

2-hour limit in Boston is not a reasonable time for parking. If you stay in the city for couples of years, you would know that it’s hard to park with enough time not only around Boston University in Allston but also Harvard and MIT in Cambridge. Thus, I think all the 2-hour limit parking around universities should be changed into 4-hour parking.

Over the past few decades, the field of computer science has experienced exponential growth and its applications have branched out into nearly every other discipline. With this broad adoption and advancement in new technology came access to an expansive amount of data, as well as the ability and computing power to easily explore these datasets and draw useful conclusions out of them. As a computer science student, I find it fascinating that we are now able to comb through a vast amounts of information, and extract patterns and structures that would have been  previously invisible to the humans eye, and I feel as though it has an almost limitless amount of applications. An example of just one of the applications could be pulled from the field of medicine. In recent years, medical researchers have been working to gather and explore data from cancer patients, and have been using it to build a mathematical models that can quickly and accurately detect cancer at an earlier stage in other patients. This would allow for the patient to start treatment before the cancer could spread further, and  would significantly increase chances of a successful treatment. Previously, identifying the symptoms for early detection would have been an extremely involved and intensive process, and the end result might have been imprecise. Now with the computing power and data that researchers have access to today, a few computers can do all the heavy lifting, allowing the field to advance at a rapid pace.

As a relatively young field, data science research is being published on an almost daily basis. Cutting edge research is not only coming out of colleges and universities, but technology companies that have recognized its many applications and have been investing in their own research facilities. These researchers investigate generic ways to use large amount of data to draw qualitative conclusions or develop mathematical models, and they spread their findings in journals for other researchers who try to find applications in their respective fields. The continued research into properly and efficiently using the enormous amount of information we have access to is going to continue to allow us to see technology advance at a rate faster than we have ever seen before.

As I progress through my metamorphosis into an adult human, I have ruminated on my life’s desires. One of the aforementioned desires, among the foremost, is to become some permutation of civil rights lawyer. This is a broad term which, as broad terms do, needs some whittling down. The more specific version, which is hopefully the version I embody, is that of a lawyer that fights for rights in the digital realm, a “digital rights” lawyer. Careers in this vein generally involve such things as net neutrality, the openness of software, and privacy in this digital age. Earth, with each inexorable rotation around the sun, will see its population of this particular form of lawyer increase as, proportionally, associated complex problems arise.

A problem, resolvable by this profession, endemic to the Northeastern/Boston locale is hard, to me, to pin down. Broadening my metaphorical search area to those of generic civil rights gives one more choices to choose from, while having the related effect of being somewhat disheartening. The problem that one can fairly easily hone in on, is that of class relations, and the disparity associated with it. World-wide dominance of societal stratification, as a subject, is essentially intractable and cannot be tackled as a whole. From this ramble, at long last, a problem statement: how can a digital rights lawyer effect change in this university, this city?

How, if at all, could one with my desired profession affect the lives of the of the, by birth, disenfranchised? An obvious avenue would be to supply these people with the the benefits of the technological revolution. However, another, more in the realm of lawyers, course of action presents itself, litigating in defense of the weak. In order to effect this social change, one could directly start a lawsuit against some company, or individual, which is blocking the benefits of the modern era from reaching the lowest layers of society. A somewhat less direct, but possibly more sweeping, way to change people’s lives for the better, is in the drafting of amici briefs. Amicus curiae, Latin for “friend of the court”, references an outside entity who advises the court to make a ruling one way or the other, in the form of a paper referencing the potential ramifications of a ruling and relevant laws and statutes. Class structure and its repressive effects to the lower reaches of the world, or Boston in this case, should be minimized if not eliminated entirely. A potential path to this state of enlightenment is through the work of lawyers, ensuring the the judicial system works in favor of the huddled masses.

Engineering, almost by definition, has a penchant for providing extremely concrete tools without specifying any required circumstances for how these tools might be applied. An exact solution provided for inexact problems. Just as this is true to the other engineering disciplines, so is it for computer engineering.

Computer engineering can be loosely thought of as the bastardized combination of electrical engineering and computer science. While a more shallow depth of knowledge is required in both circuits and programming in the general sense, the exception is the higher degree of understanding of low level programming.

Low level programming has a wide swath of uses that allow for less flashy, however far more efficient applications. To illustrate this, a computer science major might program a calculator using Java (a high level programming language), whereas a computer engineer could (with a higher degree of difficulty and at greater cost) create the same calculator using an FPGA (field-programmable gate array) for noticeably faster calculations. In some situations however, the added efficiency and reliability are unnecessary. (For example, the calculator on an iPhone satisfies the speed and usability needed for the majority of daily mathematical calculations.).

Within the computer engineering world there exist a myriad of internal divisional tasks. Firmware allows electrical devices to function in raw capacities, drivers that allow these devices to communicate in an interpretable manner and communication regulation for networks. Although the principles of design and language will likely be consistent through these sub-fields, the tasks of these three engineering roles (Firmware Engineer, Computer Engineer, and Systems Engineer) will vary dramatically. Yet, as a nod to the diverse applicability of engineering, the end application of a Firmware Engineer and Systems Engineer could have dramatically more in common than two Firmware Engineers. (Should the two firmware engineers be working in vastly different fields, while the other two engineers work in a similar field.). This adaptability reflects that the true work of engineering is defined by problems identified, and without this contingency the skills of engineering are devoid of purpose.

Fortunately the purpose of these skills is gifted by everyday problems — yielding those, ‘oh of course!’ moments after seeing a better means of doing something that you had never before thought to improve until seeing the answer. Smartphones, automated passport control and self-check out in stores are only a few of a large number of recent developments that have been culpable for these too-late-epiphanies. Informing these problem solving principles with problems from the outside world allow engineers to instead be the parties responsible for making these moments, rather than being subject to them. Applying these principles to the outside world can help us to reduce traffic using new methods of street separators, improve the safety of bikers by integrating modern technology with safety apparel, or by integrating the use of drones for delivery services.

The principles and concepts of chemical engineering can be applied over a wide array of issues and fields of study. This has resulted in chemical engineers working in many different fields ranging from pharmaceuticals, energy, micro-technology and even the food processing industry. The industry a chemical engineer enters is often dictated by the region of the country they are from. For example, chemical engineers in New England most commonly work in the pharmaceutical industry or for one of the many biotech companies founded in recent decades. Engineers in on the Gulf Coast will typically work within the Petroleum industry, while those in the Midwest enter the food processing industry, working for companies like General Mills.

One of the fastest growing industries in the country is renewable energy. There are many types of renewable energy, such as hydroelectric, solar, wind and geothermal, which all have positive and negative elements associated with them. Hydroelectric is cost efficient and can generate vast amounts of electricity, and as a result has already been widely developed across the country. Future developments are met with some resistance as the dams needed to generate the power can alter the local ecosystem. Wind and solar are both considered somewhat inconsistent sources of power generation as they are weather dependent. Geothermal has the largest potential for power generation out of any of the renewable fields, but can only be developed in very specific regions of the world that have the higher volcanic activity required to generate geothermal power. In addition, the initial cost to find a suitable location and construct an operational geothermal power plant are extraordinary.

Cities require large amounts of power to operate effectively. While residents of cities consume power at comparable rates to their suburban counterparts, the dense population center results in much larger total consumption per square mile. In addition, the city itself consumes much more power to operate public services, such as street lights, transportation systems and other required functions. In an attempt to reduce Boston’s carbon footprint, civil authorities and the public have sought ways to introduce more renewable energy sources to the city. Chemical engineers are well suited in their discipline to assist in this endeavor.

Boston’s geographical location eliminates geothermal and hydroelectric power as realistic options, leaving solar and wind power.  Solar power has far more potential to provide a significant portion of Boston’s required power. Solar panels can be installed almost anywhere the sun normally shines, but are expensive and have low energy efficient, usually around 15-20%. Chemical Engineers are working to develop more efficient solar panels, using micro-technology to change the surface that the sun’s photon’s interact with on the panel which has had considerable success on a small scale, increasing the panel’s efficiency to 40%.  In addition, chemical engineers are working on advanced storage systems to hold excess power that is generated during the day for later use. These storage systems, such as ion flow batteries, allow for a cheap and cost effective method of storing energy in a reversible chemical reaction, that can easily be scaled to suit any amount of power storage.

People who strive to impact the lives of others naturally gravitate toward the field that has made the biggest difference in their life. Nobody is going to be inspired to pursue a career in art without having been moved by a piece of art just as nobody would go into teaching without having their lives strongly changed by a teacher. Many of my fondest memories are, in some way, related to nature. For this reason, I am focusing my career options in the field of sustainability. To do something sustainably is to achieve the goal of the action without reducing its ability to be done again. The way our country has developed is not sustainable. It is saddening to imagine future generations without access to the environment we have due to the damage we inflict on it resulting from fossil fuel usage. My goal of working towards renewable energy generation is a result of the problems I see that I hope to help solve.

The permitting process associated with a coal-fired power station is long and arduous. For this reason, coal-fired plants are most often installed in low-income areas that have a large working population with minimal community involvement in the local government. Meanwhile, all wealthier areas, with a higher retired, or otherwise available during business hours, population can combat any power plant that tries to enter their town at a community hearing. We cannot continue to reap the benefits of this power while sending all the pollution and heath issues associated with burning coal to less wealthy communities. It is because they do not have to bear the major effects of the coal plants, that the higher educated, wealthier populations do not participate more strongly in the transition toward renewable energy. These are exactly the people that could have the greatest effect on this movement

Northeastern University, as an establishment of higher education, has a responsibility to exhibit the behavior to which all should strive. There are many areas in Boston that could be improved to increase sustainability; Northeastern could set an example as a producer of clean energy. Considering it’s dense building layout, Northeastern has a structure that is conducive to the utilization of rooftop solar. Although there is not enough on-campus rooftop area to cover all of Northeastern’s energy requirements, the implementation of rooftop solar would send a statement to surrounding communities. By advertising the economic benefits of solar to the rest of Boston, Northeastern could lead the way for the entire city to reap the environmental, social, and economic benefits as well.

With the wide range of uses for electricity and electromagnetism, there comes an enormous range of problems that electrical engineers can engage with. Electrical engineering is a broad field that can cover anything from artificial intelligence, to cutting edge healthcare solutions, to personal electronics, and the field’s influence can be seen everywhere. It is difficult to imagine life without telecommunications, Alexander Graham Bell, and his telephone. Another important field is computers, with major advances made by electrical engineers William Hewlett and David Packard. On a more local level, electrical engineers here at Northeastern are working on developing a humanoid robot with NASA.

There are a variety of ways for electrical engineers to communicate and share new ideas and knowledge. With the internet, many engineers have their personal blogs where they detail the projects they have worked on. There are also websites that have databases filled with project ideas and step by step tutorials. In a more academic setting, IEEE (Institute of Electrical and Electronics Engineers), publishes hundreds of journals and magazines covering topics in electrical engineering. Additionally, IEEE offers societies, communities, conferences, and events for members. The organization’s tagline is “advancing technology for humanity,” which seems to be a common goal for all people in this discipline.

Issues with the production and distribution of agriculture can be solved by this discipline. Different startups right here in Boston and Cambridge are using electrical and computer engineering to solve problems with the physical growing of produce. One company Grove Labs developed a product that combines a fish tank and a garden to create an ecosystem that can grow food indoors. LEDs are used to simulate the sun, and Wi-Fi and sensors monitor the system. Another company Freight Farms has their own product Leafy Green Machines. These machines are actually shipping containers turned into miniature controlled farms. Similar to the Grove Labs product, LEDs have been programmed to provide plants with light. The shipping containers also contain an extensive climate control system that uses sensors and feedback to adjust the temperature, humidity, and carbon dioxide levels. There is also a watering system where the user can adjust nutrient levels.

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.