Group Network block

2014-02-21T20:53:30Z

2014-02-20T16:50:38Z

Valeryf: /* Moodle 2 additions */

The User Mnet Hosts block (non standard) is similar to the Mnet Hosts block except it only gives access to MNET hosts where the
user is allowed to jump to. Custom user profile fields will be used in a dedicated category to control
which hosts are in the scope of the current user.

The block provides its own tools to install significant user custom fields and custom field category
in Moodle so the MNET output can be controlled.

At its stage of developement, hiding a MNET in list of possible destination should not be considered as sufficiant in terms of security. These are not security doors, but a way to provide intelligible navigation to users depending on there profile.

A further securisation of the door is in development plans. (back check through web service)

==Moodle 2 additions==

the User Mnet Hosts block for Moodle 2 has integrated two major additions :

* Handling of Mahara links with some variants
* Support for the MultiMnet authentification method (auth/multimnet)
* For consistency reasons, a local primary administrator (local "admin" account) cannot roam to other nodes, unless a hardcoded configuration key is enabled ($CFG->user_mnet_hosts_admin_override).

Note : The special case where an admin account would be allowed to roam is for a global network administrator. The origin moodle of such global administrator should be unique in the whole MNET network.

==Prerequisites==

No mandatory prerequisites.

Optional prerequisite : When using MNET and managing individual access, it may be worth to get consistant user profiles including custom fields. As access control fields used by User Mnet Hosts are custom fields, this makes sense.

the patch discussed at http://tracker.moodle.org/browse/MDL-24549 proposes a simple patch to get user custom fields synchronization, pursuant they have been configured consistently in each MNET node.

Using this patch will allow users to bring their access allowance whereever they are in a Moodle Network.

The Multimnet authentification method is a prerequisite for building a full wired MNET moodle array.

==Installing==

Install the block as usual:

1. Unzip the block package within the ''blocks'' directory of your Moodle installation.

2. Browse to the Administration -> notifications menu.

==Preparation==

For the block to operate properly, you need generating relevant access field for each
known MNET host in the neighbourhood. This is called synchronizing the block with
the MNETwork configuration.

==Settings==

===Global settings===

* Access to the synchronisation tool.
* '''Mahara pass thru:''' When enabled, will not apply per user access rule to mahara registered applications. If not enabled, a registered Mahara will behave as any other registere application and will e controled on a per user basis.

Other operations of the global settings:

The global settings will automatically create a default category for regitering access profile fields, and will create the local moodl access field.

===Instance settings===

there are no instance settings.

==Normal operations==
===Using a block instance===

Just add an instance of this block instead of the standard Mnet Hosts block to limitate
the network view to allowed targets.

===Giving users access to an host===

Edit the profile of users to check or uncheck the access fields matching the hosts you allow
the user to see. You might change the custom fields settings for convenience so new users are
implicitely allowed or disallowed for a particular host.

==Capabilities==

* '''block/user_mnet_hosts:addinstance:''' Allows owner of this capability to add an instance in a course or front page
* '''block/user_mnet_hosts:myaddinstance:''' Allows owner of this capability to add an instance in the My page
* '''block/user_mnet_hosts:accessall:''' Access to all joinable nodes unconditionnally (administrators).

User Mnet Hosts block

2014-02-20T16:47:19Z

Valeryf: /* Normal operations */

The User Mnet Hosts block (non standard) is similar to the Mnet Hosts block except it only gives access to MNET hosts where the
user is allowed to jump to. Custom user profile fields will be used in a dedicated category to control
which hosts are in the scope of the current user.

The block provides its own tools to install significant user custom fields and custom field category
in Moodle so the MNET output can be controlled.

At its stage of developement, hiding a MNET in list of possible destination should not be considered as sufficiant in terms of security. These are not security doors, but a way to provide intelligible navigation to users depending on there profile.

A further securisation of the door is in development plans. (back check through web service)

==Moodle 2 additions==

the User Mnet Hosts block for Moodle 2 has integrated two major additions :

* Handling of Mahara links with some variants
* Support for the MultiMnet authentification method (auth/multimnet)

==Prerequisites==

No mandatory prerequisites.

Optional prerequisite : When using MNET and managing individual access, it may be worth to get consistant user profiles including custom fields. As access control fields used by User Mnet Hosts are custom fields, this makes sense.

