Before Submission

By Tuesday, we had all delivered our prototype documents and uploaded the videos. I did most of my video and document last week but made some last changes on Monday. Given that our team chose to build separate parts of the same concept, as explained in previous posts, we also found it most useful to create a team-based video and include that in our videos. Looking at the finished video, I believe it turned out quite good and that we did well in creating the team-based video. Everything revolving the video and document took much longer than I expected, so for the last couple of weeks, I have focused more on PhysComp than my thesis.

Tuesday and out

From Tuesday and out, we focused solely on writing our feedback to the other teams, responding to the few questions we got and starting to look over the feedback we received. After meeting up for the studio on Tuesday, we all gathered and started to write out feedback. First, we tried to have one person share their screen and watch the videos together like so, to be able to play and pause along the way to comment. However, we quickly found this ineffective and started to watch the videos on our own and then meet up between videos to read the documents, discuss them and come up with rough bullet points with feedback. For the first group, we started to write summaries of our bullet points before going to the next person's video. For the second team, we just wrote down bullet points from the video and documents, discussed them to come up with more and then moved on. Before starting on the third group some members of the team wanted a break, and some wanted to go on. After discussing for a bit, we came up with an asynchronous solution where two of us, Thomas and I, continued to the last group straight away and the two others to come back and do their review of the last group later. Moreover, Thomas and I were to summarise the comments for the second group as everyone had already written their comments for them and then Tuva and Marie could summarise the third group when they reviewed them later that day. In my opinion, this solution worked much better and was more effective. We decided to go through all summaries after Thursday's workshop, before commenting on Miro.

For the rest of the week, I had to focus on my master thesis given that I had focused on PhysComp for a long time and had to pick up the slack on the thesis. Besides the feedback, this week was quite uneventful.

Video editing and document writing

This week I've spent writing the prototype document and editing both my own and the teams video presentations. It took a lot more effort and time than I anticipated, but its mostly because I wanted it to look and feel professional so I spent extra time adding elements to improve the overall experience. I started with filming the parts that needed live footage from both the building and interacting with the prototype. I then made some animations in after effekts so illustrate what the narration was talking about. I think my video ended up being pretty good at least I'm quite happy with it.

Going forward

I've been thinking a lot about what kind of improvements I can add to my prototype after the presentation on Tuesday as I've concluded the basic intended interaction + added some additional features. As mentioned before I conducted a user testing which provided useful feedback. Not only for my prototype but also for the the concept in general. Several additional features was suggested and some could be relatively easy to add and will increase the user experience. What I think is the most important element to remember is to keep the concept user friendly.

I hope the presentation on Tuesday will go well and that my team and I will be able to write good appraisals relatively quick since there are a lot that will be happening going forward.

For this week I have been focused on creating the individual and team video in addition to writing the prototype document for delivery.

Studio

In Tuesday's session, we had our regular Stand-up. As with most weeks, there's not much to say about the stand-up. We talk about where we were at with our prototype, what we had recently achieved, last-minute tasks and concerns. I had in the previous week finalised my prototype and started to conduct user research. I've noticed that it's rather difficult to get testers these days as both Thomas and I combined have only been able to recruit a few. My guess is that people do have a lot going on these days. As for week 9, it was mostly going to be spent working on the submission itself and I didn't really have any concerns around the delivery.

After Studio

After the studio, we had a short team meeting to discuss who was going to work on what parts for the team-based sections of the assessment. Thomas and I were to create a script for the team-based video and for the interaction plan whereas Tuva was going to record a voice-over and draw the interaction plan. We decided that Marie could put the video together once all elements were in place.

Workshop

The workshop was rather uneventful. Few people showed up and it took a long time before we got started. Once started there didn't seem to be a plan of content other than the tutors being available if we needed help. Given that I did not need any help I kept on working with my deliverables.

After Workshop

On Thursday we had a short meeting to discuss the interaction paradigm of our concept and then went on to work more on the deliverables.

Rest of the Week

By Friday Thomas and I had filmed some footage to put in our team-based video and handed that off to Marie for her to put it in the video. For the rest of the week, I mostly worked on my individual prototype document and video. This week was pretty straight forward. The most confusing and difficult part was to analyse and understand what we actually were meant to have in the video and supporting document as descriptions were a bit vague and abstract, resulting in a lot of back and forth to get it right. As for my own video, I had to redo a couple of video clips as I found out I had filmed it in the wrong orientation and then later found out I had to few clips to fill out the movie. So, I decided to shoot some filler clips.

Lastly, I took Sunday off just to have a breather as I've been struggling with a severe lack of motivation lately.

