24. Decathlon User Stories

The Solar Decathlon is an almost bi-annual competition between universities to build energy efficient homes.

This year the University of Hawaii was selected as one of the 20 participants, and our software engineering class has been tasked with producing user interface designs for the project's many systems.

The initial planning approach we're taking to defining requirements is called user stories. Rather than pinning down requirements that may keep changing over time, user stories are for the most part self-defined. They're narratives from the user's perspective about what they want the system to do. Usually, these are short and brief and don't get into specifics, and this allows the software designer to focus on what the user wants rather than forcing the user to come up with concrete requirements. This allows the user to be flexible in changing their mind, and it also allows the software developer to take some liberties on how to implement things, then be able to come back to the user for feedback.

Here are a few user stories for the project's House Management System (HMS):

POWER CONSUMPTION

• User Story 1: An occupant can view the house's current power consumption in comparison to it's power production. This comparison will be able to be viewed graphically and numerically, and the user will be able to select different time frames (i.e., over the course of a week, month, or day). The system will also make it readily available and easily visible the delta between power consumption and production. This will allow the user to adjust the components in the house or their energy consumption habits in order to maximize their energy efficiency.
  
  
• User Story 2: The system will also allow the occupant to view all connected devices and show their power consumption in graphical and numerical form. When a particular device or outlet is being used, the user will be able to view how the device is impacting power consumption as a whole. Devices or outlets can be grouped by category or location/rooms to offer further insight into power consumption habits and areas where the most impact can be made via power conservation methods. This will help the user pinpoint areas of concern and increase the speed of feedback as to how effective conservation methods are proceeding.

ENTERTAINMENT

• User Story 3: The occupant will be able to access all entertainment options and offer a single control location for all entertainment devices. These include audio, gaming, and visual equipment. The system will also allow for the integration of multiple components, e.g., lighting response to audio system output or routing audio output from the gaming system to the surround sound system vs. headphones. Accessing different media will also be available, as multiple storage/output locations may exist (e.g., iTunes library, media server, Apple TV). The ability to view and operate all the systems in the house eliminates the need for multiple remotes as the occupant has the option of using either the display or their mobile device.

HVAC

• User Story 4: The occupant will be able to monitor the heating, ventilation, and air conditioning systems and make adjustments to each to balance energy efficiency and comfort. Temperature control and power consumption of the different HVAC systems will be available to allow occupants to make informed decisions. The HVAC system will consume a lot of energy, so it is of utmost importance to give detailed but relevant information about the HVAC system and its impact on the house's energy consumption. Temperature sensors in each room will display temperatures in each area of the house to further allow the occupant to effectively manage power usage.

LIGHTING

• User Story 5: The occupant will be able to monitor all lighting systems within the house as well as adjust the lighting or mode (all on, follow occupants/motion sensored, audio synchronization, etc.). Setting timers and lighting schedules will also be available through the interface. The user will also be able to see a power consumption impact of certain lighting configurations. This will allow the occupant to make decisions on brightness and choose between different settings and configurations to maximize energy efficiency.

AQUAPONICS

• User Story 6: The system will also allow the occupant to monitor the chemical levels in the aquaponic system. Due to the importance of keeping the balance maintained in the aquaponic area, alerts will also be issued via display screen and text message so that the necessary adjustments can be made. This will facilitate the quickest response to any situation where chemical levels within the aquaponic environment are within critical levels. The system will also allow for management of automated controls, such as water temperature, heating, light exposure, etc. if available.

SECURITY

• User Story 7: The status of the security system will be available for the occupant to view at any time. In the event of a breach, the security system software will send a text message to alert the occupant. The health of security sensors (disabled, online, offline, etc.) will also be displayed on a floorplan of the house. The occupant can also change the level of security/sensitivity and security response (alarm, police notification, laser beams) and response time. The security interface will also allow the user to configure the lighting system and how it responds to a security alert (red lighting, or lighting the area where the breach occurred). This allows the user to have full visibility of the security of their residence and also allow for faster and more appropriate response.
  
  
• User Story 8: Computer security status will also be available to be viewed. All computers and devices on the network will be listed with IP address and data flow. All open ports will also be listed with activity status on each port, as well as any applications that are transmitting or receiving data. The interface will also allow the user to change router settings as well. This will allow for tighter network security since all activity and settings are available in one place.

