Overview of the Paper

After having the final presentation today, which I think went quite well, the paper has officially come to an end.

Overall, my preferred assessment was the app one, mainly because I am majoring in Visual Communication Design, and designing an app interface really appealed to me. In terms of the second project, I didn't really enjoy it quite as much, although nonetheless it was a good experience figuring out some basics to electronics and breadboarding, along with seeing just what we are capable of. It was quite interesting to think about the potential for future concepts, and what we could experience in a few years time. In terms of our project, the active alarm, I think it was quite successful. Our idea was quite a creative, quirky, and experimental one which allowed us to have a bit of fun with the project.

Our group worked fairly well together across the two projects, and made sure to meet up on a regular basis to discuss and share ideas with one another. In both projects, the workload was split roughly 50/50.

With this being said, overall it was a good experience taking this paper as an elective. In terms of feedback, I would possibly suggest to have a day where the paper is promoted and explained in-depth, as when I signed up for the paper (based on myMassey descriptions) I assumed it would be revolving around web design, app design, and forms of coding etc. 

Powerpoint for Final Presentation

With the final presentation coming up tomorrow, I thought that it would be a lot better and make our design look more professional if we had a powerpoint slideshow to present the class while speaking about our 'active alarm', rather than just talk about it and show the video. Therefore, today in my spare time I decided to make our group a powerpoint, which has a few brief descriptions, bullet points, and a video, which we can explain in more depth during the presentation.

Presentation Video

This afternoon, after finalizing our electronics and bread-boarding circuit, I went back to The Cube and did some filming for our video. I used my mate Fraser Malpas as the 'model', and tried to get some interesting shots to make the video a bit more exciting to watch. The video isn't meant to be completely serious, and is meant to be a bit more playful. I decided not to use any shots of the circuit we had made with bread-boarding, or of the cardboard catapult, as I felt like the video should be showing how our product would be used in a real-life context, considering we have the proof of concept (electronic circuit) and a storyboard to present along with the video. This way, they all do their own part in presenting our conceptual interaction, rather than all showcasing the exact same aspect of the design.

I feel like the video is quite clear in showing exactly what "The Active Alarm" is, and our storyboard then gives a bit more insight into how the electronics actually work.

The video has been attached below:

Following the completion of the video, storyboard, and proof of concept, now we are all set and ready for Friday's presentation. 

Electronics - Fixed

Today we met up in the Fab Lab, to set up our electronics and breadboarding circuit again, to check for any issues. Once we had set it up, it was working perfectly, which meant that the magnet glued to the classroom desk must have been interfering with the reed switch, which was causing it to react weirdly at times. We were glad that there was nothing wrong with the circuit itself, which seemed to be working perfectly today. With that acting as our proof of concept, now all we have to do is make the video before Friday's class/presentation. There are some photos below, attached to this blog post, showing the final set up for our circuit.

   

  

If we were to make this in real life, out alarm clock would consist of a similar set up. However, there would be a couple of small differences. The electronics would still be the same, and reed switches, resistors, magnets and an arduino would still all be used. In terms of the Arduino, instead of requiring a computer or laptop to supply the code, we would use a small Arduino Bootloader to upload the code. The code would consist of having a function which reverses the reed switch, which would cause the alarm to activate once the magnet moves away from the switch (just as we had done in this circuit). With regards to the trigger/catapult itself, we were looking at using some sort of servo, and speeding it up, in order to trigger the catapult. It would be quite small, with a sharp, speedy spring action to shoot the ball across the room.

Printing Storyboard

After I had drawn up each page for our storyboard, Alfred then whipped up a quick storyboard on Photoshop, which we got printed today by one of the University's large format printers. The storyboard is looking pretty good, and explains how the electronic side of our alarm will work.

Tomorrow, we will meet up to set up our circuit once more, and see if the reed switch and magnet/ping pong ball are working properly, seen as in Friday's class there were times where the reed switch would play up. However, we are fairly certain it was because there was a large magnet randomly glued to the table, which may have been interfering with the reed switch.

A video will also be filmed and made for Friday's presentation, which is our final lesson for this paper.

Class - Week Eleven

During class today, we mainly spent the time refining our design, and sharing idea with the other groups, and then finished off by working on our A2 storyboard to be presented next week.

While we were playing around with the circuit, the buzzer and reed switch weren't working 100% as they should, possibly due to loose connections in the breadboard, or another magnetic field affecting the reed switch. Therefore we spent a lot of time trying to resolve this apparent issue.

Towards the end of the lesson, I drew up a few more pages for the storyboard, which we will possibly use for our A2 storyboard. I will look to put these into photoshop and put them all onto one page, which we can then use the large format printers at the university to output. The newest drawings for the storyboard have been attached to the bottom of this blog post.

Over the course of the next week, before our final hand-in, we will look to figure out what was wrong with the circuit, and refine it so it is functioning properly, print out our A2 storyboard, and whip up a video to show how our alarm clock works. 

Independent Work - Proof of Concept (2)

Following on from the previous blog post, once we had sorted out a couple of ways to put the magnet inside of the projectile (in this case, the ping pong ball), I then proceeded to make us a basic cardboard catapult, which would be a simple yet effective way of showing proof of concept for our design. That way when the catapult is loaded, the magnet is touching the reed switch, and the buzzer is making no sound. Once the catapult releases the ball/magnet, the alarm will begin to sound, until the ball returns to the loaded position.

