Zugg Software :: View topic - User Interface Design Challenge #2 : Settings Filters

Posted: Tue Dec 13, 2005 6:49 pm

In this second design challenge, I want to talk about those "filter" buttons in the Settings editor.

1) In zMUD, these are the large buttons along the top toolbar labelled "Aliases, Triggers, Macros, etc". Clicking on one of these "filter" buttons causes the display of settings to change so that only settings of that "type" are shown. So clicking the Aliases button causes the editor to only display the list of Aliases.

You can hold down the Shift key when clicking a button to toggle the button without effecting the other buttons in the radio-group. So, you can click on Aliases and then Shift-Click on Triggers and now you see a list of both aliases and triggers in the editor.

Clicking the All button reverts back to the way it started with all settings displayed regardless of type.

Class folders are an exception. The Classes button always toggles independantly of the other buttons and controls whether class subfolders are displayed. There is also a button called "Show All Classes" that determines whether only the settings in the current class folder are displayed, or whether all settings no matter what folder are displayed.

The original zMUD design for all of this was somewhat based upon the Windows File Explorer, with "settings" being like files, and "classes" being like folders.

2) In CMUD, the functionality is much the same. And this is what I want to question and discuss. The additional issue in CMUD is that there are more settings "types". For example, Status Bar items are separated from Status Window items (in zMUD they were stored in the same place). Also, there is a possibility of packages defining their own "settings types" in the future.

In zMUD, it was already hard to fit the large buttons along the top of the window for all of the settings types. So it had options in the View menu to determine which buttons would be displayed. This was a mess. In CMUD there are even more settings types, so large buttons are out of the question. Even with small buttons with tooltips it's a bit awkward.

3) So, how do you think this should work? You've got this huge database of settings. Imagine that you have dozens of plugins loaded, and each plugin has class folders and there are hundreds of triggers, aliases, macros, etc, all over the place.

CMUD already has a tree-view that works well for navigating the hierarchy of settings. It also has a better search option than zMUD for displaying settings that match various criterion. So I'm not worried about that, nor am I willing at this point to make huge changes to the tree view.

But the filter buttons are pretty easy to change, and they are a bit of a mess. So far we have one button for each setting type (Aliases, Triggers, etc), an All button to reset the filter, a Classes button to determine whether class folders are displayed, and a "Group by Classes" button to detemine whether only settings in the current class are displayed. That's really confusing! It's even confusing to describe.

What happens with novice users is that they get lost. They either can't find the setting they are looking for, or they end up filtering the list and now can't see everything that they want to see. There are several "tasks" that I'm defined over the years for the settings editor:

1) General browsing: Here, the user wants to see everything in the full tree hierarchy. Everything is displayed, and they can navigate through the familiar "file/folder" analogy to look for settings. This is analogous to the default mode of the Windows Explorer where you can navigate through folders and see the files in each folder.

2) Specific setting browsing: This is what you get when you click a button on the main toolbar for a specific settings type. For example, if you click the Triggers button in the main CMUD toolbar, you want to see a list of all your Triggers. You don't want to see any aliases, or macros...just triggers. You might want to see *all* triggers, no matter where they are, or you might only be interested in triggers in a specific class folder or specific package.

3) Searching: You know the name of an alias and want to find it. Or you know the text that is part of a trigger command and want to find it. Here you use the Search bar to enter what you are seaching for. This is pretty simple and already works pretty well in CMUD.

4) Other? What other ways do people use the Settings/Package editor?

So, how should this work? How could the "filter" buttons be improved?

Again, this is a test. If I get some useful feedback from people on this, then I'll do more of this in the future. If it ends up being a waste of time to even explain all of this, then I'll stop.

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

I write lots of code for zMUD, as I have mentioned already in other threads, and I have more than a thousand triggers, aliases, etc, in dozens of class folders. I have never once used the setting type filter buttons to locate a trigger, alias, or anything. I *do* use the search filter all the time, and I find it very useful. Sometimes I wish that I could search only patterns (or names) or only code values, rather than always searching both.

