Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Sep 12, 2006 9:16 pm   

Multistate Triggers and Buttons UI
 
I haven't heard many opinions on this, but I think I hate the user interface for dealing with multistate triggers and buttons.

The current interface stems from the implementation details. Each trigger and button "state" is a separate record in the database. Since the Tree View in the settings editor is showing the records in the database, it shows these states as "child nodes" of the parent trigger or button. Then it adds the "Add Child" button for adding a new child state.

I'm currently working on fixing the many bugs with Buttons, and I've discovered after playing with this for a while that it just isn't very intuitive.

For example, a push button only has one state. A "toggle" button has two states. This allows you to execute a script when the button is pressed, and then when it is press again (to release the button). It also allows you to have different captions, colors, etc when the button is down vs up.

But the second state just shows as "0:" in the tree view.

Should these multiple states be shown in the tree view, or should there be a separate list of trigger or button states on the right side of the editor window somewhere?

I didn't like the interface used in zMUD either. In zMUD, the "states" were shown on a separate tab. But that meant a lot of tab flipping. You'd flip to the States tab to change the state, then flip back to the main tab to change the script or caption. I didn't like that.

Many we just need some "out of the box" thinking on this. I'd like multi-state triggers to be easier to create and edit. And while multi-state buttons (with a drop down menu) are less common, the 2-state toggle button is *very* common and also needs a better interface.

The other setting that uses "child states" are the menus. But the way menu states work with the tree is actually pretty natural. It allows you to easily create nested submenus, and the tree hierarchy is a good way to show that.

But for some reason, even though I think the UI is fine for menus, it just doesn't feel right for triggers and buttons.
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Tue Sep 12, 2006 11:15 pm   
 
I create 99% of my multi-state triggers in text scripts, mostly because it's easier to edit them there and see all of the logic from one state to the next. When I do create or edit a multi-state trigger in the settings editor, I use a mix of the first tab's drop down combo box for selecting a state (for editing the script code to be executed or the trigger pattern) and the States tab (for double-clicking a row to make it active and change the options on the last tab or to change the type in the column to something other than Pattern). It's never been fully intuitive, I suppose, but in zMUD it was easier to figure out and get used to than the CMUD way.

So, I'm afraid I don't have much to offer you in terms of an innovative new way to go about editing multi-state triggers, except that the text format made the most sense to me with zMUD.
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Wed Sep 13, 2006 12:00 am   
 
Quote:

Many we just need some "out of the box" thinking on this. I'd like multi-state triggers to be easier to create and edit. And while multi-state buttons (with a drop down menu) are less common, the 2-state toggle button is *very* common and also needs a better interface.


I think it'd be swell if patterns/captions could be listed in a scrollable list rather than a dropdown (maybe a list across the top of the window for triggers to better accomodate the normally longer trigger patterns, and a list on the left to better accomodate the shorter-but-more-numerous button states). We could click between the states without really leaving the window, and the various state-level properties would reside next to this list. A separate tab would probably best serve for general, setting-level properties that didn't require us to mess with the states themselves.

Regarding the state-level properties, perhaps if space were a premium the Value text area could be reduced to a button, opening up a much roomier, text-editor style window when clicked (ie, like clicking Post Reply)?

Or perhaps it all could work a little like an email client, where the main settings Edit window only lists the state patterns/captions and maybe a few other points of data (ie, type, and parameters in the case of triggers)? Clicking/double-clicking on a specific state would bring up a separate window with a higher level of detail.
_________________
EDIT: I didn't like my old signature
Reply with quote
acaykath
Wanderer


Joined: 03 Aug 2005
Posts: 84

PostPosted: Wed Sep 13, 2006 12:59 am   
 
I have never used multi-state triggers... though from what I've read in the #wait thread I should probably learn. As for the UI, I can only think og two ways. I have a set of tabs above the edit box:

Code:
/State:1\/State:2\/State:X\/Add State\
+----------+
|Code      |
|          |
|          |
|          |
+----------+

or have a collapsable list of edit boxed:

