Robot tracing (2003)

Endsley, M. R., Bolstad, C. A., Jones, D. G., & Riley, J. M.(2003). Situation awareness oriented design: From user's cognitive requirements to creating effective supporting technologies. In Proceedings of the 47th Annual Meeting ofthe Human Factors & Ergonomics Society (pp. 268-272).Santa Monica, CA: Human Factors & Ergonomics Society

This paper explains briefly an SA-oriented design framework; how to go from a system requirements to construct an SA-oriented design. Authors, had written a book on SA design from a perspective of a user-centric design. In this paper, authors try to focus on steps needed to conduct an SA Oriented design, and then provides an example of such design from military. The novelty of their work was, the conduction of an SA oriented design where they integrate the SA tasks with user goals.

So, first lets discuss Situation Awareness (SA). SA is human state where a human knows what are the factors that happen in the surrounding environment that would affect his/her decisions in performing any task. Example, user is driving a car. When user wants to stop, he/she will build the SA from looking at the street and other cars, looking at the dashboard, fuel level, etc, to help him/her to stop probably.

When do we need situation awareness when designing system? When user task involves decision making which relay on many variables , or factors, user errors can be heavily driven from bad interpretation, or missing data of those variables. Thus, SA is important for decision making user tasks. Another use of SA is to help managing multiple system. Example, in the previous paper, single user wants to control multi robots, with all the given variables, this can be difficult, that’s we need a good SA design to come along with such system.

One major problem about SA is that it reside inside human operator mind. Unlike user goals which can be written well. So, the key idea here is to link user goals (or requirements) with SA to form a better decision support system interface. The SA oriented design process include three main steps:

1. SA requirements analysis
2. SA-oriented design principles
3. SA measurements

Step (2) and (3) can be repeated to enhance this model.

Step1: SA Requirements Analysis
The goal of this step is to conduct SA requirements by identifying user cognitive tasks. User cognitive tasks can be identified using Goal-Directed task analysis (GDTA) - GDTA before in the blog. So, using the GDTA, we can conduct the requirements by identifying the following for every user task:

• Goal
• Information needed to achieve that goal
• Integration of such information to be presented to operator (user) to be meaningful and therefore support decision

So, SA requirements will be associated with every user goal, or subgoal to explain the above. One thing to put in mind when conducting SA requirements, that the focus here is user goals, not user tasks!

Step2: SA-Oriented Design
In this step, they cited a book which three of the authors wrote earlier (at 2003). They indicated that the book provided 50 design principles for SA design. Those principles focuses on the dynamic switching between goal-driven process, and data-driven process. So, they indicated that in order to conduct an SA oriented design, you should follow SA-oriented design principles. The paper didn't dive much into details about how to conduct an SA-oriented design. In fact, authors selected some design principles and discussed them.

Step3: SA Design Measurements
After conducting the design to enhance operator’s (user) SA, we need to verify if the new design does really help increasing user situation awareness, or not? In order to verify the design, authors suggested in their framework the use of: Situation Awareness Global Assessment Technique (SAGAT) (1995). Again, this approach was just mentioned but never discussed in the paper.


The rest of this paper explains an example of SA-oriented implementation on the military field application. In their example, they had a battle field where decisions has to be made according to the data came from the field. They developed different interfaces to different level of commands. Higher commanders would need an abstract SA-oriented design, yet detailed as needed to support their decisions.

HTA exercise

This is a small exercise where I'm performing Hierarchical Task Analysis (HTA) on Pizza Delivery System (PDS). Briefly, PDS is a system which runs pizza shop starting from order taking, queuing items in kitchen, preparing items, stacking order items, and delivering items. In the following excises, I have conducted an HTA of five major user tasks. I will give an HTA diagram of each with title,and brief description in this entry. Click on pictures to enlarge.

Task 1: Place Order
Order taker takes an order from customer, place it in the system, then calculate the total and estimated time to be delivered.

0. Using "Place Order"

1. Select Item

2. Enter item quantity 

3. Enter additional ingredients

  3.1 Select ingredients

  3.2 cluck add ingredients

