The new feature where closing an input window redirects input to the command-line caused a bunch of problems for me today.
One of my guides kept closing windows in the conferencing system, thinking he had cancelled his entry, only to have the next the he typed (".west" on several occasions) create new conferences in the system.
He did this about four times in a row.
Could we revise this so there is a minimize button and a close button? Minimize would do the current behavior, close would return a null value for the request...
ID:138675
 Mar 26 2000, 3:46 pm
|
|
What if there was nothing in the list presented, so you were left with a popup that couldn't be removed, and anything you typed in would be invalid?
| |
How about this compromise? The close button can parse whatever is currently entered into the popup (null if nothing). If this is invalid, then the system can reprompt, this time on the command line. Hmm...Windows users only have one UI item that is truly consistent between all apps: the close buttons shuts down what you are doing. I think it will be an ongoing source of confusion to have a close button that doesn't actually terminate the transaction. Re-prompting on the command-line seems pretty subtle and likely to go unnoticed. The guide who ran into this today was doing pretty destructive things as a result...and there was no way for me to catch the problem. I know there isn't an easy solution here...but maybe the cleanest would be to make a policy that all prompt() calls have to assume null as a possible answer... | |
On 3/27/00 1:32 am Deadron wrote:
I know there isn't an easy solution here...but maybe the cleanest would be to make a policy that all prompt() calls have to assume null as a possible answer... Well, that presents some difficulties with cases like: prompt() in list("A","B") or prompt() as num and so on. There are situations when you want to _force_ the person to enter some value. We could automatically require a default for prompt, but then designers would have to indicate that in the help and this would result in a lot more text per prompt. I think that perhaps the best solution is to (once again) remove the close box but allow the ESC key to jump back to the command line. I hope Zilal won't get too upset about this (although I suspect that she only wanted the ability to get out of "infinite" prompts, so this should suffice)! What do you all think? | |
On 3/26/00 11:47 pm Spuzzum wrote:
What if there was nothing in the list presented, so you were left with a popup that couldn't be removed, and anything you typed in would be invalid? That would suck. So as designers, let it never happen! Anyway, this kind of "infinite prompting" is the whole reason Zilal proposed the close option in the first place. Apparently enough CTRL-ALT-DELeting can sour one's tastes for coding. That said, I have just removed the close box and put in the ESC option. I think it will do for now. I am also taking your suggestion to ensure that null prompts automatically respond with null. | |
I think that perhaps the best solution is to (once again) remove the close box but allow the ESC key to jump back to the command line. I hope Zilal won't get too upset about this (although I suspect that she only wanted the ability to get out of "infinite" prompts, so this should suffice)! ESC makes a lot more sense to me for this functionality. | |
I think that perhaps the best solution is to (once again) remove the close box but allow the ESC key to jump back to the command line. I hope Zilal won't get too upset about this (although I suspect that she only wanted the ability to get out of "infinite" prompts, so this should suffice)! Yeah, I have some systems where <null> isn't a possible answer and putting in any answer will make the next popup come up until you're done. Since you can't access the Dream Seeker menus when you have a popup window out, people were stuck with this window popping up annoyingly, blocking part of the screen, until they were done. I wanted something that would prevent that from happening. Maybe if you just had a button below that says "Remove Popup Window," which would get rid of the window, turn off "popup prompt for user queries" and still look for the prompt input in the command line. Having ESC act to close it, as you mentioned, would be okay too... maybe with a "Hit ESC to close popup window and input on the command line" written on the window? Z | |
The problem with this idea is that not all prompts can accept a null value, so this could be just as confusing. This logic was the reason that initially there was no close button at all.
How about this compromise? The close button can parse whatever is currently entered into the popup (null if nothing). If this is invalid, then the system can reprompt, this time on the command line.