The catapult was made with double layered corrugated cardboard for stability, with the arm being created with a pencil, and then cardboard to hold the ball in place. The tension for the catapult arm was created from a rubber band, which stretched across the width of the structure, and was twisted countless times to increase the tension.

I have attached a video below, showing how the basic catapult structure works. We weren't too focused on the distance the projectile was thrown as this stage, as we were more just looking at showing the effect the magnet has on the reed switch, and using the catapult as extra proof of our conceptual design.

Once I had come up with this catapult design, and created it to a functional standard, we then went on to look at positioning the breadboard and arduino in a way that would allow us to have the ball/magnet touch the reed switch once the catapult had been loaded. Once positioned, I took a video of the catapult in action, which shows the buzzer start sounding once the ball has been fired, and then the sound turns back off once the ball returns to the catapult arm.

We will present this proof of concept in class tomorrow, and see what feedback we get. We will look to refine our storyboard, along with create our short video demonstration early next week, ready for hand-in.

Independent Work - Proof of Concept (1)

Today, we decided to meet up again in order to get our proof of concept ready for tomorrow's class. Having been to JayCar yesterday, we had all of the equipment that we would need to create this circuit. I have attached a photo below of the circuit, which is almost identical to the one created yesterday, although with our own equipment, and a larger, noisier buzzer.

Once we set up this circuit, and uploaded the code from the laptop to the Arduino Mega, we were glad to find out that it was working. Below, is a video of the circuit in action, using just a basic magnet to activate the reed switch.

Next, we proceeded to look at ways of putting a magnet inside of a ping-pong ball, which we were planning on using as proof of concept for our projectile. As shown in the photos below, our ideas were to either put the magnet inside the ball, or cut a hole in the bottom to stick the ball in a secure position.

Attached, is a video showing how the magnet/ball de-activates the buzzer.

Independent Work

At the end of last week's class, we had emailed Fab Lab to ask if we were able to play around with their electronics and breadboarding kits, in order to make a prototype for our buzzer alarm clock idea. After receiving confirmation that it was fine to do so, we went in today at around 1pm to get going on it.

We ended up making the breadboarding circuit, using an Arduino as well, in order to create exactly what we wanted. I have attached a photo of the circuit below. The circuit worked fine, and the buzzer would sound whenever the magnet was away from the reed switch. The magnet would then turn off the sound once placed next to the reed switch. We wanted to buy a larger buzzer from JayCar, as this buzzer was reasonably muted.

After making this circuit, and using some code within the Arduino to get it to work, we ended up heading down to JayCar electronics on Adelaide road to purchase some equipment of our own, so that we would be able to show proof of concept at Friday's class. Stu also let us borrow one of his Arduino Megas, which saved us buying one of them, all we needed was a usb cable to connect it to a laptop.

Research - Catapult

During class today, we continued to think about how we could possibly make this circuit. After figuring out roughly how we are going to make the buzzer turn on and off (through the use of magnets and a reed switch) we decided to look at how to actually make the catapult launch. We looked at existing examples as inspiration, with one in the link below.

https://www.youtube.com/watch?v=WPomwRV0Fyc

In the above link, it shows a catapult that has been made out of cardboard, and uses a breadboard, arduino, and a servo to launch the catapult. This is most likely the approach we are going to take in our design, as it would be an effective way of shooting the ball across the room. We will look to have it so as the ball is placed back onto the catapult, the buzzer turns off (have the reed switch below the catapult to do so).

We will continue to research into different ways that we could create this circuit. By next week, we will look to have prototyped a catapult that works, so that we have a proof of concept. We are also going to look at creating a draft storyboard to present in class.

Research - Reed Switch

After doing some research, we found a video which shows a way that we would be able to get our idea to work. This research came after doing some basic breadboarding, and we wanted to expand our knowledge on this type of circuit.

The video in the link below shows the reed switch in action, with two magnets used to control whether the light turns on or off. The only difference with ours would be that we would use a sound buzzer, rather than an LED light.

The video shows how when one magnet is moved closer to the other magnet/reed switch, the light (in our case buzzer) turns off. This would be perfect for when the magnet in the ball is placed back on top of the alarm clock (which would have the circuit, reed switch, and other magnet inside of it).

http://www.instructables.com/id/Reed-Switch-Reverse-Actuation/

Fab Lab Session

Yesterday we attended the 'Intro to Electronics and Breadboarding' at Fab Lab. We went over the basic circuits that we could make, and were given a small task of making an LED light turn on using the breadboard, and arduino.

After this, we were able to practice on how to make our own idea, which was the buzzing alarm clock. For this, we were looking at using a reed switch, so that the buzzer would be set of when the circuit was moved away from the magnet. We created the circuit, as shown in the photo at the bottom of this blogpost, although the Fab Lab laptop was playing up and didn't seem to process the code, and there wasn't enough time left in the workshop to restart it and try again.

However, we are going to look at putting the circuit and buzzer inside of the alarm clock itself, rather than the ball. That way, the sound will be closer to the person sleeping, as the sound would appear quieter if the noise was in the ball instead, as it would get further away, and could possibly get stuck under something which would muffle the noise.

This circuit acts as almost a 'proof of concept', showing how we are able to set up a circuit to do what we want for our haptic interaction.

