This is confusing to explain in words, but the panel setting I describe below is very unintuitive to me. Just a small navigation improvement idea.
Issue:
If I am looking at an entity, or to-many view, expanded with a collapsed panel on the left
Then click on an item to open up its page on the right
Then close that item on the right
The remaining 2 panels are now 50/50 split-screen open with the previously left-most collapsed panel and the previously full page expanded panel
It’s a small thing, but in my opinion it makes Fibery appear difficult to navigate - especially when I am showing Fibery to someone in my company as a possible solution. I then have to re-expand the right panel to full screen again. So if I’m on a full screen to-many view and I want to open/close/open/close multiple items on that view, it’s a hassle. Ideally, Fibery should remember if I previously had a panel in expanded mode, then when everything on the right is closed it goes back to expanded, regardless if there are items on the left collapsed. Especially with to-many views. I’m curious if this bothers anyone else or if this is just me.
Commenting again just to highlight this and see if anyone has a counter argument to why the current design is better. Genuinely curious if there’s something I’m not seeing.
I’ve had 3 people in my company complain about this. For 2 of them I’ve recommended they switch to one panel navigation because I don’t want little navigation hiccups to scare them away from using the system.
I was just about to create a request for this and stumbled upon this topic!
As of this week’s release, Fibery now remembers the visual state (collapsed/expanded) of the fields column per user, per entity which was one of the two most annoying and confusing UX quirks that was driving our team crazy. Thanks for finally improving this!
The second and arguably even more annoying thing is what other people here have already mentioned. If 3 or more entities are open and the screen is split 50/50, Fibery will inexplicably auto expand the collapsed entity to the left if the entity to the right is closed when it should just make the entity that was not closed full width.
WHYYYYYYYYY DOES IT DO THIS!? I get complaints about it daily from our team.
aBC (A 0%, B 50%, C 50%)
--X (User closes C)
AB (A 50% / B 50%)
Expectation:
aBC (A 0%, B 50%, C 50%)
--X (User closes C)
aB (A 0%, B 100%)
The same applies to the other direction as well.
Current:
ABc (A 50%, B 50%, C 0%)
X-- (User closes A)
BC (B 50% / C 50%)
Expectation:
ABc (A 50%, B 50%, C 0%)
X-- (User closes A)
Bc (B 100% / C 0%)
Ultimately, Fibery should not automatically expand something that was previously collapsed. The user should have full control over the expand/collapse behavior.
when
AA (A 100%)
and
(user opens B)
then
AB (A 50% / B 50%)
when
AB (A 50% / B 50%)
and
(user expands B)
then
aBB (B 100%)
when
aBB (A 0%, B 100%)
and
(user opens C)
then
aBC (A 0% / B 50% / C 50%)
when
aBC (A 0% / B 50% / C 50%)
and
(user closes C)
then
aBB (A 0% / B 100%)
The key for me is to never expand something that is collapsed, UNLESS THE USER EXPLICITLY SAYS SO. Otherwise there’s a disorienting “why am I now looking at this thing I didn’t want to” feeling that happens.
I don’t find it boring! It’s the little things like this that really add polish and can dramatically help productivity.
Ok, with the last use case we are on the same page
This is not how it works right now but we are looking to tweak the behavior.
Now keeping the principle in mind let’s go back to this one:
So the result should depend on whether it was the user who initiated a to be collapsed. If we automatically collapse a to clear space for C it only seems logical to me to automatically bring a back when C is closed back.
I don’t agree, because a user closing C does not explicitly mean the user wants to see A again, it just means they don’t want to see C anymore. B was already open at 50% so you can assume the user still wants to see B and therefore I would expand it to 100%. The only situation where I think A should automatically expand again is if C and B are both closed, because you need to have at least one entity/database open at all times, right?
This is not what we’ve seen so far during our UX tests. We’ve received a few complaints and noticed confusion about the aBB → aBC → AB case but not the AB → aBC → AB case.
Would be curious to hear from other folks in this thread if they haven’t unsubscribed yet
And I’ll look closely for a case like that during our next tests and customer calls. Thanks for sticking with me!
I think the root of this confusion and/or difference of opinion is that Fibery and/or users are trying to combine two (or more) related but different functions that are common in various similar tools. There is “sliding panes”, which is a more automated “collapse based on space available and length of navigation away from item” approach, which is kind of a hybrid of panels and a Breadcrumb Navigation. And then there is true “Panel” functionality, where you can open a note/file explicitly in one or more additional panels, which can be collapsed/expanded at will, but the collapse/expand is almost always initiated by the user rather than an automated process based on some aspect of navigation. Likewise the “open in panel” function is optional and not necessarily automatic with every click. Additional functions like “Pin Panel” or “Pin Current State” (collapsed/expanded) add to and modify all that.
Fibery is trying to create a clever, automated hybrid of those that provides the benefits of both with less explicit user control, options, etc. It is inevitable that it won’t satisfy all preferences. In particular this division between auto-expand based on navigation “depth” and “I never want something to expand automatically” (which is very opposed to the “sliding panes” approach and unintuitive for anyone used to that).
These may not be perfect examples, but hopefully they illustrate that there are some very different sets of expectations that come into play in user experience here.
That said, while I find the current Fibery approach to be a pretty decent hybrid and largely intuitive, it doesn’t allow some things I would want in some cases. Or it makes them more difficult to achieve, for example involving an awkward series of navigation steps to arrive at the two panels I want to have side-by-side, along with a desired collapsed panel to switch back to quickly, etc. In general I think the only solution to this is a mode for full panel control/independence and making things like “open in left panel/right panel” always explicit (maybe with hot keys), collapse/expand always explicit, etc. It would lose some of the elegance of the current approach but ultimately be more powerful I think. That said I don’t think it’s necessarily a better approach overall.
I know you paint those as two different cases, but they’re really not.
The only case is that “a” is collapsed and should remain that way until the user expands it.
It would be very weird to expect the use to have to close “a” before closing “C” if they didn’t want to see “a” show up as 50% again.
You’re definitely right here.
I think of entities as “rooms” that have data in them and the columns are independent side by side “doors” that let you access the rooms. A minimum of one door always needs to be open, and a maximum of two doors can ever be open.
So in the scenario we’re talking about here, where B and C are open:
and then Door C gets closed/deleted so there’s only 2 doors remaining, it’s very strange behavior for Door A to magically open by itself, just because Door C closed, right?
Not intrinsically, no! It’s strange if you view it as doors that you open and close, sure. But that’s not fully the intent. As I outlined above, it is trying to combine the utility of “open a page in one of two panes” and that of the sort of “extended breadcrumb navigation” metaphor of sliding panes navigation. In the former, what you’re saying more or less makes sense. But in the latter, as a navigation method, essentially like a visualization of “browser history” in some sense, then it does not. And since this feature in Fibery is a hybrid of the two, confusion is unsurprising. It depends on how much you want one type of functionality vs. the other, and whether doing a good enough job balancing between them to provide enough of the benefits of each for the average person, without too much confusion.
Personally I think it is a difficult - if not impossible - challenge to combine these two things in a way that is always intuitive to everyone. While it adds complexity, I am generally in favor of avoiding these fiddly “guess user intent” or “thread the needle” approaches where you try to make a good compromise solution between two very strongly beneficial separate functions. I prefer instead making things more explicit and separated. Of course this adds to dev burden to some degree. An example of a potential solution would be an explicit “lock” toggle for each panel, visible in any state. If collapsed, then locking it would keep it collapsed. Etc. Another, more complex but intriguing option would be the addition of Tabs within Fibery itself. Obsidian, by the way, combines Panes and Tabs in a very powerful and sophisticated way, but it can also be confusing to some, I imagine.
Only adding in an additional comment because you requested it. I agree 100% with everything @interr0bangr has said. He has phrased this perfectly in my opinion. If something is collapsed, do not open it again unless there is nothing else open to the right. It’s jolting. To me this would be the most intuitive and I believe this would solve all of the complaints I’ve had about navigation from various coworkers.
I think people’s intuition varies a lot based on previous experience with software.
Personally, I had used Binders from generism.com where the model is as @Oshyan described:
so for me, every panel to the right is ‘exploration’, whereas moving to the left is ‘retreating’.
With this mental model, it makes sense that closing C is a step backwards, so allows you to see more from the past.
I can say that when multi panel navigation was introduced, there were similar internal discussions about how it should work, and unsurprisingly there was not universal agreement.
Overall, as has already been mentioned, keeping one set of users happy will likely make another set unhappy.
And there is a general principle in Fibery dev (for better or worse) to not introduce user settings/preferences unless absolutely necessary.
FWIW retaining support for one panel navigation as a setting was done very grudgingly
I guess if you see panels opening to the right as temporary exploration and you intend to go right back where you came from within a few seconds, I can see where #teamautoexpand is coming from.
For us, as a digital agency with many different clients, we’re always context switching and trying to keep as much relevant information on the screen as possible at once, which is why having UNCONTEXTUAL information in the form of something automatically opening again after it was closed really throws us for a loop.
I will often be in the middle of something, get distracted by a message or meeting and then try to come back to the same screen I was on with zero memory of the path/entity clicks I originally used to get there…which is fine, until I close a column on the right and then get super confused why something I was looking at an hour ago and no longer care about popped up again.
Let your users explicitly define the context and not make assumptions that you know what they want to see! #teamkeepcollapsed
I bet there’s a lot of similar preferences here that align with how people use the primary left menu/sidebar as well. I generally avoid it and only use it when necessary to get somewhere completely different from where I currently am in Fibery. I much prefer to use related entity-to-entity links to get to where I need to go, which is why once I’m where I want to be, I don’t necessarily want to see the path I took to get there anymore.
I get complaints about it daily from our team.
It’s strange if you view it as doors that you open and close, sure. But that’s not fully the intent. As I outlined above, it is trying to combine the utility of “open a page in one of two panes” and that of the sort of “extended breadcrumb navigation” metaphor of sliding panes navigation. In the former, what you’re saying more or less makes sense. But in the latter, as a navigation method, essentially like a visualization of “browser history” in some sense, then it does not. And since this feature in Fibery is a hybrid of the two, confusion is unsurprising. It depends on how much you want one type of functionality vs. the other, and whether doing a good enough job balancing between them to provide enough of the benefits of each for the average person, without too much confusion.
This is all very amusing.