Difference between revisions of "User:SignpostMarv Martin/Alert Request System"

From Second Life Wiki
Jump to navigation Jump to search
(/me creates article)
 
 
(9 intermediate revisions by the same user not shown)
Line 3: Line 3:
If after reading this article you have any questions regarding the service, please visit [[{{TALKPAGENAME}}|the talk page]] to leave feedback/questions.
If after reading this article you have any questions regarding the service, please visit [[{{TALKPAGENAME}}|the talk page]] to leave feedback/questions.


== Interface Comparison ==
[[User:Don Misfit|Don Misfit]] has been [[User:SignpostMarv Martin/Alert Request System Review|aggregating feedback]] on the initial test.
=== 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 ===
== Things affected by database architecture re-write ==
From the point of view of the Alert Request ''Notifier'' user, the performance differs substantially:
* [[User:SignpostMarv Martin/Alert Request System Review#Quirky use and navigation from the Pending Requests list|Quirky use and navigation from the Pending Requests list]]
* [[User:SignpostMarv Martin/Alert Request System Review#False help requests (residents clicking the kiosk out of curiousity)|False help requests]]
* [[User:SignpostMarv Martin/Alert Request System Review#The "stats" list includes Requester and Responder Names|The "stats" list includes Requester and Responder Names]]
* [[User:SignpostMarv Martin/Alert Request System Review#Griefers playing SL version of "ding-dong-dash"|Griefers playing SL version of "ding-dong-dash"]]
* [[User:SignpostMarv Martin/Alert Request System Review#Option to add comments to a Request record after responding|Option to add comments to a Request record after responding]]


* 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.
== Access Control List ==
* 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.
Since privacy is always a concern, I plan to implement an [http://en.wikipedia.org/wiki/Access_control_list access control list] feature on the statistics.


==== Disadvantages to Responders ====
The abilities will be:
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.
* Toggling the non-group, group and public visibility of statistic
* Naming additional administrators


Marv's system swaps the HUD issue with:
The default administrator will the '''''founder''''' of the group. Since LSL currently has no facility to determine the group role of a Resident, the service will not be able to automatically identify Residents with the '''owner''' permission. As a side effect of this, if the group founder is no-longer in the group, the default admin cannot be automatically identified.
* Needing to use a website
* Needing to have an account on a third party service (ran by [[User:SignpostMarv Martin|SignpostMarv Martin]])
* Needing to use a group lookup kiosk (developed by [[User:SignpostMarv Martin|SignpostMarv Martin]])


== Issues with the new system ==
== Feedback System ==
=== Needing to use a website ===
* Individual Requests can be marked as "accidental", "malicious" or "inappropriate"
==== Why a web interface was chosen ====
* Requesters can be marked as being "likely to need future assistance" or "malicious"
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.
* Responders can be marked as "helpful" or "malicious"
* Comments are optional, but will be preferred.


==== Will there be a HUD ? ====
== Feedback System Flags ==
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:
=== Accidental ===
# The website can be used without needing to be logged into Second Life at the time.
If a request was made out of curiosity (e.g. Dee Dee-esque "oooooooh, what does *this* button do), a request should be marked as accidental.
# 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 ===
=== Malicious ===
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.
{{Alert Box|The Malicious flag should not be used maliciously- e.g. flagging a Resident as malicious because of something they did outside the scope of an alert request. Residents will only be able to leave feedback on each other if the system shows they've interacted, preventing malicious maliciousness to a certain degree}}


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.
==== Requests ====
If a Resident intentionally activates a kiosk for the express purpose of annoying Responders, then a request should be flagged as "malicious".
See [[User:SignpostMarv Martin/Alert Request System Review#Griefers playing SL version of "ding-dong-dash"|Griefers playing SL version of "ding-dong-dash"]].


Either a blind MN:SL ([http://marvulous.co.uk/ Marvulous Networks: Second Life]) account or a SLOpenID profile is needed in order to use the service (SLOpenID runs on MN:SL).
==== Requesters ====
# Using any mechanism that asked for Resident's Second Life passwords when it isn't needed is immoral (and probably a TOS violation)
For requesters, this would be if the requesting Resident didn't make the request maliciously, but violated [[LL:Second Life Community Standards|the Community Standards]] while the request was being handled.
# Linden Lab have yet to release their OpenID server (SLOpenID is an OpenID only for SL Residents that is developed by [[User:SignpostMarv Martin|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.
==== Responders ====
For responders, this would be if the responding Resident violated [[LL:Second Life Community Standards|the Community Standards]]- and/or the [[Tao of Volunteers]] for Volunteers- while the request was being handled.
----


==== Group Lookup Kiosks ====
=== Inappropriate ===
While libSL can be used to get a Resident's public groups, use was not chosen for two reasons:
The intent of this flag isn't for saying a request was of an "inappropriate nature" (e.g. "ZOMG WHERE IS TEH SEXXORZ"), but for indicating a request was directed to Linden Lab's support staff- just as with Linden [[Office Hours]], the alert request system isn't meant for for tech/billing support etc.
# 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).
If a large number of Residents are asking questions that should be directed to Linden Lab's support staff, this would indicate that Linden Lab need to improve the availability/accessibility of information.
----


== To Do List ==
=== Unrelated ===
{| border="1px" cellspacing="0" cellpadding="5px"
This flag is used if the topic of a request was something unrelated to Second Life.
|-
----
! colspan="2"| Task
! rowspan="2" style="width:200px;vertical-align:top;"| Completion
|-
! Overall Task
! Sub Task
|-
| colspan="3"|
|-
! colspan="2"| Kiosk Interface
| bgcolor="black" style="color:#fff;"| {{progress bar|50%|padding:2px 0px 2px 5px;margin:5px -5px;border:3px solid #f00;|}}
|-
! rowspan="2" style="vertical-align:top;padding:5px 10px;"| LSL
| Core Script
| bgcolor="black" style="color:#fff;"| {{progress bar|95%|padding:2px 0px 2px 5px;margin:5px -5px;border:3px solid #f00;|}}
|-
| Indication of no responders avaialble
| bgcolor="black" style="color:#fff;"| {{progress bar|5%|padding:2px 0px 2px 5px;margin:5px -5px;border:3px solid #f00;|}}
|-
! rowspan="2" style="vertical-align:top;padding:5px 10px;"| Design
| Example Kiosk
| bgcolor="black" style="color:#fff;"| {{progress bar|100%|padding:2px 0px 2px 5px;margin:5px -5px;border:3px solid #f00;|Provided by [[User:Msakaji Yoshiro|Msakaji Yoshiro]]}}
|-
| Design Manual
| 0%
|-
| colspan="3"|
|-
! colspan="2" | Web Interface
| bgcolor="black" style="color:#fff;"| {{progress bar|95%|padding:2px 0px 2px 5px;margin:5px -5px;border:3px solid #f00;|}}
|-
! rowspan="2" style="vertical-align:top;padding:5px 10px;"| Design
| CSS
| bgcolor="black" style="color:#fff;"| {{progress bar|100%|padding:2px 0px 2px 5px;margin:5px -5px;border:3px solid #f00;|}}
|-
| Make design work in non-standard rendering engines (e.g. Trident)
| Not my area of expertise, volunteers requested.
|-
| colspan="3"|
|-
! colspan="2" | Metrics
| bgcolor="black" style="color:#fff;"| {{progress bar|31%|padding:2px 0px 2px 5px;margin:5px -5px;border:3px solid #f00;|}}
|-
! rowspan="3" style="vertical-align:top;padding:5px 10px;"| Generation of Metrics
| MySQL Table Architecture
| bgcolor="black" style="color:#fff;"| {{progress bar|80%|padding:2px 5px;margin:5px -5px;border:3px solid #f00;|}}
|-
| UHU Module
| bgcolor="black" style="color:#fff;"| {{progress bar|75%|padding:2px 5px;margin:5px -5px;border:3px solid #f00;|}}
|-
| Cron Jobs
| 0%
|-
! rowspan="2" style="vertical-align:top;padding:5px 10px;"| Display of Metrics
| Smarty Templates
| 0%
|-
| CSS
| 0%
|}


== See Also ==
 
* [[/2007-10-27 19:00|Meeting Transcript, October 27th, 7pm]]
 
== Visibility of Information ==
=== Requests ===
As with the previous version of the Alert Request System, requests in the re-write will only be visible to members of the same group as the kiosk the alert was made from.
 
=== Names of Requesters ===
* Names will not be visible in the pending request list
** They will however, be visible on the confirmation page
* Names will not be visible in the met requests list
* Names will be visible in the recently missed request list
 
=== Names of Responders ===
==== Closed Requests ====
An access control list will be implemented that will control who can see statistics relating to closed requests.
 
==== Open Requests ====
Names of Responders who have left feedback on a Requester will be visible on the confirmation page.
 
==== In-Progress ====
The names of the Responder or Responders handling a request will be visible on the confirmation page.

Latest revision as of 07:41, 13 December 2007

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.

Don Misfit has been aggregating feedback on the initial test.

Things affected by database architecture re-write

Access Control List

Since privacy is always a concern, I plan to implement an access control list feature on the statistics.

The abilities will be:

  • Toggling the non-group, group and public visibility of statistic
  • Naming additional administrators

The default administrator will the founder of the group. Since LSL currently has no facility to determine the group role of a Resident, the service will not be able to automatically identify Residents with the owner permission. As a side effect of this, if the group founder is no-longer in the group, the default admin cannot be automatically identified.

Feedback System

  • Individual Requests can be marked as "accidental", "malicious" or "inappropriate"
  • Requesters can be marked as being "likely to need future assistance" or "malicious"
  • Responders can be marked as "helpful" or "malicious"
  • Comments are optional, but will be preferred.

Feedback System Flags

Accidental

If a request was made out of curiosity (e.g. Dee Dee-esque "oooooooh, what does *this* button do), a request should be marked as accidental.

Malicious

The Malicious flag should not be used maliciously- e.g. flagging a Resident as malicious because of something they did outside the scope of an alert request. Residents will only be able to leave feedback on each other if the system shows they've interacted, preventing malicious maliciousness to a certain degree

Requests

If a Resident intentionally activates a kiosk for the express purpose of annoying Responders, then a request should be flagged as "malicious". See Griefers playing SL version of "ding-dong-dash".

Requesters

For requesters, this would be if the requesting Resident didn't make the request maliciously, but violated the Community Standards while the request was being handled.

Responders

For responders, this would be if the responding Resident violated the Community Standards- and/or the Tao of Volunteers for Volunteers- while the request was being handled.

Inappropriate

The intent of this flag isn't for saying a request was of an "inappropriate nature" (e.g. "ZOMG WHERE IS TEH SEXXORZ"), but for indicating a request was directed to Linden Lab's support staff- just as with Linden Office Hours, the alert request system isn't meant for for tech/billing support etc.

If a large number of Residents are asking questions that should be directed to Linden Lab's support staff, this would indicate that Linden Lab need to improve the availability/accessibility of information.

Unrelated

This flag is used if the topic of a request was something unrelated to Second Life.


Visibility of Information

Requests

As with the previous version of the Alert Request System, requests in the re-write will only be visible to members of the same group as the kiosk the alert was made from.

Names of Requesters

  • Names will not be visible in the pending request list
    • They will however, be visible on the confirmation page
  • Names will not be visible in the met requests list
  • Names will be visible in the recently missed request list

Names of Responders

Closed Requests

An access control list will be implemented that will control who can see statistics relating to closed requests.

Open Requests

Names of Responders who have left feedback on a Requester will be visible on the confirmation page.

In-Progress

The names of the Responder or Responders handling a request will be visible on the confirmation page.

Retrieved from "https://wiki.secondlife.com/w/index.php?title=User:SignpostMarv_Martin/Alert_Request_System&oldid=44672"