Theme development: Segmentation, control and normalization?

[mbria]

Hi fellows,

I'm building a new theme for a new magazine and as in every OJS theme... I found I need to deal with /styles or /lib/pkp/sytles folders (In other words: shared CSS for every OJS magazine).

May be it's just me, but would be nice to avoid those shared CSS if you want.

So those are my suggestions to improve OJS's templates:
a) Separate "presentation" and "functionalities" (just in case somebody don't want -for instance- change notifications tooltips, but wants to remove the CSS responsible of the fonts, colors and so on...)
b) Add a new function in vim lib/pkp/classes/template/PKPTemplateManager.inc.php called "deleteStyleSheet' or so (resetStyleSheet function could be a fast easy solution).
c) And last, but not least: Work over normalize.css (or resetCSS if is your preference)

BTW, I normally take the uncommon theme (or one of my theme adaptations) as an starting point but today I started over Vanilla.
Any suggestion about the BaseTheme?

Just my two cents, hoping it will be useful for OJS' improvement.

Cheers,
m.

[mbria]

I missed to say that normalize.css could be added to your theme (pe: FooThemePlugin.in.php) with activate method as follows:

Code: Select all

    function activate(&$templateMgr) {
            // Subclasses may override this function.

            if (($stylesheetFilename = $this->getStylesheetFilename()) != null) {
                    $templateMgr->addStyleSheet($path);
                    $path = Request::getBaseUrl() . '/' . $this->getPluginPath() . '/' . 'normalize.css';
                    $templateMgr->addStyleSheet($path);
                    $path = Request::getBaseUrl() . '/' . $this->getPluginPath() . '/' . $stylesheetFilename;
                    $templateMgr->addStyleSheet($path);
            }
    }

But I think it's a good idea to include it directly in every theme... and if somebody doesn't like it, just "resetStyleSheet()".

Cheers,
m.

[asmecher]

Hi Marc,

The CSS that's currently in OJS (and OCS and OHS) is pretty garbled and has been for some years. We've been hesitant to tackle it because a lot of people have tweaked the CSS and we wanted to overhaul it properly, once, rather than forcing people to adapt to successive refinements when they just wanted a stable layout.

The structures in OMP are most of the way towards the solution we want for OJS. They still involve lib/pkp, and in fact divide the stylesheets up into many more pieces than OJS did, but they use much more logical structures -- and in the coming spring we'll be working to improve those structures and fold them into OJS. One of our major goals here is to make theming easier.

In the meantime, the best way to theme OJS is to build a stylesheet overriding the specific styles that exist in the built-in stylesheets that you want to change. It shouldn't be necessary to modify existing stylesheets, just to override the styles they specify. This means the resulting stylesheet will be tasked with undoing many of the styles you don't like, but that's unfortunately a necessary evil at the moment.

Regards,
Alec Smecher
Public Knowledge Project Team

[mbria]

Hi Alec,

Thanks for your comments.

I noticed that OMP is better on a) [Separate "presentation" and "functionalities"]
but still lacks on b) [Methods to control CSS/JS loading from theme definition]
and c) [normalize.css or resetCSS libraries]

Finally, CSS mix and compression is not mandatory but would be also appreciated as performance improvement.

From this list, if I'm reading the code correctly "b)" could be implemented in less than 10 minutes (at least a simple resetStyleSheets()) and I believe will help themers that want a completely clean starting point to build their "skins".

What do you think?
I can submit a patch with the new resetCSS method if you like.

Cheers,
m.

[asmecher]

Hi Marc,

