Android - Designing Cross-Platform 2D Games

From CS1635 Spring 2016
Jump to: navigation, search


Readings (no need to submit critiques)

Reading Critiques

Robert Webb 21:29:46 2/9/2016

I liked the walkthrough questions. I liked how it let me think critically about what I want to observed when I'm imagining a user using an app. I also appreciated the failures stories - they do a good job of going through whatever issues there are that come up frequently and what is wrong about them. I liked how they cognitively evaluated tasks and they managed to come up with good criticism

Michael Oles 14:27:29 2/11/2016

I think this reading will be very useful for our group project. We can basically use this as a guide when making our prototypes. I think the idea that every action even if it is very small needs to give the user feedback is important for us to use.I also think that it was important to realize we should not spend all of our time in detailed comparisons for things that do not have that much of a payoff in the actual app. The nine heuristics seem like a very good idea but at the same time things like preventing errors are obviously important but may not be easy to implement.

Charlotte Chen 23:58:09 2/13/2016

The article provides three approaches to evaluating interfaces without the presence of an user: cognitive, action, and heuristic. I feel like most interface designer will utilize the cognitive approach with or without realizing, which requires them to stand in the shoes of the user and think about how they will respond to the interface. I really like the questions the article has in each section that gets the reading. For example for cognitive approach, we have to imagine will users will be able to immediately see a button, and even if they see it, will they be able to recognize the effect it'll produce. I think the cognitive approach is necessary but also not the most thorough, since the person imagining themselves as the users are also designers of the interface, therefore they might have prejudice or bias and omit a lot of confusing elements in the design. I find the action approach to ask much more in depth questions and focus more on actions/sequences, which will force the designer to thinking of each step the user must take in order to complete one task. The heuristic approach is a lot more rigid but nonetheless effective since it replies on past experiences and mass knowledge. For example, in class we talked about "Provide Feedback" that is mentioned in this section, therefore it is an obvious guideline that almost all interface design should follow. Overall, during the designing and first testing stage of interface design, I think all three approaches are not extremely time consuming, therefore will all be sufficient in aiding the design of good user interfaces.

Joshua Fisher 11:38:08 2/15/2016

