Development Process

Website - Calculator Portion

The low fidelity prototype of the calculator portion was developed in Flash and as such, had virtually no limitations in how it could be designed and was indeed designed without regard to whether it could be implemented easily or even possibly given the technology that would be used for the high fidelity prototype. It was intended that the final implementation would be developed in HTML. However, the high-fidelity prototype was also developed in Flash due to some concerns about the success of it in HTML. It went through many iterations from the original design. The overall look and feel of the design with its bold colored bars was preserved as a portion of the main entrance screen when displaying the average users results. The second screen developed (where the user enters personal data) however, became more of a consolidation of many of the secondary layers (see the transition diagram in figure 4). This design was tested out because it seemed that more information could be well contained in a single screen. So, both the entry fields and the results fields could all be displayed in the same screen. This would need to be refined further and another round of usability testing would be necessary to determine if this is acceptable. The current state of it is not complete enough to make the determination whether this is an improvement over the original design.

The final version will be implemented in HTML and CSS. AJAX would also be needed to provide the popup “bubble” information that will help motivate users (the “Quick Fact”, “Helpful Hints”, etc. described previously).

The development of the backend portion of the calculator will be fairly simple to complete since it entails mostly making simple calculations and displaying them to the user. The formulae necessary for most calculations are easy to implement. For example, how many barrels of crude oil are saved based on the number of gallons of gas (there are 42 gallons produced from a barrel of crude oil ).

Some tables of information will need to be created. For example, the list of different car types and their associated gas utilization. Also, a table of distances between common cities. This will be used to show the user an example distance similar to the amount of walking required in a year. This table would have to have a range of distances of varying lengths so that a similar distance could be equated with the user’s annual exercise.

The tutorial was created using the “camtasia” tool. This tool was simple to use and provided a sleek, refined way to help the user see how to use OffRoads. There will be a note for users when running the movie (a .AVI file) so that they will be instructed to turn up their volume if they are not hearing the audio. The hope is always that the user interface is designed so well that a tutorial is not necessary, however, that is unfortunately not usually the case, as it is commonly known that all users will interpret any computer application in their own unique way.


Figure 7 - Second Revision of Low-Fidelity Prototype
The low-fidelity prototype was revised slightly before starting implementation of the high-fidelity prototype to make the application more user-centric: note the use of “My” in front of the categories (slightly altered also). The dull grey was replaced with bright orange for a header. An area was added for system messages in the header. Many of these changes did not carry over to the high-fidelity prototype. See Figues 1-3 for the first version of the low fidelity prototype in the Design section.



Figure 8 – High Fidelity Prototype: Main Welcome Screen The main screen was modified to include help, a graphic and a different header as well as a button to move the user to the next screen. Selecting the “Help” button will provide a pop-up dialog box of contextual information (see figure 10 for a sample).



Figure 9 - High Fidelity Prototype: User Entering Information
In this screen shot, a user is entering some of the information required to make the summary calculations. Note that what was designed in the low-fidelity prototype to be the welcome screen is included in this second level screen as it was deemed that perhaps both levels of information could fit in a single screen. Since not all of the necessary component data is included in this display, it remains to be seen whether this design could be used. After a user enters in values, in this prototype, they would need to press the “Calculate Your Savings” button to have the summary values updated on the right side. A final version would not require the user to do this, it would update the values automatically as the user entered the necessary component information. Selecting the “Tutorial” button will run the movie like tutorial steps the user through the process of completing common tasks by showing them how to enter the necessary data.



Figure 10 - High Fidelity Prototype: Help Text
The help text will be displayed in a pop-up dialog box. This will be used to provide small amounts of guidance, such as a correct range of values. It will also be used to explain errors.


Website – Blog Portion

The first screenshot of the blog (figure 11) is of the main page. The links need to be added, it is just the general idea of the website. The website is powered by WordPress which is an open source web site content management system. Since it is open source, we are allowed to use its database feature for free as long as we keep a reference to WordPress on the site. The template functions the same way as it is also open source.

The second screenshot (figure 12) is of a user (Sally in this case) replying to the demo post. Here you can see that she can write up her post and simply hit submit. The third screenshot (figure 13) is of an unregistered or registered user not logged in making a post. Here you can see that this type of user would have to put some sort of information in order to post correctly.


Figure 11 – Blog: Main Screen



Figure 12 – Blog: User Replying to a Post



Figure 13 – Blog: User Initiating a Post (User Not Logged in)



Figure 14 – Blog: User Entering a Post


System Requirements

The low- and high-fidelity prototypes were developed in Flash, but the final version would be implemented in HTML. Therefore, the user will only need a web browser that is a current version with no special requirements currently in terms of plug-ins. The user’s browser will be tested to make sure it is suitably configured so that the user will be informed immediately if the web browser can not support OffRoads to avoid user frustration later on after using the website and finding that a feature will not work with his version of a browser. Contact information for help will be supplied if the user has problems.