Your assessment looks correct to me; the remainder of the work will need to be done in the coming few months. (Note that we're using LessPHP, which compiles Less-format stylesheets into a single compiled CSS file; further compression could be added there.)

The style has not yet been well separated from the structure. My thinking is currently that we'll do a better job of this, and then allow the user to use their own style CSS rather than load it on top of the existing theme CSS to override previous styling (as is currently done with OJS). However, I'm very much open to input on the details of this, i.e. how much styling should be built in and how much should be left to the CSS author.

Thanks,
Alec Smecher
Public Knowledge Project Team

[mbria]

Including a CSS compiler are a really good news.
Thanks. It will definitively make themers' live easier.

About the resetStyleSheet() method I suggested "could be developed in 10 minutes"... I found it's not as easy as I expected.
Looks like in OJS 2.3.6 some CSS are hardcoded in header's templates so "templateMgr" object can't remove them in the same way addStyleSheet() method can add.

Any case, would be nice if PKP takes in consideration the proposal of improving theme/CSS/JS methods in future OxS releases with methods like deleteStyleSheet($path), resetStyleSheet().

Cheers,
m.

[asmecher]

Hi Marc,

When we get to coding that (which shouldn't be too long) I'll try to make sure we do some consultation on the forums first.

Thanks,
Alec Smecher
Public Knowledge Project Team

[asmecher]

Hi all,

FYI, I'm gathering requirements for some theme work for the forthcoming OJS 3.0 release. If you're interested in contributing, or want to follow the discussion, please let us know or CC yourself to the following bug entry:

http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8265

The CSS structures already introduced to the OJS 3.0 codebase will make CSS work much less painful for future releases. Help us get modern theming done right!

Regards,
Alec Smecher
Public Knowledge Project Team

[mbria]

Alec, I was unsure if I need to publish here or it's better if I post in bugzilla, or in a new specific post...
Let me know if I need to move it.

I still didn't find time to review OMP/OJS 3.0 in deep (I just took a fast brief look so sorry in advance if I'm talking rubbish or some points were taken in consideration in your new approach) but I know well former 2.x versions and I can say the main problem was in the HTML code that is not created thinking in making themers' live easier.

I mean, more div-grouping is required, css IDs&classes are inconsistent (or worst when missing) and some stuff is harcoded (the first think comes to my head is ">>" for "li" tags)... and this is an incomplete list.

Fixing HTML is, IMHO the "priority 0" of the work that need to be done with OxS theming (in other words: a full and detailed template review is required).

Alec posted at bugzilla the following comment:

> Need to consider how to treat "default" theme -- is it actually a theme, or should it be always included and selectively overridden as per OJS?

This is a good question. In short: Both.
We need to offer a basic theme that could be "selectively overridden".

I'm sorry to say that default theme (OxS 2.x) is useless when not an annoyance. From my experience, you spend most of the time overwriting styles instead of building what you need.

Any case, we need to distinguish between "default" and "base" themes. Alec, I know this is perfectly clear for you but let me clarify for other readers.

The "default" theme will be the one enabled by default when OxS is delivered so it will be the most usable, solid, nicer... the most impressive theme we have (and by the way, I suggest OxS to hire a designer to create this default theme).

In the other hand, the "base" theme need to be the most boring one... need to be the "minimal expression", need to be those CSS that we are completely sure will be required in absolutely every theme build in future. It very means very, very basic styling, but also normalization, cross browser styles and responsiveness (normalize, reset, modernizer...) etc.

Till now I was talking about how I think OxS theming system could be fixed (a first/fast approach). Let me talk a little about how to improve it:

As I pointed in former posts, would be nice to give themers a better control over the CSS that are loaded with functions as deleteCSS() or resetCSS() but this is just the beginning. In future we will need a template system that allows themes to build variations based on inheritance and functions to get all the control.

Let's see an example: What happens if I like to move the menu to the footer in just one magazine of my OJS?

Right now, with OxS 2.x the only solution I know now is the "mojo" approach (viewtopic.php?f=8&t=7578)... but also with "mojo" it means that we need to keep different templates for each "themed" magazine and it makes maintenance a little bit more difficult.

I believe template overwriting (or to be more precise "inheritance") it's an important improvement, a "must be" in future for every OxS product.

I'm not a big fan of smarty but if we are following with it (I full understand a change here means a huge task and in confidence I'm unsure it will mean a real improvement in performance and features) I believe we need to migrate to version 3 to take advantage of the "Template Inheritance" features.

Here you have a very biased list with some opinions, comparatives and features of different template engines to start the discussion:

* http://fabien.potencier.org/article/34/ ... nes-in-php
* http://gonzalo123.com/2011/01/17/php-te ... omparison/
* http://webification.com/best-php-template-engines
* http://www.smarty.net/v3_overview

We also need to establish CSS coding standards (for code and comments) and best practices.
Here I publish some links as an inspiration (or to adopt directly as our own standards).

* http://smacss.com/
* https://github.com/necolas/idiomatic-css
* http://www.slideshare.net/stubbornella/ ... iented-css
* https://github.com/styleguide/css
* http://www.mediawiki.org/wiki/Manual:Co ... ntions/CSS
* http://google-styleguide.googlecode.com ... sguide.xml
* https://developers.google.com/web-toolk ... GuideUiCss
* http://www.starbucks.com/static/reference/styleguide/
* http://helloanselm.com/2012/my-coding-s ... uidelines/
* http://csswizardry.com/2012/04/my-html- ... ing-style/
* https://drupal.org/node/1886770
* -> https://drupal.org/node/1887862
* http://coding.smashingmagazine.com/2007 ... ss-coding/

