The various UI items can have names, but they always have indexes (their position in the list), for example the front window would be window 1. Apple includes an Accessibility Inspector application in Xcode, or you can manually spelunk the hierarchy by using System Events to get UI elements. GUI scripting is not for the faint of heart.

You will need to take a look at the various items to see if the UI hierarchy is the same - for starters you might try using an index instead of a title for the widow.

Templates are more for a script or application skeleton/layout than for small pieces of code. In the Script Editor, the right-click contextual menu has items for inserting various statements; another option would be to create your own scripts for inserting code snippets and place them in the Script Menu, for example: set theCode to "display dialog \"Question?\" default answer \"answer\" buttons {\"Other\", \"Cancel\", \"OK\"} default button \"OK\" cancel button \"Cancel\" with title \"title\" with icon note giving up after 5" tell application "Script Editor" to tell front document set contents of selection to theCode try check syntax on error errmess display alert "Syntax Error" message errmess end try end tell Also note that these are not social media or chat forums - it may take a while for topics to be read and/or answered.

The easiest would probably be to use some AppleScriptObjC (System Events gets a bit convoluted), for example: use framework "Foundation" use scripting additions set testRecord to {SomeText:"this is some text", SomeNumber:42, SomeBoolean:false, SomeList:{"zero", "one", 2, 3, 4.0, 0.5}, SomeDict:{AnotherList:{"another 1", "another 2", 3}}} set testList to {"test item 0", "test item 1", "test item 2"} makePlist for testList at (choose file name default name "Untitled.plist") to makePlist for plistItem at filePath -- write a record/list to an XML property list file set filePath to POSIX path of (filePath as text) set plistData to current application's NSPropertyListSerialization's dataWithPropertyList:plistItem format:(current application's NSPropertyListXMLFormat_v1_0) options:0 |error|:(missing value) return (plistData's writeToFile:filePath atomically:true) as boolean -- success? end makePlist

The result property contains the resulting value (if any) of the last statement executed. You are continually getting the button returned of the result, but result can change if you do something else from when it was last set, such as executing an if statement.  Best practice is to save result in a variable unless you plan on immediately using it. In this case, when choosing to go to the shack, if the button is "Awesome!" then the next if statement sets result to undefined (since the statement doesn’t return anything), which then fails when you try to get its button returned again in the next if statement.  The solution would be to do something like: # previous statements display dialog "You have 2 areas to go to, either the snake or the shack, what do you pick?" buttons {"Shack", "Snake"} if the button returned of the result is "Shack" then display dialog ShackMessage buttons {"Awesome!"} else display dialog SnakeMessage buttons {"Continue to shack"} end if set snakeOrShack to button returned of the result -- save for the next couple of comparisons if snakeOrShack is "Continue to shack" then display dialog ShackMessage buttons {"Awesome!"} if snakeOrShack is "Awesome!" then # the rest end if If this is the start of something bigger, a better approach would be to create a data structure that contains all the dialogs and what to do with their result, and some handlers to use it, or it is going to get really difficult to keep track.