User talk:SignpostMarv Martin/Alert Request System

Don Misfit's comments on Marv's Kiosk System

First, I think it's a good idea, maybe a great idea --- making it easier to help for Newbies is always a good target.

Second, please take these comments as if I am making them to a faceless corporate entity. They are intended *solely* as my personal comments on the system, as relates directly to use in the "Summon a Mentor" context, and are not directed at any individual.

---

Kiosks *must* provide feedback to the person who clicks a button that the request has been sent, in the requested language. Currently, the resident sees "Your request has been sent..." ONLY if he clicks on the English language button. All other buttons *appear* to be non-functional.

Mentors should be able to log in directly to the "Pending Requests" page. Having to log in, and then find other links to navigate to the list is cumbersome and confusing.

The system should provide its own password reset feature. It can be as simple as the Mentor clicking on the Registration object again. Requiring Mentors to add an email address to another web system is impractical.

The Pending Requests page should have no references to "other" groups. This is a "Summon a Mentor" system, and Mentors attempting to use it should see the list of Pending Requests only. Links or references to any other functions just makes it messy and confusing.

The issue with Opera must be fixed (just format the location vectors to integers).

Clicking the SLURL on the pending requests page needs to be handled better.

1) In IE, the SLURL launches, but the requests page does not change.

2) In Firefox, a scary, cryptic warning box pops up. Clicking through leaves you at a blank page.

3) Clicking an expired or "met" SLURL gives you a notice page, but no instruction or navigation link back to the list.

I think when you click a SLURL, the page should change showing you the individual request that you selected, giving you a way to refer back to the person's name, language, and how long they've been waiting.

The documentation page provided to Mentors should be limited to how the "Summon a Mentor" system is used. Any references to use by other groups, or other features of SLOpenID / MN:SL / etc is confusing and counter productive.

---

In short, I think this *must* be a dedicated system, targeted specifically for Mentor Response to Newbie Requests. Make it a subset of your overall "generic group use" plan, but... For it to be usable - and *used* - by Mentors, it needs to be a single thing: the list of Pending Requests.

