2

Just curious of your opinions on the following subject: User can call up a menu or a pop up window. Then he realizes that this is not what he or she wanted, so clicks outside the menu/window to close it. Now:

  • if the user clicks on a non-active part of the page (e.g. background) -> menu / pop up is closed and nothing happens.
  • if the user clicks on an active part of the page (e.g. link) -> menu / pop up is closed as expected and user is redirected to wherever the link leads (e.g. bootstrap apps work this way).

I personally find the navigation event distracting as I would expect that the menu/pop up will just close and I would still be on the same screen as before. After all I just want to close the menu / window I opened by mistake and not necessarily go somewhere else. But maybe I am missing something?

What's your take on this?

3

I would just have the div closed. I think most people would not even think about where they are clicking, as long as it is outside of the popup. It can confuse them a lot to suddenly end up on a different page, in my opinion.

So I think your take on this is correct.

  • If the pop up greys out the background then definitely! It's a little more unclear if the pop up is a menu similar in style to the windows right click context menu, because then the other behavior is standard for these context menus. On balance it is probably less annoying to the user to have to click a link twice than to have something happen that they didn't intend. – Franchesca Apr 15 '16 at 14:31
  • I agree, if the pop up greys out the background, than it is a no-brainer. But indeed, if it is a drop down (e.g. menu from the main bar) or a context menu, that changes things a little as they behave differently from regular pop ups. – Odie Apr 21 '16 at 7:19
  • I did not see the option for a menu. I just only read 'popup'. Not sure if this was there and I was not very awake, or if you added that later. True. a menu is definitely a different situation and in that case I agree that clicking another link could take them there. As long as its not a style or script error where the user intended to close on the open menu but end up elsewhere... Would still prefer the menu to just dissapear only, though. – LvS Apr 23 '16 at 4:18
0

In short, you're right

Most users just want to navigate one obvious step at a time. If you give them a menu that feels like it needs to be "closed," then they don't want to have any unnecessary actions bundled into their obvious prompt: "close". I think most would agree that your intuition is correct - allowing navigation simultaneous to closing a pop-up menu isn't expected or welcome, is rarely necessary, and poses unnecessary risk.

In long... it depends!

You can design totally awesome environments that restrict actions to one-at-a-time, and comparably awesome environments that allow multiple actions from a single input. But, the interface needs to be obvious and intuitive whether you've brought users to a "bundled action" or "singular action" space.

My understanding of the underlying construct that dictates how users expect their powers of navigation to work: Accepting clicks from objects ought to occur only in states where the antecedent behaviors of informed clicking are enabled and encouraged - that is, browsing. Zones of discouraged browsing (e.g. a grey dialog box, a minimized window, a not-current tab in your web browser) aren't actionable, almost ever. If browsing outside of a specific area is noticeably hindered (by significantly desaturating the page and obscuring it with a big ol' modal box on top), then users won't expect to be able to act on those un-browsable elements.

We don't form intentions and plans to interact with hard-to-see objects, especially when there are unobstructed, popped-up elements to deal with. When we create a clear hierarchy of "emphasized objects" and "de-emphasized objects," users expect (and plan!) their actions to apply to the forefront elements at least primarily, if not exclusively.

A good analogy here is navigating a DVD menu. Quite often, the first few moments of playing a DVD are "locked" from user input, because the UI really wants you to watch legal boilerplate, trailers, ads, introductory animations and the like. While these events unfold, there's an interactive menu obscured, waiting for user input. We will eventually work with that menu to watch some content, but we won't form a clear concept of action until we are actually looking at the menu. It might be easy to guess where the buttons will be, and what they'll do, but it can't be planned for, navigated, or acted upon until it's sitting in front of us.

Imagine breaking this convention. For some budget or bootleg DVD UI, user input is accepted even while playing the "locked" welcome reel. Once the menu emerges, all the buttons you might've been un/intentionally pressing for whatever reason (to skip past the trailers, to preemptively Play the disc, to wipe off some pizza residue from your remote), all the actions that didn't have meaning yet, suddenly were acted upon by the system -- Mayhem!

It's a silly and overbearing analogy, but it makes the underlying UX philosophy clear - we expect to have power to interact with only that which we can see. If something is obscured or hidden, we don't form plans about it, and any actions we take shouldn't warrant response from hidden elements.

Doing "click + navigate" well

This points to the other side of the coin - if you do want to enable actions on elements outside of popped up boxes and menus, then make it clear that users are welcome to form that plan of action. Don't obscure or significantly change elements that still avail themselves to input. Let your users form plans about interactive stuff, and keep them from forming plans about non-interactive stuff.

A great example of this is on the responsive http://stackexchange.com/sites menu. When an object is clicked, the neighboring panels shuffle to make room for the expanded divs. Nothing else changes about the appearance of the page to suggest it is discouraging browsing behavior. Nothing pops up to obscure and de-emphasize anything else. It's clear that actions are multiply powerful, and allows clicks that just "exit" as well as clicks that connote "exit+navigate". The rest of the page remain as browsable as ever, with the elements hover-responsive and clickable as before.

  • Thanks for the answer... The "sites" page you mention works well indeed. It is a little too modern though for the traditional GUIs we are doing ATM. But I'd love to see something similar materialize within our apps one day :) – Odie Apr 21 '16 at 7:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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