My application is context-sensisitve and I dynamically build menus for the main window / context/popup, and other places. I typically know if a given menu command will be valid given the current state of the application. Is it better practice to DISABLE/GREY the menu options which currently do not apply OR since I'm generating the menu anyway, OMIT them entirely?
The application is a Java/Swing is anyone is curious. The question seems GUI toolkit agnostic but may be platform dependent.
The old apple guidelines say to Disable for fixed menus (in the menu bar), and omit for context menus.
I guess the motivation is that a context menu is supposed to only show options that are available to the particular context, and the main menus are supposed to show all commands, so the user knows where "Save" would be even if it's not selectable at the moment.
For right-click menus, I'd say that if the item is applicable to what was right-clicked but is for some other outside reason unavailable, disable it. If it is not applicable to the right-clicked thing then hide it as there's no chance of it ever showing up. Case in point:
When I right-click on the background area of this page in Firefox the first four items are Back, Forward, Reload, and Stop. Forward and Stop are disabled because they aren't valid actions right now (I have no forward history and the page is not loading anymore). These four guys are very consistently offered, they are expected, global, often-used commands. They are the four main "navigation" controls and by default they have toolbar counterparts (in the form of big dedicated buttons).
However, if I right-click on an image, I get completely different options in the context-menu all related to viewing, saving, and copying the image under where I clicked. These options don't appear at all (not even disabled) under normal use because they are very specific to what I right-clicked on. When right-clicking on the background area, Stop and Forward, while currently not valid actions, are still applicable to what I clicked on (the page) but they are unavailable for other reasons...
Like the rule for menus on the top menu bar, the goal is not to surprise users with commands suddenly appearing for, from the user's point of view, inexplicable reasons.
Related
So this is a rather specific question I feel. I want to be able to pre-load the Firefox context menu. I'd like this to happen each time a new tab and/or window is opened. I want the menu and all its associated items to be rendered upon such a request, but I don't want the menu to open as well.
And just to preface, I have e-mailed the developers of OneTab about this, no reply.
(This next section's a bit rambly, but it does explain how I came to the above question).
To contextualise why I'd like to do this: I use an addon called OneTab. It's an awesome addon (and this isn't a plug, just what I think). It can transfer some/all of your current tabs in Firefox into a singular tab for reviewing etc later. So each time you send a bunch of tabs into OneTab, it creates a new group for them. You can name these groups too which I like to do. Helps stay organised. I habitually create a lot of tabs when I'm browsing. So I've also got a lot of tab groups. Now another feature is OneTab's context menu. This is pretty much the method by which you send tabs to OneTab. Now once you've created tab groups, you can then send future tabs to those groups, via the context menu.
Rendering all those options each time the menu is opened on a new tab, takes about 3 seconds for me at the moment. It also stops me interacting with any part of Firefox for that time. Here's an example of the (current) menu structure. Example of OneTab menu structure. At the top right of the menu structure, where it says "Surge protection", there are 4 sub-menu headings. This is the case for all the other tab groups. So that's a lot of entries to render at once. I'm not surprised it takes a while.
One other thing: after I've loaded the context menu once (on the particular tab I'm on), it's just there. The next time I right-click it loads instantly, which is what I want to happen in the first place!!
So this is why I'm asking if it's possible to change the behaviour of the context menu from the Firefox source code. So that all the items are pre-rendered each time a new tab/window is created, but the menu is still opened normally via a right-click. And I think I'd like to utilise Workers for this. Because I know that Workers are background. They don't prevent user interaction. And that's exactly what happens currently, for 3 seconds. And if there's a way of doing this via an addon then so much the better. Whatever works!
Does this all make sense somewhat? I'm sorry if I've broken any formatting rules or something by posting such a long and wordy question! Just thought I might as well be detailed.
I have an app which is run from the menu bar only (LSUIElement is set in the info.plist) which means there is no main menu except the menu I attached to the status item. The problem is I would like to enable some edit commands when using an NSTextView (like command-c to copy) but all command keys seem to be disabled since the app is technically not active (I get beeps when trying any key combinations).
Is there anyway to add a standard edit menu somewhere and enable command keys that would redirect to it? I'm thinking there could be a hack to make the app temporarily active or something but I can't figure anything out.
Thanks.
They're not disabled. They're gone, because you deleted them.
You need to put back your Main Menu.
If you use version control, you may be able to resurrect it from the past using that. If not, you'll have to create a new project, copy anything custom from your Main Menu nib (if you even still have one) into that one, and move that nib into your actual project to be your new Main Menu nib.
The Edit menu commands, window-related commands (e.g., Close), and numerous other commands all live in the Main Menu. If you delete the Main Menu, you don't have those features anymore.
Your Main Menu isn't visible in a UI element app, but that's not a reason to delete it—it's a reason to keep it, even though your app won't have the menu bar, because not being visible means that it won't peek out from behind the curtain but will remain there keeping the magic of your keyboard shortcuts working.
In Xcode 4 (4.2), is there a way to keep the Project Navigator view open and Debug Navigator view open as well. Must a user have one or the other, but not both? And the other navigators?
Apple seems to have decided that if you want to see the debug view, you don't want to see the files in your project. WTH? Am I getting this wrong? Did Apple Xcode UI guys even talk to developers before designing the UI for Xcode 4?
Sigh...
You can indeed have more navigators open at once, if you are prepared to have multiple windows open. I know it's not exactly what you're asking for, but for multiple display setups it's very handy. Xcode provides "behaviors" to help automate this process if you only want certain things showing at certain times.
For example, a common pattern that developers follow is to setup a behavior for "Run starts" that opens up a new window setup for debugging. Start by creating a new tab in your main Xcode window by pressing command-T, and double-click on the tab's title to rename is "Debug", or whatever you like. Then drag that window out (or leave it as a tab if you like), and customise the view as required - for example, for a deb window you might have the Debug area showing at the bottom (or even covering the whole editor view), and remove the toolbar at the top by right clicking and selecting "Hide Toolbar".
Next, go to "Xcode > Behaviors > Edit Behaviors..." and choose "Run starts" in the left panel. Check the box for "Show tab" and enter the name of your newly created tab. You can also ask that tab to automatically show the Debug Navigator, and show the debugger with variables and/or console view. If you like, you can then choose "Run completes" and show the original "tab" (window), which I've setup to be called "Coding", and show the required navigator (in my case, Project Navigator).
On successfully running, Xcode will now open up your new window (or bring it to the front if it's already open) with all the settings you left it with. On stopping, your main editor will be brought back to the front.
There are loads of useful behaviors, so I would really recommend looking through them and taking the time to setup Xcode to suit your style as best as possible. All software dictates to the user how to go about doing things, and the developers can never please everybody when they decide to change the UI. The best anybody can hope to achieve is to customise the interface as best as they can to fit their style of working. If it's still an issue for you, you can either adapt to it, or, if possible, move to something else.
I'm not a fan of every new interface feature in Xcode, but I've "made it mine" with some customisations and I can still be very productive. That being said there are a lot of things that I do really like about it, and for that I can forgive it for some of the less friendly features - after all, you can't please every user.
I'd like to know if it ever makes sense to provide some functionality in a piece of software that is only available to the user through a context (right click) menu. It seems that in most software I've worked with the right click menu is always used as a quick way to get to features that are otherwise available from other buttons or menus.
Below is a screen shot of the UI I'm developing. The tree view on the right shows the user's library of catalogs. Users can create new catalogs, or add and remove existing catalogs to and from their library. Catalogs in their library can then be opened or closed, or set to read-only.
The screen shot shows the context menu I've created for the browser. Some commands can be executed independently from any specific catalog (New, Add). Yet the other commands must be applied to a specifically selected catalog (Close, Open, Remove, ReadOnly, Refresh, Clean UP, Rename).
Currently the "Catalog" menu at the top of the window looks identical to this context menu. Yet I think this may be confusing to the users as the tree view which shows the currently selected catalog may not always be visible. The user may have switched to the Search or Filters tab, or the left pane may be hidden entirely.
However, I'm hesitant to change the UI so that the commands that depends on a specifically selected catalog are only available through the context menu.
The Windows User Experience Interaction Guidelines for Windows 7 and Windows Vista states (pg233):
“Don’t make commands only available through context menus. Like shortcut keys, context menus are alternative means of performing commands and choosing options.”
The Apple Human Interface Guidelines states (pg189):
“Always ensure that contextual menu items are also available as [pulldown] menu commands. A contextual menu is hidden by default and a user might not know it exists, so it should never be the only way to access a command.”
In your case, opening and closing the catalogue appears already available through the +/- buttons in the tree itself, so you’re already consistent with the Windows guidelines, if not the Apple guidelines. IMO, the only reason to put them on the context menu at all is if they're the default (double-click) action (which they're not right now). Rename may also already be available by directly selecting the name of a selected catalog, but you may want a pulldown menu item for that any way since that may be no more discoverable than the context menu. The rest of the commands probably belong on a pulldown menu in addition to the context menu.
As far as the Catalog pulldown menu being redundant with the Catalog context menu, you may want to consider organizing your pulldown menus by type of action, rather than class of object, in order to provide an alternative organization. As you’ve realized, context menus already organize commands by class of object. In addition to providing an alternative organization that some of you users may find more intuitive, this may simplify your menubar. For example, rather than a Catalog and Family menus, you can have a single Edit menu with Add, Delete, Rename, Copy, etc. where these commands apply to whatever is selected, whether it be a catalog, folder, or family. If they don't apply to the current selection, they're disabled, but if it makes any sense in your app, make them apply.
BTW, what’s the difference between Add Catalog and New Catalog?
In general, it's a bad idea to have menu items accessible only through a contextual menu. Many users may not think to right click on an item to find out what actions can be performed on an item.
From your description, it sounds like it would make sense to have a 'Catalog' menu that disables menu options that are not currently relevant. For example, if no catalog is open, the 'Close' menu item would be greyed out. Similarly, the 'Open', 'Remove', 'Refresh', etc. items would be greyed out if no catalog is selected.
I suppose this depends on your user base, and who you're targetting your software at. Personally I wouldn't expect the user to be able to deduce what functionality is available when it is essentially "hidden" until they right-click on the correct item.
If it were me, I'd have a toolbar shown with the functionality exposed on there. By default the buttons would be disabled, and clicking on a node would enable the appropriate buttons based on the context. You could have this in addition to your current right-click options.
As a rule, I've always treated right-click menus as a redundant (i.e not necessary for operation of the software) shortcut to functionality for "power users".
I would leave the menu item out because the user doesn't have a way to see what catalog they are modifying if the treeview is hidden which can create problems if they think a different one is being shown.
Though, the accessible solution would be to trigger it with the keyboard also.
Yes. One key feature of UI is "discoverability": can the user find the function?
If you think that having a top-level menu doesn't make sense, based on the context, then you could have a menu button (scroll down) labelled (e.g.) "Actions" at the top of the pane.
I'm writing a COM add-in for Word, Excel and PowerPoint. This add-in has some user-configurable settings (about a page full of them actually... or perhaps even more than a single page). What is the standard way of presenting these to the user? Through a custom page under Tools->Options? (how?) Under a custom button on a custom toolbar? A specific menu for the add-in?
If it were Outlook, I would add a custom property page. I was pretty confident I could easily google something similar for the other office application, but I'm obviously not searching for the right terms. Hints to improve my searching are also very welcome!
Update:
I just realized one can figure from your question you are targeting Office versions up to and including 2003 right now, as for example the tools menu is gone in 2007.
You might still find an answer regarding your question by looking at the starting point for the mentioned migration from 2003 to 2007: access to the settings for the sample 2003 add-in is located in an add-in specific sub menu of the tools menu, as shown in Figure 7.
For current and future versions of Office (i.e. 2007 and up) your first stop regarding user interface questions should be the Office Fluent User Interface Developer Portal, specifically you'll find there the '2007 Office System Document: UI Style Guide for Solutions and Add Ins'.
Its probably worth pointing out that this guide is not on par with the Windows User Experience Interaction Guidelines (UX Guide) by a huge margin, which is unfortunate given the almost traditional friendly competition between the Office team and other Microsoft departments in setting the next de facto UI standard for 3rd party developers.
Still one can figure out initial directions from there, for example the recommendation regarding scenarios for custom task panes as suggested by Gary clearly is at odds with your need to offer user settings, citation:
Create a custom task pane if…
Your solution needs to present data
about a document that is required to
be visible, in a non-modal fashion,
use a custom task pane. [...]
You can find a good starting point regarding your question in section Simple Migration, where the migration of a simple 2003 add-in to the current 2007 release is explored step by step from a UI design perspective; not surprisingly this add-in features settings too, hence your requirements are addressed, albeit only on the side.
Reproducing this section here would be a bit lengthy plus I'm not sure whether it would be legal to reproduce the inline images used there, just look for Figure 9 in particular to get you started.
You can take it further from there depending on your particular scenario, good luck!
I'm pretty sure you cannot add a tab to Word, Excel and PowerPoint's Tools | Options dialog. I know you cannot do that in Word before 2007 at least.
I would recommend adding a menu item for your add-in somewhere, probably under the Tools menu. I assume your add-in does not already have any other menu items? I would put it in a menu item rather than a toolbar button, since most users don't need to change "settings" all the time, so they do need to look at the button on the toolbar all the time. My screen shots here show the menu in Word with Options at the bottom, though not the actual options dialog: http://www.amosfivesix.com/timken-business-stationery
If you're worried about people finding your menu item tucked away on the Tools menu, you can have a window pop-up the first time the app is started after your add-in is installed. Have it show a picture of where the menu item is, or just explain how to get there. Lots of apps have things like that the first time they run. One of my larger Outlook add-ins does have it's own menu on the menu bar (so it's fairly easy to find) but I also have a first run window that explains what/where it is. You can see an example of that here: http://www.amosfivesix.com/timken-electronic-business-card
Gary McGill's idea for a task pane might be good as well. I don't have any experience with task panes. I'm not sure it would be appropriate for "application settings" since taks panes are more like modeless dialogs that you work with while also working with the document content. Changing your add-in's settings probably doesn't work that way.
I don't know if there is a standard way. I have only created VBA add-ins, and I do not believe it is possible to add custom pages under Tools | Options.
In an Excel Add-In I created, I put a 'Settings...' button on the Add-Ins toolbar (the Add-In created a custom toolbar during the _AddInInstall event).
But this approach of course means your add-in must have a custom toolbar (or menu).
I did a quick check on an Office installation I have access to, that has a few Add-Ins:
The Adobe PDFmaker add-in has its own top-level menu, as well as a toolbar. The menu has a 'Change conversion settings' menu item
A custom add-in (eye-share, don't know what it is) also has its own top-level menu. The menu has a 'Settings...' menu item.
Hummingbird (some sort of document management system) has menu items all over the place, but no settings dialog. The installation program probably sets the necessary config values in the registry.
So my conclusion is:
You cannot add a custom page under Tools | Options (I guess Adobe would have done this if possible).
If your add-in has a custom menu or toolbar, add a 'Settings...' button or menu item (don't know if there is a standard icon for this)
If your add-in does not have a custom menu or toolbar, I would probably add a single menu item under Tools.
If you don't want to clutter the Excel interface, you could have an external program (created in .NET or whatever) installed on the Start Menu that updates the registry. This of course requires that all relevant settings can be represented as registry values, and are to be persisted. It also means that the Add-in should always look to the registry for settings values when performing operations - not read the setting at startup and cache it in a variable.