Would it be possible to carry the Windows Explorer similarities one step further (considering XP improvements) and have a temporary "Search Results" class folder that is displayed when you search and display all results there in a special column format? Just an idea. In fact, you might even have a search dialog or pane to choose options for your search, though the simple search would still be good to have, too.

Posted: Tue Dec 13, 2005 8:11 pm

The improved search bar in CMUD has a couple of these options. First, there is a "Search In" pulldown that allows you to choose whether to search "any" field (name, value, etc), or just look in the setting Name, or ID (short name), or Value, or Comments. Also, the "Search For" pattern field can contain simple wildcards. From an SQL point of view, the search is using the "LIKE" operator for SQL filters.

When there are multiple matches (like if you specific something like "a*" in the pattern), then you see all of those matches in the tree view instead of the full list of settings. So in a sense, this is like a "Search Results".

Even better is the ability to "make a tab". You can save the current search results, along with any other filters to a tab along the top of the settings editor. You can also do this by right-clicking a package or class and say "Open in new tab" from the menu. Each tab stores it's own search and filter parameters and maintains it's own "cursor" position in the settings database. So you can click the different tabs to instantly jump between different parts of the settings file, or to jump between different searches.

As far as using the filter buttons, you are probably using them without even knowing when you click one of the buttons in the main zMUD toolbar. As I mentioned, if you click the Triggers button in the main toolbar, it opens the settings editor with the Triggers filter button already pressed. So instead of closing the settings editor and then clicking the Aliases button in the main toolbar to see your aliases, you can just click the Aliases filter button within the settings editor itself. So that's the reason they are there.

But Larkin, if you have lots of scripts arranged in classes like this, then you have probably experienced the exact problem that I'm struggling with here: class folders. On one hand, being able to see the class folder structure is useful. And it mimics what people are used to seeing in the Windows Explorer. But when Class Folders are being displayed and you have a lot of them, then you end up always having to scroll down to see the settings. It's like having a folder in Windows with lots of subfolders...all of those subfolders get in the way when you are just trying to see the files in the directory (think of the Details view in Windows Explorer when there are lots of subfolders).

Then again, if you hide the folders and just display the settings, then it can be easy to get lost and not know what folder you are in. In CMUD, the current folder is always displayed just above the tree and you can click on this to view the class folder hierarchy and select another folder, regardless of whether folders are displayed in the main tree or not. This is a bit better than zMUD, but still the class folders can get in the way a lot of times.

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

I'm aware that the big filter buttons are duplicated on the main MUD window, and I don't use those, either. I prefer keyboard shortcuts for a lot of things, so it's always Ctrl-G for me. :)

I've tried to build a class folder hierarchy that makes some logical sense and no folder contains TOO many sub-folders (though that's not always possible), which makes it a little easier to navigate just using the tree view. I don't really think that part of the settings editor needs to be changed much. If I'm really lost or just braindead for a few minutes, I jump to the search option to find what I need. Most of my scripts are built in text files, though, and I organize them very aggressively.

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

Buttons take up too much space for variable typing. Maybe we could have the standard settings types kept in a separate treeview that sits on top of the Class tree? Or even a couple of nodes for filtering and searching in that same tree rather than a completely separate one? This should free up a lot of window space for user-defined types, which should get to be so many for any one person.

Apprentice Joined: 20 Sep 2005 Posts: 135

How about adding a View option for the settings to the right click menu, e.g. Windows folders. You'd right click the Settings window and have options for how to view your settings. You could also swap the position of the right click menu options with the current position of the settings buttons so that editing options are across the window and the filter options are in the right click menu. Having the editing options across the top of the window simulates most text editors and would create familiarity for new users.

Posted: Tue Dec 13, 2005 11:10 pm

Actually, there is already a "Show >" item in both the right-click menu and the main menu (under the View menu).

I try not to "hide" stuff in the right-click menu...it's usually duplicated somewhere else. I could certainly just remove the filter buttons from the toolbar and leave them in the menu if people think this is a better idea. With the customizeable toolbars, an advanced user could always figure out how to make his own toolbar with these filter buttons.