This week has been a slow week since I've been sick most of it and had to take some time off to recover. I have, however, been able to add some additional functionality to my prototype. Originally, the only indicator the user had of whether or not the transmission had been successful after the action had been performed was that the light within the ball turned off. After some user research I discovered that this in itself was not enough as it could be confused with just a reset of the ball and not necessarily an indication that it was a success. I decided therefore to add vibration to the mix to further enhance the feeling of a successful throw. Overall, the new version of the prototype now vibrates after the throw(when the ball has landed in the users hand again) that is a sure indication that the data on the ball has been sent to the server and the other user soon will receive the recorded message.

Next week I will focus on making the video and the document for the prototype delivery the final week.

Decisions

Both Thomas and I decided at the beginning of this week to scrap our plans to have audio working on the Arduino prototype. Both of us experienced a lot of issues with the SD card reader which turned out to be faulty SD card readers, which lost us around 1.5 weeks of progress. Because I couldn't get the speaker and card reader to work I instead started to look at how I could play sounds on my computer based on a command from the Arduino. I looked into using the navigator.mediaDevices function found in JavaScript, which I made work when tested in an isolated environment. However, new issues started to arise as I tried to merge the code into my existing client file. Given that navigator.mediaDevices only exist in the browser and my client file needs to be locally run on the machine to access the USB port I had a difficult time finding a good solution. The most promising solution I found was to use Puppeteer, a headless browser based on chromium to have access to built-in browser functionality while running the file from the local environment. However, I still had some issues figuring out how to use Puppeteer for this specific task. Given that I had already spent a lot of time on this issue I did not want to waste any more, so I instead opted to simulate all audio for my prototype just using a phone.

Studio & Workshop

As for this week, we had a standard speak-up at the beginning of our studio class and the rest of the time for both the studio and workshop focused on just keep working on the prototype. As for the studio stand-up, we were to answer a couple of questions, the first one being the one big question we have about the prototype deliverable. I didn't really have any questions, as my main question was how to get audio up and running, but since I scrapped that plan, I knew where I was going from there. As for the main thing I wanted to have working was the actual interaction of squeezing the sphere to listen to the recording and a notification function to display incoming messages.

Building

As for my prototype progress, I started with changing out my RBG LED light to a NeoPixel LED strip as our team decided that we wanted to make our prototypes look similar given that they are all smaller parts of a complete experience. I refactored my code from the RBG LED light and had a working notification pulse running in a short amount of time. Now that the lights worked, I focused on getting the interaction up and running by using a bend sensor to sense squeezing. The only difficulty I found using the bend sensor is that the numbers seem to change from time to time, even when I haven't touched the prototype, so I have to calibrate the sensitivity every now and then. When both the lights and squeeze interaction was up and running I chose to implement some basic haptic feedback using a vibration motor inside of the sphere. At this point in time, the prototype has three different states, as shown below.

STATE 1: No Notification

STATE 2: Notification - Pulsating Light

STATE 3: Squeeze to Listen

STATE 1: No Notification

One milestone both Thomas and I achieved this week was to link up our two prototypes. After his prototype is finished simulating a recording a simulated colour, which in the future would come from Tuva's prototype is sent over the server Marie set up and then received by my computer and forwarded to the my Arduino which then starts to pulsate the colour that was sent. This helps us give a sense of context to prototype testers and helps demonstrate the core functionality of the project.

Preparing Prototype Test & Recruiting Prototype Testers

Given that Thomas and I have similar functionality, just that my prototype is the receiving end and he is the sender, we chose to create a joint prototype test. We are planning to conduct two to three group tests with two participants in each group, depending on how many groups we get access to. We sat down together and created a two-sided test with an interview where we both get to test our own aspects in addition to testing a combination of both sending and receiving a message. Luckily we both live with two other people, so we are able to conduct one group face-to-face prototype test. However, for the other groups, we have had to reach out to our friends and do remote interviews. To do this, we have started to videotape our prototypes and written down questions of which will be sent to our testers next week.

General Thoughts

I have felt a huge change in motivation lately where I've seen my productivity level sink drastically over the last couple of weeks. I worked several weeks to get my thesis prototype up and running and I faced a lot of technical issues that I had to brute force my way through to get a working prototype. Now that a similar thing happened for the Physical Computing Prototype I have lost a great deal of motivation. Working with Arduinos in both subjects, a technology we barely know how works and not knowing a whole lot about how electricity works feels daunting. Online education for these types of subjects is far from optimal as I don't feel like I get the help I need, even if the teaching staff tries their best. It also seems like we spend most of our time learning to use a tool instead of learning about interaction design. Hopefully, I will see a return of motivation soon as we are closing in on the end of the semester.

My Individual Concept

