Zugg Software :: View topic

Posted: Tue Sep 12, 2006 9:16 pm

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.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

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.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Wanderer Joined: 03 Aug 2005 Posts: 84

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:

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

Posted: 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.

Posted: 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:

Posted: 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

Posted: 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.

Wizard Joined: 14 Aug 2004 Posts: 1269

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.