Code:
|State: 1 [collapse/expand][Hide][showall]|
+----------+
|Code      |
|          |
|          |
|          |
+----------+[/
|State: 2  [collapse/expand][Hide][showall]|
+----------+
|Code      |
|          |
|          |
|          |
+----------+[/
|State: 3 [collapse/expand][Hide][showall]|
|State: x [collapse/expand][Hide][showall]|
[New State]
Reply with quote
Kjata
GURU


Joined: 10 Oct 2000
Posts: 4379
Location: USA

PostPosted: Wed Sep 13, 2006 3:44 am   
 
Zugg wrote:
Many we just need some "out of the box" thinking on this.


Alright.

For multi-state triggers, use a finite state machine representation. Draw each trigger state as a node in the finite state machine with arrows that connect to the next state. Each node's label contains the numeric id of the state and perhaps even a new, per-state name field. Each arrow's label is the condition that must be met in order to go to the next state (a pattern, wait 10 seconds, loop 5 lines, etc.) Double-clicking on a node lets you edit the script that is executed in that state.

It's not as easy to implement as other solutions, but you asked for some "out of the box" ideas. Very Happy
_________________
Kjata
Reply with quote
Tech
GURU


Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA

PostPosted: Wed Sep 13, 2006 4:28 am   
 
Kjata... I love the idea of a state machine.. but you're right it'll probably a night mare to implement. For multi-state triggers I actually like the interface that's in CMUD for multi-state triggers. The only thing that was immediately obvious to me (and this was probably due to a bug) was how they would be nested.

Here's an idea for the toggle button interface. I thought it about looking at the appearance preview (which is a great addition BTW). On the main edit screen for the button show the button in it's current state (and the code associated with that state). When you click the button (still in the settings editor) the preview shows the next state and the code associated with it.
_________________
Asati di tempari!
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: Wed Sep 13, 2006 8:48 am   
 
It took me a while to figure out how to create a multistate button, but the cause of that is what I assume must be a bug.. probably reported already though I'll report it again anyway, a little later tonight. the bug in question is that clicking 'new child' once I've created the button itself, creates a child window rather than a new button 'state'. Once the window is created clicking it again will create the button state as it is supposed to.

Once I figured that out though, I found it very easy to create a multistate button. Much easier than in zmud certainly. Its not very logical though, I don't think. I only worked it out by the trial-and-error clicking of random buttons. "New child" does not suggest, to me, the creation of a new line in my intended drop-down menu button. The fact that it is right underneath the save and import scripts buttons doesn't help me figure it out either. At first I assumed that this oddly named button must be grouped with those on purpose, due to some similarity to them. Only curiosity led me to click on it at all.

The tree view makes it very simple to create and edit the buttons though, which is very nice. Zmud's system for this is horribly clunky. It doesn't really seem to "look" like it represents a drop-down menu.. but it is definitely functional and I'm sure I'd get used to the look. Perhaps if the "Ab" icon in the tree view that represents the button setting type were only used for the button itself, and not the "child buttons states" it would look more logical?
i.e. instead of:
Code:

 - Ab
        - Ab Name of state 1
        - Ab Name of State 2
        - Ab Name of State 3

use:
 - Ab
        - Name of state 1
        - Name of state 2
        - Name of state 3

or even:
 - Ab
        - 1. Name of state 1
        - 2. Name of state 2
        - 3. Name of state 3


For toggle-type buttons, display each of the two states as a separate 'child' in the tree view, with the label/icon for each clearly representing up/down.


Multistate Triggers
Similarly buggy "add child" button, but ignoring that.. I like this way of doing it. Its easy to switch between trigger states when editing, and easy to create a new state. Easy to change the state trigger type without switching between tabs.

The drop-down menu for the trigger type though, has a scroll bar. This doesn't seem necessary.. can't all the trigger types be displayed at once, eliminating the need to scroll up/down to find the type we need?

The tree view looks good to me. It also seems to make logical sense, though as with multistate buttons i think the icon itself for the child triggers could be different. An icon with a number, showing the state it is would both look good AND be useful (#STATE 8.. er, or was it 9? Dont make me count them Embarassed )

Also "add child" is an odd name for it. "New child trigger state" perhaps?


LASTLY (and most importantly imo) the tree view does not appear to display which state the trigger is currently in. The red/green flagging in zmud is very useful for debugging. Almost essential when you start mucking about with both reparse and manual trigger states in the same trigger, though merely useful with more simple multistate trigs.


And thats it for my musing on that topic. I hope it helps? (I have not played much with cmud yet, tonight was my first attempt at multistate trigs, and first attempt at buttons of any kind at all. So take the trouble I had as an experienced zmudder trying cmud for the first time..
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Sep 19, 2006 6:02 am   
 
Caled, those are some really good comments and ideas. I didn't implement any changes to this in 1.06 yet, but it's something that I'll be doing in 1.07. So feel free to continue the discussion.

But the chances of doing something completely new/different/complicated like state diagrams is pretty slim. Maybe that's something I'll do in several years when I have run out of other stuff. Right now I'm looking for more incremental improvements. Kind of like when I was stuck with how the Preferences should work and ended up with a much better user interface but without having to completely rewrite it from scratch.

Except for the mapper and database module (and zChat...and...) I'd like to avoid the "rewrite from scratch" solution as much as possible. After rewriting the entire package/module/window system and then rewriting much of the session stuff, I'm a bit tired of rewrites right now Wink
Reply with quote
Riesz
Novice


Joined: 16 May 2006
Posts: 35
Location: Plymouth, England

PostPosted: Tue Sep 19, 2006 7:57 am   
 
The problem I had in CMud with buttons was to do with Gauges actually. I had them working just fine to track my health in zMud, but in CMud I can't get the gauges to do anything. Most of the buttons to do with displaying health didn't seem to be there. I may have missed a thread that went passed stating on how to use them. I can't see clear places for the current/max values to go, or a place to change the colour if it got below a threshold. The only places that look like they should handle these variables do nothing in v1.05. I'll grab 1.06 today and have a toy with it though.
_________________
Elaria, Lusternia.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Tue Sep 19, 2006 9:45 am   
 
Riesz, see the "Things not found in the CMUD Beta" document. There is no interface for editing guages at the moment. I believe it might be in 1.07.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net