My concept is a device that will help primary school children learn about weight, fractions and ratios through manipulating musical sounds. The device will look like a flat rectangular box, divided into individual segments for each note. Users will place weights on pressure sensors in the appropriate segment to alter the length each note will play for. Users can also change the pitch of each note by changing out the 'note block' associated with that segment. Once the user has selected all notes and weights, they press the play button. Notes will play in order from left to right, each held for as long as the weights indicate. For example, a note with 100g weight will play for half as long as a note with 200g weight. A basic sketch of the design can be seen below.

Although the image only shows four note segments, my ideal final product would be a board with between 8 and 12 segments, so that users can create actual tunes rather than a short series of notes. There would also be an optional linking connection, so that multiple boards could be linked together infinitely, allowing users to create even longer tunes.

This week has been focusing on the physical interaction of my prototype. My team decided to divide the prototype into different parts and I was distributed the part where the user throws the ball into the air to send the audio recording previously made and stored within the ball. As mentioned in a previous post, I was also distributed with making the server and client that would make communication between the balls possible, but this was a separate part of my tasks.

The part in the process that I was building comes right after the ball has been shaken and the user has chosen a colour. When the user is satisfied with both the message and the colour to represent it, the user throws the balls upwards and catches it, which tells the code to send the message to the connected user on the other end.

My team and I purchased some components ourselves which was delivered to us last week, among the components we ordered was an accelerometer which was bought especially for my part of the prototype. The first challenge that I came across was the fact that I needed to solder the accelerometer to the pin thing(the one that you need to fasten it to the breadboard) as it wasn't able to get enough contact without and therefore didn't work. After talking to the tutors they were able to provide me with one that was already soldered so I met up with a tutor and got a different one.

Second challenge was the sensitivity of the accelerometer on its own. I used a tutorial which showed me the raw data the chip made but as it turned out it even registered gravity and the reading that was displayed varied constantly even when not touched. Aften finding a tutorial that showed me a library that made more sens of the reading I could code it to react when exceeding a specific number (when I threw the ball up). As I'm inexperienced in this tech I might have understood it or explained it a bit wrong, but as far as I gathered that was the initial problem I experienced.

Since I'm basically done with my part of the concept I'm looking at other ways of interaction and how to make the experience more complex. It is also something that I will discuss with my team in the nearby future.

During the mid-break

Since my project is not just about Arduino modules, but it also related to art crafts or even home improvement stuff. I spent more time than I expected to find the parts to make sure that I didn't miss any components that I need for my project before I place the order. Finally, I got all the stuff figured out and ordered during the mid-break. I thought I would use parts from the hairdryer I disassembled to build the smoke effect, but it turned out that I would still need a multimeter to test the voltage, current, and resistance. Therefore, I can only work on it when all my parts arrived. At the main time, I am still refining the design of the final product. In my earlier ideas, which I wrote in my previous blog, I would want to either build a house or a room; however, after I talked to Allison about my individual concept and input data that I want to collect. Allison suggested an idea of making a terrarium, the representation of the earth, and the ecosystem as a whole. It was a great idea!! I thought about the ecosystem concept before, but I didn't know how to present it in the design.

Individual Concept

The team concept aims to teach children about global warming and environmental protection. My concept is letting children know that they can be a part of the movement in their daily base by simply turn off the light when they don't use it and be conscious when using water. My individual focus I want to be narrow it down to children's behavior in the household. My plan is to create a smoke-based interaction depends on the data inputs: not turned off the lights and cautious on water usage(this is what I had for now) would trigger the smoke. Moreover, I would like to create an ecosystem that has the soil and the plant like a terrarium. It has a soil moisture sensor to detect the health of the soil, and temperature sensor to measure the temperature degree. The smoke would create when the user forgot to turn off the lights or be cautious using water. How the terrarium works, the lights create the heat, and when the heat rises, it triggered the smoke. The terrarium acts as earth, and smoke would be the effect of bad habits that causes the earth to suffer. I want to show that every action has consequences, and we couldn't undo what we had done. Of course, when a good habit was built, it will give the terrarium waters, plant more seeds, and add more warms.

My ideal finished product

My ideal finished product would be a beautiful terrarium that has plants, grass, and flowers. I want to build a terrarium that has its own ecosystem with all the sensors and detection would work. It's a small version of the earth. All the wires will be hidden in the wooden house, which is built from paddle sticks. However, I haven't built any of the parts, yet this design might change later based on any circumstances that might occur during the prototyping process.

What am I going to do?

In the next few days, I will work on research to find how to teach children about sustainability, primarily focus on the household. It would be helpful if I can find some information about teaching children about sustainability with things that could easily find in the household since I can't have an in-person interview or user testing. To bring the idea across, it would be hard for children to learn without having any probs. As for me, the best and simplest ideas would be teaching them how to do recycling, and any objects at home can be a prob to teach children if it is recyclable or not.

