Directory Studio
  1. Directory Studio
  2. DIRSTUDIO-234

Greyed out menu items should have a tool tip explaining *why* they're greyed out

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.1
    • Fix Version/s: 1.4.0
    • Component/s: studio-ldapbrowser
    • Labels:
      None
    • Environment:
      OSX 10.4

      Description

      All GUIs should have a tool tip explaining why something is greyed out and what needs to be done to make it active (and it needs to be useful information, not just "it doesn't apply" or "you're not allowed to do that now" — it's obvious the application thinks that because it's greyed out). In this case, I did a search against our ldap server, found an attribute that needed removing and did so. Then I did another search. This time the font changed to italic, and when I go to delete an attribute, Delete is greyed out. There is no clue anywhere as to what's going on. I searched in help for the ldap browser, and found very little.

        Issue Links

          Activity

          Hide
          Stefan Seelmann added a comment -

          Hi Alan,

          thanks for the report.

          In general we try to use the schema of the LDAP server to determine which attributes are editable and which are not. But you are absolutely right, there is no information why an action is disabled.

          I also thought about the GUI "paradigm", I think there are three ways:
          1) Help the user to do only things that are allowed or make sense in a concrete context. The problem is then that if the schema is not good or if the implementation has bugs the user can't do what s/he wants to do.
          2) Let the user do anything and let the server throw errors back to the client
          3) A mix of both: Warn the user in the tool if s/he does an insane action (and say why this action is insane), but if s/he confirms the action is sent to the server

          Currently we use the 1st way. I think the best would be the 3rd.

          Thoughts?

          Show
          Stefan Seelmann added a comment - Hi Alan, thanks for the report. In general we try to use the schema of the LDAP server to determine which attributes are editable and which are not. But you are absolutely right, there is no information why an action is disabled. I also thought about the GUI "paradigm", I think there are three ways: 1) Help the user to do only things that are allowed or make sense in a concrete context. The problem is then that if the schema is not good or if the implementation has bugs the user can't do what s/he wants to do. 2) Let the user do anything and let the server throw errors back to the client 3) A mix of both: Warn the user in the tool if s/he does an insane action (and say why this action is insane), but if s/he confirms the action is sent to the server Currently we use the 1st way. I think the best would be the 3rd. Thoughts?
          Hide
          Alan Batie added a comment -

          The third option is certainly the most user friendly one.

          However, in this case, something is changing and I don't know what. Specifically, we're doing some mail routing with the standard sendmail schema. I used Directory Studio to remove one sendmailMTAClassValue attribute from a sendmailMTAClassName entry. This worked once, and then while doing another search, the results started coming back italicized, which I'm guessing means non-editable. The parent entry is still editable, just not the member attributes. It acts like it's locked or something, i.e. an operational decision rather than a structural decision from a schema interpretation.

          Show
          Alan Batie added a comment - The third option is certainly the most user friendly one. However, in this case, something is changing and I don't know what. Specifically, we're doing some mail routing with the standard sendmail schema. I used Directory Studio to remove one sendmailMTAClassValue attribute from a sendmailMTAClassName entry. This worked once, and then while doing another search, the results started coming back italicized, which I'm guessing means non-editable. The parent entry is still editable, just not the member attributes. It acts like it's locked or something, i.e. an operational decision rather than a structural decision from a schema interpretation.
          Hide
          Martin Alderson added a comment -

          I just wanted to add my vote for Stefan's 3rd suggestion. I have been bitten by this smartness of studio before and had to fall back to another LDAP editor to get the job done.

          Alan: As with Stefan, I also suspect that the schema is the problem here. You might want to try asking studio to reload the schema from the connection's properties dialog box.

          Show
          Martin Alderson added a comment - I just wanted to add my vote for Stefan's 3rd suggestion. I have been bitten by this smartness of studio before and had to fall back to another LDAP editor to get the job done. Alan: As with Stefan, I also suspect that the schema is the problem here. You might want to try asking studio to reload the schema from the connection's properties dialog box.
          Hide
          Pierre-Arnaud Marcelot added a comment -

          Interesting reading on this subject... -> http://www.red-sweater.com/blog/515/disabled-menus-are-usable

          Show
          Pierre-Arnaud Marcelot added a comment - Interesting reading on this subject... -> http://www.red-sweater.com/blog/515/disabled-menus-are-usable
          Hide
          Martin Alderson added a comment -

          Good article. I read Spolsky's original article and strongly disagreed with it, although I do think disabled menu items are sometimes used when they shouldn't be.

          It always seems to me to be a good idea to give users relevant information as early as possible. I also generally think it's a good idea to not restrict users.

          For menu items that might be useful but likely are not I feel it would be ideal to alter the display of the item in some way to indicate this but still allow it to be activated. A tooltip is probably good enough but that does lose the immediacy of the disabled style.

          Show
          Martin Alderson added a comment - Good article. I read Spolsky's original article and strongly disagreed with it, although I do think disabled menu items are sometimes used when they shouldn't be. It always seems to me to be a good idea to give users relevant information as early as possible. I also generally think it's a good idea to not restrict users. For menu items that might be useful but likely are not I feel it would be ideal to alter the display of the item in some way to indicate this but still allow it to be activated. A tooltip is probably good enough but that does lose the immediacy of the disabled style.
          Hide
          Alan Batie added a comment -

          He's got a good point about greyed out menu items having value, but that shouldn't disable tooltips I would hope (never got into gui programming, though I suppose it wouldn't surprise me if apis did disable everything for inactive menu items). If so, not disabling the menu item, but manually changing the font and action so you still get the visual value for experienced users (who I'm pretty sure can still be wondering why on occasion), but also get the information to the user. If nothing else, the docs should have a menu reference that describes each menu item and what it requires for activation and other "conditions of use"

          Show
          Alan Batie added a comment - He's got a good point about greyed out menu items having value, but that shouldn't disable tooltips I would hope (never got into gui programming, though I suppose it wouldn't surprise me if apis did disable everything for inactive menu items). If so, not disabling the menu item, but manually changing the font and action so you still get the visual value for experienced users (who I'm pretty sure can still be wondering why on occasion), but also get the information to the user. If nothing else, the docs should have a menu reference that describes each menu item and what it requires for activation and other "conditions of use"
          Hide
          Pierre-Arnaud Marcelot added a comment -

          Postponed.

          Show
          Pierre-Arnaud Marcelot added a comment - Postponed.
          Hide
          Stefan Seelmann added a comment -

          There seems to be no easy way to have tooltips for disabled menu items (it is necessary to draw them yourself).

          The following actions are now always enabled:

          • New Attribute/Value
          • Edit Value
          • Delete Entry/Attribute/Value

          If an action makes no sense a warning message pops up, these situations are:

          • Add another value to single-valued attriubte
          • Add attribute that is not allowed according to the object classes
          • Add, modify or delete a read-only attributes
          • Delete the RDN attribute
          • Delete a mandatory attribute
          • Delete a object class and not all attributes are included in the remaining object classes

          What is missing now is an option to avoid these warning popups, see DIRSTUDIO-459.

          Show
          Stefan Seelmann added a comment - There seems to be no easy way to have tooltips for disabled menu items (it is necessary to draw them yourself). The following actions are now always enabled: New Attribute/Value Edit Value Delete Entry/Attribute/Value If an action makes no sense a warning message pops up, these situations are: Add another value to single-valued attriubte Add attribute that is not allowed according to the object classes Add, modify or delete a read-only attributes Delete the RDN attribute Delete a mandatory attribute Delete a object class and not all attributes are included in the remaining object classes What is missing now is an option to avoid these warning popups, see DIRSTUDIO-459 .
          Hide
          Pierre-Arnaud Marcelot added a comment -

          Apache Directory Studio version 1.4.0 has been released.

          Show
          Pierre-Arnaud Marcelot added a comment - Apache Directory Studio version 1.4.0 has been released.

            People

            • Assignee:
              Stefan Seelmann
              Reporter:
              Alan Batie
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development