...
We based our design on the following principles:
- Simplicity and attractiveness of design
- Safety from errors
- Efficiency and ease of use
- Safety from errors
Our final design is the result of three iterations of testing and evaluation. Below are the design decisions we made on each:
Paper prototype
| Several important changes resulted from this iteration:
|
Heuristic Evaluation
| The second iteration of our design yielded much criticism and many changes for our user testing phase:
|
User Testing
| |
| a | This is the default home page. It was implemented so that there would be a default page, as before we linked directly to the user's profile (which was an unprofessional design choice at best.) b | The next step was clicking either "Sign Up" or "Log in." These were separated because we observed that it was common to input a username and password in the incorrect boxes on websites that display both "Sign Up" and "Log In" options on the same page. None of our test users complained about this, so we thought it safe to implement this even though it goes against standard practice. |
| |
| |||
| |
| |||
| |
| |||
| This image shows a selected profile picture. g e | |
| ||
| | The user's reading list displays books he has read, books he plans on reading, books he has been recommended, and books he is currently reading. We added boxes surrounding the books at the recommendation of our test users in order to increase readability. Although Meelap Shah had recommended zebra stripes, we found that they clashed with the design of the rest of the website, and instead chose to enclose each book in a box. Aside from fitting the aesthetics of the site more closely, the boxes increase the space between books, making each book a unit instead of a part of a table. | |||
| |
| |||
| | | Here we display the logout page for our service. Note that the navigation bar has changed to exclude all options available to logged in users
|
Further Considerations
Our evaluation indicated that users prefer larger buttons and text over smaller ones, and to this end, we increased the size of both. This also improves the transferability of the design to mobile devices.
Implementation
We implemented the backend for our app with Parse, a Javascript-based backend which stores data online and thus does not require a server to be set up.
...
The decisions we made for implementation did not directly affect our interface. However, because we took a long time to choose the language for our backend, and struggled to implement it, we were not able to devote as much attention to the frontend as we would have liked.
Evaluation
Scenario
You want to know what your friends are reading, and you want them to read books you have previously read. This way you can bond over your shared reading experiences!
Tasks
- Create a profile.
- You are looking for a book to read later. Find one in which you would be interested later.
- Add Allison Abernathy as a friend.
- Find out who is reading the same book as you.
- Recommend the book to another friend.
- Delete Allison from your friends list.
User 1:
...
11-year-old
...
avid reader.
Usability issues found:
--Attempted to search by pressing Enter, which is functionality we intended to implement but did not have time to complete (major). There is no harm in just implementing it for every search bar.
--Was confused by the way in which ratings were displayed. The average rating is shown if the user has not rated a book, and she did not understand this. She also did not notice the “Average Rating” and “Your Rating” underneath the star selection (catastrophic). Possible solutions was to display Your Rating and Average Rating as starts as well, with the label to the left of the stars instead of above the stars.
--Accidentally clicked on the user below the one she was trying to add as a friend, indicating that perhaps the user entries are too close to one another on the page (major). The solution to this is simply to widen the gap where appropriate.
--Did not understand why confirmation was needed for recommendations, especially since it was not needed to add/remove friends (minor). In order to address this, we decided a possible solution was to ask for confirmation when asking to add or remove friends as well.
--Tried to add books to the reading list by visiting the Reading List page, rather than the page for the desired book (minor). We decided we could also provide a popup with a search bar in the Reading List order to allow the user to add books to reading list as well.
User 2: 18-year old reader
--Wanted to upload own picture; looked for a while before realizing it is not possible (minor). We were reluctant to allow students to be able to upload any picture in order to keep obscene or objectionable material from school webapps, but decided it may be possible if the administrators are notified whenever a student tries to change a profile picture so that they may review the change; if this is not possible, we wanted to just put instructions at the top of the popup.
--Preferred larger "search" button, particularly because search was not activated by hitting the "Enter" key (cosmetic, major). The solution to this is simply to make the Search button bigger.
--Wanted to be able to change colors; complained of lack of settings (cosmetic). Just as with pictures, we thought we could implement a small menu that allows users to change some settings including colors.
--Disliked having to go to book page to add books; wanted to add directly from book list (minor). We thought it would be useful to use a small popup that has a synopsis an the option to add to one's own reading list and a small summary that links to the book page, but were uncertain due to the possibly reduced efficiency.
--Did not understand what links at top of "My Reading List" were for (minor). When clarified, responded by saying they waste space anyway. The solution to this would be to place the Already Read section, which is likely to be the longest and least looked through, at the bottom, and to dispense with the links at the top of the page.
User 3: 16-year old non-reader
--Told me the links at the top of "My Reading List" were broken (minor). didn't understand that those links are only used/necessary if you have a really really long reading list of books, they help you jump down the page to the section you want to look under. Could solve using Meelap's idea of getting rid of those links entirely and making all the sections in "My Reading List" expandable lists with the plus sign next to the heading.
--When adding a book .
...
to "My Reading List", after clicking the button to add it said "It didn't do anything." (major) Solution, redirect the user to the "My Reading List" page after they add a book. Then they get the feedback instantly that it was successful.
--Upset at all the confirmations. (minor) Solution, we could get rid of the confirmations.
--Wanted a large selection of books. (minor) That was out of the scope of this project, if we had been implementing this as a real website we would have more books.
--Liked the ability to recommend books to friends. Also liked the ability to see what friends were reading.
Reflections
Elizabeth Attaway
In my opinion, we did well in integrating the comments we received during each step of the design process. However, it would have been better if we has implemented a more detailed computer prototype. Many of the comments we received for HW2 dealt with the fact that our prototype was unattractive (which was a result of our misunderstanding that external libraries like Bootstrap could not be used). We would have been able to get better feedback, and thus improved our final version more, if our prototype had been better. In addition, we would have done better to choose a backend early in the implementation process, which would have allowed us to focus more on frontend during implementation.
Paula Jacobs
This was my first UI oriented class and I think it was a success. Actually going through the design process, working with feedback at earlier stages, and creating with a team were all very useful experiences that I know I will refer to in the future. I’m happy with our final product, even if it wasn't perfect, and I've gained more confidence in my web programming abilities. If I had to do this all again, I would have asked about using bootstrap or Jquery UI for the front end earlier. I may have went with Jquery UI because it seems a lot more flexible than bootstrap. I really liked parse and found it easy to learn for the backend, but the javascript version seems a little limited at this point. Still, I think everything turned out alright, but I think if we had started the backend a little earlier (which would have required us to know a little bit more about backend options and have confidence we made the right choice), we could have smoothed out all the wrinkles in our final iteration. Given our level of experience though, I think we did wonderfully. As far as what features we used, we pretty much took it straight from our user tests and TA feedback. I would do the same again; only maybe I’d do another round of testing later in the process.
Carlo Mannino
Our design relied heavily on extra feedback due to the setback we suffered in our computer prototype. We incorrectly assumed we were not allowed to use outside libraries for the front end, which cost us valuable feedback for our computer prototype, since most comments were directed to the aesthetics of our design instead of the functionality or the details.
We managed to integrate almost all of the comments we received into our final design. The most critical step, however, is the computer prototype; there are many things that are attractive on paper, but the change in the interface from the paper to the keyboard and mouse makes the paper prototype completely different from what will end up on the screen.
In retrospect, it may have been useful to use a backend that was more widely used for JavaScript; although Parse has many wonderful properties, in particular that we didn't have to set up our own browser, its documentation for JavaScript is patchy and incorrect at times.
Finally, user input is invaluable. There were many cases where a feature that seemed completely natural and beautiful to us was awkward or misleading to other users. This is particularly true when trying to work on a problem whose affected population we have no connection to. It is a great experience to have; most projects one is likely to work one deal with populations at least slightly removed from the programmers, such that it is very useful to know how to approach such a problem.
Hannah Walker
A big part of what I learned from this iterative design process is that you will never make everyone happy. This really bothered me at first, because I am very much a people pleaser. I just want everyone to be happy with the design and our product, so it was hard for me when feedback from users was contradictory.
If I did this project again, I probably would have tried harder to get more users and more feedback because then I could see what feedback was more common among the target audience. That way it would be easier for us to incorporate designs that were more largely appreciated. Another thing I wish we had done differently was decide what our back end was going to be sooner. Although the back end didn’t have a huge impact on our front end, it did make it hard to allocate as much time as I would have liked to the development of the front end towards the end of the project.
Overall, I thought we did a great job. There were some user interface bugs that still needed to be worked out. However, we did a good job of incorporating the feedback we got, and there will always be room for improvement.