Sakai-20 Skinning Idea - Get rid of Less and Sass

[Charles Severance]

Hi all,

I am super not an expert on Sakai skinning - I am hoping that I can make it to the point where I can retire and never learn Sass, Less, Grunt, or Ruby.

I know why we did the refactor into Sass and Less - so we could change a color one place and have it be everywhere. Bu these days we have global CSS variables.

I would really like to see us redo our skins where we eliminate SASS and less and pull all those repeated colors, fonts, etc and put them into global CSS variables.

I think this would greatly benefit the ease of customizing folks who host Sakai clients in the cloud and make it so that bringing up a new skin with local branding would be SUPER simple.

Also, I have encouraged LTI folks to look at CSS global variables as a way to allow LTI tools to inherit look/branding from LMSs.

Also Bryan Olendyke told me that global CSS variables find their way into web components.

I general I have no expertise in this area - I just hear from lots of folks and try to put the pieces together.

Am I out in left field or is this actually a good idea?

/Chuck

[Rafael Morales Gamboa]

Hello,

What about allowing an admin user in Sakai to be able to configure the skin online, directly on the GUI, instead of requiring access to the source code?

Regards,

Rafael

[Charles Severance]

Right!  

If we switch to global CSS variables, we can make it so this can be set in the UI far more easily - using Less and SASS there is *no practical way* to do this in the UI.  With clever caching this can be done is a quite efficient manner.

I think this could be one of the Sakai-20 stories.

/Chuck

[alan.regan]

I'm all in favor of simplifying the color theme process in Sakai, especially if it doesn't require restarts, etc.

Factors to consider:

• For constituents like the LAMP Consortium, think about instances that host multiple institutions.  So the ability to support "skins" for several schools, universities, organizations, or departments within a single Sakai instance would be key.
• Keeping "Lessons" CSS in mind, determining a way to make sure that if a faculty member tries to set up custom CSS for their Lessons pages, s/he doesn't accidentally clash with UI/skin elements (e.g. they change H1, UL, P in a custom CSS file and it has unintended impact on other functionality, especially in embedded tools like Assignments, Forums, etc.).
• Working toward user-selected skins.  So, an institution could offer 2-3 skins and users can select their preferred one.  We have been receiving requests for a "dark mode" for Sakai, since some people like to read on a dark background rather than a light background.  It would be nice if a user could go to their Home > Preferences > and select the skin of their choice.  If a school has two primary school colors, then perhaps different variations of skins based on the main colors, plus a "dark mode" or "light mode" skin as alternatives for those that prefer reading with different contrasts.
• Building an administrative interface to set and select logo, primary colors, etc. would be nice.  This way someone could enter HEX or RGB codes in fields or via a color picker and make the process of managing skins much easier.

Those are my quick thoughts.  So, yes, definitely in favor of a streamlined way to define and manage color schemes/themes/skins for Sakai.  If it also benefits embedded LTI or other tools -- even better!

--Alan

[Adrian Fish]

It would be nice to get rid of SASS - the less pre-compilation going on the better. It was a means to an end and got us over a hump, but now's the time to think about it. Big job, though!

--
You received this message because you are subscribed to the Google Groups "Sakai Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sakai-user+...@apereo.org.
To post to this group, send email to sakai...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/sakai-user/.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/sakai-user/ff49148a-3aaf-4cf2-a661-5c40ab983265%40apereo.org.

[Charles Severance]

I am surprised we got this far without addressing accessibility and high contrast :)

/Chuck

[Charles Severance]

On May 29, 2019, at 1:35 PM, Adrian Fish <adrian...@gmail.com> wrote:

It would be nice to get rid of SASS - the less pre-compilation going on the better. It was a means to an end and got us over a hump, but now's the time to think about it. Big job, though!

I don’t know how big of a job it really is.  My guess is that because we used SASS, we already know the places where global values belong in the CSS.  Just search and replace might be the first step.  That might get us 80% of the way there.

/Chuck

[Michael Greene]