I'm just worried about adding too many steps for users who are just looking for a specific setting type. Usually when you are looking for a trigger you don't care about all of your other settings. So clicking the Trigger filter button is a good way to eliminate a bunch of the stuff you don't want to see.

Maybe MattLofton is correct and we only need filter buttons for the "major" settings like Aliases, Triggers, Macros, and leave the rest of them in the View/Show menus.

I personally think that the bigger issue is the issue of displaying the class folders, and whether or not you display *all* of the settings, or just the settings in the current class folder. I added the "Show All Classes" button in zMUD pretty late in the design because people were always loosing track of their settings, hiding down in some subfolder somewhere. But I also know that other people like seeing the class folder hierarchy all the time, and it reminds users about folders. Before zMUD showed the class hierarchy, many people didn't even know about class folders.

But the combination of "Show Folders/Don't Show Folders" and "Show all settings no matter what folder they are in" are a bit confusing to present. I've called this second option "Group by Classes" but I'm not sure if that is going to make sense to anyone.

So maybe we can have more discussion about the folder issue?

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Yeah, I posted this in the other thread where it came up, but I'm with Larkin, I never use the filter by type and find it extremely annoying when I click 'triggers' and it does filter by type because I almost always want to edit an alias or variable at the same time. I know I should click 'settings' except (1) it's way over on the left side next to 'chars' so it's annoying to click and (2) I don't associate the word 'settings' with 'triggers', 'aliases' etc... and I'm not sure what word I would associate either.

I'm a well organized person, so I keep things broken up into classes and know where to find them in the heirachy so I've never used the search for item either. I imagine having a 'search results' might be useful though.

Posted: Tue Dec 13, 2005 11:29 pm

I'm definitely open to *any* suggestions on a better term than "settings". Although since we've been using this term in zMUD for 10 years, something new would definitely need to be a lot better.

I'd love to hear from more people as to whether or not they use the "Aliases, Triggers, Macros..." buttons, either in the settings editor or the main toolbar.

Gee, if these buttons weren't in the main toolbar, I can't even think of what the main CMUD toolbar would have in it anymore ;) Also, I think it's amusing to learn that having the button "way over on the left" might make something less likely to be used. Usually thats were you want to put the most important stuff. And those are big buttons that are easy to click compared to the smaller buttons in CMUD.

Just want to make sure I'm not getting a biased "advanced user" opinion here. I'd have thought that the Aliases,Triggers,etc buttons would be something that novices would use a lot so they don't have to go digging through a bunch of menus just to edit their triggers.

Apprentice Joined: 29 Jun 2001 Posts: 198 Location: USA

I use those buttons in the settings editor. I think they're pretty handy. The only thing I don't like about them is that I have to use the SHIFT key and click them if I want to add them instead of selecting only them. I have used the filter textbox, but very rarely. I can usually find whatever I'm looking for through the tree-view and use of the buttons.

Instead of "Settings" how about "Scripts" or "Character Scripts" or "Character Package."

Apprentice Joined: 20 Sep 2005 Posts: 135

Alias, Variable, Trigger, etc, are Commands, so it could be called the Commands Editor.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I have used the filter buttons a few times. Those occasions where when I had a large class with many types of settings and I didn't want to scroll around to the region of the specific type. In general I do not think they are truly needed by most users, and that toolbar should be off by default. Let the presence of that bar be user user customizable. In other words, there should be a whole category of Preferences for UI. They should be edittable both in the Preferences section and where they are immediately applicable. Another example of this is the main zMud bar. I always tended to make those buttons as small as possible, then bury them on my layout. I never went so far as to rip them out of the global.mud, but I was tempted a few times. Just another thing eating up valuable data space for me.

GURU Joined: 24 Sep 2000 Posts: 1237 Location: USA

I agree with Vigilante. I think it should hide the toolbar filtering buttons by default, but leave a default filtering toolbar available to view/customize.

