For example, after uploading a document, the user would probably anticipate that it will be read or modified; after making a poll, he probably waits for others to vote on it. Usually this anticipation also has a certain time limit, within which the activity should take place. We call this anticipation an expectation. After an expectation is being created, the creator can either decide to notify the team members involved in the workspace about the expectation or to keep the expectation to himself. In addition, a periodic alarm mechanism is set to test Fig. As long as the expectation is not fulfilled, the periodic fulfillment tests are performed until the expectation end time.
At the end time the last fulfillment test is performed and when the expectation is not fulfilled, a nonfulfillment message is sent. If the expectation gets fulfilled, the periodic test mechanism stops and waits for the expectation end time to send the fulfillment notification. In practice, we model an expectation as an object with six basic attributes: creator, artifact, activity, participants, start date, and end date.
Additional attributes can be defined to extend the usability and flexibility of an expectation. For example, a selection of a preferred notification mechanism or an option to inform the involved collaborators of an expectation is thinkable. The values of these attributes will be specified by the user when a new expectation is created. An expectation changes its state after the deadline.
The three basic possible states are initial before the deadline , fulfilled, or nonfulfilled after the deadline.
An expectation itself, as any other object in the system, has operations to manipulate it. We consider as essential operations create, edit, delete, check fulfillment, and view fulfillment status Fig. In the following we describe the major attributes of an expectation in more detail: artifact, activity, and participants. We distinguish between a single artifact and a container of artifacts. A single artifact is an object that can be uploaded to or created in a workspace, such as a document or a note.
- My Library.
- Reform and Change in Higher Education: Analysing Policy Implementation (Higher Education Dynamics).
- Publisher Description.
- Web development design.
- Neuroscience of Pain, Stress, and Emotion. Psychological and Clinical Implications!
- Books > Electrical Engineering + Electronics!
- Equipos diagnostico - bionet.
A container of artifacts is a collection of artifacts, such as a folder, a blog, or a discussion. For a set of artifacts, users should be able to decide whether the expectation is fulfilled when the expected activity takes place in all artifacts or in at least one of the artifacts. This selection will often depend on the expected activity itself.
It is obvious to expect, for example, that the read operation will take place in all documents in a folder while the modify operation only on at least one of them. An exceptional activity for this matter is the create activity. The create operation can be expected only in a container, such as a folder. Another consideration of interest is the case of a hierarchical structure of objects.
Publikationen Kompetenzmanagement | Kompetenzen gestalten - Christine Kunzmann
Then it must be decided whether the activity should take place only in the uppermost level or in the whole hierarchy. The list of possible actions is the operational semantics of a chosen artifact with respect to the chosen participants. In other words, these are the operations available on the chosen artifacts for the chosen participants in accordance with the access rights of the latter. In case of an artifact containing other artifacts e. For members of a group or a role it should be decided, whether the expectation should be fulfilled by a role or by a group.
Further, one must consider if the expected activity should be performed by all members or by at least one member inside of a role or a group.
Again, this definition might depend also on the activity itself, since it is quite natural to expect, for example, that the read operation will be performed by all members of a role or a group while the modify operation by at least one of them. A user can decide whether he wants to make an expectation be visible to the other participants or not.
By making an expectation visible, the user implicitly announces to other members what kind of activities he expects them to perform in a workspace.
The intention is to establish a better understanding of the expected activities among the members of a project. This use of an expectation makes it very similar to another formal method of project management: task assignment. We would like to emphasize the differences between the concept of an expectation and the concept of a task.
These are the intention, the level of necessity, and the agreement of the participant assigned. The main intention of a task is specifying the work needed to be done and assigning it to a certain person or number of persons. The main purpose of an expectation is providing better awareness on anticipated activities in a workspace.
From CSCW to Web 2.0: European Developments in Collaborative Design
Creating an expectation supports the automatic summarization of events that the user is looking forward to occur in a workspace until a certain deadline. Currently this information can be obtained only manually by looking at the history of events. The one who assigns a task should have the sufficient authority, while anyone in a shared project can have expectations from his colleagues.
Tasks have to be performed as a duty, while an expectation is just a lightweight representation for looking forward to a certain action. During an expectation creation the collaborators not only do not have to agree to the expectation, but in most cases they do not have to know about an expectation. An expectation is just an expression of what its creator believes should happen in a workspace and an easy means for being informed whether it happens or not. First we give an overview of the BSCW system — the baseline system for our implementation.
Then we provide a detailed description of the user interaction and user-interface of expectations feature. Shared workspaces are established by groups of people to organize and coordinate their work. In general, a BSCW server manages workspaces for different groups, and users may be members of several workspaces e. A workspace may contain different kinds of information, represented as information objects arranged in a hierarchical order. The objects may be of various types such as folders, URL links to Web pages, documents such as graphics, spreadsheets, and text documents, discussion forums, opinion polls, tasks, or user-specific address books and calendars.
The system allows numerous operations — usually depending on the object type — that can be applied to objects, e. Authentication algorithms include basic authentication, cookie authentication, and X. Version Management Documents within a workspace can be put under version control which is particularly useful for joint document production. Documents may be locked to refrain from others replacing them. Access Rights The system contains a sophisticated access rights model using the notion of roles.
Roles define access profiles and can be attached to any object in BSCW. This way, for example, some users may have complete control over an object in a workspace whereas others have only read access or no access at all. Discussion Forums Users may start a discussion on any topic they like and the system presents the threads in a user-friendly manner. Community Support BSCW supports so-called communities of interest which provide a new mode to bring people of common interests together for exchanging information. Communities can be open to self-subscription or semi-open where interested users have to apply for membership with the community managers.
Opinion Polls Users may create and manage polls. Polls provide means to collect and evaluate the opinion of other users on certain topics. BSCW provides an interface for editing, executing, and evaluating polls. Polls may be accessible to the general public or to the members of a workspace only. Event Notification The event service of the BSCW system provides users with information on the activities of other users, with respect to the objects within a shared workspace. Events can be confirmed on a per-user basis at different levels, from individual objects to complete workspace folder hierarchies.
Likewise event notification can be filtered on a per-object basis; this is to reduce both the 12 W. The entire history of artifacts cannot be removed from the system except by a system administrator and may be inspected at any time. Upon user request direct email notifications are issued as soon as an event occurs. Synchronous Event Notification An optional applet supports real-time synchronous awareness about who is logged on and what events are produced.
Consequently, the expectation feature was implemented as a BSCW package consisting of various class definition modules, utility routines and user-interface modules, XHTML templates, and cascading style sheets.
The kernel software of BSCW was left unchanged. The same icon will indicate the state of further expectations created on an object. To promote an intuitive understanding of icons meaning, we have chosen to represent the meaning with colors matching standard signals of fulfillment green — , nonfulfillment red — , and not yet decided yellow —. This allows quick creation and editing of expectations. The email notification, however, will only be sent at the chosen end time.