Talk:Dialog Menus

okay, get busy Strife :}

(p.s. this is aimed solidly at learners) Chaz Longstaff 18:56, 17 July 2008 (PDT)

It makes my skin crawl to see the dialog bog described as a menu and today I finally figured out why. Menus and dialog boxes have different user & programmer expectations. It will be better if I tell you what happened. This morning a friend who is a new scripter approached me asking for some scripting help, they were making a menuing system and it just wasn't working properly and they couldn't spot the problem. They were trying to make a menu system that looked like this tree:

• Base Menu
  • Left
    • One
    • Two
    • Three
    • Four
  • Right
    • One
    • Two
    • Three
    • Four

The base dialog had two buttons, Left and Right, each of those subsequently spawned dialogs had four buttons. The Left and Right dialog's buttons were the same. So their listen code looked something like this: <lsl>listen(integer chan, string user, key id, string msg){

   integer button;
   if(msg == "Left")
       SpawnLeft(id);
   else if(msg == "Right")
       SpawnRight(id);
   else if(~llListFindList(LeftButtons, [msg]))
       DoLeft(msg);
   else if(~llListFindList(RightButtons, [msg]))
       DoRight(msg);

}</lsl> Can you spot the problem my friend was having? If you guessed that when they went into the Right menu that it executed the actions as if they were in the Left menu, you guessed right. My friend hadn't kept track of the context and so it came back to bite her since the buttons of the Left and Right boxes were the same.

It is common in the Menu APIs that they handle the context tracking, it automatically avoids any collision problems that might arise. The expectation is that it handle this sort of thing.

I think that calling the SL dialog box a menu encourages the belief that the context will automatically be tracked. In SL tracking is left up to the user and for a multi-user menu script it can be quite difficult to get right. For a beginners there is going to be a steep learning curve, and if you call it a menu the first thing they will have to learn is that it behaves nothing like a menu, that it behaves exactly like a dialog box; if they treat it like a menu, they will just waste their time and patience trying to work out why it isn't working like a menu.

Given todays incite, I think it does more harm then good to call a dialog box a menu. The scripter needs to be aware of what they need to do to make the script work the way they want it to and I don't think this helps things.

P.S. This article will likely end up being rather long considering that the target audience is newbies; there is quite a bit of glue code that needs to be displayed and explained. Dialog menus I suspect may be a bit to complicated for the newest of scripters to easily master. I think of them as more of an Intermediate topic. -- Strife Onizuka 22:23, 17 July 2008 (PDT)

I think we should consider using accessible vocabulary that ordinary people can relate to. People will come looking for "menu." It's the vocabulary used in-world by ordinary people. It's all we currently have as a menuing system to use in SL. We can call it a dialog menu, as I have. Americans for instance use the word shrimp wrongly, but they ain't going to change, so if your article is on prawns, you better stick the word shrimp in there somewhere, or they ain't going to find it,cause that's what they'll be looking for :} Chaz Longstaff 17:27, 18 July 2008 (PDT)

People will relate to the vocabulary if we make it accessible. If we need inspiration we can look to the newspaper industry as they do a good job of making complex topics accessible to their reads. Now in your shrimp & prawn article you only need spend at most a couple paragraphs worth of explanation on the vocabulary. Additionally that explanation can be injected into the content as needed, it need not be all at once. Though if we use the wrong vocabulary too much people are going to learn the wrong vocabulary. Don't get me wrong, I'm not saying "strike menu from the article", I'm just saying it's usage is excessive and inappropriate in most cases. Since we are pretty much on the same page I'll make some time to do some refactoring.

P.S. Sorry for being slow to respond, the (wiki) hardware failure the other day ate my response. It is just as well as I have taken the time to properly grok your comment. I don't think you meant it to be read as inflammatory though it definitely conveys the opinion that Americans are too stupid or callous to learn. We should never be saying "We aren't going to teach this because we think our students are too stupid to learn it." If we do, it sells our student's potential short. -- Strife Onizuka 02:26, 20 July 2008 (PDT)

Nope, not meant to be inflammatory. No more than I interpreted as such the appearance of your word "naive" in your first 14 words to me ever. Actually, I thought it was a good example. I mean, it's absurd to think of Americans changing their use of the word shrimp: after all, there are so many of them, why should they change? And even if despite that one still thought they should, the bottom line is, they ain't going to, non?