There are a lot of CSS "frameworks" but today "bootstrap" would be my suggestion (again IMHO).
Taking advantage of http://bootswatch.com would be a very nice feature for every OxS... and this is only one of the benefits of bootstrap.

I didn't know the work done in this sense by CUDevMaxwell&tikidream until today (viewtopic.php?f=28&t=9464), but it could be a very good starting point. If bootstrap means we need to modify OxS code I think we must adapt it to support it natively.

It finally drives us to the CSS preprocessor: Although SaSS&Compass is richer in features I'm happy you decided you use LESS, because:

* Bootstrap compiles faster with LESS
* LESS is written in JS, whereas SASS is written in Ruby. We also have lessphp compiler at server side.
* "LESS is simple"

As a themer...

* I would like a system that let me start a theme "from scratch".
* I would like to have a system that lets me start a new "subtheme" as a little variation of a former one.
* I would like to have a built-in structure to build responsive sites.
* I would like to have a CSS preprocessor.
* I would like to have a better documentation and rigid coding standards.
* I would like to have a bigger gallery of themes as starting point.
* ...

So in conclusion, I think would be wonderful that OxS base themes would be a bootstrap over smarty 3 and a set of new theming functions that could be preprocessed with LESS.

Sorry for the long post. Hope this makes sense to you... at least as an starting point for the discussion.

Cheers,
Marc Bria.

[asmecher]

Hi Marc,

Thanks for all the details -- yes, it's a long post, but this is a big subject and we want to do it right. Let's continue the discussion here for now.

First, the good news:

• As you've noticed, LessPHP is being used already for the new theming structures
• We're using much better markup, and it's much more centrally generated using standardized UI tools like grids and modals (often inheriting from JQueryUI and extending with a few additions and a PHP-backed implementation)
• More or less all of the old CSS will be torn out of OJS by the time 3.0 is released

Already the OJS 3.0 codebase (git master branch) contains very little of the old OJS mark-up -- though we do need to complete more refactoring before it'll all be gone.

I think a look at the alpha release will give you a good sense for what we have in mind. This will be available fairly soon, though if you want to get a jump on it, you can look at the master branch. Or OMP 1.0, for that matter.

LessPHP has been good to us so far; there are a few options for using it to bring in themes as well. My current preference is:

• Ship OJS with a compiled CSS file from LessCSS sources
• Theme plugins may ship with Less files if they like, but maintainers should compile these into CSS and include the compiled CSS as part of the plugin
• The compiled CSS for OJS will be included in the header template, followed by any theme CSS file(s), which may have also been compiled with Less or may be written directly in CSS.

This means that all Less compilation will happen manually. It does limit the theme's ability to intervene in the OJS Less files, except by overriding shipped styles in a later include, as is currently done with OJS. The massive improvement in CSS and markup structure should make this a much less inconvenient way to work than it has been in the past.

Alternative approaches include giving the system enough smarts to know when to recompile its own CSS files with LessPHP. Generally I'm not in favour of this because I don't like treating compilation as a runtime activity, and it breaks the KISS principle. On the other hand, it would permit themes to mix in CSS at other points in the process, and would compile system and theme CSS into a single file rather than having the reader's browser fetch them separately.

Currently the "base CSS" provides basic structure and layout, and the "default theme" adds a fairly neutral set of design decisions such as colours and fonts. The separation between the two is basically there but will need some cleanup. When another theme is chosen, the "default theme" CSS will not be applied (unlike current OJS practices).

As for Bootstrap and responsive design, we will need some outside expertise: our development team is fairly heavy on back-end development skills and correspondingly light on front-end. There are already several CSS libraries included in OMP 1.0 (the same for OJS 3.0) and I would like someone with front-end expertise to look at the set we're using and determine whether which we should turf and which others to incorporate.

I haven't yet assessed Smarty 3.0 but I'm fairly sure it's off the table for the OJS 3.0 release; we simply have too many other things to tackle at the moment. I think the way we're treating templates already in the master branch shows major improvement on the 2.x approach. Like transitioning away from ADODB, I would love to modernize our Smarty implementation, but other things are currently more pressing. Once we have OJS fully modernized as per OMP 1.0, our platform will be much easier to shift in this way -- currently we're basically maintaining two (or more) platforms at once. (We will have to consider how OCS and OHS fit into this, of course, but that's a discussion we're putting off until later.)

Caveats: 1) I have not done my homework yet by reading the links you provided above; and 2) Front-end development has never been a particularly strong skill. Your ideas are more than welcome, even (especially) if they contradict mine.

Regards,
Alec Smecher
Public Knowledge Project Team