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.
...
5) We added CRUD functionalities, including deleting photos, editing photo information, and deleting comments.
Wiki Markup
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.
...
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.
...
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:
Wiki Markup
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.
...