Zugg Software :: View topic - User Interface Design Challenge #1 : Preferences

Posted: Tue Dec 13, 2005 6:30 pm

OK, some people have been asking to get more involved in the UI design, so let's tackle a couple of specific topics. This topic is on "Preferences" and is actually a very difficult issue that I haven't come up with a good idea yet. So this is an area where you really can make a difference. I keep posponing doing the Preferences because I haven't come up with a good solution yet.

Here is a description of the functionality:

1) Definition: "Preferences" are all of those options (like in the zMUD Preferences screen) that can be turned on and off. "Preferences" are *not* aliases, triggers, etc (those are "Settings"). "Preferences" are things like: Is the AutoNumlock option on or off? What is the telnet terminal type string for zMUD? How many scrollback lines do you want to save? etc.

2) OK, let's look at zMUD so that we are all starting on the same page. In zMUD, there was a single Preferences screen (in the Edit/Preferences menu). This screen has a tree-view on the left showing various Preference "categories", such as "Command Line", "Spelling", "Syntax Editor Colors", etc, etc. You would click on a category, and then the part of the dialog on the left would show all of the "Preferences" assigned to that category.

Now, what was confusing was "inherited" preferences. The default value of all these preferences was loaded from the default.mud file when you first created a mud character. Once loaded from default.mud into your character.mud file, you could then change the preferences in your character specific file. To change the default.mud file, you needed to specifically load this file into zMUD and then change the preferences, then save it to default.mud. There was a lot of confusion because some of the preferences are not saved in the .mud file, but are instead saved in the zmud.ini file (global preferences). Global preferences and character preferences were jumbled together in a confusing mess.

3) OK, that's the past. Now let's look at CMUD. Here is how Preferences work in CMUD:

First, "global" preferences are split from "character" preferences. The global preferences (like whether the Numlock key should be automatically enabled) are still stored in the ZMUD.INI file and are still edited in a Preferences dialog similar to what zMUD had before. And while you could start a new thread on this type of Global Preference editor, that isn't what I want to talk about in this thread.

What we are left with is the complex "character-specific" preferences. For example, the Color-Syntax for a specific MUD. Or the various emulation options (VT100, ANSI, MXP, MSP, MCCP, etc) for the MUD server connection. Or the color mapping for the ANSI colors. Etc.

These character-specific preferences are now stored in packages. For example, you could have a package for a specific MUD that just specifies the Color Syntax for that MUD. Packages can also define their *own* preferences. These preferences can be accessed easily via scripts so they can control how the triggers,aliases,etc in a package function.

So each package can have an unknown number of "preferences". This can be a mix of pre-defined preferences (like color syntax, emulation options, etc) or can be additional preferences custom to that package.

But the player can also edit these preferences and override them. For example, they might load a package that sets a particular color scheme for a MUD, but then they want to change one color. If they are the package developer, they might want to change the color defined in their package. But if they are just a player, they just want to override the color with their own without changing the package (similar to overriding a trigger or macro with your own).

So CMUD allows each package to add new preferences, or override existing preferences. The player can set the order in which packages are loaded to control which package has priority. The final "character-specific" package, which only contains end-user customizations, is loaded last.

4) That's the functionality. So the challenge is: how is all of this presented to the player? The player needs to be able to easily modify preferences, either specific to a package, or more general. What if multiple packages override the same Preference value? How do you change the values stored for the package, and how do you just change the "current" value of a preference being used. How does a package developer "add" new preferences to their package. How does the package developer put together the ZML UI screen that allows the player to change these preferences at runtime?

There are lots of issues here. And it gets complicated fast.

One obvious thing to do is split the different tasks into "types of users". For example, there are things that a "package developer" might need to do, and then there are things the "mud player" might need to do. CMUD can handle this via a "Design mode" that the package developer might use to design their plugins, vs the normal mode the mud player uses to modify preferences.

So I'd like to have a discussion of this. Tell me how you'd like to see this handled if you were a package developer, or just a simple novice MUD player. If this method works well, perhaps I'll use it for other aspects of the CMUD design.

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

The issue of global versus package preferences can be solved with a tree view that has essentially two roots. It saves you from creating two separate dialogs, and it collects things together for the user to find without the hassle of having to remember where a given setting resides. If a package overrides a global setting, an indication would be useful. I like, for example, when my Visual Studio project preferences show a setting key name in bold to indicate that I have changed the value from the default.

The SSH client I use has a combined settings screen, though I admit it's geared towards the geek users.

As for building packages with their own preferences of UI, perhaps there can be a special editor for directing the settings towards a specific package, or some sort of package creation wizard (sorry, heh).

Apprentice Joined: 08 Dec 2005 Posts: 108

I like the idea of having seperate modes for the user and the developer. As a user I would like the option of loading the default value (package value) for any of the settings. I personally like the tree method of finding settings, alias, etc. As a developer I would like the ability to change the user values around, and when I come up with what I like, i would like the ability to easily convert the user value to the package value. In the past I have seen this implimented as a simple button that says, make default. The reason that this would be nice is that there are times as a developer I play around with values to tweek what is happening as i am coding. I like being able to keep the original one (lots of times it ends up working better than what i played with), and not have to write it down somewhere on a piece of paper.

