Solar Decathalon: User Stories

My ICS 413 course has been invited to participate in the Solar Decathalon (S.D.).  The S.D. is a prestigious event where universities from around the world compete to design an energy efficient, solar powered house.  The goal is to create a house that generates at least as much energy as it consumes.  Each year, twenty universities are chosen to build their home on the Washington D.C. mall.  Our class will be assisting team Hawaii in designing the home's software interface.

As the first step in the design process, two members of team Hawaii were invited to class for a Q & A session.  Then we were tasked with coming up with user stories.  User stories are short statements that describe user interaction with some aspect or functionality of a software system.  In this case, the goal of our user stories is to give team Hawaii some ideas about what would be possible to implement in their house with respect to software. 

User Stories:

As a home occupant, I would like to be able to program a weekly schedule for the air conditioning system. The schedule would allow me to set the goal temperature for the A.C. on an hourly basis. The schedule would be easy to configure, allowing me to view each day of the week by hour, but allowing me to break-up each hour into fifteen-minute intervals. I would be able to highlight time periods by clicking and dragging to the appropriate time, and setting a temperature for that time range. The system would give me a running-weekly-total of the amount of energy this schedule would use, so that I can choose where to cut back on using the A.C.

As a home occupant, I would be able to have the house keep track of the amount of food currently available via the Aquaponics system, as well what's in the refrigerator. I would be able to plan weekly meal-menus, where each meal would be a selection from the computer's recipe-database. A weekly calendar would be available for me to use in order to plan the number of people to be served, as well as each course. The computer would let me know what items I would need to pick-up from the store, or replenish, in order to complete my weekly-menu. I would be able to add new recipe to the system. The recipe system would be searchable by dish type (appetizer, entree, dessert, etc.), ingredients (pasta, pork, fish, etc), and recipe name.

As a programmer, I would be able to easily implement new functionality into the house. The system would keep track of currently available functionalities, and I would be able to enable/disable each system with a few clicks. I would also be able to run new, or questionable systems in a “debug” mode, where I can set a list of available systems that it can interact with. In this way, I could incrementally allow the new module to interact with other systems one at a time, until I am sure that it works as intended. The “debug” mode would also allow me to run a module in a text-based emulator that takes real time data from the house sensors.

As a home occupant, I would be able to monitor my current, daily, and weekly energy usage. My current power usage would be available via a widget on my computer and phone. Power usage would be displayed as a graph of usage over time for the daily and weekly reports. These graphs would also show me the amount of energy that has been generated so far this week, predict the amount of energy that will be collected throughout the week based on weather forecasts, and show me my remaining energy budget given my current energy consumption rate. Any surplus or defect of energy would be added to next week's budget. These graphs would be broken down by hour, allowing me to select any given time period and view what was using power during that time frame, how much it used, and how long it used it for. Graphs would be available via the house's local intranet, as well as an app on my smart phone.

As a home occupant, I be able to control some or all of my house's functionalities remotely via a small program that could be installed on any computer platform or phone. The program would require authentication via a user name, password, and approved MAC address. From the main home computer, I would be able to control the users and MAC addresses that can access the system. I would be able to give different permission levels to each user, so that my children would have less access than me. The application would give me the ability to inform the house of any changes to my schedule and adjust accordingly. It would also allow the home to track my location via my GPS enabled phone, and unlock

itself/disable the security system when I am within a few feet of it.

As a home occupant, I would be able to issue voice commands to the house to implement various functionalities. The house would execute my commands if it is confident in it's understanding, otherwise it would prompt me to either re-state the command, or ask for clarification. Voice commands would be substitutes for pressing buttons in the house's management system. For example, saying “Settings, Lights, Set to, Zero”, would cause the system to press the settings button, followed by the lights button, and then set the “Set to:” field to zero. This would make interacting with the house more accurate, as the system would only have to understand the spoken commands for a few dozen buttons.

As a home occupant, I would be able to control the lighting in my house in a variety of ways. I would be able to issue voice commands to the house to tell the house to only light the area where I currently am, or to light the entire house at a certain level. I would also be able to use the control panel, which would display the lights in the house as a grid, to select various areas of the house, and set their lighting levels individually. This could be useful if someone wanted to watch a movie in a darker section of the house, while another person wanted to do paperwork in a brightly lit area.

