3

To put this question in context, this is for a (mouse-driven) ui-heavy game. During this game many popup windows will appear. They are mostly non-interactive, just displaying updates on various processes, and can be closed by users.

Some of these popups will "expire" quickly, and I want them to automatically close when this happens, after a delay of say 3-5 seconds, unless a user interrupts them (in which case the user can is free to read them until they decide to manually close the popup)

What would be the most intuitive way of communicating to a user that a dialog is about to close, and offer them a way to abort this process, while being understandable in just a few seconds?

I'm thinking maybe an animated progress bar (labeled "closing...") with a cancel button (or maybe it should say "pause"?) next to it. But this might be a bit big and clunky?

close progressbar

I had initially thought to show a circular loading indicator around the popups close widget, and when it completes full circle the popup would close. But realised this doesn't communicate to the user at all how to abort the countdown. In fact clicking the only thing animating (the close button) actually results in speeding up the process. This is the opposite of the interaction I am trying to offer to the user.

close widget

Do we have any examples in the wild of interfaces which do this?

What do you think is the most intuitive way of accomplishing this?

8
  • how big are the dialogs relative to the size of the screen? And how often do you think users will want to click to keep dialogs open rather than auto close them? Once every 2, 5, 10 or 100 times?
    – tohster
    Commented May 16, 2015 at 12:14
  • Additionally to tohster question I would like to know why would they like to CLOSE the pop up if they're auto closing in just 3-5 seconds? Could they interfere with their interaction? If you can provide a mockup showing what tohster ask about the proportions. Commented May 16, 2015 at 18:13
  • I actually really like the second approach with the circular loading indicator around the close icon, and I don't think it conveys the opposite interaction of what you want. It conveys that you can close it right away by clicking there. The affordance for preventing the closing of the dialog doesn't have to be coupled with the countdown. It can be somewhere else, for example a pin icon next to the close icon, or a block of text somewhere above the remainder of the text.
    – illuminaut
    Commented May 16, 2015 at 18:41
  • 1
    @tohster: They're usually about a fifth of the screen (horizontally and vertically). It's a cyberpunk themed game and they're part of the game background sim, so it's not always important that the user read them. Sometimes just glancing at them and knowing that x happened is enough. But occasionally users may want to pause and examine them before they close. Probably only the first few times they happen, and maybe once every 10 or 20 times when they're slightly special messages. My main concern is a window closing before a user has time to read them in full, or the user feeling rushed.
    – ProPuke
    Commented May 16, 2015 at 18:56
  • 1
    @rewobs: Read my reply to tohster above. I couldn't include your name in the comment cos stackexchange only lets you reply to one person at a time >.>
    – ProPuke
    Commented May 16, 2015 at 18:57

3 Answers 3

7

Gaming popups have some different constraints

  • For many games, notifications/notices are challenging to design because the user will be focused on the core game play:

enter image description here

  • So, designing notifications is difficult because you have to make sure the user sees the notification, but it cannot be so intrusive that it takes the user's focus away (in space or time) from the core game.

  • Using a circular or linear progress bar can be challenging for games because the user first has to visually process the rectangular notice, and then also process the progress widget within the rectangle....all while trying to keep playing the game.

    • The user also has to keep track of the widget-within-the-panel which is cognitively complex.

      enter image description here

  • Using text countdowns can also be tough because it actually takes quite a bit of cognitive load to process numbers in a countdown...i.e. it's hard for the user to track the digits while playing a game.


l33t design?

  • One approach that may help is a slow fading notice. The notice appears, and then fades away very slowly (a decelerating ease-out function will help here).

    slow fading notice

  • This requires the user only to see the notice, and then the fade-out period gives the user ample time to click on the notice or let it fade away.

  • Visually, this is cognitively easier for the user to process because he just has to see the notice once, then the fade-out is cognitively easier to track than a progress bar or a countdown digit.

  • You can figure out what interaction is best, e.g.:

    1. User clicks anywhere within the fading notice and it becomes opaque....with a X button to dismiss -- OR --
    2. Notice has a Cancel button which cancels the fade-out, and then a dismiss button to do the manual dismiss.

I prefer #1 for a number of reasons, but you can choose the interaction that best suits you.

3
  • 1
    I agree the slowly fading out notice is the best approach for this. Instead of a counter that you have to track the fading out can take just as long and it's intuitive to click on it to prevent it from fading out completely.
    – illuminaut
    Commented May 16, 2015 at 23:08
  • Spot on cheers. Displaying notices on the window were hard to spot, but the fade out seems to be mentally noticed and understood straight away. I've ended up easing out to just 30% opacity, then I play a rapid close animation on the window (with a simple countdown timer over the close widget). 30% ensures it never gets too hard to read, but the fadeout explains what's happening. When your eyes investigate the simple number countdown tells you how long you have left, and mousing over the notice aborts the autohide instantly, so it's very easy to reactively stop.
    – ProPuke
    Commented May 19, 2015 at 21:32
  • Later user testing may reveal more, but I'm very happy with this for now. Your points were spot on. Despite it being a gui-driven game and thus my thinking with an app mindset your points about peripheral vision and trouble mentally processing background notices were completely correct. Cheers for the help.
    – ProPuke
    Commented May 19, 2015 at 21:39
2

There are some variables that you could take into account here to express time:

  • "Shapes" getting smaller
  • Seconds (numbers) decreasing
  • Color

Maybe you don't need to use all that variables, but I made a mockup with all of them to get the idea.
BTW "wait" and "close" are the first words that came to my mind, but since I'm not a native English speaker, you should evaluate what would be the best word choice in your context. (you you also use keep + resume/ X / dismiss for example).

enter image description here

And after clicking wait (you have million ways of differentiating the "pinned" notifications if you want):

enter image description here

You should also switch the positions of the timer, text and button according to your application and how much attention you want to give to each part.

1

A simplified approach can be as follows

mockup

download bmml source – Wireframes created with Balsamiq Mockups

This would show the user how much time is there for the popup to close and also enable him to prevent it from closing as well. The close icon on the top right enables him to dismiss even before the timer runs out as well.

This said, I am concerned that 3-5 seconds might too short for people to react in time to be able to extend the time read it. Also quoting the section 508 accessiblity guidelines

When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

Hence if its critical information, consider a longer time to show it.

2
  • This is pretty close to what I was thinking with the progress bar. The only reason I went for a progress bar instead of a countdown, is it seemed to me to convey the information slightly easier. I am concerned about people reading the "popup closing in x seconds" notice and it not being immediately obvious before the 3-5 seconds expire. It seemed like a labelled progressbar might communicate this a little faster. I can of course just increase the time period. But I'd like to keep it quick if the information can be well communicated within that time.
    – ProPuke
    Commented May 16, 2015 at 5:21
  • 1
    I would disagree, a progress is bar is great from a loading perspective when users are anticipating something to happen but then in this case, information is being hidden and hence you need to inform users that they dont have much time left. Also progress bars are great visual indicators but they dont tell you exactly how much time is left.
    – Mervin
    Commented May 16, 2015 at 5:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.