locked
Guidance for Settings flyout where switching briefly to another app is needed? RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Here's my scenario. A Settings flyout needs to display a button flyout. The button flyout shows two input fields (account name/account key) and a save button.

    The design issue I'm struggling with is that both the account name (and especially) the account key are best pasted in rather than typed in. However, when the user pastes in the account name, then alt-tabs to notepad (or wherever) and alt-tabs back - the Settings flyout has been dismissed.

    The best I have now is to save what they have put in so far, but having to maneuver back to the Settings flyout and then the button flyout is really a bad experience.

    I've tried a few designs.  This one would work great - if I could only force the flyouts to 'stick' for this particular scenario.

    Suggestions/thoughts?

    Thanks in advance!

    Sunday, October 20, 2013 9:14 AM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    You want to make sure that optimising for this case doesn't interfere with the common case. Saving what they have is definitely a good idea and should be default behavior. I'd consider getting rid of the save button and save automatically.

    You could implement your own light dismiss behavior so that the fly out stays open until the user taps or tabs within your app, but that could confuse users who expect the flouts to dismiss when they left that context. Details would depend on the language you are writing in.

    --Rob

    Sunday, October 20, 2013 3:39 PM
    Moderator