The following is a draft of user requirements for History and Participation Awareness in Shared Space M24 specifications. You can download the MS Word version for easier reading, but it will not be as up-to-date as this wikipage (i.e. changes will be recorded here, but not in the MS Word version): Please add comments to this wikipage for a more transparent and easier manner of communication. If we use MS Word, there will be too many versions circulating via email. Please make your comments by the end of your workday on 16.01. Liisa B. will try to synthesize your comments after that. If you are not able to use the wiki, please use the MS Word version and email the whole group.


  • EVTEK Liisa Benmergui
  • UH Minna Lakkala
  • UH Seppo Toikka
  • EVTEK Merja Bauters
  • FH-OOE Eva Zöserl
  • TUK Jan Paralic
  • TUK Jozef Wagner
  • TUK Frantisek Babic
  • UU Patrick Sins
  • UiO Trond Eilive Hauge
  • UiO Svein Olav Norenes
  • UU Patrick Sins

2 Purpose and Scope

After discussion with pedagogical partners Helsinki University, EVTEK and FH-OÖ, as well as the technical partners at TUK, a sketch of the user requirements for the History and Participation Awareness was created. All schematics and sketches included in this document are only used as guidelines and will be further discussed once the actual specifications have been formulated. The graphics, as well as look and feel will be further discussed with Tessera in order for the consistency to be apparent between the envisioned features and the rest of the Shared Space Application’s GUI.

The document has been divided into some sort of priority areas. There is a section that has already been labelled as “Future User Requirements”. These requirements are to be discussed further and will feed into the DOW3 discussions of the WP leaders.

3 Background

3.1 Defining history and participation awareness

There seems to be several levels to awareness. Real-time workspace awareness has already been discussed within the Awareness sub-knot. Since all actions that have taken place are seen as “history” we can see that there is a need for awareness:

1. Within the Shared Space Application; and,
2. Outside of the application itself.
FB: Point 2. means other KP-Lab applications, e.g. SMAT?
Eva FH-OÖ, 16.1.: I think RSS feeds and mail notifications outside KP-Lab tools were meant. (see sec. 5.2)

Participation awareness can be defined as finding answers to the following questions:

1. How has a person participated within a given shared space?
2. How active a group has been?
3. How active a member of a group has been?
(Minna 16.01.08) Not only members' activity in general but also position in the community's activities, mutual commenting, co-working and interaction which creates the social structure of the groups' virtual work: How is the structure of mutual interaction of the participants constructed? We have Social Network Analysis methods, e.g. Multi-Dimensional Scaling graphs, to be used for that. But this is perhaps for DoW3.
Eva FH-OÖ, 16.1.: I would also appreciate the idea of integrating visualization of social networks (e.g. regarding collaboration/cooperation, communication, ...). I agree to keep it in mind for later releases, but I am afraid that such features could be very time-consuming for the developers? (Svein Olav 16.01.08) I find this interesting from a research point of view. At the same time my understanding of awareness as features/functionality within a group work/learning system is about visualizing information from others work and contributions making it possible for collaborators to pickup this, contribute further.. and so on. For me members position and com and structures surronding mutual interaction are more like research questions that we could ask when analyzing emprical data (videorecordings etc.) from the cases. I am curious whether this actually would be possible and realistic to implement as a feature?
FB: Several graphic visualizations (maybe SNA or some other methods for analyses of communities) are planned for next development phase (DoW3) and in this moment it is possibility to use tool called "Data export for analysis tool" that will produce information as matrix of the contribution that people made on content items created by other participants.

3.2 Real-time awareness vs. history awareness revisited

The following was stated in the Real-Time Workspace Awareness User Requirement documentation.

There is a fundamental difference between what we refer to as “real-time awareness” and “history”.

Real-time awareness has mainly to do with the current session events. A session begins when a registered user logs into KP-Lab portal and enters a shared space. They then interact with the Shared Space tool as a known member of certain or no shared spaces. They can be identified and certain information about their activities is monitored by the System and broadcast for other users to see in different manners, either visual, auditory or textual signals can be detected by other users as to each others’ activities in the shared space.

History is something different, although closely tied to many of the ideas discussed within this document. During the brainstorming of these requirements, history was seen as more like “recent changes” and while the session info can be seen as recent changes, it seems to be a bit more detailed and time dependent, not to be filtered out, but rather a transcript of the activities that have taken place since a user has logged into a shared space.

A main concern within this working knot is that the history logs of occurrences within a shared space should be kept and made searchable. The real-time workspace awareness features of the Shared Space Application have this type of logging as one of their future requirements. The possibility to peruse the history of the complete shared space would allow the user to see the events and details as to who, what and when concerning the event. E.g. Liisa B. added a content item of type weblink (URL) at 15:30 on 14.01.2008. (The order of the aforementioned information, as well as how it is visualised can be discussed.)

4 Different types of history

The history should be on the following levels:

1. Shared space history
2. Object history
3. Person history

4.1 Shared space history

