Opened 11 years ago

Closed 11 years ago

#6268 closed defect

Menus are enabled or visible even when they have no functional purpose

Reported by: foxmajik Owned by: deryni
Milestone: Component: XMPP
Version: 2.4.3 Keywords:


When using xmpp chat the "Send To" menu is present but embossed even though it can't be used. Since there would never be any reason for the "Send To" menu to be needed in a xmpp chat window it should be invisible instead of embossed.

In the Conversation menu in the xmpp chat window there is a "More..." menu that has an empty sub menu. If there are no "more" functions available, the "more" menu should not be visible.

In the "Conversation" menu the "Insert image..." option exists but is embossed. Since there's no reason this menu item would ever be used in xmpp chat with the current versions of xmpp servers it should be invisible instead of embossed.

Change History (8)

comment:1 Changed 11 years ago by deryni

  • pending changed from 0 to 1

Hiding menu items that are not currently usable is not a good idea at all, there is a question among some UI people as to whether even disabling menu items that don't currently do anything is a good idea. Personally I don't see a problem with disabling menu items but I do see a problem with hiding them. I wouldn't object to not disabling them either (since I understand the reasons people think that is a bad idea), but that isn't what is generally done at the moment and isn't the path pidgin has taken so far.

That being said, the Send To menu has nothing to do with the account currently active so it has no specific interaction with XMPP, it does however make no sense for a chatroom (so I'm going to assume that's what you meant).

It would be reasonable to disable the More menu when there are no actions available there, but again I don't think it reasonable to hide it.

Similarly with Insert Image.

Why do you think hiding menu items is better than disabling them?

comment:2 Changed 11 years ago by foxmajik

  • pending changed from 1 to 0

It doesn't make any sense to present menus that have no functional purpose.

Admittedly I don't write software very often, but I don't understand how presenting menu options that do nothing can be practical.

The only way I can think of to better express my point is to offer an analogy.

Suppose that you're a nurse and it's your job to hand tools to the surgeon who is doing the operation. Why would you hand him a scalpel, a clamp and a ferret? How does offering him a ferret further the operation he's trying to perform?

Certainly the ferret may be valuable in other contexts but in the context of a surgical procedure it only serves to confuse the surgeon.

comment:3 Changed 11 years ago by deryni

  • pending changed from 0 to 1

The benefit to presenting menu items that do not *currently* have a function is that the user can learn where those menu items are for when the items *do* have a function (i.e. different conversation windows, different protocols, etc.). Presenting the disabled menu items also preserves menu item location for all the other items which means people can learn how far down a menu a given item is instead of needing to scan the menu every time (this is a large part of why everyone hates Windows favorite items magic menus and turns them off).

Your analogy is flawed in a number of ways, first off the interface isn't presenting the choices it is offering them. The distinction there is key, you don't need to mentally (or physically) discard the incorrect items you just ignore them. Secondly, in your analogy the ferret never has a use in any conceivable scenario which isn't the case with any of the menu items you indicated. Each of them has functionality at some point. If you rewrite your analogy as a nurse saying "Doctor which of these tools would you like? A scalpel, a clamp, a suction hose, a suture kit, or a (Band-Aid style) bandage?" you would rightly suppose that offering the doctor a bandage while he is in the middle of invasive surgery would be less than useful at the moment but *not* having offered him the bandage would be equally unfortunate because when the kid with the scraped knee comes in he will not know it was ever an option (or he will be surprised by the new option and need to investigate it then).

Do you see my point?

The arguments against disabling items runs along similar lines, the idea is that when presented with a disabled menu item the user is unable to determine what, if anything, will allow them to access that menu item and as such is unable to determine how to proceed if the action they desire is currently disabled. It is believed that it would be better to present the user with an explanatory message indicating why their desired action is not currently possible when the item is clicked rather than to pre-emptively disable it.

comment:4 Changed 11 years ago by deryni

  • Owner changed from nwalp to deryni

comment:5 Changed 11 years ago by foxmajik

  • pending changed from 1 to 0

Surgeons do not need bandages. They perform surgeries, not ER visits.

The same goes for software contexts.

It's a self-referential paradox:

If there's no reason for a menu to ever exist in the present context the menu should not be there.

If you would present one menu that is not valid in one context for UI consistency, then you should present every menu in every context, which means you should also include the Tools and Help menus that are not present on the Chat window, and conversely, the Conversation and Options menus which are absent on the Buddy List, and so on until every menu contains every other menu.

comment:6 Changed 11 years ago by deryni

I could have stuck with suture kits, but tacked on bandages to make the case clearer. I apologize if my attempt at clarity offended your doctor-ly leanings. Nonetheless my argument stands, the issue is one of mode of presentation (and cost of divestment) as well as an issue of learning about available options.

The conversation window is not the buddy list. Claiming that because a menu exists in one it must exist in the other is taking consistency to ludicrous levels (and while I appreciate the rhetoric value inherent in such tactics I would appreciate them being left out of this discussion in the future). The context issue is nowhere near that large. The conversation window *is* the same between IM tabs and chatroom tabs. Tabs for both can even exist in the *same window* so claiming they don't share a context is a stretch.

I will admit that the Send To menu being displayed for chat rooms is, by a wide margin, the strongest of the claims you made and the claim my defense is weakest against. This is largely because (for most people) the difference between an one-on-one IM and a chatroom is pronounced. (It is worth noting that for people who come from MSN that difference is vanishingly small, as MSN allowed you to freely morph one into the other.)

My claim about the Send To menu (which I'm assuming is the main thing you are now arguing against because I fail to see how your defense works on the other items you initially indicated) is that the "context" for the menu bar is firstly "conversation window" and only secondly "active tab" and as such the Send To menu should continue to exist even in chat rooms. I will grant that if the "Separate IM and Chat Windows" placement preference were being used that there would be (a mostly valid) reason to hide the Send To menu from the "chat" window (it would need to return if an IM window were manually dragged into that window however, for contextual consistency).

To bring in a small bit of technical argument, not requiring a continual cycle of hide/display/hide/display when switching between chat and IM tabs in a given window has efficiency merits. This is by no means an important point but is something that has a small amount of weight in deciding between roughly equivalent options.

To be clear about the non-Send To items. Your Conversation->More menu is empty because you don't have any plugins loaded that supply you with actions on your chat room, mine is not. The Conversation->Insert Image is disabled because that feature is *currently* not supported for the chat rooms on that protocol (but might be on other protocols) and at some future point may even be supported on that protocol in which case the item will cease being disabled.

I would also like to point out that you seemingly ignored my points about menu location learning and the ability to see what options are possible in other similar contexts.

Do you have further reasons that you believe the Send To menu should not be visible in chat rooms? Can you explain, without resorting to an analogy (that we have both made bad attempts at creating), why you believe it better to remove a menu item entirely rather than simply disabling it? Can you explain how removing them doesn't hurt learning the location of menu items or the ability to learn where the items for features you haven't needed to use yet live (so that you can find them more quickly in the future when you do need them)?

comment:7 Changed 11 years ago by deryni

  • pending changed from 0 to 1

comment:8 Changed 11 years ago by trac-robot

  • pending changed from 1 to 0
  • Status changed from new to closed

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!