Fab Lab - Intro to Electronics and Breadboarding

Last Thursday, Alfred and I attended the "Intro to Fab Lab" workshop at 11am, so that we would have a fair idea of what the Fab Lab offers, and also so we know what we are able to make there, if our project requires us to do so.

We have just signed up for the "Intro to Electronics and Breadboarding", as they kindly added another intro session at 3pm tomorrow (Wednesday). I'm quite excited to go to this intro session, as it will give us a basic idea of how the electronics work etc., which will definitely come in handy for our alarm clock idea, where we will need to try linking up circuits with sounds etc.

User Experience Story Board

Today in class we presented our ideas and the class decided that we should do the alarm clock idea and look to develop and refine it. We did a bit of thinking of how we could have an effective alarm clock which forces the person to get out of bed, so I drew up our storyboard for user experience. I have taken photos from my physical workbook and attached them to this blog post below.
The below image is showing an idea for how our design could be set up. An idea would be for it to be set of by sound or vibration from the alarm clock.

Below, shows the alarm going off at the set time. At this point, our design will be triggered off and the ball launched randomly across the room.

Below, is a drawing showing the ball being launched across the room, which will encourage the user to get up and try to find the ball, in order to stop the alarm. Otherwise the noise will keep going until the ball is returned to the firing dock.

We could look to have the ball making the noise, although the only trouble with that is if it gets launched into a confined area or under something, the noise won't be as loud, and the user could possibly get back to sleep if the noise is muffled. However, another idea would be to make the object that's fired into an irregular shape, that way it doesn't bounce into the same area each time, and it instead can bounce to different locations. These are all factors to look into, and we can weigh out the pros and cons as we look to refine and develop our idea.

Over the next week or so we will look to do some research regarding ways of making this, and how we can go about it's creation. We could also look for existing similar examples, and try to pick out their flaws, so that we can avoid similar flaws, and make a better interaction.

Haptic Interface Ideas

Over the course of the past week, we were given the task of coming up with three potential ideas for our 'haptic' interface ideas, which we would use as our project for this term. We came up with quite a few possible ideas, and then narrowed it down to the three that we felt could be most successful.

Alarm Clock: We were looking at playing around with the interaction with alarm clocks. We had the idea of using a pressure pad, which means you need to stand up and stand on the pressure pad to turn of the alarm, which would encourage you to stand up and get out of bed. Another idea, was to have the alarm trigger the lights in the room, so that as soon as the alarm goes off, the lights in the room turn on. To turn them off, we were thinking of either using a pressure pad (as mentioned earlier), or using a motion sensor which requires you to move to a certain part of the room to turn them off again.

Mouse Glove: This idea, which I feel would be extremely effective, was to use a motion tracking glove to replace a laptop/computer mouse. That way, you still move your hand in the movement you would with an actual mouse, although would work a bit better on uneven surfaces in comparison to a regular mouse. An idea would be to have the user then just tap one finger on the surface to 'click', and swipe two fingers to 'scroll' down the page, similar to how you would operate a laptop trackpad.

Light pads: The third idea that we decided we would present, was a way of replacing light switches in the house. This would incorporate of having a sensor pad in place of the light switch, where you simply just tap the pad to turn it on. We were considering looking at ways to swipe upwards or downwards on the pad to incorporate dimming and ways of changing the light's brightness.

We feel like all three of these ideas are quite strong, and would be exciting to work with and try to develop. We will wait til Friday's session to get feedback from the class and Stu on which ones they think we should go on to develop for this assignment.

Case Study - Good and Bad Interface

For these case studies, we decided to look at different types of interactions, rather than digital ones. We were asked to come up with one good example, as well as one bad example of 'haptic' interactions.

Bad Example (Motion Detection):

My bad example, is of some changing rooms that were at my gym back in Taupo. First you would open a door into a small corridor section, and then open another door into the main changing room. However, the lights didn't have switches, and were instead triggered and turned on when it sensed movement. The reason that I have put this into the bad example category is because of the delay in motion recognition.

Once you stepped foot into the pitch black corridor, you actually had enough time to find your way to the next door, and get inside the changing room before the lights started to flicker and turn on. Although it might not seem overly bad, having just that slight delay is so noticeable, and makes it appear as a bad haptic interaction.

The changing rooms are better off having the motion censored lights in the changing room, to avoid having people forget to turn off the lights. Therefore, less power will be wasted. However, the motion sensor would be a lot better off which a smaller delay, or do have the sensor at the first door rather than in the corridor.

Bad Example (Button):

Another bad example that deserves an honorable mention is the elevator that takes you up to the shop Football Central on Tory Street. Not only do the doors take forever to open and close (extremely slow speed), but there is also an unbelievably long and unnecessary delay when you get to the floor have chosen. As soon as you reach the desired level, the elevator seems to pause for at least 3 seconds, before jarring, and opening the doors at an agonizingly slow speed.


Good Example:

It was quite difficult to decide on a good interaction, as they generally go unnoticed or unappreciated due to their smoothness or efficiency of completing their intended task or action. The example I am going to use is will be the swipe-key system used at The Cube (Massey Accommodation). Each resident has a swipe tag which allows them by simply scanning their tag up against a small black box by the main entrance door. I feel like this interaction is nice and simple, and allows access only to those that stay there.