For the next steps, I want to create an interview and survey questions even though I don't have anyone to do the interview yet, but I hope I could find some from my friends' circle. Since working with children was not an easy task, and parents usually are more conscious. I felt it was the hardest task in this project. However, it would be nice to have some understanding of how children are cautious about sustainability at this generation.

Midsemester

I didn't get to do a whole lot over midsem as I had to focus on my master thesis. However, during the first weekend, Thomas and I went into the city to find some suitable spheres to work with. The most optimal ball we found was plastic Christmas decorations, as they were both transparent which would let us use lights inside and somewhat squishy to allow for a squish interaction. These balls weren't ideal, but definitely enough for us to get our first prototype up and running given that we aren't going to focus on form and feel for the first prototype. Towards the end of midsem we received our parts in the mail, which at this point had been delayed for about six days. Thomas and I, given that we live in the same household and that we are working on two sides of the same interaction, started to test the parts (SD card reader, microphone, speaker and lights). I had some progress working out a solution with pulsating lights for a notification feature by sending in RBG values through the serial port, simulating the data transferred from another Arduino.

Week 7

As for the weekend leading up to week seven and until Thursday's workshop, except for the regular stand-up at Tuesday's studio, I spent all my time trying to work out an issue with the SD card reader. Both Thomas and I was working with SD card readers, but none of us was able to make them work. We received some help from Steven and Ben after the workshop which led to us figuring out that the SD card readers had a fault in them so we had to give up on trying to make it work. Steven and Ben suggested that we could look into streaming over serial, make use of a raspberry pi instead or use a computer to simulate the interaction of voice recording and playing the recording. Having looked into the complexity of streaming audio over serial, and not having time to learn a new tool we chose to pursue the option of using JavaScript to record and play audio from the computer-based on input from the Arduino. I tried to look up how I could use JavaScript to record and play audio files, but soon after ended up stuck again not being able to get this to work either. By this point, since I hadn't had a day off in weeks I chose to take a couple of days to rest.

Concept

My team chose to work on the same concept and divide it into smaller prototypes that together make a whole concept. The overall concept (E-mories) consists of a basket full of spheres that will double up as an emotional sharing platform and a decoration in the house. Each sphere is capable of recording and playing audio for people to send each other messages. When a user wishes to send a friend a message, they simply pick up a sphere and squeeze it to start recording. When done recording he or she can then shake the sphere to choose a colour corresponding to the mood of the message they are sending. When the user is happy with their combination of message and colour they can throw it up in the air to send the message. On the receiving end in another household, there is an identical basket of spheres. When a message is received a sphere will start to glow in the colour the sender chose to notify the receiver of an incoming message. The receiver can then pick up the sphere to listen to the message. The concept tries to facilitate and encourage positive emotional sharing for people that are unable to meet face-to-face and give them a sense of being closer to each other through a physical platform.

We divided this concept into four parts, where mine revolves around the receiving end of the concept, where I'm looking into how to show a notification of incoming messages and play the audio recording.

In an ideal world, I would say that this concept included more than two senses, as in not only audio or lights. I would like the concept to include deep meaningful memories that people wish to share with one and each other consisting of smell, video, images, sound, touch and more. My personal idea of the concept is for it to contain complex combinations of memories consisting of the above-mentioned factors and for users to be able to build upon old memories with new memories and reflect on their memories together. However, given that we have yet to prototype test our current solution it is difficult to say if this is the correct path to pursue.

For Tuesday's studio class, we had a stand up as per usual, talking about how far along our team have come in the process and what we are planning to do next. I find these stand-ups to be wasteful given that we spend a lot of time doing something that does not move our project forward. I would prefer it if each group had their own breakout room and a tutor came by to check in on the progress as this would be far more valuable.

After the stand-up, we moved on to an online exercise using the tool MIRO. Our task was to find a way to conduct user research in COVID times and how to get valuable first-hand data without the need of meeting face-to-face. For this task, I looked up a youtube video of passengers on a train and observed their behaviour. Although I can see why the teacher team wanted to make us student open our eyes to the possibilities that still exist, I didn't find it overly helpful as the exercise wasn't relatable to conducting a prototype test, which is the next assessment piece in the course. I find that I get the most value out of meeting- and discussing with the team instead of performing stand-ups and these types of tasks as they take away time that we could have spent on our project.

The next task on MIRO was really helpful to us. Even though we already had a good understanding of our concept, it is always nice to map out the complexity and fully comprehend the quirks and commonalities of the project you are working on. Our team sat down together and went through our concept and tried to map out as much as possible to further define our concept as can be seen in the pictures below.

