Design

Above you will find the final implementation of the Beaver Buzz user interface. There are several types of pages that needed to be implemented. The following is a description of each page and the design decisions we had taken to create the page.

• Home Page:The home page is the most important part of the application as it allows users to navigate the different discussions. There are login and register buttons which link to the appropriate pages. Tabs are used to resort the articles based off rating, time created, or whether the post was created by the currently-logged user. The "add post" button was made large. In the paper prototype we had placed it at the bottom, but we got feedback that it was not very visible. As a result, we decided to make it large and at the top. There are several topics under which posts may be placed. We did not think it was necessary to alphabetize them given that there were not many topics. If the application were to add many topics, though, it would be good to either alphabetize them or sort them by popularity (or allow the option for both). Seeing as how it was not necessary for our purposes, we decided to sort them by what we thought would be the most popular topics. Topics cannot be created by the user. This would be done for practical purposes for managing the database of the application. The topics list the articles, which may be scrolled horizontally. We made the scrollbars persistently visible after getting feedback in the heuristic evaluation that there was no affordance for scrolling.
• Login Page: The login page is simple, and takes in a username and a password. Since there is no database the page takes in any combination of username/password. It returns the user to the main page. In addition, it is possible to go to the register page, in case the user made a mistake. The login page also checks for empty inputs and informs the user that a username and password must be entered. The enter key has been overrided so that it goes to the next item in the form.
• Register: The register page takes in a username, a password, and an email. Like in the login page, it checks for empty fields. In addition, it checks that the email given is an MIT email, as this application can only be used my members of the MIT community. The enter key has been overrided here as well.
• Create Post Page: This page is used to add additional discussions in the main page. The user must input a title, category, and a description. The user may also optionally insert an article link, which is displayed in the post page. In the paper prototype, we had envisioned creating a third type of post: events. However, the feedback we got made us feel that adding an event class would be too confusing, as the users did not find much difference between linking to an event page and just displaying a time and date. As a result, we got rid of events all together. The post is added under whichever category it is marked.
• Post Page: This page allows users to discuss the subject of the post, and allows them to rate it. We decided to make the ratings bar large as we got feedback that it was difficult to use the touchscreen with it. Comments may be typed in at the bottom of the page and submitted. Comments are displayed in order of most recent, which allows users to quickly find whatever comments they last saw. Users may delete their own comments, and if they created the post they are able to delete it as well.

Implementation

From the onset we wished to focus on the user interface without getting bogged down by the back end. As a result, we decided to make all data non-persistent. This means that once the application closes, it goes back to how we had set it up in the beginning of the session. We used java HashMap to store all the categories, and a Java ArrayList to store the post objects of each category. This was extremely useful in giving us an easy way to store the data, without needing to update databases and worrying about synchronization issues from multiple users. The data storage was definitely sufficient for updating the user interface.In particular, we made the dictionary global, and a such all threads of an application could access them. Since we assumed only one user, we did not have to worry about threading issues such as deadlock.

Because we were creating an Android application, we needed to conform to the Android API. Each page is its own separate activity (the Android equivalent of a thread), and results of child activities are transferred to the parent activities. Working within the Android framework was definitely challenging, and much of our time was spent on learning how the API worked. Unfortunately, the strict separation of activities made our job quite challenging, as sometimes we found that we needed to communicate between two activities that were children of different activities. We only found that android Adapter class very late into the project, and by that point it would have required extensive redesign. As a result, we restart every activity when it is focused on the screen. The activity itself will use the dictionary to reconstruct its state. For future work, we would implement an adapter to communicate changes in one activity to another. For our purposes, though, resetting the activity works well, and it does not hinder the functionality of the user interface.

Evaluation

Our User Interface is directed to students of the MIT community. We want Beaver Buzz to be a safe environment for students to share and express how they feel about different topics. Thus, we chose our test subjects to be MIT students. We chose them randomly and did not look at their major since we would want any MIT student to use our product. The users were not given any sort of background information about Beaver Buzz or any information whatsoever on what it does. These were our test subjects:

1. 22-year old male, MIT student course 20.

This user thought the user interface was pretty simple overall.  He said that it would have been interesting to see the test posts with actual comments and discussions.  This would give a better feel for how the user would browse and interact with the application.  He also mentioned that subcategories or more specific categories of discussions or articles would be nice.  We had decided to get rid of user defined categories to make the UI simpler, but for a live application we could have compensated by adding more categories to separate discussions and articles, possibly with functionality to sort or display categories of interest.

2. 23-year old female, HST student.

This user found the UI easy to learn and easy to use.  She said that she liked that she could browse a large number of articles at once.  She wanted more content for each discussion topic, and it was unclear whether or not article links were actually links in test articles.  We actually did implement links, but forgot to return and add this functionality to the test articles with which we populated the application.  Otherwise, she thought the user interface was good.