Are you suggesting moving from SASS variables to CSS variables or moving completely away from SASS?

Would we have to remove Bootstrap since that is baked in as the starting point of our SASS compile?

I know the core CSS spec has grown tremendously over the past several years, but I don't have a good understanding of how much of the SASS feature set it currently supports. What SASS features would be required by native CSS in order for a complete rewrite to NOT be necessary? Nesting, mixins? Looks like lots of good stuff is coming, but how soon? https://github.com/tabatkins/specs/blob/gh-pages/README.md

Seems like the right time to explore it though. Shawn F and Earle N are doing a Sakai bootcamp tomorrow & Friday for 4 students we've got working for us over the summer to continue the SWITCH project. We may be able to incorporate this into the work they do if that's the direction the community decides on next week.

Also, found this thread on hackernews https://news.ycombinator.com/item?id=19753282 creator of the bulma framework chimes in.

@MG

On Wednesday, May 29, 2019 at 1:50:41 PM UTC-4, csev wrote:

[Eduardo Rey Jara]

Well,

I think would be terrible if we remove SASS. Making direct CSS is coming back to the past as if we remove JSF2 to maintain JSF1 all over the place. SASS is the right way and it supports EVERYTHING :D .. even CSS variables or what we need to add (bootstrap 4, css grid, flex box, whatever ,ReactJS, VueJS, AngularJS), even Bootstrap abandon LESS to embrace SASS. 

If we are planning to move forward to SASS variables (I think it would be great if we want to move sakai into webcomponents) we can do it inside SASS.

Here in University of Murcia we have made several skins for users to choose it and it's pretty simple with SASS but yes, it would be easier with CSS Variables AND SASS.

If you use BEM metodology on SASS, for example, you can write more readable code than in CSS (and faster and more comfortable)

Sadly, I can't attend to Open Apereo but I wanted to make my point.

--
You received this message because you are subscribed to the Google Groups "Sakai Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sakai-dev+...@apereo.org.
To post to this group, send email to saka...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/sakai-dev/.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/sakai-dev/6891a68e-d7fc-40e9-ac39-c4db3d2c7001%40apereo.org.

[martin...@apereo.org]

As a completely non-technical user who manages at least 16 different skins in the same instance of Sakai (the LAMP Consortium), I heartily second the idea of simplifying skins.  

I don't know how it works under the hood, but the promise of Sakai 10 was that we could specify skin "parameters" and that these parameters would drive the color scheme everywhere in Sakai.  For example, if I specified that a button should be dark blue with white text on it, I would have expected that buttons throughout Sakai would be dark blue with white text.  Not so.  Each tool has some kind of nuanced approach to using skin parameters.  That dark blue might show up as the background for a button in one tool, but be used for a link color in another tool.  We have ended up, in some skins, with text and background colors the same (rendering them unreadable), but changing one parameter messes up the way another tool looks.  We struggled for a year and a half to try to find which parameters drove which colors in which tools, but finally gave up.  Kenny Aragon at Longsight is now manually building our skins for us.

I started to develop a "skin parameter thesaurus" that would identify each skin parameter and where it was used.  I found at least 97 different parameters, but had to abandon the project after it became apparent that a single parameter might be used in very different ways, depending on which tool it appeared in.  I also did write up a document, "Sakai Design Standards: Skin specifications," in an effort to identify the limited set of skin parameters that were needed and how they should be implemented throughout Sakai, if anyone is interested.

Martin

[Charles Severance]

This is the danger of me proposing an idea and *NOT* being an expert. :)

Perhaps the answer is keep SASS for various reasons but switch to a pattern where we use CSS global variables in the places where we can use them and so we can change branding, colors, font, etc in a admin / user UI.

My hope is for someone far more skilled than me to make a real proposal that makes the most sense to make it easier to change branding without requiring a developer, re-boot, re-compile - whatever.

/Chuck

[Adrian Fish]

It's a good conversation to have, whether you're an expert or not. Always good to keep an open mind.