From this exercise, some new questions emerged that we had to take into consideration when working on our prototypes and conducting user research. These questions were such as: "does it need to be a ball?"; "is flashing lights the best metaphors for incoming messages?"; "is sound the best input and output?"; "Can it be anything else than a bowl?"; "Is squeeze the best interaction?"; "Is the living room the best place for it?" and more. These questions are important to consider moving forward and to include in our upcoming user research. Moreover, from this exercise, we did figure out that our target audience was rather vague and needed more working on.

On Thursday we had a Arduino tutorial. Having already worked with Arduino previously I found the content too basic and decided to instead focus on refining the assignment prior to delivery. Moreover, our team sat down to order the parts we needed so that we could get them in time for our next deadline. We decided to purchase our parts with express delivery to get a headstart on the prototype.

Studio and Workshop

Our proposal report was due this week, so we spent a lot of our team time and free time working on it. However, we also spent some time during the studio session on Miro board, and had some discussion about how to access users for interviews and observation during the current lockdown situation. Our task in class was to find a way to observe passengers on a train from where we were sitting, and then discover some other ways we could observe passengers remotely using different techniques and technologies.

Then we moved on to team boards, and spent some time mapping out our theme, domain, user group(s), and so on, in relation to our concepts. As my team has decided to all design separate concepts for the same user group, we only focused on mapping out the parts that applied to the whole team.

I found both these exercises quite helpful, especially in terms of getting ideas for how to do user research under the current restrictions. It was also nice to get a more concrete layout of the design space and user group we needed to focus on.

The workshop was focused on a basic introduction to Arduinos. I have used an Arduino before, but that was nearly 2 years ago, and I'd forgotten most of it. Thankfully, once I started going through some of the activities, it all came back pretty quickly, and I'm feeling a lot more confident that I'll be able to take on any part of my concept that may end up using one.

Report and Individual Concept

As mentioned before, our report was due this week, and we spent a fair bit of time as a team figuring out which aspects were part of our team section, and which parts we needed to write about individually. We decided that a lot of the general background research we had done, as well as our user group and context of use, were similar across all our concepts, so that became part of our team section. We then put all other aspects relating to our individual concepts in the individual sections.

As I had finally decided on my concept at the end of last week, I spent some time this week trying to visualise it, and create a preliminary design sketch to be included in the report.

I don't entirely know how exactly I will achieve all of the functions I want, but after the Arduino workshop on Thursday I feel a lot more confident about the electronic aspects I might need to tackle, and I also trust the experience of the tutors to be able to answer any questions I might have.

This week was a bit more hectic than expected, because we ended up losing two team members and gaining a new one. I completely understand people's reasons for choosing to drop the course at this time, and it was nice that we had some time this week to sort out the new directions we would take as a result of feedback from last week's presentation, as well as new team formation.

Following meetings across the studio and workshop sessions this week, we decided that individual concepts would work best for our team set up, as none of us live together, and it would be difficult to collaborate on a single design. We decided to focus on using music and sound in a primary school classroom setting to help learn in other non-musical areas, such as maths and art. We then helped each other flesh out our individual concepts through discussion and brainstorming.

At the beginning of this week, I was undecided on what my concept would be, other than a vague idea of somehow using music to help students learn braille. I did some research into this during the week, as well as spoke to tutors during studio time, and ultimately came to the conclusion that there is very little consensus on the 'correct' associations between sounds and letters, and it would be very difficult to justify any design decisions I made because of this.

Therefore, after being inspired by my team mate Maria and her focus on using sound to learn multiplication, I decided to create a concept around another mathematical concept, as it is much easier to find research about links between maths and music. I came up with the idea of using weights and musical rhythm to help students conceptualise ratios and fractions in a new way. At this stage, I'm thinking that users will place weights on a sensor, and the amount of weight will correspond to how long the note will play for. So a note with 200g of weight will play for twice as long as a note with 100g of weight. I will need to spend some time developing this further, and come up with an idea of what this device might look like.

Finishing the proposal

The last week before the break, my team and I manage to finish the proposal. The week before we had finished the team part of the writing so this week I wrote my individual part. It was much harder than writing the team part because of all the uncertainty and lack of knowledge on what you are doing exactly and what you need/expect to happen.

Starting on the project

My team decided to go for the first option on how to divide the project which was working on the one concept just divide the different part between us. The part that I was allocated was creating a server to which the devices will upload and download the content on the balls and also develop the upwards trow which indicate the sending of the information currently stored on the ball. During the mid-semester break I managed to create a server on UQCloud which was more challenging that I anticipated. I have made zones before, but this time I only needed a server and not a webpage so I decided to install an image (Ubuntu) instead of the regular one, but what I didn't know was that neither npm or node was install on this one so it had to be done manually through the terminal. There was also some concern on whether or not a vpn had to be used every time one accessed the server but this was later revealed to not be necessary. To create the server I used socket.io which was a request by one of the team members who had some previous knowledge on it.