VOICE ACTIVATION

• User Story 9: The interface for the voice activation system will allow occupants to program commands as well as change settings (sensitivity of voice recognition, male/female voice on responses). Commands will be linked to the other automated systems within the house, such as HVAC, lighting, entertainment, etc. Monitoring of the many systems within the dwelling is also available by having status reports read back to the occupant over the house speaker system. This allows yet another interface to accessing the house's management system, the other interfaces being a display (touchscreen or mouse/keyboard controlled) and a mobile device (phone, tablet pc). This interface allows the occupant to access settings and monitor house systems instantly without having to have a device with them.

OTHER

• User Story 10: The user will be able to access the main monitoring systems of the house via normal stdin/stdout as well as via touchscreen devices such as a mobile phone or display screen. This will allow the user to navigate and view all the systems on one display and will also allow for control or viewing from remote locations as well as from within the house. Possible uses could include warming or cooling the house prior to the occupant's arrival, or arming or disarming the security system remotely. The multiple display formats and remote access allows for a big increase in flexibility as far as usability goes.
  
  
• User Story 11: All monitoring screens/systems will be integrated into a single application. The occupant will be able to seamlessly switch between the different house systems without having to open up different windows or software programs. This encourages wider monitoring of all systems, rather than heavy monitoring of a select number of systems, leading to better efficiency and planning. This also decreases the learning curve needed to use the system, as new occupants will be able to learn the system quickly.

23. Website Usability Review

As a website designer, it's very important for me to ensure that my webpages get the job done, both aesthetically as well as functionally.

Usability is paramount. Over anything else, you want the reader to come to your site, easily find what they're looking for and not get discouraged. You also want them to stay and listen to what you have to sell or say. The internet is a lot like the radio or TV. If the program you're watching or listening to is unclear or uninteresting or the music is bad, then usually you leave.

Good usability in website design means minimizing or eliminating turn-offs. The worst thing you want the user to feel is frustration. I think from all the readings I've done on effective web design and usability, the overarching theme seems to be a focus on simplicity and clarity. Usually a lot of thought and sometimes testing must be done in order to select what you want a user to get out of your site as well as how they should navigate through the site.

Some things that I thought were interesting:

don't use stock images. I've used stock images from dreamstime and iStock, and I've been very careful to select unique and interesting photos. I've also seen sites, however, that pick very generic stock photos, and it's obvious and easy to spot. It's really similar to looking at a sign for a store that's done in comic sans or picante (two easily recognizable fonts included with microsoft word). It screams of unoriginality and conveys to the viewer that there's nothing special here.

don't use anything that even resembles an ad. I didn't realize that even content that looks like an ad is ignored by website visitors. It makes a lot of sense, though; anything that looks like an ad probably is, and don't we all hate commercials?

Some good websites:

• National Institutes of Health - http://www.nih.gov/
  
  
• Suprisingly, this government organization has a very effective website. Clearly laid out with a clean, focused design, it adheres to normal website conventions, navigation bars at the left and top of the screen, and searches (e.g., job seach) that are easy to understand and filter. Search results area also displayed in a clear table format with important headers in bold. On first visit to the site, it's obvious where important information is and the site also offers a site map at the very bottom.

• Alex Dukal - http://circografico.com.ar/

• This site just blew me away. Does all it needs to do, shows the artist's work (he's an illustrator), and give you easy access to any pertinent information about him. Clear, beautiful, and a tremendously good job at showcasing his talents. All the elements, from the text font to the use of whitespace and composition of the site are all carefully selected to provide an aesthetically pleasing site as well as a website that is very easy for the user to navigate through. His portfolio also has enlarged portions of interesting parts of each work and intuitive next >> and previous navigation. A case where less is definitely more; the site really gets out of the way and gives a nice framework for the art to speak for itself.
  

Some bad ones:

• Cyber Rebate - http://www.cyberrebate.com/
  
  
• This website looks more like a template than an actual website. Filled with tons of stock photos and stock text, there's nothing that makes this website interesting. Even the name of the website is in regular text. This is usually the thing readers see first and it's important to catch their attention with it.
  

• Amby's Directory of Resources - http//:amby.com
  

