Working Together

Vicente uses the very real life and actual events of numerous plane crashes as examples and metaphor to illustrate what can occur in teams when they fail to communicate.
Cool Hand Luke (1967) uses the expression "What we have here is a failure to communicate" and can be viewed in this scene on YouTube

http://www.youtube.com/watch?v=1fuDDqU6n4o

This video also illustrates the effect that authoritarian leadership has on members of a team. While the Warden tries to explain in a rather benevolent fashion that Luke's beating is due to the fact that "Some men cannot be reached" this should definitely not be the case in a team oriented atmosphere of Computer-based learning tools development.

Vicente continues to illustrate his point with the surgical team example in which one member views himself as more important than another. However, for the overall survival of the patient (or project in our case) all members must be viewed as vital, important and valuable. I'd like to state right now that our group is made up of four talented individuals, each bringing vast and varied experiences that interweave well in our project development thus far.

It is when members view them selves as more important or valuable than others and when these people rely on fear-invoking authoritarian styles of leadership that lines of communication are broken and the proverbial patient dies.

The necessity to communicate outside of our team with our users and clients is also a critical element to keeping our patient/project alive. We can use our prototype as a design tool to gather information and feedback from our users to make our customers strong co-designers (p370). Our challenge then is to communicate the experience that our new system will offer. Including our users as co-designers will help to establish and maintain trust while simultaneously develop buy-in from our clientele. The prototype testing process should also flush out design flaws as we receive feedback from our users. This relates well to Vicente's argument that all shareholders are important to a project's success.

This ties in well with my own personal beliefs of classroom instruction. I believe that teachers are not the sole sources of knowledge and that we can allow student input to the direction and modifications of their learning. Respecting student's abilities and experiences as valuable creates an environment of trust and collaborative learning.

Returning to Vicente's plane crash examples, communication need not stem from the original holder of information. It is all members' responsibilities to seek out information about the actions of others within our project. This is why we have enabled to "update" feature in our wiki to inform each other of recent changes to our project.

While the wiki affords us time and space to reflect deeply on our process, face-face meetings allow for rapid iterations and resolving arguments within our design team(Citation Required Here). Just as Vicente's anaesthesiologist experience real-life pressure and stress trying to save the dummy patient, instant feedback has been important to the smooth development of our LMS.

Furthermore, the dynamic and authentic assessment scenario of the practice dummy related well to Norman's Visceral, behavioural and reflective levels of design as working on that patient will be an experience not long forgotten by Vicente's anaesthesiologist. Working closely with our users in as close to real situations in our prototype may evoke memories and emotions from our users that in turn will uncover deeply hidden design and technical flaws in our LMS.

References

Cool Hand Luke (1967) Jalem Productions.

Norman, D. A. (2004) Emotional Design: Why we Love(or hate) everyday things. Basic Books. New York.

Vicente, K. (2004) The Human Factor: Revolutionizing the Way We Live with Technology. Vintage, Random House. Toronto