The next following weeks I plan on finishing the prototype and developing the throwing motion with Arduino and also conduct some user research and maybe starting on the video for the presentation.

Week 5

I had a rough week 5 because my accommodation kicked everyone out due to rising cases in COVID-19 in Queensland and for safety because of which I couldn't attend either the Tuesday's session or the Friday's session. I had informed my team about this and was trying to keep my communications as quick as possible. My team had communicated with me and had decided that we will be proceeding with the Option-2 for our team concept and individual prototype building part.

---

Week 6

This week, I had to finish the team part and the individual part of our proposal report. We had decided that I will be doing the problem space/concept part of the report. I had started researching more about global warming and its cause. I was trying to think about what are the different things that we can use or we can inform children about global warming. I found out stuff such as plastic contributes to greenhouse gas emissions at every stage of its lifecycle, from its production to its refining and the way it is disposed of. Meaning that it's not only bad for the ocean and environment, it also contributes to global warming.

After the team part, I worked on the individual part of the report. I read all the feedback again. Kasey had copied all the feedback and put it on our google drive which made things a lot easier.

As we hadn't finalised any input method, my plan for the break is to come up with a system of input, and output response. A system which should be interactive and fun for children. Although it is easier to come up with the output method from the globe of our concept, I will look into different sensors that can be used as well.

On the Tuesday of week 4, we had our group presentation on a topic which had to be novel, interactive, fun and physical. We had decided that we will be going with the topic of teaching people about global warming with an interactive device. I think live presentation in front of a classroom would have been a lot more fun because we were planning on having volunteers to come up and do a small demo of our concept. But, cause of restrictions we decided to make a video to explain our concept as demonstrating the concept online-live through a skit would have been very difficult.

We had divided into different tasks that everyone in the group will be researching about and preparing for the video. I particularly looked into explaining the problem space. I recorded my voice using my phone (which did not have the quality that I was expecting) and sent my part of the presentation with the recording to Kasey, who was editing the video together and had the rest of the voice over. Eddie had planned to do the skit for giving a demo of our concept with his housemates.

After our presentation, we received critique feedback from the class, all the teaching staff members on slack and via zoom.

After that, we talked to Alison and clay in a private zoom room on the things that we can improve and they helped with different ideas. The main aspects that we talked about were how to make the input more interactive and who will be our target audience.

Later in the week, we had a group meeting to discuss about the proposal-report. We also tried to discuss the various input methods that can be replaced in our original idea, but we failed to do so. Hence we decided to meet again on Sunday where everyone would bring in 2 ideas for 'ways of input' and bring in 2-3 research paper related to any aspect of our concept.

I had mostly researched global warming and sociology, and teaching children about global warming which I shared and summarised to our group. One of the input methods that I preferred that I thought of was having 2 garbage bins as the inputs. One for plastic and the other for biodegradable things only. Depending on how much each bin weighs, it will affect the globe accordingly. such as if the plastic garbage bin weighs more, then the earth will turn grey and brownish with sounds on cars honking, whereas if there is more biodegradable things or less plastic the globe turns green and blue with sounds of birds chirping and rivers flowing. But the only problem that we discussed with this way of input was that it was too binary, like before when we had received the feedback about our presentation.

Eddie came up with another Idea of input where we use a strip which can take our inputs via our finger. We will be able to glide across it to input.

But we still have to research more on the ways of inputting.

Later we also divided the sections of the individual report to make things easier.

Tuesday

In the studio session we learned about how to conduct different types of fieldwork during a pandemic and how to use a Miro board.

Miro Board

This is what my team mate and I came up with. Additional information about our projects will be added in after we determine the details of our form.

Individual

My Project - Spud

Spud is a small robot that sits on the user's shoulder and uses its body language and facial expressions to show its sassy personality.

User Testing Ideas

From the background research I have done for the proposal, I got an idea of getting participants to show what body language they think is suitable for an emotion. Participants will be given a figurine/teddy bear to move its limbs to create body postures and paper cut outs of eyebrows to position it on its face to create different facial expressions.To find the best method of a shock factor, different methods of shocking participants will be used. For example, the Jack-in-the-box with springs, glowing red, showing teeth, etc.

All of these testing will be done with my housemates during the mid semester break so I can start building Spud as soon as possible.

This week I worked on the group presentation report establishing the concept, domain space and what i want to work on throughout this course, creating a working hand with gestures to promote social distance. The report work consisted of research of papers in similar fields and on concepts using gesture controls, people's understanding of gestures both by itself and when paired with emotions. These found that many simple gestures are hard to misinterpret, allowing easy understanding, at least in western/Australian culture of signals such as a 'thumbs up', 'flipping the bird', 'rock on' and 'hang loose' signs all being quite recognizable, (with most people just reading the names here and you know what fingers to hold up).