The readings on 2D Games was interesting. I am assuming our third assignment will be to create a 2D Game, so these documents will be useful when we start to program the games. Installing the required software seems rather difficult for Android Studio because you have to follow the instructions for setting up for Android through the terminal (since there is no specific "Android Studio" instructions. Hopefully we will go over the basics of installation in class so that everyone has a general idea of how to do it. Another difficulty is that the basic concepts show code examples for C++ and Javascript, so are these the only two languages we can use?

Tiffany Martrano 13:04:12 2/15/2016

The reading we had to do for today focused on things we talked about the previous lecture in class, which is Qualitative Evaluations. I thought that this approch of designing was interesting because it focused from the developers point of view rather than a user. It was a nice change of pace from the user oriented programming that we had been talking about for the majority of the class. I liked having a different perspective, and it's interesting to see how I can use methods from user oriented designing and non user oriented designing to make an appealing application.

Alex LaFroscia 18:40:58 2/15/2016

I thought that the mention in the reading about making sure controls are visible and obvious was very interesting, especially in light of some of the changes to mobile operating systems in recent years. Specifically in the recent versions of iOS, controls have begun looking more and more like labels as they lose their borders, depth, background and shadows. For people unfamiliar with the system, it's hard to know when something can be clicked on and when it can't, unless you have a lot of context about where you are now and where the app can take you. If you're a new user, or not technically inclined, this can be really hard to figure out. Another issue is knowing when a button does what you're looking to do. iOS 8 and 9 have introduced a sharing icon that is not exactly obvious, and Apple allows developers to integrate their own actions into this menu. For example, if I want to share a website with a friend, I can choose the Sharing menu and then the Messages app to send it to them. While the sharing menu may not be obvious at first, at least once I get used to that button I can associate it with sharing the content that is currently active. However, what if I want to bookmark a page? Sharing icon. Translate a Tweet? Sharing icon. What about sharing an email, forwarding it to someone else or saving it for later? No sharing icon available. Not only is the icon unclear, it's also inconsistent, which is greatly surprising to such a design-oriented company.

Luke Kljucaric 20:27:39 2/15/2016

The readings seem like a good read on how we should go about analyzing our interfaces for the apps we are creating. We need to realize we won't have the user available for feedback on the interface we design. If we use the techniques such as cognitive walkthroughs, action analysis, and heuristic analysis, we can refine the problems with our interface to make the user experience much better. However, implementing all of these techniques require a lot of time so we need a good balance between being able to find the necessary problems while not taking an eternity trying to find them all. I agree with the reading that the suggest to use the cognitive walkthrough method and potentially using heuristic analysis to uncover some additional problems as well. Overall, we need to please the user because if the user isn't happy using the app then no one will want to use it so focusing on fixing potential pitfalls of our interface design will prove very beneficial.

Matthew Reinhold 21:03:14 2/15/2016

The information regarding what sorts of problems to look out for during a walkthrough wasn't too eye opening by itself, but it was helpful. The particular hints that it brings up are pretty basic things to look out for in general, but are also quite forgettable since you most likely have knowledge about how every part of your design works. The information worked fantastically as a reminder on how to check your own work from another point of view.

John Phillips 21:29:10 2/15/2016

The reading covered ways to evaluate design without users, presenting methods for cognitive walkthroughs, action analysis, and heuristic evaluation. The main goal in all of these is to be able to find initial bugs cheaper and quicker than using actual users. However, the normal problem with this is that people instinctively think designs they make are clear even when they may only be clear to themselves. The goal of these methods is to try to pretend we aren't familiar with the designs. Cognitive walkthroughs involve telling a story about how someone will use your interface. Action analysis can be done more formally or casually and involves making a list of actions that users can do at different steps. Lastly, heuristic evaluation involves very general rules that interface designers should incorporate into products to make them easier to use.

Andrew Lucas 22:50:08 2/15/2016

The mental walkthrough seems like the most intuitive way for a programmer to evaluate the design of an interface without a user. The programmer knows the actual program code, so they will be more likely to catch "obvious" bugs than, or instance, beta users who have no idea what is going on under the hood. The programmer also has the best idea of what the interface is supposed to do. Users will be able to tell when something that they want to do is more difficult than it should be, but they will not be able to provide any feedback for tasks that they do not realize they have the ability to complete.

Adhyaksa Pribadi 23:26:16 2/15/2016

Users are not always a resource that designers will have in the design process. So the readings mentions three ways that we'd be able evaluate interfaces without users. All though it is not exhaustive, each method will reveal a different type of problem in the interface. In general, the cognitive walkthrough will give you the best understanding of problems it uncovers, and we recommend thinking through the interface in walkthrough terms as you develop it. When a substantial part of the interface is complete, heuristic analysis is a good way to catch additional problems. Finally, Formal action analysis is probably only appropriate for very special cases.

Max Benson 23:31:54 2/15/2016

I like the idea of cognitive walkthroughs; it seems like an effective and systematic way to visualize the usage of a system by someone who has no prior experience with it. I think a lot of tasks that seem intuitive to developers only seem that way because they designed the system and know what they need to accomplish, what controls to use, and where to look for those controls, while first time users who don't know where anything is might think the process to complete those tasks is very obtuse. Cognitive walkthroughs seem like a good way to bridge that gap, to let developers stand back from their design and look at the tool from as unbiased a perspective as possible. Action analysis seems very helpful in this regard as well, as it allows developers to assess how easily a new user can learn the interface without letting the developer's prior knowledge of the design get in the way.

Jonathan Blinn 23:34:57 2/15/2016

This reading definitely helped to clarify the process a little bit more. Seeing an example helps greatly to understand what the user should be doing and how to go about it. The way the user behaves when going through the "test" can greatly impact the way we view our own product - it helps to show any changes that need to be made as well as showing more of how the user would expect the app to perform versus the way we expected them to use it. I also liked the part on speaking the user's language - for us, it is easy to talk about activities and the way things are implemented but a typical user probably would not be familiar with this vocabulary.

Jason Naughton 23:57:31 2/15/2016

I had the chance to sit in on cognitive walkthroughs during my summer internship. I think the most important (and difficult) element of these user-driven design processes is keeping yourself out of the interaction. The user needs to wholly conduct their experience, without tampering. Much of the benefit comes in the users' candid appraisal. As with the prior readings, I also found the physical timing breakdowns of human perception, thought, and action to be very interesting.

chris finestone 1:47:56 2/16/2016

Testing a UI without users is kind of like letting the mechanic tune up the car while he's driving it. It's hard to gauge if the interface allows for good use of the underlying code. The main problem with not testing with users is that they cannot tell you if it's the wrong approach. Engineers are good at writing and testing code. It's much harder to evaluate the design of the interface. It is crucial to know the needs of these users if you cannot have them evaluate the experience.

Dustin Chlystek 1:50:41 2/16/2016

I liked the way they showed how you can uncover different problems using different approaches. Like the example with Control Panel vs. Chooser. I never would have thought twice about the Cs and Os in them being too closely related.

Xinhai Xu 2:51:17 2/16/2016

The reading introduced three approaches of evaluation without users. The first approach is the cognitive walkthrough, a task-oriented technique that fits especially well in the context of task-centered design. The second approach is action analysis, which allows a designer to predict the time that an expert user would need to perform a task, and which forces the designer to take a detailed look at the interface. The third approach is heuristic evaluation, a kind of check-list approach that catches a wide variety of problems but requires several evaluators who have some knowledge of usability problems.

Casey Nispel 3:30:20 2/16/2016

Reading about how to do a walkthrough and what to do with the results feels like we do most of this already, this just assigns a name to it. When we have to first come up with an interface for the user to interact with, we generally always do a walkthrough in our heads, we just don’t officially call it that or write out all of the steps, but just visualize in our heads the results of certain actions and how we can improve the user’s experience with our design.

Bogdan Kotzev 6:53:12 2/16/2016

In today's reading I learned about the 3 ways to improve the UI without using the precious time of users. The Cognitive Walkthroughs takes advantage of the general knowledge you have about your users, and thinking about how to use your interface from their point of view. I think this is a pretty easy way to improve your interface design, you can just assume the user would be need a lot of visual help in your UI and then try to provide them with that help. The other useful approach was the Back-of-the-Envelope Action Analysis where you keep track of the actions that are needed to perform a task. I also like this approach because it is very easy to do for the designer. All you have to do is pay attention to the number of actions and their difficulty to perform in doing a certain task. The last approach is the Heuristic Analysis where you follow a set of guidelines in your design. I think this is another easy one! Overall, I think all of those strategies are easy to do and would help in the design process!

Clark Nicolas 7:50:35 2/16/2016

I found this article useful because it's very relatable to the lo-fidelity prototype that we will be creating for our group apps this month.

David Fioravanti 8:21:48 2/16/2016

This reading brought up an interesting point about making a new feature easy to learn when first using an interface. This is obviously necessary for things like ATMs when many people who are not familiar with the interface need to use it quickly. What was interesting in the reading was that it mentioned that this was also important for more sophisticated interface products in which people will be using over the course of a few years. This is because the product will typically learned incrementally starting with no experience. This will mean that making things easier to learn will help create expert users even on products intended to be used for long periods of time.

Alexandra Krongel 8:25:00 2/16/2016

"If you can't tell a believable story about an action, then you've located a problem with the interface." I thought this was a really good phrasing of something I've heard before, but the presentation is very different. It puts a lot more of an onus on the designer as opposed to something like 'the user should be able to figure out you're supposed to do x then x." I also liked the idea of building up tasks for more advanced systems with incremental learning. I think a lot of programs with really high learning curves could have been made easier to learn. Often a complicated end makes an excuse for the designer to make an overly complex interface, but using a stepwise strategy with something like show/hide for advanced features, this could be reduced.

Sarah Dubnik 8:58:41 2/16/2016

I think today's reading brought up a lot of valuable advice about how to evaluate a design. Previously, it made sense to bring in users to test the product and see what mistakes they made or difficulties they had. However I did not think too much about the process of the designers themselves going through the steps and how difficult it could be to put themselves in the shoes of the users. I found the cognitive walkthrough interesting, but I'm concerned that it might still be difficult to think of all the possible problems this way from the designer's perspective. The action analysis seemed extremely daunting - I was surprised that the formal analysis included such tasks as human memory speed, and the hierarchy of tasks seemed to make this unnecessarily complicated; but I understand that this would only be used in certain cases compared to the "back-of-the-envelope" approach. The heuristic evaluation seemed the easiest and most reasonable step to evaluating a product, and I'm sure we will include the nine heuristic steps in our project.

John Riesenberger 10:05:35 2/16/2016

I don't know if a reading critique is actually required today, since the Readings page suggests we don't need to, however: we learned about how to install and use Cocos 2d-x for our preferred platform. Cocos 2d-x is a simple 2d framework for creating games. The introduction broke down the various components i.e. Scene, Node, Sprite, Menu, and Action. It provided an overview of the Director & Scene concepts as well, which helped visualize game logic in more familiar terms.