Week 7 Journal

This week in the studio classes we demonstrated our paper prototypes as well as tested some other groups paper prototypes. 

Our prototype was mostly complete but did lack a few more specific features that we intend to implement. This provided a few limitations to the tester which they will be able to use in the final product. One of these limitations was map zoom and movement functions as well as a user profile page. However, the tester was still able to navigate through the main features of the application. I found in the prototypes that I tested, that some had features that were limited by the paper prototype and required it to be explained by the person who was the 'computer'. Some applications though, were very well represented by their paper prototype. I found the one about the article chains to most effective and best represented, this also was the one I gave the least 'general' feedback but focused more on specific features that may need to implemented such as specific error catching.

We were given quite a bit of feedback on areas to improve, mostly relating to general interface and ease of navigation. While being a 'user' of other groups concepts, I tended to give feedback on some of the more subtle human-computer interaction aspects. For instance, one group displayed a video immediately at the start explaining how to play, this window also featured a 'skip' button which I immediately pressed without having any idea of how to play. Once I got to the next screen, I pointed out that there was no way for someone who may have skipped the intro video (even accidentally) to find out how to play without having to go back/refresh their browser.

I found that the feedback given was generally reliant on how well-done/complete the paper prototype was. Prototypes which still lacked in displaying basic features such as some navigation generally required more 'effort' to use. Ideally, the application should be engaging but not be too difficult or take to long to get to the substance of it, otherwise the user will be disengaged and less likely to come back to use it.  I found that the prototypes that were most complete, needed the least amount of feedback, compared to those which still needed refinement where I was most confused about how it works. In terms of our prototype, although it was complete the feedback we were given suggested that some aspects needed to be further demonstrated in the prototyped. Overall, I think we needed to be a little more specific in what was presented and to not assume that the user will do a particular action or take a particular path.

The most useful piece of feedback we received would have been to include a whole new bar at the top of our page to provide more user functions. This would be used to put a number of different functions that were scatted in other areas on the page together in one location that is central and easier to find for the user. The least useful would have been having a zoom in function. We couldn't really implement this into the paper prototype but were going to implement it already. The exact method to which the markers would be displayed at different zoom levels is going to required some trial and error within the google maps API but we already have a basic idea of what we want.

The paper prototyping was a success and it highlighted some things that we need to remember when implementing. For the next week, we will be starting to implement different aspects including building a database/s, getting the basic html/css done, looking further into the maps API and finalising the trove search articles.