In addition to this, robotics are at a stage where hands with dexterity and a range of motion can be created, and as a mock-up, i iterated upon the hand design and made a cardboard mock of the robotic hand for size and joint/movement reference. This will be used to see how feasible the size of the hand is along with future use for interpretation and understanding of the concept based of user reactions. The mock was given further detail to illustrate the concept, overall turning out quite well for a first draft, while future improvements can be made. These include; giving the joints a wider range of motion, capped finger tips without the rough edges or flat tips, a smaller and more pronounced 'hand' design that is clearly identifiable with a smaller more manageable size.

One team member of our group dropped this course due to the online teaching, so with the help of the teacher, three members of our group and two members of another group formed as a new team. fortunate, both of our topics are "body as controller".

Meeting 1

Through the first meeting, we learned about the research theme of their group. Their team is based on environmental protection games, through the body control to eliminate harmful waste, and finally get a certain educational significance. Our team uses physical control sensors to strike objects in the virtual vent space.

Through the feedback of the speech, we summarized the advantages and disadvantages of the two groups:

-Our team：

Advantages ：Specific sensors and background research are available to provide adequate information on solutions to relieve stress.

Disadvantages ：Because of the use of destroying virtual items to release pressure, this method of decompression is questioned whether it is "too extreme." Some people asked that if users use this method to relieve stress for a long time, maybe they will be violent.

• Their team：

Advantages：With a good background (environmental protection), environmental protection is a popular topic in nowadays life. We can extend the application of this theme to have good educational significance.

Disadvantages ：There are no specific plans, such as what sensors will be used to make the game.

###Conclusion

By analyzing the advantages and disadvantages of the two projects, we have generated a new idea:

We decided to use the background of protecting the environment, which can make our works more meaningful. On the other hand, we will continue to make use of body control sensors to hit trash that destroys the natural environment. (Eg: In an ocean scene, there is some marine debris floating in the water. The user can use the glove in his hand to trigger the sensor to eliminate the garbage in the ocean. This is just a preliminary idea) Such a combination makes up for, in addition to the shortcomings of the two groups, the goals and themes are also more abundant.

Workshop - Analyse User Interviews

Between Tuesday and Thursday, we all did one user interview to gather some initial data to further move along our project. To start with, in the Thursday workshop, we summarised and analysed our interview findings. What we found was that people aren't very comfortable sharing emotions and when they do they prefer to do it face-to-face. Moreover, our users told us that they feel it helps to talk about their feelings. We also gathered some similar data on how our users perceive emotions and thoughts around emotional sharing. I feel we gathered some good data that would easily help us decide on the one concept we will pursue as well as an initial understanding of our target audience. Doing these interviews wasn't ideal given the current restrictions set in place due to COVID-19, but I feel we managed it nicely as we all live with other people that were in our target audience. One thing to consider though is that the people we live with won't provide a complete picture as the demographics are fairly limited. It's also going to be interesting to see how we can manage our way around these same restrictions when we have to test our prototype, but I'm confident that we will be able to perform some quality testing sessions when that time comes.

Based on this feedback we started to discuss some ways to change our focus and came up with some ideas that revolved around moving to a self-awareness focus, making it controversial, making it easier for people to talk or focus on the positive emotions. After a short discussion, we all figured we were most excited by exploring sharing positive emotions with others. This choice was made due to how our data told us that people don't really talk about their positive emotions and that they are not very comfortable sharing their negative emotions.

Around this time we got some guidance from Steven as we had some difficulty focusing our concept and getting down to the nitty-gritty details. Steven gave us some great advice which helped us immensely, which was to take a step back and look at what questions we are trying to answer. By now we had decided on wanting to focus on lifting the spirit in the home. Steven told us to focus on what we would like to achieve, as in, find a goal. He gave us some examples from his own experience that helped us understand what he meant with finding our goal.

After the meeting with Steven, we took a step back and went at our goal. We started off with "How can we lift the spirit in the home?" and went through a couple of iterations where we asked ourselves questions and tried to answer them with a new version of the goal. One example of this is how we asked ourselves "How can we help sharing positive emotions between homes?". We figured based on our data that people were most comfortable sharing with close friends and family that we should make it more personal or humanise the emotional sharing. This led to a new goal of "Help personalise emotional sharing and lift spirit of others when remote". We went through a couple of more iterations before we landed on something we were satisfied with that we all felt covered what we wanted to achieve. Our new goal at this point was "Encourage positive emotional sharing with close ones remotely". We had a short brainstorming session on new concepts that fell under this new goal before we decided to take a break and meet back after a couple of hours. We all agreed to write down some new questions based on our goal for when we got back and to create a concept with a rough sketch, a target audience and an intended experience.