--
You received this message because you are subscribed to the Google Groups "Sakai Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sakai-user+...@apereo.org.
To post to this group, send email to sakai...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/sakai-user/.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/sakai-user/C69077A4-3B9B-443F-984E-C0DD4B695965%40umich.edu.

[Charles Severance]

On May 29, 2019, at 10:37 PM, Michael Greene <michael...@duke.edu> wrote:

Would we have to remove Bootstrap since that is baked in as the starting point of our SASS compile? 

No - If removing Bootstrap is a side effect of any of my ideas - then I am 100% opposed to my ideas. :)

/Chuck

[Eduardo Rey Jara]

Hi everyone again :)

Martin, the reason almost every single tool has a different HTML tags and classes in Morpheus is because we tried to standarize de view but we couldn't refactor every tool. Right now, when a tool is being updated or upgraded we try to standarize them before we do the PR :) ... step by step, bit by bit.

So, if we agree on maintain SASS and Bootstrap hehehe I volunteer to upgrade Morpheus with SASS Variables if that's what community decides. Of course, doing what Shawn F. commands right now he is the person who has more knowledge on SASS skins. Great conversation indeed,

Cheers.

El jue., 30 may. 2019 a las 16:51, Bryan Ollendyke (<bto...@outlook.com>) escribió:

Sorry if you get these twice but I joined the sakai dev list to post these:

 

Since Chuck pinged me on this let's see if this actually goes through.

The HAXTheWeb / ELMS:LN group is handling this through our own color pallet that's a series of intentional CSS vars. We were doing classes but have just recently abandoned that for css vars. You can see our color set for our component here -- https://webcomponents.psu.edu/styleguide/?selectedKind=Pattern%20Library%2FAtoms&selectedStory=Color&full=0&addons=1&stories=1&panelRight=0&addonPanel=storybook%2Fstories%2Fstories-panel

These CSS vars are applied globally by a web component which manages all state of our color library and objects for querying to obtain very specific colors -- https://www.webcomponents.org/element/@lrnwebcomponents/simple-colors

This plays right into accessibility because using these patterns of naming --simple-colors-default-theme-green-6 for example, we can guarantee contrast ratios as well as UI consistency throughout our element (and non element) sets. Numbers go 1-12, we support dark / light variations and we largely don't think about accessibility of colors it just happens if we follow the conventions. These colors were generated in conjunction with our accessibility office so if they are something you all want to adopt we'd be happy to help make that happen.

We replaced SASS about a year and a 1/2 ago and I'll never go back to it. There's nothing wrong with it but CSS vars, advancement of web components, as well as recent Edge/IE announcements means that the world is only web components here out for our team.

Happy to discuss this or other WC issues at Apereo next week, our team (just me this time) is leading a training Sunday on web components.

