|
|
| (10 intermediate revisions by 4 users not shown) |
| Line 3: |
Line 3: |
| | GCompris contains a lot of activities for children in a large age range. It is used at home and at schools. | | GCompris contains a lot of activities for children in a large age range. It is used at home and at schools. |
| | | | |
| − | Home users can easily follow their children and propose them the most appropriate activities. But using it in classrooms brings a new set of requirements: | + | Home users can easily follow their children and propose them the most appropriate activities. But using it in classrooms brings a new '''set of requirements''': |
| | | | |
| − | * let the teacher hide inappropriate activities | + | * Maintain students/teachers/groups/profiles |
| − | ** activity filter
| |
| − | ** creating profiles to easily propose an activity set to a new audience
| |
| − | ** activity pre-configurations (like uppercase only)
| |
| − | ** creating and assigning exercises.
| |
| − | | |
| − | * let the teacher track children usage
| |
| − | ** must be as real time as possible to let the teacher help the children asap
| |
| − | ** no real need for long term persistence, teachers probably won't dig in old data to extract relevant informations.
| |
| − | | |
| − | | |
| − | == Legacy version ==
| |
| − | | |
| − | In the legacy version the [http://gcompris.net/screenshots-en.html#administration administration mode] is accessible with a second icon launcher. In fact it just runs the same 'gcompris' binary but with the '-a' option.
| |
| − | | |
| − | Features:
| |
| − | | |
| − | The idea is to let an administrator configure as much or as little as he wants. For instance, the profiles can be used even if no classes, groups and users are created.
| |
| − | | |
| − | * Classes / Users
| |
| − | ** Create users
| |
| − | ** Create classes and associate users
| |
| − | | |
| − | * Groups
| |
| − | ** Create groups within a class
| |
| − | ** Associate users to the group
| |
| | | | |
| | * Profiles | | * Profiles |
| − | ** create profiles | + | ** activity filter (difficulty filter or activity list) |
| − | ** associate one or more class / group to a profile | + | ** activity configuration (like uppercase only) |
| | + | ** create and assign activity dataset |
| | + | ** create and assign a scenario. A scenario is a list of [activity/level/configuration] that a children must follow. It replaces the traditional menu. |
| | | | |
| − | * Activities | + | * Collect and report students results |
| − | ** enable / disable activities for a given profile
| + | ** must be as real time as possible to let the teacher help the children asap |
| − | *** one by one
| + | ** longterm statistical reports |
| − | *** by a level filter
| |
| − | ** configure activities for a given profile
| |
| − | | |
| − | * Logs
| |
| − | ** All success / failure in activities are saved in a log
| |
| − | ** A report contains the date, user, activity, level, sublevel, duration. An optional description of the difficulty encountered was planned but never implemented.
| |
| − | | |
| − | * Login | |
| − | ** If users have been created, they can be authenticated when GCompris is started in the normal mode (login pseudo activity). There are 2 modes, one where the children click on the button with his name, one where he must type his name. There is no password. | |
| − | | |
| − | | |
| − | == Brainstorm area ==
| |
| − | | |
| − | Most important features in order of importance:
| |
| − | * profiles
| |
| − | * tracking real time usage
| |
| − | | |
| − | ----
| |
| − | Well, as a teacher I think that would be better if GCompris administrator has another organization. So, instead of "classes/users", "groups" and "profiles", I would like to suggest that we have "users" (where we could enter the students data), "groups" (where we could group the users), "profiles" (to create profiles associated with groups) and "board selection" (where we would populate the profiles). This would give more freedom for the teachers to organize their student groups (because they could make groups from more than one class). And, in some educational experiences, the "class" concept doesn't exist at all, so it makes more sense that we have only users (and the classes/users window is a little confuse to understand without explanation).
| |
| − | | |
| − | I really like the the reports, but the "win/lost" status ever bothered me. I don't think it's applicable to many boards. Maybe we could change it to "complete/incomplete", "finished/unfinished" or "successful/unsuccessful". But I'm not certain about it.
| |
| − | | |
| − | And I think that we need to rewrite the help to make it more clear.
| |
| − | | |
| − | --[[User:Aracnus|Aracnus]] ([[User talk:Aracnus|talk]]) 03:15, 18 July 2014 (CEST)
| |
| − | ----
| |
| − | | |
| − | === Persistence ===
| |
| − | | |
| − | In the old version the sharing of the configuration was done through a shared 'sqlite' database. This is not a good usage for it, it requires an admin to set it up on a shared folder. Does not suit well the mobile use case. Where do we save the configuration: gcompris.net, a teacher server, ?
| |
| − | | |
| − | ----
| |
| − | The advantage of sqlite database is that it doesn't require any infrastructure to be maintained. Just copy and share it, which gives great flexibility to the teachers. But I agree that a MySQL database (for example), on a local (or remote) server, would offer better results. A gcompris.net centralized server is a very interesting idea, but, in this case, we would have the requirement of an active Internet connection, which isn't a reality in many schools.
| |
| − | | |
| − | It would be possible a "hibrid" model, where teachers could choose the better solution? This would be amazing!
| |
| − | | |
| − | --[[User:Aracnus|Aracnus]] ([[User talk:Aracnus|talk]]) 03:15, 18 July 2014 (CEST)
| |
| − | | |
| − | ----
| |
| − | '''Data sharing scope:''' Storing profile/user data centrally (gcompris.net) would probably mean that we'd need to maintain user data for different working groups (i.e. maybe check access permissions) and need to make sure the service is highly available etc.
| |
| − | | |
| − | '''Data access:''' We could also decouple the data access (by clients) from the data store by e.g. letting the admin-node/application expose a platform neutral API (with methods like "getProfile", "setUser", "storeResults", ...) over a protocol supported on all platforms like a JSON-RPC based (web)service running on top of a plain TCP socket or Websocket protocol (available since Qt 5.3). A client for such an access protocol can be implemented on any platform (using qt). The data store could then be set up and maintainted by the admin node running the access service and does need to be shared, e.g. sqlite and would not require any additional admin tasks except starting the admin application (cf. below) which in turn manages the data store transparently to the admin user.
| |
| − | | |
| − | If we think about a shared RDBM like mysql we must make sure that all clients/platforms support the access-protocol. By now I am not sure whether all QSqlDrivers are available on Android platforms.
| |
| − | | |
| − | --[[User:Holger|Holger]] ([[User talk:Aracnus|talk]])
| |
| − | ----
| |
| − | | |
| − | === Administration console ===
| |
| − | | |
| − | How do we do this, what technology (Qt, Web, ...), how is it linked to the users, ...
| |
| − | | |
| − | ----
| |
| − | Again, web interface is a great idea, but it would demand some skills to configure a web servers that may complicate the situation on schools.
| |
| − | | |
| − | --[[User:Aracnus|Aracnus]] ([[User talk:Aracnus|talk]]) 03:15, 18 July 2014 (CEST)
| |
| − | ----
| |
| − | | |
| − | '''Availability''': According to the above idea to use an admin-application exposing an API for data access, this central service would be available once the admin-application is up-and-running.
| |
| − | | |
| − | Using a shared DB on the other hand would require the additional step to set it up.
| |
| − | | |
| − | '''Discovery/Registering:''' A client that wants to use the admin service (e.g. for getting profile data) needs access information like IP/port information probably to be entered by the client user PLUS a username for client/pupil identification on the admin side.
| |
| − | | |
| − | '''Admin application:''' The scetched admin application could be responsible for both: a. editing/updating profile/user/... data by an admin user using a QML-based admin GUI and b. exposing access methods (cf. above) to this data via an API.
| |
| − | | |
| − | This application could be a separate one. It could also be baked into the existing GCompris application as was done in the gtk+ version.
| |
| − | | |
| − | This application could also be available on all platforms, thus allowing a teacher to setup up a class environment on his tablet.
| |
| − | | |
| − | -- [[User:Holger|Holger]] ([[User talk:Holger|talk]])
| |
| − | ----
| |
| − | | |
| − | === Proof of concept ===
| |
| − | | |
| − | A web service (coded in python with django) named 'schoolbus' is accessible here:
| |
| − | http://gcompris.net:8000/admin/schoolbus/ (login test/test)
| |
| − | | |
| − | It provides the following features:
| |
| − | | |
| − | * A teacher comes to gcompris.net and creates a teacher account. He gets a unique UUID in return.
| |
| − | * The teacher can then: | |
| − | ** Create a profile (only min and max level for now) | |
| − | ** Create a group and associate a profile to it. A group is recursive, the teacher can create groups within a group at unlimited depth.
| |
| − | ** Create users and associate them to a group. A user maybe a student or a GCompris instance like 'Lab PC1'.
| |
| | | | |
| − | Schoolbus provides an API (getProfileByLogin) to get the profile in json for a given Teacher UUID and student:
| + | * Distribute activities (as rcc files) |
| − | http://gcompris.net:8000/schoolbus/getProfileByLogin/d96f0affe2094e8889dfccddd365ca41/pc1
| |
| − | {"name": "strong", "level_min":3, "level_max":6}
| |
| | | | |
| − | GCompris can be configured with the teacher's UUID and the user login. It uses the getProfileByLogin API to get the profile and configure its min and max level.
| + | * Share datasets and activities with other teachers/schools |
| | | | |
| − | The code of the client is in the [https://git-next.kde.org/kde/gcompris/commits/admin_poc admin_poc branch];this
| + | * Web storage and sharing of children's creation |
| | | | |
| − | The code of 'schoolbus' is [https://github.com/bdoin/schoolbus here]. To run it use: 'python manage.py runserver'. It is then accessible on localhost:8000.
| + | * Private text chat with the ability to share a drawing or send it. |
| | | | |
| − | === Notes ===
| + | * Pause or mute the set of GCompris under the teacher's control. |
| | | | |
| − | This is only a proof of concept that we can use to iterate to find the best data model.
| |
| | | | |
| − | Some ideas:
| + | == Schoolbus System Architecture == |
| | | | |
| − | * The 'schoolbus' web service is a good approach to let all GCompris and teachers communicate. | + | * Centralization of a backend service (schoolbus) that is supposed to run on gcompris.net as well as (optionally) as an installation in LAN/school scope. |
| − | * If a site does not have Internet it can still install 'schoolbus' on its network
| |
| − | * Beside the web interface we can create a 'schoolbus' client in Qt Quick. This interface would be more useful in live sessions where a teacher can see in real time what the children are doing, assign one children an activity, block all Gcompris, ...
| |
| − | * Once registered on the 'schoolbus' web server a Qt Quick client could talk directly with the GCompris. In a sense 'schoolbus' act as a dns server for our GCompris instances.
| |
| − | * 'schoolbus' should also be used to let a teacher create exercises.
| |
| | | | |
| − | Other:
| + | * The core of the central service comprises an access layer (API) and a storage layer (DB). All data access happens through the API. Optionally a web interface may be needed to administrative the central service itself (not the admin content), which then would also use the API. |
| − | * I don't know yet were to put the code of schoolbus. | |
| | | | |
| − | -- [[User:Bruno|Bruno]] ([[User talk:Bruno|talk]])
| + | * DB store: Could use a RDBM or a non-relational, key-value based DB. Will be decided based on datamodel complexity ... |
| − | ---- | |
| − | Oh man... We have so many possibilities with this interface... I loved it! :-)
| |
| | | | |
| − | Commenting your ideas, yes, 'schoolbus' do have a potential to be a great "hub" for teacher interactions. And for this, I have some other suggestions, that I'll comment below. The local network alternative is a great idea, since many schools here in Brazil (and other countries too, I'm guessing) don't have Internet connection. And the Qt Quick client is another great idea.
| + | * For the gcompris.net installation daily (or so) backups of the DB are expected to be enough. |
| | | | |
| − | And using your "communication" and "exercises creation" points, I have some ideas here:
| + | * To be better able to cope with outage of the server or the network the GCompris client could store a backup of the last known profile data to be used as fallback. |
| | | | |
| − | * To have a section on ''schoolbus'' that would let teachers write freely (in a textarea field for example, with minimal bbcode formating support). There he/she could write strategies to use GCompris activities. This would be associated with the possibilities to choose activities/levels and generate a "pedagogical set", that could be shared with other people and/or downloaded to one's own ''schoolbus'' instance (on local network). With this, we have a potential to build a great repository for [http://en.wikipedia.org/wiki/Open_educational_resources open educational resources]. | + | * Protocol: For communication with the API Websockets can be used as well as HTTP. Websockets have the advantage of bidirectional communication and can be used both by web-based clients as well as native clients. Over the low level protocol an ASCII based payload (like JSON RPC) will be used to call API methods and return results back. |
| − | * ''Schoolbus'' could be used to administrate GCompris internal resources, like word/picture lists. And these lists could be shared and/or downloaded too.
| |
| − | * The digital manual would be stored on ''schoolbus'' too, with a possibility to make "community contributions" to it, but only for restricted people (to avoid vandalism). So the manual pages could be included on the "pedagogical sets" too. Or consulted online.
| |
| | | | |
| − | What do you think?
| + | * A QML based admin console might live as an admin activity inside the GCompris application and be unlocked in some way. Serves for administrative access to the content via the backend API. |
| | | | |
| − | Oh, and I didn't understand your last question, Bruno. Are you asking about where to put the code being developed or to host ''schoolbus''?
| + | * Direct communication from users to the admin-application could be used to directly report result for the live view unless storing the results is not needed. This would relieve the central server. |
| | | | |
| − | --[[User:Aracnus|Aracnus]] ([[User talk:Aracnus|talk]]) 03:46, 9 August 2014 (CEST)
| + | [[Category:English]] |
| − | ----
| |
