1. Improvements over GR5 for user testing
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.
2. Design
Describe the final design of your interface. Illustrate with screenshots. Point out important design decisions and discuss the design alternatives that you considered. Particularly, discuss design decisions that were motivated by the three evaluations you did (paper prototyping, heuristic evaluation, and user testing).
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.
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. “Locate in Map” for an event only linked to that floor, so the users lost information about the particular tank for event location when to leave the event page.
Severity: Major
Solution: Link “Locate in Map” to not only the floor, but also the tank where the events are scheduled to happen.
4. "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.
5. 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 substring for the animal search query.
6. 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.
7.
5. Reflection
Discuss what you learned over the course of the iterative design process. If you did it again, what would you do differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observations.