GR6 -- User Testing of Final Implementation

1. Improvements over GR5

Usability and Design:

• Feedback on the active section was added by changing the color of its menu button.
• When clicking Locate in Map from a Search Result, the Map is directly opened in the correct tank, not only in the floor.
• Some minor broken links to picture files and animal names were fixed.

Events:

• We have iterated through various versions of a design that is circular, very simple, and ties animals, events, and location together. The events page has been hard because there is a lot information attached to each event and including all of it, for all events, quickly makes the page overloaded and confusing. Our latest version focused on coarse-graining information, i.e., more detailed information is shown if the user asks for it, and allowing the user to directly manipulate the events available that day, i.e., the user can sort, drag, and delete events from the page. However, this approach required us to include safety features that were somewhat abrupt. For example, if a user deleted all events and wanted to get them back, a ‘Reload Events’ could be pressed to have them reappear. Moreover, the temporal relationship between events, which is inherent in any list of scheduled items, was not captured by the interface and could only be obtained by looking at the small hour numbers for each event. We incorporated the comments from our TA and have modified this page to account for these problems. We show events in temporal order and have the hour be the most significant text on each element. This makes the list look like some type of calendar that is as simple as it can be but also allows for access to all the information regarding it (animals, location, specific information regarding the event with more pictures). Additionally, we replaced the remove feature with a button beneath each timed element that can be marked and unmarked. The idea is that the user will associate time, event, and this marking system, and will use it to keep track of what they are planning on attending. This also allows us to remove the drastic ‘Reload Events’ safety feature and simply let the user mark and unmark as needed.

Tickets:

• Disable selecting a past date for tickets.
• Change <= to English word.
• Change some design so that the total price is more visible.
• Add cookie functionality so that if a user has already bought a ticket, going to the ticket section display the confirmation page.
• Add a purchase button at the confirmation page.

Maps:

• Make the affordance for linking to animals stronger by changing the style of the links.
• Change the text of level buttons to achieve consistency
• In Chrome and Safari, the position of the map is in the left of the page so that the map would not be obscured by the tank pop up and clicking in a tank close the pop up.

2. Design

2.1 Design Flowchart:

The navigation schema of the website is shown in the following Figure. The goal of the design was to keep the number of pages to the minimum but not over populate then with information. From the paper prototyping stage (GR2), the idea was to have a circular design connecting three main pages: Tickets, Map and Event. The idea started with the metaphor design (see GR2) and then with the location-based design (see GR2). For user testing of the paper prototype we added the search feature and included it in the circular design.