Users will want to know history about a shared space and its past. The types of actions/events that are logged would give an overall picture of how this shared space has been created/modified.
Eva FH-OÖ, 16.1.: From my point of view the shared space history contains all information concerning additions, modifications, deletions of everything which can be inside a SSP (including content items, persons, task, metadata, vocabulary, ...). As the SSP contains content items etc. there are overlaps to Object History.
(Svein Olav 16.01.08) From a user perspective space-level would normally relate to a level concerning space details (name, description, metadata, theme/color, visual look config..), person/members permission/rights, and operations like copy/export space so on. A log of activities on this level would normally be more of a concern for administrators. In SSP things seems to be a bit different. Creating spaces are more part of the knowledge building and work activity than what might be typical. As such i think that the space and the task/content/knowledge objects are getting close to one another. I agree, being able to view a history of instantiation, deletion and versioning of content objects and tasks might make sense on the space level.

1. Changes to a shared space itself
a. Metadata such as Title changes
b. ???? Need more info about this by ped partners
(Minna 16.1.08) Perhaps the summative information could be in this level (relates also to the Data export for analysis tools): statistical summaries about objects, persons, actions, social network analysis results etc...
2. Changes to objects (content items, tasks, links) within the shared space*. *Seems to overlap with “4.2 Object History”
(Minna 15.1.08) Does this mean a list of all changes in a ssp presented e.g. in cronological order, categorized according to object types (by demand) or filtered sub-list (by demand) of some changes?
FB: From technological point of view we plan some types of categorization (maybe grouping based on time, days, objet type, etc.), because this approach bring more simply visualization in situation that user has a lot of notifications.
a. Addition
b. Modification
c. Deletion
d. Comment added
e. (Versions)
3. Changes concerning persons within the shared space
a. Addition of persons to a shared space
b. Removal of persons from a shared space
4. Changes of vocabularies
a. Additions
b. Modifications
c. Deletions
d. (Versions)

4.2 Object history

This seems to overlap with the shared space history point #2. This section needs clarification by ped partners.
(Minna 16.1.08) This means history info of one chosen object when user is inside the ssp?
Eva FH-OÖ, 16.1.: Yes, for me it means the history of one single object / content item which is inside the SSP. The user has not to be inside the SSP necessarily - for example a user creates a RSS feed in which he defines to be notified when someone changes a certain object inside the SSP. Another example: a user right clicks onto a content item and then all changes of this certain item will be shown/listed.
Eva FH-OÖ, 16.1.: While the shared space history would contain all additions, modifications, deletions regarding everything which can be inside a SSP (content items, comments, tasks, persons, vocabularies), the object history only contains information concerning the choosen object.
(Svein Olav 16.01.08) To separate object history from space history by being able to view only history within one single object makes sense. At the same time you would then need to exclude/include attributes from some objects. Like discussed briefly in the v-meeting, there should maybe be done some classification and possible grouping of different kinds of objects. E.g. content objects like wikis, discussions-rooms, notes and so on are more developing objects that are instantiated and made numerous editions and contributions to over time. These will need (and normally do provide on their own) different attributes than e.g. a file or link will.

1. Changes to objects (content items, tasks, links) within a shared space
a. Additions
b. Modifications
c. Deletions
d. Comments added
e. Changes to the metadata; e.g. tags
f. (Versions)
(Minna 16.1.08) What changes can be listed of one object besides changes in metadata (e.g. we do not know what changes has been done inside a file; only through versioning)? Who had done the change, when has the change been done, relationships (links) added and deleted attached to the object ...
FB: Yes, changes inside a files can be discover only through versioning that will be implemented for knowledge and content repository. In actual version of TLO are some properties, that can be used for proposed purposes, e.g. dc:modified (date/time of modification). )

4.3 Person history

1. Which content items the person has opened/viewed?
2. Which groups the person has been active in?
3. FB: Which tasks have been assigned to this person?
4. Eva FH-OÖ, 16.1.: Which content items the person has modified/deleted?
5. (Svein Olav 16.01.08) A persons editing activity/frequency on single objects?

4.4 Visualisation of the history

It should be possible to visualise the history at the minimum as some sort of list. Graphical interpretations could also help the user, e.g. a timeline style of visualisation. The user should be able to view the history with respect to time (i.e. chronologically) or categorised by person, object, object type, etc Eva FH-OÖ, 16.1.: or also by date / timespan.

An example of timeline can be seen in figure 1.

Figure 1: A screenshot of timeline navigation. Timeline slider at the far right of image. (Click on image to see full-size.)

(Minna 16.1.08) Is this possible only in ssp-level (4.1)?

5 Notifications as awareness

5.1 Receiving notifications when interacting with Shared Space Application

A user should be able to interact with the Shared Space Application and receive notifications directly within the Shared Space Application. This type of requirement is being partially fulfilled with the M24 release of the real-time workspace awareness features. There are two basic extensions of such features:
1. The possibility of tailoring the notifications to only certain types of events. See Appendix A for more info about Session log information.
2. Being able to view a full history of all that has happened and then filtering this history. This type of feature is very similar to the idea proposed in section 3.2 of this document.