3. 21-year old male, MIT student course 6.

This user was less familiar with Android.  He did not know that the back button could cancel the registration screen, and there was no button for it on the touch screen.  We could add a button on the registration and login screens for users who are not familiar with android physical buttons to lessen the learning curve.  Overall this user, thought the user interface was simple and effective.  He mentioned liking the layout for our main page and the scrolling panels.  At one point, this user stated, "This is actually a pretty cool UI." 

All users either registered or logged in, browsed a few articles, and posted their own articles.

Tasks

These are the tasks the test subjects were asked to perform. They were given no background information on the software or what it was for. We decided to give them a couple of tasks (very similar to the ones done in GR4):

• Task 1 - Create Account
  •  You are new to Beaver Buzz, thus the first logical step is to create an account!
• Task 2 - Go into Post, rate it and comment on it.
  •  After hours in the library finishing your last PSETs of the semester, you decide to log into your Beaver Buzz to check the latest news. You find an interesting post, so you visit it, rate it and comment on it!
• Task 3 - Go back to the home screen.
  • You can't have enough of Beaver Buzz and want to go back to the home screen to check out more posts!
• Task 4 - Delete Post.
  • Your MIT girlfriend is embarrassed of your last post! Remove it before our get dumped...
• Task 5 - Logout.
  • Back to reality. Finals are around the corner so you must log off and o back to work.

Usability Observations: Problems and Resolutions

• Task 1 - Create Account
  •  No problems. All users found the creating an account process easy to follow and similar to other interfaces they had used in the past.
• Task 2 - Go into Post, rate it and comment on it.
  •  No problems. At first test subject #1 did not know that you could scroll down using his thumb. After a few seconds he figured it our and was able to explore the whole screen. The other users did not encounter any problems.
• Task 3 - Go back to the home screen.
  • User #3 did not click on the "back to home" button since it was only the picture of a beaver. It looked cool, but it had no meaning to the user.  The other two users liked the design and did click on it. Still, it would be appropriate to change the image to something more familiar. We should change that picture to an arrow, much like the one in the common internet browsers.
• Task 4 - Delete Post.
  • No problems. All users thought it was simple and clear.
• Task 5 - Logout.
  • No problems. All of the users logged out successfully.
• Others:
  • Test subject #2 thinks that the colors used in the UI can be more vivid and interesting.
  • Test subject #3 thought that the UI could use more images. He thinks that it can be better looking.
  • None of the test subjects thought there were any usability issues and found that the UI did not require previous experience at blogs or anything. They thought it was simple and straight forward.

Reflection

The iterative design process greatly aided us in conceiving this user interface. Our original designs that we came up with before paper prototyping were very different from our final product, and at each level we found new features that needed to be added and redundant or confusing features that needed to be removed. In particular, many of the features that we found would be "cool" turned out to be unnecessary or would bewilder the user. Keeping it simple was always better. Finally, because we ended up doing an Android application, some of the features we had made during the paper prototype were not very feasible. When designing a layout, it is important to know what kind of technologies you will be using, even though they should not hinder the creative process.

There are things we should have done differently, however. In paper prototyping, we decided to focus on testing one type of design, as we thought we would not have enough time to go through and test all our other ideas that we had made during the initial design stages. We wanted to use one layout, and get as many kinks worked out in the paper prototyping stage as possible. That may have been a mistake, however, as we were not able to get user feedback for different types of designs so we could not rate which general layout to go with. If we were to start this process over, we would probably have made our paper prototype testing on several types of designs. This would have allowed us to choose the layout users were most comfortable with. 

We are also not sure if we would make an Android application if we were to restart the process. Learning the technologies definitely took a lot of time, and though we were able to make it work and have our interface be usable it may have been more useful to use javascript, which we had been practicing all semester.

None of us are particularly artistic, so we did not focus greatly on the visual appeal. While it is not extremely important for this class, it is important for first-impression purposes. Also, since we were using Android, our visual appeal tools was limited. If we started designing this interface again, we probably would try to integrate color-use and images earlier on so that we could fully use the technologies to make our interface more inviting. It would have also been nice to have someone on our team that would know what changes would be visually appealing to users without introducing usability problems.

Overall, though, we are extremely pleased with the result. The user interface is simple, elegant, and easy to use, and the design we chose during the paper prototyping process made it easy to design on the Android. We did not get complaints about not being able to complete a task, and users actually told us it was rather easy to complete the tasks. Some even said they would happily use the application if it was fully functional (and had a better color scheme). We were extremely pleased that the iterative design process allowed us to work out most of the kinks in our design early on and catch lack of affordances, information scent, and other helpful clues in the interface. It definitely shows in the final product.