Repository navigation
Make the topbar less prominent #2348
Description
Note
this should fix at least these 2 issues:
- users overlook the primary action and/or mix it up with nav items because of the surrounding chrome border
- in editors we received the feedback the top bar it "too high". in fact, the top bar is almost as high as in onedrive but the perception is different, presumably because of the "heavy" color
User Story
As a user, I want the main content area to be visually prioritized over the topbar so that I can quickly focus on the primary action/information.
User Value
- focus
- consistency with dark mode
- "feel at home" for people transitioning from Big Tech to OpenCloud (see m$ onedrive & google)
Acceptance Criteria
- no more VIP / extrawurst color: set chrome color to surface-container (and set the on-surface color accordingly)
- set logo color to petrol
- set logo color to alex' lillac in dark mode as we would totally loose lillac (not sure if this is right solution to preserve lillac somehow in the ui)
the above would then be in line with the dark mode:
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
bxtcns4tdp-art commentedon Apr 11, 2026
The lilac is a beautiful color. Also, please don't go to monochrome for the sake of looking like Big Tech. Opencloud should form its own distinct design, and is in my opinion already more visually appealing than either one drive or google drive. We should embrace color.
streaminganger commentedon Apr 12, 2026
i get what you mean. i was surprised myself after realising the height of the topbar is the same or even smaller than onedrive. but i echo the same sentiments as @bxtcns4tdp-art about stripping away that beautiful lilac color. the branding and soul is somewhat gone after that
honestly what i feel helps even more is doing away entirely with the side paddings and rounded corners surrounding the main content. it returns some significance and screen real estate to the main content. no longer making collabora or other apps feel like a "container" or just another iframe
tbsbdr commentedon Apr 14, 2026
lets try to keep the lilac in. how about:
Variant 1
B47CEE)Variant 2
Variant 3
bxtcns4tdp-art commentedon Apr 14, 2026
My opinion - V1 looks not bad. Not a fan of the gradient in 2 and 3 though, its a bit tacky.
What is the underlying issue though, were people finding it difficult to create new documents? If that's the case, I think it might be the color match between the top bar and the new button. So V1 should help that.
tbsbdr commentedon Apr 15, 2026
Yes, users overlook the primary action and/or mix it up with nav items because of the surrounding chrome border
Thanks for sharing your perception!
JammingBen commentedon Apr 15, 2026
I find V1 okay. Not super nice looking, but it does it's job (though I'd prefer the petrol logo over the lilac for better uniformity).
I agree. Removing the border already increases the focus on the "New"-button IMO, because there is a clear separation between topbar and content. This missing currently.
Besides that, making it a bit more "airy" would probably help also. Not a big fan of the gradient. We still have the primary color (see the FAB on mobile resolutions), that could work as well.
Alternative suggestion to V2:
streaminganger commentedon Apr 15, 2026
V1 for Big Tech look and consistency with dark mode
V3's gradient buttons brings us back to ocis days, but it looks a little out place in the material redesign of opencloud. it worked better on ocis which had that layered aesthetic.
i like this! @JammingBen's variant of V2 is the best look to me so far
would shadows or border highlights around the new action help? i do think it's fine as is with the brighter primary
tbsbdr commentedon Apr 15, 2026
Problem description
By moving the primary button to the left sidebar, we violated the rule of proximity. Elements that are close together or visually grouped are perceived as related. In this case, the button appears to belong to the sidebar, suggesting it creates a new sidebar item rather than a file or folder in the main list.
Lets focuse on fixing this misunderstanding eg. via increasing the visual prominence of the button, reducing competing elements such as the top bar and avoiding any additional grouping cues that tie the button to sidebar items.
Any visual grouping between the button and the sidebar reinforces the wrong mental model (even if it looks very nice).
How is it fixed by others?
Mitigate this problem through stronger visual hierarchy cues, for example:
streaminganger commentedon Apr 15, 2026
i think i also know why the new action can be overlooked. think about it. at a glance doesn't the current flat and wide button look almost like a header that might be cancelled out unconsciously?
the button needs to look more like a button again. i tried combining some of the suggestions above.
borders are taking inspiration from @JammingBen's variant. but without the sidebar grouping which is misleading
following google, button gets taller and not full sidebar width
airy padding below and above the button
button is using primary color, rounded, has a thin border which is role-onprimary? and has shadow
what do you all think?
tbsbdr commentedon Apr 17, 2026
oh yes, thanks @streaminganger - thats definitely an improvement to the status quo!
streaminganger commentedon Apr 17, 2026
i tried playing around myself and implementing in code those surface container borders, and man only now did i realise its easier said than done. its a whole new layout variant thats only applicable when there is a sidebar and has to differentiate itself from the other apps that dont need those borders like collabora. tricky. sounds like a lot of refactoring needed to make this idea.
forkrails commentedon Jun 25, 2026
@tbsbdr for document editors like collabora/eurooffice, the solution is not to make the top bar smaller. the solution is to open office documents in a new tab, without a top bar at all. This recovers all the space, and it is the same approach google drive/docs takes for example.
The top bar is just an unnecessary waste of space when using one of the office editors.
kulmann commentedon Jul 1, 2026
we'll go with this ^ (except for the blue highlight on the selected nav item, that'll stay like it is now)
kulmann commentedon Jul 1, 2026
thank you for the input! we'll have another look at the editor/viewer layouting