Pages

Thursday, October 28, 2010

Decathlon User Stories

Overview

The Solar Decathlon is a competition in which 20 teams consisting of college level students build a home that is powered by only solar energy. The winning house's design should blend affordability, consumer appeal, and design while maintaing optimal energy production and maximum efficiency.

Hawaii's Solar Decathlon team, or Team Hawaii, consists of a wide range of students, from electrical engineers to architects, but the one thing the team is currently lacking is computer science students. The goal of this current project is to have students from our software engineering class hopefully help and maybe eventually join Team Hawaii in the Solar Decathlon competition by designing a mock up user interface for the home management system of the house. This system will control and monitor multiple features of the house such as lighting, H.V.A.C., power statistics, and entertainment.

Before we can get into the design of the home management system, we have to look at what requirements that users of the house would like. To do this we're assigned the task of creating ten user stories that will describe interactions with users and the system, and it will explain the goals and benefits of the interaction. In short, wikipedia says that a user story "...is one or more sentences in the everyday or business language of the user that captures what the user wants to achieve."

User Stories

    Power
  • As a user of the system, I would like to be able to monitor the distribution of the energy consumption. For example I would like to see how the energy is being dispersed to the different functions of the house, such as lighting, entertainment, H.V.A.C., or the AquaPonics system. When one system (e.g. The H.V.A.C. system) of the house is consuming too much energy the home owner should be notified via an alert. As a result of being able to view these statistics and monitor the behavior of the power usage the user would be able to see which areas that they need to cut back in, whether it be not running the lights as often or turning down the air conditioner.
  • I would like to be able to see how much energy, on average, the house produces per day. This would allow me to predict the power production over next few days. Because I can predict the amount of energy that my house should produce on a certain day, I can set a target power usage goal for that day. This will allow inhabitants of the house to not go over their power budget.

  • Lighting
  • I would like to be able to control the brightness of the lights in the home as well as the hue, through the home management system. Brightness level is a bit of a necessity, as sometimes you need to work in a bright surrounding, while other times you need to work in low light settings. Being able to control the color of the lights is also important; say I wake up in the middle of the night and don't want to be blinded by white light, instead we could use amber. By being able to simply control the lighting, the user has full control of their working environment, as a result this could increase productivity.
  • I would like the ability to lock the lights over wherever I currently am in the house. This would allow the user to sit at a desk and lock the lights directly above the desk, turning off the lights everywhere else. One advantage of being able to localize the light, is that it would save energy. Instead of having all the lights on we can just have light where we need it.

  • H.V.A.C.
  • I would like to be able to set the max and minimum temperature that the house is allowed to reach. This would prevent the house from ever being too cold or too hot. For example if it is hot, but we want to conserver energy, we could set the max temperature to something moderately high like eighty-five degrees. This would allow the house to not turn on the air conditioner until it reaches the max temperature set by the user, as a result we conserve energy.
  • I would like to know how much power is allotted to the H.V.A.C. system. I would like the interface to show me how long I can run the air/heat for before having to turn it off and recharge the system. This will allow me to efficiently manage my use of the H.V.A.C. system. This too, will also help in conserving energy.

  • AquaPonics
  • As an occupant, I would like the ability to monitor the AquaPonics system. Because this system is tied into the ecosystem of the home, being able to monitor it and make sure everything is running correctly is extremely important. I would like the home management system to allow me to monitor the pH levels of the water. If the pH level is off significantly, the system should alert the occupant and provide a number of a technician to call for assistance.

  • Entertainment
  • I would like the ability to voice activate and control the television using the home management system. Alternatively the user should be able to control the television when using the home management system application on their smartphone. This would allow the user to control all aspects of the television entertainment system, such as controlling the volume of the sound system associated with the television. This allows ease of use, and it is very convenient for the user.
  • The ability to control music using voice activation would also be important. While not a necessity, it would appeal to the average user of the home. Voice control would allow the user to select music by just saying the name of the song. Likewise, with the television, the music should be controllable via smartphone too.

  • General
  • The main interface of the Home Management System should be integrated into a touch screen slate like device, such as the iPad, located within the home. It should allow the user to control all of the previously mentioned aspects. As well as being integrated into the slate device, the Home Management System should be portable to the web and smartphone devices. This will allow the user ease of control of the home wherever they may be.

Tuesday, October 26, 2010

Website Usability

Overview

