For the food assignment I want to create an application that allows users to flip pancakes. A timer would count down letting the user know how long to cook each side of the pancake, they would need to flip the pancakes by flipping their wrist that’s holding the phone, which will be detected through the phones accelerometer. If the user were to burn the pancake they would loose. When each pancake is completely cooked they would slide it off the pan by shaking the phone, and would then pour a new pancake on the pan by using their finger to draw on the batter. They would then repeat this process. The more pancakes they cook, the hotter the pan becomes and the faster they have to flip the pancakes before they become burnt.
Reading HIG was useful and brought up a lot of things that I never noticed before, like the fact that iOS applications never display a close or quit option. I suppose it was always just second nature but reading the text allowed me to think more intently about the interactions I am designing for the users. When reading HIG one of the things that stood out to me was to avoid a splash screen when creating an application. In designing applications I always questioned if it would be a nice way to introduce a person to your application or if it was superfluous. It makes sense to avoid the screen in order to allow users to get to an application as fast as possible without being hindered by seeing another image, but previously I thought of it as a branding opportunity to show the users your logo once again.
However, this ties in with another thing I read in HIG and that was to resist showing your logo on screen, because the screens are small and you don’t want to take any of the real estate away from the interaction. This makes sense when you acknowledge that the users know what app they are in, because they tapped the icon to open it, and similarly they wont need to see the splash screen because they are aware of which app they are clicking when they tap the icon. It also suggests that if we do use a splash screen it should be very similar to the first view we see in the application so the user has the feeling that the application runs quickly.
Another good tip is to delay a login requirement as long as possible, often times users are deterred from applications that require them to log-in so if we prompt them with a log-in in the beginning they may never give the application a chance. It is better to allow majority of the users access to using the parts of the application that do not require a log in, and then prompt them with an area to log in once they need to.