Blossom
Made by ihans, Priya Jain, Amal Jafrani and Miley Hu
Made by ihans, Priya Jain, Amal Jafrani and Miley Hu
Connected device that helps friends focus without getting distracted
Created: December 11th, 2021
We explored the space of productivity between friends. The premise of our product is that when friends study/work together, it helps them stay focused. Our product, Blossom, allows friends to still have the sentiment of "working together" even if they are physically apart. The second part of our design addresses helping friends be more mindful when they get distracted by their phones. When a friend picks up their phone off the platform of the device, their own flower and the flower on their friend's device starts to calmly breathe.
In terms of tangible design, we wanted to keep the form simple and aesthetically pleasing. We thought that a square with rounded corners would be a sleek design with 2 pastel-colored flowers. These colors are not distracting to the eye and are subtle.
We've taken the approach of using calm and ambient technology. We decided on this approach because we wanted our device to be unobtrusive, something in the background that could help users be mindful of their distractions.
Context
Here are 3 precedents that informed our design proposal:
1. Ever Blooming Mechanical Tulip
This is a flower form that blooms upon touch. We thought this was a very beautiful and delicate design. This design inspired up to use a flower as it many times represents productivity and looks nice on a desk, which is where our device is intended to be placed.
Source: https://www.instructables.com/Ever-Blooming-Mechanical-Tulip/
2. Couple Communication Device
This project inspired us to make paired connection an integral part of our design. This long-distance couple communication device is a way for couples to feel emotionally closer even though they are physically apart. This is such a meaningful use of IOT. In a similar fashion, we intended to also create a meaningful interaction between friends who want to feel like they are studying/working together even if they are apart through our device.
Source: https://www.hackster.io/dconlin/long-distance-couple-communication-device-41626e
3. Internet Connected Pomodoro Timer
This was a productivity tool that publishes your work and rest cycles to Google Sheets for analysis. We really loved the topic of productivity as it went well in combination of our previous design goals and inspirations. We also appreciated the concept of publishing data so the user could analyze their own behavior and habits. We included a similar idea in our final concept where users would receive a weekly report of their work session habits.
Source: https://blog.particle.io/particle-pomodoro-an-internet-connected-pomodoro-timer/
According to the reading Chapter 2 "Principles of Calm technology" by Amber Case, there are multiple design principles of calm technology. We incorporated the following principles from the reading in our product:
1. Requires little attention: Our device is intended to stay in the background. The lights are not bright, and the form is simple. There is also very little input needed from the user (just turning it on and placing their phone on the platform)
2. Make use of peripheral vision: The lights on the roses breathe slowly so that it would catch their attention but will not be intrusive or invasive.
3. Affective design: We believe that our product will help replicate the joy of working alongside a friend. It will connect two friends so that they are keep each other productive and less distracted.
4. Simplicity: This is something we discussed frequently. We wanted to make sure this device does only one or two things, as opposed to being a complicated device. It should be embedded into their routine, but not too demanding or difficult to learn.
Our concept is a paired device that works between two friends to motivate them to stay focused and be more mindful of distractions. Each device has two flowers — one representing the device owner, the other one representing their friend.
When the person (user 1) is ready to start working, they can use a button to turn on their focus mode, which will light up the flower representing them on both friends' devices. The flower will start to gently breathe, prompting the user to place the phone on the bottom platform of the device. Once the phone has been put down, the light will become stable.
If the friend (user 2) sees that user 1 is focusing, they can be motivated to also start their focus session. In that case, the procedure above will be repeated, after which both flowers will then light up on each person's devices.
During their focus time, if any of the two users gets distracted and picks up their phone, the flower representing this person will once again start to gently breathe on both devices. This breathing motion is designed to capture the user's attention in a non-intrusive way and remind them of their own distractions, thereby gently nudging them to go back to work.
When the focus session is over, the user can turn off the switch. By the end of each week, the user will receive an email, summarizing their focus time last week and how many times they get distracted.
Interaction Flow
We knew that we wanted to create something simple and do it well, so when it came to our design, we were mindful of both the form, behavior, and code being manageable for us. We built our code piece by piece as follows, almost as coding exercises that built on top of each other:
1. Step 1: Connect one neopixel each on two particle boards
The exercise on connecting two servo motors was helpful for this and gave us an easy starting point. However, in the beginning, we were using particle.function to trigger turning on the neopixels through the console. This worked well for the neopixel that was directly connected to the same computer but not the one listening through particle.subscribe. In trying to debug this code we learned that that was happening because particle.function is suited for simple operations (like math, assignments, etc). We fixed this issue through the second step.
2. Step 2: Connecting the photoresistor
We wanted to utilize the gesture of placing and removing the phone on the device to indicate distraction. When the device is removed, the light would breathe (slow ambient blinking) instead of staying consistent. We considered two sensors for this: the pressure sensor and the photoresistor. The pressure sensor is not very sensitive to weight and would have led to errors so we decided to use the photoresistor, such that light falling on the photoresistor would indicate distraction. This decision helped us not only with the behavior we wanted to achieve, but also solved our first issue. We could just use the thresholds for different intensities of light falling on the photoresistor for if-else statements, without needing the console or a push button to do the first step.
3. Adding the second neopixel, pretty straightforward
4. Connecting the two devices through particle.subscribe
This step took us a while to crack. Both devices had the same wiring and the code, but each photoresistor was supposed to control the behavior of a specific neopixel (either D2 or D3) but on both devices. Somewhere we had to utilize the device ID (not the token) to do this so that the handler code for particle.subscribe could use this information. We eventually figured out that this needed to be a part of our published event and wrote if-else statements that linked to two different device ids, but still kept getting an error wherein both the photoresistors were controlling all neopixels without any differentiation. Getting a second set of eyes on the code revealed a simple mistake that we had used = instead of == in the handler code which was causing the conditional statement in our code to pass.
5. Running out of data limit:
Soon after we got the code working, the particle devices we were using ran out of their data limit and we had to configure two other devices to do the same thing. We got stuck on this but our class TA helped us do this step by step through particle CLI which fixed the issue.
Deliver a functional mock-up of the device(s) prototyped using Particle. Document the outcome itself (code, circuit diagrams, photos, design files, 3d models, video demonstrations, etc. as required) and provide a short narrative. A bill of materials (sensors, input devices, actuators, and other components) should be provided. This documentation should be sufficiently rich to allow anyone to repeat/recreate it.
#include <neopixel.h>
#include <math.h>
#define PIXEL_BLUE D2
#define PIXEL_GREEN D3
#define PIXEL_COUNT 16
#define PIXEL_TYPE WS2812
Adafruit_NeoPixel stripBlue = Adafruit_NeoPixel(PIXEL_COUNT, PIXEL_BLUE, PIXEL_TYPE);
Adafruit_NeoPixel stripGreen = Adafruit_NeoPixel(PIXEL_COUNT, PIXEL_GREEN, PIXEL_TYPE);
int r = 0;
int b = 0;
int g = 0;
long lastPublishedAt = 0;
int publishAfter = 500; //the initial delay
int baseInt = 40;
int maxInt = 1000;
int currBlueInt = 40;
int currGreenInt = 40;
bool dimBlue = false;
bool dimGreen = false;
bool greenBr = true;
bool blueBr = true;
int photo = A4;
bool blueOn = false; //color for Lily = blue
bool greenOn = false;
// -1 = distracted
// 1 = working
int currentState= 0;
void setup()
{
stripBlue.begin();
stripGreen.begin();
Particle.subscribe( "working" , eventOn );
Particle.subscribe( "distracted" , eventOff );
Serial.begin( 9600 );
}
void loop()
{
publishMyEvent();
if(blueBr){
if(currBlueInt >= maxInt){
dimBlue = true;
}
else if(currBlueInt <= baseInt) {
dimBlue = false;
}
if(dimBlue){
currBlueInt-=10;
}
else{
currBlueInt+=10;
}
stripBlue.setBrightness(currBlueInt);
for(uint32_t i=0; i< stripBlue.numPixels(); i++) {
stripBlue.setPixelColor(i, 50,10,40);
}
stripBlue.show();
}
if(greenBr){
if(currGreenInt >= maxInt){
dimGreen = true;
}
else if(currGreenInt <= baseInt) {
dimGreen = false;
}
if(dimGreen){
currGreenInt-=10;
}
else{
currGreenInt+=10;
}
stripGreen.setBrightness(currGreenInt);
for(uint32_t i=0; i< stripGreen.numPixels(); i++) {
stripGreen.setPixelColor(i, 45, 25, 0);
}
stripGreen.show();
}
if (blueOn == true) {
blueBr = false;
currBlueInt = 40;
stripBlue.setBrightness(currBlueInt);
for(uint32_t i=0; i< stripBlue.numPixels(); i++) {
stripBlue.setPixelColor(i, 50,10,40);
}
stripBlue.show();
}
else {
blueBr = true;
}
if (greenOn == true){
greenBr = false;
currGreenInt = 40;
stripGreen.setBrightness(currGreenInt);
for(uint32_t i=0; i< stripGreen.numPixels(); i++) {
stripGreen.setPixelColor(i, 45,25,0);
}
stripGreen.show();
}
else {
greenBr = true;
}
// stripBlue.show();
// stripGreen.show();
delay (100);
}
void publishMyEvent()
{
// check that it's been 10 secondds since our last publish
if( lastPublishedAt + publishAfter < millis() )
{
if (System.deviceID() == "e00fce68d1958060a1d74bac"){
if (analogRead(photo) > 3000) {
if( currentState != -1){
Particle.publish( "distracted", "blue");
}
currentState = -1;
}
else{
if( currentState != 1){
Particle.publish( "working", "blue");
}
currentState = 1;
}
}
if (System.deviceID() == "e00fce687a57041bdac6f101"){
if (analogRead(photo) > 3000) {
if( currentState != -1){
Particle.publish( "distracted", "green");
}
currentState = -1;
}
else{
if( currentState != 1){
Particle.publish( "working", "green");
}
currentState = 1;
}
}
lastPublishedAt = millis();
}
}
void eventOn(const char *event, const char *data)
{
String dataString = String(data);
if (dataString.equals("blue")) {
blueOn = true;
}
else if (dataString.equals("green")) {
greenOn = true;
}
else {
return;
}
}
void eventOff(const char *event, const char *data)
{
String dataString = String(data);
if (dataString.equals("blue")) {
blueOn = false;
}
else if (dataString.equals("green")) {
greenOn = false;
}
else{
return;
}
}
Click to Expand
Discuss what you achieved with the project, what did and didn’t work, what you learned, and what you would do if you took this project forward.
Reflection on Team Roles:
As a team, initially, we decided to not have strict roles of Designer, Developer, and Lead because we didn’t want hierarchy. As we progressed in the project, we learned how tricky it can be for everyone to work on everything together, especially when the project is only 2.5-3 weeks long. So, after some initial discussions for shaping an idea, we had a conversation about each teammate’s learning goals and started dividing our energy into different parts of the idea. This proved to be helpful in the end because it helped us all find a balance between learning new things and bringing our existing skills to the table to do a successful project.
Critique and Further Steps:
Two of the interesting feedback we received were in regards to form as well as the function.
In regards to the function, during the discussion, it came up that the device would have much more of a tangible utility, in addition to our proposal, if the base of the device could be used as a charging station. This is possible by using the induction charger.
The other valid point that was raised was that the form itself did not prevent distraction caused by phone because it made the phone easily visible and accessible. Working with a form that added a subtle barrier in accessing the phone might be more helpful.
We are really grateful to Daragh (the faculty) and Kishore (the TA) who consistently helped us in debugging. Kishore also helped us out the evening before the final submission when we were a bit stuck which helped us finish in time and have a working prototype for the presentation.
Provide a list of academic papers, articles, videos, etc that you make reference to in your documentation.