Difference between revisions of "User:Lum Pfohl/LSL Goodies/HI-WA Occupancy Counter System"

From Second Life Wiki
Jump to navigation Jump to search
(New page: {| width="100%" |- |valign="top"| <FONT size="+2"><B>DETAILED REQUIREMENTS</B></FONT><BR/> <div id="box"> ==Help Island/Welcome Area Occupancy Counter System - Overview== <div style="paddi...)
 
m (__NOTOC__)
Line 1: Line 1:
__NOTOC__
{| width="100%"
{| width="100%"
|-
|-

Revision as of 14:51, 30 August 2008

DETAILED REQUIREMENTS

Help Island/Welcome Area Occupancy Counter System - Overview

Background

This is a system of scripts, sensors and servers designed to sense, collect, report and disseminate information on the occupancy levels of Orientation Islands, Help Islands, Welcome Areas and Infohubs.

Statement of Business Need

The information described above, when extended to discerning Second Life Mentors from New Residents, can be useful in determining effectiveness of Second Life Mentoring and Greeter programs as well as helping Mentors decide where to go to help New Residents.

Project Scope

This following list indicates the new functionality included as part of the enhancement package included in the HI-WA Occupancy Counter System:

  1. Design, architect and build a system that will detect, count and tally the occupancy levels certain areas within Second Life.
  2. The areas for consideration include, but are not limited to: Orientation Islands (all), Help Islands (all) and Welcome Areas / Infohubs.
  3. Allow for a number of clients which can poll for this information and utilize it in various ways. Some such methods include, but are not limited to, Text Displays, HUDs, Database/Warehousing Server, other Occupancy Counter Systems.

Project Out Of Scope

The following is a list of items that are specifically excluded from this enhancement:

  1. Real-time info.
  2. Resident names and personal metrics.
  3. Data warehousing capabilities although external systems (under a separate project) can interface to it to gather limited info.

User Characteristics

The Second Life Mentor group has several thousand members whose focus is on locating areas where New Residents require basic help. The Mentors are at least 6 months old (by the calendar from their rez-date), and possess a certain level know knowledge of the intricacies of Second Life, the usage of certain basic tools and widgets available to them, to complete their business tasks. The Second Life Mentor group also have a number of Linden Lab employees (for example: VTeam) whose focus is on the effectiveness of the Second Life Mentor Program and the retention of New Residents as they enter Second Life. Users generally do not have extensive technical expertise. Nonetheless, Users are knowledgeable regarding their business tasks. Consequently, the pool of Users overall is considered to be sophisticated.

Specific Requirements

  1. Design, architect and build a system that will detect, count and tally the occupancy levels certain areas within Second Life.
  2. The areas for consideration include, but are not limited to: Orientation Islands (all), Help Islands (all) and Welcome Areas / Infohubs.
  3. Allow for a number of clients which can poll for this information and utilize it in various ways. Some such methods include, but are not limited to, Text Displays, HUDs, Database/Warehousing Server, other Occupancy Counter Systems.
  4. The system must be able to operate entirely in-world and not be dependent on any external systems for information/message routing, configurations.
  5. The system must continue to be operable and maintainable beyond the creator's lifespan.
  6. The system must be able to perform under potentially hostile conditions. For example: Parcels/Sims with No Script, No Build, No Object Entry, 2 minute auto-return, etc.
  7. The system must provide a basic mechanism for utilizing the collected information at a "personal" level. For example: a personal HUD that will receive information, parse and display it in a manner meaningful to the end-user.
  8. The system must be scalable to handle requests from potentially several thousand Users.
  9. The system must provide a mechanism to alert the User if an update is available, and where possible to automatically deliver such updates to the Users.
  10. The system must be easy to maintain.
  11. The system must be well-documented.
  12. The system must operate autonomously.
  13. The system must be easy to use by the User base (as described in the previous section).

Lum Pfohl 13:58, 30 August 2008 (PST)

Lum's Quick Links
LumSelfPortrait.jpg
Click to Enlarge


Related topics

edit