User:SignpostMarv Martin/Alert Request System
The Alert Request Kiosk/Notifier system developed by SignpostMarv Martin is inspired by the one developed by Tateru Nino.
If after reading this article you have any questions regarding the service, please visit the talk page to leave feedback/questions.
Interface Comparison
User's perspective
From the point of view of the Alert Request Kiosk user, the performance is identical to the old system with one major improvement: language-specific requests.
Responder's perspective
From the point of view of the Alert Request Notifier user, the performance differs substantially:
- With Tateru's system, notifications hooked into the "Help Islanders communciator" (later renamed "Volunteer communicator"), but provided no historical view and were (initially) restricted to the island the kiosk was on.
- With Marv's system, the notifications are displayed on a website, circumventing the location issue while also providing historical views on pending, met and unmet requests.
Disadvantages to Responders
Since Tateru's system was hooked into a HUD, many Volunteers refused to use a device that would "tell them how they should volunteer". This resulted in requests for assistance being ignored on an otherwise manned Help Island.
Marv's system swaps the HUD issue with:
- Needing to use a website
- Needing to have an account on a third party service (ran by SignpostMarv Martin)
- Needing to use a group lookup kiosk (developed by SignpostMarv Martin)
Issues with the new system
Needing to use a website
Why a web interface was chosen
Since HUDs are limited in the amount of data they can display, and since reliable inter-sim communications and metrics would need to be handled by an external server, a web-based interface was developed as the primary means of responder interaction.
Will there be a HUD ?
There is a possibility that an API for the service may be released, however there are two key points for why a HUD would not be used:
- The website can be used without needing to be logged into Second Life at the time.
- Linden Lab's Release Candidate viewer and the Electric Sheep Company's "OnRez" viewer both feature built-in browsers.
- The current stable release of the Linden Lab viewer does feature uBrowser, but the Release Candidate viewer's Help > Inworld Help browser features an address bar, while the stable viewer requires modification of debug settings.
Needing to use 3rd party service
The service was developed for use by all Second Life Residents and groups, with the awareness that only group members should be able to respond to requests made from kiosks set to their group.
Once Linden Lab release a method for third-party services to authenticate the identity of a visitor to their site as being the Resident they're claiming to be (e.g. an OpenID server) and provide a method to access group membership info without using libSL, these methods will be supported.
Either a blind MN:SL (Marvulous Networks: Second Life) account or a SLOpenID profile is needed in order to use the service (SLOpenID runs on MN:SL).
- Using any mechanism that asked for Resident's Second Life passwords when it isn't needed is immoral (and probably a TOS violation)
- Linden Lab have yet to release their OpenID server (SLOpenID is an OpenID only for SL Residents that is developed by SignpostMarv Martin)
- Accessing group-restricted resources via the website requires some form of login/authentication.
Although SLOpenID is currently the only site operating on MN:SL (SLBirthday.info will hopefully join it after discussion with Linden Lab), group-restricted forums are in development and MN:SL is able to host community sites operated by other Residents, so the benefits of needing to use the third-party service will increase over time.
Group Lookup Kiosks
While libSL can be used to get a Resident's public groups, use was not chosen for two reasons:
- Only public groups can be read via libSL
- Getting mono, let alone libSL up and running on Marv's server environment is difficult to the point where any benefit gained by using libSL would be lost through development time and complexity
LSL, via llSameGroup() has the benefit of being able to check membership regardless of visibility. This benefit is met with the disadvantage of the function being limited to the scope of a single region, making automated lookups impossible- forcing users to revisit the kiosk regularly (since Residents can be kicked out of groups, the cache of group lookups is expired based on the last time the Resident was associated with a group by the system).
To Do List
| Task | Completion | |
|---|---|---|
| Overall Task | Sub Task | |
| Kiosk Interface | 50%
| |
| LSL | Core Script | 95%
|
| Indication of no responders avaialble | 5%
| |
| Design | Example Kiosk | Provided by Msakaji Yoshiro100%
|
| Design Manual | 0% | |
| Web Interface | 95%
| |
| Design | CSS | 100%
|
| Make design work in non-standard rendering engines (e.g. Trident) | Not my area of expertise, volunteers requested. | |
| Metrics | 84%
| |
| Generation of Metrics | MySQL Table Architecture | 100%
|
| UHU Module | 94%
| |
| Cron Jobs | 80%
| |
| Display of Metrics | Smarty Templates | 70%
|
| CSS | 80%
| |