The small back swipe box detects the tags very easily as well, so even if the key is in your wallet, you can hold it the wallet (open) up against the swipe box and it will detect your key. Once the key is detected, the light on the box turns green, and then the doors open at a good speed.

The swipe tag system is quite a good way of ensuring security in the building, and it can even be manipulated to allow certain tags to access extra areas such as the staff room.

The fact that the swipe tags can be disabled so easily is a good way of ensuring that if a student happens to lose their swipe tag, the tag can just be disabled so that whoever picks up the key is unable to use it to get into the building.
Much like digital interactions, it seems a lot easier to notice the bad interactions, such as slow doors opening, light switch delays, or sensors not detecting movement in general. It's because we expect them to be efficient enough to allow us to continue on with our daily tasks without any bother, so as soon as we run into a bad interaction, it's easy to notice. In a way, the good interactions are those that go unnoticed; the ones that happen so smoothly and unconsciously that we don't even bat an eyelid.

Project Two

Following the final presentations today, we were introduced to what our next assessment would be. The blog posts from now on (above this post) will be for assignment two. The posts that can be found below this post are the blog posts for assignment one.

Final App

Follow the link to find our final app...

http://invis.io/CH2OWD6NE

Note: Follow the path of... Drink - Alcohol - (any 500m Bar)
This will ensure that you see what the end result will look like.With our final presentation next Friday, we decided to meet up today in order to get it finished comfortably before hand-in. We made some slight changes to a couple of screens. The biggest change, was the change in layout for the "Suggestion page" which shows all of our suggestions in relation to the proximity of each location. Another small change we made was the feature of clicking on the map (on each final page) which then zooms it in slightly. We were going to look at getting the map to move as the user moved it, and zoom as they use the pinch and expand technique, although there were no features on inVision to do so, so we just stuck to a basic zoom. Some of our screens have been attached below.

Overall, I am extremely pleased with the final outcome of this interface design. We got a lot of good feedback in the final class critique, and we have developed it further, so I feel like it is at an even more refined level than it was before. It was interesting to see exactly how useful the paper prototyping was initially, as it allowed us to quickly mock up our initial concepts, without putting too much effort into designing it digitally. The introduction to inVision then made this all so much easier. InVision offered an extremely quick and effective way to prototype our interface deign digitally, as well as output the prototype onto our intended device (iPhone 6). The continuity in terms of theme, and screen transitions (with the left and right pushes) is a successful and effective way of helping with the user interaction. The pushes help to show whether the user is in fact going forwards to the next screen, or going backwards to the previous screen. The colour scheme is very simple, yet effective. Each button has been created so that it looks like it is meant to be pressed, in order to make the experience easier for the user. Another way of making the process easier for the user, was to shorten the number of interactions required to reach the intended final result. We did this by removing a few filters, and having slightly more options on the proximity screen. This was done as the proximity of each location is actually a really important part of our app, as it is about finding places in Wellington close to where the user is. On the proximity screen (as seen in the 500m zone for Alcoholic Drinks), we have included the logo of bars in that proximity, making it easier for the user to identify the differences between each button. We only did it for a few, by making a specific pathway for the user in this prototype, as this allows a clear indication of how the final app would operate, without going through and making a whole heap of extra screens, which overall convey the same message of how the app works. In terms of group work, I feel like we both contributed a relatively even amount to the project, and we both shared similar idea on how our final app should look right from the start of the project. We found it quite easy to agree on each others ideas, although we weren't afraid to point out potential flaws, and find ways to avoid these possible obstacles. Both of us were very effective at managing our time, and we made sure we had all of the required work ready for each class. By meeting up regularly in order to discuss the app, as well as sharing files via dropbox, it made the whole project a lot easier and more successful. I have really enjoyed this paper so far, in terms of learning about user interaction with different interfaces, and it is crazy to see easy it is to notice bad interfaces now, whenever I am online or on a different app. I am looking forward to the final presentation next Friday, as it will not only be exciting to share our own app with the class, but it will be interesting to see how the other apps from the rest of the class have turned out. Now that this project is completed, I am interested to see our brief for the next project, and start coming with ideas for my next project.

App Development

Following the critique last Friday, and even though we don't have class tomorrow as it's Easter Friday, Alfred and I decided to meet up and work on developing our app, so that we are finished nice and early in advance of the hand-in and final presentation.
We met in the university library, to develop our app based on feedback gained. Because of the positive feedback on the layout, colour scheme, and nice continuity throughout, we kept this the same. A couple of changes we made, consisted of reducing the number of interactions required to reach the final outcome. Therefore, we had it go from the search button straight to "food, drink or entertainment", and then from there, there was only one more filter used to narrow down the searches. We made a screen (which has been pasted below) which shows the new screens we have made. 

Instead of having the screen with just 3 choices, we made a screen which gives slightly more choices, based on proximity to the user. That way the user can make the decision of how far they want to go, while making the selection, rather than having a whole different screen to filter down the distance. 


The final screen has changed as well, which instead of giving a whole screen of information and an image, it now gives some basic details about the place, as well as a map with how to get there from your current location.


I feel like this development has improved our app greatly, by making it a lot quicker and easier for the user, as well as maintaining the good continuity in colour scheme and template as we already had.

