I have a question about my Mac program's preferences window. I have an application with a CoreData-based back end. My program includes a feature that allows users to switch out the database for a different one. I do not expect users to do this very often—perhaps once or twice a year.
Now, many of the options that users can tweak are stored in the database. These options need to be configured once every time that a new database is used, because they are specific to the database itself.
The Apple Human Interface Guidelines on Preferences state this:
As much as possible, ensure that users rarely need to reset
preferences. Ideally, preferences include settings that users might
want to change only once. If there are settings users might want to
change every time they open your app, or every time they perform a
certain task, don’t put these settings in preferences. Instead, you
could use a menu item or a control in a panel to gives user modeless
access to these settings.
My question is this: Are my database-level settings valid candidates for the preferences window? Does "once or twice a year" count as "rarely"? If not, are there any downsides to creating a second panel (with many panes that are controlled by an NSToolbar) that looks just like a preferences panel but is accessed from a different menu item ("Database Preferences" for example)?
I see database-level settings all the time under Preferences in various apps (1Password and MacJournal come to mind). Thus, Preferences often contains both database-level settings and "actual" preferences that go in a plist file. The former (the data-base level settings) is absolutely crucial, being the actual data. The latter (the plist file) isn't as important and losing this data shouldn't cause too much harm, as it's just simple settings the user can easily get back to manually.
On the other hand, I see nothing wrong with separating the two, especially if your app is a multi-window (document-based) app that can have many databases open at once.
But I do think it's simplest to just put it all into the Preferences. That's what you probably should do, unless you have a good reason to do otherwise.
To answer some of your questions directly:
Are my database-level settings valid candidates for the preferences window?
— Yeah, I think they are. And many apps (such as 1Password and MacJournal) do this too.
Does "once or twice a year" count as "rarely"?
— Yeah.
Are there any downsides to creating a second panel?
— If you have a good reason to separate the two, I see nothing wrong with it.
Just my two cents.
Related
Background
We're looking to improve the performance of Dynamics AX 2012 by disabling preview panes and factboxes for all users.
However; we don't want to remove useful features; so want to allow users to re-enable those items which they use (i.e. therefore can't disable through the client performance options screen).
We could ask users to go through and manually disable/hide these options, but this would be a lot of work for them, would be something they'd be unlikely to do; whereas re-enabling anything they explicitly need would be less effort and more likely to be done.
Question
Where are user preferences concerning FactBoxes and preview panes stored?
Is there a simple way to update these en-masse (e.g. through SQL, X++, or some other means)?
If it's not simple to update these, is there any way to report on who has what enabled; i.e. so we can see which users have which options to help identify those we'd need to chase if asking them to disable these options for themselves?
I often have Safari open while working on a project in Xcode, looking up stuff on Stack Overflow and the like. A few times, I've searched something in to the web address/search engine field of Safari, and a word or two from what I typed in and it will be entered into the Search Navigator in Xcode, even though I didn't type it in there. It doesn't do it every time.
EDIT: Text entered in through the Search Navigator can pop up in Safari too.
This doesn't cause any problems, but the words it picks don't seem to have any relevance, and I'm curious as to why this oddity is happening.
I'm running Xcode 4.6.3, Safari 6.0.3, and Mac OS X 10.8.4
Is this a glitch? A half-baked feature?
What you are seeing is the OS X Global Find Pasteboard in action. Anywhere the private class NSFindPanel is invoked (typically in conjunction with a text field) this global pasteboard will get invoked and provides a single, central location for 'find' metadata which includes the most recent query:
In addition to communicating search strings via the find pasteboard, the standard Find panel for NSTextView also communicates search option metadata, including case sensitivity and substring matching options. This metadata is stored in a property list as the NSFindPanelSearchOptionsPboardType value on the global find pasteboard. As such, third party applications may store additional keys in this property list to communicate additional metadata as desired to support the various search options common to many third-party applications' Find panels.
from Section "Find Panel Search Metadata" in the NSTextField documentation on developer.apple.com
I believe the design intent to be, if you've performed a search in one app, there is a reasonably high probability that you'll be doing the same search in another app, so the global find pasteboard acts as a syncing mechanism between Find fields on disparate apps. For those coming from other operating systems, this would appear to be very odd behavior where the find capabilities of an app are very much sandboxed to their own process -- the most recent search term is an app-specific search term, not this global shared space.
As far as replication is concerned, you can always trigger the reported behavior by coping text to the clipboard, then pasting it into a Find field. When you switch from application to application the global find pasteboard will update the find NSFindPanel. This is why you see it going both ways between Xcode and Safari -- as both use NSFindPanel, both reference the global find pasteboard and sync up when the next time they get focus.
Unfortunately, this is not a user-configurable kind of setting; all NSFindPanels have this behavior and there is not a System Preferences or defaults preference you can set to change the behavior. Consider filing an issue with Apple at bugreport.apple.com
We've got several web-based applications that are launched from our ERP system (SAP R/3 in this case, but since we're using ShellExec, I don't consider this a SAP issue). The problem is that we can either set the IE to "open every URL passed from the ERP system in a new window" or to "reuse any one of the existing IE windows" (same problem with tabs). Both settings are not acceptable for our users: one of the web applications is a rather bulky medical image viewer applet that wreaks havoc if invoked multiple times. The other option is a no-go either because this way opening the image browser for a patient automatically displaces the lab result display for the very same patient and vice versa.
I'd like to have some control over which window may or may not be reused. My idea would be a kind of "window tag" and a helper program that checks if a window with that tag exists - if it does, reuse it, if not create it. So basically
IELauncher SEARCH http://www.google.com
would open a new window and tag it as SEARCH.
IELauncher DEVEL http://stackoverflow.com
would open a second window, tagging it as DEVEL. Then
IELauncher SEARCH http://www.wikipedia.org
would replace the contents of the first (google) window only.
Is this possible at all? Do you have any pointers for me where to start? I don't even know what to look for...
I had to resort to some rather ugly methods - dynamically assembling a HTML page that uses JavaScript and window.open() to open and access a window by name, then close the page executing the JavaScript. Ugly, but at least this way you get the additional benefit of being able to control certain aspects of the browser window like switching of the menu bar, toolbar and location bar.
I am trying to silently apply very specific appearance settings for a single user with poor eyesight on an XP machine.
I can alter the settings by using the appearance tab of the display settings dialog and clicking apply/ok. Doing this works however the user cannot see well enough to change her settings back to how she likes them each time she logs on.
Just changing the registry keys does not make the desired changes until the user logs off and then on again. For reasons that would take too long to explain, I cannot simply get the user to log off and then on again. I need the settings to be applied immediately upon login.
So! I either need to force windows to apply the display settings, a process which seems to be associated with the 'Please Wait' dialog, screenshot included OR I need to programmatically change the appearance settings individually (which includes altering 'Advanced' font-size settings).
Many thanks.
Please Wait Example http://www.dur.ac.uk/alexander.holmes2/b/pleasewait.jpg
Does this user have his/her own windows User? (his/her own account on XP). It should keep settings for you if you have them as a separate user from whoever else likes the larger DPI. Just create a user.
By and large, modal interfaces suck big rocks. On the other hand, I can't think of a better way to handle File Open..., or Print... and this, I think, is because
they are occasional actions, infrequent and momentous, and
they are atomic in nature; you either finish specifying all your print options and go through with it, or you cancel the whole show.
Let's put together a little style-guide. Suggest any use-cases in which a dialog is the preferred presentation and why it is preferred. Can the dialog be non-modal? If it is, how do you mark transactional boundaries, since Cancel ceases to have a clear meaning. Do you use an Apply button, for example?
IMO, modal interfaces should only be used when you HAVE to deal with whatever the dialog is doing or asking before the application can continue. Any other time, if you're using a dialog, it should be non-modal.
When doing non-modal windows, you might want to ensure they are unique: you don't really want two identical toolboxes (in a graphical program for example) or two identical preferences dialog (I saw this in a product), which can be confusing at best.
On the other hand, I appreciate when a Search/Replace dialog is non-modal: I can go back to the document and cancel last change, skip elsewhere, etc.; without losing the current settings.
Somehow, modal dialogs tell the user to "stop everything else and finish what you are doing", which has its uses, as pointed out in Stephen Wrighton's answer.
In my experience, there are very few things that should ever be modal in a UI. One of the best examples of this, and probably one very familiar to the users of the site, is Eclipse. Although it has some modal dialogs, and I'm speaking only of the core IDE here, they largely fall into three categories: File operations, preference dialogs and parameter dialogs.
Preference dialogs, while modal by tradition, need not be modal either. All you have to do is look at the Mac OS preference model, where configuration changes take place immediately, with modal behaviour introduced only in cases where the change might be disruptive to work in progress.
In short, here's what I would say is a good summary of what should be modal. Exceptions to this set should be well-justified by the usage.
Parameter entry dialogs (example: refactoring wizards. anti-example: find dialogs)
File operations
Confirmation of an action that will take immediate disruptive effect
How about a user login window, you cannot (or should not) use the rest of an application until you've logged in, assuming security is necessary.
I think the distinction is that if there is anything at all that a user might be able to do in the application while the dialog is shown, then it should not be modal. This includes copy/paste actions. Personally I would prefer it if file/open and print dialogs weren't modal either. I think modal dialogs are a sign of weak design, a necessary evil to get code out the door quickly.