I've received news from Birgitte that Lene Schack from Gentofte Hospital wishes to be involved in the project too, which is great news. The more collaborators, the better.
Also, Birgitte clarifies a thing about the title. I thought it to be neurologists, but their actual title in danish is 'neurologopæd', in english speechtherapists. They work with the communication difficulties that patients with brain trauma may experience. Though the title is speechtherapist, they work with more than just speech - body language, semantics and meaning, reading and writing are all central parts in what Birgitte and Lene do.
This description is written from a rather limited understanding from my part. One of the key challenges in this project will be to bridge the gap between us, as IT professionals, and the health care professionals, who have an understanding of the patients needs. Such knowledge may be very hard to convey in precise terms. Likewise, the design challenge of a resulting system may be equally hard to clarify. That is why I hope that we will have the chance to gain a much more detailed and rich insight into the work of Lene and Birgitte. More on that in later posts.
Thursday, February 7, 2008
Friday, February 1, 2008
Initial project description
This project is, in the broadest scope, about software with game-like elements for assisting in the rehabilitation of people with acquired brain damage. The correct danish term is 'senhjerneskadede', and it simply describes those patients who have functioned normally up to the point of acquiring the brain damage. Most typical cause is trauma (head injury).
The project is aimed at creating such a product. This means it has two sides: the practical requirements of the product, and the academic requirements of the thesis.
The practical requirements are defined by health staff on Glostrup Hospital. Neurologist Birgitte Aner is our main contact in the collaboration.
The academic requirements are initially decided by ourselves, and moderated or modified by our supervisor. At this time, there is no supervisor tied to the project.
The system requested is a simulative application that recreates the visual feeling of exploring one's own home for the patients. In other words, we need to rebuild the visual representation of a house or apartment in some sense. At the same time, it should be possible to explore the home, perhaps with some details (drawers, pictures, etc.). It is meant to assist in memory training and the feeling of security for patients who might feel alienated after a long period of hospitalization. These are the practical requirements specified by Birgitte so far.
From my own perspective as a game designer, I would like to focus on how games (or applications with game-like elements) are developed from external requirements. Normally, games are developed from an anticipation of user demands. This may even be an artificial way to put it. It may be more appropriate to say that games create a demand for the user, in the same way literature, music or movies do.
It may also seem artificial to call this an "application with game-like elements". But I see a great potential to actually force game logic into this - especially in the user interface and in the development methods. This is something that I need to clarify in later posts.
At our inital meeting, Birgitte hinted at the wide scope of deficiencies that patients may suffer from. Some patients might not even be able to use a conventional interface. This creates some very special requirements related to the user interface. With the risk of being perceived as cynical, it may also turn out to be an advantage in a real challenge of creating the most intuitive and accessible software tool. Here, games may be an inspiration.
This is not a very sharp or to-the-point project description, but it very well reflects the current level of details that I have to offer.
The project is aimed at creating such a product. This means it has two sides: the practical requirements of the product, and the academic requirements of the thesis.
The practical requirements are defined by health staff on Glostrup Hospital. Neurologist Birgitte Aner is our main contact in the collaboration.
The academic requirements are initially decided by ourselves, and moderated or modified by our supervisor. At this time, there is no supervisor tied to the project.
The system requested is a simulative application that recreates the visual feeling of exploring one's own home for the patients. In other words, we need to rebuild the visual representation of a house or apartment in some sense. At the same time, it should be possible to explore the home, perhaps with some details (drawers, pictures, etc.). It is meant to assist in memory training and the feeling of security for patients who might feel alienated after a long period of hospitalization. These are the practical requirements specified by Birgitte so far.
From my own perspective as a game designer, I would like to focus on how games (or applications with game-like elements) are developed from external requirements. Normally, games are developed from an anticipation of user demands. This may even be an artificial way to put it. It may be more appropriate to say that games create a demand for the user, in the same way literature, music or movies do.
It may also seem artificial to call this an "application with game-like elements". But I see a great potential to actually force game logic into this - especially in the user interface and in the development methods. This is something that I need to clarify in later posts.
At our inital meeting, Birgitte hinted at the wide scope of deficiencies that patients may suffer from. Some patients might not even be able to use a conventional interface. This creates some very special requirements related to the user interface. With the risk of being perceived as cynical, it may also turn out to be an advantage in a real challenge of creating the most intuitive and accessible software tool. Here, games may be an inspiration.
This is not a very sharp or to-the-point project description, but it very well reflects the current level of details that I have to offer.
Thursday, January 31, 2008
About me: Kristian Parkov
This introduction of myself serves as a little overview for anyone interested in joining on the project. In a few days from now, I am planning to do an intensive search for some students interested in joining my thesis idea.I'm studying Media Technology and Games at the IT University, and I am currently a thesis and a single course short of being a candidate. I'm also working at ITU as a student counselor.
My interest in games is primarily focused on how to use game-related logic, methods and theory for other fields. Even though I am interested in making games, this is limited almost exclusively to games that do not express entertainment as their primary use. That could be learning, rehabilitation, museum communication, etc. Because of this, I guess I am a little disappointed in how "Media Technology and Games" is 95 % games and 5 % media technology.
I am a Bachelor in Computer Science and Communications from Roskilde University (RUC), and I've been trying to stay on that very fine line between being a technician and a theorist. I know coding, and enjoy to do it regularly, but I would prefer to keep it secondary in my professional life. I am aiming to be somewhere in the strategic / design area...
Group work has been a central part of my education, since it is the primary way to work on both ITU and RUC. For the same reasons, I may be a little scared of the thought of working alone on my thesis. Besides, I think the size of this project requires more people.
The blog is up
Welcome to my new thesis blog. This will be the main platform for a description document of the thesis writing process. This is where new ideas will be presented, structured and shared.
The blog is written in english because I suppose I am going to hand in my thesis in english as well. Besides, my future writing colleagues could very well be english-speaking.
I will try to let posts be conceptually divided. One post should be centered around one subject. Furthermore, every post will be marked clearly with one or more tags for easy retrieval. The blog will be set to display a certain period (haven't figured out how long) as default.
The tags that I have decided upon using at this point is:
Somehow I figure this structure is too rigid, but I just can't see how, yet. The tag structure will be adapted for future needs. I just hope such modifications will happen in a structured way, too.
The blog is written in english because I suppose I am going to hand in my thesis in english as well. Besides, my future writing colleagues could very well be english-speaking.
I will try to let posts be conceptually divided. One post should be centered around one subject. Furthermore, every post will be marked clearly with one or more tags for easy retrieval. The blog will be set to display a certain period (haven't figured out how long) as default.
The tags that I have decided upon using at this point is:
- Presentation: Posts targeted directly at those not directly involved, wanting to know more about the project, or which could be interesting for potential collaborators.
- Event: Something has happened in the real world which needs to be described for project management or ideas.
- Communication: One or more group members have been talking to someone (meeting, telephone, e-mail), and the main points of the communication needs description.
- Requirement: New requirements have emerged from either group, the supervisor or our contact that needs description.
- Personal: A way to let steam out or to comment on the situation in a way, that does not affect process or results.
- Inspiration: Something out there is cool and inspiring, and should be noticed. It does not have to be directly related to this project, as long as it may be of help in some way.
- Idea: New ideas for product or documentation.
- Process: Ideas or comments that concern the internal group processes of development or writing, without being directly related to the product or end result.
- Academic: Posts that concern the academic side of the project. Methodological and theoretical foundation.
- Technical: Posts that concern the technical foundation for creating the product. Code, tools and techincal issues.
Somehow I figure this structure is too rigid, but I just can't see how, yet. The tag structure will be adapted for future needs. I just hope such modifications will happen in a structured way, too.
