Architecture: student feedback

[amyjko]

1

Here is a silly example of a metaphor for MVC you could include along with the more practical one:

The model is the employee at the movie theater who’s job it is to change the ad on the sign outside. He has all the letters The view is the sign The controller is the manager of the theater who approves what goes up on the marquee

2

Maybe include another visual along with your first sketch that labels an image of an actual application window.

3

This is more of a compliment than a critique, but I like the way this chapter is organized in two labeled sections, it makes it really easy to find the part I’m looking for.

[amyjko]

Compared to other chapters this was a very terminology-heavy chapter. I often wasn’t quite sure if I had the same definitions as you. Specifically words like: widget, state machines, child and root widgets, container vs component vs widget, synthetic event processing. These all stood out to me as questions.

I think your paragraph about why knowledge of this is so important for designers is very powerful and a compelling start for this chapter. However, I found the example case of keyboards to be confusing, I didn’t see how changing the industrial design really needed to know anything about the complex architecture of systems and programs you then go on to discuss.

I think the first illustration of a button moving could simply be replaced with a quick annotated gif of the motion. At first I was confused what was happening in the diagram because of the many places it has up and down written on there.

The fact that the definitions of model, view, and controller do not follow the same order as the image was confusing.

[amyjko]

Chapter Critique: Architecture

i) While talking about the model/controller/view components, I actually found your explanation in class more helpful than the example presented in the text (login process). I am not from a technical background and have little to no knowledge of coding, but I think that highlighting areas of code that talked about the different elements of the code and the functions did a better job of explaining the role of the model, controller and view components.

ii The three ideas (hierarchies, layout, event propagation) could have a different method of explanation. like,

when you try to post something on fb, you move your mouse to the ‘create post’ region of the page’, where you can either write something or attach xyz… If you choose to attach a photo, it opens up the explorer window where you can choose the photo(s) that you may want to upload. Three things are happening here,

you are initiating an action by having the mouse send signals to the UI.(event propagation) you follow a linear step in order to achieve a task (hierarchy) Each widget has one or more follow up options for you to choose from (layout).

this is just a rough draft of the explanation, but in general, I find explanations better where the example/scenario is presented first and then the explanation.

iii The event propagation examples are really long. For example, I felt that just by saying “A mouse emits mouse move events and button presses and releases.”, the point was clear enough for me to move on.