4. Submit order

5. verify order

Plan 0: do 1-2 in that order, then 3 if necessary, in the previous order repeat as necessary, then 4-5 in order

Plan 3: do 3-4 in that order and repeat as necessary

Task 2: Change Order
Customer calls the store, and asks to change his/her order.

0. Using "Change order"
1. Query order name
   1.1 Enter order name
   1.2 Enter phone number
2. Change item
   2.1 Change quantity (0 to delete)
   2.2 Add ingredient
   2.3 Delete ingredient

Plan 0: do 1-2 in that order.
Plan 1: do 1.1-1.2 if necessary in any order.
Plan 2: do 2.1-2.2-2.3 if necessary and repeat in any order.

Task 3: Cancel Order
Customer calls the store, and asks to cancel order.

0. Using "Cancel order"
1. Query order
   1.1 Enter order number
   1.2 Enter phone number
2. Cancel specific order
   2.1 Click cancel button
   2.2 confirm cancellation

Plan 0: do 1-2 in that order.
Plan 1: if necessary do in any order 1.1-1.2.
Plan 2: do 2.1-2.2 in that order.

Task 4: Cook Order
Order has been placed, it will be forwarded to the kitchen and placed in a queue to be prepared. Cook will take the next item in the queue and start preparing it.

0. Using "Cook order"
1. Prepare order
   1.1 Read item details off the screen
   1.2 Prepare item to be placed in the oven
2. Place item in the oven
3. Take item out of the oven
4. Finish order
   4.1 Read order items off the screen
   4.2 Stack order items together to be delivered

Plan 0: do 1-2-3-4 in that order.
Plan 1: do 1.1-1.2 in that order.
Plan 4: do 4.1-4.2 in that order.

Task 5: Change Store Functions
Store Manager at the begging of the every work day can manage: store menu items, cooks, oven, and deliverers.

0. using change "store functions"
1. Manage menu items
   1.1 Add new menu item
   1.2 Change item
   1.3 Delete item
2. Manage cooks
   2.1 Add cook
   2.2 Change cook
   2.3 Delete Cook
3. Manage ovens
   3.1 Add oven
   3.2 Delete oven
4. Manage deliverers
   4.1 Add deliverers
   4.2 Delete deliverer
5. Manage delivery locations
   5.1 Add location
   5.2 Change location
   5.3 Delete location

Plan 0: if necessary do any of the following in any order or combination 1-2-3-4-5
Plan 1: if necessary do any of the following in any order or combination 1.1-1.2-1.3
Plan 2: if necessary do any of the following in any order or combination 2.1-2.2-2.3
Plan 3: if necessary do any of the following in any order or combination 3.1-3.2
Plan 4: if necessary do any of the following in any order or combination 4.1-4.2
Plan 5: if necessary do any of the following in any order or combination 5.1-5.2-5.3

From HCI to Interaction Design

I just attended  a talk by Dr. Oli Mival; A professor at Edinburgh Napier University; which discusses in general sense the current HCI issues and how research is heading in the future. He also, discusses some of his project; especially ICE project.

Dr. Mival went over his big research project "Interactive Collaboration Environment (ICS)" which is an interactive meeting room designed to help in conducting a more engaging and effective meetings. He discussed design issues and obstacles that faced them when they started the project.  The idea of the meeting room is room equipped with different equipment's to enable participants in their meetings in better a way. The following is a list with what Mival indicated as a components in the ICE:

• Interactive multi touch large screen embedded in the meeting table, which can be controlled by different participants
• A control pannel can be connected with most of the common used devices
• Dropbox can be used to transfer files from and to the system
• Analog switch can turn on/off the whole system
• Three different cameras distributed around the meeting room to help when video conferencing with others
• Interactive touch screens placed on the walls for discussions which needs participants to stand and explain

One fact about this project, that I liked was the use of analog switch to turn on/off the system was a cleaver idea. I've been in the user shoe and I know how frustrated are users when they get around this type of systems.

Dr. Mival also indicated that spaces and places should be included in any user interface design. He closed his talk by indicating that now as the HCI research and industry is getting advanced, any further work in the interface design should consider all the following factors: people, places, activities, context.

