Testing Sandbox

Introduction

This page is used to test some mediawiki stuff, in particular extensions. Some code in here may not work because the extension is disabled for various reasons. Testing ONE.

Testing a new file caching config - july 2013

an external URL tecfa

Collaboration diagram

Two pages <collaborationdia page="Cognitive_apprenticeship;Writing-to-learn"/>

One with a namespace (will break)

RAW

http://edutechwiki.unige.ch/mediawiki/index.php?title=Mediawiki_collection_extension_installation&action=raw

http://edutechwiki.unige.ch/mediawiki/index.php?title=Web_browser&action=raw

Shoutbox test

Extension from http://jimbojw.com/wiki/index.php?title=ShoutBox_Extension

Problem is that anyone from any site can read/post to this id. It would be a good idea to use this code and use a proper php shoutbox something. I have to decide whether to enable or disable yet. Disabled for the moment ....

PageBy test

Default <pageby/>

All minor edits, but no comments <pageby comments="false"/>

No anon, no comments, no creation <pageby noanon="true" comments="false" creation="false"/>

AnyWikiDraw test

Breaks, can't find the file.

Math

The math tag allows to enter complex latex formula.

$\sum _{m=1}^{\infty }\sum _{n=1}^{\infty }{\frac {m^{2}\,n}{3^{m}\left(m\,3^{n}+n\,4^{m}\right)}}$

Note: Some functions do not seem to work. Probably needs some custom installation. Failed to parse (unknown function "\vv"): {\displaystyle \displaystyle\Q{}{t}\iiint\varrho d^3V+\oiint\varrho(\vv\cdot\vvec{n})d^2A=0 }

MetaUML test

This extension was killed for security reasons .... but may be back some day

Test for the uml tag

Diagrams error (with plantuml command): /bin/bash: line 1: plantuml: command not found

Graphviz extension test

See version 22146 (18:52, July 10 2009) for more code....

CoUML

Top contributors

various tests

Bla bla bla bla test after crash .... sandbox2 .. for wilder tests

test after recompil de mysql

Testing my new name: Daniel K. Schneider

Testing (Access restricted)

testing IP registration in recent changes log

template test

He said “no”

Is this true ???

I don't believe this:

bla
bla

That's it

Here is some text:

dfsajaéfdlkfdaj éadflkjfda adfjfdaélkjafd

I don't believe this:

bla
bla

That's it

(Access restricted)

Slides extension test

Code commented because CSS problems

a    b     c  d
d -> e

Les wikis sont

Test citizen science template

Low

Medium

High

Complete

Cs Portal > List of citizen science infrastructures > Experimental tribe - Xtribe -(2018/03/08)

THIS PAGE DESCRIBE A CITIZEN SCIENCE INFRASTRUCTURE

⇾ DISCUSS THIS FORM

⇾ GO TO PORTAL

IDENTIFICATION

Testing Sandbox homepage

Number of project: 12
Number of users:

Start date :

Beta start date : N/A
End date :

Active projects

Retired projects

⇳ Description

➠ Purpose

COMMUNITY

COMMUNITY TOOLS

Communication:
Social Network: N/A
Main news site: http://doc.xtribe.eu

MEMBERS

Visibility of member profiles:: N/A
Member profile elements:

⏣ Description

DEVELOPERS

SOFTWARE

Uses Citizen science software:Citizen science custom software

Provides online tool to create applications: yes

SUPPORT

Provides support team for development: N/A

Provides documentation for development and hosting: yes

MAIN TEAM LOCATION

Loading map...

Rome, Italy

♜ DEVELOPERS TEAM Official team page:
Leader: Vittorio Loreto
Contact: Vittorio Loreto http://socialdynamics.it/vittorioloreto/
+ Information about the team

OVERVIEW

▣ SYSTEM OVERVIEW

The Platform In Depth XTribe has been designed with a modular structure through which most of the complexity associated to running an experiment is hidden into a Main Server, while the experimentalist is left with the only duty of devising a suitable interface for the actual experiment. In this way most of the coding difficulties related to the realization of a dynamic web application are already taken care by the ET Server and the realization of an experiment should be as easy as constructing a webpage with the main utilities for it. Interface and Game Manager A game, an experiment can be imagined as a combination of two intercommunicating parts: the interface and the Game Manager (GM). The interface is what is visible to players, and will interact with them. The GM is represented by those functional parts that process the action of the players. But even if the researcher writes down the code for both the interface and the GM, he is still far from the creation of a web game. Here, XTribe comes in handy. In the first place, the platform will host the game interface. The platform will offer a page for the description of the game rules, compiled by the researcher, from which players can access and play the game. Instead, the GM part of the game will be hosted by the researcher. In this way he can directly collect the data in real time. Users and Data Since the game has been created for research purposes, the researcher is interested in all sort of statistics related to players. Beside this, he may also be interested in filtering players for specific purposes, e.g. according to their age, gender, geographical location, nationality, etc. To this end, XTribe handles a user registry in which players will be allowed to register, if required, and play while the system would maintain all the information about them, such as scores, ranks, etc. together with biographical information. If needed, this information should be send to the GM, i.e. to the experimentalist. Furthermore, based on this information, when properly configured, the system will grant the access to the game only to certain profiles. Being in charge of the handling of the user registry, the system would also spare the researcher from dealing with privacy and security issues since all data will be properly anonymized and, possibly, encrypted. However, by default, it is still possible for unregistered users to access the games. Filters are applied only if set by the researcher. ... and this is how it begins! Once the players have accessed the game, the system will create an instance of the game. There may be given rules for the game to start. A basic rule is the number of players: a certain number of players have to be reached to start a game. There may be also different constraints such as locations, age, sex, etc. As soon as there is a sufficient number of players satisfying the grouping constraints, the game starts. The Game The interface will transmit the actions of the players to the GM, but all messages will pass through the system, which will group them by match instance number after having anonymized them. The GM will then receive the data, will elaborate them and will send the results of the elaboration back to the system, which in turn will transmit them to the interfaces. Obviously, it will also save the data of interest locally (the GM runs on the researcher’s machine). The platform will also handle errors and exceptions. For instance, if the match aborts because one of the players disconnected, the system will detect it, will notify the abort to the remaining players and will send a message to the GM. Since there is no direct communication between GM and interface, the GM will experience no trouble at all. All these features, especially the user registry and the instance handling, usually require a lot of coding, quantified in time and money, to be realized. Within XTribe, they can be realized with a straightforward procedure. After the configuration, the system will automatically take care of all. What researchers have to do is writing the code of the interface and of the GM. Yes, but how? The interface has to be structured as a web page with plenty of freedom in using HTML, CSS, Flash, etc., while the interaction between the interface and the system has to be achieved by means of the ET API, which are internally developed as Javascript functions. With this simple set of functions the interface will interact with the platform and, through it, with the GM. Basically, the GM has to work as a HTTP server hosted on the researcher’s machine. The communication with the system takes place through the HTTP protocol and all messages are coded in JSON format. Besides a restricted set of system messages, the game internal protocol is fully elaborated by the researcher. The following parts contains some tutorials aimed at introducing the various concept related with the XTribe platform. If you haven't done yet, go on XTribe and play some of the game available there.

	field_project_name	Experimental tribe - Xtribe
