Standing Meeting 5/6/14

Our standing meeting felt very good this week, mainly because we were able to accomplish many of our goals:

Update the user's light control page

Implement Schedule 

Add button to turn on/off all lights within a room

Well, maybe we didn't accomplish as many goals as we thought. But we made good progress towards each of them. Arik did successfully revise the interface for changing the state of lights, as you can see from his earlier blog post. Karl's work with implementing a schedule led to some revisions to the initial design. With Zach's assistance, the schedule was revised to contain a list of a new class called Rules so that multiple on and off times can be scheduled through the week. Our system can recognize whether or not a schedule should be on at a given time, but we haven't yet put in the functionality to have the houses (Raspberry Pis) recognize this change. We weren't able to put an interface in for turning on or off the lights in a room, but we did some work on the backend to possibly make this task easier in the future.

Moving forward we have several more goals.

Add button to turn on/off all lights within a room. - Arik

Make the stats tab a relevant tab, rather than just displaying dummy data. - Karl

Finish implementing the schedule, and put into effect Lester's success story. - Zach

Lester's user story: Lester is going on vacation to Kathmandu he is in a rush to get through the airport, but he wants to make sure that his house is set to run as he wants it while he is gone. He calls the company and tells a technician to set his house to run on a schedule, turning lights on and off every 5 minutes in order to make it seem like he is still in the house. The technician follows through with this and Lester's neighbors call his house several times because they are confused why the lights are turning on and off so often.

That's all we have for this week's standing meeting.

Upgrading the user experience - House List Page

So, our original method to control the lights on the webpage was a list of lights with a check box. Users could change lights by modifying check boxes and then clicking save. While this worked, we were getting a little frustrated with it and we figured that our users wouldn't like it either. From here, we started looking into other options.

The best approach we came up with is the standard on/off switch for each light. Each light will have an on and off button that the user can just click. once the button is clicked, the new state of the button will be automatically updated and the user does not need to push save. I figured we could do this through javascript. I ended up making my own on/off buttons from scratch and got the following:

Now, this worked pretty well but what if the user was mobile? It might be easy to accidentally click on when you meant to click off and that may lead to some frustrations. Karl also pointed out that it was a little hard to tell if the light was on or off. It depends on what the user is used to. So we needed a switch that users are used to. From this, I looked online for Bootstrap Switches and eventually came across some code to simulate the iOS switch buttons! I modified the code to implement these new buttons and got the following:

This was much easier to comprehend! Furthermore, this switch is a single button whereas the last design was two buttons. This means, the user can click on any point on this switch and the javascript function will simply toggle the state of the light and submit the changes all with a single click! The look of the button will then change to match the state of the light.

From here, there are still some changes I need to make. For one, we are still going to put in a switch to change all lights in a room. But for now, we have a good switch design to start with.

Let Me Just Write That Into My Schedule ... Not

I knew when I was assigned the task to develop a schedule for our project it wouldn't be easy. I just didn't have any idea how not easy it would be. I'll review a few of the decisions that we made regarding how schedules will be implemented in our project.

1. Lights, Rooms, and Houses will have schedules. This is opposed to a system where a schedule would be in charge of managing all of the parts of a house. If a schedule were to be in charge of managing the house, it would simplify things because all of the schedule information would be located in one place. On the other hand, Lights, Rooms, and Houses each having their own schedule feels like a better reflection of how the world works. I like to think that I have my own personal schedule that I choose to follow in going to classes and appointments, rather than my schedule ruling over me and dictating what I must do.

2. Triggered events are represented by a start time AND an end time. This decision was primarily made based upon how we plan to implement checking whether or not the light should be on a schedule. The plan is to examine the current time and the light's schedule, and if the current time indicates that the light is scheduled to be in a certain state, then the light will be switched to that state. Then if a user changes the state of the light from its scheduled state, a variable will be set indicating that the light is intended to be in the state that it is, rather than its scheduled state. Once the end time has been reached, this "override" switch can be reset to off so that the schedule will work as planned in the future.

In an ideal world, we would like the database to push information regarding whether the lights should be on or off to the client rather than having the client constantly fetch what state the lights are in on the database. For this reason, our decisions on how to implement the schedule may change in the future.