Title: Alternative Process Views
Unique identifier: APV-01-2008-11
|Partner’s short name||Participant|
|UH||Minna Lakkala (ML)||firstname.lastname@example.org|
|UH||Sami Paavola (SP)||email@example.com|
|UH||Jiri Lallimo (JL)||firstname.lastname@example.org;|
|FH-OÖ||Eva Zoeserl (EZ)||email@example.com,|
|FH-OÖ||Christoph Richter (CR)||firstname.lastname@example.org,|
|Metropolia||Merja Bauters (MB)||email@example.com|
|TUK||Jan Paralič (JP)||Jan.Paralic@tuke.sk|
|TUK||Frantisek Babič (FB)||Frantisek.Babic@tuke.sk|
|TUK||Jozef Wagner (JW)||firstname.lastname@example.org|
|AKKA||Benoit Baurens (BB)||email@example.com|
|AKKA||Mirela Ionescu (MI)||firstname.lastname@example.org|
|0.1||16.10.2008||Sami Paavola, Minna Lakkala, Hannu Markkanen, Merja Bauters, Svein Olav, Frantisek Babic, Jozef Wagner, Eva Zöserl||User requirements elicitation on Wiki (see M40AlternativeProcessViews)|
|0.2||28.10.2008||Eva Zöserl||Usage Scenario first draft|
|0.3||29.11.2008||FB and JP (TUK), MB (Metropolia)||Comments|
|0.5||2.11.2008||Sami Paavola (SP)||Comments|
|0.6||2.11.2008||Christoph Richter (CR), FB||Comments|
|0.6||10.11.2008||Minna Lakkala (ML)||A few comments|
Working Knot: Process Management and Analysis (WK3)
High Level Requirements: List of all HLRs that are addressed by the system usage scenario (based on the new D2.4).
|HLR 8.8||Users can choose between different types of process structure visualizations (e.g. project-based or progressive inquiry).|
Additionally, the following HLR are somehow related to Alternative Process Views:
|HLR 1.5||Users can create and work with selected subsets of artefacts (e.g. a user might select all content items relevant for a certain task at hand) Tailored View||When double clicking onto an area, a tailored view which displays related tasks and content items will be opened.|
|HLR 2.3||Users are able to select which tools they want to work with (i.e. they can choose from the set of tools integrated or supported by the system) Preferences and configurability of shared space and user management||The user is able to define the default process view which is displayed first.|
|HLR 8.1||Users are able to define and modify the tasks and responsibilities throughout the process lifetime. Process View||In the alternative process view users can also define and modify tasks and responsibilities throughout the process lifetime. TUK: I do not understand what is the difference here. Based on this description Alternative process view has the same functionality as Process View.EZ: Okay, i see what you mean. Here I just wanted to show that this HLR which belongs to Process View is also related to the Alternative Process View as tasks can also be modified in the Alternative Procecss View (e.g. someone uploads a new background image, or modifies the name of a task etc.). This means, that the Alternative Process View is not static. FB:OK.|
In the Process View the user can choose if he wants to create a process view on the basis of a GANTT chart (current M24 implementation) or if he wants to use alternative process structure visualizations. In the requirements elicitation in Wiki the Alternative Process View was exemplified by using a progressive inquiry approach (see figure 1).
1.1 Creating Phases by Uploading and Dividing Background Image
It is proposed to upload a background image which describes the process (e.g. image of progressive inquiry, image of a problem-based learning process or any other image that can be used to visualize the process). Since images might be different according to the process and/or educational setting, users should be enabled to divide the image into parts in order to define phases which are understandable for the system. This could be done by drawing lines or using pre-defined shapes (e.g. rectangle, circle) that the user can drag and resize on top of the image. For example, the user would select a rectangle from the control tab and drag this over the image to define an area in the image which represents a phase. TUK: How complicated is to implement some of the alternatives mentioned here from the GUI-s perspective should comment people from Metropolia. I can imagine that we start for the first release with one simpler option and can provide additional ways of graphical division into phases for DOW4. EZ: Do you have a concrete simpler option in mind? Currently, I only see the option which is described in section 2. Or did you mean: starting with providing rectangles instead of having all options (lines, circles etc.) available?FB: I think, we can imagine here situation that APV will provide list of preddefined objects (rectangles, circles, etc.) that will represent phases and user can use these alternatives for creation. SP: I’m not sure how important different pre-defined shapes are? A central idea has been that different areas can be marked (as different “phases”) not so much alternative ways of marking different shapes. Of course, it could be handy to have alternatives with shapes also but that is not the most important thing – or is it? Or are these pre-defined shapes important in the sense how they make possible to construct alternative process figures as a whole (like a spiral, to divide the area with squares, to have triangles, etc.)
CR:Actually I don't see the benefits of uploading and dividing a background image. I think the alternative described by Eva in section 2 is much more flexible and generic.
FB:The last discussion about this point emerged in result, that we will not divide the image by self, but image will be only like wallpaper and we will create the process structure through some geometrics elements above her. In progressive inquiry such a phase could be “Setting up the Context”. The forms drawn and dragged onto the image would be like transparent nodes which tell the system that these areas are phases. For each transparent node (phase) a form appears (e.g. by double-click) in which the user has to insert one tag; additionally s/he can add a name and a description. One phase can only have one tag which represents the phase.
Note: In GANTT such a phase could be presented as a container for tasks without defined start time and end time (represented in GANTT chart as a simple line, not rectangle). The naming or tag would define it as a phase that would be like a container in GANTT.
CR: I agree with Sami as I also do not understand the semantics of a phase in contrast to a task? What I read in this document I don't see any systematic difference between both. In some cases it is mentioned that phases dont have to have a start- and end date, but the same holds for tasks. For this reason I would suggest to skip the concept of phase and speak of tasks only. As long as we have the possibility to define subtasks and do not have to assign timeframes this should not be a problem. In addition, I do not understand the difference between the name of the phase/task and the one tag. Why not simply using the name of the task/phase instead. This way a task would simply inherit the names of all its supertasks as tags and a phase/task without a name does not make sense to me. FB: I don't agree with you, because phase can be used as a cluster for tasks - something like workpackage. Sometimes is better to divide whole process into several phases and each phase will contain concrete tasks or subtasks for assigned actors. Basically phase is something like container of tasks (but you can use phase as simple task too) and tag relevant to this phase represents identificator of the membership. And personally, I like name phase much more as supertask:) - but you create end-user requirements, we are only developers:) ML 10.11.08: I strongly agree with FB; sometimes you need to describe the elements of the process in more abstract level and cluster more concrete tasks under more general titles to help the understanding of the logic of the process; see also some of my comments below.
1.2 Adding Tasks to the Process
Tasks and subtasks can be added either in the Process View or in the Content View.
1.2.1 Adding Tasks in the Process View:
The user can add a task to a particular section of the image (= phase) which was defined like described before (see 1.1). For example, the user right-clicks onto the phase and selects “add task”. A form appears like in Process View (name, description etc). When adding a task to a particular phase (node/process area), it automatically gets the tag that represents the area.
The user can add a task in the Content View e.g. by a right-click onto the space. A form appears in which the user has to insert the name, a description etc. Tags of phases can be used as any other tags from any vocabulary, i.e. they can be searched for, they can also be used in the content view for tagging tasks and content items etc. When the user adds a task in the Content View and tags it with one of the tags representing a particular phase, the task will automatically be displayed on top of that area in the Alternative Process View, although it was added in the Content View. If no tag is indicated to it in the Content View, the task appears in the lower part of the Alternative Process View (sort of no-man’s land) and can be later moved to its correct place.
After adding a task, the user can drag it from one area to another. When dragging it to another area, the tag changes according to the area. Tasks cannot have tags from different areas and subtasks inherit the tag from the parent. EZ: When tasks cannot have tags from different phases/areas this would mean that tasks cannot occur in different phases. Or in other words, each task can just occur in one phase. Why do we have this constraint? For example, the task “reflection” occurs at the beginning and at the end of the semester (in 2 different phases).TUK: This is an important point. Technical partners should rethink what kind of implication would have he possibility to assign one task into more than one phase. I see here one possibility that we can have different instances of similar task - reflection with relevant properties at the beginning and reflection with relevant properties (other) at the end. SP: I agree with Eva that it should be possible to have a task with a same name in two phases; but isn’t this then possible? To have, for example, reflection (at Phase 1) and reflection (at Phase 5)? So to have a task with a similar name within two phases. Is the problem then if I would like to have them tagged in a combined way; like reflection (Phase 1, Phase 5) – but I’m not sure if that is needed.
CR: To my understanding we should take care not to mix up tasks in the sense of elements of a work plan and tasks as recurrent activities or methods. While in the first case there would be two tasks labeled as reflection (the first at phase 1 and the second at phase 2), but you might want to refer to the same type of activity in both cases. Similar, I think it is essential to become clear if the process structure is meant to represent a work plan or if should depict the actual work process.FB: This last remark is interesting, because I understand our process models from KPS as basic process structure (at the beginning use as workplan) that can be dynamic modify and adapt to the actual situations - actual work process/progress. Differences between started workplan and actual or final version can be used for improvement or identification of typical steps, critical points, etc. ML 10.11.08: I agree with FB that process view can describe both plans and actualized work process. In addition, it can also be a visualization of conceptually critical or central elements of the process; in such situation the phases describe the process in more abstract level.
According to the additional proposal that process view could be like content view, where phases, tasks and subtasks are displayed including relations but without items, I had the idea of an alternative approach of creating an Alternative Process View (besides the creation presented in section 1.1). The following approach could be used additionally to the creation approach presented in section 1.1. However, it should be discussed if this approach would be feasible and if it would allow more generic scenarios. In my opinion it allows more generic scenarios as teachers do not always have images of the whole process. SP: I agree because images are not necessarily central but different ways of constructing a process model (see above – a spiral, etc.); Or should there be a possibility to have some generic images (like a spiral as such) instead / besides some particular process models (like a progressive inquiry model) with which users could define their own process models?
The difference between the approach described in 1.1 (uploading one background image and cutting it up into parts) is, that the user can upload as many images as s/he wants. Each image itself automatically represents a process element (like a phase or task). The user does not have to cut up the image, but if he wants he can (like described in 1.1). Additionally, the images can be linked with arrows to describe relations and workflows.TUK: We should technically rethink implementation differences between both approaches. I currently do not see a principal difference (only in case that the types of graphs that can be produced by each of the two approaches are fundamentally different).
Tasks can be assigned like in the approach described above. There could also be some pre-defined shapes which can be used to represent phases (then the user does not have to search for an adequate image) Relation to CSME? TUK: Integration with CSME is interesting question but we know that integration tasks are very complicated in our project:). But I see here possibility that CSME will have list of process elements as CSME nodes and relations between them.
Users can define a process either from scratch or from existing templates. For example, users could choose from a list of pre-defined process structures which already have been saved and shared. A typical type of process could be progressive inquiry. In this case, the user has not to upload images as they already exist in the template. This requirement is related to the Re-Use Library.
CR: As mentioned above, according to recent discussion on re-use, the idea is to handle also process-structures as content items that could be copy-pasted across spaces. Detailed specifications on this are currently in preparation.
After adding a task, the user can drag it from one area to another. When dragging it to another area, the tag changes according to the area.TUK: This can have more implications than just this one. If e.g. the phases are in causal relations, than moving a task means also significant changes in its starting/finishing times constraints. If we would like to have another attributes like milestones, or responsible person (for task, or for a phase), these may also change when moving a task between phases. EZ: Good point, I have forgotten the relations! Then for example the user should get an information about the new time constraints and that he should adapt it. I added this point to the phase "Modification of an alternative process view". SP: How these relations between phases are defined? Because necessarily phases are not supposed to be causally related?
CR: As far as I can see, the relation between tasks and subtasks is defined as an "is part of relation". In addition the user can of course define other relations in content view. I wonder if this is not sufficient. And again I think we should become clear whether tasks refert to plans or to actual activities. AS I would prefer to understand tasks as plans, I don't see how plans can be causally related ;-) ML 10.11.08: I am not sure whether I undestand the issue but I could easily see that there is a process view where some phase (e.g. writing of own explanations as answerst to the created inquiry problems) should be "done" before concentrating on the next phase (e.g. searching for existing infromation from knowledge sources ) and the users would like to explicate this "causality" in the process view before starting the work. E.g., in Progressive Inquiry it is quite central idea that learners should write their own explanations to their inquiry questions before searching for info and reading source materials, and as a teacher I would like to explicate this "pedagogical causality" in the process view. I do not see the process view only as a plan or as a documentation of realized process but in some practices it is a conceptual visualization of the logic or critical elements of the activities; sort of idealized conceptual model of the practices that the students should learn.
It was proposed that an Alternative Process Visualization could be automatically presented as a GANTT chart. As there would then be two possible views, the user could define the default view which is displayed first – the GANTT type or the alternative type. This is a question for GUI developers. Additionally, the user could switch between both views and both process views could be opened at the same time. For example, one view could be opened as a “floating pop up”.
In the following the relation of the Alternative Process Visualization in regard to the GANTT chart visualization is presented.
In the actual M24 version of Process View we have implemented process elements called phases and it is possible to link it with these phases of the Alternative Process View (TUK).
From a project management point of view phases represent something like work packages containing tasks. It is possible to implement these phases as only containers for tasks without defined start time and end time (TUK). The system could define a phase which is created by the Alternative Process View as a container for tasks without having a defined start time and end time (see figure 2). The naming or tag of the phase acts like a container. This could be represented in GANTT chart as a simple line, not rectangle.
When we want to visualize figure 1 as a GANTT chart, the basic structure could look like following: TUK: but particular tasks could have their starting/finishing times - this was one of the main requirements from pilot courses EZ: Yes, usually tasks have particular starting/finishing times, and sometimes they don't have fix times (as Minna mentioned). The image just shows the relation of GANTT and Alternative Process View regarding phases and tasks. It does not show the rectangles which should be visible when tasks have starting/finishing times etc.FB:OK.
Questions regarding visualization:
Input from Tessera?
UH: The presentation of tasks to which users come frequently back is questionable. It is proposed that such tasks could be presented in the time line as repeating (i.e. in the same line the rectangles which represent the task would come over and over again as many times as users return to the task). The phases could go from the start of the timeline to the end.TUK: The simplest implementation possibility would be to have different tasks of the same phase representing repeating activity of the same task (?)
It should also be discussed if an Alternative Process View should be saveable. This question comes in mind when thinking about what we want to present in the Process View. Do we want to present the intended process structure? Or do we want to update the process structure according the real process? When we can save an Alternative Process View, we can change the structure according to what has happened in real, and then we could initiate reflection processes by analyzing the difference between the intended process and the real process. Additionally, alternative process views should be saveable in the re-use library for later re-use. CR: See comments above, the idea would be to treat process structures as content items. This way we could also think about a kind of history function for the process structure, depicting changes to the process structure in time.
There also was and idea that the user could directly from the process view create a tailored view that would show the image, arrangement of the task in it and hold the “tag areas”.
UH: When the user clicks a particular phase it will open in the tailored view presenting all the tasks in that phase but also all the content items, notes or whatever happens to be placed into that phase. This means that in the alternative process view it would not display the content items, notes, etc. content view stuff, but only the phases and tasks.
Reason explained by ML: Sometimes presenting and organizing the work using content view might be quite challenging for students because such network presentation of all tasks and contents is quite demanding, especially if there is much stuff. I have a vision to be able to organize the process so that there is quite simple and clear visual model of the main phases/elements of the process presented in the process view and by clicking one phase, you can open a view that includes only those elements that belong to that phase - sort of container metaphor to the content. But everything is possible to view also in content view and if you do something in the tailored view (e.g. add a content item), you can also go to content view and see the same item linked with a hierarchical link to that specific phase/task item. And if you have defined "phases" that will be viewed as tailored views, it would be nice if each item added in a specific phase/tailored view will automatically get a tag of that phase. It would be quite nice course design to make students start their inquiry in easy steps supported by some clear phase model that structures the successive activities, and later give them a task to start finding commonalities between the produced knowledge object through linking and tagging them in content view ... Perhaps there is some similarities in this approach an in the ASDS tool that has its own ways of modeling the process in specifically designed views but users can also always go to content view and see all stuff there in network form.TUK: Good point, Minna. Somebody from ASDT team should have a look the ideas behind the alternative process view, to what extent it matches the activity system triangle there.
It was left open how this tailored view (in the content view) would react when the changes of the arrangement made by the user in the process view, etc., i.e., should the tailored view reflect what the user does or not. If not then the user has to create a new one to display the new arrangement. It was not decided yet if this creating a tailored view from this alternative process view is what is wanted, it was more or less brainstorming.
UH: At the moment tasks of the GANTT chart can be presented in the content view. The phases as well as the tasks of the Alternative Process View should be also presentable in the content view. Both (phases and tasks) should be visualized in different manner to make them distinguishable. For example, we could different colors.
Additionally, in the Content View the relation of parent tasks and subtasks could be displayed as hierarchical black link.
The Content View would be as it is currently. The “structuring vocabulary” used in the alternative process view would be usable in the content view also. It would hold the restriction that task, or content item can only have one tag from this kind of “structuring vocabulary”. The tags from this kind of vocabulary can also be used for content items.
Figure 4 presents an idea of a possible visualization of semantic search when searching items and tasks that have been tagged with the above kind of “structuring vocabulary”. The idea was for example in the above case that the user has searched by using as a constraint only the tag of one particular area. TUK: This should be not a problem, when indexing this tag properties by SSP, this results in the possibility to use it as one of the facets for search.
In this case there has been one task and the content items that have been linked to it are presented next it as related items and the next column presents the content items linked to the content items in the first column etc, i.e., it would display the distance of the content items to the task. This was not discussed yet nearly at all. So very preliminary idea and might not be accepted by the ped. partners when discussed further.
mb: This is also the task of the search visualisation which has not yet been started .....
|Creation of an Alternative Process View||The approach of how to create an alternative process view has to be discussed according to the two proposals (section 1.1 and 2). Besides GANTT chart visualizations the user can create alternative process structure visualizations by uploading one or more images. The user is able to cut up the image by drawing lines or using pre-defined shapes which are dragged and resized on top of the image like transparent nodes. Each image (or each transparent node on the image if the image is cut up) represents a phase which has to be tagged. Users can add pre-defined shapes and link it phases and tasks with arrows.|
|Adding Tasks to the Process||Tasks and subtasks can be added either in the Process View or in the Content View. The task automatically gets the tag of the phase. Subtasks inherit the tag from the parent.|
|Display the alternative Process View in form of a GANTT||Presentation of an Alternative Process View as a GANTT chart. Users can open both process views at the same time and can switch between different views. Users are enabled to define the default process view which is displayed first.|
|Modification of an alternative Process View||An existing alternative Process View can be modified (delete, change position etc.) in the Content View as well as in the Process View. Tasks can be dragged from one phase to another phase. They change their tags according to the phases. Additionally, if phases are in causal relations, moving a task means significant changes in its starting/finishing time constraints. The user should be aware of that and should be enabled to adapt the properties according to the new time constraints.|
|Saving an alternative Process view for later re-use||An Alternative Process View should be saveable for later re-use it from the re-use library. To be discussed: Intended processed could be compared with the structure of the real processes. TUK: interesting suggestion for AKMS.|
|Using tags||Tags can be used as any tag from any vocabulary, i.e. they can be searched for, they can be used in the content view for tagging tasks and content items etc.|
|Display of the alternative Process View in the Content View||Phases and tasks of the Alternative Process View are presentable in the content view. Both (phases and tasks) are visualized in different manner to make them distinguishable. In the Content View the relation of parent tasks and subtasks could be displayed as hierarchical black links.|
|Focusing on a particular phase by opening the Tailored View||When clicking onto a phase a tailored view which presents all the tasks in that phase but also all content items, notes etc. appears.|
Here comes some more ideas that UH generated. The phases are not strict in time sense, i.e. these are sort of general structure of the process, which can (and often does) occur in different order than what the phases are in the image. The phases include different kind of actions/tasks out which most come into play in some time within the over all process but the order is not predefined. One reason for this that the users will return repeatedly to some phases and activities/tasks in these phases. Lets say that one of the phases holds a task of setting hypothesis or problematizing the domain of research. This might be done early in the process but is also something that users frequently return to.
For example there might be a need to have discussion or brainstorming of a topic that is not defined yet where it would belong to in the process, it is just know/felt that it is important to raise up. Thus the users create a task for it but do not know exactly when it should be done - when they will reach the moment that they can start doing it. Or it is sort of ongoing activity (this ongoing activity could be, though, presented as the phases i.e., cutting all across the time set for the course/project/ research/whatever. (Minna can continue this she had a good example that does not come to my mind clearly at this moment). If this no-start-end date task is possible then it would be needed that it has a different visualization - like TUK mentioned (line in GANTT).
In many inquiry-type or problem-based educational practices the phases of the process (e.g. in ProblemBasedLearning seven "steps") are modeled for the students as sort of a conceptual tool that helps them understand the logic of activities. But in the course practices, the phases have no strict time constraints like in waterfall type project practices (which are easy to model by GANTT) that can be defined beforehand; e.g. a group might stay in the problem clarification phase as long as they decide that they have managed to define the problem well enough to go on; and they may have to return to that phase or iteratively do it again in later time when they go deeper into the phenomenon. It is like in innovation processes where you cannot predict or plan in advance when the innovation is ready and how much it takes to make it. In such practices, the visual process view is partly sort of a "to do -list" but it models in higher conceptual level the whole process and its critical phases. Perhaps in such practices the process view and task definitions are used more like coordination and reviewing purposes than for planning purposes - e.g. to structure and organize (or re-organize later) tasks and created knowledge according to the central phases of the overall process or to make decisions when to go on (e.g. from problem definition to start searching information from knowledge sources for finding answers to the defined problems). Or the teacher wants to give the whole process structure for the students but defines concrete deadlines for each phase bit by bit when the process goes on, according to the progress of students' work. I organize my courses always that way; no strict deadlines beforehand but they are agreed on together phase by phase during the course, depending on what comes out of the students' work.