I am setting up a simple 'boot menu' for my app, where the (experienced) user can check or uncheck various run options. The boot menu is a simple borderless form shown modally and with
Quit button
Continue button, as well as
boot options checkboxes
I display this boot option dialog as I am starting my app if the user is holding the F8 key - I've discovered that Windows does not use F8, so you can actually hold down F8 while clicking on a shortcut to my exe and my boot dialog opens. Herein lies the probem.
My form does not become the active application - rather the Explorer window hosting the shortcut that I clicked on does. If I click on my form (boot dialog) it gets the focus. How can I make my boot dialog form 'pull' Windows into focusing it?
In general you cannot take focus. From Raymond Chen's Old New Thing blog:
Foreground activation permission is like love: You can't steal it, it has to be given to you
...the window manager sees no reason for the first instance to have any right to take the foreground. There is no evidence that the first instance is coming to the foreground in response to some user action.
There are a variety of ways of addressing this problem. The easiest way is simply to...
You don't need to steal focus if you can just arrange for someone to give it to you
...outright stealing the focus is the wrong thing to do...
...Just because there's no good way to do something doesn't mean that you are automatically permitted to do it in a bad way.
The problem is that the user has been giving input to a program that is not yours. You're not entitled to have focus just cause you want it.
It may not be the answer you want, but it is the answer. And Microsoft has been working hard to thwart programs that try to steal focus. Any solution you come up with is breaking the rules, and might not work at any point in the future.
...Just because there's no good way to do something doesn't mean that you are automatically permitted to do it in a bad way.
Related
Is there like an option in SQL developer that confirms with the user if he/she really wants to close the window? I know this might sound silly but I always accidentally hit the close button probably because I'm working on dual screens, and when I click it then it'll close without any confirmation.
I can only see options upon closing on worksheets but not on the sql developer window
easiest workaround would be to make the two monitors appear to be not on the same height. on my window display settings this is what I did, this way if the mouse accidentally goes to the external screen, it will be far away from the close button of sql-developer
I am developing in PHP with Xdebug and for some reason every now and then the debug session stops working, so i click again the debug button but it gives me this error all the time "Web launch already running", so i have to go to Debug Perspective and click "Terminate and Relaunch".
Is there a way to make eclipse automatically terminate and relaunch or launch two sessions or don't show this popup, for 2 years this popup has been bugging me xD
As noted in response to questions like this one and this one, the best current solution appears to be binding "Terminate and Relaunch" to a keyboard shortcut.
Not automatic, but at least a lot less clicking around.
I have taken care of pesky popups in Eclipse with AutoHotkey script which have worked very well. I could create an AutoHotkey script which sends specific keystrokes automatically every time there is a specific pop-up.
So the flow I had in mind was as follows :
You click on the debug button -> The Error popup appears and as soon as that happens the AutoHotKey script kicks in and automatically does what you have to do manually.
If you think that might be worth looking into then we can talk more in a Chat session somewhere. I would need some information about the Pop up using the AU3_Spy.exe bundled with the AutoHotkey Installer.
Searching on Google, I found that many people have the same problem.
Bellow are some links that help you, I think:
https://aptanastudio.tenderapp.com/discussions/questions/123-definitive-installation-guide-for-php-debugging-on-linuxubuntu
A good article: http://www.latenightpc.com/blog/archives/2008/05/24/a-complete-lamp-development-environment-xampp-eclipse-pdt-and-xdebug
See this, too: http://www.eclipse.org/forums/index.php/m/57493/
Take a look here, too: Getting error in XDEBUG
So, read and try, read and try.
We are currently evaluating install4j and things are going pretty well, however I have a question about auto-update.
Currently I see options and documentation around 3 options for auto-update and the third one (no version check) seems
to be the closest to what we need. However it sounds as though it still prompts the user to actually start the download/install. Is there
any way to get around this? We are targeting our software as a service on many windows boxes in a server room, so there isn't a user
to click continue for that last step. I believe we can roll our own service to monitor for upgrades that will do a command line
install with an answers file to prevent prompting, but I'd love to know if I missed something that would allow me to utilize
install4j's auto-update.
When you go to Installer->Screens & Actions, click on the "Add" button and choose "Add application", you can choose from a number of pre-defined templates. However, they are just templates and after adding them you can change them completely.
If the updater should be automatic but still show a progress dialog, you can just set the "Default execution mode" property of the updater application to "Unattended mode with progress dialog". In that case, no screens will be shown at all.
I'm making an image editor (e.g. for drawing pictures and diagrams) for iPhone and Android mobile devices. This question would also apply to anything that involves editing documents e.g. spreadsheets, videos, text files.
When the app starts, the user sees all the documents they've created so far in a gallery and clicking a document opens up the editor. My saving options so far, which work as they do on desktop applications, are: "save" (which is good for saving incremental progress) and "save a copy" (which is good for saving a milestone in the editing phase). When the user exits the app, they see the usual "Save changes? Yes/no/cancel" dialog.
However, this approach doesn't seem great:
I've found it common in tests that users accidentally pick the wrong option when shown the "Save changes? Yes/no/cancel" dialog.
Explaining the difference between "save", and "save a copy" to causal users in particular is tricky and is something where misunderstandings will lead to data loss. I want an option like "save as" as well but this is probably the most confusing save option especially since you don't really want the user to specify a filename on a mobile device.
Are there any better interface models I could consider for handling the saving of complex documents on a mobile device?
Some ideas I've considered are:
When quitting the app, changes are always saved to a new file on exit without prompting. The user can then manually discard the original or the edited copy if they wish
and/or
When "save" is selected from a menu in the editor, the updated document is saved to a new file F and all future "save" actions will overwrite F. This lets the user save their progress as they go without having the option of destroying the original file by accident. The only issue with this is what to do if the user saves, makes some changes and then wants to leave the editor while discarding the changes since the previous save. The only ideas I can think of are to add a prompt when exiting or to add a "discard" changes menu option.
I'm looking for something that is flexible, easy to explain and prevents mistakes.
Edit: Due to the nature of my app (large images, destructive and slow operations), it is impractical for me to offer persistent undo (I know there is some discussion to be had here but it isn't practical here even if we just consider development time). This makes autosaving documents more troublesome. I'm aware this limits my options but I'm not expecting perfection.
When I'm in doubt how to handle such things I start some of the flagship apps and look how they do it.
Let's take Numbers for iPad as example.
If I edit a spreadsheet Numbers never asks me if I want to save, it just saves.
If I make changes I can undo them later because there is a Undo function.
And even if I force quit the app the undo option will be there the next time I launch it.
If I want I can duplicate my spreadsheet, but this option is hidden in the "My Spreadsheets" submenu. It's not visible when you create a spreadsheet.
So I would suggest to implement some undo functionality so you can save without user interaction.
I wonder how you ask the user to save when the application exits anyway. On iOS this should not be possible.
Btw, this is what the iOS Human Interface Guidelines say:
Ask People to Save Only When Necessary
People should have confidence that
their work is always preserved unless
they explicitly cancel or delete it.
If your application helps people
create and edit documents, make sure
that they do not have to take an
explicit save action. iOS apps should
take responsibility for saving
people’s input, both periodically and
when they open a different document or
quit the application.
If the main function of your
application is not content creation,
but you allow people to switch between
viewing information and editing it, it
can make sense to ask them to save
their changes. In this scenario, it
often works well to provide an Edit
button in the view that displays the
information. When people tap the Edit
button, you can replace it with a Save
button and add a Cancel button. The
transformation of the Edit button
helps remind people that they’re in an
editing mode and might need to save
changes, and the Cancel button gives
them the opportunity to exit without
saving their changes.
For iPad, save information that people
enter in a popover (unless they cancel
their work), because they might
dismiss the popover without meaning
to. For more guidelines specific to
using popovers, see “Popover (iPad
Only).”
Your app should automatically save without requiring an explicit action by the user. 99% of tne time this is what the user wants, so why put up an obstacle (a prompt) that inconveniences the user 99% of the time to protect tbem 1% of the time?
If you are really concerned about tnat ladt 1%, save N versions and provide a revert feature. If you had an interface for that which would show what was added or deleted in each version, even better. I bet if you do that and monitor how often it is used you'll be surprised at how rarely people actually use it.
I have the in my opinion odd request to close a wizard form as Done or OK if Enter was pressed on the keyboard even if the OK/DONE button is not focused.
In my opinion that would be a usability mistake. For example: In the wizard you may have multiple controls, buttons, check boxes, multiple line controls and they all have a different behavior on actions from the ENTER key. And don't forget the other buttons in the navigation of the wizard, what if they are focused?
Should these controls don't react on Enter like expected before? Should they do their actions but in other cases where Enter does no further action for the control it should close the form == inconsistent?
I think that is a typical request where the needs of one person would help him but confuse many other.
In my opinion Wizards are very special because they are not only made to make things easier but also very often focus on people with less experience with the functionality of an application. So I take every request serious and try to look into all arguments for and against the request.
Is my point of view to narrow? Are there some usability studies or guidelines especially for Wizards to backup my opinion or maybe proof me wrong?
Thank you very much!
Michael
Well, here's the thing: there are two kinds of users you have to take into account here.
First kind of users are the Baby Boomers and Gen Xers (e.g., people who have been using computers in the 70s/80s) who are accustomed to pressing Enter to move to the next field. These are the ones who learned how to use computers in terminals/consoles and enter means you're finished typing on that field and would move on to the next.
Second kind of users are those who were weaned on Windows. These people are used to pressing the Tab key to move to the next field. Pressing enter to them means they are done with the whole thing.
So which convention should you follow? That will depend on whether you're targetting the first or second type of users, the environment (Windows or Web?), and the OS.
If you're targetting Windows forms, it is much advisable to be consistent to the OS (e.g., letting people use Tab instead of Enter) for form entry. In the web, you're in a quandary, since Enter is trapped by the web browser as a submit event.
In the end the only useful advice I can offer is to try it out with your target customers and see whether they prefer Enter over Tab.
I think the key is to test. You can't really guess what your users will find comfortable, you have to watch them try it. Especially since there are multiple incompatible standards you could follow, you are just going to have to see if this change works for most users in your audience.
I would be of the same opinion, perhaps mention it to the client and let them use the final version in both modes. I guess you have to give them what they ask for when they are paying.
To me this also seems to be an odd request but as Paul says, if the client wants it, then the client gets it.
However from a usability/comprehension standpoint, I would make the border of the ok/done button much thicker then normal so that it stands out a bit and maybe indicate to people that it has special behaviour.
Also I would perhaps make a note in the dialog/wizard box that hitting enter will cause the wizard to close as if the OK/Done button had been pressed.
While the one user may know that hitting enter will close it, unless someone else is specifically told, they will not be expecting that behaviour.
I think you should have a finish page to facilitate this. If the user presses enter by mistake the worst is that he won't finish the wizard, only go to the next page (which may be the finish page). This is good for situations where nuclear bombs are controlled by said wizards.
On the finish page pressing enter would finish the wizard (and blow up Iraq, bring down a satellite, or erase Jimbob's farm).
If the user can re-run the wizard I don't think it would be disasterous if they accidentally finished it.
Remember, wizards should never take any action until they are finished, in case the user cancels or such. Confirmation dialog boxes on a finish are tedious and I will hunt you down if you use them, I think once the user has finished the wizard he is pretty sure about his intent.
Maybe the client has good reasons for it.
Imagine the following situation:
A screen with lots of optional fields that gets opened/closed a lot and where data accuracy is not really critical.
Think of a little program that pops up every half hour to ask you what you have been doing, for what client and maybe some notes so it can gather this info and generate your timesheet.
Being able to open up the screen, enter the info and close it all really quick and with as little hassle as possible is way more important than the accuracy of the data.
I can imagine lots of situations where being able to confirm the field without having focus can be usefull.
Is this request perhaps because the UAT that was undertaken on the wizard involved users that weren't aware that pressing ENTER will have the same effect as clicking the button?
If when the final page of the wizard is displayed, the 'Finish' button is already highlighted (as I would expect) that maybe it's a matter of giving the user some cue that they can also press ENTER at this point.
If you take Google for example, I seem to remember that if you tend to systematically type your search term in and then click the 'Search' button with the mouse, a message is displayed at the top of the search results that kindly hints to you that you can also just press ENTER. Obviously, this is not something that can easily be done in your case because this is the last page of the wizard, but maybe this is the sort of thing that your client is trying to get you to engineer around?
Educate your clients. Show them some documentation as why that suggestion might not be a good usability practice.
Some reputable website will work best, as clients will usually believe a third party before believing you. After all, to them you are probably just being lazy and don't want to work more.
If the client still doesn't concede, then just do what they want, and warn them that it is not the good thing to do.
Although in your case, the "good thing to do" seems a little on the gray area.
I would argue that you could possibly use this functionality to move forward through the wizard but ONLY if no other action had been taken on that page.
The moment a field is completed or a button clicked/highlighted or the cursor is moved from the default position, the Enter functionality should revert to that of the standard OS.
As others have said, clearly this would only work if those using the wizard were made aware of this as part of their application training, but it might prove useful for moving quickly through un-used pages of the wizard to get to where the user needs to be.
Doesn't matter. Choose and be consistant in all your applications