XXXXXXX, X. (####) AAAAAAAAA. Chapter 17: Prototyping as a design tool.

Why do we trust technology?

Much like a concept map begins at some random point then branches off to make other connections, I would like to begin by making connections between the two aspects of design presented in Chapter 1.
Between the Principles of Usability and Design

Visibility of System Status - Visibility and Affordance
It is vitally important for our product's success to inform the users that a particular action is taking place. This can be achieved by constant feedback through the use of easily understood icons and feedback messages.
Match between system and the real world - Mapping and Consistency of language
Being user centered implies that we understand the user, their language, their level of expertise with computing and a common assumption to their experiences. However difficult this may be heuristically, by performing representative testing with representative users under representative conditions (RBWD&UG, Chap2) we can begin to approach our user's understanding and expectations of our product. Again it is crucial that we map our tools and layout in an easy to understand, intuitively feasible manner that uses language that anyone, including a lawyer could understand.
User Control and Freedom - Constraints
Norman (Chap 5) spoke about trust. Our users will trust us to allow them to work within safe limits yet protect them from making critical errors that could cause them loss of information, position, or communication.
Consistency and Standards - Consistency of layout and constraints
Trust is built on consistency. Users will need to see that the product works, it consistently delivers the same message for the same action, and consistently protects them from harm.
Help user to recognise, diagnose and recover from errors - Constraints, Feedback and visibility
Feedback is extremely important in helping users to recognise when they have attempted to do something that could cause them grief later. However, should they pursue this avenue they would still need a "chicken exit" much like at a fun house at a local fair. Chicken exits are usually labelled clearly and easily found prior to a patron going deeper into the scary sections of the house.
Error Prevention - Mapping, consistency, constraints, feedback, affordance
Directly linked to helping users recognise, diagnose and recover from errors is making sure that we can prevent them from occurring. Again by employing user centered design principles and making a valid attempt to understand the user, we can map our tools in such a manner that is representative of real life situations and intuitively easy to understand even for a first time user. Furthermore, consistently protecting users from errors with the use of feedback built into our constraints will be critical to our product's success
Recognition not recall - Affordance, visibility and mapping
users are busy, they have but a moment to learn how to use a product let alone use it on a daily basis. If a user has to spend time and energy trying to recall how particular functions are performed, they will not use our product. By allowing users to come each time as if they are a "blank slate", and recognising items that are somehow related to their life we can make a user's experience that much easier and satisfactory.

All the while that we create our design, we must be active in a recursive, or cyclic iterative state to ensure that we develop alternative designs to meet our users needs. However, as we develop the need for A, may we also create a need for B. Then as we satisfy B could be then iteratively create a need for C?

One note kept resonating with me as I read Norman's Chapter 5 and Reese's Chapter 1 -

Our product is Interaction Design.

We are charged with creating a product that by definition allows users to be highly productive in their lives (Reese, p13). Furthermore Norman (p157) clarified our product in my mind to create a technology that supports social interaction. We are creating a technology that builds and fosters trust and emotional bonding.

We are not creating a program nor ore we creating something that is not already out there. We are creating an experience. We must create that experience to be as useful, supportive, enjoyable and pleasurable as possible. How can we achieve this?
Again by focusing on the user and their experiences. By fostering trust through applying the design principals of visibility, feedback, constraints, and consistency. Why do we trust our parents? They were visible when we were on the highest rung of the monkey bars. They provided feedback prior to an accident. Hopefully they were consistent in that message until we had proven our ability to go further (Much like how many programs hide the more involved functions but readily display the more common and safe ones).

I left this reading with many more questions to which I will hopefully discover the answers. Are people's mistrust of machines a manifestation of their mistrust of people or themselves? Norman's (p151) question, "if we love talking on the phone why don't we love our phones?" lead me to ask how can we get our users to fall in love with our product?
Norman (P157) quoted Linda Stones description of current human nature as "Continuously divided attention". Can we and if so, how can we plan to deal with, reduce or all-together avoid this human trait?

References
Norman, D. A. (2004). Emotional Design: Why we love (or hate) everyday things. Basic Books, New York.
Preece, Rogers and Sharp (2002) What is interaction design? In Interaction Design: Beyond Human-Computer Interaction.
U.S. Department of Human and Health Services. (2006) Research-Based Web Design and Usability Guidelines. Chapter 2.

Oooh... so that's why I love or hate everyday websites

As part of Designing Web-Based Instruction I completed an online personality index. While it was not required, I did two different ones to verify results from two different indices. What I found confirmed some of my suspicions. I am definitely a visual learner, I am an active learner, I am slightly intuitive with a predisposition for relationships, abstraction and mathematics - go figure, no pun intended; I am a math teacher - and I prefer sequential models over random thinking - I knew this before as I tend to think best when I jot my ideas down in lists, and hated concept maps. But the more I think about things the more I tend to begin drawing (literally) connections between ideas. I have recently become slightly better as concept mapping - but only after I have my trusty lists complete. (Moses, 2008).
Optimizing the User Experience further deepened my personal beliefs as well as preferences. This chapter read like an excellent check list for developing web-based learning environments. All the while confirming what I like or hate about certain websites.
Certainly graphics are a major aspect of developing user-centered learning environments. Guidelines 2:4 &2:5 suggestion to refrain from requiring users to do mental calculations was in consensus with Vicente's( 2004) suggestion to do the same. Whether it be for mortgages(USDH&HS, 2006 p12) or for monitoring a nuclear power plant, (Vicente, p133) graphics are a powerful yet unobtrusive information delivery method. Being a visual learner, I can certainly concur with this recommendation.
I wholeheartedly agree with Guideline 2:5 "Do not require users to remember information from place to place on a Web site". The challenge now is to design for this suggestion. How will I organise the page to display new information while connecting it with previously needed or used information? This is re-iterated ironically on page 19 with guideline 2:13 "Do Not Require Users to Multitask While Reading". I found myself thinking back to guideline 2:5 as I was reading 2:13. This was definitely something to remember as a "what-not-to-do" as I develop my course shells.
While "Format Information for Reading and Printing" appears to be a final consideration, perhaps it needs to be a-priori one. To design with the user in mind is to recognise that not everyone will want to read items off of a computer screen. It will be advantageous for myself as a designer to consider this as I put large amounts of text (although undesirable, sometimes altogether unavoidable). Taking this into consideration before-hand will probably save me a tonne of work afterwards. Instead of creating something that will eventually need to be re-formatted, why not put it in that format to start (USDH&HS, p16, 18,20)? Good idea.





References
Moses, S. (2008) Typical of Me. Discussion thread entry as part of University of Calgary EDER 679.06 Designing Web-Based Instruction. Retrieved electronically October4, 2008 from https://d2l.cbe.ab.ca/d2l/orgTools/ouHome/ouHome.asp?d2l_stateGroups=grid~gridpagenum~mycoursesstategroup&d2l_stateScopes=OrgUnitSession~GridPageNum~Search~PageNum%5EOrgUnitUser~LCS~MyCoursesStateGroup%5EUser~Grid~PageSize~HtmlEditor~HPG&d2l_statePageId=389&d2l_state_grid=mcg17957~0~~Asc~~0&d2l_state_gridpagenum=mcg17957_pgN~0&d2l_state_mycoursesstategroup=mcg17957_tree~37239%2C31819&ou=68439.
United Staes Department of Health and Human Services. (2006). Research-Based Web Design &Usability Guidelines. Retrieved October 4, 2008 electronically from http://www.usability.gov/pdfs/guidelines.html.
Vicente, K.(2004) The Human Factor: Revolutionizing the Way We Live withTechnology. Vintage Canada, Random House. Toronto.