The first prototype was completed. I conducted a detailed analysis of the prototype, including video and text. And got some feedback.

Feedback from Demo

After organizing the feedback, I came up with some useful points of information below.

• Team 1: Noise issues; dripper needs wireless transmission; dripper and test tube avoid contact
• Team 2: Intended experience not identified; few ways to stimulate user interaction, making the prototype more attractive; pressure sensor not suitable for transmitting sound, and it can be changed to capacitive touch; pressure sensor can be used for volume; LED lighting based on recording time; light color and dimness indicate the type of sound
• Team 3: Concept of individual contribution is unclear; use of scenes and everyday sound sources is unclear; single sound editing feature does not meet user needs; suggestion to let people take melody from something that is stressful

1. Functionality: noise/more editing

The issue of noise has been mentioned in previous feedback. Our group also discussed this issue and found it to be a difficult one to address. Neither of the previous solutions (using third party software/editing audio files with Python) seemed to solve the problem in terms of implementation (if editing with third party software on a computer, the process wastes too much time and the simulation of the real product is poor / if editing audio with Python, this is a very complex feature as it needs to identify noise and useful sounds, we don't think we can do this with our coding capabilities, perhaps a similar feature or module can be found online), so we put this solution at the end of the project and if there is time we will consider how to implement it.

More editing functionality is also within our design considerations, but this is in the test tube part, not the recording and transmission part. Since this part of my content is basically done (with a very little left to improve), I'll help other group members with their complex content, such as the sound editing features of the test tube. According to the previous concept, the user was basically unable to edit the music. But we'll try to accomplish some simple editing functions, like volume. Hopefully, it will help users have a better experience.

2. Physical interaction: wireless transmission / capacitive touch

One person mentioned that a wireless transmission module should be used in the dropper section. There are 2 questions that get pondered ahead of time: whether it can be put in and whether it's necessary. Because the dropper we use is particularly small and there is no room for other sensors after the buttons and LEDs have been placed (another option is to tape the sensor to the outside of the dropper), there is a need to consider aesthetics as well as necessity. Because the LEDs and buttons must be connected to the development board, this means that it is impossible to be truly wireless (the storage of recordings has also been discussed before and this problem cannot be avoided). In terms of specific productions, we've thought about portability. Using a long line, rather than a short line, enables the user to hold the dropper and move within a certain range. So unless we can address the audio storage and aesthetic issues, wireless transmission will not be considered again for inclusion in our project.

We don't know much about capacitive touch yet. Discussion and research with group members is needed to decide whether to use the feedback. On top of that, there was feedback that the dropper should not touch the test tube for triggering sound transmission (this is standard chemical procedure). We didn't think of a better way to do this, so we used a pressure sensor. But the feedback still raised the issue, which made me need to rethink how to implement the transmit function again.

3. Visual feedback: LED

LED lights were really my next focus in the design direction. The feedback says that the number/brightness of lights on is used to indicate the duration of the recording. It's really one of my future design directions. Because we use a relatively small physical dropper, it's difficult to fit all 3 lights in, so I'm talking to the group about how to solve this problem. My current idea is to swap the LED for an LED strip, but in a previous operation I found that both LED strips could not be used at the same time (I tried to swap the LED in the jar for a strip, but failed. We don't know what it is yet, but it's safe to say that the code part is not a problem. Then it could be a circuit problem). If it is not possible to use multiple LED strips at the same time, we need to think of other ways. Another reason for me to stick with the LED strip is that the color of its lamp is richer, more varied and brighter, and from all aspects, the effect of using it is much better than LED.

4. Concept description: intended experience/personal contribution/use of scenarios/daily sound sources

It's true that the description of these parts was overlooked. Originally, I thought that the introduction of domain space, target audience and sketch of the project at the beginning of the video would give the viewer a general idea of what the whole project is about, but the use of scenarios and intended experience still needs to be introduced. This leads to a bias in the group's understanding of our overall project. They didn't know what everyday sounds were (in the video, we used pictures of birds in place of real natural environments, leading the other group to think we were getting the sounds from the pictures). And through analysis of their comments, it appears that they misunderstand our concept (their comments are also very succinct and do not explain the specifics. I'm confused and unsure about some of the comments), so I'm hoping to have another discussion with their group members to clarify their views on our project.

5. Conceptual change: taking melody from something that is stressful

The suggestion was made to be able to capture the sounds of objects that can cause stress. I don't quite understand why this group would come up with such an idea. First of all, stress normally comes from studies, work, family conflicts, etc. Would it make users feel more stressed and annoyed if they had to listen to these sounds over and over again? (e.g. parental bickering and decorating sounds) (which is not what our project was designed to do. Our design is to hope that through the use of users, their pressure can be relieved). Beyond that, we have literature and app support (certain light music and nature sounds can reduce the user's sensitivity to stress and the user can also choose sounds that make them feel at ease), and is there theoretical support for their idea (I'm guessing it could be that frequent exposure to unpleasant sounds can reduce the user's sensitivity and increase resistance? We may need to do more research on this direction before changing the concept).

Overall, except for the concept change part, the other feedback was all in my expectation. What we accomplished this time around was just the core functionality (collecting, passing, storing, mixing, and deleting music), so there wasn't a lot of sophistication in terms of more visual and sound editing features (which was planned to be refined and designed in the next phase).

Next step:

1. Discuss the feedback and change some of the concepts
2. Design for more complex visual effects
3. the physical part needs to be redesigned to reduce the wires (for now, a box is designed as a test tube holder to hold all the wires inside. The aesthetics of other equipment need to be discussed further)
4. Purchase vibration sensor and development board with more interface
5. Discuss feedback with the group EMS