New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Skins and themes support #277

Closed
Sing-Li opened this Issue Jul 7, 2015 · 48 comments

Comments

@Sing-Li
Member

Sing-Li commented Jul 7, 2015

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

This comment has been minimized.

Member

engelgabriel commented Jul 7, 2015

Depends on #222

@jonbaer

This comment has been minimized.

jonbaer commented Nov 18, 2015

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

This comment has been minimized.

Member

engelgabriel commented Dec 4, 2015

@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

This comment has been minimized.

jonbaer commented Dec 4, 2015

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

This comment has been minimized.

Member

engelgabriel commented Dec 4, 2015

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

This comment has been minimized.

Member

Sing-Li commented Feb 4, 2016

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 #2102 and #2095

Also - see themes for

@Sing-Li Sing-Li reopened this Feb 4, 2016

@mitar

This comment has been minimized.

Contributor

mitar commented Feb 4, 2016

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

This comment has been minimized.

Contributor

mitar commented Feb 4, 2016

(Maybe time to move to Blaze Components.)

@Sing-Li

This comment has been minimized.

Member

Sing-Li commented Feb 4, 2016

😸 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.

@blindingstars

This comment has been minimized.

blindingstars commented Feb 4, 2016

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

image

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

This comment has been minimized.

Contributor

mitar commented Feb 5, 2016

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

This comment has been minimized.

shtefcs commented Jun 8, 2016

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

@engelgabriel

This comment has been minimized.

Member

engelgabriel commented Jun 8, 2016

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

@shtefcs

This comment has been minimized.

shtefcs commented Jun 9, 2016

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

This comment has been minimized.

bjoseph1 commented Jun 16, 2016

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, #1944, #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

This comment has been minimized.

stevoPerisic commented Jun 20, 2016

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

@timkinnane

This comment has been minimized.

Member

timkinnane commented Jun 21, 2016

@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

This comment has been minimized.

@timkinnane

This comment has been minimized.

Member

timkinnane commented Jul 27, 2016

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 #2102, #2347 and #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

This comment has been minimized.

Member

rodrigok commented Aug 16, 2016

@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

This comment has been minimized.

Member

timkinnane commented Aug 16, 2016

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

This comment has been minimized.

Member

rodrigok commented Aug 16, 2016

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

This comment has been minimized.

Member

timkinnane commented Aug 16, 2016

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

This comment has been minimized.

Nemra1 commented Oct 22, 2016

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

@justinr1234

This comment has been minimized.

justinr1234 commented Dec 12, 2016

@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

This comment has been minimized.

Member

Sing-Li commented Dec 12, 2016

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

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

#4803

@timkinnane

This comment has been minimized.

Member

timkinnane commented Dec 12, 2016

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.

@bott0r

This comment has been minimized.

bott0r commented Aug 2, 2017

any news on the whole UX review

@idchlife

This comment has been minimized.

idchlife commented Sep 19, 2017

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

@engelgabriel

This comment has been minimized.

Member

engelgabriel commented Jan 30, 2018

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

This comment has been minimized.

jcklpe commented Mar 13, 2018

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.

@RedRocketCat

This comment has been minimized.

RedRocketCat commented Mar 23, 2018

@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

This comment has been minimized.

jcklpe commented Mar 23, 2018

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.

Peym4n pushed a commit to redlink-gmbh/Rocket.Chat that referenced this issue Apr 6, 2018

Merge pull request RocketChat#277 from assistify/feature/RocketChat#213
…-pin-message-perm-as-default-for-user

added pin-message permission to user default permissions
@lorek123

This comment has been minimized.

lorek123 commented Aug 16, 2018

Is there any chance for support per-user styles?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment