Fluxx

The Project

Fluxx is a superhero cuff for children in hospitals.

We wanted to create a memorable experience for children constrained to the hospital for an extended period of time due to an illness or injury. Fluxx aims to strengthen trust between patients and nurses and encourage play and interaction between patients.

With our checklist application, nurses can input tasks for each patient to accomplish to work towards their recovery. With each completed task, a patient’s Fluxx cuff power increases. With these superpowers, children can play with Fluxx, creating light and sound effects, and can even ‘heal’ their friends by placing their Fluxx cuff over another to ‘charge’ it up.

Fluxx - Filling Hospitals with Heroes!

A Use Case

John is seven years old and in the hospital because he has mild cystic fibrosis and is seeking early treatment. He’s missing out on school and playing with his friends and is quite scared by the sterility and quiet of his ward.

Nurse Jackie gives John a Fluxx cuff on his first day, explaining it to be a cuff for his superpowers that he’s about to accumulate as he gets better.

Jackie logs into the checklist application on her iPad and sets up a profile for John and inputs his tasklist for the day: Meet Dr. Jackson, Take Meds, Blood draw.

John is afraid of needles but encouraged by the opportunity to gain more superpowers, he bravely gets his blood drawn. Nurse Jackie checks his tasks off on the app causing his Fluxx to power up accordingly.

John now has powers and finds Alec, two beds down, to play with him. He uses the buttons on Fluxx to create cool sound and light effects. After a while of playing, John runs low on power. Alec helps his new friend out by placing his Fluxx on John’s and ‘heals’ him, giving him more power.

John is now getting better as he tries to complete all his tasks and stay active. He also has made a friend in Nurse Jackie and Alec, and has taken charge of his illness.

The Product

Design Process 

The design road towards Fluxx started with a user centric approach. Following the  Design Thinking methodology, we initially intended to visit a Hospital and get ideas from children themselves. However, after a few failed phone calls and unanswered emails from doctors, we reached out to pediatric nurses for insights. This proved to be a great resource since the nurse would become one of the main interactive users of our device.

We spoke to two registered nurses. The first nurse works in the pediatric floor of a hospital in Florida. The second works in the emergency department of a children’s hospital in NJ. They both provided great insights about the inner workings of a children’s hospital as well as the interactions between patients. We gathered quotes and worked on drawing insights from them.

“Each pediatric floor has a play room and the hematology/oncology floor has a teen room as well. The kids are allowed to go in those rooms as long as they are not on isolation for something easily contracted. The teen room has computers, game systems, magazines...the play room has lots of toys. There are also portable game systems and DVD players/DVDs that can be signed out by the children if they are not allowed to leave their rooms. There's Child Life Specialists during the day who round and interact with the children, play with them, or help them cope during difficult or painful procedures. They also have a schedule of arts and crafts, story or song time, and different activities set up on specific floors or in the lobby for kids who can leave their rooms.” -Kelly, Pediatric Nurse

Based on insights from the nurses, we developed various design principles before combining some of the most powerful into one cohesive design principle that would guide our design through conception to prototype.

–Device [wearable] should empower kids via use of lights and sounds [game] as well as to provide connectivity to nurse–

Throughout the process, we learned the importance of focusing on the user. It was difficult to concentrate all our design strength into helping only some children in the hospital, since our hearts really wanted to help all of them. However, we realized that we would spread ourselves too thin if we tried to design for everyone, resulting in an uncompelling product. So we narrowed down to children who are able to walk around the pediatric floor. Based on the interviews we knew that children in the pediatric floor would be able to have access to a toy such as ours but this would not be suitable for the emergency room nor the Intensive care unit where children are also in need of special attention and empowerment.

“I worked at the intensive care unit once and kids there can't really move. At the emergency room, they are not allowed outside their room because they are there for a relatively short period of time as we try to assess what they have. A product for kids would be best suited in the pediatric floor where kids can move around. I remember this girl that would get chemotherapy and she would walk around the floor without a problem. Kids are allowed if they are not contagious. ” Virgen, Pediatric Nurse

We did however think as to how to include those children who cannot move from their beds, and the idea of allowing for a power up/healing concept came to our minds where children can aid other children and make each other feel better, at the very least psychologically. Armed with user information, a few brainstorming sessions saw various concept generations geared to fulfilling the design principle requirement. Superhero capes, belts, necklaces, bracelets... The idea of superhero powers quickly set in. Fluxx is the combination of many of these concepts into one cohesive product. 

THE BOX

For this project, our design team worked with the hardware team to push the constraints on various components. It was important to have a solid housing for the electronics that would then be embedded into a more flexible attachment interface, at least for the time being. Our main goal was compact size and optimal comfort for placement on the wrist. Despite the fact that we were using our own arms for testing interaction as we built the product, we wanted to make sure we were aiming towards our end users -- children. Therefore size was of the upmost importance. 

