Visualization studies

My project is all about configurability. The user should set up their Glance however he or she sees fit, based on the specific goal or affect they are looking for. (pun intended)

I wrote out a bunch of scenarios for different data sets, and the questions they could help a user answer quickly. I then asked several ITP students what type of graph they would use in each situation:

  • Distance Between Two Travelers (horizontal)
  • Traveler Count Up
  • Traveler Count Down
  • Traveler Round/Gauge
  • Horizontal Traveler


It was interesting that I didn’t get a unanimous result. For some, the “goal zone” meant “in the clear” but for others it meant “you’re in the danger zone get out!”

Example: Using the horizontal traveler for the balance of your bank account.

When the traveler is in the goal area you have enough money and are “in the clear”


When the traveler is in the goal area you’re overspending and need to spend less/make more money to get out of the “danger zone”

Either way, the same display works for both. These conversations helped me understand how important having a clear “finish line” is to this project. If the goal isn’t immediately clear visually, that the time to read the display increases as does the effort. I set out to explore ways to make the display read effortlessly:


After many tries, I’ve concluded that the display deserves to have one clearly marked goal zone with no gradient intermediate. It should read like a digital map program- Green Dot to start, Red Dot to finish — easily identifiable goal.



I also did a quick study of paint on wood after finding these wooden products for inspiration:

20140420-115611.jpg 20140420-121111.jpg


DropCam Setup


I borrowed an extra DropCam to add to my existing account. I was interested to see the setup experience in a system that includes multiple connected nodes, but does not require a hub to control them.

Not only is DropCam by far the most error-free setup process of all of the connected devices I have reviewed, adding an extra node was simply a pleasure. After plugging the cam into my computer, it is recognized as a flash drive containing the configuration software. With just a 3 step process (Log into my account, Choose my WiFi Network, Place the Camera in it’s location) the cam was ready to go. There were no connection hiccups with arbitrary pairing procedures.

This process is superior because:

  • With the DropCam physically plugged into the computer, it illiminates connection failures
  • With a serial number for each device, the system knows who owns it even if it goes offline
  • The app and the DropCam both communicate directly with the user account on the server, no failures because the camera did not connect to a hub or the app directly
  • If one camera goes offline, the whole fleet is not knocked out

Now, I’m seriously considering this type of configuration for my thesis project instead of a hub and nodes approach.


Jess and I created a fun New Jersey Party experience: A Fist Pumping Light Show using the RoboSmart connected lights. In this experience, a partygoer holds their phone in the hand they fist pump with, and the synced light will flash with their fist pumping action! We had originally talked about creating a way for rock show attendees to control the lights onstage, but we decided on a really fun “House Party” experience instead.

A big challenge was designing how the user would learn what to do. We considered using screens that the user swipes between or having a separate instructional section in the app. We decided to pair the whole process down to 3 steps: a connection animation, a simple instructional animation, and the fist pump action as the ‘go’ to start communicating with the light. This simplicity helped make it a smooth experience. Here’s what the app looked like: (White NJ = RoboSmart light ON; Blue NJ = RoboSmart light OFF)

First working prototype:

In-Class PARTY!