To help add to the confusion for you all -- PatternFly (code name for Red Hat's element set) https://github.com/patternfly/patternfly-elements Uses SASS heavily in conjunction with web components.

Speaking to design framework shift / grind in our own work. In ELMSLN the last 4 years we went:

• To SASS + Foundation (zurb)
• To SASS + Foundation + MaterializeCSS
• To Foundation + MaterializeCSS + web components (so scoped but ShadyDOM)
• To MaterializeCSS + web components (so scoped but ShadyDOM)
• To now, web components (pure ShadowDom) with bits and pieces of MaterailizeCSS here and there as legacy

If you are in fact going to start going towards web components I'd bake in some kind of strategy where you make elements which work with your styles / current vars and see how to untangle / work backwards towards the microframework approach in the next few years. Brightspace (https://www.webcomponents.org/author/BrightspaceUI) has their elements up on webcomponents.org if you'd like something to react to as far as a system obviously built, running, and then augmenting with webcomponents (keep in mind they use V0 spec which is not the way to start now).

~!Bryan

From one, many: Ex Uno Plures

---

From: Eduardo Rey Jara <sedu...@gmail.com>
Sent: Thursday, May 30, 2019 2:47 AM
To: Michael Greene
Cc: Sakai Development; Adrian Fish; alan....@pepperdine.edu; sakai-user; bto...@outlook.com
Subject: Re: [sakai-dev] Re: [sakai-user] Re: Sakai-20 Skinning Idea - Get rid of Less and Sass

 

[Bryan Ollendyke]

The HAXTheWeb / ELMS:LN group is handling this through our own color pallet that’s a series of intentional CSS vars. We were doing classes but have just recently abandoned that for css vars. You can see our color set for our component here -- https://webcomponents.psu.edu/styleguide/?selectedKind=Pattern%20Library%2FAtoms&selectedStory=Color&full=0&addons=1&stories=1&panelRight=0&addonPanel=storybook%2Fstories%2Fstories-panel

These CSS vars are applied globally by a web component which manages all state of our color library and objects for querying to obtain very specific colors -- https://www.webcomponents.org/element/@lrnwebcomponents/simple-colors

This plays right into accessibility because using these patterns of naming --simple-colors-default-theme-green-6 for example, we can guarantee contrast ratios as well as UI consistency throughout our element (and non element) sets. Numbers go 1-12, we support dark / light variations and we largely don’t think about accessibility of colors it just happens if we follow the conventions. These colors were generated in conjunction with our accessibility office so if they are something you all want to adopt we’d be happy to help make that happen.

We replaced SASS about a year and a 1/2 ago and I’ll never go back to it. There’s nothing wrong with it but CSS vars, advancement of web components, as well as recent Edge/IE announcements means that the world is only web components here out for our team.

Happy to discuss this or other WC issues at Apereo next week, our team (just me this time) is leading a training Sunday on web components.

To help add to the confusion for you all -- PatternFly (code name for Red Hat’s element set) https://github.com/patternfly/patternfly-elements Uses SASS heavily in conjunction with web components.

Speaking to design framework shift / grind in our own work. In ELMSLN the last 4 years we went:

To SASS + Foundation (zurb)

To SASS + Foundation + MaterializeCSS

To Foundation + MaterializeCSS + web components (so scoped but ShadyDOM)

To MaterializeCSS + web components (so scoped but ShadyDOM)

To now, web components (pure ShadowDom) with bits and pieces of MaterailizeCSS here and there as legacy

If you are in fact going to start going towards web components I’d bake in some kind of strategy where you make elements which work with your styles / current vars and see how to untangle / work backwards towards the microframework approach in the next few years. Brightspace (https://www.webcomponents.org/author/BrightspaceUI) has their elements up on webcomponents.org if you’d like something to react to as far as a system obviously built, running, and then augmenting with webcomponents (keep in mind they use V0 spec which is not the way to start now).

[Adrian Fish]

Speaking in terms of rubrics in Sakai, with the frontend written using lit-element - we made it so they share the communal dom, no shadow dom partitioning at all. That way all the rubrics markup is targetable by the existing morpheus skin without any changes being necessary. In other words we didn't write webcomponents, we wrote custom elements. I don't think anyone will want to use the rubrics comment editor outside of Sakai, for example, so the effort of making things fully modular components just wasn't worth it.

Cheers,

Adrian.

--

You received this message because you are subscribed to the Google Groups "Sakai Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sakai-dev+...@apereo.org.
To post to this group, send email to saka...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/sakai-dev/.

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/sakai-dev/4246d87d-56d1-4130-8158-ea9f2d23bfc1%40apereo.org.

[alan.regan]

Ditto.

--Alan

On Thursday, May 30, 2019 at 6:52:03 AM UTC-7, Feller, Kathy wrote:

Martin,

 

We’re interested. Can you send me your document?

 

Kathy

--

[Matthew Jones]

If SASS was just the variables it would make sense, but it's also mixins, extends and probably other things being used. Moving to CSS variables might work but not sure about removing SASS entirely. This is somewhat what it sounds like Eduardo has been saying.

The SASS hasn't worked consistently with Sakai because of the multiple frameworks used and this is something identified by the UX team but is still a work in progress. If we had written it rewritten Sakai all in one framework this would have all been easier. 😀

[Charles Severance]

On Jun 1, 2019, at 9:46 AM, Matthew Jones <jon...@gmail.com> wrote:

If SASS was just the variables it would make sense, but it's also mixins, extends and probably other things being used. Moving to CSS variables might work but not sure about removing SASS entirely. This is somewhat what it sounds like Eduardo has been saying.

The SASS hasn't worked consistently with Sakai because of the multiple frameworks used and this is something identified by the UX team but is still a work in progress. If we had written it rewritten Sakai all in one framework this would have all been easier. 😀

I am not arguing at all about which framework here - just a way to change colors and branding without a server script needing to be run.

Given what you say above, (again I know little about this) it sounds like we keep SASS for all those other reasons. But instead of having SASS put in hard-coded colors, we put the hard-coded colors in as global CSS variables in a small and another CSS file and then have SASS promulgate references to those CSS variables in\stead of hard-coded color values into the derived CSS files.

We could then build a UI to let admins, sub admins, and even end-users manipulate those variables.  That is all I am trying to go for here.  The ability to change simple branding (like a logo) and colors without re-running scripts or doing a restart on the server.

This might be a really small change in the CSS flow and a pretty simple UI to be built.

/Chuck

[Matthew Jones]

Ah, that sounds like a different question then.

It's not about "Let's get rid of SASS" (Original topic) but more "Let's see if we can use CSS custom properties (variables) instead of SASS variables to make skin customization easier"

I feel like the answer to that second part seems a lot more likely, but SASS is still going to stick around for awhile.

Back in the day Edia developed a Skin Manager [1] but AFIAK it wasn't used much outside of rSmart though I believe many of their clients used it. I'm betting that the Sakai 11 skins didn't allow this to work very well anymore but looks like they did release an 11 version. 

Oxford also had a relatively simple fix (that EDF developed) that allowed for the banner bar to be customized per site easily to allow you to have a different logo, etc. [2]

This wouldn't allow the full customization you describe but is even more straightforward than changing the whole skin. 

These won't fix *every* problem brought up in this thread (those 1000 cuts are what SWITCH [3] is identifying) but could help!

As an aside, Canvas has a nice little Theme editor [4] that's like what you describe, however most schools don't have as many themes as LAMP. Having a way to upload themes does seem nice to have (and we already mostly have that tool from Edit) and adding in the css custom properties without compiling. Also related to this the best feature (IMHO) of the Canvas theme editor is you can upload Javascript code as part of the theme to add new functionality. In Sakai the only way we've really had to do this is with the sakai.property. (via good ol' SAK-15097 and SAK-29001) ;)

[1] https://confluence.sakaiproject.org/display/SM/Home

[2] https://jira.sakaiproject.org/browse/SAK-31577

[3] https://confluence.sakaiproject.org/display/SWITCH/SWITCH+Project

[4] https://community.canvaslms.com/docs/DOC-10891-4214418311

On Wednesday, May 29, 2019 at 11:02:02 AM UTC-4, csev wrote:

[Eduardo Rey Jara]

Hi everyone,

My two cents...

It's assumable changing SASS variables inside morpheus to use CSS variables without so much pain. Then, we can set up a default value for them scoping by responsive, non-responsive, etc and that could be overwritten on frontend by that tool you are comenting.

Cheers,

--

You received this message because you are subscribed to the Google Groups "Sakai Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sakai-dev+...@apereo.org.
To post to this group, send email to saka...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/sakai-dev/.

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/sakai-dev/93db198c-4c53-4651-9e3a-b17228ab2fa6%40apereo.org.

[hhale]

So from what I gather, we have a clear path(s) forward, just need to finalize a plan.  Whatever its final form, having it ready for Sakai 20 seems doable and certainly has my support.  So what are the next steps to make it a reality?

To unsubscribe from this group and stop receiving emails from it, send an email to saka...@apereo.org.