Interesting facts and issues raised by Dr. Mival were:

• HCI and Interface design should adapt people tasks not the other way around. He gave an example about their ICE design, the multi-touch screen in the table was designed to handle mugs, laptops, etc in top of them. He mentioned that, you can't ask people not to bring coffee or tea in their meetings!
•  Hands wave gesture interfaces are not usable. Simply, user will get tired after a couple of minutes.

Here is a video about the ICE system. I thought it would be cool to share it with you:

Joint Application Development (JAD)/ Discovery Sessions

JAD session, is a meeting where analysts meet with all stakeholders in one room to identify the system requirements. It is similar to focus groups, except that in here all stakeholders brought together in one meeting to agree on system requirements. JAD session has a potential risk of undiscovered clashes. Typically, stakeholders with more power can resolve any disagreement in their favor (their point of view), so it is essential for analyst to understand that and to be aware of any potential risks.
JAD session is intended to capture requirements from multiple stakeholders. Additional tools may be used within JAD session to help in modeling requirements, and therefore help stakeholders to understand requirements being captured. Tools can be any modeling tools like: use-case diagrams, activity diagrams, etc. Brainstorming can be used on ambiguous points, also prototyping can be used.

According to our referenced book [3], a good JAD session should contain between 5-10 participants, but can go up to 15-20 if needed. Participants can be categorized under the following types:

• The Facilitator: is the person who will guide the session and controls it. According to [3], this is the most important type to the success of JAD session. A good facilitator would stop any unneeded discussion, and will make sure that session is working as planned. Some of the facilitator roles are as the follows: timekeeper, mediator of conflicts, coordinate different groups within the session (if any), summarizing discussions.
• Business Analyst: the one who manage session goals, and should explain to the facilitator the goals up front.
• Scribe: the person who take notes during the meeting.
• User (customer).
• Domain expert (subject matter expert): sometimes it is important to bring some expertise in certain technology or certain thing needed to enrich meetings.
• Developer: this will bridge the gap between developer and customer needs.
• Sponsor: OF COURSE
• Observer(s): if you need to train someone about JAD session, we would call them observers. Note, that an observer could be someone who have an interest in attending the JAD session but will be minimally engaged.

JAD session can be conducted in four simple steps as shown in the figure below[3]:

• Establish Goals and Objectives: explain meeting goals and objectives to the participants.
• Prepare for the Session: making sure that participants are there, everything is in place, and all the needed tools are there.
• Conduct the session.
• Follow-up: to complete the documentation. Also, by presenting the results to the sponsor, and following up any issues, or outstanding issues.

In case of any non-agreed upon points, small JAD session might be assigned to some members of a smaller JAD session. JAD sessions will provide a good support from users since they were involved in the sessions, however as any other meeting types, JAD session can end up in generating conflicts between participants which makes it harder to be resolved.

Observation (Job Shadowing)

Observation (or job shadowing) is an effective way to elicit requirements from an end-user point of view [3]. Through this technique, requirement engineer can define what are the steps needed to perform every user task. This can be in details, or in an abstract view (as needed). Our reference [3] indicated three methods to conduct observation (or job shadowing) as the following:

• Job shadowing: analyst will be at the user site, and interact with user to understand how he/she perform his tasks. The analyst note the needed actions for every task.
• Videos: if available video recording of user activities which explains how user perform his/her tasks. Analyst can perform the observation offsite. Also, it worth mentioning that this method saves time.
• one-way mirror-type setup: this type is in between the two above, analyst will observe a real time activities of a user on a medium; like live video camera (with user permission). The advantage here is to observe more than one user at a time.

Observation is a great technique to capture the current requirement or workflow, however it might have the following drawbacks:

• Sometimes, users tend to over act when they’re observed.
• Time consuming: Analyst may spend a lot of time to observe users.
• Analyst needs to be critical to ignore any user behavior outside the job being observed.

Interviews

Interviews [3]


Interviews is part of the Ethnographic Techniques, that I blogged about before. Here I will provide a detailed article about this technique.