the patch discussed at http://tracker.moodle.org/browse/MDL-24549 proposes a simple patch to get user custom fields synchronization, pursuant they have been configured consistently in each MNET node.

Using this patch will allow users to bring their access allowance whereever they are in a Moodle Network.

The Multimnet authentification method is a prerequisite for building a full wired MNET moodle array.

==Installing==

Install the block as usual:

1. Unzip the block package within the ''blocks'' directory of your Moodle installation.

2. Browse to the Administration -> notifications menu.

==Preparation==

For the block to operate properly, you need generating relevant access field for each
known MNET host in the neighbourhood. This is called synchronizing the block with
the MNETwork configuration.

==Settings==

===Global settings===

* Access to the synchronisation tool.
* '''Mahara pass thru:''' When enabled, will not apply per user access rule to mahara registered applications. If not enabled, a registered Mahara will behave as any other registere application and will e controled on a per user basis.

Other operations of the global settings:

The global settings will automatically create a default category for regitering access profile fields, and will create the local moodl access field.

===Instance settings===

there are no instance settings.

==Normal operations==
===Using a block instance===

Just add an instance of this block instead of the standard Mnet Hosts block to limitate
the network view to allowed targets.

===Giving users access to an host===

Edit the profile of users to check or uncheck the access fields matching the hosts you allow
the user to see. You might change the custom fields settings for convenience so new users are
implicitely allowed or disallowed for a particular host.

==Capabilities==

* '''block/user_mnet_hosts:addinstance:''' Allows owner of this capability to add an instance in a course or front page
* '''block/user_mnet_hosts:myaddinstance:''' Allows owner of this capability to add an instance in the My page
* '''block/user_mnet_hosts:accessall:''' Access to all joinable nodes unconditionnally (administrators).

User Mnet Hosts block

2014-02-20T16:43:22Z

Valeryf: Created page with "The User Mnet Hosts block (non standard) is similar to the Mnet Hosts block except it only gives access to MNET hosts where the user is allowed to jump to. Custom user profil..."

The User Mnet Hosts block (non standard) is similar to the Mnet Hosts block except it only gives access to MNET hosts where the
user is allowed to jump to. Custom user profile fields will be used in a dedicated category to control
which hosts are in the scope of the current user.

The block provides its own tools to install significant user custom fields and custom field category
in Moodle so the MNET output can be controlled.

At its stage of developement, hiding a MNET in list of possible destination should not be considered as sufficiant in terms of security. These are not security doors, but a way to provide intelligible navigation to users depending on there profile.

A further securisation of the door is in development plans. (back check through web service)

==Moodle 2 additions==

the User Mnet Hosts block for Moodle 2 has integrated two major additions :

* Handling of Mahara links with some variants
* Support for the MultiMnet authentification method (auth/multimnet)

==Prerequisites==

No mandatory prerequisites.

Optional prerequisite : When using MNET and managing individual access, it may be worth to get consistant user profiles including custom fields. As access control fields used by User Mnet Hosts are custom fields, this makes sense.

the patch discussed at http://tracker.moodle.org/browse/MDL-24549 proposes a simple patch to get user custom fields synchronization, pursuant they have been configured consistently in each MNET node.

Using this patch will allow users to bring their access allowance whereever they are in a Moodle Network.

The Multimnet authentification method is a prerequisite for building a full wired MNET moodle array.

==Installing==

Install the block as usual:

1. Unzip the block package within the ''blocks'' directory of your Moodle installation.

2. Browse to the Administration -> notifications menu.

==Preparation==

For the block to operate properly, you need generating relevant access field for each
known MNET host in the neighbourhood. This is called synchronizing the block with
the MNETwork configuration.

==Settings==

===Global settings===

* Access to the synchronisation tool.
* '''Mahara pass thru:''' When enabled, will not apply per user access rule to mahara registered applications. If not enabled, a registered Mahara will behave as any other registere application and will e controled on a per user basis.

Other operations of the global settings:

The global settings will automatically create a default category for regitering access profile fields, and will create the local moodl access field.

===Instance settings===

there are no instance settings.

==Normal operations==
===Using a block instance===

Just add an instance of this block instead of the standard Mnet Hosts block to limitate
the network view to allowed targets.

===Giving users access to an host===

Edit the profile of users to check or uncheck the access fields matching the hosts you allow
the user to see. You might change the custom fields settings for convenience so new users are
implicitely allowed or disallowed for a particular host.

Cognitive operator: 2D Mapping

