Productogyser

capture

Dikla Sinai, Finlay Braithwaite, Karo Castro-Wunsch
1

Productogyser is a chaos management system for shared workspaces. It polls users’ desire to focus and creates a generative artistic centrepiece that indicates the office’s combined desire for focus. The device is a small control box with a clean and minimal design. It allows the user to use the encoder to express their state of mind. Red light is an indication for your coworkers that you need to focus and preferred not to be disturbed. Green light is an indication that you are willing to socialize.

The Productogyser is a custom-made product, specially designed to answer the needs of Victory Social Club, an open-space shared workplace. Victory Social Club is a multi-disciplinary production and design collective based in Toronto, Canada. The people who are part of this group come from different backgrounds such as filmmakers, directors, designers, sound editors, picture editors, animators, and educators. They all share one open space which makes it challenging to maximize the productivity in such a busy environment.

dsc_0728

2

Design Kit

List of electronic components – Here

3

4

Process

Since our product is custom made for a specific client, it was necessary for us to listen to our clients and get their feedback in order to come up with the best solution for them. We thought that it would give us the best insights about the functionality, group dynamic, etc. During the whole process of designing and testing, we worked together with our clients to make sure we were synced regarding the expected outcome. It was fascinating to learn about the process of creating a real product, to serve other users. For some of us, it was the first interaction with such a process, and it was highly educative.

Day 1 – Interview

We got together with the people from the studio to hear from them about their work experience in an open space. We pitched our idea and asked them some questions to understand if there is a real need for our product and get their ideas, comment about it. After the interview, we set together to define our product, based on their feedback.

We come up with a list of requirements:

  • The product should be able for each user to indicate his/her abilities to focus or socialize.
  • The individual should be able to express their state of mind, in a comfortable and not embarrassing way.
  • The sign for the individual’s state of mind should be visible to others.
  • There should be a shared area where everyone can be aware of the overall state of mind.
  • Since they have many guests and clients in the studio, they don’t want to codes for ‘please be quiet’ and ‘let’s socialize’ to be very clear to someone on the outside. They don’t want to make them feel uncomfortable. The codes should be more of an abstract than a traffic light.
  • The design of the product should be minimalistic and suit the overall studio design.

Some other things people mentioned in the interview:

  • If they need quiet, they just put on their earphones.
  • They think that most of the people are just not aware of the fact they are causing so much noise.

Full interview link: Victory Social Club – Charette

6

7

Day 2 – Worked on our first version of product

Code Ideas

The individual stations hold and broadcast a value for the desire for focus of each individual. The value can be positive or negative, representing more or less desire for. The value for ‘focus desire’ is dialled in using a rotary encoder. The local focus desire is reflected in the red/green LEDs integrated in the rotary encoder, red signifying a desire for focus (negative value) and green signifying an openness to distraction. This gives the user live feedback that their input has been accepted by the system. It also allows visitors at close proximity to observe and respect the user’s desire for focus.

 

Either state, positive or negative depreciates over time, eventually landing and resting at 0. This is ‘dead man’s switch’, eventually negating the user’s output over time, so that if they leave their desk their influence over the global office state diminishes.

 

void Depreciation() {

if (millis() – DepreciationMarker >= DepreciationRate) {

if (dialValue < 0) {++dialValue;}

if (dialValue > 0) {–dialValue;}

DepreciationMarker = millis();}}

 

Each device publishes their local state to feed the central generative display. Each device publishes to its own PubNub Channel. The data published is the desire for focus ranging from -255 to 255.

Channel1: {“focusDesire”: -111}
Channel2: {“focusDesire”: +200}
Channel3: {“focusDesire”: -5}

 

The generative display aggregates the data from all user stations and uses it to build its display. The generative display is a javascript site translates the incoming data into an engaging yet informative peripheral notification. Low saturation red and green background inform the space of the overall desire for focus. The shape of the generative display is circular for each user until they dial in a desire for focus (negative value) wherein the shapes become more angular, representing the desire for focus. There can be multiple shapes both circular and angular that represent the mood of individuals in the studio. However, there can only be one background colour representing the cumulative mood of the entire studio.

This cumulative mood is returned via PubNub to Channel0. Each local station translates this global value to a Neopixle LED, turning red for negative values, green for positve. In this way, each user can know the state of the studio, irregardless of their ability to see the generative display.

8

9

User Station Code – Arduino

https://github.com/KaroAntonio/productogyser/blob/master/arduino/Productogyser.ino

Generative Display Code – Javascript

https://github.com/KaroAntonio/productogyser/blob/master/script.js

Diagram

10

Day 3 – Design, testing plan and code

  • We created a list of questions for the user testing process –  Here. The survey contains questions to provide feedback about our product. With our survey, we aim to understand if the product works as expected and how intuitive is the user experience, to understand the need of each feature, get feedback about the product design, measure the overall satisfaction level, and understand what needs to be improved.
  • We start discussing ideas for the physical design, keeping in mind our clients demands. We did some research online for fancy plastic boxes and we found some ideal soap containers at MUJI. We thought that since they are semi-transparent, they could be perfect for our needs since the neopixel lights are too bright and this will help dim their output a bit. We also tried to optimize the configuration of all parts on a breadboard to find out what is the minimum size required for the box.
  • We went shopping for boxes at MUJI.

11

The making of

We planned to create one fully functioning prototype, test it, and multiply the successful prototype two more times.

  • Each soap container includes two parts of foam to protect them from scratches. We decided to use the foams as part of our design for two reasons:
    1. Design element – They can defuse the light and makes it more interesting as it goes through the foam texture.
    2. Functionality – we can use it a substitute for our breadboard which helps to stabilize the parts and hold them inside the box.
  • We drilled two holes for the USB cable and the encoder.
  • We added encoder covers (same colour as the box) to make the encoders easier to see and turn.
  • Since the wiring required three GND pins, we had to connect four jumper wires – three that go to each pin in the encoder and neopixel and one that goes into the GND pin at the Feather.

12

Day 4 – testing the code

We were trying to test the code with the prototypes before the user testing, but we had to deal with some code issues first:

  • Communication with PubNub – we got ‘client error’ messages in two of our three Feathers.
  • We managed to get green light output but not red light output on the encoder LED.
  • Finlay was out of town 🙁 which makes the process and communication a bit harder *BUT* we managed to figure some of the issues over a group chat.

13

Day 5 – debugging

We needed to solve two main issues:

  • Showing red light for any values below zero.
  • Make the neopixel respond to our central art piece and shows the same output – the average value of the whole devices.

We did some testing, and figured out that two of the three devices were just not responding. This gave us an indication that there might be a problem with the Feathers. We started with checking the wires to make sure everything is wired correctly. Once we verified that the wiring is ok, we were quite clueless about might be the problem.

We then decided to test it on another wifi network to see if this might be the problems and we found out that they were all working fine. Apparently, two of our Feather was not registered on the OCADU wifi network. Our reaction to this discovery was a fine blend of elation, exaltation, frustration, and indignation.

14

Day 6- User testing

We set up 3 working stations at the studio and asked people to plug them to their computer for 3-5 hours, and at the end of each session, answer our online survey.

15

Conclusions

We had 7 people to test our product and share their feedback with us.

things-we-learned-about

References

  • Music by Mild High Club, used with permission
  • victorysocialclub.com

Leave a Reply