Posted: Tue Dec 13, 2005 8:24 pm

The difficulty is when multiple packages override the same value.

For example, imagine that the "default" text color is black. Then you have PackageA loaded which overrides the color to red. Then you have PackageB loaded which overrides the color to blue. Now the player want to change the color to purple.

OK, so you display the text color preferences screen and the player sees that the current color is blue and he changes it to purple. That stores "purple" as his character-specific preference which is always loaded last, overriding everything before it.

Just making this "bold" to show that it has changed from the default doesn't help much. In fact, what if purple *was* the original default, and was then overridden to red and then blue. A simple "bold" indicator doesn't actually tell you much.

Also, just adding a "Make Default" button doesn't help. What are you overriding? The original default setting? If you override the original setting (changing black to purple), then your color is still blue because of the other packages. Do you override one of the package settings? Which one?

Also, when it comes to changing defaults, you run into a problem that was bad in zMUD. The problem is when other people update their package files (or when I update the main zMUD default.mud file). Updating these files overwrites any changes you have made. So if you spend a lot of time changing the values in the Default file, then a new Default file is released, all of your changes get lost. That's what happened in zMUD.

In CMUD, I'm trying to figure out a way to override the values in packages without having those changes lost when the package is updated. So you can't store your new values within the original package. You basically need to create a new package that overrides the original settings. Then when the original package is updated, your overrides are still applied. In this case, you want the changes made to the preferences to be stored in your "override" file. But you might have different files: one file to override color settings, another to override MXP preferences, etc. So it's not obvious which file to update when you make a change.

This is the kind of stuff that continues to make my head spin, which is why I'm having trouble with the Preferences in CMUD right now.

And yes, obviously I'll be using a Tree View for Preferences. In fact, I'm trying to figure out a good way to integrate the Preferences editing with the Settings editor since in a way a Preference is just like any other setting that can be overridden. It would be nice if I could come up with one interface that worked for both, if I can find a way to make it less complicated.

But your tree diagram also does a good job illustrating the problem with preference "trees"...there is just *so much* complexity there for novice user. A novice user takes one look at the tree on the left and gets completely overwhelmed. Also, even advanced users end up having trouble finding stuff..."was the Pueblo Detection in the Emulation page, or in the MXP page??"

But I've got to laugh at a couple of those "categories" in your display: "PKCS #11"?? That's just hilarious. I'm sure it means something to someone, but that's such geek jargon that I just had to laugh. Hey, what about the "PKCS #10" settings?? Where are they? Laughing

Not even good tooltips will help save that one I'm afraid.

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

I agree completely that the tree view for preferences can be very daunting for the novice user. Since most dialogs that use this format have parent categories with no options of their own, maybe that (normally blank) space could be used to explain a little bit about what the category is for, or give some sort of useful information to the novice user.

Even in zMUD there are settings that most people have no idea when to enable or disable, such as MCCP, GA/EOR, etc. To the novice users, they'll just leave them set to the default until someone like me tells them that they should change them to play the game better or fire prompt triggers more reliably. Honestly, I have no idea what PKCS #11 is, either, which is why I never even look at that part of the options (or much of the rest of them, for that matter). We avoid or ignore what we don't understand, and I'm even one of the increasingly more rare manual readers.

If you get the preferences worked in as a tab in the settings editor, would that open up a search possibility? We may know that we want to change something to do with emulation or number of lines, but not where to find it or what exactly it's called. Using a LIKE query to track down elusive preferences might be helpful for some of us.

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

The best analogy I can think of to re-describe this is that it's very much like Photoshop's Layers concept. An image (or your preferences) has as many layers as you want, but the ones on the top of the stack mask the ones on the bottom. If a certain area of the top-most layer has a transparent region, then the layer below is shown, and so on.

I make the assumption that the total set of preferences chosen is finite. For a given topic, all the switches/controls/displays fit in a window and from package to package will be shown in the same place

So if that analogy is correct, I would capitalize on Adobe's work to make Photoshop understandable, and imitate their layer paradigm...

Show a set of tabs at the top of the window that control the group of settings being displayed.
Show the list of packages in order of load, from most-recent (top) to oldest (bottom) (left pane of the preferences window).
Select the top-most layer by default when the window opens.
Let the user choose which package (layer) to view by clicking on other package names in the stack.
When a package is selected, its name appears selected and its settings are displayed at right.
Packages can be re-ordered by drag/drop to control their stack order

See my crude screen shot mockup for giggles:

In my mockup, the "Darker" settings are currently displayed. The items to the right are the state of "Screen" settings at or below the "Darker" level. Bold items are settings IN the "Darker" package, regular text settings are derived from packages in layers below.
The "Battle" package would supercede all others for any settings it declares, "ThisMud" supercedes "Darker" and so on.