( end of Don Misfit's comments )

• Opera Bug- I'm examining the code right now to find where the best place is to do the integer changeover.
• Feedback- the translated strings weren't added to the script prior to rollout
• Pending Requests on Login- Make the "My Groups" the default display, or send it to there upon login ?
• No reference to other groups- The system is scripted to be independent of any particular group. The current "My Groups" page is an amalgam of requests for *all* of the Residents' groups. It is feasible however to put up pages for individual groups.
• Firefox- Screenshot please ? I'm using Firefox and I get no such message.
• Already Responded- Redirecting back to the "My Groups" page and leaving a note in the sidebar would be better than a blank page- however, since I'm using header() to redirect the page to the secondlife:// URL, I'll have to look into how to best implement this (suggestions are welcome)
• Documentation- The system itself is independent of any group, however I will concede that since the SL Mentors are currently the primary users of the system the documentation should be biased towards them- as long as there is something in the preamble/intro to indicate that the system can be used by any group
• Password Reset- I do actually have a password feature ready to deploy (the login portal was down while i was developing it), but I changed my mind due to security concerns. The Alert Request system *is* the other system.
  • MN:SL is built around WordPress- the login data is WordPress, not a custom login application.
  • Normally when creating an account on a WordPress install, the users' email address is required- since MN:SL accounts are created using in-world kiosks, I use emails which go to one of my own addresses, then delete the email from the WordPress user table.
  • Since users are "created", not "invited" to MN:SL, the email address is only needed to reset the password (hence why it is deleted)
  • Basically, it's a balance of convenience vs security. Using a custom password reset feature when one already exists is a risky maneuver (it's also why you can't change your SL password via the SL Wiki)

SignpostMarv Martin 13:04, 1 December 2007 (PST)

Comment on the system

I'm not sure if this is the correct place for a little feedback.

I won't get into the technical details, but just descride how I've experienced using this feature done so since last night. Overall I think it's very useful and a great idea.

There is one thing I suggest should be added to the kiosk, when people click, they should have a pop up show up asking if they want to confirm their request.. As 50% of the resquests I got were mistakes or people who clicked out of curiosity only.

[12:17] You: Hello

[12:17] You: You called?

[12:17] Charley : hi

[12:17] Charley : umm by accicent!! sorry

[12:17] Charley : i didnt know what it was!

[12:17] You: ok, no problem

As a linguist I also noted several mistakes on the french text:

False : Correct

Pour Français cliquez ici : Pour le français cliquez ici

As-tu besion d'aide? : As tu besoin d'aide?

Demands un mentor! : Demandes un mentor!

That's all ;)

Zack Preminger

Unable to use site

I cannot use this at all. Whenever I click a link, it takes me to a "Page Not Displayed", yet it shows in the result page that I have answered the alert. I have tried both the SL browser and the one I normally use, OnRez. I use IE6 browser and have disabled pop-ups, done everything I can, but it just won't work. I am in a Catch 22 situation now, because if I click a request link to see if it's working for me and it isn't, I cancel it out.

Perhaps something essential is disabled in services.msc (I disable quite a few things in there), although I wouldn't have thought so. I have tried everything I can think of, but it makes no difference. It's very frustrating, so would appreciate any suggestions.

As far as suggestions are concerned, leaving a browser window open constantly (esp. one that doesn't automatically refresh) is very taxing on resources. It would be so much better if this function could be used in-world.

Julie Apocalypse 00:04, 3 December 2007

• Some browsers (though it seems only IE ones), don't like the method I'm using to automatically forward peeps to the secondlife:// URL for the requests' location. At this time, there's nothing I can do about that I'm afraid.
• If the OnRez viewer doesn't support secondlife:// URLs, then you need to take that issue up with the Electric Sheep Company.
• The website is made up of two key components:
  1. The XHTML that forms the web interface
  2. The location links
• Neither of these are affected by anything running in services.msc (except of course, anything that affects your ability to connect to the internet :-P )
• Leaving a browser window open constantly with a static page (with no images whatsoever) isn't taxing
  • If the page had an auto-refresh you would merely get a small recurring spike of CPU resources every time the content was reloaded.
  • However, your mileage will vary depending on the browser you use, so I would suggest trying a different browsers such as Opera, Firefox or the Second Life Viewer's In-World Help browser (Help > In-World Help)

It should be noted that the web interface uses CSS3 Selectors, which IE doesn't support (amongst other things), explaining why the design looks a bit screwy.

SignpostMarv Martin 16:26, 2 December 2007 (PST)

Opera doesn't work for me at all, it won't even load the requests. Firefox does bring up the map, but all I get is my current location, it doesn't show the sim involved in the request and I have no option to Display or Teleport. However, I don't think this is the cause of my problem with the links because I have no problem whatsoever clicking other slurls. However ... the SL Viewer In-World Help Browser DOES work. This will have to do for the moment, if I can get used to the SL Viewer again. Unfortunately, I much prefer OnRez so that may be a problem! Hopefully, the fact that this works and the 'external' browsers don't, might go some way to explaining the problem. As far as having IE open is concerned, the reason I assumed it zapped my resources was because my frame rate drops alarmingly whenever I open the internet and jumps back to normal when I close the window.

Suggestion

When Mentor clicks on a pending request:

• system flags request as "met" and displays a new web page
• new page shows: requester name, location, language, times -- plus a Cancel link and a Return to Pending Requests link
• Mentor can then click on a standard SLURL link to "map" to the location
• If TP fails, SL crashes, Mentor realizes he clicked the wrong request, etc... Mentor clicks Cancel to put the request back into the queue
• after responding, Mentor clicks Return to go back to the Pending Requests

This accomplishes a couple things:

1. Mentor still has resident Name, language, wait time, etc still available
2. Accidental clicks / TP errors can be corrected
3. Fixes problems with different browsers (allowing Mentors to use the browser / viewer of their choice, instead of being told to switch to something else)
4. More intuitive navigation

Don Misfit 23:32, 2 December 2007 (PST)

STRONG RECOMMENDATION

I am very surprised to see that names - both Mentor and Resident - are being tracked and displayed.

VERY STRONGLY RECOMMEND THAT NAMES BE DELETED WHEN A REQUEST IS MET!!!!

The only data that should be saved is: language, location and time info.

I did not ask, but when I was evaluating the system and writing the overview and instructions, I assumed the names were being displayed only because the system was in development. So, again:

VERY STRONGLY RECOMMEND THAT NAMES - BOTH MENTOR AND RESIDENT - BE DELETED WHEN A REQUEST IS MET!!!!

Don Misfit 00:26, 3 December 2007 (PST)

Request Expirations

Marv - have you looked at the data on the "not-met" list? It appears you are expiring all pending requests on-the-hour, regardless of age.

Don Misfit 00:35, 3 December 2007 (PST)

Responses to Don Misfit's comments

Deleting names from records

• contradicts "undo" request.
• prevents griefers from being blocked from using the service (feature not implemented)
• prevents planned "review" feature (for both responders *and* requesters)
• not displaying names is doable, but deleting records of who did what would require a complete rewrite of the system.

Removal of automagical request removal

• Doable
• Photoshop mockups of suggested interface would be welcome
• Would allow multiple responders

auto-expiry

• SQL date queries + cron = pain in the ass

SignpostMarv Martin 08:40, 3 December 2007 (PST)

WOW, This seems to be over-engineered to me.

I have about 300 mentors currently wearing my communicator. I can easily add a pseudo group chat to those genuine gold mentor badges. The group chat would include fixed HELP telephones on any island where scripts can run. Visitors wanting help would make a call on a help phone. I could even have a handset and animation :).

The Alert/Help phone would broadcast their message to the pseudo group. Their SLURL would be added to their first transmission. Only those mentors on line and wearing their badge would hear it.

If no mentors were on line, the visitor would get a "voice mail" answer and could record their question for any mentors coming on line in the next xx hours. On hearing the question, mentors could reply to the visitor on the phone via the pseudo group. All in the group would hear a response had been made and join in if needed. If more than a brief response is needed, my current system would allow switching the help phone and responding mentor to a different channel so the whole group would not be interrupted.

If no one in the group on line wearing badges was available to respond at the time, the help call and SLURL could be manually sent out to the Mentor Group for someone else to respond.

To have any level of success it would require giving communicators to a significant number of mentors but any mentor Alert system is going to need an enrollment of some kind.

I have everything above already running on other products. They are free, available now, and in use by a number of groups. It would take a day or two of customization for the telephones and it would be ready to go. It already has spammer blocking facilities. Since it is script based, Help Telephones and Mentor badges would fail in non-script areas.

Just my approach. I've not put much thought into it, just looking at combining projects I already have completed. Questions and comments welcome. —The preceding unsigned comment was added on 30 April 2008, 05:36 by AnnMarie Otoole

The reasons it may appear over engineered are:

1. I'm a big geek.
2. The project is created to support any number of groups, not just mentors.

Since my project is web-based, mentors did have to check the web page for new alerts. However, it's entirely conceivable to plug in support for notification via in-world objects- I didn't develop support for that myself for two reasons:

1. As it was an initial alpha/beta test of the software, adding in *another* feature would've created yet-another-point-of-possible-failure for debugging.
2. I remember how difficult it was to get mentors to collectively use a communicator, so developing an entirely new one seemed rather pointless.

Does your communicator have a pluggable architecture ?

SignpostMarv Martin 00:49, 30 April 2008 (PDT)