We will look to meet up again before the final presentation and hand-in, so that we can find aspects which require further refinement and then refine them before the hand-in, so that the app is as good as it can be.
The link to the app hasn't been shared on this blog as we are still editting it further, so I will just post the final link in my final app design blog post.

Class Feedback

Today in class, we all had another sharing lesson, where we would go around and experiment with everyone's interfaces and give them feedback, in turn receiving some valuable feedback of our own. I decided to stay and get the feedback, since I had done most of the preparation of this prototyped interface, while Alfred went around to critique other apps. I have attached an image with our feedback below.

In the above image, is the notes that I took based on our feedback from the class, as well as Stu. The majority of the feedback was positive, with every single user saying that they found it easy to navigate, and it was simple where they had to go to reach the final outcome. A few sad that it was really logical, that they liked the colour scheme, and that it was looking really nice and refined. One of the key aspects seemed to be the ease of user interaction and navigation, as well as the design aesthetics and flow. Earlier in the lesson Stu had spoken about making sure the interface has a consistent feel in the colours, layout etc, and I felt like ours was very successful and effective in each of these. Stu's feedback, which is overall the most important feedback to acknowledge due to his experience with user interaction design, was very helpful. He did say that it was easy to navigate and use, and that he liked the consistency in the layout. There were a few suggestions, such as the "indoors" icon since it is so similar to the icon which is so often used for a "home" button. His other idea, since proximity of destinations is such a key factor within our interface idea, was to include this a lot earlier in the interaction stage. I have included a photo of his rough sketches of what to do below. Basically, he wanted it to go from the search screen, to allow location, to the 'casual, active, family' screen, then to the 'food, drink, entertainment', and then to another screen which shows their relative proximity to the user. It could be created in such a way that we can continue the use of our circle theme, and use these to show the distance each destination is in relation to the user. 

Our final hand-in presentation has been postponed to Week 7, the first week back from the holidays, since our next class would have fallen on Easter Friday, a public holiday. However, Alfred and I will make sure that we meet up regularly in order to keep discussing the development of our design, so we can continue to refine our interface until the final presentation. I will keep this blog updated with our progress.

Preparing an Invision Prototype

After meeting up yesterday, Alfred still had quite a bit of work to do for his VCD studio class, and since I had already finished my VCD work, I decided that I would take charge of this and continue to work on the app design. So I spent a few hours finishing the screens on Photoshop, planning out what our activity suggestions were, and then finally created an InVision prototype.The link to this prototype can be found here: http://invis.io/NW2JG4S7Z 

The above screens show pretty much all of the screens, most of which I individually created in Photoshop today while Alfred was catching up with VCD. I felt like there was quite a nice, consistent flow in terms of colour, along with the general layout, since we followed a set template. I feel that individually, it appears quite easy to navigate around, as we have given the user limited options to choose from, which quickly filter down their options to a few suggested destinations.

In the photo directly above, I have attached a screenshot from inside of InVision. This was once I was working out all of the hotspots for each screen, and begining to link them all together. Below, I have shown the screen that follows the one above. So once the user clicks on an activity, it has a page with a photo, the name, and some general information or background about that destination. Right at the bottom, within easy reach of the users thumb, is the "Go To Map" button, which will link them through to Google Maps, allowing the user to then find directions to get to their intended destination. I only made one of the paths lead all the way to the final suggestions, while all of the other links lead to the second to last page. The path to follow to get here is Entertainment - Indoor - Casual. 

 Below, I have attached a photo of part of my physical workbook, where I planned out all of the different options that the user could follow, and worked out suitable destinations in accordance. That way, if we decided to make the app completely, we would have a list of places to include in the final suggestions.

Research of Existing Apps

Today, towards the end of the class, we were given some time to go through and look at some existing apps, as well as download a few to try them out, and see exactly what was good and bad with their interfaces, so we could both gather some effective ideas, and also know what sorts of interface designs to avoid. A few that we looked at online have been attached to this blog post below.

Most of them, although being quite easy to navigate, just started off with a whole set of categories to choose from, rather than just using a couple to narrow down the options. The second one down, "Here U Go" is one that Alfred and I downloaded, and it was extremely poorly designed. Not only does it look bad aesthetically, it's also not very well designed in terms of layout. As you can see in the screenshot below, it shows the large, large list of categories that there are available. To make things worse, it has been placed in alphabetical order. By doing this, it makes it extremely difficult to navigate, as some things might be called something else and put under a different letter. For example, you might be looking for "Mechanics", when it has been placed under "A" for "Auto Repair", which leaves it relatively far away from where you were looking.

Another one that we analysed, although was downloaded on Alfred's phone (as he switched his iTunes account to U.S to download), so I don't have any screenshots of it, was an app which allows the user to choose their activity based on how they were feeling. There were a few different options such as "lively", "classy", and "whatever". Once you clicked on how you were feeling, it generated a list of all sorts of places and activities that applied to how you were feeling when searching. We felt that an idea similar to this would be quite handy to use or develop when we come to developing our own interface.

Most of the screenshots below are from android apps, although each of them show that there is no real point where they begin with only a couple of options, all of them seem to have heaps of choices to make right at the beginning. We are going to make sure that we begin with only a limited number of choices at the beginning of our app in order to try and make it more successful than all of these ones below. Another aspect of the below apps are that they take quite a few steps to get to the end result, so we will also try and make it so our app can go from start to finish in between 3 and 5 interactions if possible.