Our width constraint would be a few millimeters larger than the neopixel ring we use to indicate charging capacity (~50mm). With this square as our starting point, we extended the casing to allow us to fit the sparkCore, switches, and other components that would be added as the design developed. 

As we were working on hardware and casing simultaneously, modularity became key in the development of the box. When new  pieces of hardware with different size constraints were introduced, being able to swap out pieces quickly and efficiently was extremely helpful in understanding the final user interaction. It also allowed the team to consider new aspects of the interaction design as the project progressed and we learned the possibilities and constraints of the various hardware and software introduced. For example, varying the number and sizes of buttons opened up new opportunities for "powers" and nurse-patient as well as patient-patient interactions. 

Along with these goals, it was important to us that the product offer visual cues to the user. Although we anticipated the children getting a briefing on how it works when they are initially equipped, 

THE HARDWARE

Integration of hardware components

Building Fluxx was a challenge as it is meant to be a small device to be used by children on their forearms/wrists. We set out to create the smallest device we possibly could given our time as well as resource constraints. While procuring parts, the team gathered necessary dimension information from each component and we began to design an idea for an outer case assuming a maximum allowed space. This space in essence was the constraint for all of the electronic components, the backbone of Fluxx. Needless to say, it was very difficult to integrate all of the electronics in the casing. We knew they would fit, but we didn’t know how they would fall into place once soldered, because of the tight space. This took some finesse but we were ultimately able to put everything together into a small device, with a sleek look. Part of the reason we were able to accomplish this was because the maximum allowed space took into consideration a factor of safety to provide for unexpected space such as cables and solder. This proved invaluable.

Many iterations happened between the circuity and the outer case in order to make Fluxx a reality. The circuitry began in a larger form factor. Utilizing Arduino as a platform to create the first circuit including the Neopixel ring and the audio breakout module. Because we wanted the smallest form factor possible, we began looking for small microprocessor boards with Wifi and BlueTooth capabilities. We got our hands on an Intel Edison and a Spark Core board, both with such abilities in connectivity as the ones required for our purposes. We deviced to go with the Spark Core. from the prototyping board of an arduino and a breadboard. We began researching methods for minimizing the architecture. Making a customized PCB for our components looked promising, but we settled on a protoboard for our final iteration since fine detail could be achieved when on the right hands.

A challenge in designing and implementing the circuit in a small form factor was the power requirement of Fluxx. because the Spark Core provides an low 3.3 volts from its outputs, we worried that the needs of the Neopixel (5v) –combined with the audio module (3.3v) would end up proving too much for the Spark Core. This was a fresh problem since testing up to this point had been done on an SparkFun's Redboard and it itself outputs a constant 5v. While aware of the current and voltage requirements of the system, we were advised on utilizing a 6v input (eg. 4 AAA batteries in series) and using a Level Shifter to bring down the voltage at the correct location in the circuit . However, further research into datasheets and past works of other designers suggested that a 3.7v from a LiPo battery would suffice and that the problem would occur in the current supply to the Neopixel and not on its voltage end. To circumvent this issue, we tested to our satisfaction a 3.7v LiPo battery being supplied in parallel to the Spark Core and the Neopixel Ring with the Audio module and remaining LED receiving power from the microprocessor itself. While controlling the intensity of the Neopixels’ LEDs via code we were able to achieve a system that works from a small 3.7v LiPo Battery with 150mAh. enough for over 20 minutes of minimal use (press buttons and connect through WiFi). For realistic use, a larger battery with a capacity of > 1200mAh should be utilized as it provides around 6 hours of battery life during extended use. Our prototype has a special pouch holder under the acrylic casing. The smaller battery fits inside the actual casing, nudged between the speaker and the audio module. We though about leaving it there and adding a switch and a charging port. This meant that the device would need to be recharged as a whole and could not be used by kids during charging times. However, we felt it would be best if the nurse should only need to swap out one battery for another. This way the kid can feel a sense of ownership over the device by allowing possession of the device through the entire hospital stay.

The soldering on the protoboard sees connections on both the front and the back of the board in order to save space. and provide the least amount of wires. 3 buttons serve different purposes. 1 is meant to display power on Neopixel Ring. A second and third button provides play interactivity by means of sound effects (Zap, Tag) and flashing red LED at the front of the board, while the Neopixel loses power with increased use. The third button also serves the purpose of scalability. It is intended to provide communication between users –such as a walkie talkie device– as well as between the parents and the child wearing it. The team decided this would be achieved in future iterations. The third button allowes for the ability to code different scenarios for user testing. The button could provide sounds alone, Lights alone, communication, game connectivity with tablet, and many other user test scenarios. 