• Cramped text, and no real sense of organization. And the design of the site is very plain with nothing that really grabs the attention of the reader. photos are inconsistent and appear to have been plucked from random places around the web. The lack of whitespace makes the site hard to read and disheveled.
  

21. RoboHosting

We started a new unit on project hosting and configuration management in class this week. While most of our assignments in previous classes have been individual, there have been a few instances where we've had to work on teams, and this has usually involved meeting at a person's house and sometimes even bringing over multiple desktop computers so that team members could switch off and work on the same files.

In my data networks class, we're actually just starting a project and I've set up a Google project hosting site for all of us to collaborate on. Although we'll still be meeting in-person to iron out things, the discussion board and Subversion repository should help us manage the configuration of the project.

• Here's a link to the ics451-p2p-oreos project

The only downside is that we'll be using C for the project so we'll be without the use of ant. So for now, we'll probably have to deal with just the capabilities of make.

We were asked to accomplish the following tasks, and I was able to complete all of them without difficulty.

1. Install an SVN client. Since I'm using a Mac, I chose SmartSVN. The interface is clean and easy to use, and I installed SmartSVN and checked out a project from Google's Subversion repository without any problems.
2. Checkout, modify, and commit an existing project at Google Projects. This also went along without a hitch. I actually submitted twice since I forgot to run verify for the first commit. I had included a tab, which caused Checkstyle to fail. I can definitely see the importance of running some sort of verification check prior to committing a change.
3. Create a new system hosted at Google Projects. This includes a Google Group discussion board, User and Developer Guides, as well as uploading all Ant and Source files for my Robocode robot.

• Here's a link to the ics451-kgl-leonganisa project I created for this assignment

Now that my code is out there in the public, there's even more pressure for me to improve the performance of my robot. It's a lot like art. You can doodle and keep all your horrible art away from the public eye, but once you put it up in a gallery for the world to see, the stakes go way way up.

Hopefully I'll have some time to tweak my code in the near future.

For now, I can definitely see the value of version and configuration management.

18. RoboTesting

In class we've entered the testing phase of our Robocode projects. This was quite a ramp up from the previous few class sessions, which were mostly focused on ensuring that Ant and Eclipse worked properly and were properly configured.

Download the Leonganisa Testing Project (Eclipse)

Tests Implemented through JUnit:

• Assurance01 - Can the robot beat Corners 90% of the time
• Assurance02 - Can the robot beat both VelociRobot and Crazy at least 40% of the time (in a 3-way battle with the robot coming in first)
• Behavioral01 - Does the radar stay locked on a stationary enemy robot at least 90% of the time using the current scanning algorithm
• Unit01 - Does the proportional firepower method calculate the correct values
• Unit02 - Does the hypotenuse calculation function used to get the length of the battlefield's diagonal calculate correctly?

A few observations:

• The Assurance tests by far were the easiest to create, since we were given a template/example. Unit tests also were fairly easy to implement as well. Since they involved simply plugging in relevant values that prove the calculations are done properly.
  
  
• Behavioral tests by far took the most amount of time. In our behavioral tests we were given a parent class called RobotTestBed, which incidentally was written by our professor (after tracking it down on the google code site). What makes the behavioral tests so difficult is the fact that 1) the saved snapshots of bullets and robots can be a tad unpredictable and 2) the snapshots only offer limited insight into certain variables and methods. For example, the onScannedEvent method in the Robot class allows one easy access to the bearing of a scanned enemy robot. The Robot snapshot, however, has no such helper method, so a bearing must be computed by hand using trigonometric functions.
  
  
• The test cases are somewhat limited. I think it tests two of the major aspects of my robot, but due to the cumbersome nature of testing a battle only simple tests were able to be implemented. E.g., the behavioral test was done with SittingDuck rather than a moving robot.
  
  
• After running JaCoCo, it found that my tests covered 100% of my robot code. I think this may have been a byproduct of running the battles (10 rounds each) through JUnit, which allowed all the code to run all the way through.
  
  
• As for redesigning my robot to ensure that testing is easier, modularizing calculation methods makes it infinitely easier to create tests for them. Also, coming up with the tests beforehand (as well as the requirements) and shaping the robot according to these guidelines would definitely have made things much easier.