2014-02-16T17:31:50Z

Valeryf: /* Categorize GUI */

[[Cognitive Factory Module|Back to index]]

==Operator==

[[Image:mapping_operator.gif]]

===Complexity level===

Complexity is no more than 2. This is

===Operations===

Summarizes nature of informational operations (exercice types) that can be setup.

===Purpose===

Summarizes the cognitive outcome of using this operator.

==Applications==

===Direct Workflow===

Describes the typical scenario for a Direct Workflow.

===Reverse Workflow===

Describes the typical scenario for one or more Reverse Workflows.

===Meta Workflow===

Describes what pedagogic cognitive concepts can be discovered

==Implementation==

===Setup===

*'''quantifier type:''' quantification can be integer or float

*'''X axix label:''' label for X

*'''X min range:''' lowest value accepted on X
*'''X max range:''' highest value accepted on X

*'''Y axix label:''' label for Y

*'''Y min range:''' lowest value accepted on Y
*'''Y max range:''' highest value accepted on Y

*'''proximity radius:''' Distance value for aggregating input equivalence classes

Teacher options :

*'''blindness: ''' See [[Cognitive Factory Module]] for complete information about blindness and privacy behaviour

===2D Mapping operation GUI===

The essential work asked to students is to report X,Y coordinates as two independant valuators as attributes. The result of the 2D valuation will be to display the input locations on a graphic map, identify equivalency proximities, draw and analyse mediatrix and input spread.

*'''Blind mode:''' For each input, two valuation widgets are provided.
** If quantifier type is integer : use DHTMLx sliders
** If quantifier is float, use standard textual inputs, with number format check.

*'''Semi-blind:''' Same as above, with average statitics : mean of all other answers, and spread indicator.

*'''Full View:''' Same as above, with average statitics : mean of all other answers, and spread indicator, but shown BEFORE inputing data.

===Display GUI===

Describes what can be expected as result display and exploration GUI behaviour for each privacy mode (Blind, Semi-blind, Full view / No privacy).

''Merely Display GUI are visualizing tools aiming at :

* Help participant assess himself against a teacher answer of exists
* Help participant to self-position himself in a group (knowing global trends)
* Help participant to examine the group answer structure anonimized
* Help participant to examine and argue nominatively with peers (full view)
* Observe and find emerging organisations from the group answers
* Discover how some cognitive operations work''

Cognitive operator: 2D Mapping

2014-02-16T17:23:14Z

Valeryf: /* Setup */

[[Cognitive Factory Module|Back to index]]

==Operator==

[[Image:mapping_operator.gif]]

===Complexity level===

Complexity is no more than 2. This is

===Operations===

Summarizes nature of informational operations (exercice types) that can be setup.

===Purpose===

Summarizes the cognitive outcome of using this operator.

==Applications==

===Direct Workflow===

Describes the typical scenario for a Direct Workflow.

===Reverse Workflow===

Describes the typical scenario for one or more Reverse Workflows.

===Meta Workflow===

Describes what pedagogic cognitive concepts can be discovered

==Implementation==

===Setup===

*'''quantifier type:''' quantification can be integer or float

*'''X axix label:''' label for X

*'''X min range:''' lowest value accepted on X
*'''X max range:''' highest value accepted on X

*'''Y axix label:''' label for Y

*'''Y min range:''' lowest value accepted on Y
*'''Y max range:''' highest value accepted on Y

*'''proximity radius:''' Distance value for aggregating input equivalence classes

Teacher options :

*'''blindness: ''' See [[Cognitive Factory Module]] for complete information about blindness and privacy behaviour

===Categorize GUI===

Describes what can be done and operation GUI behaviour for each privacy mode (Blind, Semi-blind, Full view / No privacy).

===Display GUI===

Describes what can be expected as result display and exploration GUI behaviour for each privacy mode (Blind, Semi-blind, Full view / No privacy).

''Merely Display GUI are visualizing tools aiming at :

* Help participant assess himself against a teacher answer of exists
* Help participant to self-position himself in a group (knowing global trends)
* Help participant to examine the group answer structure anonimized
* Help participant to examine and argue nominatively with peers (full view)
* Observe and find emerging organisations from the group answers
* Discover how some cognitive operations work''

2014-02-16T12:19:51Z

Valeryf:

Cognitive operator: Hierarchization

2014-02-16T12:14:43Z

