- dockable, resizable, optionally semi-transparent (Windows 2000/XP+ only)
- pull-down menus: Edit > Undo, Redo, Cut, Copy, Paste (plus global object properties cut/copy/paste), Undo/Redo (which should use standard Windows ctrl+z and ctrl+y commands instead of non-standard--and non-working--"backspace", which is useless in a field anyway), Move, Rotate, etc
- toolbar buttons: configurable so as not to unnecessarily widen the dialog any more than it has to be; wrapable
- object pull-down menu: with the current object's name selected and names of all objects (RWXes in ZIP files) in the object server's "models" directory listed. Hopefully this list wouldn't have to be updated each time an object was selected.
- trigger pull-down menu: "create", "activate", and "bump"
- command pull-down menu: "animate", "sign", "URL", "picture", "sound", "noise", "visible", "warp", "teleport", "solid", and "name"; when one is selected:
- "animate": Pull-down menu with the name of all textures (JPG files) in the object server's "textures" directory could appear. Hopefully this also wouldn't have to be updated each time an object was selected. Otherwise, a text entry field (edit box) where the texture name would be entered. Because this command is rather complex, a text-entry field would probably be the best option. However, a better design would be to use branching ([+]/[-])commands or even some kind of integrated flowcharting.
- "sign": Edit box where the sign text would be entered could appear. Then 2 buttons with a "color" label above: "background" and "foreground", where, clicking either, would bring, say, the color selection dialog that appears in the menu: Options | World... | Features > Backdrop Color > "Change..." button option.
- "URL"/"picture": Edit box could appear (with "http://" in front, but not IN the typing portion, since the "http://" is not needed, but assumed) where the URL is entered. Additionally, with "picture", an "update" checkbox with a small edit box for the # of seconds could appear.
- "sound"/"noise": Pull-down menu with the name of sounds (WAVs/MIDs as ZIP files, or MP3s) in the object server's "sounds" directory could appear for relative paths. Otherwise, an edit box where the file could be entered could appear for absolute paths.
- "visible": Pull-down menu with "me" (or "self" or "current") and "other" (or include other in-range named objects). Or if "other" is selected, (optional) if other objects are named in the area (cell/sector?), a pull-down menu with their names; otherwise an edit box where the name of the other object's name could be entered. Also, a pull-down menu would appear with "on" and "off" or just a checkbox.
- "warp"/ "teleport": Edit boxes for north-south and east-west coordinates (with appropriate pull-down menus for north-south and east-west); altitude and direction edit boxes. Similar to this: _# edit box_ <"N"/"S" pull-down menu> _# edit box_ <"E"/"W" pull-down menu> "altitude": _# edit box_ "facing": _# edit box_
- "solid": "on"/"off" (or "yes"/"no") pull-down menu or just a checkbox.
- "name": Edit box where the name would be entered.
- Unassociated command options should be hidden (preferably) and/or disabled (greyed out).
- Multiple, linked actions (currently separated by a semi-colon) could be done with a "More >" button, bringing up additional trigger and command pull-down menus, with the argument edit boxes or pull-down menus to follow, as needed; or just another object properties box, though these methods would clutter up the screen quicker. A "< Less" button could remove extra commands. And since only relevant information would be shown, even with multiple actions the dialog shouldn't be that cluttered. For "old-timers" and die-hard programmers, the traditional all-text commands could still be used.
- The action triggers/commands/options could be abbreviated to however AW could interpret them, with as few bytes (preferably binary instead of ASCII--at least for pull-down menus and checkboxes) used as possible so as to reduce cell byte data use, but the GUI presentation of doing object properties would remain more detailed.
- "States" of all the options could be saved and loaded so multiple-object property application would be easier. But with enhanced multiple object manipulation this shouldn't be that big a deal.