Author: bakes.s

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.