As a home occupant, I would be able to receive notifications about the status of certain events in the house. The house would be able to notify me that my laundry is done and needs to be hung up, or that the pie in the oven is done. The house would be aware of my current activity, sending me a visual or text-based message if I were on the phone, or playing an audio alert if I weren't busy. These alerts would remind me every minute until the situation was remedied. The house would be able to sense that the dryer/oven door was opened, and cease the alerts. These kinds of alerts would help prevent the need to re-dry clothes, and prevent the wasting of burnt foods.

As a home owner, the house would notify me if something needed maintenance or replacement. The house would keep a database of parts that it uses, as well as a list of certified repair centers. The house would be able to monitor important systems in the house and notify me which parts need to be swapped out before they fail. I would be notified in the same manner as other alerts, but the message would include the name, number, and approximate cost of having the maintenance done.

As a home occupant, I would be able to set limits on hot water use. Each user could be assigned a quantity of hot water to use for showering and doing laundry each week. Users would be able to check their hot water allowance in order to budget it. The shower in the house would be temperature adjustable via a waterproof touch screen display, so that users would be able to specify the temperature of the water that comes out of the shower head. The cooler the temperature, the longer users would be able to shower. The shower would also display a visualization of the time remaining for water at a given temperature. The shower would notify the user a minute and a half before their hot water allowance would expire.

Website Usability Review

My class has taken a break from the hard-nosed, numerical, inorganic blob that is software engineering, and focused on a much subtler topic: Website Utility. I say subtle, as various authorities each have their own view of what a well-designed website should be.  After pouring over dozens of "top-ten" lists, I have simplified them into a list of frequently occurring topics.

The Common Law of Web Design

• Important information is readily displayed.
• Make sure it's useful and pertinent
• Navigation is easy to use and understand.
• Don't do anything tricky.
• The page should be easy to read.
• Use less text.
• The use of white space should focus the user's attention.
• Avoid unnecessary noise (flash,animations,ads,music).
• Appease the user.
• Don't open links in a new window
• Don't use fixed text sizes

To simplify the above list,
Web pages should be targeted toward their audience and deliver information quickly and simply. 
Examples:

The Good:
http://www.pixelumbrella.com/
The online portfolio of Nick Robinson, a web designer and developer.  Because the products he develops are largely visual, pictures are better suited than words to show off his talent.  The page immediately points out two things, that Nick Designs things, and Makes Websites.  Navigation is inherently simple, click the picture, and you go to the page.  This is a very clean, elegant and effective website.

http://www.hawaii.edu/parking/
The University of Hawaii's parking website.  A dark green header tells users where they are, and ensures them that this is an official page.  A light green background offsets the navigation bar from the rest of the page, while bold text and simple rollover animations tell users that these are links.  Bright yellow icons and short announcements separated by white space draw the users attention from one item to the next.  This is another very clean, simple, and informative page.

The Bad:
http://art.yale.edu/
Yale University's School of Art website.  After landing on this page, users might wonder what just happened.  The lack of any sort of header makes a user wonder where they are, and what organisation this page is associated with.  The noisy background makes it very difficult to differentiate the actual page content.  Everything just blends together into a mish-mash of flowing orange lines and plain text.  It's difficult to tell, but the plain text that camouflages itself on the left is actually the navigation bar.  The rollover animation is the only indicator that this isn't just a bunch of text, or a part of the background.  If I were an unsuspecting visitor, I would leave the page immediately.

http://www.usabilitynet.org/home.htm
Supposedly a site sponsored by the European Union to promote "usability and user-centered design."  This page definitely isn't user friendly.  Curiously, this page has a normal navigation bar, but then chooses to expand all of it's navigation tabs, enumerating every possible link on one page.  Users don't like having to hunt and search for the link they want.  Topics should be logically arranged, so that the list of available choices the user has at any given time is very short.  The European Union might want to re-think this page.

Robocode Project Hosting with Google Project