Later that day, we all met back online and went over each of our questions and sketches. My questions were as follows:

• Can positive emotions be shared?
• Can positive emotions be shared in the form of memories, music, sounds, color, lights, haptic feedback, and or heat?
• Are positive emotions equally valuable when shared digitally?
• Can we encourage emotional sharing?
• Will positive emotions overshadow people’s need for feeling down?
• What does positive emotions look like for different people when shared?
• When do people want to share positive emotions?

These questions, in addition to the ones the other team members come up with are meant to be used throughout our development. Moreover, I presented a concept of a wearable that would encourage sharing memories with people you had experienced them with previously. This device would allow for recording information in various formats and had the intended experience of encouraging people to reflect and reminisce with close ones on the good memories you shared. Without going into too much detail the high-level concept is a wearable that when visiting places with memories from before, can ‘rewind’ and see, hear, feel a collection of those memories on your wearable device. Friends who was there will be notified as well that you are reliving that memory and can join in on it. After all ideas and questions had been presented we went over all of them and gave feedback to each other. Finally, we picked pieces from the concepts we liked and put them all into one final concept to present in our proposal. We divided the concept into two parts, one that we would like to present as our intended MVP and the other part as a future version where we would like to be in an ideal situation.

Before the meeting ended, we decided on some research topics we all were to explore further and divided the concept proposal amongst ourselves.

Over the Weekend

I got to write about and detail our goal and research question, which was nice as I got to take a look back and see how we got to where we were now and why we chose our path. Moreover, I found it useful to dissect our research question and define every bit of it and how it was all connected back to our domain of Emotional Intelligence. Like everyone else, I too found a peer-reviewed article to be used in our proposal. I found an article on how shared experienced regardless of communication is amplified, which to me were quite interesting. This article had some limitations for our purpose as it didn't explore if the same effect would be possible if people shared an experience remotely. Hopefully, through our prototypes, we will be able to provide an answer to this question. On Monday, I wrote the section on how our concept was relevant to the brief. Having already written about our research question I was quite confident on what our concept was and how it relates to the brief, so I had no real difficulty doing so. Lastly, before our meeting on Monday, Thomas and I went through the document and made grammar and content suggestions to improve what was already written.

Potential Methods of Inquiry

As for my own concept, where I'm looking into the interface response to incoming messages through coloured lights and how to play the recorded message, I'm focusing on post-prototype methods rather than pre-prototype methods. The reason for which I choose to not focus on pre-prototype methods is due to the team's initial research which covered enough for me to move forward with my prototype. With that said, I will, to the extent it is possible and ethical, do a combination of prototype tests with interviewing and observations. Where this approach is not feasible, I will instead focus on an online format trying to retrieve similar feedback. Moreover, given our restricted situation, I have considered conducting a heuristic walkthrough of the prototype using the other team members as experts, but this has yet to be decided in the upcoming weeks.

Tuesday - Contact

On Tuesday we started off with a 'stand-up' where each person in all teams was to explain what the team and they themselves had done so far in the course. Although interesting to listen to what the other teams are doing there was a lot of overlap and repetition from many team members. So far in the process, most of what we have done is as a team and therefore there is little extra to tell when asking a second team member. I believe we would hear more unique aspects moving forwards as we are moving into the individual parts of the course. However, I'm also concerned about the amount of time this takes up and if it's worth the time as I didn't feel like I learned anything from this exercise.

After the stand-up, we jumped into team chats to work on our concept. In this meeting, we talked about starting to write the report and work out how we could split the concept between ourselves. We decided that we wanted to split prototypes based on outputs and inputs. Given that Thomas and I live in the same house we decided that we could take one input and one output so that we are able to test if everything works as it is supposed to locally before testing remote. Moreover, Tuva was to prototype automatic input and Marie were to prototype an output. However, at this point, it was still unclear what the individual prototypes should be.

At this point, Ben came in to give us some feedback on our concept. He brought up some good points on how manual input could be an extra barrier of entry. We also discussed how we should consider the physical aspect of the concept such as what the balls are doing and how they could be interacted with. Ben also gave us some technical suggestions to look into such as ESP32s or ESP8266s for the connectivity and Galvanic Skin Response(GSR) as a sensor in case we wanted to measure emotions as users were holding the ball in their hands. Finally, we asked for some tips and tricks too for user interviews.

After our feedback from Ben, we went on to create an interview protocol to get some early information on how people understand emotions, how they display them as well as if and when they are comfortable sharing emotions. We decided to write some open-ended questions to begin the interview with, continue with a task to allow users to show us how they think and then end with some more directed questions.