In order to keep the number of pages to the minimum, we incorporated in a single page different types of information that are logically connected. For example, the Map page presents the animals in each tank, instead of having a page and having another page for a list of animals. If the user need is only localization, the Map site solve the task, while linking to more information about the species (search result) if the user decides to learn more about it. This also allows find species with unknown name (which can't be done with the Search page.

2.2 Main Page/Search:

The graphical design is based on a color scheme related to the Aquarium theme. The background image is a picture of an underwater environment. A semi transparent white background was used to serve as intermediate background for the content box to make the text readable. Typography (size and font type) together with white space and balanced layout was used to emphasize the simplicity of the design as transmit the feeling of usability. This design was generated after computer prototyping. We kept the concept and navigation logic, but changed all the graphic design, speciacially because of the size constrains of browsers in desktop/laptop and mobile devices.

The navigation menu is fixed to the top part of the screen to improve usability, even if the page is scrolled up and down. Feedback about the active page is provided by the color in the menu button.

The main page shows the search function. This feature is using autocomplete, is in focus when loading the page, and is enhancing information scent with the 'Penguin' suggestion on grey color.

2.3 Search Result:

The search result present a table with information about the specie and a picture. To find the animal in the map, it's possible to click on 'Locate in map' and it will open the Map page, showing the specific tank in which this species is located. This idea surged after early user testing of this implementation.

The search bar is still located on top to improve usability by being able to perform a new search from the result page (no need to go back).

Both the search bar and the information table is centered to keep the layout balanced.

White space between pieces of information is used to enable visual grouping of information.

2.4 Tickets:

The layout is using to vertical columns. This is useful to (1) keep spatial separation between the Ticket and the Billing Information, (2) keep the layout balanced in space, and (3) no need to scroll up and down so that all the info is simultaneously in view.

This page is using feedback to inform the user about errors and the price of the current order.

As a safety feature, the system presents a pop-up windows with a summary of the order before processing it and explicitly says this to the user to transmit security. 

After processing the order, a confirmation number is shown.

2.5 Map:

The map page is rich in information: it contains localization information and link to species information.

It is possible to navigate through the three floor by using the buttons below the map. The map will automatically refresh.

The map has been simplified to present the information that is relevant to the user while discarding unnecessary geometric complexities that are not perceived by the visitor to the Aquarium. This allows intuitive direct mapping and reduces the cognitive load on the user.   

Each tank is clickable to show a list of animal in the tank. The Map image is kept at the left while the animals list is in the right column, similar to the tickets layout. This reinforces internal consistency of layout.

2.6 Events:

This page shows the list of events of the day. We used a two-columns layout to give space to pictures and text information. The time of the events are the most relevant piece of information given that visitors are likely to choose events based on time as first criteria. The user can mark its favorites event by using a blue bar that can be marked and unmarked. Events are sortable so that the user can interact with the list and organize them as desired. A 'more info' button dynamically displays the information below the event.

The event also has links to the map and animal information.

3. Implementation

We used HTML, CSS, JavaScript, and jQuery to implement the front-end. We also used Twitter Bootstrap to take advantage of the visually simple and balanced layouts provided by this toolkit, as well as the options to adapt the layout to different screen sizes. The site is primarily designed for mobile devices (tested on iPad - Safari), but will also work for desktops (tested on Firefox and Chrome).

All the user interactions and feedback such as checking for buying ticket input fields, drag and drop events, and search autocomplete are implemented using javascript and jQuery.

We used Git for version control. This was useful to keep track of the changes across the different pages and to share the changes that might affect other pages.

The site has four parts: tickets, map, search and events. Different sections of the website share the layout and graphic design by using the same view tree (background, fixed menu, content area for each page). This is to make sure that our site is easily navigable and internally consistent. Each single .html then inserts its own content on this section of the viewtree.

We did not implement a back-end database mainly because the number of data we need is small and displaying static pages for events and animals suffice. This implementation limitation may affect the usability of the interface by restricting the number of animals a user could search for and that the events page is not updated with time.

4. Evaluation

We test the interface in Chrome with three adults interested in going to the aquarium or have been to the aquarium before. We found our users by reaching out through our friends and some users are same as when we did paper prototyping.

4.1. Briefing:

Two adults with a child arrive at the aquarium without a visit plan and they hope to plan their day there. They have limited time available because they are tourists in Boston. This web-based system is available through a tablet to accomplish the most common tasks required by visitors.

4.2. Tasks:

Task 1: Buy 2 adult tickets and 1 child ticket

Task 2: Find the Little blue penguins and go there.

Task 3: Find the events (times-location) related to penguins today.

Task 4: You saw an interesting red fish. You want to get information about it and find out its name. The only information you have is your current location.

4.3. Demo:

We did not use a demo for user testing because one of main principles that ruled our design was to make it simple to use and learn in a few minutes without previous instruction. Given that the site is intended for visitors to the Aquarium, our target population will likely see and use the site for first time during the visit and won't have cognitive availability to learn complex procedures that are needed only during the visit.

For a short overview, we prepared a 30sec video for the Madness

4.4. User Testing Experience:

This section summarizes the more relevant critical incidents we found during user testing.

Task 1 - Buy 2 adult tickets and 1 child ticket:

- After buying a ticket: "What do I do now?", Even though the task was successfully accomplished, the user felt lack of logic procedure after that.

- After buying a ticket: "I don't feel I actually bought the tickets, I don't trust this message, no codebar or something?", The user found the confirmation message doesn't transmit security.

- After finishing the task: "It was straight forward!", Good comment! Positive for usability and learnabilty.

Task 2 - Find the Little blue penguins and go there:

- To start the task, the user was hesitant about using "maps" or "search": "I think search is only for the information of the animal, I'll go to map". The answer is that both link will work for this because of the circular design.

- After finding the Penguins in floor 1: "How do I know that there are no more penguins in the Aquarium in other floors?"

- While using the map: "I would like to have the search box here in the map as well", "I would like to be able to mark animals as favorites"

- After finishing the task: "Pretty easy", Good comment! Positive for usability and learnability.

- Searching for "Penguin" didn't work, the current list is limited to names in the list, and for this case is "Little Blue Penguin"

Task 3 - Find the events (times-location) related to penguins today:

- "No indication of ongoing events"

- " I want to filter the events"

- "I want to set up a reminder"

Task 4 - You saw an interesting red fish. You want to get information about it and find out its name. The only information you have is your current location.

- "There is no indication I can click on tanks to see the animals": The user didn't see the initial help box.

- "I appreciate the overall simplicity", Good comment! We think this reveals a good feedback on the main objectives of the design.

4.5. Usability Problems:

1. Users are not sure what will happen after they have purchased the ticket, e.g. what’s the form of confirmation.
Severity: Major
Solution: Assures the users that after purchasing the ticket that they would get a ticket number.

2. It is difficult to find the events related to a particular animal, such as little blue penguin.
Severity: Major
Solution: In the event page, add filter function to allow users to filter the events by keyword.

3. "Search for Animal" seems to be redundant with “penguin” also typed into the box, which also suggests an animal could be searched.
Severity: Minor
Solution: Replace “penguin” in the search box by “Search for Animal” hint to simplify the interface.

4. The users need to type in whole name of an animal or select one from the dropdown. For instance, searching for mistyped animal name returns Animal not found. It would be better if the system is more lenient with user input.
Severity: Minor
Solution: Implement backend database for animals and match sub-string for the animal search query.

5. Selecting an animal from the drop down suggestion does not automatically search for it. The users need to press Search button to perform searching.
Severity: Minor
Solution: After the user has selected an item from the drop down list, automatically performs searching to improve usability. This could be down by triggering the button click through jQuery code.

6. Some users don't see the initial help message in the map. This produces lack of information about the tank affordance.
Severity: Major
Solution: Keep this message for a longer time.

7. There is immediate information about ongoing events.
Severity: Minor
Solution: Include an icon for current events

8. There is no help for billing information, such as where to find the security code. This brokes external consistency and degrades usability.
Severity: Major
Solution: Include help icons as commonly used in other websites.

9. To perform a search, the user need to go to the search page. Some users want to have it immediately available.
Severity: Minor
Solution: The search box could be present in all pages.

Final comment on user testing: We observed that some of the problems found in the last set of user testing are now recurrent (no big variations among users) and known (no surprises or problems we haven't worked on the design) , and some of them are the consequence of some design decision that otherwise would have produce bigger problems. As general evaluation we think this is positive because it means we got an advance stage of iterative design trying to minimize the number of usability problems. There is no perfect design, but we observed satisfaction from users.

5. Reflection

Most of us are accustomed to using an engineering paradigm when approaching any design project. Because of this we initially focused on the intended functionality of our page; we tried to find problems users were having while at the aquarium and only thought about finding ways to solve them. However, as soon as we started getting feedback from other students and performing users tests we realized that presenting information or any resource to a user is not trivial and that a lot of widely-used design techniques we are used to having in our interfaces are essential. For example, during the paper prototype testing sessions, we thought users would have no problems with standard tasks like filling out a form with their credit card information, and would spend most of their time playing with our first map/scheduling interface. However, we found that most standard design decisions we take for granted, e.g., aligning and grouping input boxes that are related to each other, greatly affect the user experience. Similarly, in order to provide users with solutions to all their needs, our first design iterations had too much information on the screen, and had them traversing numerous screens. The studio discussions greatly helped us find ways to minimize the amount of information on the screen and to maximize simplicity. After taking all these things into consideration, we were able to converge on a simple, cyclical, design that allows the users to coarse-grain the information on the screen and to go iterate through animal, location, and event information.

If we were to go through this process again, we would probably try to get a paper prototype together as early on as possible and focus mainly on getting continuous user feedback on what they expect, like, and not like. We think this would allow us to focus on the user experience and increase the probability that we find features that don’t typically arise from analysis of problems at hand, but do arise from user testing and interviewing.  There are many things we learned that could potentially better tackle a similar project in the future. For example, simply having all the information needed for a user to solve a problem or complete a task is not enough, one can easily drawn the user in information or simply make it very difficult to access. Similarly, the users needs regarding a task or problem must be understood at a very intimate level as an effective interface requires that only what is absolutely necessary is present in a simple way. Finally, adding more functionality or features is not always a good idea. This is somewhat counterintuitive, as one can easily think that there is no such thing as too many options or ways to do a task. However, user testing and the studio discussions made it clear to us, that one can easily ruin the efficiency of an interface by adding too many ways of interacting with it. Through the class and project we learned many things regarding how about design and implementation. Perhaps the most important thing we got from the class is a better understanding regarding how to think about the problem and force our mind to think on the experience of an user in an area we are nor familiar with.