Sloodle Todo List
From SLIS Second Life Wiki
This a general list of tasks which need to be completed for Sloodle at some stage. They are presently in no particular order!
Combine Registration and Enrolment Booths
It will make things simpler if we combine both behaviours into a single booth (perhaps simply called the “Sloodle Booth”?), since both are virtual identical in form and functionality.
The code change to simply do both behaviours all the time is fairly trivial, since the registration/enrolment is actually handled by a separate, link-message controlled script, called “sloodle_manual_regenrol”. In the “sloodle_mod_regbooth-1.0” LSL script, the ‘ready’ state at the bottom responds to touch events by sending out a link message. The first part of the message is “do:reg”, which initiates an avatar registration. This can be changed to “do:regenrol” to initiate both registration and enrolment. (The alternative, “do:enrol”, initiates enrolment only.)
It may also be useful to include a facility to un-register your avatar, so that it can be registered to a new Moodle account.
Reduce number of registration/enrolment objects
The variety of registration and enrolment objects has caused confusion for some users, and many seem to prefer the booth approach. The LoginZone and Access Checker are particularly prone to bugs. They should still be available for people who want use them, but separately from the main tools distribution (e.g. an alternative Sloodle Set, or just the individual tools which a user can add to their own Set if they so wish).
The Access Checker Door has shown some degree of use, despite the fact that it is fairly easy to circumvent its access check. Notably, it appears to be used (as the name suggests) simply for checking access, rather than for registration. Given the somewhat awkward usage requirements for registration/enrolment, it may be sensible to reduce its functionality to simply checking access, instead of enabling it. This would require the removal of portions of the LSL scripts, simplifying it significantly.
Improve notification of auto-registered accounts
Currently, when a user is auto-registered, their new details are stored in database table “sloodle_login_notifications”, until processed by cron job, and dispatched to the original object via email. It appears to be fairly stable, although when handling several (~20) avatars’ account details in fairly quick succession, the email checking script has crashed due to memory violation. (It should be noted that, the lower the frequency of the Moodle cron job, the greater this problem could become, as the number of pending login notifications per ‘batch’ will increase significantly.)
Additionally, the in-world LSL script for checking the notifications could be improved in terms of efficiency. Currently, every object will be checking for emails every 30 seconds, whether it has actually auto-registered somebody or not. (Auto-registration adds a side-effect code to the status line of any Sloodle HTTP response, so the object could check for that).
Check support for Moodle 2.0
It has been reported that at least some of the Sloodle module works on Moodle 2.0, but that the block does not work at all. It is important to investigate ahead-of-time what is likely to need changed in order for Moodle 2.0 to be supported.
PrimDrop ‘rez’ functionality
The ability for a teacher to rez individual items from the PrimDrop via menu would be useful (as opposed to the current requirement, to copy items from PrimDrop to own inventory, then rez on the ground). It may also be useful to establish a remote data connection (like the Vending Machine) with the Moodle site, allowing the teacher to request that an item is rezzed from with the assignment marking system.
PrimDrop ‘feedback’ functionality
Presently, the student can only check for grades and feedback on PrimDrop-submitted assignments by logging-in to Moodle. It would be useful to have the PrimDrop either make that information available on request, and/or to automatically IM the information to the user when it initially becomes available. (This may utilise the Moodle cron job to process/dispatch the messages, and may use the same remote data channel mentioned in the ‘rez’ functionality, or may use email instead. HTTP polling would likely not be an efficient use of resources, given the infrequency of updates in this context).
Improve accessibility of Sloodle Choice
Currently, the Sloodle Choice relies heavily on colour-association to determine which answer corresponds to which bar on the graph. Displaying a number alongside each answer, corresponding to a number below/beside each bar on the graph, may help this situation. Additionally, making the number clickable (and preferably making the answers clickable as well) would improve the ease of interaction.
Investigating alternative methods of presenting answers (i.e. other than llSetText) would be useful also.
Make MetaGloss command customizable
Traditionally, the MetaGloss has always been invoked by prefixing a chat message with “/def”. However, in some contexts, it may be desirable to change this command and/or the channel upon which it is received (some interest has been shown in this possibility). These can be added as configuration settings.
Make output visibility of MetaGloss customizable
It may be useful to some users to be able to make the MetaGloss output private (e.g. using llOwnerSay, instead of the public llSay). This could be set as a configuration option, which would enable its use as a personal device. (There has been implicit demand for this feature from a number of users asking if the MetaGloss can be used as a HUD device).
Improve layout functionality
The Sloodle Set has been able to store layouts for some time, although currently their use is extremely limited, as you need to configure all your objects before you can store their layout, and you also need to configure each object which has been rezzed by a layout. It would be useful to store the configuration of the rezzed objects, so that they can be rezzed and immediately used.
Additionally, the layout does not appear to correctly store the orientation of objects relative to the Set.
Make classroom auto-rezzer
The ability to auto-rez general classroom objects has been requested several times, such as table/chair layouts and such like. This should be a fairly simple tool, and can have a standalone variant.
Also, configuring each individual Sloodle object for use in a virtual class can be a tedious, time-consuming process. It would be far better to be able to click a button, and automatically rez pre-configured items. This could be done for all relevant objects on a course, or for a particular topic within a course. It has also been suggested that Moodle modules for which there is no Sloodle link should be represented by a fairly inert object which simply provides a link when clicked. (It should also be considered that some Sloodle objects are not directly related to Moodle modules, such as the Registration Booth and Password Reset… these should be included, if possible in the auto-rezzing functionality). Ideally, it should also be fairly simple to adjust the default pre-configured settings for each object.
Re-visit Sloodle Set design
The Sloodle Set has out-grown its design, and needs to be changed to suit the number and variety of objects which it can rez. The most important change is to make the rezzing menu more user-friendly. Currently, it provides a fairly monolithic set of menu dialogs, which must be stepped through page-by-page – this is not very intuitive, and it can be difficult to navigate.
It would be better to have a series of object categories, each containing a small subset of the objects which can be rezzed. Additionally, the facility to search for an object by name or description would be useful (this could utilise chat and/or preferably the new llTextBox functionality, when it becomes available).
Improve Sloodle object distribution
It would be wise to make the distribution of Sloodle objects more user-friendly. Additionally, it would be good to attempt to include user-generated content, such as custom design variants.
Quiz Chair Design
As has been noted, most people do not customize the look of their Quiz Chair at all. We should either create our own new design, or incorporate a community-contributed design as standard.
Pile-On Quiz generates teacher ‘attempt’
The Pile-On Quiz is controlled entirely by a teacher, and it currently creates a new empty ‘quiz attempt’ in Moodle for that teacher. This should not happen – it should simply query the questions.
Pile-On Quiz design
As with the Quiz Chair, a more interesting (engaging) design should be made for the Pile-On Quiz.
Improve Toolbar authentication process
The Toolbar is still a little awkward to use and setup. This process should be improved where possible. Additionally, if an avatar wears it, but tries to authenticate it by logging-in to Moodle with a different user account than that which the avatar was already registered to, then the displayed error message does not make sense. (An earlier explicit error check in the PHP script is required). See Issue 56 for more information.
Make Toolbar capable of posting to Moodle forum
This functionality has been requested and encouraged by several educators who would prefer the blog to be tied-down to individual courses. Adding posts to a forum instead of a user’s blog is fairly simple regarding the database manipulation. However, it would require significantly more educator involvement in the configuration process.
The Toolbar is currently a user-authorised object, so individual students authorise it themselves, but adding to a specific forum instead would require the educator to specify more information before distributing it. The alternative would be to allow the students themselves to select any Moodle forum to which they have write access.
Update other Toolbar functionality
More gestures have been requested in the Toolbar, and the ability for educators to add custom gestures has been discussed. The ability to invoke gestures using chat messages is also desired, and should work even when the gestures part of the Toolbar is not visible. It may also be beneficial to publicly release the Toolbar Lite, which solely does gestures, and needs no user authentication.
It has also been suggested that a chat-range notifier is include, which indicates when avatars enter/leave chat range.
Allow the use of images in Choice tool
Various people have expressed interest in the ability to make a Choice tool which displays images instead of simply text. If tied-in to the standard Moodle Choice, then this will not be usable from within Moodle. This consequence has been considered acceptable, although it would be possible to develop a custom activity which may better support the goal.
Incorporate Sloodle Slideshow
The prototyped Slideshow module is tentatively include in the Sloodle 0.4 branch. It requires substantial further worth, including adding an in-Moodle slideshow view for students.
Update and incorporate RSS reader
A simple RSS reader was prototyped quite some time ago. Some interest has been expressed in this, so it should possibly be updated and incorporated into Sloodle.
Implement student stipend payment tool
Many educators pay students in SL a stipend in L$. It would be useful to implement a new sub-type of the Sloodle module which can be used to configure regular payments to course members. It would tie-in to an SL object. Students could touch the object in-world, or click a link/button in Moodle, to have their payment sent to them. The educator should be able to specify their own frequency, payment amount, and which students are included.
Implement SL Webmap API tool for Moodle
A new resource type should be added (which will be installed as part of the Sloodle module) which will allow educators to add SL landmarks, and an SL map, in their Moodle course. (See: http://secondlife.com/developers/mapapi ).
Other potential new tools:
- course selector (shows list of courses which can be clicked for info/enrolment)
- forum browsing/posting
- wiki browsing/posting
- interactive lessons
- survey tool
- SCORM/IMS Learning Design Integration
User Documentation
The Administrator documentation is up-to-date, but much of the rest is not. Most objects require an update for Sloodle 0.3.
A tutorial does exist for Sloodle 0.3, although this could probably be improved and better linked with the rest of the wiki:
http://slisweb.sjsu.edu/sl/index.php/Getting_started_with_Sloodle
Further text tutorials and videos covering other areas would be useful, especially covering commonly misunderstood areas such as:
- Submitting assignments to the PrimDrop (Ctrl+Click+Drag)
- Installation
- Setting up and using the new Toolbar
Developer Documentation
The API documentation requires to be updated. All of the source code in the repository is marked-up for use with the phpDocumentor software. An old version of the API documentation for Sloodle 0.3 is online already.
The wiki documentation for developers requires some degree of update. In addition, there is old API documentation on the wiki which should be removed (including a list of the files/folders in the module download, which was never used, but is superseded by the generated API docs).
| This page is part of the Sloodle documentation | |||
|---|---|---|---|
| SloodleDocs Home | User Documentation | Administrator Documentation | Developer Documentation | Sloodle Wiki Home | |||
