Wiki source code of Diederik Reflection
Version 3.1 by Diederik Heijbroek on 2024/03/02 17:08
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | |||
| 2 | |||
| 3 | == Lecture Summaries == | ||
| 4 | |||
| 5 | Because I cannot attend the lectures on Monday, I'll give a short description of each of the missed lectures to show that I am familiar with the lecture content and fully up-to-date with the course material. I have attended all of the Tuesday lectures. | ||
| 6 | |||
| 7 | === Lecture 1 === | ||
| 8 | |||
| 9 | Besides the course information, the main topics and terminology about socio-cognitive engineering are explained. Moreover, the different types of robots are introduced and the assessment and tools are explained. | ||
| 10 | |||
| 11 | In the second part of the lecture about human-centred design, two books are given as reference. Additionally, the (ISO) standard is elaborated by mentioning usability, effectiveness, efficiency, satisfaction, context of use, user experience, and stakeholders. | ||
| 12 | |||
| 13 | Last, projects for PwD are shown, in particular the environment and activities of the Pieter van Foreest healthcare institute. Some of the projects are about what the PhD and MSc students are doing. | ||
| 14 | |||
| 15 | === Lecture 3 === | ||
| 16 | |||
| 17 | The lecture started with an example about health management for people with diabetes. Also, different types of systems are described which could be used for health management. | ||
| 18 | |||
| 19 | Next, the operational demands are explained using an example. The situated needs, the mind map with all things to consider, situated activities, stakeholders, design method, value stories, personas, and the problem scenario are talked about in the diabetes example. | ||
| 20 | |||
| 21 | The human factors, technology, and evaluation are briefly explained with corresponding requirements, concerns, and examples. | ||
| 22 | |||
| 23 | Finally, the co-design of the model is explained in detail and considerations for the growth of hybrid intelligence can be explained in one sentence: Integrating technology into the situated practice via co-design by joint task performance and co-learning grounded by ontologies, collaboration, and value. The relation between ontologies, patterns and values are important for human-robot partnership. | ||
| 24 | |||
| 25 | === Lecture 5 === | ||
| 26 | |||
| 27 | **Claims and design patterns** | ||
| 28 | A claim is the description of a specific functionality having a specific kind of effect. So in a claim we describe WHAT (function) happens and WHY (effect). The functions in this story are basically the functional requirements that we know from software engineering. To add onto this we can also use Use Cases to describe the WHEN, WHERE, and BY WHO. The resulting claims can be justified by existing theory and empirical studies. | ||
| 29 | |||
| 30 | The functions, effects, and use cases are part of the Task Level, and are abstracted by the Team Design Patterns. On the other side we would have the Interaction Level, containing the answer to the HOW-question. This Interaction Level is abstracted by the Interaction Design Pattern. | ||
| 31 | These Design Patterns help us manage problems; How do components interact, what are their responsibilities, etc. The patterns provide building blocks that we can apply to our problem to find a solution, but if there are no useful design patterns to be found you can make your own by starting with a proto pattern (a candidate pattern) and refine it until it is a useful design pattern. | ||
| 32 | |||
| 33 | Design Patterns are generative and you can organize them in a meaningful way to create a pattern language, in order to create an abstraction of true collaborations and interactions. | ||
| 34 | |||
| 35 | **Ontologies** | ||
| 36 | The ontology and the design pattern should be consistent with each other and their elements should be recognizable in the other. An ontology provides a description of the world around us and its entities. How to group those entities and how to subdivide them. A specification of the systems representation of the world (more computer science viewpoint). | ||
| 37 | Ontologies exist of both declarative and procedural knowledge, both of which are necessary for automated reasoning, eg. a robot needs to know what a person is and what they can do before it can reason about people. | ||
| 38 | Ontologies consist of classes (aka concepts) and instances (eg. human as class, with instance Betty). The classes have relationships between them (such as dog is-an animal), but also classes and instances have relationships (eg. Relationship: labrador is-type-of dog). And then lastly those classes and instances have properties. | ||
| 39 | |||
| 40 | The lecture ends with the REJAM and PAL 3DM examples about interaction design and the objective ontology. |