# PLEASE get rid of the wonky "two click requirement" to change focus **URL:** \ **Category:** Bugs & Issues\ **Created:** [September 17, 2021, 8:28pm UTC](https://community.fibery.io/t/please-get-rid-of-the-wonky-two-click-requirement-to-change-focus/2037 "2021-09-17T20:28:25Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Matt\_Blais](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/matt_blais/32/1464_2.png) [@Matt\_Blais](https://community.fibery.io/u/Matt_Blais)\ **Post date:** [September 17, 2021, 8:28pm UTC](https://community.fibery.io/t/please-get-rid-of-the-wonky-two-click-requirement-to-change-focus/2037/1 "2021-09-17T20:28:25Z")
When certain subwindows/sidebars/dialogs are open, a single click anywhere else in the UI does **not** do the expected thing, which would be to open/view whatever you clicked on; Instead the first click just closes the current subwindow/dialog, and a SECOND click is required in the exact same place, to open the thing you clicked on. This leads to much UI weirdness, such as: After opening an entity view in the sidebar by Alt-clicking a reference-type cell in a Table View; now Alt-clicking a _different_ reference cell in the Table View does NOT open that entity in the Sidebar; it simply closes the Sidebar (even though the hover hint over the cell says “ALT + Click” will open it). But regular-clicking on a cell WILL close the sidebar AND execute the click. The same thing happens in the Apps and Templates page when a Type is currently being edited: clicking a different Type does not edit that type; it just closes the current entity’s definition in the right side of the screen. ---
**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\ **Post date:** [September 17, 2021, 9:40pm UTC](https://community.fibery.io/t/please-get-rid-of-the-wonky-two-click-requirement-to-change-focus/2037/2 "2021-09-17T21:40:03Z")
I understand the frustration here, but I think I also get why it works the way it does. Pop-up views are treated as “modals”, basically. So while the feature request makes sense, it might be more correct to say something like “make entity views non-modal” or something. I also think this will probably be affected, at least in some/many cases (e.g. entity views), by the forthcoming: > [@\[DONE\] Multi-panel context-preserving navigation](https://community.fibery.io/t/in-dev-multi-panel-context-preserving-navigation/2003): > > Problem It’s very hard to work with data in Fibery, since you have only single open entity/view in the main area. It leads to the following problems: Loss of context when you open entities in collections or references. You have to remember where you’ve been. High cognitive load for all side-actions. Main flow is interrupted by some sudden sub-flow and it’s hard to go back easily. Solution We’ll experiment with making multi-panel navigation a major UX pattern in Fibery. It will be easy to op… ---
**Author:** ![Matt\_Blais](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/matt_blais/32/1464_2.png) [@Matt\_Blais](https://community.fibery.io/u/Matt_Blais)\ **Post date:** [September 17, 2021, 10:04pm UTC](https://community.fibery.io/t/please-get-rid-of-the-wonky-two-click-requirement-to-change-focus/2037/3 "2021-09-17T22:04:22Z")
> [@Oshyan](#): > > make entity views non-modal I understand the modal dialog pattern. These Fibery “modals” generally do not adhere to the “_Explicit Save is required, or else closing it cancels all changes_” behavior, and their modal status doesn’t seem to serve any purpose. And sometimes they don’t behave like modals at all – in my above example, _regular_-clicking a Table View cell DOES close the sidebar AND execute the click (which is what I want, only with more consistency). Modals are a PITA if not actually required. I would much rather have them be active, independent windows/panes – and hopefully that’s where we’re headed with [Multi-panel context-preserving navigation](https://community.fibery.io/t/in-dev-multi-panel-context-preserving-navigation/2003). Either way, once you’ve accepted that clicking outside the thing dismisses it, it’s not a stretch to dismiss it and activate your click-target in a single operation. Personally I think the hit to usability (the double-takes of having to click twice) far outweighs the benefit of adhering to a standard modal pattern that that’s not serving any purpose. Innovators create new UI/UX patterns every day, and I’m glad they are, else we’d all be using Windows 3.1 UI.