Right at the end of the class, we began sketching a few more ideas on how we could layout our interface, and had another small discussion with Stu on our newer ideas. He gave some more feedback on how to develop and simplify these even further, so we will definitely take these into strong consideration when creating our next InVision prototype. By next week, we have been asked to create another InVision prototype, although this time it is to be created digitally rather than drawn and transferred onto the computer.

Below is the page of our sketches with some ideas for certain screens in our new layout.

Feedback on Prototype

Today in class we had our class feedback session to go over our apps. It was strange seeing how different it is for people to navigate the app if they have never used it before. Pretty much the main piece of feedback was to simply the app, so there aren't so many things on the screen at any one time. That way it will be more obvious to the user as to what they should press. I could probably get rid of the saved, and planned features altogether, although if I keep them, I'll definitely combine them into just one, as they practically serve the same purpose and was a bit confusing.

On the home screen, possibly have the question straight away of "What do you want to do?", so that the user is immediately taken to where they need to be, making their interaction a lot easier. The loading page could have the logo come up, and then once it has loaded have the "What do you want to do?" appear. From there, I will make sure each page only has a certain amount of options for the users to choose from.

Stu suggested that the aim is so make the app have the least number of interactions as possible, so that there is no struggle in the user getting to the final interaction, as you don't want them getting confused or lost along the way. He also told us how the interface should almost be like a cone, so at the very beginning of the app, in the first few interactions, there should only be a couple of options that the user must choose from to avoid confusion, and then as the interactions continue you can have the freedom to expand slightly more.

A few people commented saying that my layout of my prototype was quite good, yet I realised that the fact that we hadn't confirmed all of the categories, made it a lot harder for them to navigate, as they didn't know what was going to be in place of each of the icons.

However, now that Alfred and I had designed them separately, it allows us to take the best aspects from each, and combine them, as well as continue to develop these further in time for hand-in. I will keep my blog updated with how the development is going, and will continue to show what stages of the design process we are up to. I am looking forward to getting into designing the actual aesthetics of the interface as well, as we will be able to use the digital advantages to improve user interaction. For example, we can then make the buttons look like they are actually buttons with bevels or shadows etc.

Independent Group Work

Today, Alfred and I met in the library to get some work done by Friday's class. Initially, we sat down and started to clarify what exactly we were going to do in terms of getting the user from the beginning to the end as easily as possible. Once we had this sorted, we began to work on a few screens on Adobe Photoshop, that we would eventually insert into InVision. We made sure to set up a template that we would follow for each screen, as well as a set colour palette to follow throughout the entire app prototype. We got a few screens up and running, although I will work on the rest tomorrow and whip up an InVision prototype.

InVision Protoype - Drawings

Today I got to experiment with the program InVision that we were introduced to. I was really excited to get into using this program, as I saw how easy it made app design, and I was excited about the fact that we could actually make our own functioning app via this software. So I ended up drawing up each of the pages for my interface, so that I could take photos of these and then insert them into InVision via their Drag and Drop feature.
Alfred and I decided to create one InVision prototype each, so that way we have two different layouts and concepts that we can use as inspiration. By doing this, it will also allow us to see each others ideas on how to create this interface, and then take the best ideas or aspects from each, and use these when it comes to the development of our interface.
Below are photos of the drawings that were in my physical workbook. For the InVision prototype, I took photos of each drawing individually so that I could have one per screen, and then create the links between each page. 

So once I had drawn up each interface, I decided to create an account on InVision and give it a go. I quickly watched the two recommended videos on the basics of InVision. Once I got into making my own, I realised just how easy it really is to use, and to create your own fully functioning interface. I also noticed a lot of cool features that we could add when we get into making our proper prototype, rather than just this paper prototype.

I'm really happy with how this initial drawn prototype turned out, and I'm looking forward to developing it and seeing just how far we can develop this idea into a final output.

Here is the link to access my drawn InVision prototype...

http://invis.io/H92HA3PFB

Class Work

In class today, we went around the class and each group of 2 discussed their 3 ideas that they had come up with for a potential interface design. Out of our three, Stu preferred the ones that experimented more with the use of geo-location on smart phones, and thought that this would give us more freedom to expand and experiment on.

Alfred and I thought that experimenting with geo-location would be new and exciting, so we ended up deciding to go with our 'Wellington Activity Planner', which gives the users all the information required to find all sorts of cool places to go, and activities to do in the Wellington region. In class, we were asked to come up with a list of interactions that are required to get the user to the end result. Our interface will be for smart phones, which allows us to find the users location. Our initial ideas for this were as follows...

1 - Unlock phone
2 - Click to open the app
3 - User will be asked to allow access to their location (first time only)
4 - Pick a category (e.g: walks, shops, food, live events)
5 - Choose basic or advanced search (advanced takes user to a set of questions which allows them to narrow down their options based on a series of factors)
6 - User will receive a list of recommended places or activities
7 - Choose place or activity
8 - User will be given information and pinpointed on Google Maps

We also discussed the possibility of a few other features...

"Save" - This would be an option that appears once the journey has been planned, and gives the user the chance to access this journey at a later date without needing to repeat the process of answering questions and re-finding their event or activity. The saved section would appear when the app opens, alongside a "New" button.

