Skins and themes support

Sing-Li commented 9 years ago

Make it possible to 'white label' Rocket.Chat.

Should not need to know Meteor or JavaScript to become a skin/theme artist.

Embrace a mini-industry of Rocket.Chat themes and skins creators.

TEST for success: When we see a themed Rocket.Chat in the wild, but we're not certain if it is really Rocket.Chat :)

engelgabriel commented 9 years ago

Depends on RocketChat/Rocket.Chat#222

jonbaer commented 8 years ago

Please somehow add the following:

RocketChat.theme.setPublicColor "primary-background-color", "#000000"

When creating a theme package it is not possible to override these settings (w/o having to go into the admin console itself), I understand the need to adjust this @ runtime via the admin panel but it would be nice to just be able to setX on the themes as well via a custom package @ startup.

engelgabriel commented 8 years ago

@jonbaer you can do this:

RocketChat.settings.add("theme-color-primary-background-color", "#04436a");

On you package, but must be added BEFORE the theme package.

Or even set that as an environment variable or Meteor.settings.

See /packages/rocketchat-lib/server/functions/settings.coffee for reference:

RocketChat.settings.add = (_id, value, options = {}) ->
    # console.log '[functions] RocketChat.settings.add -> '.green, 'arguments:', arguments

    if not _id or not value?
        return false

    options.packageValue = value
    options.valueSource = 'packageValue'
    options.ts = new Date
    options.hidden = false

    if process?.env?[_id]?
        value = process.env[_id]
        options.processEnvValue = value
        options.valueSource = 'processEnvValue'

    else if Meteor.settings?[_id]?
        value = Meteor.settings[_id]
        options.meteorSettingsValue = value
        options.valueSource = 'meteorSettingsValue'

    if not options.i18nLabel?
        options.i18nLabel = _id

    # Default description i18n key will be the setting name + "_Description" (eg: LDAP_Enable -> LDAP_Enable_Description)
    if not options.i18nDescription?
        options.i18nDescription = "#{_id}_Description"

    return RocketChat.models.Settings.upsert { _id: _id },
        $set: options
        $setOnInsert:
            value: value
            createdAt: new Date

jonbaer commented 8 years ago

I understand this, but what I was trying to avoid was having to rename "rocketchat:theme" and add my own values and instead have it to where I could keep "rocketchat:theme" package and (somehow) have my own "mycompany:theme" package which would override the setting values. It would be great to have a way to let the official rocketchat packages load first + then have secondary packages overlay but I understand this is not possible in Meteor(?) ...

engelgabriel commented 8 years ago

You can set the variable later too.. but that way, you will reset it to your package value everytime you restart the app... what may be acceptable in some cases.

RocketChat.settings.updateById("theme-color-primary-background-color", "#04436a");

Sing-Li commented 8 years ago

Re-opening in the light of recent discovery that our existing implementation of theme is completely different than the community's view of what a user-loadable theme should be.

Reference RocketChat/Rocket.Chat#2102 and RocketChat/feature-requests#635

Also - see themes for

mitar commented 8 years ago

I think those are two separate things. How to skin (CSS) and how to theme (change HTML).

I think Rocket.Chat should just provide skinning, but theming can be done later. For now one could use things like template extension package to override themes.

Or would you provide something like autoform where are templates can be configured?

mitar commented 8 years ago

(Maybe time to move to Blaze Components.)

Sing-Li commented 8 years ago

:smile_cat: If we take a look at the thriving marketplace eco-systems for Wordpress, Ghost, and Drupal themes ... the industry's term for changing the look of a system seems to be generic 'theme' - I'd suggest regardless of technical correctness.

It would be good to get input from some in-the-trench theme design/modification folks from the other systems. Like on the other linked issues.

stephymiehle commented 8 years ago

I think there's even another subset... Slack calls changing the sidebar colors a "theme":

The color swaps are nice, but very limited; you can't customize the looks of anything else. This only affects the sidebar.

I can see three main ways to allow styling:

Allow Slack-esque color swaps in the base style, perhaps with a few built-in themes; easy for general users to tinker with things. I would not call this a theme; maybe "color scheme"?
Allow custom CSS skinning like @mitar mentioned; this allows for incredible style overhauls, especially when the markup is well-organized and classes make sense. I'd call this "theme". Perhaps themes could have multiple color schemes to choose from, if the author created multiple versions, but I don't think I'd allow general users to edit the colors in a theme, only choose from available color scheme options. Writing CSS in a way that you could easily color-swap could work with some layouts but is limiting.
Changing the markup itself could be a "template"; this would be the ultimate for white labeling, but also require the most work to set up. Each template would need a template-specific theme, since with changed markup, we can't rely on the same structures and nesting for CSS and themes for other templates will likely break.

