Relevant sites

After viewing others’ ideas about web projects, I found these relevant sites…

My version of the digital version of our, or anther, class is with education materials rather than individual profiles. I found a source of some free online courses that include multimedia presentation of material like something we might create: http://www.free-ed.net/free-ed/FreeEdMain01.asp. Of course, Kathy’s online version of this class is an example of organizational structure and design elements. Also, M.I.T.’s project to put their courses online would be a useful resource: http://ocw.mit.edu.

There was also discussion of a digital representation of a geographical community. Such a site might look like this: http://www.caithness.org. This site offers an example of the elements that need to be included in this type of site.

Finally, I took another approach to the community site by suggesting using a topical focus. Such a site might look like this: http://www.ishmael.com/welcome.cfm. This site is a community based around a book, but the example could be translated into various forms.

Project Responce

I think the class website seems like a great idea. But I would choose to create a digital artifact of a course rather than profile the specific members. Perhaps it would be better to this on another class, rather than such a reflexive silly thing.
I also noticed a theme of using totally non digital type projects, focusing on things that are less likely to be online already and involving people who would be unlikely to already have an online presence. This may offer a nice, fresh opportunity and be able to be “stand alone.” Additionally, many were focused on outdoor activities. There may be a whole host of other idea relating to thing that wouldn’t be so cold to collect. =)
I would like to alter the community type site to focus on one main topic. Rather than enabling an already existent geographical community, it might be more fun to facilitate a spread-out community through online communication.

Experience, Goals and Roles

Past Experience :: Within one team in the past there has been a struggle over who creates the content, and what titles various members carried. As webmaster it can be more important to know what you are truly NOT going to work on rather than what you ARE.
Within another team a problem again arose from roles. Tasks of each team member were again not clearly defined. When problems arose each person thought someone else was responsible for solving it.
A third issue from the past was the importance of the end result. Sometimes regardless of planning and elegance a simple fix is necessary. JUST GET IT DONE seems to become critical at times, even if it’s a patch. Additionally, since the web world is 24 hour, the webmaster position is in essence an on-call position.

Rethinking Goals :: There is an emphasis, within goals, on the roles played of executives and PR folks, perhaps due to peoples’ past experience or perhaps due to influences of the reading. Seeing where you fit is vital in effective team production, online of off.
The obvious technical goals are also listed. The fact that many people listed flash makes me think this would be worth my energy too, since it will be a concentration for those around me.
-- Learn about the current and future applications of RSS and pod-casting.
-- See the role of all members of the online production team.
-- Improve objective prioritization (tech and non-tech) skills.

My Roles and Avoidances :: I would enjoy the role of hands-dirty-code-guy, but that may not allow me to expand perspectives. Perhaps I can just assist in this area.
I would enjoy working with over all architecture. I have experience in this area, but trying to think from purely this perspective could be rewarding.
Working in content creation and design would be similar to the above experience.

Responce and goals

Ah-Ha Moments! [One] The first light bulb was illuminated by the prototyping text. I wrote the phrase "perspective accuracy," which seemed insightful to me. By these words I'm referring to: what the prototype “means” to different members on the design team. When a prototype is created not only does everyone need to have input, but it has to evoke an accurate portrayal of the design intentions within various perspectives. [Two] The second flash comes from the same article. I came away with a distinction between three concepts… scenario, story and theme. A scenario is a specific task carried out upon the system; a story is an anecdotal understanding of an interaction with the system; and, a theme is a convergence of stories.
The generation of themes, within stories, (kinda) become scenarios. Whether or not those are intended or are truly part of the system, a theme of use is a very valuable tool. This helps to understand the way in which users perceive the functionality of the a system.


Three personal goals...
-- Gain knowledge of the tech. side of RSS and pod-casting.
-- Better understand the role of the webmaster in the business team
-- Improve my overall perspective regarding tech meets non-tech objectives.

Wk1 reading (Publishing Team)

McGovern, Gerry & Norton, Rob. Year. The Publishing Team: Chapter 11 - Content Critical: Gaining Competitive Advantage Through High-Quality Web Content.

Well I feel stupid. While I read I started to create a heirarchy map of the different roles, only to find there was one already created at the bottom of the document. I think that may be the most useful nugget of information.
As a "webmaster" (and yes I hate the word) it is eternally frustrating to have so many tasks that are very multi-disciplinary. But, that's what attracted me to the work... so I shouldn't complain. What I can complain about is that sometimes your colleagues don't understand this. Not only does the copy have to be right, but the database structure has to be correct, the server environment has to been running correctly, the code has to be perfect, the generated HTML has to be formatted correctly (including the CSS) and finally it has to look good graphically… oh yeah and load quickly.
It’s helpful to see such a clear definition of roles, it will help to focus given tasks and may even warrant a ‘check list.’ It's just nice to know that somebody knows us "webmasters" are overworked.

Wk1 reading (Design Practice)

Erickson, Thomas. 1995. Notes on Design Practice: Stories and Prototypes as Catalysts for Communication. Available online at http://www.pliant.org/personal/Tom_Erickson/Stories.html.

This article puts a huge emphasis on the communicative process involved with production. We see the emergence of the roles, communication artifacts and the processes (or models) of communication. The concepts above are then within a stage model.

I initially wanted to argue against the author’s point about stories. A story is a scenario, but perhaps a scenario isn’t a story. The goal of Use Case description is to capture all possible scenarios. I get the idea of “real-world” thinking; anecdotes are useful, but I did not see the grand distinction. But it’s clear now the real strength of this story collection concept is the development of themes. By evaluating similar sentiments a system can really be improved. Also, stories are useful in the brainstorming and design communicative process.
Another important point is that the themes from above become macro-scenarios. Then we can move into the next point-- motivations and feelings. These are the main concepts of the first stage of production.

The next stage is focused on prototypes. Artifacts which represent the project and help shape it can exist at many levels. But, the most valuable discussion here is the perception of prototypes. The engineer knows what a prototype “means” in a very different way than the PR person, the financial director, etc. In this way various prototypes may serve different uses and must be clarified to be qualified. In a highly successful communication scenario a prototype would fulfill perspective accuracy for all viewers.
The distinction between vision and working prototypes seems very useful. The first teases the brain with the general concept, and the second allows more specific critique. But the notion that all members of the team should be able to alter the prototypes may be the most pivotal mistake of real-world examples.

The article was full of great concepts, but was somewhat disorganized. There was not a single topical narrative flow. The article would have benefited from a web type layout. Ha ironic! Perhaps the journal publication was presented differently.