Despite the fact that interviews are involved in any elicitation technique, what we’re discussing here is a stand-alone interview technique.
The basic form of interviews will aim to meet every stakeholder a one-to-one meeting to note his/her requirements, opinion, and assumptions about the system. This basic approach works handy when we have the following:

• Less disagreement between different stakeholders
• Stakeholders are geographically distributed and can’t meet togeather
• Some stakeholders can’t leave their workplace and engage in workshops and meetings

With the above in mind, it is important to keep the requirements shared between all stakeholders to eliminate any conflicts or disagreements. If any stakeholder disagree with requirements, then a formal walk-through would be needed with the disagreed stakeholder to verify and eliminate it.

Interviews can be categorized in two types as the following:

1. Open-ended interviews: requirements engineer (or interviewer) start the interview with an open-ended questions as the start point, the record the response and elaborate with stakeholder if needed. This type is useful when few we have few stakeholders, and when the interviewer is experienced.
2. Closed-ended interviews (Surveys): in this type, interviewer will design a survey; similar to survey technique; in which interviewer go on the survey questions by question with stakeholder and record the response. This type is beneficial when the interviewer is less experienced, and when we have many stakeholders (less time).

Interview process can be repeated until stakeholder understand and provide his/her best feedback. The following steps describes a good way to prepare an interview:

1. Keep in mind that you can’t interview all stakeholders, so use the stakeholders analysis to select the most important stakeholders (key users) to interview, then for each, identify a high-level goals for the interview; what you want to get from that interview; in which you will focus in the interview to capture a good requirements.
2. Schedule an appointment with stakeholders, and let them know how important are their feedback to the system.
3. Before meeting each stakeholder, learn something about their knowledge about the current system (or business workflow); and try to realize what area on the system they can provide a good feedback about.
4. Write some questions specified for every stakeholder according to their role and knowledge, and then refine the questions.
5. Send out the questions to the customer before meeting, so they can realize how important this meeting is, and how committed you are to the interview.

In addition to the above about preparation, a requirement engineer may use the following type of questions when designing an interview:

• Open-ended questions. When you want the customer (stakeholder) to express his/her opinion about some system process. This is also a useful technique to let the customer open up to you in an interview.
• Closed-ended questions. When you need precise and short answer from the customer.
• Probing questions. Used when you want the customer to elaborate about a requirement they mentioned. For example, if a customer said “ Our system should function 100% in our working hours ” , so you may ask “Can you specify what are the working hours?”.
• Validating questions. To go over requirements and models (i.e charts) and show them to customer and check their agreement, or disagreements.

The main point of interviews is to discover the unknowns. Reference [3] provides a step-by-step process to discover the unknowns throughout interview starting with the known. Steps are as the follows:

1. Interviewer should understand the problem boundaries and describe it using any method; [3] suggested using Functional Decomposition Diagram (FDD) see figure [3] below; then should explain it to the customer and make sure that customer understand it. This will help in bringing the customer in the same page.
2. Interviewer should define the problem being proposed to be solved here, either a system problem or a business problem.  
3. Identify the root causes for the problem being discussed. Interviewer need to be focus causes other than the main root cause which was already identified.
4. “Envision the future.” Discuss with customer what he/she and you think about the current situation (AS-IS) and what they think will be when this system is done (TO-BE).

At the end, interviews is a good elicitation technique, which provides an insight into details needed for good requirements. However, some customers may not be committed to those interviews, and sometimes its hard to control the interruptions in interviews.

Focus groups

Focus group is a structural guided meeting with sampled potential customers to determine their feedback about an upcoming product (or system) [2]. Typical session would take between an hour and two. Like brainstorming session, focus groups needs a moderator to lead the discussion about the product. To have a good results, the sampled group should represents the prospect users.

A business analysis book [2] suggested that the ideal focus group should contain between 6 to 12 people due to the non feasibility of large groups.

One major drawback of focus groups is that it depends heavily on the way moderator handles the groups discussion. People who participate might not share their true opinion when they discuss issues in the focus group.