Predictive evaluation, Cognitive Walkthroughs & Heuristics

Predictive evaluation was a tool introduced in Kate Devlins HCI lectures in 2011. I am planning on applying it to the project as a form of prototype evaluation prior to its introduction to a focus group. This should allow me to identify any glaring issues and tweak the prototype accordingly before going to do a pilot test.


I am referring to a few resources whilst preparing for it: the book 'User Interface Design And Evaluation by Deborah L. Stone, Debbie Stone' as well as the following online resources http://courses.csail.mit.edu/6.831/archive/2008/lectures/L18-predictive-evaluation/L18-predictive-evaluation.pdf http://www.sigchi.org/chi96/proceedings/shortpap/Hamilton/hf_txt.htm. The importance of it as a n early developmental evaluation methodology is emphasised in the book (Chapter 19, page 406) 'Alyson: Heuristic or predictive evaluation and trial-based (user based) evaluation, complement each other. If we'd only used predictive evaluation, we wouldn't have had the response from the real individuals who are going to be affected by the system; as a usability assessor, I could have sat there and said "Yes, it's not going to affect memory load, yes the design is consistent,.... yes the design is simple." But I'm not a user. I wouldn't have known what it was like to use it for real.'


There are positive and negative aspects to said evaluation. In the first link (a PDF from a User Interfact Design lecture at MIT. 


'Today’s lecture is about predictive evaluation – the holy grail of usability engineering.  If we had an accurate model for the way a human used a computer interface, we would be able to predict the usability of a design, without having to actually build it, test it against real people, and measure their behaviour.  User interface design would then become more like other fields of engineering.  Civil engineers can use models (of material stress and strain) to predict the load that can be carried by a bridge; they don’t have to build it and test it to destruction first.  As user interface designers, we’d like to do the same thing. '

It points out the necessity of having a model for how a user interacts with an interface. This link http://www.usabilityfirst.com/usability-methods/hci-design-approaches/ gives a list of approaches to HCI and explains the GOMS method: Goals, Operators, Methods and Selection Rules. It was developed in 1983 by Stuart Card, Thomas P Moran and Allen Newell.

'Goals are defined as what the user desires to accomplish on the website. Operators are the atomic-level actions that the user performs to reach a goal, such as motor actions, perceptions, and cognitive processes. Methods are procedures that include a series of operators and sub-goals that the user employs to accomplish a goal. Selection Rules refer to a user’s personal decision about which method will work best in a particular situation in order to reach a goal.

The GOMS model is based on human information processing theory, and certain measurements of human performance are used to calculate the time it takes to complete a goal. For example, the average time it takes a human to visually fixate on a web page, move eye fixation to another part of the web page, cognitively process information, and make a decision of what to do next can be measured in milliseconds. The times it takes for each of these operators can be added up to produce the total time for a particular method. Multiple methods can be compared based on the total time to complete a task in order to determine which is the most efficient method for accomplishing the task.'

Advantages of doing predictive evaluation is that it doesn't involve users, or in some cases, require a prototype. It allows for comparison between different ideas and can identify problems before implementation is complete. 'predictive evaluation not only identifies usability problems, but actually provides an explanation of them based on the theoretical model underlying the evaluation... User testing might show that design A is
25% slower than design B at a doing a particular task, but it won’t explain why.  Predictive evaluation breaks down the user’s behaviour into little pieces, so that you can actually point at the part of the task that was slower, and see why it was slower.' - http://courses.csail.mit.edu/6.831/archive/2008/lectures/L18-predictive-evaluation/L18-predictive-evaluation.pdf

KLM is also useful wih predictive evaluation (Keystroke-Level Monitoring as it evaluates the time required by users to execute tasks. 'The first predictive model was the keystroke level model (proposed by Card, Moran & Newell, “The Keystroke Level Model for User Performance Time with Interactive Systems”, CACM, v23 n7, July 1978).. This model seeks to predict efficiency (time taken by expert users doing routine tasks) by breaking down the user’s behavior into a sequence of the five primitive operators shown here.

'Human Information Processing Model

Human Information Processing (HIP) Theory describes the flow of information from the world, into the human mind, and back into the world. When a human pays attention to something, the information first gets encoded based on the sensory system that channeled the information (visual, auditory, haptic, etc.). Next, the information moves into Working Memory, formerly known as Short-Term memory. Working Memory can hold a limited amount of information for up to approximately 30 seconds. Repeating or rehearsing information may increase this duration. After Working Memory, the information may go into Long-Term Memory or simply be forgotten. Long-Term Memory is believed to be unlimited, relatively permanent memory storage. After information has been stored in long-term memory, humans can retrieve that information via recall or recognition. The accuracy of information recall is based on the environmental conditions and the way that information was initially encoded by the senses. If a human is in a similar sensory experience at the time of memory recall as he was during the encoding of a prior experience, his recall of that experience will be more accurate and complete.'

Predictive evaluation involves task analysis, and it was not only this that i wanted to analyse. I also wanted to analyse how easy the prototype was to use, how easily the instructions are to follow and to generally analyse the interface. It is for this reaso that i have decided to do a 'cognitive walkthrough instead' which is a step by step analysis of the processes undertaken to interact with a system. Also as it is such a simple interface the tasks executed will be done quite quickly and taking timings will not be massively beneficial. My 'cognitive walkthrough' seeks to evaluate the presentation and execution of the system as a whole, not just timings of individual tasks. I am going to tweak this 'predictive evaluation' into more of a predictive walk-through with a novice user. I am going to use Schneiderman's 8 Golden Rules to assess whether my interface is successful with its accompanying manual http://faculty.washington.edu/jtenenbg/courses/360/f04/sessions/schneidermanGoldenRules.html

I am going to do a step-by-step evaluation of:

1. Reading the manual
2. Manipulating the bear
3. Closing communication

If any problems arise i will say them aloud, and will do a 'cognitive walkthrough' to identify every step that is being made. I will record the audio of evaluation and analyse the results. I will need an end user, and then will swap roles with that person to evaluate their responses. There will be two 'predictive evaluations. I will probably need two manuals as the two bears will be different. I will need to consider the possibility of proximity sensing 'how do i know they are there and received my message?'.

I will use this evaluation to create a version 3.1 prototype (and manual) which i will then do a pilot user test with and then a focus group.

I am referring to these guidelines on cognitive walkthroughs: http://www.usabilityfirst.com/usability-methods/cognitive-walkthroughs/ http://ics.colorado.edu/techpubs/pdf/93-07.pdf. I will also take timings on how long it takes to execute  individual tasks.

Week 29 Log

Week beginning 23/04/2012

Goals Achieved: Completed the stage 3 prototype, completed the manual for user review.

Goals Outstanding: Test stage 3 prototype, evaluate manual & website with techniques i.e. user testing, participatory design & heuristics (normans 7 principles), usability & experience goals. Do a user test where a user is given nothing but the manual & the object and is observed. Use the Goetz & LeCompte framework. There will be predictive evaluation conducted.

This week has involved preparation for the final round of user testing and prototype evaluation to develop the final stage 4 prototype. Once this is complete the accompanying materials i.e. packaging, manual, advert /video & a website will be developed. 

Transient Memory: A new mode of communication....

This project was led by research into memory, but in transmitting memories it becomes communication. All communication involves memory of some kind as it is essentially the transference of information whether this be talking, emailing, instant messaging or anything else.

Technology has facilitated the crossing of geographic boundaries between people, and we are now more than every able to keep in touch with people far away from us. This project has created a new method of electronic communication. I have narrowed down my context and user base, but what underpins it is transient memory.

I want to show how it contributes to the field of electronic communication. There is lots written about electronic communication, and how it can be both beneficial and detrimental.

There are a few fundamental aspects of this project which differentiate it from others.

1. A single purpose object
2. Paired architecture between two users. No networking aspect or expandability.
3. Transient communication. No data recovery; once it's gone there is no evidence of the transmission every existing.
4. Form led functionality.

This http://ccs.mit.edu/papers/CCSWP167.html is an interesting paper titled 'SHAPING ELECTRONIC COMMUNICATION: The Metastructuring of Technology in Use'. It explores ways in which electronic communication methodologies can be adapted to suit differing contexts of use. 'In this paper we identify a role -- technology-use mediation -- which we define as the deliberate, organisationally-sanctioned intervention within the context of use which helps to adapt a new communication technology to that context, modifies the context as appropriate to accommodate use of the technology, and facilitates the ongoing usefulness of the technology over time.' 

'Technology-use mediation' has been utilised within this project to explore different ways in which memories (or essentially communication) can be valuable in their transient form.

'Technology Structuring' is described in the essay as the ways in which technologies are 'structured by uses in their context of use'. 

'As a role that influences the interaction of users with their technology, mediation can also be viewed from the framework of structuration theory (Giddens, 1984), and particularly in terms of how technologies are structured by users in their contexts of use (Barley, 1986; DeSanctis and Poole, 1994; Orlikowski, 1992b; Walsham, 1993; Weick, 1990). The structuring of technologies in use refers to the processes through which users manipulate their technologies to accomplish work, and the ways in which their actions draw on and reproduce (or sometimes change) the particular social contexts within which they work.

Technology structuring is influenced by users' interpretations of their work, the organization, and technology, their access to organizational and technological resources, and the normative rules that guide action in their social context. A general outline of the technology structuring process is depicted in Figure 1. [2]Users draw on existing institutional rules and resources (e.g., division of labor and work procedures; arrow 1) to use the technological capabilities available to them (arrow 2). In using their technology to accomplish some task, users appropriate their technology (arrow 3) and enact certain social practices, which reinforce, adjust or change the existing institutional realm (e.g., division of labor and work procedures; arrow 4). The influence of individuals' technology use on the institutional properties are often unintended and unnoticed, just as the influence of the institutional properties on technology use is often unnoticed and unacknowledged.'

Some peoples adaptation of their communication technologies can be spurred by situations where the technology is not working properly. In the version 2 user test, a user mentioned the way in which she put timestamps on text messages when she had a very slow phone so that her friends knew when they were sent, and vice versa. Communication technologies should be designed with how and when they will be used in mind, otherwise they wouldn't be used.

Analysing users day to day lives and looking at their interactions with technologies can inspire interventions, which is what this paper is about really. My project worked the other way round at times, with a general concept being developed, then a context of use and design established, and the design was tweaked to suit it.

This paper http://ctl.ypu.edu.tw/ezfiles/17/1017/attach/51/pta_11206_6271112_54993.pdf focuses on the negative effects of electronic communication at work. It suggests that the perceived effects of interaction with electronic communication could be symptomatic of the core characteristics of said communication. 

'Electronic mail, for instance, filters out personal and social cues and provides new capabilities not found in traditional media, and it has been argued that these factors have consequences such as “flaming” and depersonalization.Alternative theoretical perspectives on the impacts of information technology suggest that our ability to explain these outcomes might be enhanced by attending to users’ intentional choices about how to use technology and to the unpredictable technology usage patterns that; emerge when users interact with the technology and each other. These alternative perspectives are examined in the context of an exploratory case study of a complex organization in which electronic mail was heavily used.

Users were found to select email deliberately when they wished to avoid unwanted social interactions. At the same time, they actively took steps to avoid negative outcomes, such as depersonalization of their relationships with subordinates. However, despite their well-intentioned efforts, some negative social effects did occur that cannot entirely be attributed to the technological characteristics of electronic communication. Instead, they appear to be ironic side effects of users’ thoughtful efforts to use email effectively'

It makes the point that certain mediums can affect users behaviours and the way they interact via them. User intent is thought to play a part in the observed negative behaviours and actions, but so are the tools and limitations presented by technologies. These tools and limitations change the way that users interact with eachother, and a theory that i was exploring was whether memory storage and retrieval was always a good thing within systems.

This paper http://dash.harvard.edu/bitstream/handle/1/3382980/mandl_electronic.pdf?sequence=1 explores an emerging proposal for email communications between doctors and patients. 

'This paper seeks  to identify the promise and pitfalls of electronic patient-pbysician communication before such technology becomes widely  d i s t r i b u t e d. A research agenda is proposed  that would provide data that are useful for careful shaping of the communications infrastructure. The paper addresses the need  to 1) define appropriate use of the various modes of patient-physician communication, 2) ensure the security and confidentiality of patient information, 3) create user interfaces that guide patients in effective use of the technology, 4) proactively assess medicolegal liability, and 5) ensure access  to the technology by a  multicultural, multilingual population with varying degrees of literacy.'

Email is presented as a useful technology, but 'Health care providers need a framework for choosing the communication mode that is most appropriate for each situation'. The problem is of increased administration and the lack of customer satisfaction that comes with inadequate communication. Security and confidentiality are crucial, which is also a consideration with my project although with such personal sensitive information involves within health care this is hugely important. Customers may not want to have their information emailed to them! It proposes controls on message frequency and priority. There are also the issues of access to technology and multiple languages.  

Prototype 3 focus Group Prep

In the next few days I am going to conduct a focus group to evaluate the phase 3 prototype.

The focus group will have three members and will be classed as a 'mini-group', which was endorsed by Krueger (1994). The specialism of the group is based on whether they fit into the specific age categories, whether they have a close friend or family member living away from them, and whether they keep memento's of people in general. Whether they keep memento's will not be a reason to accept/reject a potential participant, it is just for the record. I believe that most people keep memento's, but if any participants do not it could be interesting to compare their feedback.

I will also test my thesis with this focus group: "transient memory increases the value of memories transmitted between two people. it conveys a sense of presence and a feeling of being 'connected' to another person".

To select my focus group users, I will ask them to do a basic on-line questionnaire to determine their suitability.

The on-line questionnaire is hosted here:

I had to quantify a few things i.e. what is 'far away'. I chose a distance of over 1 hour or 30 miles away because this is classed as the 'normal commuting distance' by some employers. I have presumed that people living over an hour away are people that a person would not really see daily, unless you are commuting to a common place. I also had to quantify frequency of seeing them at 'less than once a week'.

The focus group will mainly be an evaluation of appropriateness, context of use and core interaction. Participants will be asked on their opinions on the prototype both positive and negative as well as discussion of the content and presentation of the manual. The key has been removed, and whether it needs to be reintroduced with be discussed. Other features will be discussed such as presence indication, and the usage of the device as a storytelling bear for other markets.

The framework will be similar to the previous one, but there will be more focus on the actual interaction and whether improvements can be made.

Full Size Teddy Bear Models

Now that the wires have arrived, I just need to implement the following;

1. longer wires for contacts & LED
2. button contacts on the wires
3. edit the audio on the mp3 player
4. insert all wiring into the teddy bears

Once this is complete i can do a focus group and other types of prototype evaluation as mentioned before in my weekly goals.

The first thing i did was strip down the ends of the wires. I then soldered the buttons onto the ends of the wires as well as soldering long wires onto an LED to use as an indicator light.

I then tested the original xbee circuits to check that they were working correctly. They suddenly are very buggy. Below is my schematic:

I was experiencing some bugs with the circuit last time and when i turned it on again today it didn't work at all. I re-posted to the arduino forums as someone had mentioned the possibility that the mp3 player was interfering with the arduino's whole power supply. After doing this i realised that i'd been following advice that the things connected to the relay had to share a common ground with the arduino. This was what was causing the problems. So i decided to see if i could get it to work without having them share a common ground and moved a single wire across. 

It worked! I posted my solution to the arduino forum in case anyone else wanted to learn from my mistakes. http://arduino.cc/forum/index.php/topic,102291.0.html

New fritzing diagram.

Building the wiring into the bear:

The metal contacts for use in the hands are extremely conductive and work perfectly. There is debounce code on them with is useful. The LED on long wires had to be re-soldered because the little fragments of wire didn't come together as they should have.

The next step was to insert the components into the bear. I planned on leaving the bulk of the circuitry outside of the bear until testing was complete, which is why i needed extra long wires. I pierced small holes in the fabric using a seam ripper as well as small rips in the seam so i could get my hand in to manipulate the wiring. I also insulated the LED wires using teddy bear stuffing to stop it short-circuiting.

Above is the bear all wired up. Notice the contacts in the palm of its hands. The green led is the heart area, and i will possibly put an actual heart logo there. 

I may also put hearts in the palms of their hands.

Next i need to work on preparation for target user evaluation, and do predictive and heuristic evaluation of the prototype.

Weekly Log: 27-28

Week beginning 09/04/2012

Goals achieved: Focus group, context of use verification, completion of stage 2 prototyping in the spiral model, requirements capture, user base, context of use, stage 3 prototype development, Manual & Website development.

The last two weeks have involved prototype development and user testing as well as the development of accompanying materials i.e. a manual. A pilot test was conducted prior to the focus group which was extremely useful and a version 2 prototype was developed from this to use this to focus group. Informed consent forms were used to address ethical concerns as well as to inform participants. A question sheet was utilised to guide the discussion and to keep notes. The presentation of the project has also been considered.

As well as the development work, the contextual report has been worked on.

Goals for next week: Complete & Test stage 3 prototype, evaluate manual & website with techniques i.e. user testing, participatory design & heuristics (normans 7 principles), usability & experience goals. Do a user test where a user is given nothing but the manual & the object and is observed. Use the Goetz & LeCompte framework.

Version 3 Development: Website & Manual

Whilst I am waiting for the long wire to complete the prototype physical build, I am going to work on two other things from the task list: an informative website and an instruction manual.

I have completed some development work in my sketchbook and worked out a rough design for the manual and a layout for the website so far. These will also be brought to the focus group for review. In addition to this I will have a look at similar manuals/websites to compare their content and to ensure mine meets the requirements and conveys all the information it should.

Below: Development work from my sketchbook

I had a look at some manuals online whilst developing my list of requirements.

My requirements: Warning, Instructions & Care information all need to be on the manual. The toys themselves will already have a care label on them and these will be removed if they conflict with my care instructions, and any information lost will be put on my new label.

I have decided on a heart theme, and have done a mockup for it. The clip art for the heart is taken from http://technorati.com/politics/article/the-tell-tale-heart/

I changed the design slightly from the drawing and had the two cuddly toys just standing on either side of the heart. I've made them different to represent the two different people that they will belong to, and this is reflected in the differences between the actual toys that i'm using.

This is an official document that allows you to categorise your toys by age: http://www.cpsc.gov/businfo/adg.pdf it give age determination guidelines, and takes into consideration factors such as small parts and abuse testing.

'Small Parts Regulation1 In 1979, the Commission issued a regulation under provisions of the FHSA to ban certain toys intended for use by children under 3 years of age if they present a choking, aspiration, or
ingestion hazard because of small parts. This regulation, known as the Small Parts Regulation, is
published in the Code of Federal Regulations, Title 16, Sections 1500.18(a)(9), 1500.50–52, and
Part 1501. '

Although this product is being targeted at 18-25 year olds, it may be bought by them to use with younger people so age appropriateness must be taken into consideration.

However, i do not intend the toy to be used for anyone below the age of 3. The most important part of the document was the section on 'Dolls and stuffed toys'. Weight, size and cleaning ability are considered. It is mentioned that children as young as young as 12-18 months can interact with toys that have a sound or visual response to input such a a push button. However, they cannot have toys that represent a choking hazard and the teddy share system would do with the small metal buttons that can probably be pulled off.

Children aged 6-8 begin to respond well to more structured activity, and children as young as 4 can comprehend a moderate to high level of cause-and-effect activity i.e. a movement response to buttons.

From analysis of this document i'd suggest that this toy is appropriate for anyone aged 5 and older in terms of safety and comprehension, so i can add this to the manual mockup.

side 1

side 2

I have noticed though that the layout needs to be on the opposite side for side 2, but for now this is how it will look. The website development will be continued later.

Version 3 Development: External Physical Build

Currently waiting on: Longer wires to arrive from oomlaut

Two larger teddy bears have been purchased for this project. They are both different, but this was to give users a choice between them to see if they have any preference as well as to illustrate how the form could be changeable.

Pictures of the two bears are below. they are 3x as big as the original bears and will comfortably hold the wiring.

The arms are about 15cm long, but i think it would be a good idea to have wires long enough for the arduino to sit outside the bear whilst functionality is confirmed (so that i'm not going in blind and wondering where a wire has fallen out if something goes wrong which it has done in the past).

Permanent Build: It would be great if i could make a PCB, as in this tutorial http://www.theparsley.com/arduino/diy/ to stop the wires falling out but another option is to use stripboard which is far simpler http://www.hobbytronics.co.uk/stripboard-95-127 I believe i will use this option for the final prototype.

I have to move the 'i'm missing you' file on the SD card to slot 1 as the music is currently being played to debug. The delay time will be matched to the exact duration of the track that is recorded. It is multi-purpose; users would be able to record any message they want (it is customisable).

Still to do for this prototype:

Wait for longer wires
Work out which contacts to use in the palms of the hands i.e. metal buttons
Create an instruction manual for review
Develop a few informative web pages for review (will bring to users-it could be used to host the advert/video, an instruction manual if it is lost and contact information)

UPDATE 22/04

Metal buttons have been purchased from a local haberdashery. They will have wires attached to the inside (usually where they are sewn on), and the round smooth top of the button will be exposed in the hands of the bears to be pushed together. There is a good surface area for conductivity, but extra solder will be added to the inside. I will have to test the resistance across the circuit as they are designed for clothing and may not be very conductive as they are not designed for electronics usage. I may have to reduce the resistance of the resistor in series with it to compensate.

Version 3 Development: Fixed Relay Function

I posted a question to the arduino forums for help

http://arduino.cc/forum/index.php/topic,102291.0.html

I got two responses from two members
1. move the indicator light code to the top
2. To 'clean up' my code of any unnecessary function calls

Note: I had to tweak the code so that the LED was normally off rather than normally on.

This fixed the relay whilst it was connected to an LED. However when i put my hacked MP3 ino the circuit, the duplication re-occurred. I noticed that with the LED there was a resistor in series with it, so i added a low-value 560ohm resistor back into the circuit (as to not stop the MP3 payer working entirely).

Partial Success! The MP3 player turned on only once! Then off again after 5 seconds

Pitfall: It did not allow quite enough current through to turn the MP3 on completely, only enough to turn the lights on it on. This means that it needs a very small resistor, so i will purchase a couple and try them to see which gets the desired result. I don't know exactly why this works as it suggests that it was a physical problem   rather than a coding one. I have reposted to the forum to see if i can get an explanation for this.

Below are snippets of my finished code

button xbee


if (digitalRead(BUTTON) == LOW) {
    digitalWrite(localINDICATOR, HIGH);
    Serial.print('D');
    delay(2000); // prevents overwhelming the serial port i increased the delay
}

relay xbee

added this line at the top to turn the relay off in its natural state :     digitalWrite(relay, HIGH); //TURN OFF


  digitalWrite(relay, LOW); //TURN ON
  delay(5000);
    digitalWrite(relay, HIGH); //TURN OFF
    delay(1000);

UPDATE: On a second tests the system seems to be working perfectly with a 560ohm resistor

Below: Video of the system working
In the video I am touching the wires together on one xBee (not visible in the video).


Below: new relay layout-note the extra resistor

Version 3 Development: work on relay function

I wanted the button to work by turning something on for x amount of seconds and then going off. To do this i added an extra external variable 'indicatorVar' as well as an extra LED on pin 1.


  if(indicatorVar==1) {
    timerVar = 1;
 
  }

  if(timerVar==1) {
  digitalWrite(ledpin2, HIGH);
  delay(5000);
    digitalWrite(ledpin2, LOW);
    timerVar = 0;
  }

With this example the delay does interrupt the program flow, but this means that duplicate messages cannot be sent which is a benefit. All i need to do now is make a few edits to the code on this side as well as that on the other side.

In the main code of the communicator xbee changed the trigger back to the original 'pushbutton'. In the code on the relay xbee i added the delay code to the main code.

I moved the code so that the indicator lights are always off, and stay solidly on rather than 'blinking' this will help to reduce the delays within the code to speed it up.

I noticed that the transmitting xBee continued to send messages long after it has been pressed, so i decided to incorporate debounce code. I also moved my relay code from inside the 'TimerVar' conditional. These two actions helped with reducing the repeating problem, but now it still repeating twice. I am going to try and use a switch operative which may help me exit the loop.

Part the conditional i removed:


 timerVar = 1;
   
      if(timerVar==1) {
   
      digitalWrite(relay, HIGH);
  delay(5000);
    digitalWrite(relay, LOW);
    delay(1000);
      }

I then changed the 'if' statement to a switch one. I used the arudino reference library to remind me of the exact syntax.

switch (var) {
    case 1:
      //do something when var equals 1
      break;
    case 2:
      //do something when var equals 2
      break;
    default: 
      // if nothing else matches, do the default
      // default is optional
  }

I had to change the transmitting to do equal numbers rather than letters.

However, this switch case still isn't improving the repetition problem.


digitalWrite(relay, HIGH);
  delay(5000);
    digitalWrite(relay, LOW);
    delay(1000); //var equals 1

this basic code works, but repeats even when within the switch framework, as below


switch (val) {
    case 'D':
 digitalWrite(relay, HIGH);
  delay(5000);
    digitalWrite(relay, LOW);
    delay(1000); //var equals 1
      break;
    case 'H':
      //do something when var equals 2
      break;
 
   
  }

The next thing i'm going to try to get around this problem is increasing the delay of  AND the delay on the debounce code.

Debounce code delay has been increased to 100

long debounceDelay = 100;    // the debounce time; increase if the output flickers


I increased the serial.write delay all the way upto 10,000 but it is still repeating twice.

The serial monitor shows that the arduino is only sending a single 'D'. I am going to post this in the arduino forums and see if i can find an answer. It might be good for the system to repeat the message twice, but i'd like it to be a design choice.

The breadboard layouts are very similar to before, see below.

I just wrote in the feedback code (where USER A knows that their message has been sent to USER B, and this exacerbated the the message duplication issue-it repeated 3 times rather than the 2).

The code is good enough to take to the next focus group, i just need to decide which contacts to add onto the wires in the bears hands (to close the circuit), get hold of larger teddies, wait for the longer wires to arrive and   incorporate the system into a new teddy bear. In the meantime i want to develop the branding and presentation of the teddy bears i.e. packaging, website, advert/video and of course develop an instruction manual. This will all be developed in the sketchbook and will be presented to users at the same time as the version 3 prototype.

Version 3 Development: the manual switch

To make a switch which closes when the bears hands close i will need two long wires to place within the bear, and two metal buttons or conductive fabric for the user to push and hold together.

Below is an annotated drawing of the teddy bear

Below is a description and drawings of how the manual switch should work as well as a component diagram.

To test this manual switch i built it on my breadboard. Below is a fritzing diagram of how this looks.

The code that i'll be using is simple pushbutton code. I am using an LED and the serial monitor.

The code checks to see if the circuit is closed, and turns the LED off if it is. It sends a '0' to the serial monitor if the circuit is open and a '1' if it is closed. It works perfectly.

 A larger surface area is required, so metal discs or conductive material will be used in the version 3 prototype once it is installed.

int indicatorVar = 0; //this is set to either 1 or 0 depending

//on if the circuit is close or open

//this will be useful in communicating with the other arduino

const int buttonPin = 2;     // the number of the pushbutton pin

//constant variable stay the same

const int ledpin = 7;

int buttonState = 0;         // variable for reading the pushbutton status

void setup() {

  // initialize the LED pin as an output:

  // initialize the pushbutton pin as an input:

  pinMode(buttonPin, INPUT);    

    pinMode(ledpin, OUTPUT);    

 Serial.begin(9600); //initialises the serial monitor

}

void loop(){

  buttonState = digitalRead(buttonPin);   // reads the state of the pushbutton value:

  Serial.println(indicatorVar); //this continuously prints the value of the status indicator

  //code to test whether circuit is closed or not

  if (buttonState == HIGH) {     

    // turn LED on:    

 digitalWrite(ledpin, HIGH); 

  indicatorVar = 0;

  } 

  else {

    // turn LED off:

  digitalWrite(ledpin, LOW); 

 indicatorVar = 1;

  }

}

How that this is working, i can move onto the next task: removing the delay and setting the system so that once it is pressed it stays on for a certain amount of time, then goes off. I will develop this on a single board then move it across to two boards.

Task List: Prototype Version 3

This is the new task and parts list to develop the new prototype based on the responses from the focus group

Prototyping

• Longer wire, cutters and extra solder COMPLETED-bought from 'oomlaut uk' and 'maplins'
• 2x larger teddy bears
• Discover why there is a delay (completely code-related) and fix it
• Work out how to trigger the 'hug' mechanism
• Will probably involve the creation of a switch with a wire in each arm
• Refer to 'Making things talk' for ideas
• Develop new prototype with 'hug' interaction without the delay
• Finish build
• Do another focus group as well as questionnaires sent for quantitative data gathering

Other goals

• Think about packaging design (if any)
• Develop instruction manual
• Do a basic website (if appropriate)
• Create a short advert
• Finish off the dissertation report
• Decide on how to present everything

Focus Group Analysis: Summary

Summary of the focus group

New user base: Younger people – going travelling/away at uni because this was the preferred choice. Aged 18-25. Male or female.

Context of use: In the home at any space within it-portability was very important to all users.

Form: form should be tailored to the user base. The teddy bear was the most popular within the focus group, but this may change when a new specific user base is tested.

Functional requirements: Users should be able to push a button and send a message ‘I’m thinking about you’ without having to continually hold onto is. The ‘hug’ motion was preferred, so users should be able to close the bears arms briefly to send the message. The bear should be portable. The sound needs to be loud enough to hear from a different room, and should only play once. The user sending the message should get visual feedback that their message has been received.

Non-functional requirements: The interaction should not be too obvious as a security feature to protect the system instead of a keypad input/physical key.  The users could feel the wiring inside the bear, so a slightly bigger bear is required.

Scenario: Jane is going away from home so her sister Sarah buys a ‘Teddy Share’ Bear and records a voice message for her as a going away present. Whenever Sarah  is missing Jane  she makes her bear send a ‘hug’ by closing its arms and this is transmitted to Jane who hears Sarah’s voice. It is very personal because she can hear Sarah’s voice and it provides a real-time connection to Sarah and lets her know that she is thinking about her right at that moment.

Persona

Jane is a 19 year old student who is moving away from home to start her art degree. She has a teddy bear that her mother bought her when she was a baby and whenever she sees it, it reminds her of her mum. Jane has never been away from home for so long before. She is used to her sister Sarah being around, and will miss her. She is given the Teddy Share bear by Sarah to take with her. Sarahs voice is recorded in the bear and will be sent whenever she is missing her. Sarah does not have to say anything else, it is just a simple message. Jane and Sarah communicate through the bear and the messages cannot be re-captured. It creates a new experience for them both to engage with.

Affordances: The bear will have markings sewn/painted onto it to illustrate where the user has to press. This was because the users has to be shown exactly where to push the trigger when it was embedded so this problem with re-occur with the new design.

Constraints: A message can only be sent every so often.

User type is Novice & Infrequent. Affordances will mean that once instructed the user should know how to use the bear, but there will be an instruction manual. As an SD card is incorporated, the users could record their own messages in person. All users are also primary users (they have hands on interaction with the device).

ESSENTIAL USE CASE DIAGRAM

USER INTENTION	SYSTEM RESPONSIBILITY
send a message
	transmit the message
	provide feedback that the message has been successfully sent

HOW TO HELP USERS FORM THE CORRECT MENTAL MODELS:

·         AFFORDANCE, SIMPLICITY, FAMILIARITY (similarity to existing systems), AVAILABLITY (Recognition and cues to reduce memory load, FLEXIBILTY (access to all objects anytime), FEEDBACK (Complete and continuous aids action validity)

·         These have all been considered in the design.

Screen-shots of the notes from the session

Focus Group Analysis

Focus Group with Teddy Share Prototype v.2:  Analysis

The users were provided with signed consent forms that had been edited to remove the audio recording section due to the length. I instead printed out my prep sheet and kept notes. I also used the prep sheet as a prompt. One of the users did a drawing which I kept.

Users were selected on the fact that they all had friends/family members that they were away from. They were contacted over the phone and in person and screened beforehand.

I ensured that all of the questions I had were answered and that all my high level goals were met. I am able to improve the prototype. The DECIDE framework as well as the question prep sheet was very useful.

This is the feedback I received.

PART1: Opinions, Context of use and user base

Users like the prototype i.e. ‘very good’, ‘we like it’, and all agreed that it was useful and that they would use it themselves. Examples of when they’d use it was ‘when my sisters at uni’. They suggested ‘parents/children, couples, friends, or anybody that wants to tell someone they love them’.

They all use alternative methods to show that they missed someone that was far away. Examples of these methods were ‘phone, call, text, bbm, ping, letters’. They all used these methods currently for various reasons i.e. ‘just to say hello’. I added a question last minute ‘What are the benefits of this system over other?’. The responses were:

·         Personal

·         Fun Element

·         Direct element

·         You don’t have to give a reason for contacting them i.e. if you have nothing else to say except for that they are missed.

·         Historically the teddy bear already has certain connotations (in relation to why the form of the teddy bear is appropriate

PART 2: Interaction questions

They thought that the twisting control was easy to use, but all preferred to use a button instead for example embedded in the hand for them to squeeze.

They like the idea of putting the hands together to send the message as well as squeezing the stomach of the bear (instead of the hand)

They felt that all users i.e. children would be able to manipulate the control easily, but this would have to be tested by representatives of a specific user base. They would prefer to be able to push the button once to send a message rather than holding onto it. This was because ‘how would we know how long to push it??’. Which is very valid.

I  suggested a system where you place the bear on something to send the message, and one user liked it and drew a design for a platform, but the other users disliked it due to the constraints presented by it ‘you’d have to leave it in one place and it wouldn’t be as portable’.

Below is the drawing of the system.

I added a single question ‘What kind of messages would you send?’.

·         ‘Thinking of you’

·         ‘Wish you were here’

·         ‘I just called to say I love you’

·         Boo’

·         ‘Hello how was work today’

·         ‘Goodnight’

‘Thinking of you’ got all votes, but this system is meant to be tailored to suit the individual so it can be left open ended. However the primary message for presentation could be the ‘I’m thinking of you’.

PART 3: SECURITY

Users were split 50-50 on their personal preference between the key nd the password, but all agree that it would depend on the users. If it was for a child it could be made wearable.

Below is a drawing of a t-shirt design for a child generated from the focus group.

However, something detachable might be more appropriate for an older age group  they saiddue to concerns around reliability and the lack of access. ‘if it was in a t-shirt, you’d have to wash it eventually which would make it off-limits for an amount of time’. They also suggested voice activation but mentioned that this might be a bit over the top. One user gave an example of a scenario ‘when I had a slow phone that send messages with a massive delay I put a code 123 on the end of messages and added a time code on it which let my friends know it was from me and knew what time I had sent them.’ There was the idea of a secret code and validation.

In terms of protection, I mentioned the fact that because it would look like an ordinary teddy bear, it wouldn’t be obvious so people wouldn’t know how to use it or that they should use it at all. A user mentioned the fact that a user would probably have the teddy bear in a protected space i.e. a home or a bedroom so It wouldn’t really be interfered with. There was also point made that ‘why would anyone bother sending a fake message that a person is missing them, there’d be no point’.

I agree with this and the idea of physical protection. I did like the idea of a matching t-shirt or bracelet to go along with it, but this would only be appropriate for certain users and would have to be trialled with the next focus group.

PART 4: PHYSICALITY

Other physical manifestations suggested were keyrings, dolls and toys. One user suggested that there could be a choice of objects with the same function i.e. a toy car for a child. The other users agreed that this is possible, but felt that the bear was most appropriate for the widest range of users and personally preferred it above the other ideas. They did not want any other functions to be added.

NOTES

Users have said that the system adds to the electronic advancements of today, but this system makes it more personal and intimate. This was said without prompting and it was great  because it is the point of the system. They also said that it was universal i.e. anyone could use it and the form could be subtly tailored to suit different user bases without changing core function i.e. a toy truck with a wheel you can press. ‘It can be bought for someone going away’ as a gift which I thought was a context I hadn’t focused on. Users like the fact that it has been ‘stripped down’ and has a specific function.

The final question I asked ‘Is there one user base that sticks out for you’

·         Kids

·         Younger people

·         Connection between young & old people i.e. parents & children

Focus group prep sheets

My prep sheets for the focus group today

Participators: 6 members aged 18-50. 

Start time: 2pm 

How they are selected: By their familiarity with technology and whether they have a friend/family member that lives far away so i can evaluate how they communicate now, and see whether the prototype is a useful one

Recordings: no audio recordings will be taken (will be changed on the informed consent forms) due to the potential length of the focus group. Notes will be taken and space has been provided on the prep sheets for this. 

Medium: Paper, pens and plasticine are provided for users to dicuss, evaluate and generate the prototype. They are encouraged to interact in a tactile way and be clear when conveying their ideas to other members of the group the discussion

Duration: 1-2 hours. This new duration will be added to the informed consent forms.

The prep sheets:

Once this evaluation is completed, i will re-address the prototype, determine a user base and context of use then select a focus group with these characteristics for the next stage of testing. I will determine new requirements and develop a final scenario and personas. After this i will do the final evaluation using all of the techniques below for triangulation. I will also determine if my users are novice, infrequent or expert and develop affordances and constraints.

EVALUATION METHODS THAT WILL BE USED 

·         EXPERT: Heuristics & Walkthroughs

·         PREDICTIVE: Tests against engineering model – simulated user

·         EMPIRICAL: Watching Users