The whole website does not need a complex array of pages, therefore CSS based templates will be used for two reasons. The first is to provide uniformity. The second reason is that it limits the size of the actual HTML file, as a goal in developing this is to reduce the overall size of the site since the user might be on dial-up.

The servers hosting the website will need to be dynamic as the amount of traffic to the site builds. Many hosting packages now come under five dollars a month and with plenty of bandwidth and storage space (per month). In particular, “1and1” Hosting (www.1and1.com) has hosting for about three dollars a month and has 500 GB of traffic allowed. This is plenty to start with.

One consideration of the future design is to maintain a database of users’ data to build up national and local averages for their comparison purposes. This will require a large database that will need plenty of space to grow. As more users come to the website and user profiles start to strain the hosting account, an upgrade to a bigger package might be needed (a problem that would certainly be welcome).

This website will rely on data that will need to be updated periodically. For example, current gas prices will need to obtained on a regular basis. There are many sources for this on the web. AAA has data showing trends in gasoline costs for different types of gas. It also has a regional cost summary. The government provides a website for calculating true gas mileage that could be used too to increase the accuracy.

Usability Testing

In general, the users who tested the high-fidelity prototype were positive about the user interface and found the calculator portion easy to use and the blog portion interesting. The subject matter was more of interest to some than others, which is expected and an inherent part of the difficulty with such a subject matter as this website addresses, specifically changing personal daily habits for the sake of the greater good (improved ecological environment).

The users were given tasks in using our prototype and blog. As per the prototype, they were asked to enter in values to calculate costs saved and view the help function. They were also given an introduction to the report and what was missing from our prototype to gauge their reactions of our project. They were also asked to make an account with the blog and post a message online. The phone aspect was not tested because it was no functional at that point in time.

General User Comments and Suggestions

Everyone liked the Help Button and how it was easy to find. However a reoccurring comment was that it needs to be more in depth. It is very basic right now saying the minimum, but it could definitely be expanded.

There is also no help section affiliated with the forums pages, which still needs to be added. The direction of the forums or blogs needs to be worked on. There seems to be a few ideas of where to take this section among the testers. One approach is to have small specific sections like carpooling, user testimonies, help, etc. Another approach is leave it as it is until the site grows big and then deal with sub-categories. By doing this method, we would leave the forum open to anything as opposed to having many sub-categories and only one or two entries.

Another comment about the blogs was relatively reoccurring: how to deal with posts or questions on the forums after a certain period of time. It does not look good to have old posts or questions that have not been answered in months. It will be necessary to either ‘archive’ them or delete the postings every few months.

Quality of Usability Testing

We picked only undergraduate students for our surveys since they are the most represented at the school. It was a coincidence that each member happened to pick two males to participate. The lack of female representation was not intentional and further plans for usability tests will remedy this problem so it is closer to a 50/50 balance between male and female undergraduate students.

The average user was about the age of 20 and considering the focus was on under graduates, that is a good norm. This does indicate that more upper classmen were chosen than younger college students. The average use of computers per week was between 17 and 20 hours. Computer use was considered to be anything from using the computer for email, video, homework, papers, etc where the student was actively interacting with the computer. If the tester was just using it to play music, it was not included in those times.

Most of our subjects relied on private transportation methods when they had a choice, and some of the younger candidates who did not have that option were forced more to accept public transportation.

All in all, they were all very open to the idea, though some were more drawn to it than others. A recurring comment was that the website is very easy to use, but the motivation of why a student or commuter would use such a program was expressed as a concern. Subjects questioned what would draw a person to look into the site and how much would they value or trust the outcomes. One solution would be to show the work and logic behind the calculations. And there are few other possibilities to be considered. Again this deviates from the point of testing usability so no further detail will be provided. But as a whole it went great and most people flew through the tasks without asking questions or raising concerns.

Usability Subject Detailed Comments

The following are notes from a subset of the 8 tested students.

Subject 1: Navpreet

Navpreet is a junior who relies mostly on his car to commute to campus and to work. He sometimes takes public transportation.

He liked the idea of the calculator, but liked the blog better. He questioned the validity of the results without seeing the sources. One comment he made is that within the blog/forum area, there could be a section to try to get people to commute together. For our test scenario, the commuters still need to get to the Metro station, which will happen typically by car. Since they have to take the car to get to the Metro, they might as well drive each other there to save even more gas.