5.2 Users receive notifications when not interacting with Shared Space Application

Users should be able to receive notifications when they are not directly interacting with the Shared Space Application. They can receive these notifications via email or RSS feeds. These 2 types of notification systems must be able to be tailored/modified through some type of GUI component within the Shared Space Application. See section 5.3 for more details.

5.3 Tailoring notifications

Choosing how the user is made aware of changes to a certain shared space and what it contains (at the different levels mentioned in section 4) should be made possible through some type of GUI component.
  • It should be possible to group events to be notified about in order for the user to be notified about different things in the different possible manners (direct notification through a component within Shared Space Application or via email or via RSS feed).
  • The user should be to able to choose what they would be notified about with respect to each shared space, object (content item or task) they choose to be notified about.

5.4 User interface mock-ups

The following are some examples of how the user could interact with the GUI in order to add new objects to be notified about or manage existing notifications. In figure 2, we see how the user can select one or more objects within a view of a shared space and then right-click to choose to be notified about changes that occur to these objects. The user is then prompted to choose the "parameters" (what they want to be notified about) and "how" they want to be notified. (No image is currently available for this step.) The user can then manage these settings from the "Preferences" area found in the UI of the Shared Space Application (see figure 3). The user does not have to be logged in to manage their notifications.

Figure 2: An idea of how the user could add objects to be notified about from within the content view in the SSGUI. (Click on image to see full-size.)

Also, notifications can be on 2 levels:

1. shared space specific
2. or then what we can call "customised notifications", which are notifications that can be from any shared space.

An idea was to have some sorts of default notifications that can then be personalised by the user, so that they would not need to start to create all RSS feeds from scratch. In this way, the user can modify the pre-existing notifications (e.g. notify about all changes) and remove the types of objects or whatever from the list. The use of some sort of filter when viewing what objects/persons are being notified about will help the user to view the list in an easier manner.

Figure 3: An idea of how the user interface could work when managing the notifications. (Click on image to see full-size.)

6 Future user requirements

There are several user requirements that cannot be specified in the M24 technical specifications and have been grouped under the above heading. These user requirements will feed into the discussion surrounding writing DOW3.

Topics to be discussed:

  • Versioning of content of objects within a shared space
  • Versioning the changes to the actual node within a shared space; e.g. the metadata attached to content item node
  • Creation of (email/RSS) notifications with the use of “saved searches”. This idea deals with the integration of the Semantic/Free Search/text mining features being developed within KP-Lab.
  • Overlaps with the Data Export tool being developed for M24
    • The fact that the Data Export tool could be used as an export of a summary of events that have occurred within a shared space. It allows for the users to be aware on a more holistic level of the occurrences within a shared space.

Appendix A

Excerpt of RT awareness doc: Current Session Information

At the moment users using Shared Space Tool are able to see certain actions performed by other users. These actions include when one user moves a node within Process View, Content View or SSp Network, the others can see the node move across the screen with the name of the user displayed as being attached to the node. Also, if a user is editing a node, there is a hint to others that that node is “locked by user X”.

While these have been the first steps toward real-time awareness, we will elaborate on further requirements.

The list of activities within the SSp should include such things as were mentioned in chapter 3.1:

  • User is moving object A to a new location within e.g. content view.
  • User is editing an object’s contents (e.g. wikipage, note)
  • User is modifying an object’s metadata (this includes e.g. semantic annotations, start/end dates of tasks, titles, etc)
  • User has created a link between objects
  • User is adding/has added a comment

Once a user has logged into KP-Lab system, there is a live transcript of events during the session that is constantly updated with the information that the System has been monitoring and is broadcasting to all other users that are currently inside that Shared Space. This transcript-type list is very closely tied to “Recent Changes” as was mentioned in chapter 3.2, but there is a difference in the way these two lists work.

  • The “Current Session Info” is always in real-time and lists all the aforementioned events as they occur, chronologically.
  • Each activity that is logged is interactive in the sense that e.g. User A has just uploaded a file, User B has been online and notices this event in the current session info and can choose to view this newly uploaded file.
  • E.g. User A is editing Content Item X. User B sees this in the real-time transcript and chooses to start a chat based upon this item in the list. This is what we refer to as a “context-based” chat. Please see chapter 6 for further details about the chat.
  • The Current Session Info is not saved as such. The changes that occur to any objects within Shared Space are saved, but information about a session is not saved. E.g. when a user first enters a shared space that they have rights to access, they will find the “current session info” area blank. Upon entering the shared space, the user will begin to receive notifications of all activity specified earlier within this document.
  • E.g. Once a user leaves the shared space, they would be able to view the “recent changes/history” in order to find out what has happened within the shared space since they were last there. This is something that is not in the scope of these requirements. It is only added here for clarification of the real-time awareness requirements.

M30 History Participation Awareness
  Page Info My Prefs Log in
This page (revision-45) last changed on 18:24 25-Mar-2017 by merja.
JSPWiki v2.4.102