I’d like to say that I am quite proud that amaroK has no context menu which has more than 9 entries. We like to keep options minimal, and our settings toolbar menu has only 11 entries.
But there is one thing which has been bothering me, and I don’t know the answer. I’ll be specific. amaroK has the ability to write cds if k3b is installed. There is always a burn menu in the context menus, which is menu entry is disabled if k3b was not found during compilation.
Is it better to remove entries which can never be used by the user, or to keep them disabled, and hence alert the user that such features are available?
I’m strongly leaning to the former, and remove anything that can’t be directly used. After all, the user would need to recompile/install the application to gain advantage and be able to use the this feature.
16 Comments
imho, it’s better to hide all entries which can’t be used.
An other thing ; In Amarok 1.2.3, even if we don’t have an ipod, there is always the “media device” tab, and we can’t hide it… (well, maybe it’s possible in a newer version, i must update)
Back in the 1990s, I used an operating system where entries in context menus were disabled (faded) rather than removed if their actions were unavailable. Apparently, the reason for this was to make users aware that unavailable features could be accessed via the menu when they became available. As a bonus, the placement of menu entries remained consistent, remaining in positions that the users had come to expect.
Of course, this scheme had to work well because the system in question relied exclusively on pop-up menus instead of menu bars and pull-down menus. Unfortunately, the use of pop-up menus didn’t catch on, other than as context menus, and we’re still stuck with menu bars today.
Definitely better to remove them, IMHO. Otherwise you run the risk of having users playing around with every option, and digging through every preference pane trying to figure out how to get the damn thing to work, which (and I say this from personal experience) is incredibly frustrating.
At the same time though, I have no ideas as to how to make functionality visible to users. There’s documentation, but really a user should never have to read that with an application like an MP3 player and most never will. Perhaps you could have a greyed out button with a tooltip? Or a pop-up dialog warning that functionality isn’t available the first time the program is run (with a “don’t show me this again” checkbox ticked as default). But you’d think there must be something more elegant than those solutions.
I definitely think it’s better to remove them. Letting the user know that additional features could be available is the job of the package manager. A good example of this is Debian’s suggests/recommends system. When you install a package, you know of other packages that will bring additional functionality. There’s a good chance that, if those packages aren’t installed, they were left out intentionally, and there’s no reason for a user to be bothered with menu items they’ll never use.
The big problem with removing the entry is that the user will search for the feature in other places, cause he has heard that it exists. So it must be somewhere, right?
We’ve been through that before, it confuses the hell out of users and leads to many complaints.
Imho disabling entry is much better so the user knows the functionality is there but just disabled.
Yes, I’m going to have to say keep it there, especially, since the burn menu becomes available once k3b is installed, and does not need to be recompiled!
Instead of disabling or removing the menu entry you could replace it with a dummy action which opens a dialog telling the user that he needs to install k3b if he wants to use this feature. This way the user knows that Amarok can burn CDs (if certain preconditions are met) and moreover he can easily find out what he has to do to really enable the feature.
As it stands it not much use as there’s no way to let the user know how to make the burn menu enabled. Alas tooltips on menus don’t work (I tried to do that for this feature already!
But you can disable the menu entry but not the popup, try inserting a popumenu for that entry that contains a QLabel with formatted text that reads:
How to burn!
You don’t have k3b installed… etc.
Yep, you can add QLabels to menus, you can add any widget. And maybe don’t disable the menu entry at all? But yes you can disable the entry and not the popup, I did it by accident once, I assume it wasn’t a bug (although thinking about it, it would seem like one! heh).
Laters.
“I’d like to say that I am quite proud that amaroK has no context menu which has more than 9 entries. We like to keep options minimal, and our settings toolbar menu has only 11 entries.”
Um??
Not quite
bah, I meant to link to http://kundor.org/images/contextmenu.png
Heh, right, got me there. Point is i was generally talking about the rest of the interface… That menu should only really exist in the player mode anyway.
why not give them the ability to update it or enable the features? If they are a linux user, they are pretty technically skilled. Just give them the ability to point to the k3b install when they install it for if it’s not already there. A little thing to remove unwanted buttons like how the media device is always there even without an iPod or something would be nice. I don’t mind having the features there as long as I can customize the look to suit what I do have.
why can’t you check for k3b at program startup and enable/disable based on that?
Well, actually it turns out that’s exactly what’s done
“Instead of disabling or removing the menu entry you could replace it with a dummy action which opens a dialog telling the user that he needs to install k3b if he wants to use this feature. This way the user knows that Amarok can burn CDs (if certain preconditions are met) and moreover he can easily find out what he has to do to really enable the feature.”
I like this idea – and I think it could also be used for the ‘visualisations’ menu entry, which is greyed out if amarok wasn’t compiled with vis support.