Valeryf: Created page with "Back to index ==Operator== Image:hierachy_operator.gif ===Complexity level=== The hierarchization operator is known as a fractal complexit..."

[[Cognitive Factory Module|Back to index]]

==Operator==

[[Image:hierachy_operator.gif]]

===Complexity level===

The hierarchization operator is known as a fractal complexity level.

===Operations===

1 Arrange ideas in tree

===Purpose===

Tree organisation ask for identifying unique antecedant dependency which results of a non unique resolution of a strict ordering. Hierarchization requires to carefull understand the implicit "classification" mental operation that will conclude in one item being located in a sub branch of a node, thus accepting to belong to this node 'sub classes'.

==Applications==

===Direct Workflow===

# Students input some ideas upon teacher requirement.
# Teacher setup a hierarchization operator with some constraints on tree
# Students perform the hierarchization
# Students comare and analize different solutions of peers, or compare to teacher answer as assessment
# Students argue and report
# Teacher feedbacks individually or collectively and grades

===Reverse Workflow===

===Meta Workflow===

This exercice can be used to discover the difficulty of organizing semantic taxonomies, that will need
a unique resolution of ascendance.

==Implementation==

===Setup===

*'''tree max depth:''' constraints the number of tree layers the information can be organized on

*'''branch max arity:''' constraints the max number of sons a node can have

Teacher options :

*'''blindness: ''' See [[Cognitive Factory Module]] for complete information about blindness and privacy behaviour

===Hierarchize GUI===

*'''Blind mode:'''

*'''Semi-blind mode:'''

*'''Full view mode:''' Same as above, but trends are visible before the participant has answered

===Display GUI===

Describes what can be expected as result display and exploration GUI behaviour for each privacy mode (Blind, Semi-blind, Full view / No privacy).

''Merely Display GUI are visualizing tools aiming at :

* Help participant assess himself against a teacher answer of exists
* Help participant to self-position himself in a group (knowing global trends)
* Help participant to examine the group answer structure anonimized
* Help participant to examine and argue nominatively with peers (full view)
* Observe and find emerging organisations from the group answers
* Discover how some cognitive operations work''

2014-02-16T10:20:38Z

Valeryf: /* Display GUI */

[[Cognitive Factory Module|Back to index]]

==Operator==

[[Image:merge_operator.gif]]

===Complexity level===

Complexity level of this operator is fractal, between 1 and 2, as this is a reduction of set to a smaller scale, while keeping the global meaning.

===Operations===

1. Choose inputs that can be worked together for a reduction.
2. Choose one of the inputs as significant synthesis, or propose a new predicate as merged input.

===Purpose===

Reduction of a large set of input not always can be solved by simple elimination, as some valuable information can exist in less pregnant inputs. The merge operator let eliminate surnumerous inputs, while offerign a way to draw a merged input and keep vlauable information from ideas that will be discarded by the way. This exercice is typical when summmarizing texts or meeting notes and try to keep the essential value of a big mass of information that cannot be handled reasonabiliy.

The operator provides an explicit tool to do this summarizing operation, with adjustable constraints.

==Applications==

===Direct Workflow===

# Students brainstorm and add collectively predicates
# Teacher enables and setup a merge operator, with rest to reduce inputs to some definite number
# Students operate separately the merge on their own merging board
# Students observe and analyse other's ideas
# Student report and argue about what can be valuable
# Teacher feedbacks and grades.

This scenario would be likely completed with a collective final Wiki to produce a final version, collectively agreed
of the summary.

===Reverse Workflow Example===

# Teacher setup inputs to be reduced by students
# Teacher enables and setup a merge operator, with rest to reduce inputs to some definite number
# Teacher merges as a teacher answer
# Students operate separately the merge on their own merging board
# Students report about their merge, explaining and justifying
# Teacher analyses work, by displaying pair match or global view
# Teacher feedbacks collectively or individually and grades.

===Meta Workflow===

This operator can allow teacher to explain the techniques that operate when identifying ideas that could be merged (similarities, redundancy) and can explain how predicates give or not additional informatoin. Teacher can also demonstrate how a merge can be processed as a common cognitive technique to reduce things to essential while having a chance to keep all what is valuable in each original input set.

==Implementation==

===Setup===

*'''number of output:''' The number of final predicates that must be obtained by reduction.
*'''allow source reduction:''' If allowed, students can use the result of one merge to reduce the original source set back.

Teacher options