Navpreet suggested that the forum perhaps had a way for people to click on a Metro station (i.e. College Park Station) and see who travels from that station to arrange a better commuting schedule. Implementing this is not difficult but it brings up the concern of security and public posting of information like the commuter’s name and address proximity. A solution could be that we can make OffRoads email addresses for each log-in based on the user’s log-in name so if Mr. X wanted to contact Mr. Y about commuting to the Metro, an email can be sent to MrXLogin@offroads.com (for example) and should Mr. X care to respond, he can. This sort of system is done on Craigs List. Another simple option is to warn the poster that his information (name/address proximity) will be public information. The previous option is more secure and user friendly with novice users, but for the first phases of this project, the latter option is easier to implement. This will be considered further.

Subject 2: Malcolm Malcolm is an athlete at the University and is a junior. He does realize the benefits for public transportation to school and work, but relies mostly on his car to transport himself. For example, when he has 5 AM practices with the team, he would rather drive himself or get a ride rather than try to catch the bus. Deficiencies in the local public transportation are a concern that are outside of the scope of this application. A goal of OffRoads is to provide users a comparison of public and private transportation.

He found the test to be very easy and straightforward. This seemed to be in common with the responses of the other subjects. He did spend more time looking at the blogs and the dummy data. He said that if they were filled with testimonials he would be more interested in that as opposed to the actual calculations. If that was the case, he mentioned it would at least spawn an interest in looking at the cost calculator and re-thinking public transportation.

The idea of trying to estimate cost between public and private transportation is not a new one, but trying to make it comprehensible and appealing to a variety of users is a goal of this system. Malcolm agreed that user testimonials would bring more credibility to the system. He did not seem to care about the models or reasoning behind the calculation (as Anand was – see below). He was more concerned with the site being useful and attractive as a whole.

Subject 3: Nikhil

Nikhil is a senior engineering student at the university. Like most of our testers, he relies heavily on public transportation, primarily the UMD DOT’s busses.

He completed the tasks fine with minimal questions and is anxious to see the final product. He asked about our sources and as they were explained to him, he saw that there are many similar projects out there. His main concern was getting this out to the public and how it would be implemented.

Even though the comments steered away from the point of a usability test, he did bring up a good question. It is not a question we have fully prepared for. Once we have the final product done, where does it go from there? How or what is the best way to reach a good majority of DC-Metro-Area commuters who drive on their own?

Subject 6: Anand

Anand is a freshman student at the University of Maryland. He does not have a car on campus and relies heavily on public transportation within the school setting and when he is home. He was more excited about this project because of his heavy use of public transportation. We think that since he was more enthusiastic about it, his comments were more complimentary then derogatory. But he did have some useful comments.

He loved the blog aspect of the site but had similar comments that Navpreet had, specifically, that it can be expanded to add more features. His main focus of what could be added would be specific forums and successful user testimonials.

As far as the OffRoads Calculator, he mentioned to include more of an explanation of how the results were derived. Perhaps it could be an optional button that would explain the math or logic behind the results. It does not have to be a mandatory feature where the user has no choice but to see the methodology behind it, but maybe another click-button that would bring up a screen explaining how the data was calculated.

Mobile Device

The OffRoads Mobile website allows users to view the calculator via a mobile device that is WAP enabled. Many phones and PDA’s are able to access WAP content, but are not able to access html content, so OffRoads Mobile allows more people to use the calculator.

System Requirements

Different mobile devices display WML content in different ways, so a very simple interface must be used in order for the majority of users to be able to view our calculator. The Nokia Mobile Internet Toolkit allows web developers to test their code on multiple PDA and cell phone SDKs, giving feedback on whether the code is compatible. Nokia provides SDKs for each of their phones in production, enabling testing the functionality on the Nokia 3300, 3410, 5100, 6310i, and 7210. While certain graphical interfaces are available on the Nokia 7210 SDK, they can’t be run on the 3300, so the interface was designed around the 3300’s capabilities, which were compatible with all later models.

Implementation

As of now, the actual calculations are not implemented. A CSS page would be needed to calculate the actual savings given the user’s inputs, along with the functions that provided the calculations. An actual implementation would communicate with the CSS page and be sent back the resulting answers, all viewable on the mobile device. All of the links are enabled however, along with user input and variable selection.

Since a WAP-ready server is required to host the content, it is not possible to give demonstrations via a website. Testing is possible through WML simulators, like the Nokia Mobile Browser 4.0 shown in the screen shots below. The simulator reads the WML page and displays it as a mobile device would, and simulates the limited functionality of a phone or PDA. OffRoads Mobile can be divided into 4 main sections: the homepage, the calculator, the results, and “about OffRoads”. Using the arrow keys, users are able to select between links and input fields, and are able to enter information via keyboard or numbered keypad represented on the phone. The screen shots below were taken using the Nokia 3300 SDK (see OffRoads Mobile section for a video demonstration of OffRoads mobile).


Figure 15 - Mobile Device Sample Screens
These screen shots were captured from the Nokia Mobile Browser WML simulator. The sequence shows a user using the calculator portion to enter personal data including their car size and daily mileage, and getting help information.