The magnetic switch –also know as a reed switch– was a great addition thanks to Chris Meyers, whom while bouncing ideas gave us insight into this component. The switch allows for a magical "power up" moment between devices as all it need is a magnet to be activated. 

As for Audio, we initially thought about utilizing an amplifier to increase the loudness factor, however in order to keep with our design objective of a small wearable, in a sleek form we decided to opt out from using it. Specially, after our initial test when it was evident that the audio could be clearly heard by the wearer. By adapting a small speaker on the center of the hardware casing. the cover of both the neopixel was designed to provide a form a natural amplifier as it would concentrate the audio inside it and the holes would allow for the audio to be directed in the direction of the wearer. 

Circuitry 

THE CODE

Getting the Software and Web App up to speed

Live Site: https://fluxx.herokuapp.com/

SparkCore code: https://github.com/JonSEng/fluxx_sparkcore

WebApp code: https://github.com/JonSEng/fluxx

Software-Hardware Integration

Part of the experience was to have a partnership opposed to an adversarial relationship between the nurses and the children. To aid the interaction, we decided that as the child completes his recovery tasks, the nurse checks him off and charges up his powers - represented by the circular lights. To accomplish this we connected our SparkCore to the audio card, speaker, Neopixel lights, and other LED lights and registered a cloud function that would handle a REST api call from the web application we built. When a nurse checks off a child for completing his vital sign check-up, the web app sends a signal to the SparkCore telling it how much to increment the child’s fluxx’s power, and the lights flash to increase accordingly.

The children used their power by pressing on the buttons which triggers lights and their power’s sound effect. As they continually press the button it cycles through various light colors and sound effects. This part was tricky to code on the SparkCore arduino because we realized that we had to put in a delay in order to correctly read a press and depress of a button. The optimal delay we found was 20ms. Also it was difficult to keep track and maintain a correct and consistent state representation of the fluxx - to know when it was time to charge, to use a power, when the wireless magnetic charging is happening, and when to handle the online REST call.

Web App and Integration

We designed and built a web application for the nurses to interact with the child’s Fluxxes and also keep track of their progress.

Nurses have a set of tasks that each child needs to complete in their recovery routine: 1) vital sign checks 2) IV drips 3) physical therapy 4) breakfast ...etc. The nurse web app has a tasks page for each child where the nurse can quickly tap off completed tasks which communicate over a REST api call to the Fluxx’s internal SparkCore and lights up a few more power lights. Secondly, it is able to keep track of the child’s progress on various tasks, namely a timeline of the number of tasks completed per day.

During our first iteration, the live demo site is on fluxx.herokuapp.com. The dashboard feature has not been completed and there is much to be polished but the tasks check off functionality is there.

We wanted to make onboarding as easy as possible so the webapp is computer and mobile friendly - and completing tasks require only a tap, simple enough on a phone they are likely to have with them. Also part of the design was to give much free room as to how the kids and nurses use the product we give them. For instance, they can choose to make a leaderboard with the timeline data, or not.

Extending the project into the future, I envision giving nurses a simple and perhaps automatic import of recurring tasks that are largely still paper based. For instance, the nurse might be able to just type it in once, and be able to import/export JSON task template files. And of course, in production it would have a complete backend database. To actually implement it in a hospital would require integration with their existing patient system and that is something we need to keep in mind. Perhaps then the web application would be tailored for each hospital needs and the particular characteristic children that are there (patient stay time, complexity of the task data...etc.).

Conclusion

Fluxx aims to create a support system in pediatric hospitals to make recovery less painful and a bit more fun for children.

While we integrated the core functionality of Fluxx (positive feedback for accomplishing tasks on the recovery checklist, power representation and light/sound interaction), much can be done with idea - tracking progress, encouraging group play (possibly unlocking stories with collaboration of multiple children), incorporating heart rate and other sensors to ensure children are safe when playing.

Future of Fluxx will see haptic feedback when using power as well as group interactions of Fluxxes. The integration of additional sensors into the cuff will augment Fluxx's capacity from a simple toy to a constant monitoring system. We are aware that  we might run into issues in hospitals that frown upon having sick children run about or with overprotective parents but this will should all be identified during the iteration process in user testing as we follow through with Design Thinking methodology.

 In a future iteration, we hope to get insight from both children and parents to influence the design. We’d also make the design sleeker and smaller to fit smaller wrists given a bigger budget and smaller circuitry. We see our current prototype as a step into an exciting possible future, rethinking how wearables could fit in a hospital setting and encourage trust and recovery.