Listen, I've got an idea. The template I used for the piece classed it under Communications. I don't like it there. I think you said you don't either.

Here's my idea. People come looking for "menu" stuff. Let's get this out of communications. And in the main left-hand index on the LSL Portal page, let's put the word "Menus" in there (bear with me for a sec.) That way, it's clear for them to see. So they click on that, and we give them a (disambiguation? Is that the term? ugh.) page that says something to the effect of the following (CAVEAT: worded way better of course):

"SL does not have a real menu system with pull-down menus. A real menu system is etc, etc, etc. SL may have one one day, who knows (or whatever.) So for now, the only tool we have to deliver menu-like results are dialog boxes. A "Dialog Box" elsewhere in user interfaces often carries the meaning of an informational box you can click "Ok" in, and possibly "Cancel." In Second Life, we press the use of dialog boxes to offer the end-user a far broader selection. Technically, they remain dialog boxes, not menus, and it's important to retain the distinction in case SL ever does actually get real menus. That being said, most end-users will refer to them as menus, as they will have no idea what the technical term "dialog box" means. Some product creators therefore refer to them as menus; some like to call them "dialog menus."

With that proviso, click here to see how to deliver menu-like results in SL (ugh, terrible phrasing) using dialog boxes."

We can sort out the details of this approach, but to sum up the scheme, we catch them coming in on the wrong term, we get a chance to set them straight, and then, like a good librarian, we still point them to the information they are actually after, but didn't know the right word for.

What do you think? Chaz Longstaff 16:06, 23 July 2008 (PDT)

Hey, just had a follow-up thought the minute I walked away. It's entirely possible that I'm off-base in thinking that the word used in-world is "menu." It's entirely possible that my path has just lead me to encounter that phrase from a small selection of people, and everyone else is using something different. After all, everyone I know says "kk" instead of "okay", but maybe those people are actually a small minority in SL (which is likely.) So I'm wondering if we should consult more broadly, and pose the question in a survey poll in the survey tips forum at http://forums.secondlife.com/forumdisplay.php?f=54 . See what people think. We'll likely get a broad range of opinions, with the minority ones strongest of course as usual, lol, but it may serve to correct some thinking re the right terminology, if nothing else, and let us know what synonyms to allow for for the search engine.

What do you think about consulting more broadly, than just us two? Chaz Longstaff 16:35, 23 July 2008 (PDT)

DialogMenus Tutorial Piece

(moved here from my talk page)

Hey Strife, you wrote: "I'm not sure it should (or should not) be in the base LSL category."

Given that I can't even figure out how to find where you wrote that and respond directly there (it's not showing up in that page's discussion when I open the discussion, thus responding here, hehe), can I leave it up to you where / how to categorize? You know your filing system best, and I say, stick with it. Bottom line is that wherever it is filed, we can link people to it, right? Chaz Longstaff 21:38, 17 July 2008 (PDT)

It's currently in Communications, my thought was that I didn't want to pollute the base category. But then I really don't want to pollute the function categories... so I really don't think my wants in this case are realistic. -- Strife Onizuka 22:26, 17 July 2008 (PDT)

I'm not really sure if Communications is the right place for it, will have to do until inspiration strikes. Maybe in the Dialog cat instead or too?

Insert non-formatted text here

Code should be checked and debugged before being submitted.

I was in a class today in which the teacher actually used this wiki page for their class and the results were horiffic.

The timer event to kill the listen was constantly being called every 60 seconds which meant that between their posts of teaching things, we got 12 "Sorry, you snooze you loose" from all the objects that were being scripted at the time. Why wasn't there a llSetTimerEvent(0.0); in there to stop the timer?!

I have edited this page to compensate for that.

Also, if the person who wrote this actually tested the code they wrote, they'd find that if they pressed the "-" button in the dialog and then tried to use it again, nothing would happen. Oh I wonder why...

Maybe it was because the entire listen function was killed when it shouldn't have?

...

Yeah, it's probably that.

I've moved the llListenRemove function to within the 'else if' statements so that when a user presses "-", they get a new menu, and that new menu works.

PLEASE test the code you submit for COMPLETE FUNCTIONALITY before submitting it.

We don't want embarrased teachers now do we? ;)

Tester Ellison When menu is clicked and listen is removed then also stop the timer, there is no reason to allow the timer to expire.