Usability, in terms of web design, is the ease of use of the website for a user. If a website has poor usability, people will leave your website. In order to have a successful website with good usability you must follow a few simple rules.
  • Appease the user: A user shouldn't have to think to use the website. Everything about the site should be straight forward, from the content to the user interface.
  • Keep it simple: Don't over-complicate the user interface or design of your website. If the user interface isn't simple the users will be confused and leave. If the design of your website is messy/cluttered people will leave.
  • Be straight forward: Don't beat around the bush when trying to convey a message on your site. Be straight forward and say what you trying to say as simply as possible.
  • Follow conventions: It is important to follow conventions when designing your website (e.g. putting the "sign in" link on the upper right side of a webpage) as it will greatly decrease the learning curve for your website. If you do everything against the normal conventions of making a webpage, users will have a hard time learning how to navigating/use your website.
  • Test your website: It is important that you make your website adjust to the user and not the user adjust to your website. A user shouldn't have to download a specific browser to view your website, you website should work with multiple browsers. It is also important that before you release your site, you test the usability of it by observing a few people actually using your website.

Examples of Good Usability

1. Imgur: A simple image sharer


This is an example of good usability because it gets right to the point. Everything a user needs the site for is on the front page. The purpose of the site is to host images, so the site gives the option to simply upload an image from your computer or from another site all on the front page. This is a user interface in the simplest form, if one requires more options they can optionally create an account to gain access to those features.

2. Dropbox: Online file storage


Dropbox is a also another example of a site with a really simplistic user interface on the main page. When you first come to the site you are presented with a video that explains what Dropbox is, then right below is a link to download it. Those two things are what users come to the site looking for: what the tool does and where to get it. As a result of the video and download link being very large and hard to miss, the users don't have to think twice about how to use the site. It also uses standard conventions of putting the login information in the top right corner of the website.

Examples of Bad Usability

1. Havenworks: A political news site


This website obviously has bad usability in the sense that it is completely cluttered. The navigations isn't straight forward or standard at all; there are many sub-links in content of site, for example. Also there are walls of text with no bold keywords which makes it very difficult to skim over the content. If the design doesn't turn users away, the usability definitely will.

2. Jones Chijoff: Designer


This is a fine example of a site that has an appealing design but a poor user interface. The user interface that this person uses is completely nonstandard and will most likely be confusing to the average visitor; the user will have to learn how to use it. The way that the website presents itself leaves visitors wondering what services this person offers, or even what the point of the website is.

Tuesday, October 12, 2010

RoboHosting

Overview

For this assignment we were asked to create a google project hosting page for our existing robocode project, in my case robocode-ajk-wallspin. We were assigned to set up the google hosting page to allow use of subversion for content management updates and also to create wiki guides for developers and users of the project. Along with a google project hosting page, we had to set up a google groups page for the discussion of our project. Overall I would say this was a great learning experience and will help me in the future if I am ever part of a large (or small) development group. I was able to complete all of these task successfully, with little difficulty, after a little trial and error. The most difficult part of this task was setting up the wiki pages for the project and learning about the wiki syntax; other than that it was a pretty straight forward task.

Lessons Learned

Like mentioned above, I mostly learned about using subversion and google project hosting to allow content management for developing projects. I definitely think this will be a useful tool for future projects, and in fact I have already set up a google project hosting page for a project I have in my ICS 451 (Data Networks) class. I will be working on a peer to peer program for this class; I will be working with two other students so using subversion and google project hosting will greatly improve our workflow since we will be working on multiple copies of the same code. I'm hoping to learn a lot more during the course of this project, as we will most likely be using it more in depth.

Useful Links

Deliverables

Thursday, October 7, 2010

RoboTesting

Overview
This was my first experience with writing JUnit tests so it was a fun learning experience, but also a difficult one. We were assigned to write six tests for our existing robocode project: two acceptance tests and four behavioral or unit tests. For my project I wrote two acceptances tests which tested my robots WallSpin's ability to beat two other robots; in my case the SittingDuck and RamFire Robots. I wrote three behavioral tests which tested that WallSpin visited each corner of the arena, visited the center of the arena, and spent at least fifty percent of its time in wall mode when facing the Crazy robot. The last test I did was a unit test, which tested that WallSpin's firePower method returned a bullet fire power relative to the enemies distance.

