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.