LOCATION AMBIENT DISPLAY

This project started as something for Seattle Children’s, but grew into something more so that it could address the issues of climate change. It was originally a low impact idea that was meant for team management in a healthcare setting. By having having nurses or other employees self-report their location from time to time, it would be easier to find them in the maze that is the hospital. While useful, the project became more meaningful when we asked ourselves what other solutions our platform could host. Keeping climate change in mind, we thought to address the commute problem that Seattle Children’s was trying to tackle. Despite initiatives geared towards reducing their carbon footprint, Seattle Children’s still had many people commuting in their personal vehicles. This was because the shuttles provided by Children’s were inconsistent. Seeing that as another problem that could be solved by our display, it became one of our focuses for design. This left us with two main objectives to complete in this project. The first was creating a display that would represent where people were within the hospital. The second was collecting transit data to make the shuttle time schedules more consistent. Both address climate change, even if our first objective assumes climate change isn’t stopped. All that left was creating an ambient display that was easy to understand.

​

That took some doing. Not because displaying the information was hard, but because there was a lot of work that needed to be done behind the scenes. That being said, our project managed to complete our objectives almost to the letter. When it came to displaying location of people, we created a robust system that allowed location input both physically and over the internet. This hybrid approach allows for easy information sharing across multiple enclosures, with a minimum of calls. There was a lot of work on making a streamlined enclosure to house all of it, but ultimately it was relatively simple. Unfortunately, the same cannot be said about the transit data. The first problem was that real time data of the shuttles was not available to the public. Even APIs that had them recorded did not have any data besides where they stopped. Due to this, we had to shift to showing real time data for public transit between the hospital owned buildings. Although it is less convenient than the shuttles, by keeping tabs on the real time data we were able to make public transport a more consistent option. It took three different APIs and various data reading methods, but finally we were able to parse it to the point where we could display the data. With both of our objectives completed to the best of our ability, we were able to create something that could fit in on any workstation or computer on wheels at the hospital.