Wiki source code of Diederik Reflection
Last modified by Diederik Heijbroek on 2024/04/07 20:15
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | == Personal Reflection == | ||
| 2 | |||
| 3 | During our initial brainstorm, we quickly figured out which direction we wanted to go in. As it is easy to drift off, we had a second session to narrow down all of our ideas to one concept and made sure that we were consistent throughout the rest of the project. Throughout the weeks we divided the tasks (most of the time in groups of 2) and made sure that we reviewed each other's work to stick to the aforementioned coherency. I believe that throughout this project we divided the work equally and everything led up to that we had a solid pace, were able to do the full experiment and evaluation in week 7 and showed our interesting work and progress properly during the two presentations. I'm proud of what we achieved in so little time, which we can thank to good organisation, division of tasks, and everyone's involvement :). | ||
| 4 | |||
| 5 | Throughout this project I learned about all of the requirements for coming up with new ideas. Delft is really entrepreneurial and I like about this course that we could learn more in this field by doing the project. Also, the potential of the three robots suggested in the lectures is really good and it is nice how each group could come up with a creative idea for the support of people with early stage dementia and that we could test our idea with fellow students and friends. | ||
| 6 | |||
| 7 | I'd like to give a bit of feedback about the course as well. It seemed to me that sometimes we had to be very repetitive, because in for instance 2.b, 2.c, 2.d, 2.e, we kept repeating the same pieces of information. In my opinion, some of the text is a bit redundant this way. Moreover, it was a bit unclear in the subsections of the evaluation what was expected of us and where to talk about what. However, this was done really nicely in the foundation part of the project, so if it could be more similar to that, it would be an improvement. Nevertheless, I really enjoyed the course material, that we were able to work with the Nao robot and see our idea come to life, and that guest lecturers were invited to talk about specific topics they were specified in! Thanks to the TAs as well :)! | ||
| 8 | |||
| 9 | |||
| 10 | == Lecture Summaries == | ||
| 11 | |||
| 12 | 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. | ||
| 13 | |||
| 14 | === Lecture 1 === | ||
| 15 | |||
| 16 | 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. | ||
| 17 | |||
| 18 | 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. | ||
| 19 | |||
| 20 | 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. | ||
| 21 | |||
| 22 | === Lecture 3 === | ||
| 23 | |||
| 24 | 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. | ||
| 25 | |||
| 26 | 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. | ||
| 27 | |||
| 28 | The human factors, technology, and evaluation are briefly explained with corresponding requirements, concerns, and examples. | ||
| 29 | |||
| 30 | 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. | ||
| 31 | |||
| 32 | === Lecture 5 === | ||
| 33 | |||
| 34 | **Claims and design patterns** | ||
| 35 | 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. | ||
| 36 | |||
| 37 | 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. | ||
| 38 | 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. | ||
| 39 | |||
| 40 | 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. | ||
| 41 | |||
| 42 | **Ontologies** | ||
| 43 | 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). | ||
| 44 | 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. | ||
| 45 | 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. | ||
| 46 | |||
| 47 | The lecture ends with the REJAM and PAL 3DM examples about interaction design and the objective ontology. | ||
| 48 | |||
| 49 | === Lecture 7 (no lecture) === | ||
| 50 | |||
| 51 | === Lecture 9 === | ||
| 52 | |||
| 53 | **Know how to evaluate in an iterative design-test process** | ||
| 54 | First we need to determine usability for different groups, identify good and bad features for future design. Compare the design choices for making decisions and observe the effects. We need to use this final step to evaluate what to do better. As people's interests change over time, there is a constant need for reiteration of the product. In SCE specifically, we focus on checking the usability of the interaction design at the task level. | ||
| 55 | |||
| 56 | **Know about different types of evaluations and how they relate to each other** | ||
| 57 | There are formative and summative evaluations. They both intertwine, because we need to observe how people interact with the system and based on that we can evaluate other properties, such as whether they are able to do the interaction we designed. By understanding how they interact with the system we can make different design choices to allow people to perform the interaction based on "logical" choices we observed. | ||
| 58 | |||
| 59 | **Understand basic quality aspects of evaluation methods** | ||
| 60 | Formulative evaluation is derived from open questions in the design specification. | ||
| 61 | Summative evaluation is derived from closed questions in proving the quality of the design. Summative evaluation also uses independent variables which we manipulate to measure the effects (dependent variables). | ||
| 62 | |||
| 63 | **Know about basic data type constraints** | ||
| 64 | We need to consider which tools to use (GDPR), where we can gather much data (crowd sourcing) and how to ensure that our data is of quality (attention checks or multiple questions related to same construct). | ||
| 65 | |||
| 66 | **Other** | ||
| 67 | Finally, we looked at the PAL-example, ethics approval form, and ReJAM-related examples. | ||
| 68 | |||
| 69 | === Lecture 11 (no lecture) === |