"Add" - We thought that when the list of activities come up, we could add a little plus button which allows the user to add the journey to a 'to do list' or 'favourites' section. This would allow them to then go to the 'Planned' section at the very start and see which events they had previously planned on doing.

We started drawing up a few ideas of how the interface and layout could look, and we both felt that this interface idea would develop very nicely, and we both continued to think of extra ideas to develop the app.

By next week, we were asked to draw up some layout ideas in a sequential order, and then go onto the 'In Vision' site that we were introduced to at the end of class. Stu asked us to have a mock-up interface made on there by next class.

'Gruesome Fish' - And Brainstorms

Alfred and I decided to call our group "Gruesome Fish", as this was one of the names that appeared in a random name generator we found on Google. We were asked to come up with a couple of ideas for our interface design. A couple of our ideas are as follows...

1 - Football Coaching App: Having been an employed coach for over a year, there was always a bit of time that you needed to spend before each training planning the training with exactly what drills you will do, how long they will be for, what equipment is needed, and then also what the intended learning outcomes are. This was always done by either writing it down on computer, or creating a template on photoshop and filling it out on there.

We had the idea that we could create an App for phones or tablets, which allows coaches to plan their training on there phone via simple drag and drop functions. There was a possibility to have different categories for drills, such as passing, shooting, movement etc, and then even further narrow them down into other factors such as players needed per drill, equipment needed, and also the difficulty level of each. For game days, when it came to choosing your squad, we were also thinking of having a extra section to cater for this, so you can simply drag and drop players and move them between the field and the bench, or even into the reserves squad. These were just our initial ideas, and we will look to further expand on these as we go to narrow down to one idea.

2 - Wellington Activity Planner: Having realised exactly how much there is to do in Wellington, and realising how little people know about all of these activities made me realise that this would be a very good interface to pursue.

We were planning on using this interface in order to let users plan out what activities they would like to do in Wellington. Initial ideas consisted of getting the user to select a certain icon on a home screen, each icon representing a different category, such as food, shopping, sports, entertainment, and so on. From there, we thought that it would be neat to have a section that allows the user to type in some more answers to narrow down the options that appear, such as price they're willing to pay, how long they have to do the activity, and also what means of transport they have available. Once the list appears, after inputting some details, the user can choose an activity, and find out all the details about the place, while also being directed to a page with Google Maps embedded.

3 - Live Venue Finder: For this idea, we realised that many people are unaware of just how many live events, shows and concerts are on offer in Wellington, so we decided to brainstorm this as an idea for our interface design.

What we were looking at, was an app that uses the users location to find out where exactly they are, and give them updates on events or shows that are close to them, and what times they are on, who is performing, as well as the prices of each. We were thinking of doing it just for Wellington, although it would be better in terms of expanding our target audience if we did it for all of New Zealand. This wouldn't be too much harder, as it would still be using the location finder on smart phones to find the users location, and then give them details and information accordingly.

Paper Prototyping

Today in class we had our presentation of our case studies, which involved choosing one good interface, and one interface that we found bad, or not quite as user friendly. The two that I presented were News Now (good) and Sky GO (bad). 

After the hour and a half of presentations, we went off individually and did a bit of paper prototyping with the bad interface that we had selected. So I was required to draw up some paper prototypes for the Sky GO wesbite. Tim asked me to draw up the process that you would have to go through to "see what was on Cartoon Network at 4pm tomorrow (Saturday)". So I quickly drew up a couple of pages in a prototype fashion, showing the main labels and layout, and identifying where the user would have to click in order to get there. This was to see if there were any issues in terms of needing to click in a whole bunch of different areas to get to the channel listings. The paper prototypes can be seen below.

In the first photo, it shows the two points in which you can click, to get to the page which shows the tv guide.

In the second photo, it shows where you need to click (10 times in fact) until you find Cartoon Network. You could also click the "left arrow" once, although users tend to click on the right arrow first, and they would be unaware that Cartoon Network is in fact on the left hand side of BBC.

In this last photo, I have circled the section in which it tells you the time, although as indicated, once you come to this page you need to scroll down to find the time, as it has listings for the full 24 hours.

Along with this, we were then asked to decide how we would make this task slightly easier. My idea would be to introduce a sliding bar into the section where you choose which channel you would like to watch. This would allow easier user interaction, being abel to quickly slide between channels, rather than needing to click the arrows multiple times to try and find the channel you are after.

At the end of the session, we were randomly split into pairs, in which we will spend the remainder of this term in, and we will work with one another on this interface project. I was paired up with Alfred Hoi.

Over the next week, we have been asked to come to do one reading on paper prototyping, which can be found on stream, and also think of a minimum of 3 different scenarios that we could design an interface for. We stayed for a bit longer after class in order to come up with a wide range of ideas for our interface, and decided that we would try to think of a few more over the course of the next week as well.

Case Study Two - A Good Interface

For my second case study, I have chosen to use a website that I refer to multiple times on a daily basis. One of the reason's that I consistently use it, is because it is easy to navigate, and has many good features about it. This website is a news source website known as "News Now", and I always use to it keep up to date with all of the latest football gossip. However, it also has news sources on a large range of worldwide events and issues, along with current events for each country, and doesn't just focus on the sporting industry. In this case study, I'm going to go through and name all of the features that make me continue to use this website, rather than jumping ship and looking for another, more effective source of news.

