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?
Related
I write some automation software. I want to be able to send a message to a particular control of an application. I can find an application, but I need HWND of the control. How can I tell my software to pick that edit over here or that button over there, for example? I inspected several controls with Spy++, but I found no unique persistent properties, see images below:
The only idea I have now is to check control position, but even this is not 100% reliable, since several controls on different tabs of a tab view may have the same position!
What else could I do? How do GUI automation test suits solve this task?
pywinauto automation framework is able to identify control by index like app.SomeDialog.ChildWindow(class_name='Button', ctrl_index=0).ClickInput() which is persistent for each concrete moment if test sequence is deterministic. Also it allows more complicated matching criteria: app.SomeDialog.ChildWindow(title='&Next', class_name='Button', parent=SomeViewContol, predicate_func=SomeFunc).ClickInput().
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.
I have a help file for my program and was asked to add a description of the menus in a toolbar as the user browses them. So I thought I could just use the beginning of the menu's description of the help but just cant find how to access the contents of it.
I saw WinHelp has a macro language, so I figured maybe through this, but I couldnt find any references on this around.
Anybody now some pointers or examples of hot to do this?
the winhelpcgi utility contains library code that can read .hlp files. The source is here: link
I haven't used it so I can't vouch for its usage.
First, your help system should have an Index on each topic that permits you to open help and have that topic appear (if not, then check out Help & Manual - it'll help you build more complete help files). However, this doesn't directly solve your problem since, as I understand it, you want this to pop up in a toolhelp Window.
Thus, you'll need to go under the surface and figure out how the Help system uses the key to pull the appropriate information. However, it is not a trivial undertaking (as far as I can tell) to directly access a specific, indexed chunk of text in a WinHelp file. You may find some information here that is of use. You might also want to browse the forums on the Help and Manual web site.
Here's a bigger question though: does it really make sense to pop up an entire help topic (even if short) when a user just hovers over a menu item or button? It doesn't to me and I spent years in a UI design group at Bell Labs. It is A) simply too much information and B) going to be visually distracting (and thus incredibly irritating) to experienced users. The accepted practice here is to pop up a toolhelp window with a very short (1-4 words) descriptor of the button ("Open" or "Open File").
If you want the help to be available for each menu item or button, I would suggest one of two alternatives.
First, consider having a "Help Cursor mode" where the cursor uses the help icon (an arrow with a question mark). The user accesses it via a Help button on the button bar. When in Help Cursor mode, a user click on any item will take them to the help topic for that item. I'm kind of lukewarm to this approach since it is modal but I've certainly seen it done.
Second, you might simply beef up your help system a bit. That is, create a topic in your Help system that features a screen shot of your application. On this screenshot, create hot spots for each menu item and/or button and permit the user to go to the appropriate topic by clicking on it. Done right, this gives the user a visual key to the topics they wish to learn about without interfering with the normal operation of your program.
Most importantly: before doing all of the work necessary to implement your current plan, be sure it is the right plan!
Modal dialogs are evil, but I keep reading "You should remove modal dialogs when possible"
When isn't it possible to remove modal dialogs? I mean, what are some truly modal tasks that force us to use evil modal dialogs?
The most common given example is the "Do you want to Save?" I think this is the problem of the concept of having the user hit Save instead of remembering that user input is sacred. If you just saved automatically with the ability to "undo" or have revisions, then you don't ever need ask the user if they want to save.
"Are you sure you want to delete?" Undelete
"Are you sure you want to quit?" Why would you ask that? Are you that vain?
Why do we ever need modal dialogs?
EDIT
Webs app don't count in my books, unless they write their own UI windowing system within the browser. Web apps don't have the same tools set as desktop apps.
EDIT 2
My question is slightly different than the one labeled as duplicate. I feel that there is no case that modal dialogs are the best solution. The referred question assumes there is such a case.
Duplicate of: When Is Modal UI acceptable?
Use Cases for Modal Dialogs
blocking the application flow until information required to continue is entered, as for example a password in a login process.
collecting application configuration options in a centralized dialog. In such cases, typically the changes are applied upon closing the dialog, and access to the application is disabled while the edits are being made.
warning that the effects of the current action are not reversible. This is a frequent interaction pattern for modal dialogs, but it is also criticised by usability experts as being ineffective for its intended use (protection against errors in destructive actions) and for which better alternatives exist.
(Source: Wikipedia)
When I use them
In instances where stopping them from doing something stupid is absolutely mandatory. My company has a web app where Users sometimes leave the page before finishing their work. We prompt them with a Modal (the standard onbeforeunload JavaScript function) if they haven't saved their work.
Otherwise, I don't use Modals if I can help it, I hate it when an app steals focus from what I'm doing.
Edit: We don't save their work automatically for them when they leave the page. We do at other times, but not when they leave the page, hence the Modal. I did write could that could go in and save their work when they left the page, but it wouldn't be a 'great' idea to implement it, especially if they accidentally deleted their work and didn't want it to automatically save.
The only thing more sacred than user input is any file I known about. You should never modify any file that an implementation detail unless I have told you to. Thus boxes like "do you want to save?" at exit are a must because I may want to not save.
Imagine an application which needs to open a dialog for some actions. Now imagine that these would be non-modal dialogs: while one dialog is open, you could change the selection or even worse - invoke a different command which itself opens another dialog. Now imagine the these dialogs would be modal: then you would have to close the dialog to proceed - you can't get in the state where the selection changes under a dialog or where two commands are waiting for input.
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.