CSS theming alone make font, color, and layout easy to change. I've worked on several systems with awful, awful markup that couldn't be edited, and you'd be surprised how much you can accomplish with CSS alone.

mitar commented 8 years ago

CSS theming alone make font, color, and layout easy to change. I've worked on several systems with awful, awful markup that couldn't be edited, and you'd be surprised how much you can accomplish with CSS alone.

And as an open source project people can always make pull request to add classes and other CSS related stuff to the theme if needed.

shtefcs commented 8 years ago

As @Sing-Li said it will open whole new mini marketplace for RC themes.

I really cant wait to see that coming out, but I guess its pretty early yet to working on theme engine.

Anyway, when this happen, I would be glad to create unqiue theme for RC and share with community.

Peace,

jseadragon commented 8 years ago

Is there any chance this will also skin the chat window background? I'd like to eventually create a dark theme for the whole window, not just the sidebar

engelgabriel commented 8 years ago

Yes, 100% of the colours used on the UI will be configurable.

lucasvanhalst commented 8 years ago

for those that do not want to wait for this and would like a night theme, you could use this css and javascript to add a button to the flex tab bar which turns on a night theme: CSS: https://gist.github.com/lucasvanhalst/1aff04d33a826afd2600696332c1c5ee JS: https://gist.github.com/lucasvanhalst/35dcffa5cbfd704825debc4e83a2e30f It's far from perfect but it's usable for now :stuck_out_tongue: It's also assuming the sidebar is set to a dark-ish colour It looks like this: https://i.imgur.com/10YW5ou.png

shtefcs commented 8 years ago

This is really nice :). gj

freeredpill commented 8 years ago

Is there any update on how to modify the theme, for example changing default logos and background-color?

engelgabriel commented 8 years ago

@freeredpill you can change most colours via the admin panel.

timkinnane commented 8 years ago

@engelgabriel I'm not confident the admin panel colour approach works. See RocketChat/Rocket.Chat#2347. There's inconsistent implementation of the settings within less files, so you can override some, but others are fixed, so its impossible to do more than minor tweaks that way, definitely can't produce any kind of overall "skin".

I've been hacking theme system through my own custom meteor package, adding less assets and replacing some templates using another meteor template package.

I'm working toward a theme framework approach that could maintain a path where child-theme folders can be added, to dynamically load a set a of less files, template replacements and execute some custom hooks, the way Wordpress theme functions.php works. My current version is very hacky but I'd be happy to share my approach with anyone else working on this.

Maybe some others would like to set up a working group to discuss further and share resources? I'd also suggest consolidating the other issues around this into this one. Includes: RocketChat/Rocket.Chat#2347, RocketChat/Rocket.Chat#1944, RocketChat/Rocket.Chat#2102.

bjoseph1 commented 8 years ago

+1 for @timkinnane suggestion for theme/skin framework. Tim, would love to learn more, participate and share resources

shtefcs commented 8 years ago

This will be one huge step forward.

@timkinnane Maybe me and jelena can help with designing new template. I could design something and @jelenajjo can do frontend work.

We hangout on our RC chat on https://chat.vanila.io.

We are waiting for this feature from the RC start.

timkinnane commented 8 years ago

Thanks @bjoseph1, @shtefcs, @jelenajjo!

I have made one fairly big re-skin already, screenshots attached with my team's branding removed. Through a custom package I've changed settings defaults, injected custom styles, templates and jQuery into template hooks, mainly with aldeed:meteor-template-extension. My first theme has a lot of my-own branding content built-in, so I need to make a generic version before I can share it. Will hopefully do that soon.

screenshot 2016-06-08 12 30 00 screenshot 2016-06-08 12 31 23 screenshot 2016-06-08 12 32 21

Here's the general proposal / draft roadmap for a theming system.

The main problem is that each of the theme's client/server resources need to be set manually by the package using api.addFiles and api.addAssets. So themes must be contained in the package / repo before build. Ideally the package would maintain a folder structure that themes can be loaded into dynamically without needing a pre-defined manifest (e.g. via zip upload), then it would scan the theme folder and map in the resources dynamically and trigger a rebuild. Such as discussed here. The basic theme structure would be something like:

Client files