Personally, I would keep the toolbar off. This is an "advanced user" thing. When I'm working on a class that plays blackjack for me, or runs quests for me, it's never just one type of setting - the triggers call aliases, the aliases depend on variables, etc. etc. Changing the filtered view just gets in the way of progress, so I prefer to see them all.

I would definitely like to preserve, though, the Menu option of "Show" but to be honest I don't recall exactly what it looks like, so here's how it makes sense to me for it to work: It has a few options at the top, such as "Show All", "Hide All Except Current" (to focus on other settings like the one I'm looking at now), etc. Then a divider line. The listed below, every type of setting in my loaded packages - Aliases, Variables, Triggers, whatever: set up like checkbox options (see Firefox's "View"->"Status Bar" menu for an example).

The top options are for doing things en masse, the bottom options are for turning on/off specific setting types.

As far as which classes to view/etc, I like always showing them all, so I can easily switch between them. Just exactly the way Windows Explorer handles the tree-view of folders, but also has an address-bar above so I can navigate through my list in either place. I don't think there should be an option for showing/hiding class subfolders - it just confuses the issue of switching between them, or instructing another user on how to change a specific setting.

As far as calling them "Settings" or anything else, I'm not sure I agree with calling them "Commands" (I'd expect that to have a direct and immediate output to the mud, e.g. "look"), but I do think "Settings" draws confusion with "Preferences".

How about "Automation"? That's what every settings type does, in some way or another.

Posted: Wed Dec 14, 2005 3:39 pm

Vij, my mud windows were always the full size of the screen and the main zMUD bar would pop over when I moved the mouse up to the top of the screen, this a direct copy of how I have the windows taskbar and so comes very naturally.

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

I don't like the "Automation" thing. For one, I agree with Zugg that changing the name from "Settings," which has been in use for 10 years with zMUD already, is going to confuse users. For another, not everything you build in a script is automated. You can have aliases to calculate things, for example, without the use of triggers to track things or respond to events. Some folks like to do all commands manually and just use triggers to substitute and/or highlight things. I wouldn't call that automation, either.

Wanderer Joined: 11 Mar 2002 Posts: 93

I actually love the filter buttons. I use the frequently to jump around in my coding. click variables to make sure a variable is existant, then jump back to aliases and code in more, then jump to triggers to quickly get a glance at something. I understand the space requirement though on buttons, I have everything displayed and it takes alot of room up. I think they could be made alot smaller though to be honest, with a mouseover tooltip instead of large icon and text.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

My layout actually has even the basic zMud bar buried. I have MUD output in one window (raw), chats in another, and formatted room text in another. The chats and formatted room text form a column. Then I start eating window title spaces with 2 Settings editors and a Mapper window all rolled up until I need them. All of my text windows actually have thier own settings, but the more complex ones are done in the formatted room output and the main window that provides information to all the child windows. The mapper actually belongs to one of those child windows, and still I occasionally think to myself that I need more screen space. I am almost tempted to buy a second monitor, but then I would need more real desktop space to put it.

Posted: Thu Dec 15, 2005 3:26 am

*chuckle* WOW!

Larkin those things you suggested are not automation could be construed to be so, you're not calculating the numbers the computer is, you're not substituting or highlighting text the computer is. We're bound to never get 100% agreement on a new word but I think it is important to have one since Settings and Preferences are too easily mixed. Even if it has been like that for 10 years doesn't mean to say a brand new product has to do things the same way.

Posted: Thu Dec 15, 2005 6:02 pm

Larkin has a good point though. I agree with him that "Automation" isn't the right word yet. For example, Gauges are being split into their own Settings type (instead of being mixed with Buttons). And as zApp is used more and more, you might get more "visual" types of settings.

I'm open to suggestions, but it needs to be a *really* good one to "bump" Settings from the top of the list. A new product doesn't need to do things the same way, but the easier I can make it for existing zMUD users, the better.

Also, we have to keep in mind the job of support, both in the forums and in my own email. There is a *lot* in common between zMUD and CMUD. For example, the scripting language is compatible between the two. Both zMUD and CMUD have aliases, triggers, macros, etc. If zMUD uses one term for these but CMUD uses a different term, then it's going to be confusing to support players who ask questions. And I'm sure that even I would end up using the wrong term for the the wrong program.