It just seems more obvious to me to ditch the tree view in this case, and opt for tabs that scroll left/right, or stack, to accomodate different "pages" of settings.

You'd have to do something with the toolbar to make saving changes evident... like "save Darker" (the currently selected package), "save All", etc.

Anyway, just my first idea.

Apprentice Joined: 08 Dec 2005 Posts: 108

Zugg, I am not sure if you have ever used vim. But it has an interesting way to save scripts/settings for multiple levels
What it does is have a default directory, and all the files in that locations are loaded up first. Then it goes to the user directory and loads up those, and finally there is an after directory in the user directory that gets loaded last.

They way I could see this being incorporated into cMud would be to have any packages that you provide in the default directory. Any packages that user would download or create would be in the user directory, or any user overrides for the packages that you give would be here.. And in the after directory would be any of the settings/scripts that are overwritten from the user packages. This seems to work pretty well for vim. but of course being vi all the settings have to be edited in a text file. That would not be the way to go. (Though for a power user this might be a cool option, to have the ability to open up all the settings/scripts in a text file for a package. I know larkin and others write massive scripts, and this would be easier for them to do.

Posted: Tue Dec 13, 2005 11:24 pm

cazador, I prefer not imposing a complicated directory structure. zMUD did this a bit too much already and it caused problems with users who wanted different folder configurations, or had shared files on a network disk, and stuff like that. With CMUD, packages come from the cmud/packages directory by default, but you can actually override this anyway you want and pull packages from any location (network disk, etc), or even fetch them from a remote SQL database. I don't want to get rid of this kind of power for a simple text file and directory structure.

Packages *can* be in a text file using the new XML format, although they will load a lot slower than settings stored in a database format. Also, XML files are subject to corruption: one wrong edit and the entire XML structure can get messed up and unreadable.

Darker, you have provided an interesting suggestion and idea. I'll need to think about it a bit more, but it has a lot of possibilities. One complexity is that there is *not* a fixed number of settings, nor a fixed layout. Each package can provide their own layout of their own settings. But handling the main "default" settings in CMUD might work with what you described.

I tend to not like tabs across the top when there are too many tabs though, and the number of settings pages is quite large these days. I think I counted something like 34 Preference pages in zMUD, which would be 34 tabs along the top, which is too many. That's the reason for going to the tree view in the first place.

But, it still might be possible to have the tree view on the left to select the Preference category, and then have the package list on the right for selecting the "layers" as you mentioned. In fact, I like that even better because at first glance it's still familiar (looks almost like the existing zMUD preferences that people are used to), with just the added "layer" selection control on the right.

I doubt I'd let users change the package order at this point in the interface though. That gets set from the initial character screen, replacing the old "Files" tab where you set the Primary and Inherited settings. Once stuff gets loaded into memory, changing the package order on the fly is pretty hard without just throwing everything away and reloading it all again in the new order, and that's not something you'd want to do on a simple drag/drop operation I don't think.

Hmm...interesting ;) Definitely some ideas for me to think about. Thanks!

Larkin, yes, the preferences are stored in a database now, just like the settings. So doing a search is certainly possible. The database stores the ID number and ID (short) name of each preference, and you'll be able to modify *any* preference via a script using this short name. In addition, the database stores the text label (like the text to the right or left of the checkbox option), along with the full mouse-over hint for each item. So when searching, it would certainly be possible to search both the text and/or mouse-over hint. I'll give that some thought and see how easy it is to add that once I determine whether or not the Preferences get integrated with the Settings or not.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

If I follow correctly you had planned to have the ZML define the categories. So the default package would define a number of categories and subcategories then the preferences that go in them. Then further packages can define other categories, other preferences, or just override a previsuly defined value. This almost makes me think that after the tree view is expanded to the Preference level you get 1 more level. That would be a package list showing which packages define it, and what value they have for it. This makes the top level of the tree category, as it has always been.

I think the best way to do this is when 'design mode' is on add tabs for the category+subcategory page that show all the packages defining preferences within that group. This would then allow a specific package's definition to be changed. These tabs can easily be allowed to be 30 items or so since they will only be used by those of us willing and wanting to tweak things on a specific package level.

Posted: Wed Dec 14, 2005 8:06 pm

I agree with Vijilante. The really should be a design mode or advance interface. I'm almost certain I'm not even using a tenth of zMud's power. And as Larkin neither do many casual users. Integrating a tab/layers view in advance mode would be great but for novice users the standard tree should be fine. (You might even consider a "simplified" for common settings. Definitely highlight a setting that's been over-ridden and then display a tool tip in Novice/Standard mode that shows the over-ride history.

I know there maybe UI guru's who just spit on the ground on what i just said but I like the idea of choosing multiple views. For example SpyBot S&D gives you the option that limits the options and tools you have access too. By doing something like this you give advanced users the power to fine tune as every detail with out overwhelming a novice user. Of course there's the other drawback of having to maintain two displays for the same settings.