None the less, the first chapter is about creating ideas for your project. It talks about the importance of brainstorming to get your project started and how it should be done most efficient. Something I noted though, is that the book says the brainstorming should not be made in words, but by sketches. Why is this? And why did we not follow this in the course? In our exercise we brainstormed ideas by writing them down. Another approach of ideation is what the book calls brainwriting which we also did during the exercise, though we called it something else. The idea is that someone starts with a basic idea, and then pass it on to the next person in the group that add something to it, and then pass it on. By keeping this chain going the idea will grow from something basic to a more detailed idea with the help of the whole group.
Chapter 6 also mentioned how to later try to filter out some ideas that might not work. This can be done by creating design principles, which is a sort of requirements that the ideas must pass to be accepted. In our project this was not as important since we did not have a many ideas to start with to filter out. But we did manage to eliminate some of them with the principles. For example when looking at the user group as an requirement we concluded that the GPS idea (as mentioned in previous blog posts) were really not intended for our user group and hence more or less discarded.
Chapter 7 goes deeper into the refining of your ideas. Some constraints are suggested to further filter out some of your ideas. But what would normally be the biggest constraints in a real project; time, money and technology we have all been told to not focus so much on, as long as the project is not completely unfeasible.
For the matter of direct or indirect manipulation our project has a very simple interface and will only use direct manipulation. The user will hear a sound and then press the screen which he think the sound came from. It does not get much more direct than that. Instead the biggest problem we will have to solve is that of affordances, how will we make it visually obvious how to use our sound room? While the idea is really simple, to push the screen you hear a sound from, a screen do not have the regular indicator that it is a button. This is something we have discussed a lot but still not found a good solution to.
Another thing that is mentioned in the literature which has played a big part of our project is the matter of feedback. We concluded early in our project, during the museum visit, that the feedback in a lot of their stations was very poor. Some simply because of slow computers, but others because of design. The book describe the delay between user input and the device output as latency and divides it in four stages, going from immediate (0.1s) to disruption (over 10s). One of the games I played at the museum made you answer a question and if you answered correctly a text block with information would pop up that you were expected to read. To ensure that the user would actually read it, the station locks, making you unable to press any buttons for as long as it would take to read it, hence creating an disruption. This was a big deal to us and we put it as one of our pain-points and decided our sound room should always have immediate feedback.
Because our project is so simple in practice, a lot of the laws mentioned in the book will not actually be relevant for us. For example Fitt´s Laws describe how buttons should look and be placed in a graphical user interface, making them easy to target and click. But the only "buttons" we will have are the actual screens with the animals. Hick´s law and the magic number seven describe the best way for a program to handle the presentation of multiple choices, as well as never having more than seven elements to keep track on. Again, in our sound room this will never be a problem.
The Poka-Yoke principle states that you should stop anything that can go wrong as early as possible (if you can not stop it from happening to begin with). However there is not much that can go wrong in our game. The worst case scenario is that the user do not understand how to start the game and play it. Concerning the start of the game we have had some discussions in the group of what kind of controls would be best used for this. Some people have suggested a button, while I am suggesting that it should be automated by motion sensors. My reasoning is that automating the process eliminates one thing that can go wrong (above principle), that the user do not understand he should press the button to start, or he might not even see it. I have tried to motivate the use of sensors with Poka-Yoke as well as Tesler´s Law of the Conservation of Complexity which states that it is good to move complexity from the user to the system to make it easier for them.
During our last meeting we realized there were a lot of details that we had not discussed yet for how the game is going to run. What happens if a kid hits the right screen? What happens if a kid hits the wrong screen? What happens if he does nothing at all? As to not miss any steps I decided to create a Task flow to simulate everything that can happen during a run, how the program should react to it, and what happens when it does. This is not a final product, but rather to be used as an overview of the system while working on it. I think it will help a lot.
The last chapter is about prototyping, something we are just about to start in our group. As we are aiming for as little text information as possible we will instead use sound effects and animations. The book gives a warning when using sound effects, that the user might grow tired or even annoyed of them after hearing them too many times. But this is more of an issue for a program that the user will use for a long period.
At the moment we are planning to do a low fidelity Wizard of oz manipulation. Meaning that we will simulate the finished product by manually controlling the prototype. We will use big posters with the printed animals on them and place them in a circle to "create" our sound room. The members of the group will then stand behind the posters, ready to play the sound (with a mobile) of the animal, as well as a happy or sad sound to give feedback whether they pressed the correct screen. Our hope is that the use of this together with a test group will get us answers to some questions that we have not been able to agree on, such as the starting of the game.
No comments:
Post a Comment