Consistent theming across components

I’m probably late to the party here, but it’s recently struck me that visually, Nethserver is a mishmash of apparently-unrelated projects. Just to name a few, you’ve got Cockpit, Roundcube, Nextcloud, and SOGo, none of which looks much like any of the others–different colors, different icons, different logos front and center, etc. And a quick web search suggests that all of these (even WebTop) support at least some level of theming.

It seems to me that Nethserver would look considerably more “polished” if at least the major pieces had matching themes–IOW, it might be less obvious that “Nethserver” is really just the glue holding a bunch of unrelated products together. Obviously it’d be up to the packagers of any third-party modules what to do with their stuff, but having a consistent look and feel across (say) Nextcloud and whatever webmail system is being used would go a long way toward making Nethserver look like a single integrated product.

Thoughts? Developing this would of course involve some talent in the graphic arts, which I completely lack, but I’d think that once a style guide is put together, it should be relatively straightforward to implement it in the various apps.

5 Likes

@danb35

Hi

I do think this is a good idea.

I’ve dabbled at keeping a consistant look for my customers, also trying to keep a consistant design eg in Apps (Like Zabbix). But all over NethServer? Not yet put my toe in yet!..

Design (by extension also present fashion / tastes) is a difficult issue, as the latin saying goes:
De gustibus non disputandum… (You can’t argue about taste)…

-> Later on someone added in:
Some aquire it earlier, some later, and some never at all! :slight_smile:

But as an example: Since the event of smartphones, almost the whole IT have consolidated on a squarish image for a person - or company logo… Even Outlook uses a squarish space… Yet how many “Graphic Designers” submit in a rectangular Logo for a new company? It looks really crappish when “squared” out to fit!

But a simple “Design” or Theme, with a few guidelines - that would go a LONG way!!!

A starter would be a “put your logo here”, a tickbox with “distribute this to all installed apps”, and a bit of scripting added in would already work wonders!

My 2 cents
Andy

Of course, and no single theme is going to please everyone–though it should be possible to come up with something that (almost) nobody hates. The most obvious extension of this idea would be to have a dark theme and a light theme.

Now, it would be great to have centralized control over the theming, but that’s way beyond the scope of what I’m suggesting. I’m just suggesting that we come up with a style guide and then implement it in the nethserver-* modules for those applications that support it.

I think that… it’s quite a waste of time.
The coherence of the user experience is always something nice and useful, because provide a faster adaptation by users both on “new installations” or adding to the user more applications/modules, But… the projects where the software came from are not managed in the same way, and they are not the same kind of product.

Webtop is “similar” to roundcube, but it’s not the same thing, and i don’t know if sonicle wish to “adapt” to the goals about UX of KolabNow and XS4ALL (these two names came as acting contributors to the roundcube project). Or the other way around.
The only place into i wish coherence about interface, UX and some more is cockpit, because currently is custom made by Nethesis as the “boss switchbox” of the distro. (By the way: it’s possible to have at least a way to change color theme from menu without tweaking the CSS?)
But there’s no point IMVHO, to try to make Mattermost a “look alike” to any other module. It’s like the sunday mechanic which starts from a pickup to create an high performance one-off for track days. He can succeed, i know, but maybe it’s better to start form… IDK, a BMW M3? Less useless work.

On the other side, a bit more documentation/knowledge base/tasklist for branding or theme adaptation/creation should be much more effective. Small/Medium business maybe do not have a “style/palette” for the brand identity, but maybe they already have, so knowing how to “tweak” some settings for (at least) use the “right orange” for the higlighs and accents… could be a speedup into adding ribbon and glitter to the installation.

But since both implement theming control into their applications (based on what a quick Google search tells me; I haven’t had occasion to try it myself), neither Sonicle, KolabNow, nor XS4ALL need to do anything more than they’ve already done. It’s “us” (for some value of “us”) who can then adopt a standard color palette or two (again, both dark and light themes would be nice), consistent-looking application logos, etc. No, Nextcloud isn’t going to look just like Mattermost–they’re different applications and do different things. But they can look similar, such that it isn’t immediately obvious to anyone looking that Neth is nothing more than a collection of open-source applications from a variety of developers, with a bit of glue to hold it all together.

(and yes, I know that “a bit of glue to hold it all together” greatly understates the work that goes into making all these things work together. There’s lots of integration going on, but that integration isn’t apparent to the end user).



No offense intended, buddy, but a three-panel-layout is the most common thing to both. After the login process, of course.

I see no use to make a spark plug look like a fuel injector, only because they’re screwed into the engine head.

Either I’m being very unclear, or you’re deliberately misinterpreting me. But since you’re using an automotive analogy, do you see value in the instrument cluster, the HVAC controls, and the radio all having similar symbology and color schemes, even though all three may come from different manufacturers? Because auto manufacturers do, and in fact spend quite a bit of money to make it this way. I’m not interested in “under the hood” (literally, in your example) components–I could even leave out Cockpit for that reason–I’m interested in the user-facing side of things. And I’m pretty sure that was obvious from my suggestion.

1 Like

For me, the term “theming” associates making something cosmetically “beautiful”. Making something “beautiful” is a futile endeavor, because beauty is in the eye of the beholder. But making something uniformly recognizable and usable by applying a style guide that defines which UI element is placed how and where in a standardized way would allow for faster familiarization. This should also be possible for the pure cockpit modules. In this context, call your proposal “consistent application usage experience across cockpit modules” and most of us will agree.
Across applications even for third party modules I think this is impossible. If volunteer developers would be “forced” to provide or serve an additional theming layer as well, the additional effort would make it rather difficult for them to provide integration-ready packages on their own repos. It would significantly diminish the value of the platform if developers were to forgo providing their own packages just because the extra effort makes it more difficult for them to do so.

If I called it that, it wouldn’t be what I’m proposing–my suggestion has little if anything to with Cockpit. Am I really being that unclear?

It really seems like neither you nor Michael are reading what I’m suggesting here. Because if you read these quotes and think that “consistent application usage experience across cockpit modules” is anything like what I’m suggesting, I don’t know that I can do any more to help you understand.

While I see the benefits, specially to keep a corporate branding (or make the different integration of applications look more professional to new users), I doubt it will be implemented any time soon. Disregarding the differences, the idea could be extended to choose a general default language as @carsten wanted.

…some db props (and optionally a panel in cockpit to manage them) with most common theming/branding settings for modules to adhere to:

  • logo
  • favicon

Preset (pre-made combinations; optional):

  • light
  • dark
  • Custom… (custom combinations):
    • Main/Primary color
    • Secondary color

(Just a quick example, things can be more complex like size of logo, image format, etc.)

Module developers, can opt to adhere to general theming preferences:

  • if global theming preferences are set, translate them to the available theming options of the underlying module application (i.e. set a specific theme, or fill in the matching theming fields).
  • Some dbprop to ignore global preferences in case someone wants to override them for a specific application.
  • If nothing set, nothing to do, use defaults.

Sudden upstream changes could make things more difficult.

1 Like