The assignment this week was to create a centralized location where our open source projects can be accessed by the world.  Utilizing Google Project and Subversion (svn), I created a site for Failbot.  The assignment involved using Subversion for versioning and uploading/downloading to/from the project site.  Subversion is a neat little program that melds itself into Windows explorer, adding a few entries to the right click menu.  Interestingly enough, subversion can be invoked on a folder by folder basis.  This means that subversion can be implemented only where you want it.  The program is fairly light weight, but provides a lot of functionality.  It's definitely one of the tools I'll be using in the future.  It's nice to no longer have to "File ->Save As... " every time I want to make a backup of my working files. 

I finished creating both my project site and discussion group, and added my partner to both.  I also generated a Developer Guide and User Guide based on Prof. Johnson's examples.  I found the markup language that Google uses for it's wiki pages has a quick learning curve, and provides all of the basic functionality needed.  However, that isn't to say that I enjoyed using it.  I must have previewed each wikipage half a dozen times before I finally got the pair right.  This assignment was perhaps the simplest so far, but there was a lot of new stuff that was floated my way.  I've known about all of the Google features that were implemented in this project, but I had never had a reason to utilize them until now.  It's like visiting the tourist traps in your home town, you never actually go until someone from out of town makes you. 

JUnit & Jacoco Testing of Failbot.java

Link to Source
So this week's assignment was to create six test cases for our Robocode robots using JUnit.  I'm sad to say that Failbot was the first to be culled from the competition, as it was paired up against a non-wall-hugging robot.  On the bright side, it did win a Free-For-All match against everyone in the class, and managed to take down one of the toughest competitors in the class in a last-minute duel, which ranked it 8th out of 25.  But enough of my robotic exploits...

My six cases consisted of:

• Often beating SpinBot (>50%) (acceptance test)
• Consistently beating SittingDuck(acceptance test)
• Unit test of the toTurn() method
• Unit test of the getPow() method
• Behavioral test to ensure the bot hugs the walls
• Behavioral test to ensure the bot goes for the top left corner at the beginning of the turn.

The first two tests were dead give aways, as they were simple to implement.  The first behavioral test was also a give away, as it was provided as an example.  The other three tests (the two unit tests, and the "top-left" test) were a bit harder to come up with and required me to re-design Failbot's code to make it easier to test.  It was somewhat difficult to figure out what parts of the code should be tested, and what algorithms could be made into stand-alone methods for testing.  Honestly, Failbot is quite simple, and coming up with 6 different tests was a real stretch. 

We were given a Robocode control class wrapper, which I found somewhat useful, but not powerful enough to get the data I needed.  The wrapper allowed for "snapshots" to be taken during specific (read: asynchronous) times in the battle where certain parts of the bot's code could be accessed.  Robocode really doesn't provide a nice, easy way to get at the bots while they're in the arena.  I wanted to override some of Failbots methods, and inject accessors in order to get at the robot's variables while it was in action.  Unfortunately, it was impossible, so I created some fake events and called the bot's methods with the aforementioned events.  It seemed completely inefficient to have to break out such small parts of the bot's algorithms into stand-alone methods simply to test them.  But I suppose that those were areas where bugs could potentially go unnoticed by larger-scale debugging attempts.  Breaking out these little snippets of code can be compared to disassembling the lunar lander...It's painful.

While creating the tests was a ton of work, in the end, I feel like Failbot got a thorough diagnostic check up on it's algorithms (I even found a bug in Robocode!)*.  Jacoco says that the test suite gave 100% coverage of Failbot, but in reality, there was a fair bit of code (~15-20%) that wasn't specifically addressed.  I do however feel that all of Failbot's core functionality, as well as it's more complicated features were well addressed and inspected. 

After having to run such thorough tests on my bot, I now have a fairly good idea of how a program should be written in order to make testing much simpler.  Some general guidelines for testing:

1. If something can be broken into two simpler methods, do it.  Each method should do one simple task.
2. If a block of code seems murky or suspicious, break it up and run tests on each component.
3. Try to avoid creating two similar but slightly different methods, you'll have to run the same test twice.
4. Choose good test cases.  Use equivalence classes and test boundary conditions.
5. Junit is your friend. 
6. Jacoco is like a fortune cookie, it doesn't do anything very meaningful, but every so often, it'll tell you something insightful.

Basically its like data normalization: break up all of the chunks.