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).

Our final main page

:

Our computer-prototype main page

Decisions we made after paper/computer prototyping and heuristic evaluation:

1) We decided from the paper prototype that we should allow the user to search based on a particular search type instead of searching for a general term. Some users were confused when presented with one search box as to what kind of term to input.

2) We combined the four search boxes on the sidebar in our computer-prototype design into one search box and a drop down list to select the type of search in the final design. In the computer prototype, users find that the four boxes and the four buttons accompanying it are confusing; it is not clear whether the users can search using more than one type of search at a time. With the drop-down, it is clear that the user is only searching using one search type at a time, and that only one query is possible. We also changed the "Go" button to "Search", so that the user knows exactly what he/she is doing.

3) We removed the sidebar from all pages. This is as a result of the search box modification. We were about to fit the modified search box in the top bar, and so we decided to save space on the left. With new wider layout, we also centered the contents and resized some elements on the page to make a more compact appearance. For example, the comment sections and the preview boxes in the home page have their positions changed and padding reduced.

4) From the paper prototyping, users were curious about how they could find related photos when they're at a certain photo. So we decided to implement photo tags as links, as can be seen in the following screenshot.

The links go to a search results of photos related to that tag.

5) We added CRUD functionalities, including deleting photos, editing photo information, and deleting comments.

(The [X] in the following photo is the "delete photo" button)

Delete comments/edit photo information:

One feature that we missed, and was mentioned by our TA, was one that would allow the users to browse all photos in the site. There currently is no easy way to do this. In hindsight, we should have implemented it, since it would give the users greater freedom in browsing through the photos.

Implementation

Describe the internals of your implementation, but keep the discussion on a high level. Discuss important design decisions you made in the implementation. Also discuss how implementation problems may have affected the usability of your interface.

For the implementation, we decided to use the Django framework, since one of our members was already somewhat familiar with it.  Though this was decidedly well-suited to the demands of our implementation and the framework is quite elegant, there was an obvious learning curve that required us to spend much of our time familiarizing ourselves with the syntax and methodology, thus limiting our overall pace.  The Django framework, without discussing it on it a low level, uses a model-view-controller architecture which was perfect for our needs.  Though the final design of a Django system is often elegant and efficient, there is a lot of tugging and pulling between the models, views, and controllers, especially when the syntax and methods are not entirely familiar to the implementers.  In our case, these factors slowed us significantly and we just barely implemented all of our features in time.  Since we had, at that point, spent so much time working with and observing the system, we had lost much of our objectivity in the regard the interface and thus did not consider all of the usability issues on our last day of implementation.  Particularly, we failed to notice one glaring flaw in our system: there is no way, other than search, to discover and view photos.  On the plus side, Django is equipped with a very robust user authentication, data validations in forms, and error reports for form elements. These features sped implementation process since we can concentrate on something else rather than security and form validations.

We also made use of Ajax and JQuery UI for the autocomplete feature in the search form. We agreed that the feature is important enough for the usability of the site to spend the time making it. Since we have to integrate it with our backend, it took a while to find a suitable autocomplete library, and we needed to spend even more time tweaking it to fit our needs.

One minor point about our implementation is the feature that previews the photo that is about to be uploaded. In addition to giving an immediate feedback, this feature also offers error prevention by detecting if the selected file is an image file. Sadly, this feature only works in browsers that are equipped with HTML5.  In browsers that are not, the upload page's usability is affected a little (a placeholder image, saying that the picture is selected but cannot be displayed, is put up instead). However, the uploading still works all the same.

Evaluation