*'''blindness:''' Defines the privacy level

===Categorize GUI===

The main GUI is dedicated to process to source reduction, by assigning some input ideas to a merge group and choose the merge output for the group.

*'''Blind mode:''' The user will not have any information about the environment.
*'''Semi-blind mode:''' The GUI adds for each input the amount of preselections in the final output of peer answers. The total amount of "new predicates" is also mentionned. Statistics are shown after the participant's merge is done.
*'''Full view mode:''' Same as above, but answer statistics are shown also before participant has answered.

===Display GUI===

*'''Blind mode:'''
** If teacher has answered, then a pair comparison to teacher' choise is shown as assessment.
** If teacher has not answered, the result of merge is shown, with statistics upon the environment.

*'''Semi-blind mode:''' Same as above, with statistics (number of choices as output, new predicates amount). In addition, an anonymized table of individual results with matching indicators.

*'''Full view:''' Same as above, but the global table of results is not anonymized.

Large audience effect :

When the audience becomes too large, the global result tables need to be sliced into pages.

Cognitive operator: Reduction by synthesis

2014-02-16T10:12:53Z

Valeryf: /* Categorize GUI */

[[Cognitive Factory Module|Back to index]]

==Operator==

[[Image:merge_operator.gif]]

===Complexity level===

Complexity level of this operator is fractal, between 1 and 2, as this is a reduction of set to a smaller scale, while keeping the global meaning.

===Operations===

1. Choose inputs that can be worked together for a reduction.
2. Choose one of the inputs as significant synthesis, or propose a new predicate as merged input.

===Purpose===

Reduction of a large set of input not always can be solved by simple elimination, as some valuable information can exist in less pregnant inputs. The merge operator let eliminate surnumerous inputs, while offerign a way to draw a merged input and keep vlauable information from ideas that will be discarded by the way. This exercice is typical when summmarizing texts or meeting notes and try to keep the essential value of a big mass of information that cannot be handled reasonabiliy.

The operator provides an explicit tool to do this summarizing operation, with adjustable constraints.

==Applications==

===Direct Workflow===

# Students brainstorm and add collectively predicates
# Teacher enables and setup a merge operator, with rest to reduce inputs to some definite number
# Students operate separately the merge on their own merging board
# Students observe and analyse other's ideas
# Student report and argue about what can be valuable
# Teacher feedbacks and grades.

This scenario would be likely completed with a collective final Wiki to produce a final version, collectively agreed
of the summary.

===Reverse Workflow Example===

# Teacher setup inputs to be reduced by students
# Teacher enables and setup a merge operator, with rest to reduce inputs to some definite number
# Teacher merges as a teacher answer
# Students operate separately the merge on their own merging board
# Students report about their merge, explaining and justifying
# Teacher analyses work, by displaying pair match or global view
# Teacher feedbacks collectively or individually and grades.

===Meta Workflow===

This operator can allow teacher to explain the techniques that operate when identifying ideas that could be merged (similarities, redundancy) and can explain how predicates give or not additional informatoin. Teacher can also demonstrate how a merge can be processed as a common cognitive technique to reduce things to essential while having a chance to keep all what is valuable in each original input set.

==Implementation==

===Setup===

*'''number of output:''' The number of final predicates that must be obtained by reduction.
*'''allow source reduction:''' If allowed, students can use the result of one merge to reduce the original source set back.

Teacher options

*'''blindness:''' Defines the privacy level

===Categorize GUI===

The main GUI is dedicated to process to source reduction, by assigning some input ideas to a merge group and choose the merge output for the group.

*'''Blind mode:''' The user will not have any information about the environment.
*'''Semi-blind mode:''' The GUI adds for each input the amount of preselections in the final output of peer answers. The total amount of "new predicates" is also mentionned. Statistics are shown after the participant's merge is done.
*'''Full view mode:''' Same as above, but answer statistics are shown also before participant has answered.

===Display GUI===

Describes what can be expected as result display and exploration GUI behaviour for each privacy mode (Blind, Semi-blind, Full view / No privacy).

''Merely Display GUI are visualizing tools aiming at :

* Help participant assess himself against a teacher answer of exists
* Help participant to self-position himself in a group (knowing global trends)
* Help participant to examine the group answer structure anonimized
* Help participant to examine and argue nominatively with peers (full view)
* Observe and find emerging organisations from the group answers
* Discover how some cognitive operations work''