Context Menus vs Main Menu

[jtkirk]

I spent awhile on the help forum asking people where I could find the 'Animate Spawns' map option, because behavior has changed by default from the prior version of showeq. I didn't even know such a configuration exists. As I thought about it, I realized my confusion stemmed from a UI design issue.

It strikes me as unfriendly to only have an option available through a right-click context menu, and not the main menu hierarchy. People end up having to right click on certain parts of the screen to cause certain configuration settings to occur, while drop down from the main menus for others. That's confusing.

Now I don't know QT, so I'm not sure if the toolkit allows this, but I know that the toolkit I'm used to using (MFC) allows dynamic menus. When the map is displayed as part of the main frame, you could display a menu item called 'map'. And when the spawn listcontrol is up, you could similarly have a 'spawn' menu item.

I know this isn't the most pressing issue facing the seq developers, but it would have saved me some frustration... Possibly others as well.

[Cryonic]

I don't think there is much wrong with the UI as it stands now. The problem for most stems from not reading the documentation that is available (e.g. CHANGES file that comes down with SEQ and the announcements board). I've had no trouble with the UI and find it very usable. Right-click for things specific to that subtask (spawnlist, map, etc...) use menus for other things. The right-click is good because not everyone has the map docked with the rest of the interface, or the spawnlist or the spell list, etc.... Add to that the fact that you can have multiple maps open, so now which maps properties are you editting by using the menu in the core interface as opposed to just right-clicking on the map in question.

[jtkirk]

You make three points:

1) I didn't look in the right place for my original question, and therefore I was confused.

Very true, I should have read the CHANGES file for my original answer. But when was the last time you read the release notes to most of the software you run? I have to admit, I almost never read that stuff. I fire it up, and figure it out as I go. Sometimes I get stuck, but more often than not, what gets me stuck could have been easily fixed by a UI change. The source of the confusion for me was the odd way the UI works. I didn't look to the right place to resolve that confusion. But it shouldn't be confusing in the first place.

2) The UI works well the way it is, with operations related to a certain UI component accessible by right-click context, and operations related to the app as a whole accesible from the main menus.

True, assuming you know to right click in the first place, and further assuming that you want to use the mouse, and not the keyboard, to get to that option. I'm not suggesting you take away the right-click context menu. Just add an additional dropdown menu when appropriate.

3) A menu solution is more difficult when you have multiple items of the same type displayed in the main frame (ie. 2 maps).

I realize I'm speaking from ignorance here, because I don't know what QT 2.3 does or does not allow. But assuming that it allows dynamic menus, here's how I'd do it:

In addition to the context menus, make duplicate menu items in the main frame, named by the type of UI item (assuming any item of that type is displayed in the main frame).

Let's say there are 2 maps displayed in the main frame, a spawn list, but no player info. The mainframe should realize that the two types of items displayed are 'map' and 'spawn list'. Therefore, it should cause a 'maps' menu item to appear, as well as a 'spawn list' menu item. If the user dropped 'maps' down, it would show two menu sub-items: map1, and map2. From there, I'd see all the operations associated with map1 and map2.

There are a couple advantages to this approach over what we currently have:

1) Novice users can easily find the items they're looking for.

2) People who like to use keyboard shortcuts for menus get access to configuration settings.

I assume what I'm talking about here doesn't take a lot of effort to implement.

*shrug* I get the feeling from the only response so far that nobody else considers this a problem. It's not a big deal to me either way. But I know from experience that it's almost never the case that you can reasonably show options ONLY through context menus.

[high_jeeves]

I do UI design for a living, so let me toss my hat in the ring here:

1) Generally, its a good idea to read the CHANGES file on opensource.. it changes very quickly, and new features are constantly added... just my opinion... You will also save yourself, and others alot of headaches

2) As far as the UI goes, I would definitely stick with contextualizing the menus. Here is a scenario:

There are 5 options that work only on maps. A context menu for each map provides a simple way to view state and change state of all options for that map.

If on the other hand, I use global menus, I have no way of viewing state for all attributes on a single map.

3) Remember, UI design is about audience. The audience here is NOT new users, it is a so called "expert" audience. The ShowEQ user base is small, and long term, so you optimize your UI for ease of expert use, not for ease of new user.

Just my opinion.

--Jeeves

[jtkirk]

> There are 5 options that work only on maps. A context menu for each map provides a simple way to view state and change state of all options for that map.
>
> If on the other hand, I use global menus, I have no way of viewing state for all attributes on a single map.

Please re-read item 3 in my prior message.

[high_jeeves]

Ahhh.. you are talking about dynamic menus... UI public enemy #1.

Q) What is worse than a hard to use UI?
A) A hard to use UI that changes on you!

Context menus is the standard.. look at most products (MS ones included).. Look around at your IE page... lets say there are 3 frames... do you want a File->Print->Frame1->... and a File->Print->Frame2->..., or a right click on Framex, print.

Its standard, its used everywhere... when you have 4 maps up (many of us play with 2-5 maps), do you want to have to go up to a menu, figure out which map you are interacting with, then click, or do you want to click ON the map you want to interact with?

--Jeeves

[jtkirk]

I didn't say to take away the context menu. By all means, leave it there unchanged.

I suggested that you just add a few global menu items.

Come to think about it, those new menu items wouldn't have to be dynamic. Just display under 'maps' an item for each of 'map1' through 'mapn'. It doesn't matter if they aren't visible at the time. You could still set properties on those undisplayed maps.

Same type of approach goes for a global menu item called 'player stats', 'spawn lists', etc...

As things are right now, there's no way to get to the map options except by using the mouse. It would be nice to have a way to navigate to that stuff using keyboard shortcuts. And I still maintain that it's easier to find things for the first time if there are many paths that reach the same point.

[high_jeeves]

Well, I personally disagree, but.. this is opensource.. feel free to add a feature request, or code patch... click the links up top to make it.

--Jeeves