Architecture: student critiques

[amyjko]

From Brian Nguyen:

The first improvement in the chapter that I think would assist me in understanding event propagation a bit more is using mouse/keyboard as one example, but then potentially illustrating events in a more complicated system such as voice interface. I think mouse and keyboard are so integral to our interactions with a computer so events seem obvious to me with them, but they are not as clear for some of the other examples that you provided after these 2.

The second improvement in the chapter that I think would improve it would be to give a code example of MVC. Experience levels for programming definitely vary within the class, and I know that teaching code isn't the explicit goal of the class, but I do think explaining MVC with a short simple code example would provide a context that would be helpful for me and other students.

[amyjko]

This week’s reading includes lots of terms and insightful explanations related to interaction design. I think there are two things that may need to be improved. For some terms such model, view and controller, I feel that the explanation by text makes sense for me. But I still feel that more graphical illustrations to analyze the correlation between these terms are more straightforward and explicit for me. And for some interface toolkits mentioned in the article, each of them are followed by a concise description. But I still have no idea which one to pay more attention to. There are too much information running through while none of these leave me a greater impression and interests. So probably giving more emphasis on few of them work better.

[amyjko]

1) "Precise technical knowledge of user interface implementation also allows designers and engineers to have a shared vocabulary to communicate about interfaces. Designers should feel empowered to converse about interface implementation with engineers, knowing enough to critique designs and convey alternatives. Without this vocabulary and a grasp of these concepts, engineers retain power over user interface design, even though they aren't trained to design interfaces."

I really resonated with this part of the reading. It reminded me of when my father told me years ago that if you are working on a team project and do not have any technical knowledge or adequate grasp of the technical concepts you are working on, you will be taken advantage of. I never forgot his words. For example, if you are a project manager working with programmers but do not know anything or enough about programming, the programmers can say that they need a lot more time to complete the work than they actually do. This will delay the project completion time and cause you to be exploited. I think elaborating on this more, relating it to industry examples, and explaining a bit more on how these scenarios can negatively affect a person can really strengthen what you are saying and cause readers to care more about having the technical knowledge they need.

2) "Of course, graphical user interface buttons in modern operating systems are actually much more complex. Consider, for example, what happens if the button is in a down state, but the mouse cursor moves outside the boundary of the button and then a mouse up event occurs. In this case, it transitions to the mouse up state, but does not execute the button's command. If the button can be disabled, then there's an entirely different state of disabled in which the button never changes states in response to events. If the button supports touch input, then a button's state machine also needs to handle touch events. All of these additional behaviors add more complexity to a button's state machine, but ultimately, it is still state machine."

I read this a few times and I still don't fully understand the interaction being explained. It is a dense paragraph. I think incorporating images or a video will be helpful. This will make it easier to understand and learn. For example, the video of the first GUI from a former reading really helped me understand how it operated and why it was so revolutionary. Some sort of image or video would be helpful here too.

3) "Interfaces can be automatically generated, manipulated, inspected, and transformed, but only within the limits of the architecture in which they are implemented."

The word "be" is missing. Please add.

[amyjko]

Addressed all relevant feedback.