The screenshots I have taken for this case study have been taken from http://www.newsnow.co.uk/h/Sport/Football/Premier+League/Chelsea.

Firsty, although the layout isn't the most appealing (a screenshot is shown below), the functional aspects of the site is very, very good. For a starter, as we generally read right to left and top to bottom, it makes sense to have the "News Now" logo in the very top left hand corner. It's been linked so that if you click on the logo, it takes you back to the News Now Homepage. It is easy to be aware of the fact that you can click on the logo, as the cursor shape changes to a hand icon with a pointed finger, indicating that it is 'clickable'.

Below that, as you can see in the screenshot, is a row which shows all of the sub-categories that have been accessed in order to get to the page you are currently on. So for example, in the screenshot I am searching for news about "Chelsea" (an English football team). They play in the Premier League (hence the sub-category just before 'Chelsea'), they play Football, and Football is a Sport. If I wanted to go and look at news related to football as a whole, it's as simple as clicking on the label "Football". When you hover the mouse of it, the cursor again changes to a hand symbol, while the label itself becomes underlines, a further indication that a click of the mouse will take you there.

On the left, I have inserted another screenshot, of the side bar on the left hand side. It is a very well designed interface, as it has an option to search for keywords, along with search via the drop down menus. Below the search bar, are the labels from the top of the page (the sub-categories) in a drop down form. This is extremely helpful as if I want to go read about another team in the Premier League, rather than click on the 'Premier League' label at the top, and then find the team on that new page, I can do it all in one go, by hovering the mouse over the 'Premier League' label on the left hand side bar, and then the drop down menu will come up with a selection of all of the teams.

Along with that, if you would like to narrow your search down to subcategories within 'Chelsea' such as 'Injuries and Suspensions' or 'Transfer News', you can do so via the side bar menu. Further sub-categories can be accessed by the drop down menus in tabs such as 'Midfielders' which then lets you choose exactly which football player you would like to read about. The drop down menu has also been well-designed so as you move your cursor over to it, you have plenty of time to highlight the category you want, as some poorly designed sites have drop down menus which disappear before you can even move your mouse to where you want. Again, the cursor turns into a hand, while the label that you are hovering on top of turns blue with white, underlined writing, making your selection extremely obvious. The left hand side bar is one of the features that I use the most in order to navigate my way between different news sources.

In the above screenshot, is another feature that I really like. When you click to
 read an article, it automatically opens that article in another tab, rather than in the one you are currently using. That way you don't need to keep on going back once you have finished reading the article, and you can also have multiple articles loading simultaneously this way. Once you have opened an article, the title of the article on the main 'News Now' page will turn to a green colour, indicating that you have previously opened this link. This feature is very helpful when I am reading a lot of articles in a day, as if I come back to the site later on in the day, I can easily see which articles I have already read, and which ones I am yet to read so far.

On the left hand side, is a snippet of the right hand side of the website. Another toolbar. In this section, it shows you the most read stories from the last 24 hours, along with the previous top stories. I really like this, as if I haven't been on the site in a day or two, I can easily look down into these two columns and see which articles are recommended to catch up on and read. When you go to click on a link, the cursor again turns to a hand, and the text becomes underlined. Below each article, it says the name of the source, so you can choose functions such as 'hide publication', if it's one that you don't necessarily want to see continuously popping up. If you go to click on that link, the text turns red, and also becomes underlined.

Again, the link then turns blue once you have opened it, to indicate that you have already opened that link.

On the left hand side, is a screenshot of another section of the page. This is located just below the sections "Top Stories" and "Previous Top Stories"

This has been designed to show the stories in which you have most recently read. This is helpful in case you are looking to find the article again, yet it has disappeared off of the main home page. This section shows the 10 most recent, and there is an option to get rid of these, if you don't want the page to show them. To do so, you click on the red cross on the right hand side of the article.

Last but not least, I want to talk about another smaller functions in the thin screenshot above. This is at the very bottom of the page. There are a few links that you can click in order to contact News Now, subscribe to their articles, and various other options like that. However, there is also a feature that they have incorporated which auto-refreshes the page every few minutes, and the timer down the bottom tells you how long is left until the next auto-refresh. I find this helpful, in certain circumstances like on transfer deadline day, when there is only a few minutes left of the transfer market, and you are dying to see if your club signs any new players. The auto-refresh refreshes the page and brings you the latest batch of news every couple of minutes without the click of a button, so it can continuously reel in more news, even while you only have the tab open in the background.

Another aspect that I like about this site, is the variety that it sources to the public. It gives the reader multiple choices of which article they would like to read, and notifies them of which website it has come from. I find this helpful as some sites, such as 'Daily Mail' and 'Sky Sports' for instance, are more reliable than 'Vanguaard' from over in Nigeria.

So overall, due to the extremely good functional qualities of this site, I continue to use it to keep me up to date with the most recent football news. If the interaction wasn't as positive, I am sure that I would look elsewhere for a better functioning site. This goes to show that the ease of interaction is a key part of a users experience, and plays a big part in their decision of whether or not they want to continue using this interface. In all honesty, good interface designs almost make you return to them without consciously thinking "I'm going to use this interface because it's very functional'. However, a poorly functioning interface immediately makes you blame the difficulty of use, and poor interface design for your bad experience. By creating a case study on this interface, it has actually make me consciously aware of how good it really is.