Page MenuHome

UI: Tab-Like Side Panel Close Widgets
Needs ReviewPublic

Authored by Asher (ThatAsherGuy) on Tue, Oct 1, 12:51 AM.

Details

Summary

This diff combines aspects of @Harley Acheson (harley)'s D5870 and the default open/close widgets, centering them, adjusting their colors, and scaling them with the width/height of the editor. The general goal is to update their styling while retaining the affordances of the original design, using a tab-like shape that may be useful elsewhere.

Current design:

Initial design proposal:

Updated design proposal:

Diff Detail

Event Timeline

Brecht Van Lommel (brecht) requested changes to this revision.EditedTue, Oct 1, 1:29 AM

I think these grab too much attention. They look like scrollbars at first sight, particularly in the timeline. They will conflict with the horizontal scrollbar in the outliner. In the properties editor they sit really close to other UI elements, to the point you might accidentally click them, though admittedly the current ones don't work well there either.

This revision now requires changes to proceed.Tue, Oct 1, 1:29 AM

You're right about them visually crowding the scrollbar in the outliner and the expansion arrows in the property editor, but I haven't had much issue with actual interaction. How frequently do users flip and hide headers and navigation bars? I could work in some region-specific and orientation-specific accommodations.

When it comes to them looking too much like scrollbars, would inverting the luminescence values help?

Actually I quite liked this until it was pointed out that they look like scrollbars. And now that is all I see. LOL.

It is a tough problem as we don't have a good way to judge success. We just know the current ones look a bit funny.

Looking at both yours and mine though I think it does help a lot to have these indicators centered, rather than offset as they are now. And it is nice that the grab area is longer than now - easier to see and grab. Yours looks prettier but probably too intrusive while Mine might be too minimal? They both feel nice in practice though.

It could be that anything is an improvement over what we have now. It might be worth a try to keep the indicator exactly the same as it is currently, with same arrow and coloring. But make it longer like yours and centered. It would then be just a slight evolution. It would be difficult for anyone to say it looks worse in any than it does currently or interfere more with the scrollbars. Then once that is in we might be able to play with it further.

I can push the design a bit, overlapping the shapes in order to break the scrollbar feel. Here it is with const short narrow = (U.pixelsize) + (int)(2 * U.dpi_fac);, which is about as thin as it'll go.

While there are advantages with making them more prominent,
In general I find corners a better place to add these hints (it feels less intrusive).
In the center they're not as easy to ignore.

Also these wont co-exist well with scroll-bars.
While the current widgets aren't great with scroll-bars, they are at least distinct, we could tweak placement not to overlap scrollbars without larger changes like this.

Prefer to leave these as-is.

Campbell Barton (campbellbarton) requested changes to this revision.Tue, Oct 1, 8:14 AM
William Reynish (billreynish) requested changes to this revision.Tue, Oct 1, 8:33 AM

Also prefer to leave as-is for the same reasons already mentioned.

Asher (ThatAsherGuy) updated this revision to Diff 18698.EditedTue, Oct 1, 8:43 PM
Asher (ThatAsherGuy) edited the summary of this revision. (Show Details)

Removed tab outline, reduced tab thickness, simplified arrow geometry, adjusted colors, adjusted dimensions.

Regarding scrollbar overlap, here's a quick comparison:

Asher (ThatAsherGuy) edited the summary of this revision. (Show Details)Tue, Oct 1, 8:47 PM

Would a combination of center-aligned horizontal elements and top-aligned vertical elements (or vice-versa) be better?

I have a feeling that there just isn't a path forward that will please everyone enough to get any change through. It might take @William Reynish (billreynish) to first mock up a design that he likes, approval through UI group, then we can follow whatever they come up with.

It isn't a critical design task, so I'm not too worried about what the final result looks like. Mostly a way for me to use Cunningham's Law to figure out how the UI team does its thing.

The thing is we already changed this design a few times, what we have now is what the UI team agreed on and it's sort of a local maximum. Unless we find some way to solve this problem in a very different way I don't think we'll be changing this design again.

Different in terms of behavior, appearance, or functionality? I can look into incorporating behaviors like the reactive thickness based on cursor proximity, and I'd be happy to build those behaviors on top of the default appearance and position instead of what I've proposed here, but I can't tell from your feedback if that's the kind of solution you're looking for.

I'm not looking for any solution at all, I think the current design is fine.

It awkwardly overlaps with other UI elements in some places, but solutions to that probably all have some downsides too.

That was poor wording on my part; 'a solution you're amenable to' is a better way to phrase it. My intention was to follow up on your comment about finding a very different way to solve the issues in the default implementation and clarify the scope of the conversation.

In any case, I learned what I was looking to learn. Barring actionable feedback, I'll move on.