field_project_purpose
field_home_page_URL
Total number of projects (estimate)	12
Total individual participants (estimate)
Uses Citizen science software	Citizen science custom software
Programming languages (for custom development)	Any
field_project_start_date
field_comments
The Platform In Depth XTribe has been designed with a modular structure through which most of the complexity associated to running an experiment is hidden into a Main Server, while the experimentalist is left with the only duty of devising a suitable interface for the actual experiment. In this way most of the coding difficulties related to the realization of a dynamic web application are already taken care by the ET Server and the realization of an experiment should be as easy as constructing a webpage with the main utilities for it. Interface and Game Manager A game, an experiment can be imagined as a combination of two intercommunicating parts: the interface and the Game Manager (GM). The interface is what is visible to players, and will interact with them. The GM is represented by those functional parts that process the action of the players. But even if the researcher writes down the code for both the interface and the GM, he is still far from the creation of a web game. Here, XTribe comes in handy. In the first place, the platform will host the game interface. The platform will offer a page for the description of the game rules, compiled by the researcher, from which players can access and play the game. Instead, the GM part of the game will be hosted by the researcher. In this way he can directly collect the data in real time. Users and Data Since the game has been created for research purposes, the researcher is interested in all sort of statistics related to players. Beside this, he may also be interested in filtering players for specific purposes, e.g. according to their age, gender, geographical location, nationality, etc. To this end, XTribe handles a user registry in which players will be allowed to register, if required, and play while the system would maintain all the information about them, such as scores, ranks, etc. together with biographical information. If needed, this information should be send to the GM, i.e. to the experimentalist. Furthermore, based on this information, when properly configured, the system will grant the access to the game only to certain profiles. Being in charge of the handling of the user registry, the system would also spare the researcher from dealing with privacy and security issues since all data will be properly anonymized and, possibly, encrypted. However, by default, it is still possible for unregistered users to access the games. Filters are applied only if set by the researcher. ... and this is how it begins! Once the players have accessed the game, the system will create an instance of the game. There may be given rules for the game to start. A basic rule is the number of players: a certain number of players have to be reached to start a game. There may be also different constraints such as locations, age, sex, etc. As soon as there is a sufficient number of players satisfying the grouping constraints, the game starts. The Game The interface will transmit the actions of the players to the GM, but all messages will pass through the system, which will group them by match instance number after having anonymized them. The GM will then receive the data, will elaborate them and will send the results of the elaboration back to the system, which in turn will transmit them to the interfaces. Obviously, it will also save the data of interest locally (the GM runs on the researcher’s machine). The platform will also handle errors and exceptions. For instance, if the match aborts because one of the players disconnected, the system will detect it, will notify the abort to the remaining players and will send a message to the GM. Since there is no direct communication between GM and interface, the GM will experience no trouble at all. All these features, especially the user registry and the instance handling, usually require a lot of coding, quantified in time and money, to be realized. Within XTribe, they can be realized with a straightforward procedure. After the configuration, the system will automatically take care of all. What researchers have to do is writing the code of the interface and of the GM. Yes, but how? The interface has to be structured as a web page with plenty of freedom in using HTML, CSS, Flash, etc., while the interaction between the interface and the system has to be achieved by means of the ET API, which are internally developed as Javascript functions. With this simple set of functions the interface will interact with the platform and, through it, with the GM. Basically, the GM has to work as a HTTP server hosted on the researcher’s machine. The communication with the system takes place through the HTTP protocol and all messages are coded in JSON format. Besides a restricted set of system messages, the game internal protocol is fully elaborated by the researcher. The following parts contains some tutorials aimed at introducing the various concept related with the XTribe platform. If you haven't done yet, go on XTribe and play some of the game available there.	Completion level	Medium

Documented projects in this wiki:

Images test

A big svg picture

SVG test - This seems to work (needs a better ImageMagik installation or something ...)

SVG as a thumbnail

SVG thumbnail

Testing of a new ImageMagick install

ok seems to work

Infobox Software test

kill see march 2018 version