Each person's critique is pasted below, separated by --------:
1) In the 4th paragraph, I believe that there is a typo. The word was supposed to be “then” instead of “them”.
“…Abstract syntax trees are them compiled into instruction…”
2) It was very hard to listen, watch and understand the first video listed named “How does a compiler, interpreter and CPU work?” by All About Software Youtube channel because the writings and drawings did not really match the speed of the information that was voiced by the videographer. Basically, what they were drawing on the video was either slower, faster or even sometimes different than what it was voiced; which caused significant confusion that I had to watch the video several times (one time even without looking at the screen) to fully understand the content. I also asked around and some of my classmates had the same issue with this video.
3) At the end of the article it was mentioned that “...One way to think about all of these innovations is as trying to bring all of the benefits of graphical user interfaces—immediate feedback, direct manipulation, and concreteness—to notations that inherently don’t have those properties….“, listing immediate feedback as a feature that is different than direct manipulation. However at the beginning of the article, “No direct manipulation” was described as “no immediate feedback”. This conflict confused me as a reader.
Reading critique:
Overwhelming amount of vocabulary. While I appreciate the use of bullets to separate discrete terms, there were so many bulleted fields I didn’t know which aspects to pay close attention to. Unless these are terms that will be repeatedly used throughout the book, the bolded term-and-bullet system should be avoided.
Perhaps use diagrams to illustrate the bulleted fields that aren’t super important? (and by “important” I mean reoccurring) This could gives the information the same level of legibility the bullets give, just without drawing the same type of attention the bolded, bulleted terms should be allotted.
Break up some of the paragraphs? Because I am very new to many of these concepts from this chapter, it might help to break up some paragraphs; specifically when the sentence starts with “other systems like...“. I am suggesting this because many people will re-read paragraphs if they feel they’ve missed the point, so having paragraphs be as short as possible greatly improves the UX of reading
Declarative Interfaces Chapter Suggestions
Use of notation — perhaps provide an example of what this could look like in programming?
Paragraph starting “What are declarative interfaces?” took me a reread to understand. Perhaps give an example of a ‘textual language’ — it could give context to those who have heard the names of certain programming languages.
Use barriers — “… might have to learn what kinds of arguments to send to the function” — maybe add “(input)” after the word ‘arguments’ for those with zero understanding of how functions work.
Error-proneness — some people may not know what a ‘string’ is
I have a very basic understanding of programming languages so a lot of my suggestions are based on what ‘noobs’ might struggle with in this chapter. (Perhaps noobs aren’t the intended audience though!)
Critique:
Declarative is spelled incorrectly.
(shows This is because different abstractions in a "declaractive")
Maybe explaining the term programming by demonstration a little more clearly. When saying, "users demonstrate the behavior they want the computer to perform, and the computer generalizes that into a program," I don't quite understand how the computer is taking in user input and generating a program.
Should be its not it's.
"which moves file.txt to it's"
The following are my suggestions that can help improve this chapter :
The video 'How does compiler, interpreter and CPU work?' is very confusing and with visuals don't match what the speaker is talking about. For a person like me with little to no knowledge of this topic, it was very difficult to understand and follow what he was saying. I would recommend this video be substituted with a visual diagram or another video that might better explain the concepts. (Maybe Khan academy could be a good source?)
While the examples under 'how can declarative interfaces be made easier to use?' are illustrate some of the ideas, I think this section is rather long and lacks clarity. I would suggest making this section more concise. Bullet points and summaries could help provide novice readers to gain more clarity.
It would also be great if you could use more current examples to illustrate simpler declarative interfaces. For example, Scratch (which I know you have mentioned) is an interface many of us are familiar with. It is also an interface that is easy to understand and is more accessible for us to explore.
Here's my critique of the chapter:
I found the description of notation to be a bit confusing in the reading because I'm more familiar with the other definition of notation, which is more akin to annotation. It was much clearer to me when Amy explained it in class, as she described language in general as notation, because it helps us describe and translate what is going on in the world around us. Ironically, the use of an example in the chapter made the description of notation less concrete for me, and it would have been clearer if notation was more explicitly defined (and possibly clarified compared to the other definition of it).
The video about compilers, interpreters, and CPU seemed to distract from the reading, rather than add to it, because it is so complex. The pace of the video is really quick and feels really technical, which makes the material even more intimidating for non-technical readers. The overall message of the chapter is less about the intricacies of compilers, interpreters, and CPU, and more about how declarative interfaces compare to GUIs, so the video could be removed or replaced with content that more closely aligns with the overall goals of the chapter.
The six categories of gulfs of execution and evaluation in declarative interfaces that Amy published could have been more clearly explained in the chapter. In particular, I did not understand the interconnectedness of each gulf and how each gulf is sequentially related, until Amy explained it in class and I learned more about her paper from my peers who summarized it for me. It would be helpful to have a diagram that explains how each gulf is connected, possibly using the diagrams and explanations from Amy's paper.
Suggested corrections for the chapter on Declarative Interfaces: (original text is in (parens))
"In these interfaces, a user declares to the computer what they want (it wants), and then the computer compiles and executes the instructions (rather than acting directly on data)."
subject pronoun
What are declarative interfaces? Ultimately, they're software that translate some expression of a program (a text file with code in it, or a hierarchical tree of language constructs in a block-based editor) into a representation a computer can execute.(,) Declarative interfaces are usually some series of instructions that consist of low level operations such as arithmetic, reading and writing data values in memory, and jumping to other instructions.
run-on sentence
The Cognitive Dimensions of Notations framework (Green et al. 1996) described several dimensions along (with) which notations, and particularly programming notations, vary.
typo
Some notations require a user to make several decisions before they have the information they need, while others provide flexibility. For example, Excel is quite good at letting users type in a bunch of data, later adding formulas on top of that data as needed, regardless of how the data is organized in a spreadsheet.
grammar
Similar systems have used similar ideas to allow users to write simple programs to automate web tasks. CoScripter (Leshed et al. 2008) allowed users (a user) to demonstrate an interaction with an interface, which generated a program in a natural-language-like syntax that could then be executed to replay that action.
subject consistency
I feel that that required reading on 'declarative interfaces' would be more effective if there was an easier way to explain the theory of computing and the usage of grammar in the context of programming. I feel illustrations would be easier to explain concepts, either through drawings or videos. For some reason, I feel that the person narrating in the video doesn't sync the concepts with the illustrations he presents. Overall I really liked the way Amy covered the concepts on her webpage on declarative interfaces highlighting the concepts I learned during my undergrad.
Critiques:
"Because of the indirection, notation, and abstraction inherent to programming interfaces, I will refer to them as "declarative" interfaces from here on"
It's not that straightforward why it could be called "declarative" for me. I spend half hours to discuss this with my engineer friends. They feel confused too.
Why are declarative interfaces hard to learn?
This paragraph is easy to understand. While we talking about the gulfs of evaluation and execution in programming, would it be more clear if we compared it to the GUI interface?
Premature commitment Some notations require a user to make several decisions before they have the information they need; others provide flexibility. For example, Excel is quite good at letting users type in a bunch of data, later add formulas on top of that data as needed, regardless of how the data is organized in a spreadsheet. In contrast, doing the same calculations in Python requires data to be organized and formatted before it can be read in, long before a user is allowed to explore the data with code.
For this paragraph, it's more like a unique think-model in programming. I would say it's clean and structured to organize data before executing it. I can't see why it more difficult than other interfaces.
amyjko
commented
3 years ago
Each person's critique is pasted below, separated by --------:
1) In the 4th paragraph, I believe that there is a typo. The word was supposed to be “then” instead of “them”. “…Abstract syntax trees are them compiled into instruction…” 2) It was very hard to listen, watch and understand the first video listed named “How does a compiler, interpreter and CPU work?” by All About Software Youtube channel because the writings and drawings did not really match the speed of the information that was voiced by the videographer. Basically, what they were drawing on the video was either slower, faster or even sometimes different than what it was voiced; which caused significant confusion that I had to watch the video several times (one time even without looking at the screen) to fully understand the content. I also asked around and some of my classmates had the same issue with this video. 3) At the end of the article it was mentioned that “...One way to think about all of these innovations is as trying to bring all of the benefits of graphical user interfaces—immediate feedback, direct manipulation, and concreteness—to notations that inherently don’t have those properties….“, listing immediate feedback as a feature that is different than direct manipulation. However at the beginning of the article, “No direct manipulation” was described as “no immediate feedback”. This conflict confused me as a reader.
Reading critique: Overwhelming amount of vocabulary. While I appreciate the use of bullets to separate discrete terms, there were so many bulleted fields I didn’t know which aspects to pay close attention to. Unless these are terms that will be repeatedly used throughout the book, the bolded term-and-bullet system should be avoided. Perhaps use diagrams to illustrate the bulleted fields that aren’t super important? (and by “important” I mean reoccurring) This could gives the information the same level of legibility the bullets give, just without drawing the same type of attention the bolded, bulleted terms should be allotted. Break up some of the paragraphs? Because I am very new to many of these concepts from this chapter, it might help to break up some paragraphs; specifically when the sentence starts with “other systems like...“. I am suggesting this because many people will re-read paragraphs if they feel they’ve missed the point, so having paragraphs be as short as possible greatly improves the UX of reading
Declarative Interfaces Chapter Suggestions Use of notation — perhaps provide an example of what this could look like in programming? Paragraph starting “What are declarative interfaces?” took me a reread to understand. Perhaps give an example of a ‘textual language’ — it could give context to those who have heard the names of certain programming languages. Use barriers — “… might have to learn what kinds of arguments to send to the function” — maybe add “(input)” after the word ‘arguments’ for those with zero understanding of how functions work. Error-proneness — some people may not know what a ‘string’ is I have a very basic understanding of programming languages so a lot of my suggestions are based on what ‘noobs’ might struggle with in this chapter. (Perhaps noobs aren’t the intended audience though!)
Critique:
(shows This is because different abstractions in a "declaractive")
Maybe explaining the term programming by demonstration a little more clearly. When saying, "users demonstrate the behavior they want the computer to perform, and the computer generalizes that into a program," I don't quite understand how the computer is taking in user input and generating a program.
Should be its not it's.
"which moves file.txt to it's"
The following are my suggestions that can help improve this chapter :
The video 'How does compiler, interpreter and CPU work?' is very confusing and with visuals don't match what the speaker is talking about. For a person like me with little to no knowledge of this topic, it was very difficult to understand and follow what he was saying. I would recommend this video be substituted with a visual diagram or another video that might better explain the concepts. (Maybe Khan academy could be a good source?) While the examples under 'how can declarative interfaces be made easier to use?' are illustrate some of the ideas, I think this section is rather long and lacks clarity. I would suggest making this section more concise. Bullet points and summaries could help provide novice readers to gain more clarity. It would also be great if you could use more current examples to illustrate simpler declarative interfaces. For example, Scratch (which I know you have mentioned) is an interface many of us are familiar with. It is also an interface that is easy to understand and is more accessible for us to explore.
Here's my critique of the chapter:
I found the description of notation to be a bit confusing in the reading because I'm more familiar with the other definition of notation, which is more akin to annotation. It was much clearer to me when Amy explained it in class, as she described language in general as notation, because it helps us describe and translate what is going on in the world around us. Ironically, the use of an example in the chapter made the description of notation less concrete for me, and it would have been clearer if notation was more explicitly defined (and possibly clarified compared to the other definition of it).
The video about compilers, interpreters, and CPU seemed to distract from the reading, rather than add to it, because it is so complex. The pace of the video is really quick and feels really technical, which makes the material even more intimidating for non-technical readers. The overall message of the chapter is less about the intricacies of compilers, interpreters, and CPU, and more about how declarative interfaces compare to GUIs, so the video could be removed or replaced with content that more closely aligns with the overall goals of the chapter.
The six categories of gulfs of execution and evaluation in declarative interfaces that Amy published could have been more clearly explained in the chapter. In particular, I did not understand the interconnectedness of each gulf and how each gulf is sequentially related, until Amy explained it in class and I learned more about her paper from my peers who summarized it for me. It would be helpful to have a diagram that explains how each gulf is connected, possibly using the diagrams and explanations from Amy's paper.
Suggested corrections for the chapter on Declarative Interfaces: (original text is in (parens))
"In these interfaces, a user declares to the computer what they want (it wants), and then the computer compiles and executes the instructions (rather than acting directly on data)."
What are declarative interfaces? Ultimately, they're software that translate some expression of a program (a text file with code in it, or a hierarchical tree of language constructs in a block-based editor) into a representation a computer can execute.(,) Declarative interfaces are usually some series of instructions that consist of low level operations such as arithmetic, reading and writing data values in memory, and jumping to other instructions.
The Cognitive Dimensions of Notations framework (Green et al. 1996) described several dimensions along (with) which notations, and particularly programming notations, vary.
Some notations require a user to make several decisions before they have the information they need, while others provide flexibility. For example, Excel is quite good at letting users type in a bunch of data, later adding formulas on top of that data as needed, regardless of how the data is organized in a spreadsheet.
Similar systems have used similar ideas to allow users to write simple programs to automate web tasks. CoScripter (Leshed et al. 2008) allowed users (a user) to demonstrate an interaction with an interface, which generated a program in a natural-language-like syntax that could then be executed to replay that action.
subject consistency
I feel that that required reading on 'declarative interfaces' would be more effective if there was an easier way to explain the theory of computing and the usage of grammar in the context of programming. I feel illustrations would be easier to explain concepts, either through drawings or videos. For some reason, I feel that the person narrating in the video doesn't sync the concepts with the illustrations he presents. Overall I really liked the way Amy covered the concepts on her webpage on declarative interfaces highlighting the concepts I learned during my undergrad.
Critiques:
"Because of the indirection, notation, and abstraction inherent to programming interfaces, I will refer to them as "declarative" interfaces from here on"
Why are declarative interfaces hard to learn?
Premature commitment Some notations require a user to make several decisions before they have the information they need; others provide flexibility. For example, Excel is quite good at letting users type in a bunch of data, later add formulas on top of that data as needed, regardless of how the data is organized in a spreadsheet. In contrast, doing the same calculations in Python requires data to be organized and formatted before it can be read in, long before a user is allowed to explore the data with code.