Sudden pop-up windows sometimes process in-progress keyboard or UI activity which results in unintended results.

I once was given the task of creating an app to pop-up to warn user about something (that was the requirement given to me). I did not want to give anything focus out of fear that active typing might perform some unintended action. I could not find a way to achieve "no focus" in the GUI toolkit, so I just made a grey input box with a grey font on a grey background with no borders, and gave it first focus. The grey was the same color as the background.

Thus, when the window popped up, any typing would just end up in a dummy invisible input box. It was as if nothing had focus (although the cursor still flashed there.) One would have to explicitly select something to perform any activity.

However, it would still not work very well if somebody was tabbing and typing right before the popup. But, it was better than what most pop-ups currently do: process any current input as if meant for the sudden popup window.

----
I cannot help but think what it is the user is typing and why. However if one is typing, it only makes sense to make it visible, even if it is going to a dummy box. There are other ways one can handle keystrokes than to send them to an invisible useless box. 

What is a better solution to the stated problem?

''XOSD and Mac-style global floating windows are better IMO. They're just drawn onscreen and exist outside of any input or task-switching mechanism - any keystrokes continue to go to the frontmost window. Obviously depends on toolkit support for this but there's always a way, maybe using OpenGL or some game API.''
----
NEVER pop up a window in any GUI ever, unless it's modal or a fatal error. It rips focus and interrupts flow. You should place a warning on the same screen, make it flashing/bold/red or something. You could spawn an asynch thread that loads a modeless window into an area they aren't typing in, but it would be very annoying and intrusive.

''I'm not sure it's possible to make such intuitive unless there's a lot of white space available. Some random widget starts glowing or what-not, how does the user know what to do?"
---------

Avoid '''greying out''' options. It's often better to display a message about a feature not being available and why it's not available and how to make it available. But greying out without explanation is frustrating. At least have a rollover that explains why it's grey if you really must grey.

''Alternatively, it's very annoying to accidentally select a non-greyed out, unavailable option and have to dismiss (for the 1000th time) the message about why the thing you didn't mean to do can't be done.''

I agree that such should be "marked" somehow to indicate it's not active, but to not tell the user why is rude and frustrating. How about greying it out, but have an icon next to it, maybe a lower-case italic "i" meaning "information". One clicks on the "i" to get an explanation. Deal?
----
CategoryUserInterface CategoryTips