Describe how you conducted your user test. Describe how you found your users and how representative they are of your target user population (but don't identify your users by name). Describe how the users were briefed and what tasks they performed; if you did a demo for them as part of your briefing, justify that decision. List the usability problems you found, and discuss how you might solve them.

We decided to test our website with three users from our friends and families. Since our website's user population is generic enough, finding the user base that match the target population was not a difficult task.

The briefing and the tasks were similar to those we did in paper prototyping (see GR3). The three main tasks included searching, commenting, and posting photos. Since our final implementation also has user system, we also have minor tasks for the users to register and log in to the website. For some users, we also included the task for deleting photos and comments. We did not feel any need to do a demo; just a quick overview of the site's purpose was enough. In general, we were really satisfied with the relative ease that they were able to perform the tasks, especially compared to previous prototyping.

Usability problems we have found include:

Issue #1:

Problem: One user, when attempting to search for and view photos, was frustrated that there was no obvious way to get to photos.  That is, the only way to find photos was to search for them and she had no idea what to search for.  The user guessed at a few possibilities for search terms and had some success, but the user was frustrated that there wasn't a way to access a list of photos.

Solution: One solution is to present some section of the photo content on the home page along with links to navigate through the larger set.  Our initial design for the home page (and the one we stuck with throughout the project) derived from the need to help users come up with search term ideas.  This was made nearly obsolete by the helpful auto-complete feature we implemented and, thus, the current home page should have been removed in favor of a home page that presented more photos and more ways to explore the larger set of photos.

Some solution ideas:

• Have each picture in the homepage linked to the search result page for the corresponding keyword rather than the image itself. For example, if the picture in the "Location" box with a label "LA" is clicked, bring the user to the search page of the location "LA".
• Expandable categories: have the category header of each box ("Photographer", "Location", "Time", and "Type") linked to a special page that display usable search query of that category, ordered either by popularity or alphabetically. For example, clicking the word "Location" brings the user to the page with a list of all locations.
• Recent photos: display photos that are just uploaded on the front page.

Issue #2:

Problem: The photo view page allows comments, but does not allow captions.  One user has the opportunity to post the first comment on her photo; however, the user would much prefer to be able to post a caption under the photo so that is distinct from all the comments.

Solution: This would be easily implemented by adding an extra text field to the upload form and adding a caption in the photo display page. One alternative solution is to offer a comment field in the upload form, and display the comment in the info box on the right hand side of the photo.

Issue #3:

Problem: One user would like there to be a field in the upload form for submitting a link.  Since it doesn't make sense to post an entire recipe on the website, she'd like to be able to link to it.

Solution: This could be implemented in the same way as photo caption. However, this might present some security issues and, at the least, the website should ask users who try to click the link if they are aware of the possibility of a malicious link.

Issue #4:

Problem: One user wanted to change his username while he was browsing the site using his account.

Solution: We didn't implement that feature, even though we had CRUD features for both photos and comments. We could have made an "edit user info" page that is accessible from the user page.

Issue #5:

Problem: The "search by photographer" only searches for username. One user tried to search by full first and last names (that he provided in the registration), but couldn't.

Solution: It would be better if the user can search using either real name (first and last names) or username. One possible solution is to offer autocompletion of the form "First-name Last-name (Username)", and allow the autocomplete system to look up the typed query in both usernames and real names.

However, searching by first and last name can lead to ambiguity since several people can share the same real name. One solution is to have a page that list all users with the same name as the input query, and then let the user choose the name he wants. This ambiguity resolution page can also be used on other search categories as well.

Issue #6:

Problem: One user didn't discover our autocomplete feature, as he was typing too fast into the search box for the feature to manifest itself. As a result, he was left wondering what query he should use to search by type.

Solution: We couldn't really do much about this, since the delay is internal in the implementation.

Issue #7:

Problem: One user typed multiple words into the search box, thinking that it is similar to popular search engines' search boxes that can search multiple terms.

Solution: By design, we do not want the users to use multiple search terms.

Issue #8:

Problem: After one user filled out the registration form and clicked the Submit button, the home page appears. The user got confused, and complained that he has to log in manually.

Solution: Instead of redirecting to the front page, the website would log in the user automatically, bring the user to the user's page, and display some message to help the user get started.

Issue #9:

Problem: One user have trouble finding the place for deleting the posted photo. He searched for a delete photo button in the photo view page until he finally realized that he must use the small [X] link in the user's profile page to delete photos.

Solution: Increase the visibility of the small [X] button by changing it into an icon or a word "Delete". Also include the delete button in the photo view page.

One side note to the delete buttons (for both comments and photos) is that they lack error prevention. There are no confirmation boxes, and the user cannot undo the action. It would be a good idea to have some confirmation before the comment or photo get deleted.

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.

When we created our paper and computer prototypes, we decided to focus on the three main objectives of the website: to search for photos, to post photos, and to comments on photos. As a result, we have abstracted away some other features, such as user authentication. We thought it was a good decision since our main focus of this course is to design a good user interface that fits the main objectives. The computer prototype ended up not having any user authentication or CRUD system. When we began our actual implementation, we realized that the decision was a risky one: since we do not have those minor features, we have to spend time to create them during the short implementation period.

Our implementation, our method of implementation, and the time available to us all had significant impact on the end result of the interface and, thus, its usability.  Since we had only two weeks for implementation and our website required implementing user registration, user log-in, user log-out, four-category search, photo and text upload, and user commenting, we had to work at an extremely fast pace in order to not have to leave any of these features out, each of which was essential to our original vision.  This pace had two direct effects on our implementation phase. One, we were so busy implementing features that we had no time to notice any interface issues or reconsider any previous choices.  And two, we were each working very intensely on various parts of the site, so it was difficult at times to coordinate and delegate tasks.

Our biggest mistake in regard to communicating during the implementation phase was not having an immediate real-time form of communication.  This would have been find if we had the luxury of taking turns on different tasks, but were often working simultaneously on various aspects of the site.  The biggest issue was relying on e-mail instead of using the phone or on-line chatting.  The price we paid for using e-mail was that one group member might spend three or four hours attempting to implement a feature when another group member could have done it much more quickly.  This would never happen in most work environments.  Furthermore, since we were mostly beginners with the Django framework, being able to discuss implementation methods in real time would likely have helped all of us learn faster, again speeding up our implementation time and allowing for more reflection on the interface at the end of the implementation.  However, considering that are group was spread out by quite a few miles and we had little opportunity to physically meet due to conflicting schedules, our group did quite well with remaining in touch.

One relevant mistake was the lack of direct code collaboration. The code was put on one of the group member's private Athena account, and we did not have a good system to work on that code at the same time. One obvious solution is to use a version control system so that everyone can edit the code at any time without conflicts. If we could redo this project, we would set up a better communication method and a version control system for our website.

After we finished our implementation, we have received several comments from our TA and user testing. As mentioned before, one of our website's weakness is in the lack of user control. The user cannot easily navigate through the photos in the system, since the only way to access photos is via the search feature. We also observed that users did not care much about the main page at all. As a result, we think that we should have spent more time on designing the front page in order to give more information to the users.