themes/mytheme/views/*.html templates, to replace defaults if names match). themes/mytheme/client.js single file for client functions, template helpers, hooks.

Client assets

themes/mytheme/clientAssets/** contents loaded as assets (mostly images)

Server assets

themes/mytheme/serverAssets/** server assets (mostly less files)

I also have a server.js loaded, but I don't know if that's a good idea for themes. It only does two things:

It contains settings updates (e.g. in my screenshot Message_ShowFormattingTips is false), I've also changed most of the theme-color- which are then also used in the custom less files.
It loads the less files via RocketChat.theme.addPackageAsset()

The better alternative for complexity and security would be to take those functions out of the theme and let the parent package read in something like a YAML settings manifest from the theme and auto load any included less files. That would allow themes to stay simple, have a rigid semantic structure and be basically drag and drop loadable.

At some point we'd have to consider versioning themes and allowing the theme manifest to declare its own compatibility with versions of Rocket.Chat / Meteor. Possibly even parent/child theme relationships. I have no idea how to any of that.

shtefcs commented 8 years ago

Pretty nice design. I would re-design that user buttons on rightsidebar, and instead put small one or in some menu

timkinnane commented 8 years ago

Yeah I just restyled the existing buttons as proof of concept. Plus all but one of those buttons only appear for admins.

engelgabriel commented 8 years ago

This looks exciting, we desperately need some help with the UX. Should we arrange some time to talk?

shtefcs commented 8 years ago

@engelgabriel Will you accept Tim work and merge into master ? I would like to help with UI/UX and create some templates.

engelgabriel commented 8 years ago

If what is produced for the new UX is aligned with we have in mind, yes, obviously.

shtefcs commented 8 years ago

Well, you if you put this in core, we can produce template per any needs.

Can we talk so I can understand what is yours alignments?

bjoseph1 commented 8 years ago

Awesome and thanks a ton @timkinnane . I think your solution sounds excellent and well thought out. Your designs look great too.

I'd imagine this process would include:

Define theming system functionality (what it can/can't do)
Define theming system framework model (how will it work; as @timkinnane did above)
Get Rocket.Chat's blessing
Build package + documentation

I've done bit of research and am good with @timkinnane suggested method, but this is outside of my domain. It sounds like there are some versioning and compatibility questions which could be important considerations so perhaps merging in the other related issues (#2347, RocketChat/Rocket.Chat#1944, RocketChat/Rocket.Chat#2102) and members could provide some suggestions and additional participants. Regardless, I’m good with the suggested plan.

It may also be of benefit to review WordPress' theme anatomy and docs, and conduct some research on any other related Meteor theming questions.

Someone needs to lead this….???

I'd be willing to participate via a Bounty contribution provided we can get this completed soon, which I’d love to see happen.

stevoPerisic commented 8 years ago

@timkinnane is there a Rocket.chat channel for this? :)

timkinnane commented 8 years ago

@stevoPerisic - Don't think so. There may be a private group for core developers of the UI, but I haven't had a chance to catch them yet. I'm busy for the next week, then will get back to this issue and publish my theme.

geekgonecrazy commented 8 years ago

@stevoPerisic @timkinnane https://demo.rocket.chat/channel/skins-and-theming i've created one.

timkinnane commented 8 years ago

Tried to get work done on my theme, but found a big blocker; the myriad hard coded colors are a major impediment to theming Rocket.Chat. I've started a branch updating all rgba and hex codes used in less files, swapping them out with their closest equivalent color setting variable.

Would love some help and feedback on points below. Resolving this will really grease the wheels of allowing custom themes/skins. Would also resolve RocketChat/Rocket.Chat#2102, RocketChat/Rocket.Chat#2347 and RocketChat/Rocket.Chat#1944.

I found there's also two divergent approaches to loading .less files in packages; directly as a client file or as an asset processed through the rocketchat-theme addPackageAsset method. Only the latter allows the less file to reference global color variables. So I have to also update any packages using the other way.

Is there any way to add a codacity or commmit hooks to look for direct use of hex codes or rgb/rgba values in future PRs to prevent a backward slide in theme-ability or RC?

A couple issues I uncovered while going through all the less files (didn't have time to address yet and would love help/feedback):

There's no standard settings view styles. Even very common stuff like tables are styled differently by individual packages (e.g. rocketchat-authorization). This leads to poor and inconsistent UX for admins.

There's too many colors. Having so many arbitrary color definitions encourages inconsistent usage and bad design. The context for each color setting needs to be high level (like primary-background-color) not specific (like clean-buttons-color and unread-notification-color). It's better for specific cases to use derivatives of the main palette, through less functions like lighten/darken/mix.

There's also lots of grey and semi-opaque variants that reproduce each other. We could simplify them all by having a setting like primary opacity, secondary opacity, then set those specific grey derivative colors to use two extremes (default to white and black) as a base, combined with the opacity settings.

The general level of specificity in the default theme is too high. This makes it hard to redefine colour usage in custom themes, because you have to overrule way too many selectors. There needs to be common semantic classes that can be applied to view components to denote their color hierarchy. e.g. rocketchat-theme _color_imports.less uses primary-background-color in 22 places. Instead elements where the primary background is used could just have a primary-bg class in the view. Themes can still override specific cases if they need to.

rodrigok commented 8 years ago

@timkinnane We don't have a UX guy, so we don't have a good UX/UI in Rocket.Chat, we did the color config just to have that option but we need to improve this part.

If you can help us to define the colors, variables, etc, I can help implementing theses changes :)

timkinnane commented 8 years ago

Thanks @rodrigok, I've done this kind of thing quite a bit, but I'm not claiming to be a design guru. Will give it a shot and share where I get to. It's good to know you guys are open to it.

rodrigok commented 8 years ago

Awesome @timkinnane, and yes, we are open to any improvement, we know we need a better UI/UX and a better support for theming, but we didn't have time and resources to do this.

Thank you so much by your help :)

timkinnane commented 8 years ago

No worries, I understand you guys have other priorities right now.

I'm working on consolidating the current use of color variables. There is an implementation issue I could use help with or just direction, that is extending the rocketchat-theme package with some simple methods for other packages to use colour variables (registers/getters/setters), so they can work with the existing scheme instead of defining duplicate color usage. e.g. SAML buttons.

I'm not sure the order assets are loaded and compiled, but maybe extra packages like that could declare their own settings if they needed, but use defaults from something like RocketChat.theme.getColor('action-buttons-color').

Nemra1 commented 7 years ago

wher is the defult skin path pls.. im lost her..

justinr1234 commented 7 years ago

@timkinnane Where did you end up on this? I'd like to contribute but want to know where to start ... Can you create a checklist perhaps?

Sing-Li commented 7 years ago

@justinr1234 A lot of work on this front ... thanks to @timkinnane .

Please see this PR and all the related PRs and issues.

https://github.com/RocketChat/Rocket.Chat/pull/4803

timkinnane commented 7 years ago

Thanks @Sing-Li. Yeah @justinr1234 I had done a fair bit, but haven't been able to work on it lately. @karlprieb has been carrying most of it since then, he had a list (#5040) but it looks all done.

If you search for is:issue is:open involves:karlprieb there's plenty more UI tweaks and fixes to get to. I also added some docs which are hopefully helping getting new contributors up to speed.

ma-karai commented 7 years ago

any news on the whole UX review

idchlife commented 6 years ago

Yes, interested too. Is there way right now easily to customize at least colors in desktop client?

engelgabriel commented 6 years ago

I think we can close this issue, as most of the recommendations and requirements have been incorporated into the layout section of the admin panel.

jcklpe commented 6 years ago

Hey what's the status of themes in Rocket Chat? I'm having trouble finding this information. I can see docs on how to develop themes, and I can see a section on changing the UI colors with CSS, but I don't see any good repo to actually browse themes or see what other people have done with the features. As someone who is tech savvy but not a full developer, having access to this information would be helpful. I don't know Meteor so I don't know what I should expect as far as customization. But I am very interested in seeing examples.

VWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWV commented 6 years ago

@engelgabriel actually why don't you leave it open? everything i've come across with respect (or lack thereof) to rocketchat UI/UX is related to people wanting, trying, clamoring, and begging for something that looks better than AOL layered with modskin2018 and has a more functional UX than compuserve. this is the face of your development, which is judged by the same standard as slack by those whose pants get tight when they use the alternative. make it happen dude!

jcklpe commented 6 years ago

Also I think I might have said this elsewhere but I'd be willing to donate my time to help out RocketChat as a professional UX Designer. I've been wanting to get involved in more Open Source projects but my dev skills are not yet up to the level where I'd be very useful. I can however help a good deal with UX,but I'm not sure how to plug in on that.

I'll link my website here to just prove I'm a greenhorn: https://www.jackalope.tech/

Also I've been asking around on twitter about how I could help an Open Source project and I was linked this article: http://opendesign.foundation/articles/import-designers/

Which I found very useful. If I can help out in anyway, let me know.

lorek123 commented 6 years ago

Is there any chance for support per-user styles?

cortex3 commented 5 years ago

yes please, per-user style and an official dark mode would be fantastic.

lucaspmarra commented 4 years ago

Any new update? We'll able to install themes like in Brackets IDE? (Open-Source)

RocketChat / Rocket.Chat