Tests
  • TestWallSpinVersusSittingDuck
    Type: Acceptance Test
    Overview: This tests that WallSpin can successfully beat SittingDuck.
    Difficulty: This test was rather easy to create as it was based off of the example test provided for this assignment.
    Test Quality: I feel that this test in particular, because it is only facing SittingDuck, does not really ensure the quality of my robot. All this test really does is make sure that my robot knows how to target and fire at a stationary robot.
  • TestWallSpinVersusRamFire
    Type: Acceptance Test
    Overview: This tests that WallSpin can successfully beat RamFire.
    Difficulty: Again, this test was also pretty easy to create; it was just a matter of changing the robot that WallSpin should face, from SittingDuck to RamFire, from the previous test case.
    Test Quality: This test does ensure the quality of WallSpin, in the sense that it guarantees that WallSpin can beat another simple robot which can track and attack. It is important that WallSpin can beat certain robots, like RamFire, a hundred percent of the time.
  • TestWallSpinMovement
    Type: Behavioral Test
    Overview: This tests that WallSpin visits each corner of the arena.
    Difficulty: Like the first test mentioned, this was easy to write as I just used the example class file provided for this assignment. It just so happened that my Robot used wall movements, so it should be guaranteed to visit each corner of the arena.
    Test Quality: I would say that this is a valid and important test because it makes sure that my robot is behaving the way it should. This test reassures that WallSpin will visit each corner of the arena when facing SittingDuck.
  • TestWallSpinCenterMovement
    Type: Behavioral Test
    Overview: This tests that WallSpin can will move to the center of the arena when hit by a bullet.
    Difficulty: This was a bit more difficult of a test to write, because I had to calculate the center of the arena and take into account the size of the robot. I basically had to test if the robot was within fifty units of the center in either the x and y coordinates.
    Test Quality: This test does ensure the quality of WallSpin because it makes sure it is behaving the way it is supposed to: moving to the center of the arena when hit by a bullet. To guarantee that WallSpin is hit by a bullet, I make it fight the WallsRobot. If WallSpin were to not move to the center of the arena during its battle with Walls, it would mean that there is a flaw in WallSpin's code.
  • TestWallSpinPercentageMovement
    Type: Behavioral Test
    Overview: This tests to see that WallSpin spends at least fifty percent of its time along the walls when facing the Crazy robot.
    Difficulty: This test was a bit difficult to write as I had to calculate the range of where the walls lie in the coordinate system, then check during each turn if WallSpin was within those coordinates. At the end of the rounds I divide the number of times WallSpin was along the walls by the number of turns that WallSpin took, this provides me with the percentage of time WallSpin was riding along the walls. Thinking of how to conceptually write the test was more difficult than actually writing it.
    Test Quality: I would say this is an important test of WallSpin's behavior, because depending on the robot it faces, it should spend roughly fifty percent of its time in wall mode. If it's not then something is wrong with its code, or the robot it is facing has trapped it in a corner.
  • TestWallSpinFirePower
    Type: Unit Test
    Overview: This tests to see if WallSpin's firePower method returns a firepower relative to the distance of the enemy.
    Difficulty: This test was pretty difficult to write, because I had to modify the source code of WallSpin to allow this unit test. I had to make the firePower method take the maxDistance of the arena and the enemy's position as parameters to be able to unit test the method. In the unit test I set the maxDistance as five hundred and give firePower varying positions for the enemy's distance.
    Test Quality: This test is probably one of the most valid and important tests, as it makes sure that WallSpin is firing bullets proportional to the enemies distance. If this test fails this means that WallSpin's code is flawed and that WallSpin is most likely either wasting too much energy or using too little energy.

Jacoco
Running Jacoco showed that my WallSpin class had a total of seventy-two percent coverage. Basically it showed me what I already suspected, that some of the code in methods like moveToCenter are not guaranteed to be reached all the time. In WallSpin's moveToCenter method there are some cases I check for that will rarely be reached, such as the special case where the robot is already in the center when moveToCenter is called. Even though it showed me things that I already knew, the Jacoco output was very interesting to look at. I've never seen a tool that showed the coverage of the code, and I definitely believe that this can be a useful tool for detecting errors in my future projects.

How could I redesign WallSpin to make it easier to test?
If I were to rewrite WallSpin I would definitely separate its methods more effectively and make them have return values as opposed to being void. This would make it much easier to write unit tests for WallSpin. I actually had to modify WallSpin's source code in order to write the firePower unit test. I would also give the robot more defined movement patterns, as it would be much easier to create behavioral tests for. With the existing source code I had, it was very difficult for me to come up with my behavioral and unit tests.

Download
To download my WallSpin robot distribution click here.