Tasks Sub-System <Not fully implemented yet!>

Fablusi™ is task driven. The set of tasks designed by the simulation creator helps:

  1. scaffolding the learning process,
  2. providing concrete work for assessment and evaluations,
  3. providing just-in-time resources,
  4. information sharing mechanism, and
  5. triggering

Types

Basic: Tasks which are predefined for a simulation. Any moderator will inherit such tasks. Basic tasks will be saved in the packaged simulation.

World: tasks which are added at anytime by a moderator. World tasks can be saved as patch (not part of the packaged simulation)

Dynamic: They are generated as a result of other tasks (either by the same role or other role).

Application

Any type of task can apply to any combination of roles. World tasks only apply to roles in the world in which it is defined or loaded by the world moderator. Dynamic tasks also apply only to the world in which they are generated.

Switching on

Basic Tasks are staged. World task can be staged or created on demand by moderator. Dynamic tasks are always created dynamically.

Staged tasks in a world are switched on when the simulation enters the triggering stage as defined by the creator of the simulation.

Switching off

All the three types of tasks can be switch off by any ONE of the following conditions as set when the task is created:

  1. only at the beginning of a nominated stage
  2. only when completed
  3. stage change or completion, whichever comes first
  4. never switch off

Task Action

  1. instruction to the role (taken from the task description) with completion button
  2. pointing to some resources and reading material without completion button (URL of resources or reading material needed)
  3. pointing to some resources and reading material with completion button (URL of resources or reading material needed)
  4. Writing task (with temporary save and completion button). The result emails to world moderator
  5. Writing for other roles to read (with temporary save and completion button). The result becomes a dynamic task to specified roles to read
  6. Writing for other roles to read via another basic/world task (with temporary save and completion button).
  7. Reading of writing by other roles unconditional of completion of specified task
  8. Reading of writing by other roles (completion of other roles indicated, but writing can be read only after completion of specified task)
  9. Jump to another simulation (transparently transfer the username and password with world ID specified by world moderator)
  10. Arbitrarily HTML forms for email submission to world moderator.
  11. QPLUS items. The items can be in the form of "arbitrarily HTML forms". Before a role submit/commit the task, the read items button will only indicate whether the other roles have/have not completed the task. The role cannot read the result of the other role's work. However, after submit/commit, the role can read the response(s) by other role(s). This is for sharing information after the role has submitted/committed his/her attempts. The authoring requirement of the arbitrarily HTML form is same.

Work space

The task's work space can be the mainframe, the whole window or a new window.

Look and feel

 

Design guideline for "Arbitrarily HTML forms"

  1. Create the HTML form using any HTML editor and observe the following restrictions.
  2. Only the <body> part of the HTML document will be needed. The <body> tag itself is not needed. The ending tags are not needed too.
  3. The <form> tag must be without action and method, in small case like this: <form>; no space between the tag marks and the word.
  4. Immediately after the <form> tag, insert a hidden field to indicate the field names to be sent to world moderator using this format:

  5. <input type=hidden name=EmailFields value=Q1|Q2|Q3>

    where all the field names are separated by the pipe character (|) in the value attribute (Q1|Q2|Q3 is an example only). This input field must be called EmailFields (in one word) and no field to be sent can take this field name. Only these fields will be restored if "store temporarily" were used last time.

  6. The submit button must be called "DataAction" and may have up to two with any of these values:

    "Store temporarily" & "Submit"