So, there are lots of reasons to keep it called "Settings". It's not the greatest word for it, but it's not horrible either.

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

Posted: Wed Dec 21, 2005 11:55 pm

I use the filter buttons a lot. If I'm creating a "script" (and its not really the correct word, is it?) to handle something relatively complex, there are usually multiple aliases, a dozen or so triggers and a bunch of other settings. I may be working on modifying the triggers and aliases in it only, but have to scroll back and forth between them. In this case I will switch to view only trigs+aliases and the job is easier.

If CMUD makes it easier to move settings around, I'll be a happy man. I try to keep my settings logically ordered, but it is not easy. I often think of a better way to do it and am then faced with moving loads of triggers/aliases in dozens of folders from one branch in the structure to another. Its a painful process, especially when one branch automatically closes, or fully expands, when you move one of the settings.

If I could place the target folder in one of those creatable tabs, and drag/drop directly to this tab, from the tree structure.. rearranging would me much simpler.

Lastly.. I believe that the tree structure should never automatically do anything when you do something else. Dragging one thing from this folder to another should not result in a tree structure opening/closing, or the other window refocussing. Mind you.. with the new interface that shouldn't be an issue, if I understand it correctly?

For example:

Wanderer Joined: 01 Jul 2002 Posts: 81 Location: USA

I suggest one of those buttons with a little funnel on it to toggle the filter toolbar on and off. And have the default for the filter toolbar be off.

Wanderer Joined: 13 Jun 2005 Posts: 51

I would like user interface more scriptable.
Placement of panels and buttons could be more precise with buildin script.

Posted: Tue Jan 03, 2006 9:19 pm

Yejun, I looked into that, but with something as complicated as the settings editor, it wasn't possible to script it. When you let something be scriptable, then it's very hard to "optimize" the interface so that it works well, because you never know where people will move stuff.

As I said before, all of the toolbars are draggable to other locations, but the main layout is fixed and cannot be scripted.

Regarding the drag-drop issue that Caled mentioned, what happens is that when you drag a setting from one folder to another, the setting is still focused. For example, if you drag an alias from the "Misc" folder into the "Diagnose" folder, the Diagnose folder gets selected because the alias is still displayed in the edit panel and the tree always selects the folder than contains the currently displayed setting.

So in CMUD, what happens is that the Diagnose folder in the tree will be expanded, and you'll see your alias listed there and it will still have the current focus. The Misc folder will still be expanded as before...CMUD doesn't force only one folder to be expanded at a time like zMUD did sometimes. So I think that will be better. It also works as other tree drag/drop operations work in Windows and I'm trying to stick with existing user interface conventions whenever possible.

And yes, you will be able to drag a bunch of selected stuff to one of the "tabs" to move things easily like you suggested.

The only time the tree collapses or expands itself is when you issue a new "filter" or "query". For example, if you search for something. Basically, if the tree structure gets changed, then everything auto-collapses because there there is no way to save the node expand/collapse state when the structure is changed. But except for that situation, in CMUD the tree nodes stay expanded or collapsed the way you left them.

Unfortunately, there is only a single tree view that is shared by each "tab". So changing tabs is changing the structure of the tree and will reset the expanded/collapsed flag for the nodes. The only way around this is to allow each tab to have it's own tree structure, and that ended up taking up way too many resources on the system and slowing everything down (since there were multiple trees that needed to be updated whenever the database changed). So each tab remembers the previous setting that was focused and will make sure that setting is expanded, but other nodes that were expanded get collapsed when changing tabs.

Wanderer Joined: 13 Jun 2005 Posts: 51

There are actually only two reason I am using filter button in zmud setting editor. First, the full list of all settings is slow. Second, the pull down button of New not work very well when triggers are firing, so I click a filter button then new button to create new settings.

In stead of multiple tabs, IMHO multiple windows will be much better.